導讀

隨着AGI理論的不斷突破，智能體已經成為LLM在企業落地的最重要的形式之一。一個完備的智能體必須能實現：感知、推理、計劃、執行等一套完整的功能，從工程的角度來看workflow特別適合這種複雜任務的分析、拆解、重組、執行,  再結合CoT技術, 實現LLM和業務功能完美契合的智能體應用。本文嘗試用成熟的圖引擎技術驅動workflow探索更多樣性的拓展agent能力的方法，以更好應對各類業務場景。

01 簡介

1.1 什麼是智能體

以大模型(LLM)為核心, 具備以下特性的智能化系統：

• 交互性: 通過文字，語音，圖像等多種交互方式來理解用户的持續性需求  (感知)；
• 適應性: 感知環境的變化持續進化，以更好地完成任務和適應複雜環境      (記憶)；
• 自主性: 能夠自主學習，主動思考和決策                                               (推理)；

1.2 業務形態、流程

一個智能體生態平台，用户可以在上面體驗功能各異的智能體app，同時也能讓用户將自己的優秀想法以極低的成本(通過快速組裝已有的插件、workflow、知識庫、記憶) 快速實現成新的agent。

系統特色：

• 流程編排能力：支持可視化的數據流加工，通過編輯各個處理節點將原始input加工成output；
• 功能複用能力：眾多的agent庫、插件庫都可直接複用到自己的智能體裏, 可插拔、替換；
• 低代碼能力：無需大量寫代碼，直接通過拖拽元素就能拼裝出想要的功能。

1.3 業務場景的需求難點

1.3.1 能自由組裝流程實現人機無縫銜接、數據解耦

• 能將人的需求表達和agent思考結果的進行完美串聯融合，發揮各自優點；
• 除context外更多樣性的數據傳遞方式，更好滿足workflow、cot等流程編排的場景；
• 細粒度控制數據傳遞、適配方式，滿足特定場景的靈活性和性能的平衡需求。

1.3.2 能更精細規劃路徑、簡化流程設計

• 支持多種路徑控制能力，滿足多樣性的靜態化任務編排；
• 支持在workflow內部動態編排新的子flow, 滿足動態化的場景。

1.3.3 能對流程進行統一的控制、干預

• 流程運行過程中當出現超時、異常等非預期情況需要框架能提供快速干預、退出機制；
• 擺脱對executor(執行器的依賴)，更低成本支持大量功能異構的流程。

1.3.4 能進行簡單的功能注入

• 支持在模型前後、工具調用前後等地方注入策略邏輯和觀測代碼，避免對大量節點進行浸入式改造；
• 支持流程編排時給節點初始化賦值，降低數據傳遞的成本；
• 支持任意節點信息的流式輸出能力，滿足長流程中階段性結果的sse輸出需求。

1.3.5 能支持缺少代碼能力的使用場景

• 將用户生或者LLM產生的cot轉化成具體流程配置；
• 將流程配置轉換成可運行的代碼。

1.4 為什麼自研圖引擎

1.4.1 常用智能體開發框架簡介

• LangChain框架：一個開發智能體的框架，定義了prompts,  index, memory, agents, tools, outputParser等一系列功能抽象,通過chains將各個功能串聯成應用。
• 開發模式：
• Chains:  規劃靜態任務,  很多抽象都實現了chains的接口，規劃好路徑就能讓各功能有序執行
• AgentExecutor:  執行動態任務，某些場景無法預知執行路徑，需要不同的輸入走不同的分支，因此引入代理人(AgentExecutor), 通過多輪循環推理產生最終結果
• 總結：多輪學習和推理是自主ai系統的基本的能力, Chains不具備循環”能力,  AgentExecutor多輪調度是一個不透明度黑盒。

• LangGraph：基於LangChain基礎上演化的框架，引入條件邊，賦予用户對循環的控制能力。
• 開發模式：用透明化的有向狀態圖打破LangChain動態任務的循環黑盒 (AgentExecutor)

已有框架比較注重系統的自主性，對業務執行路徑的編排能力較弱。

1.4.2 業務需求的挑戰

• 強化的路徑控制能力：既能滿足llm的多輪循環特性， 又能結合cot模式的功能編排；
• 傳統功能的結合能力：模型存在知識能力邊界，業務需要結合之前傳統功能來滿足多樣性、個性化的需求， 在數據的校驗、傳遞、併發、同步，流程控制等這些貫穿整個業務隨處可見的基建功能都需要支持。

這些都不是已有智能體開發框架本身所擅長的，從下層視角看需要提供一個更通用、更精細化控制能力的流程驅動框架增強以下特性來滿足業務需求。

02 用seda圖引擎驅動workflow的模式開發智能體

對於以上共性需求我們引入圖引擎驅動workflow的開發模式：將任務拆解成獨立的功能節點，不僅可以包含 LLM, prompts, memory, tools, 等智能體(ai)元素還融入了 分支、循環、條件、多路複用、數據傳遞等傳統應用所擅長的路徑編排、數據轉發、超時控制、錯誤處理等方面的功能，為智能體應用提供一個更強大、穩定、便於解耦且可黏合性強的基座環境。

2.1 實現更靈活的流程拆分組裝、數據解耦

2.1.1 流程拆分

元素：

算子:  若干個函數的集合，組成一個業務邏輯上可簡單描述的功能模塊；

邊：  聯接2個算子，具有方向性，代表執行順序，起始節點作為上游算子，指向節點作為下游算子；

聯接：

串聯: 一個上游算子聯接一個下游算子，上下游順序執行；

並聯: 一個上游算子聯接多個下游算子，上下游順序執行，下游算子之間並行執行；

join:   多個上游算子聯接一個下游算子，上游之間並行執行，下游等待所有上游執行完後再執行，實現匯聚、歸併。

flow:

將複雜業務功能分解成若干個易實現、解耦、可複用的算子，根據業務執行順序用邊將算子串聯起來，形成工作流。

用户請求從起始算子流入，通過flow的算子進行加工，最終從結束算子輸出，完成整個業務流程。同時支持 dag 和 dcg(有環圖)。

2.1.2 分層組裝

• 子圖(sub-flow)：把一個flow也當成一個算子(sub-flow)，直接掛到另一flow上，當數據推動到這個算子的時候就會觸發這個(sub-flow)的內部邏輯，實現flow級別的抽象和複用；
• 分層脈絡地圖：功能複雜導致算子數量過多時可以按不同粒度劃分層級，把相同抽象粒度的算子放到同一個層級，不同層級的算子通過子圖實現串聯。通過點擊進入子圖內部瀏覽功能細節，通過收攏子圖回到上層抽象，以此實現功能導航地圖，既方便瀏覽又方便解耦拆分到多人協作開發。

2.1.3 數據解耦

context共享可以方便的在所有算子間傳遞數據，算子的插拔替換、順序調整也無需考慮數據的匹配，但同時也帶來了數據加工處理過程黑盒，以及為了儘量避免參數讀、寫範圍放大而需要加強數據訪問權限保護這2個問題。

為此我們提供了額外的方式，滿足不同場景的需求。

• 鏈式推導 -- 更細粒度數據解耦

描述：上游output和下游input類型一致，就能串聯並傳遞數據。

優勢：output/intput是數據傳播的契約約束，數據加工流程清晰。相同intput, output定義的算子之間能串聯且插拔替換；相互之間不匹配的算子能通過定義中間類型的"橋接"算子來實現串聯。

短板：需要用户手工串聯算子，而且算子間容易產生串聯類型不匹配以及併發問題也需要用户自己解決。

• 自動推導 -- 自動優化使用和運行效率

描述：算子數量越多人工編排效率越低，在鏈式推導的方式上引入Referential Transparency, Single Assignment等規則約束來實現調用鏈自動推導。

優勢：可以幫助用户自動管理大量算子的聯接關係， 省時省力的同時還能在保證數據併發安全性的同時實現最大程度的並行化。

短板：關注的焦點從過程轉移到數據，用户需要對流程做設計、優化時需要從數據入手做逆向推導流程(數據是在流程中慢慢產生和迭代的)，違背了用户的使用習慣。而且對現有系統來説這種對數據讀寫的嚴格拆分、解耦往往需要全部推翻重來。

2.1.4 拷貝與引用

除了以上的數據傳遞方式外在不同的需求場景下我們同時還需要思考是傳遞數據的副本拷貝還是傳遞數據引用(本身)的問題

• context共享：出於性能考慮，基本都是採用傳遞引用的方式；
• 鏈式推導：可以手工指定，默認通過簡單的判斷下游算子的數量來自動決定：下游算子個數等於1:傳引用，大於1: 第一個算子傳引用,剩餘算子傳副本，儘可能在局部範圍內降低用户心智負擔；
• 自動推導：在Referential Transparency, Single Assignment雙重數據訪問規則保護下無需用户考慮併發安全性問題；
• 自定義：用户可以在聯接2個算子之間的邊(edge)上顯示指定是副本拷貝還是傳遞數據引用(本身)來獲取更大的靈活度。

2.1.5 類型適配

同一類功往往有多種實現，各自針對不同的使用場景有自己的優化，這些算子的input/output 往往基本結構一致，但又稍稍有一些小差異，為了更方便讓這些算子能快速插拔，提高功能複用度，降低複用成本，我們提供了一系列自動適配機制。

• 類型自動放大：內置多種數據類型及其變體自動轉換邏輯：

A  <--->  *A,  interface{}

A  -> []A, []*A, []interface{}

• 特型自動匹配：上游算子的output類型是被下游算子input類型內部組合的子類型，相互能串聯，並完成自動賦值。
• 自定義適配器：一個單獨的適配器完成2個功能類同，但是intput/output參數形式差異較大的算子之間串聯，適配器的input是上游算子的output, 其output是下游算子的input。
• 為什麼不直接用過度算子實現：避免大量轉換算子干擾業務流程；
• 為什麼不把適配邏輯放算子內：避免侵入式改造和過度引用導致耦合。

2.2 實現精細化的路徑規劃

2.2.1 多功能邊

• if：                    條件邊 (單分支)；
• switch:               多條件邊 (多分支)；
• multiplex:           多路複用邊 (同時監聽多個資源、信號)；
• optional edges:  可選邊 (按需放棄對非強依賴上游的等待)；
• while:                 循環邊 (條件和循環次數組合實現dcg)；

2.2.2 動態規劃

編譯時構建一個基礎的大致性的功能脈絡(上層基礎邏輯定義)，具體實現邏輯由執行期根據代碼運行情況及LLM返回結果動態規劃做邏輯的實時增刪、拼接、構建。

2.3 實現統一的驅動控制和干預

2.3.1 流程驅動

• executor 執行器：
• 存算分離設計：執行器讀取flow信息並驅動執行，提供路徑控制、資源調配，flow僅存儲數據；
• 一次解析多次執行：對flow進行一次解析後可以得到該flow的一個excutor, 後續相同的flow都可以通過該executor進行執行；
• 適用場景:系統裏flow異構類型有限, 都需要大量重複的被執行, 能節省每次構建重複flow的開銷。
• flow自驅動：
• 無需解析，直接執行：flow被構建出來後，利用flow自驅動的功能直接運行, 無需構建執行器；
• 適用場景：系統裏大量異構flow，或者會動態產生出新構型的flow，能節省複用度低的執行器構建的開銷。

2.3.2 錯誤處理

• 退出流程

當算子返回值 <0 時表示發生錯誤，默認直接跳到最後一個算子執行(讓系統能有一個給用户回包、打日誌的機會) 後並退出當前流程，快速終止無效的執行邏輯，迅速釋放資源。

• 逐層退出

當有多層(子圖)時候，每一層有算子返回值 <0都會直接跳轉到本層子圖的最後一個算子執行，隨即返回回上一層。用户可以按需給上層指定返回值，當給上層的返回值 >=0時候上游正常往後面算子執行，否則繼續跳到本層的最後一個算子執行，以此類推直到整個flow結束。

2.3.3 超時控制

• 圖超時

我們可以給整個flow指定一個執行的超時時間，觸發後直接跳入到本層最後一個算子(讓系統能有一個給用户回包、打日誌的機會)，這樣快速終止無效的執行邏輯，迅速釋放資源。

• 算子超時

一般沒有特殊需求我們建議根據業務接口要求通過flow控制整體超時即可，由系統自行判斷可以儘量避免一些超時設置不合理的問題，同時我們也保留單獨指定算子超時的能力，算子發生超時但flow整體沒有超時時會跳過超時算子繼續往下執行；，儘可能保持必要的靈活性。

2.4 實現通用注入

2.4.1 事件監聽

• 監聽通用事件

提供以aop接口的形式統一支持算子 on\_enter, on\_leave, on\_timeout, on\_error等關鍵事件的鈎子機制，以全局函數或者算子成員函數的形式進行改寫，以便用户能統一加入自定義的日誌記錄、監控、通知、錯誤處理等應對機制。

• 監聽自定義事件

除了上面的通用事件，我們還提供統一的機制，提供用户在算子內部任意地方加入自定義事件的能力，幫用户簡便地完成應用層框架監聽機制的建設需求。

2.4.2 附加屬性

除了context共享，鏈式推導的傳遞機制外我們還提供了額外第三種"附加屬性"的方式來給算子傳遞數據，方便用户在編輯算子時就能給算子指定一些固定屬性值，算子運行時能快速被讀取，降低初始化成本。

2.4.3 流式輸出

放置一個內置的流式輸出的算子到workflow裏，通過向這個算子的channel裏寫入數據即可實現在任意算子裏流式輸出信息來滿足sse需求，同時將流式輸出算子和最後一個算子相連，即可實現優雅退出。

2.5 實現低代碼

• 提供可視化編輯器，讓用户拖拽設計流程併產生對應的配置文件；
• 後端提供算子倉庫作為用户功能實現的基礎素材；
• 圖引擎的generate負責將配置翻譯成流程代碼， builder動態構建流程，driver負責驅動流程運行並返回結果。

2.6 seda相較其他圖引擎實現的優勢

2.6.1 圖引擎實現方案一：多線程併發(thread-base-on-request)

本質：線程數和請求數N:M的模型，基於請求數量規劃線程的設計， 由操作系統保證線程調度、資源分配的均衡。

優勢：實現簡單、數據局部性好，負載在系統處理能力閾值內性能及佳，適用於對耗時要求苛刻的場景。

短板：

• 流程黑盒：線程粒度太粗(請求粒度)，不利於功能迭代、優化。
• 擴展性差：請求數受系統線程數制約, 負載超出系統處理能力閾值會使系統陷入“調度內耗” (上下文切換，鎖競爭)，處理能力指數級下降。

2.6.2 圖引擎實現方案二：事件驅動併發(thread-base-on-resource)

本質：資源數和線程數N:M的模型， scheduler根據系統資源初始化若干線程，將請求拆解成由若干個non-blocking節點組成的有限狀態機(FSM)，節點執行後將狀態回傳給scheduler, 由其根據當時資源使用情況分配下一個節點的處理線程，直到整個有限狀態機結束。

優勢：

• 流程可視：通過有線狀態機實現各個功能節點之間互相解耦；
• 擴展性佳：線程數不受請求數影響，能始終控制在系統資源可高效運行的閾值範圍內；
• 吞吐量大：事件驅動極大程度避免了多線程之間的"資源內耗"，能有效提升系統併發和吞圖。

短板：

• 時延增大：一次請求處理過程跨多個線程執行增加了數據傳遞消耗的同時也降低了硬件緩存命中率導致請求延遲增大；
• 實現困難：中心化的scheduler調度器既要驅動業務狀態流轉又要管理資源調度往往會顧此失彼。

2.6.3 圖引擎實現方案三：基於seda的圖引擎驅動(thread-base-on-stage)

seda：staged event driven architecture

本質：將上面中心化的scheduler模塊給拆分成多個子部件實現。

• 用多個事件隊列將每個狀態節點(stage)， 組成一張數據流動網絡 (Directed Graph)；
• 每個stage都由事件隊列(接收數據)、控制器(分配資源，驅動stage流轉)、線程池(調節線程數)、事件處理器(業務處理handler)組成；

優勢：

• 資源按流程stage拆分,粒度適當 （按request粒度過小，容易陷入內耗；按resource粒度過大，容易浪費）；
• 去除中心化模塊，通過對事件隊列的流速控制使得每個stage可以單獨進行負載調節。

短板：

相比運行狀態良好情況下的單線程處理一個請求的設計, 時延上會有增大 。

03 通用圖引擎在智能體場景的實際應用

3.1 功能場景應用

3.1.1 根據大模型COT結果動態生成子workflow

• query：請預測下明年下週的天氣情況
• 大模型將問題拆解成具備先後依賴關係的多個小步驟：

1. 計算下一週對應的時間範圍
2. 查詢本週天氣情況
3. 查詢歷史上前n年對應時間範圍的的天氣情況，
4. 根據歷史查詢結合當前情況推測明年對應的時間範圍的天氣情況(結果保存到短期記憶)
5. 如樣本範圍太小或結果單一則重複前面過程3-4，直到給出預測結果的具體概率分佈

• 大模型根據當前執行到的具體步驟將工作內容動態分解到子圖並執行。

3.1.2 複雜場景的功能拆分解耦和精細化路徑控制能力

• 用"多路複用"同時監聽多值，支持任意數量路徑分發，將 "路由和子功能調用" 算子進行拆分解耦；
• 用"可選邊"將多處可能會觸發到的公共邏輯"潤色模型"模塊拆分成獨立算子；
• 用過"融合邊"將各種不同類型的邊融合匯聚到一個算子, 便於整體控制流程結束邏輯；
• 通過以上多種精細化路徑控制功能，減少大量膠水代碼的同時方便對流程圖做快速修改，讓用户專注於業務邏輯自身。

3.1.3 通用注入和循環增強

• 由侵入式改造轉變成通用事件注入來統一控制算子內部的共性行為；
• 個性化功能增強也可以通過非侵入式方式注入算子內部；
• 在之前純代碼邏輯控制循環結束條件的同時增加了框架保護機制，避免響應不及時和資源長時間侵佔。

3.2 小結

通過圖引擎驅動workflow的開發模式提供了一個強大的基座，用户可以快速在其上通過插拔替換、順序調整、串聯匯聚、編輯出任意自己想要的流程，其強大的解耦和精細化路徑控制能力從根本上解決傳統ai開發模式帶來的黑盒問題和相關不確定性問題，同時還能獲得極佳的運行時效率(天然併發)；其自帶的低代碼、分層導航等特性減少了大量膠水代碼，還有助於多人同時入場並行開發，降低開發、維護成本。

目前系統已經接入80w開發者，15w合作企業，超過10w個智能體。

————END————

推薦閲讀

直播間互動框架性能優化與穩定性實踐

百度網盤防雪崩架構實踐

如何在百度百舸部署滿血版DeepSeek-V3、DeepSeek-R1模型

首日調用客户破1.5萬！DeepSeek-V3/R1上線背後的超低推理成本技術揭秘

喚醒 AI 算力，專有云 ABC Stack 面向企業級智算平台的 GPU 提效實踐