輕鬆搭建AI版“誰是臥底”遊戲，muAgent框架讓圖譜秒變編排引擎

全新Agent框架，將知識圖譜從知識獲取來源直接升級爲Agent編排引擎。

螞蟻集團推出muAgent，兼容現有市面各類Agent框架，同時可實現複雜推理、在線協同、人工交互、知識即用四大核心差異技術功能。

這套框架目前在螞蟻集團內多個複雜DevOps場景落地驗證，同時可通過快速搭建的創新AI文本遊戲“誰是臥底”遊戲快速感受一下。

站在當前視角，LLM大模型能很好的解決通用單步任務（如SQL生成）、單步工具使用（如天氣查詢），但實際現實中的場景卻是複雜多步驟的，尤其面向嚴謹專業私有領域，LLM只能給出泛泛而談的答案（包括ChatGPT），面向C端體驗用戶可能問題不大，面向B/P端實際生產時卻往往用處不大。

螞蟻團隊認爲大模型就像才畢業的名校博士，具備優秀的基礎素養，但卻無法面向特定領域進一步學習，能夠面向特定領域給出完善的任務規劃決策。LLM能逐步協助人來解決問題或者Agent能實際解決問題，核心在於PLANNER推理能力。

人面向專業複雜事務處理具備豐富的經驗，人的經驗從哪裡來？兩部分：

muAgent基於LLM+EKG（Eventic Knowledge Graph行業知識承載）驅動，協同MultiAgent、FunctionCall、CodeInterpreter等技術，通過畫布式拖拽、輕文字編寫，讓大模型在人的經驗指導下幫助你完成各類複雜多步任務。

muAgent整體架構

爲了實現複雜多步流程SOP（Standard Operating Procedure）自動化，先來看SOP的構成。拆開抽象，任何任務流SOP的推進本質由三部分組成“經驗”+“工具”+“人物”，銜接LLM推理，實現整體三者的有機結合。

經驗：面向特定專業領域，複雜任務是如何操作處理？流程步驟是什麼？工具：在流程推進中，周邊工具的使用，使用什麼工具？如何使用工具？人物：在流程推進中，周邊人物的諮詢，找誰（人、智能體）？問什麼？

爲此，muAgent整體的架構大圖如下，和業界Agent框架定義對標，包含Planner、Memory和ActionSpace三大核心模塊，以及Diagnose的調試監控和Interface的產品界面。

爲方便理解，接下來通過“誰是臥底”這一AI文本遊戲串聯整個流程的介紹。通過簡易畫布拖拽加上輕文字編寫，即可實現這一遊戲的快速體驗。中間的流程即剛纔提及的“經驗”，下方深紫框即“工具”，上方淺籃框即“人物”。

muAgent中的經驗模塊

存儲結構

面向不同行業、不同類型的工作流/SOP，該如何抽象統一，能夠比較好地設計schema來存儲經驗知識？古語有云“授人以魚不如授人以漁”，即應該設計存儲“過程經驗”，而非“結果經驗”。相比存儲狀態結果，更應該告訴大模型如何來做一件事獲得結果。例如相比於僵化的告知大模型今天天氣如何，更合適的做法是教會大模型如何去查詢天氣。muAgent設計了“場景意圖+事件流程+組織人物+統一工具”四大類節點，可滿足不同場景所需的SOP經驗承載。如下圖所示。

由於任務流通常天然呈現爲圖或者樹結構，因此muAgent採取圖數據庫來承載經驗的存儲。相比傳統的RAG，或者微軟的GraphRAG—-更多的是把知識圖譜KG作爲一個數據的來源—-muAgent直接把KG升級作爲編排引擎。通過“拖拉式”“輕文字”編寫實現特定領域複雜SOP的沉澱以及SOP的自動化。

經驗獲取

有了經驗的存儲設計，就像有了人腦，接下來要解決知識的獲取構建問題。muAgent提供兩種經驗構建能力。第一種是剛纔提及的通過產品側畫布式輕文字編寫；第二種是面向海量的存量文檔，muAgent具備自動化抽取的能力，能將普通文本和流程圖自動抽取轉換爲圖譜結構。對於抽取的部分信息錯誤或者信息缺失，通過簡易的編輯調試即可獲取完善的SOP經驗。

由於圖譜的引擎設計自然繼承了圖譜的能力實現，在承載經驗的同時，muAgent提供“經驗拆分”和“經驗合併”的能力。

經驗拆分：

我們期望模型具備一定的泛化能力，而不是告訴什麼回答什麼（類似DiFY固定僵化的任務流，同時不同於AutoGPT純隨機發散的推理），舉個例子，當沉澱了“杭州旅遊行程規劃”後，那麼應該抽象出“旅遊行程規劃”，在面對“北京旅遊行程規劃”的Query問題時，也應該能很好的作答。再發散一點，抽象原子經驗“酒店訂購、車票訂購、餐飲選擇”，那麼在面對“北京差旅行程規劃”時也能利用好原子經驗進行回答！類似於告訴人一個特定問題的解決思路的時候，他會舉一反三，我們期望擁有原子經驗的模型也具備這一能力。爲此muAgent提供“經驗拆分”，通過“現象-任務-判斷-結論”這一四段論的形式，結合下一小節的推理能力，實現在人的經驗指導下的發散推理。

經驗合併：

一千個人讀哈姆雷特有一千個看法，如同盲人摸象，錄入承載的經驗更像是一個抽象類的具象化，更好的做法是將不同共建的經驗合併來提供事物本質的模樣。以旅遊車票訂購爲例，距離較遠的人會沉澱經驗“車票訂購-飛機”，距離較近的會沉澱“車票訂購-高鐵”，本地遊的會沉澱“車票訂購-地鐵”，將這幾個經驗對齊合併，才能完整的形成原子經驗“車票訂購”。

經驗推理

有了經驗的知識存儲，接下要解決知識的利用推理問題。推理方面muAgent整體包含兩大模塊：

意圖識別：

面向多層意圖，支持“順序+直接”意圖定位；面向不同問題，支持意圖分類（執行OR諮詢）；面對模糊意圖，支持反問用戶以得到信息補充。

圖譜推理：

基於用戶沉澱經驗，協同FuncCall，面向不同類型用戶問題，多路推理（執行OR問答）。

muAgent中的人物模塊

人物構成

在任務流/經驗推進的過程中，避免不了和“人物”的交互。muAgent中對人物的構成整體上可以分爲三類：“智能體”、“用戶人”、“企業人”。在誰是臥底的場景中，我們已經感受到了“用戶人”和“智能體”，在這統一做下介紹和說明。

4.2.人物交流

什麼是多Agent/MultiAgent框架？核心在於多Agent信息交互的實現。多Agent信息交互即多Agent討論模式。

基於人類交流討論的模式，muAgent抽象歸納出8種討論模式，可同時滿足不同場景信息隔離訴求（全部/部分/單獨可見）。

這裡又可以歸結爲兩大類問題，信息通信（我能、應該看到什麼信息？）和信息加工（我如何能更好的看到信息？），muAgent可通過屬性的簡單配置和邊的鏈接來實現不同的場景需求。接下來，我們將通過誰是臥底的案例帶大家整體認知下不同的信息通信模式。

信息通信

公開通知：座位分配環節每個人都知道對方的座位在哪，由主持人統一分配，同時不需要針對分配結果給出回覆。muAgent通過任務節點-信息隔離屬性的“公開”設置實現。

私下通知：單詞分配環節每個人只知道自己分配到的單詞，主持人統一分配且知道每個人的單詞，針對分配單詞不需要給出回覆。muAgent通過任務節點-信息隔離屬性的“私有”設置實現。

順序發言：分享討論環節，主持人根據分配座位號，以及現場存活的人員，制定接下來發言的順序，然後實際發起每個人的分享（需回覆），每個人知道其他人的回覆。這裡新增一個工具使用模式的設置，將在工具章節詳細介紹。

信息加工

有了良好的信息通信的實現保障不同場景所需，接下來的問題就是怎麼讓人更好的看到信息。舉個大家都會遇到的場景，突然被拉入一個羣聊被艾特一個問題，需要從很長的歷史長下文中梳理出我到底要幹什麼？那麼有沒有更好的方式，直接把上下文總結提煉好了從而一眼就能知道我要幹什麼？這就是信息加工模塊存在的必要性。這裡提供3種信息加工的模式（通過屬性設置來實現），分別如下：

muAgent中的工具模塊

使用方式

介紹完經驗和人物，還剩流程推進中的最後一環-工具。先從工具使用方式出發來介紹。目前業界整體的工作可以歸納爲3種思考使用方式：

以票選兇手環節爲例，同步諮詢不同的智能體，同時給出回覆，避免不同智能體根據別人的信息輸出來僞裝自己的描述。

工具管理

使用效果

隨着以ChatGPT爲首的閉源模型和Qwen等開源模型的迅速發展，去年研究火熱的垂類模型或者定製微調（LoRA）在不斷的弱化，很可能訓練了很久都不如外部新版本迭代來的效果好。但面向工具場景，muAgent主打預置插件/工具，相同的模型見過的工具（微調）肯定比沒見過的模型效果好，尤其是企業內部複雜的API工具。爲此，團隊搭建了多Agent自動化數據構建鏈路，實現給定插件，自動化數據構建（Q+A），模型微調服務。保障在專業場景工具使用效果的準確性和穩定性。

muAgent四大核心差異

基於上述的架構設計介紹，回看最開頭提及的muAgent框架，相比現有市面各類Agent框架，四大核心差異體現在如下幾個方面：

同時muAgent還提供調試運行功能。圖譜編輯完成後，通過可視調試，能快速發現流程錯誤、進行修改優化。同時面向調試成功路徑，可關聯配置自動沉澱，從而減少模型交互/開銷、加速推理流程；此外，在線運行中，muAgent提供全鏈路可視化監控，讓排查和維護更加方便。

GitHub項目地址：

https://github.com/codefuse-ai/CodeFuse-muAgent