性能,成本,可控性：從Sub-Agents到Multi-Agent的工程詳細指南

先糾正一下，很多人誤以為 Sub-Agents 和 Multi-Agent 是兩個對立不同的架構，其實不是，Sub-Agents 是 Multi-Agent 體系下的一種架構模式，而不是一個與 Multi-Agent 對立的總體范式。

花了兩個月搭建的多智能體系統，上線后發現響應時間比預期的慢了3倍，而且每單次請求的成本直接把預算燒掉了三分之一。

這個場景，可能大家都不陌生。

當你開始搭建真正的AI應用時，幾乎都會遇到兩個致命問題：能力越來越多，單個prompt放不下；不同團隊在不同模塊里改代碼，協作變得混亂。

這時候，你面臨的選擇就很關鍵：是走Multi-Agent（多智能體）路線，還是用Sub-Agent（子代理）架構。

LangChain在《choosing the right multi-agent architecture》這篇文章中給過一個核心判斷：大多數任務仍然適合單智能體，但當"上下文管理"和"分布式開發"成為瓶頸時，多智能體才成為必要選擇。

但問題是，Multi-Agent和Sub-Agent到底有什么區別？什么時候該選哪個？

扒了很多資料，這篇文章我們就來系統聊聊這個問題。

文章篇幅稍長，但絕對干貨滿滿。

1.一個真實的試錯經歷

去年的時候，有一個朋友，他們團隊是搞金融的，他們有這樣的場景：用戶問一個復雜的問題，比如"幫我分析一下Q3的營收情況，對比去年同期，并給出改進建議"。

這個問題涉及三個獨立領域：數據查詢、財務分析、策略建議。

一開始他們用的是單智能體方案。把所有邏輯塞進一個prompt里，掛載一堆工具。

問題很快就暴露了。

首先是上下文管理失控。當需要同時處理數據查詢、財務指標計算、行業知識檢索時，prompt里塞滿了各領域的專業術語和規則。上下文窗口被占滿，推理質量直線下降。

LangChain的benchmark研究顯示，當distractor domains（干擾域）從0增加到8個時，單agent架構的性能從0.67暴跌至0.34，下降50%。

這簡直是災難性的。

也就是說，你塞進去的知識越多，模型反而越容易暈。

其次是團隊協作困難。負責數據查詢的團隊、負責財務分析的團隊、負責策略建議的團隊，大家都在改同一個大prompt。版本沖突、權限混亂、不知道誰改了什么東西，最后變成了一團亂麻。

他們意識到，必須升級架構了。

但他們面臨一個更關鍵的問題：怎么升級？

是搞一個真正的Multi-Agent系統，讓三個獨立智能體協作？還是用一個主智能體加幾個Sub-Agent？

2.Multi-Agent和Sub-Agent的本質區別

很多人會混淆這兩個概念，我先簡單的跟大家說清楚。

Sub-Agents 和 Multi-Agent 不是兩個對立不同的架構，Sub-Agents 是 Multi-Agent 體系下的一種架構模式，而不是一個與 Multi-Agent 對立的總體范式。

Multi-Agent（多智能體系統） ，本質上是一群相對獨立的智能體在協作。它們可能有各自的目標、各自的狀態、各自的上下文，通過通信協議來協調。

就像一個真正的工程團隊，產品經理、架構師、工程師、測試，大家有明確的分工，各自負責自己的部分，通過會議、文檔、工具來協同。

而Sub-Agent（子代理） ，本質上是集中式架構下的分工。一個主智能體掌控全局，把任務委派給幾個專用的子代理。這些子代理更像工具，無狀態，只處理被分配的子任務。

就像一個項目經理手下有幾個專精的執行者。項目經理知道全局目標和上下文，根據需要把任務分發給不同的人，拿到結果后再整合。

這個區別很重要。

Google Cloud的一篇文章給出了一個非常清晰的對比：Agent as Tool（工具式子代理）vs Sub-Agent（委派式子代理）。

Agent as Tool就像一個專家顧問，主智能體調用它時，給出明確的輸入，拿到明確的輸出，就像調用一個API。這個專家顧問有自己的邏輯，但主智能體不需要知道細節。

而Sub-Agent更像一個項目經理的分身，它在主智能體的全局上下文中工作，處理復雜的多步驟流程，可以訪問主智能體的對話歷史和狀態。

關鍵區別在于：控制權和上下文。

Multi-Agent模式下，控制權是分布式的，每個Agent都有一定的自主權，上下文是隔離的。而Sub-Agent模式下，控制權是集中式的，主智能體說了算，上下文是共享的。

3.性能與成本的真實對比

回到上面那個金融團隊的案例中。

他們一開始嘗試的是Multi-Agent方案。三個獨立Agent：數據Agent、分析Agent、建議Agent。每個Agent有自己的prompt、自己的工具集、自己的上下文。

從理論上看，這個方案很完美。職責清晰，易于擴展，團隊可以獨立開發各自負責的Agent。

但上線后問題很快就暴露了。

首先是延遲問題。用戶一個請求進來，需要經過多個Agent的來回協作。Agent之間要通信，要協商，要同步狀態。每次協作都增加一次模型調用，響應時間直線上升。

更嚴重的是成本問題。每次Agent之間的交互，都需要消耗token。而且由于上下文隔離，很多信息需要重復傳遞。

LangChain做過一個對比測試，結果很有意思。

場景一：一次性請求（比如"幫我買杯咖啡"）

• Skills模式（單Agent動態加載技能）：3次模型調用
• Handoffs模式（Agent間切換）：3次模型調用
• Sub-Agents模式：4次模型調用
• Router模式：5次模型調用

Sub-Agents之所以多一次調用，是因為所有結果必須回傳給主Agent進行整合與決策。這個數據還挺意外的。本來以為Multi-Agent會更快，結果反而慢了。

場景二：重復請求（兩次"買咖啡"）

• Skills模式：5次模型調用（節省40%）
• Handoffs模式：5次模型調用
• Sub-Agents模式：8次模型調用
• Router模式：10次模型調用

Skills和Handoffs因為有狀態復用，在重復請求時效率大幅提升。而Sub-Agents和Router因為無狀態設計，每次都得走完整流程。

場景三：多領域查詢（同時問三個專業問題）

這是Multi-Agent的優勢場景。

• Skills模式：約15K token消耗
• Sub-Agents模式：約9K token消耗
• Router模式：約9K token消耗

Skills模式之所以token消耗高，是因為所有專業領域的知識都會累積到同一個對話上下文中，出現上下文膨脹。而Sub-Agents和Router通過上下文隔離，每個子Agent只加載和自己領域相關的內容，節省了大量token。

Anthropic的研究也得出了類似結論。他們用Claude Opus 4作為主Agent、Claude Sonnet 4作為Sub-Agents的多Agent系統，在內部評估中比單純的Claude Opus 4高出90.2%。

但這個提升是有代價的：更高的成本和更長的延遲。

4.維度一：性能與延遲

性能和延遲，是Multi-Agent架構最需要權衡的地方。

4.1 并行能力

Multi-Agent的一個核心優勢是并行執行。當任務可以拆分為多個獨立子任務時，多個Agent可以同時工作，大大縮短總時間。

比如用戶問：幫我查一下Python、JavaScript、Rust三種語言的最新特性。

如果是Sub-Agent模式，主Agent可以并行調用三個語言專家Agent，它們同時工作，最后匯總結果。理論上可以節省2/3的時間。

但前提是這些子任務是真正獨立的。如果存在依賴關系，比如需要先用Agent A的結果去調用Agent B，那就無法并行了。

Handoffs和Router模式在并行能力上相對較弱。Handoffs是順序執行的，Agent A做完才能輪到Agent B。Router雖然可以并行調用多個Agent，但Router本身的分類和分發是串行的。

4.2 調用次數

這是影響延遲的關鍵因素。

每次模型調用都需要時間，而且可能是可觀的延遲（特別是用大模型的時候）。

簡單任務上，Skills和Handoffs只需要3次調用，Sub-Agents需要4次，Router需要5次。差距看起來不大，但在大規模應用中，這個差異會被放大。

但復雜任務上，情況就不一樣了。

比如一個需要多次交互才能完成的任務，Sub-Agents模式的優勢就出來了。因為Sub-Agents可以在主Agent的上下文中持續工作，不需要每次都重建上下文。

而Skills模式雖然調用次數少，但上下文會不斷累積，可能導致后續調用變慢或質量下降。

4.3 響應時間

響應時間 = 調用次數 × 單次調用延遲 × 并行因子

這是一個簡化的公式，但抓住了核心。

Sub-Agents模式調用次數多，但可以并行，總響應時間可能不會太差。Router模式調用次數也多，而且Router的步驟本身可能比較復雜（分類+分發），響應時間可能更長。

Skills模式調用次數最少，但上下文膨脹可能導致單次調用變慢。

Handoffs模式調用次數少，但無法并行，如果任務步驟多，總響應時間也可能很長。

真實的選擇，要看你的具體場景。

如果你的任務可以高度并行，Sub-Agents和Router更有優勢。如果你的任務需要多輪交互但領域切換頻繁，Skills可能更好。如果你的任務有嚴格的順序依賴，Handoffs更合適。

5.維度二：成本控制

成本，是Multi-Agent架構另一個需要認真考慮的問題。

5.1 Token消耗

Token消耗直接決定了你的API調用成本。

LangChain的測試數據顯示，多領域查詢場景下，Skills模式消耗約15K tokens，而Sub-Agents和Router只消耗約9K tokens，節省了約40%。

這個差距來自上下文隔離。Skills模式下，所有領域的專業知識都會累積到同一個對話歷史中，第三個Skill加載時，前兩個Skill的內容仍然占用著上下文窗口。

而Sub-Agents模式下，每個子Agent只在自己獨立的上下文中工作，只加載和自己領域相關的內容（約2000 tokens + 少量任務指令）。

如果任務涉及3個以上領域，Skills模式的token成本會迅速失控。

5.2 模型選擇

這是一個很多人忽略但非常關鍵的優化點。

Sub-Agents模式的一個優勢是，不同的子Agent可以用不同的模型。

主Agent可以用最強大的模型（比如GPT-4或Claude Opus），因為它負責全局規劃和結果整合，需要最強的推理能力。

但子Agent可以用更小更快的模型（比如GPT-4.5 Mini或Claude Sonnet），因為它們只需要處理特定領域的任務，推理復雜度相對較低。

Boris Cherny（Claude Code的開發者，前段時間很火那個）就提到過這個實踐。他在使用Claude Code時，所有工作都用Opus 4.5，但在一些簡單的子任務上，可以換成Sonnet來節省成本。

Skills模式相對靈活一些，可以動態切換模型，但切換成本可能較高。Handoffs和Router模式因為需要保持狀態一致性，切換模型的難度更大。

5.3 重復請求優化

如果你的用戶經常會重復類似的問題，這一點就很關鍵。

Skills和Handoffs因為有狀態復用，在重復請求時可以節省大量成本。LangChain的數據顯示，重復請求時可以節省40%的模型調用。

但Sub-Agents和Router因為無狀態設計，每次都得走完整流程，無法從重復中獲益。

這個數據還挺重要的。如果你的應用場景中，用戶經常會問類似的問題，Skills或Handoffs可能更劃算。

但如果每次請求都是新的查詢，Multi-Agent的上下文隔離優勢就更明顯。

6.維度三：可維護性與調試

性能和成本是外在的，可維護性和調試是內在的，但同樣重要。特別是當你的系統需要長期運行和持續迭代時。

6.1 日志與追蹤

Multi-Agent系統的日志管理復雜度比單Agent高很多。

單Agent模式下，你只需要追蹤一條調用鏈。

輸入 → Agent推理 → 工具調用 → 輸出。

但Multi-Agent模式下，調用鏈變成了網狀結構。Agent A調用Agent B，Agent B又調用Agent C，Agent A和Agent C直接通信……如何追蹤一個錯誤是哪個Agent引入的？

Sub-Agents模式相對簡單一些，因為調用鏈是樹狀的。主Agent調用子Agent，子Agent可能再調用更下層的Agent，但不會橫向通信。

Router模式的調用鏈也比較清晰，Router負責分發，子Agent負責執行，最后匯總。

Skills和Handoffs模式最簡單，因為從外部看仍然是單Agent，只是內部邏輯更復雜。

6.2 狀態一致性

當多個Agent協同工作時，如何保證它們對同一個狀態有一致的理解？

比如一個訂單處理系統，庫存Agent看到庫存是10個，訂單Agent生成了訂單，但支付Agent處理超時了。庫存Agent怎么知道訂單沒有成功？它看到的庫存應該還是10個，還是被鎖定的？

Sub-Agents模式通過共享上下文來解決這個問題。所有子Agent都在主Agent的上下文中工作，狀態由主Agent統一管理。

Handoffs模式通過傳遞狀態來保證一致性。Agent A完成時，把自己的狀態和上下文傳遞給Agent B。

Multi-Agent模式需要專門的機制，比如共享內存、消息隊列、或者事件總線。

6.3 錯誤處理與恢復

當某個Agent出錯時，如何恢復？

單Agent模式下，你可以重試整個請求，或者部分重試。

Multi-Agent模式下，如果Agent A出錯，但Agent B和C已經成功執行了，怎么辦？是回滾所有Agent的操作，還是只重試Agent A？如果Agent B和C的結果依賴于Agent A，那重試Agent A可能沒有意義。

Sub-Agents模式相對簡單，因為主Agent可以看到所有子Agent的執行結果，可以決定是重試某個子Agent，還是調整策略后重新分配任務。

Router模式需要Router來協調錯誤恢復。如果某個子Agent失敗，Router需要決定是重試、換一個子Agent，還是返回錯誤給用戶。

Skills和Handoffs模式因為調用鏈相對簡單，錯誤處理也相對容易。

7.四種架構模式的適用場景

Anthropic在ADK架構中將Multi-Agent分為四種模式：Sub-Agents、Skills、Handoffs、Router。

每種模式都有最適合的場景。

7.1 Sub-Agents：集中式編排的專業協同

適用場景：

• 多個獨立領域需要統一工作流控制
• 需要強上下文隔離
• 團隊協作，不同團隊負責不同領域

典型例子：

• 企業知識庫Agent：主Agent負責意圖理解和結果綜合，技術文檔Sub-Agent、財務數據Sub-Agent、HR政策Sub-Agent各司其職
• 個人助理：協調日歷、郵件、CRM，多個獨立領域需要統一控制

優勢：

• 強上下文隔離，避免領域間相互污染
• 集中式控制，便于協調和整合
• 易于團隊分工協作

劣勢：

• 每次交互多一次模型調用（結果需要回傳主Agent）
• 系統復雜度增加，調試鏈路更長

7.2 Skills：漸進式能力披露的輕量化擴展

適用場景：

• 單Agent需要覆蓋多種專業方向
• 功能切換頻繁但單次對話涉及領域較少
• 需要快速迭代和探索

典型例子：

• 編程Agent：在一次會話中需要Python調試、前端開發、API設計多種能力
• 創意寫作Agent：需要在SEO優化、文案撰寫、數據可視化間快速切換
• 個人生產力工具：功能多但不要求強隔離

優勢：

• 輕量，開發門檻低
• 對話連貫性強，技能加載后保留在上下文中
• 適合快速迭代和產品探索

劣勢：

• 上下文會不斷累積，容易token膨脹
• 多領域混合時性能不如Sub-Agents
• 難以嚴格隔離不同領域的權限

7.3 Handoffs：狀態驅動的流程化交互

適用場景：

• 分階段順序工作流
• 智能體需要全程交互用戶
• 后續步驟依賴前序結果

典型例子：

• 客服流程：信息收集Agent → 問題診斷Agent → 解決方案Agent
• 保險理賠：資料收集Agent → 審核Agent → 賠付計算Agent → 通知Agent
• 訂單處理：商品查詢Agent → 庫存Agent → 支付Agent → 物流Agent

優勢：

• 多輪交互自然，上下文在階段間平滑傳遞
• 每個Agent專注自己的階段，職責清晰
• 適合有嚴格順序約束的場景

劣勢：

• 無法并行處理，效率較低
• 狀態管理復雜
• 不適合需要多Agent協作的場景

7.4 Router：并行派發與結果綜合

適用場景：

• 垂直領域多源查詢
• 需要整合多專業結果
• 請求無狀態，可以獨立處理

典型例子：

• 企業知識庫查詢：技術文檔+銷售數據+法律合規并行查詢
• 電商平臺推薦：庫存Agent、價格Agent、評價Agent并行查詢
• 內容生成：不同風格的內容并行生成后綜合

優勢：

• 并行執行，節省時間
• 無狀態設計，性能穩定
• 橫向擴展能力強

劣勢：

• 對話需要歷史上下文時，每次都需要重新分類，帶來重復開銷
• Router本身的分類邏輯需要精心設計
• 不適合需要多輪協作的場景

總結一下

最后，基于我們看到的成功案例和失敗教訓，以及我們親身做的項目01Agent，從 routeragent 走向 multiagent，總結一些經驗，歡迎感興趣的朋友一起來交流。

從單Agent起步，逐步演進

不要一上來就上Multi-Agent架構。

LangChain在文章開頭就明確寫道："Many agent tasks are best handled by a single agent with well-designed tools. You should start here."

單Agent不是過渡方案，而是正確的默認值。

原因很簡單：

1. 1.單Agent更容易構建、推理和調試
2. 2.成本與延遲更可控
3. 3.便于快速迭代和驗證

只有當你真正遇到以下問題時，才考慮升級：

1. 1.上下文管理失控：單個prompt塞不下了，或者推理質量因為上下文過長而下降
2. 2.分布式開發不可避免：多個團隊需要獨立維護不同模塊

根據你的核心需求來選擇：

1. 1.需要多領域并行執行、集中式工作流管控 → Sub-Agents
2. 2.需要輕量化多能力擴展、快速迭代 → Skills
3. 3.需要分階段順序工作流、智能體需全程交互用戶 → Handoffs
4. 4.需要垂直領域多源查詢、整合多專業結果 → Router

不要為了用Multi-Agent而用Multi-Agent。每個模式都有自己的適用場景和Trade-off。

優化模型選擇

不要所有Agent都用同一個大模型。

這是一個很多人忽略的優化點。主Agent可以用最強的模型，因為需要全局規劃和結果整合。但子Agent可以用更小更快的模型，因為它們只處理特定領域的任務。

Boris Cherny提到：雖然Opus比Sonnet更大更慢，但因為你需要更少的引導，工具使用能力更強，最終幾乎總是比用小模型更快。

但這個"更少引導"的前提是，你的Agent設計得足夠好，知道什么時候該調用哪個工具，怎么組合工具的結果。

設計清晰的通信協議

Multi-Agent系統最大的坑往往在通信上。

Agent之間說什么？什么時候說？怎么說？這些都需要明確的協議。

最常見的問題包括：

1. 1.語義不統一：同一個詞在不同Agent中有不同的含義
2. 2.信息不對稱：Agent A知道的信息Agent B不知道
3. 3.決策沖突：Agent A想做X，Agent B想做Y，但兩者無法同時滿足

1. 1.統一術語和格式定義
2. 2.設計清晰的消息協議（比如用JSON schema定義消息格式）
3. 3.引入沖突解決機制（比如投票、協商、優先級）

Multi-Agent系統的調試比單Agent難一個數量級。

你需要能夠：

1. 1.追蹤每個Agent的決策過程
2. 2.記錄Agent之間的所有通信
3. 3.可視化整個調用鏈
4. 4.快速定位問題Agent

很多團隊會在系統中嵌入詳細的日志和追蹤機制，甚至專門開發調試工具。

這也是為什么很多企業最終還是選擇現成的Multi-Agent框架，而不是自己從頭搭建。這些框架通常已經提供了完善的監控和調試能力。

考慮Human-in-the-Loop

Multi-Agent系統的一個風險是"失控"。Agent之間的協作可能陷入死循環，或者朝著錯誤的方向越走越遠。

引入Human-in-the-Loop機制，讓人類在關鍵節點介入審核和決策，可以很大程度上降低這個風險。

比如：

1. 1.主Agent在調用某個子Agent前，先向人類確認
2. 2.子Agent返回結果后，主Agent在整合前讓人類審核
3. 3.設置最大迭代次數，超過后自動停止并通知人類

就像前文提到那個金融團隊，他們最終選擇的是Sub-Agents模式。主Agent負責意圖識別、任務分解、結果整合，三個子Agent分別負責數據查詢、財務分析、策略建議。

上線后的效果還不錯。響應時間比之前的多Agent方案降低了60%，token消耗減少了40%，而且因為職責清晰，團隊協作也順暢了很多。

但他們也很清楚，這個選擇不一定適合所有場景。

如果你的應用是單次查詢為主、領域切換頻繁，Skills可能更合適。如果你的應用是嚴格順序的工作流，Handoffs可能更簡單。如果你的應用需要大規模并行處理，Router可能更高效。

沒有最好的架構，只有"最合適"的架構。

關鍵在于，你得先搞清楚自己的需求是什么。

參考資料：

• LangChain: Choosing the right multi-agent architecture https://blog.langchain.dev/choosing-the-right-multi-agent-architecture/

• Google Cloud: Where to use sub-agents versus agents as tools https://cloud.google.com/blog/topics/developers-practitioners/where-to-use-sub-agents-versus-agents-as-tools

• Anthropic: Multi-Agent Systems https://docs.anthropic.com/en/docs/build-with-claude/multi-agent-systems

• IBM: What is a multi-agent system?

  https://www.ibm.com/think/topics/multiagent-system

關注公眾號, 用極客視角洞察未來!