LangChain官方實測：多智能體架構怎么選？
在構建 AI Agent 的時候，是不是感覺當工具和業務場景一多，單個Agent就越來越“笨”，越來越不好維護？這幾乎是所有開發者的共同痛點。
怎么解決？多智能體（Multi-Agent）架構是目前最主流的方向。但問題又來了，多智能體架構有好幾種，比如 Swarm、Supervisor... 到底哪種更好用？
LangChain 官方親自下場，扒了扒幾個主流的多智能體架構，并發布了一份超詳細的性能評測報告。今天，我們就來深度解讀一下這份報告，看看官方的結論是什么，以及我們到底該如何選擇。
三大主流架構
首先，我們得認識一下這次評測的三位“選手”：
- 單智能體 (Single Agent):一個 Agent 掌握所有工具和指令，獨自處理所有任務。這是評測的baseline。
- 群聊模式 (Swarm):每個子智能體都知道彼此的存在，可以直接“接力”工作。誰拿到控制權，誰就負責干活，直到它把任務交棒給下一個。
- 主管模式 (Supervisor):一個中心化的“主管”Agent 負責接收用戶需求，然后把任務分配給相應的“員工”子智能體。員工干完活，必須把結果匯報給主管，只有主管能跟用戶溝通。
LangChain評測
LangChain 的實驗設置方式是，他們在一個真實的零售場景任務基礎上，故意加入了家居、醫療、汽車等多個無關的干擾領域，每個領域都有一堆工具和知識。目的就是為了看看在復雜、充滿噪音的環境下，哪個架構最能打。
直接來看結果。
性能得分：單體智能體，卒
結論非常清晰：隨著干擾domain增多，單智能體的性能出現了斷崖式下跌。 當有兩個以上的干擾域時，它基本就廢了。
而 Swarm 和 Supervisor 架構則表現出了極強的魯棒性，性能基本不受影響。這證明了在復雜場景下，多智能體架構的必要性。有趣的是，Swarm 的表現略微優于 Supervisor。
成本（Tokens）：主管模式有點“啰嗦”
從成本看，單智能體的 Token 消耗隨著干擾增多而線性爆炸。而 Swarm 和 Supervisor 則非常穩定。
但這里也能看到，Supervisor 的成本始終高于 Swarm。為什么呢？
其實很容易理解，在 Supervisor 模式里，子智能體不能直接和用戶說話，所有信息都得經過主管“轉述”一遍。這一來一回，不僅增加了 Token 消耗，還可能因為主管的“轉述”而出錯，這也是它性能稍低于 Swarm 的原因。
被“優化”過的Supervisor 架構才是完全體
所以，是不是覺得 Supervisor 架構又貴又容易出錯，不如 Swarm 好呢？
LangChain 表示， Supervisor 初始版本，性能爛到爆。但是經過一系列優化之后，可以獲得更好的結果！ 下圖的 old_supervisor 是初始版本。
最后，如何讓 Supervisor 架構變得好用？
主要做了三件事：
- 移除交接消息， 主管在分配任務時，會產生一些路由邏輯和決策信息。在初始版中，這些信息會一股腦塞給子智能體。優化后，這些“廢話”被移除，子智能體的上下文變得干凈，讓它能更專注于核心任務。
- 增加“轉發”工具，為了解決傳輸的損耗問題，他們給了主管一個 forward_message 工具。當子智能體生成了完美的回復后，主管可以直接調用這個工具“原文轉發”，而不是自己去復述一遍，大大減少了信息失真。
- 優化工具命名， 主管分配任務本質上也是一種 Tool Calling。他們測試了不同的工具命名方式（比如?
?delegate_to_agent?? vs??transfer_to_agent??），選擇了最不容易產生歧義的表達。
這些優化，已經集成到了langgraph-supervisor 包里。https://github.com/langchain-ai/langgraph-supervisor-py
最后
總結一下：
在需要擴展和應對復雜場景時，單智能體模式是非常脆弱的，可以嘗試多智能體架構，可擴展性、可維護性和魯棒性上優勢巨大。
Supervisor 是最通用、最靈活的架構， 雖然 Swarm 看起來性能和成本更好，但它要求每個子智能體都互相知曉，這在接入第三方Agent或構建復雜系統時幾乎不可能。而 Supervisor 架構對子智能體的要求最低，耦合度也最低，最具普適性。
本文轉載自????????探索AGI????????，作者：獼猴桃
