看到 LangChain 的 Sydney Runkle 寫了這篇 Choosing the Right Multi-Agent Architecture，把 multi-agent 架構整理得蠻清楚的，值得一讀。

先講結論: 很多時候你根本不需要 multi-agent。單一 agent 配好工具就夠了。只有碰到兩種情況才值得考慮 multi-agent:

  1. Context 塞不下: 每個功能要的專業知識太多，一個 prompt 裝不完
  2. 團隊分工: 不同團隊各自維護不同能力，一個巨大 prompt 跨團隊管理會崩潰

文中也引用了 Anthropic 的研究佐證 — 他們的 multi-agent 研究系統 (Claude Opus 4 當主管 + Claude Sonnet 4 當子代理) 在內部評估比單一 Claude Opus 4 好了 90.2%。關鍵就是把工作分散到各自獨立的 context window，實現平行推理。

以下是文中整理的四種架構模式:

1. Subagents (集中式調度)

主 agent 把子 agent 當 tool 來呼叫。子 agent 無狀態，做完就回報。

適合多個不同領域要集中控制的場景，例如一個助手同時管行事曆、Email、CRM。好處是 context 隔離乾淨、可以平行跑。代價是每次互動多一趟 model call，因為結果要回到主 agent 彙整。

2. Skills (漸進式揭露)

單一 agent 按需載入專業 prompt 跟知識，技術上是單 agent，但行為類似 multi-agent。

適合一個 agent 有很多種可能專長的情況。最簡單，用戶始終跟同一個 agent 互動。缺點是 context 會在對話歷史中一直累積，token 越用越多。

3. Handoffs (狀態驅動轉移)

活躍的 agent 根據對話 context 動態切換，每個 agent 可以透過 tool call 轉移給其他 agent。

適合客服流程、需要依序蒐集資訊的多階段對話。context 在多輪對話中自然傳遞，但狀態管理比較複雜。OpenAI Agents SDK 的 handoff 機制就是這個模式。

4. Router (平行分派與綜合)

路由層分類輸入，分派給專業 agent 平行處理，最後綜合結果。

適合不同垂直領域的知識庫、需要同時查多個來源的場景。無狀態設計所以效能穩定，但重複對話要重新路由。

怎麼選?

需求 推薦架構
多個不同領域，需要平行執行 Subagents
單一 agent 多種專長，輕量組合 Skills
有順序的工作流程，agent 全程對話 Handoffs
不同垂直領域，平行查詢綜合結果 Router

效能比較

文章用三個場景做了分析，蠻有意思的:

單次請求: Skills、Handoffs、Router 各 3 次 model call; Subagents 要 4 次 (多一趟回主 agent)

重複請求: 有狀態的 Skills 和 Handoffs 在第二輪省 40% call; Subagents 維持固定成本

多領域查詢: 這個最有趣 — Subagents 和 Router 因為平行執行加 context 隔離最有效率。Skills 的 call 少但 token 爆多 (context 累積)。Subagents 比 Skills 少用了 67% 的 token。Handoffs 必須依序處理，最慢。

架構 單次請求 重複請求 平行執行 大 context
Subagents — — ✅ ✅
Skills ✅ ✅ — —
Handoffs ✅ ✅ — —
Router ✅ — ✅ ✅

蠻實用的整理。其實做 agent 最常犯的錯就是一上來就搞 multi-agent，結果複雜度爆表又沒比較好。文章最後的建議我很認同:

Start with a single agent and good prompt engineering. Add tools before adding agents.

先把單一 agent 做好，先加工具不要急著加 agent。等真的碰到明確的限制再升級，這才是務實的工程思維啊。

📎 原文: Choosing the Right Multi-Agent Architecture