跳轉到

Multi-Agent 協作：Orchestration 模式、通訊協定與失敗隔離

整理自廠商文件與技術分析（見文末），2026-06-20。當單一 agent 的 context、工具、職責塞不下時，會拆成多個 agent 協作。本頁講有哪些編排模式、它們各自的單點故障、agent 怎麼通訊、以及失敗最常發生在哪。

實證標記：〔廠商〕= 出自框架供應商文件；〔分析〕= 出自業界技術分析；〔實務〕= 業界慣例或本人整理。預設 under-claim。

先問：真的需要多 agent 嗎？

多 agent 不是越多越好——它放大除錯難度、延遲與成本。先確認單 agent 真的不行（context 爆、職責互斥、需要並行）再拆。能用「一個 agent + 好的工具」解決，就別開多 agent。〔實務〕

主要編排模式

模式 結構 取捨
Supervisor（主管） 中央協調者依執行狀態動態指派 worker 直覺、好控；但主管是單點故障與延遲下限
Sequential Pipeline（管線） agent 分階段接力處理 簡單可預測；不適合需要回頭/分支的任務
Peer-to-Peer Mesh（網狀） agent 經訊息匯流排直接互通 靈活；協調與除錯複雜
Event-Driven（事件驅動） agent 對事件流反應 解耦、可擴展；流程不易一眼看懂
Swarm（蜂群） 無中央協調，靠局部互動/handoff 輕量好架；沒有單一 agent 有全局視野，handoff 出錯極難除錯

〔分析〕兩個極端的代價要記住：Supervisor 把風險集中在中央（掛了全停、所有流量過它）；Swarm 把風險分散但失去全局可見性（沒人知道整體走到哪）。多數生產系統落在中間：確定性的工作流引擎 + 少數 LLM 決策點，而不是讓 agent 全自由互推。

通訊：Handoff 是核心抽象

agent 之間最常見的協作原語是 handoff（交接）：一個 agent 顯式地把控制權轉給另一個，並帶著對話脈絡過去。〔廠商〕

主流框架（OpenAI Agents SDK、Google ADK、Anthropic Agent SDK）大多圍繞三件事：〔廠商〕 - Handoffs：agent 對 agent 的控制轉移。 - Guardrails：輸入/輸出驗證（在交接邊界把關）。 - Tracing：對整條 agent 鏈做端到端觀測（見 Agent Observability）。

〔廠商〕跨框架/跨廠商的通訊正在標準化：Google ADK 預設多 agent，用 A2A（Agent-to-Agent）協定跨 agent 溝通，能把 Google 的 worker 接到 Anthropic、自寫 Python、第三方 SaaS 的 agent。協定層的互通是 2025–26 的重點演進。

失敗最常發生在「交接」，不是 agent 內部

這是 multi-agent 最重要、也最反直覺的一點：〔分析〕

〔分析〕多數失敗發生在 agent 的 handoff，而非 agent 內部。 最典型的是無限交接迴圈：兩個 peer 互相不同意、把任務推來推去，沒有硬性回合上限就一直跑到告警才停。

對策是機械式的，不要靠模型「自己想通」：〔分析〕〔實務〕 1. 數 handoff、設硬上限（業界常見用 ~12 作通用天花板），超過就停。 2. 加第三方仲裁者（arbiter） 打破僵局。 3. 超限時回傳 best-so-far + 降級信心旗標，而不是無限重試或直接報錯。 4. 每個 agent 隔離在自己的容器，限制單一 agent 失控的爆炸半徑。 5. 高風險動作 human-in-the-loop（見 AI Agent 安全與權限）。

落地建議〔實務〕

  1. 先證明單 agent 不行再拆多 agent。
  2. 預設 Supervisor 或 Pipeline（好除錯）；只有在真的需要去中心化彈性時才上 Mesh/Swarm。
  3. 把編排骨架做成確定性工作流，LLM 只在「決策點」介入——別讓整個流程都靠模型即興。
  4. 每個 handoff 都要驗證 + 限次 + 可追蹤：guardrail 把關、handoff 計數上限、trace 端到端。
  5. 獨立子任務才並行（context 隔離、無共享狀態），呼應 Claude Code 的 subagent 紀律（見 紀律框架對比）。

延伸閱讀（本站）

來源