想系統性學習如何開發 LLM、RAG 和 Agents 應用嗎? 歡迎購買我的課程 大語言模型 LLM 應用開發工作坊
(來一次講三篇 multi-agents 架構文章 + PoC 實作經驗分享)
近期有兩家知名 AI 公司幾乎同時發表了關於 multi-agent 系統的文章，但觀點乍看之下完全相反:
- Anthropic 說 “How we built our multi-agent research system” 我們如何建構多代理人研究系統
- Cognition 說 “Don’t Build Multi-Agents” 不要蓋多代理人系統
兩方論點整理
Anthropic 的見解: Multi-agent 有其必要性
- Single-agent 在複雜任務上必然會撞到 context window 限制
- 某些研究任務天生就適合平行處理，像是「找出 S&P 500 科技股的所有董事會成員」
- 他們的內部評測顯示，multi-agent 系統比 single-agent Claude Opus 4 效能提升了 90.2%
- 關鍵在於: token 使用量解釋了 80% 的效能差異，multi-agent 能有效擴展 token 預算
Cognition 的見解: Context 共享才是王道
- Multi-agent 最大問題是 context 無法有效共享，導致子代理人做出衝突決策
- 而大多數現實世界的任務都有許多層次的細微差別，這些 context 細節差異都有可能被 multi-agent 誤解
- 就像兩個工程師各自寫程式但沒溝通，結果 merge 時衝突一堆
- 現階段的 LLM 還不夠聰明去做多 Agents 的有效協作
- 建議用 single workflow 架構搭配 context compression 技術，確保 context 連貫性
心得: 什麼時候適合用 Multi-agent？
這其實非常像「一人公司 vs. 多人團隊」工作效率問題: 一人公司(Single-agent): 效率最高，沒有溝通成本，但有體力和時間上限。多人團隊(Multi-agent): 可以 scale 更大問題，但需付出高昂協作成本，容易出現資訊不對稱。
Anthropic 這篇的實作文章給我許多 Multi-agents 實作的啟發，首先是什麼時候適合用 Multi-agents? 並不是所有問題都適合。適合的條件有: 1. 任務天生就可以平行拆分，例如收集多個來源資料 2. 需要處理的資訊量超過單一 context window 限制 3. 價值要夠高，付得起筆一般對話高達 15 倍的 token 成本
另一篇 LangChain 的 Multi-Agent 實驗
剛好 LangChain 近期也有一篇 Benchmarking Multi-Agent Architectures 一針對不同架構進行實驗，對比了三種常見形式：
- Single Agent: 單一 Agent 擁有所有工具與指令集，直接處理任務
- Multi-Agent (Supervisor): 主 Agent 負責接收任務並將子任務分派給不同 Sub Agent，再彙整結果
- Multi-Agent (Handoff): 所有 Agent 對等，彼此可互相 handoff 任務，當下只有一位 Agent 活躍
實驗在 Tau-bench 任務集上進行延伸，加入 6 個額外干擾的任務 prompt 與工具 tools，模擬真實複雜場景下的代理人行為。結果顯示:
- 單一任務 + 工具少時，Single Agent 表現最佳，執行路徑簡單、不需額外協調。
- 任務多元 + 工具繁雜時， Multi-Agent (Handoff) 架構略勝一籌，因為可直接回應使用者。Multi-Agent (Supervisor) 架構需要透過 Lead Agent 在轉回給用戶，表現次佳。
重點是，在干擾增多的情況下，Single Agent 的效能快速下滑，反映其對雜亂的 context 抵抗力較弱；反之，Handoff 與 Supervisor 的 Multi-Agent 架構在 context 複雜度提高時仍維持穩定效能。這篇研究其實加強了 Anthropic 的主張: 在資訊量很高的任務中，Multi-Agent 架構確實能更穩定地 scale 出效能。
Anthropic 的場景是搜尋資料很多，而 LangChain 測試的場景是任務很多元，這是差異，但共通點是 AI 要處理的資料量很多，所以才需要用到 multi-agents 架構。
心得: Mutli-agents 的 prompt 怎麼寫?
另一個我在 Anthropic 文章學到的是 Mutli-agents 的 prompt 的實作細節，例如:
- 要詳細教 Lead Agent 拆解任務、明確劃定邊界
- 根據任務複雜度分配 agent 數量與工具呼叫次數，例如: 簡單任務 1 agent + 3~10 次工具，複雜任務則 10+ agent 平行操作
- 給予明確工具使用規則，降低誤用率
- 搜尋策略採「先廣後深」：先用短查詢探索，再聚焦深入
我的 PoC 實作經驗
Anthropic 只有公開 prompt 沒有程式碼，要體會 multi-agents 架構要練習實作跑跑看，才能知道到底他是怎麼運作的。我用 OpenAI o3 + GPT-4.1 用 OpenAI Agents SDK 臨摹了 Anthropic 的這個 multi-agents researcher 系統，Code 在這裡，有稍微調整過 prompt 來配合 OpenAI Agents SDK 框架。我的版本跑一次可達 10 分鐘，呼叫工具 69 次，花費約 USD 1.5。
做出 PoC 可以跑其實不難，難在細節打磨啊。難點還有:
- 評估機制: 需搭配 LLM-as-judge，從事實正確性、引用品質、工具效率等面向評分，仍需人工測試輔助
- 檢索工具品質: 設計良好的 web search/fetch 工具與描述，避免 agent 走錯路
- 狀態管理與容錯: 長時間任務 (>10 分鐘)、多 agent 並行情境中若遇錯誤或中斷，要能容錯與重試
- 需要 production tracing 工具來追蹤 agent 行為與失敗原因
最後結論
建議預設還是先用 Single-agent + context compression 設計，特定適合場景(例如適合拆任務平行處理、或是任務很多元) 才用 Multi-agent 來 Scale 更大規模。相信之後隨著模型變聰明，發明出更好的 Agent 協作系統，Multl-agents 架構想必也會越來越可靠。
One more thing: 如果是自用，推薦用 Claude Code 也可以做出 multi-agent 的 researcher 流程，而且是用 Claude Max Plan 固定月費，不吃 API tokens 這會超貴，性價比超高。詳情可以參考我的 Claude Code 筆記。
想學 mutli-agents 架構嗎? 也歡迎參考我的課程，各種架構都有教你怎麼做。