Multi-Agent（多代理系統）是讓多個具有不同指令、工具、權限或上下文的 AI Agent 協作完成一項任務。它適合能拆成獨立方向的複雜研究、多領域客服與需要權限隔離的工作流。任務只有一條線、步驟固定或一個 Agent 加工具就能完成時，使用 Multi-Agent 往往只會增加費用、延遲和除錯難度。
代理數量本身不代表能力。只有拆開後能得到可量化的品質、速度或治理收益，才值得採用 Multi-Agent。Microsoft Agent Framework 的官方建議很直接：能用函式完成就用函式；流程步驟明確時用 workflow；只有開放式規劃和自主工具使用才交給 Agent。
Multi-Agent、Subagent、工具有什麼差別？
一個 Agent 呼叫搜尋、資料庫和寄信工具，仍可視為單一 Agent。當它把任務交給另一個有獨立指令與執行迴圈的代理，才進入 Subagent 或 Multi-Agent 編排。
Subagent 通常不直接面對使用者，而是接收範圍明確的子任務，回傳結果給主代理。Handoff 則把目前控制權交給另一個代理，後者可以直接接手對話。兩者最大的差異，是誰保留最終回覆與流程控制權。
先確認三個問題：子任務是否真的需要不同指令或工具？是否能用結構化輸入輸出隔離？多一個代理後，成功率提升是否足以抵銷成本與失敗點？只因 Prompt 很長就拆 Agent，通常無法解決不清楚的任務定義。
4 種 Multi-Agent 編排模式怎麼選？
| 模式 | 誰控制流程 | 適合情境 | 主要風險 |
|---|---|---|---|
| Router／程式路由 | 程式或分類器 | 類別有限、規則明確的客服與文件分流 | 分類錯誤會送到錯的代理 |
| Manager／Subagents | 主代理 | 多個專家提供材料，由一處合成最終答案 | 主代理可能漏用或扭曲子結果 |
| Handoff | 接手的專業代理 | 專家要直接和使用者持續對話 | 對話與 guardrail 在交接處失真 |
| Concurrent | 程式或主代理 | 多個互不依賴的搜尋、分析或審查 | 成本同時放大、結果衝突 |
Router／程式路由最適合第一版。先用一個結構化分類步驟輸出 billing、refund、technical，程式再呼叫對應代理。路徑、延遲與成本容易預測，也能在信心不足時直接轉人工。
Manager／Subagents由主代理保留使用者對話，將研究、資料分析或法規檢查包成工具型代理，再合成一個答案。OpenAI Agents SDK 稱為 agents as tools，LangChain 則常稱 supervisor／subagents。每個子代理應收到最小必要背景，回傳固定格式和證據，不要把完整主對話全部複製過去。
Handoff適合專家需要接手後續互動。例如客服 Triage Agent 判斷是退款問題後，轉交 Refund Agent；專家收到必要歷史並直接回應。交接資料應有 schema、理由、使用者已確認事項與禁止操作。OpenAI Agents SDK 也提供 input filter，讓下一個代理不必接收全部工具紀錄。
Concurrent把獨立子任務平行執行，例如分別查產品、法規、競品，再由主代理合成。它只有在任務沒有相互依賴、I/O 等待明顯時才會加速。後一個步驟需要前一個結果的流程，硬做平行只會產生重工。
何時該用 Multi-Agent？
值得做原型的訊號有四個：問題需要探索多個獨立方向；單一上下文塞入所有資料後品質下降；不同子任務必須使用不同權限或資料來源；同一批輸入能用明確 Eval 證明多代理優於基準版。
不建議使用的情況也很清楚：任務可用一個 API 呼叫或固定程式完成；每一步高度依賴前一步；所有代理都需要同一份完整上下文；沒有追蹤、成本上限和人工接管；只是想用多個角色互相辯論，卻沒有成功標準。
Anthropic 的 Research 是適合 Multi-Agent 的代表案例。研究問題可拆成多個搜尋方向，Subagents 各自使用乾淨上下文平行探索，再把壓縮後的材料交回 Lead Agent。Anthropic 的內部評測顯示，這套特定研究系統相對單代理有顯著改善；同一篇工程文章也指出，多代理約用了普通聊天 15 倍 Token。這個數據只能說明「高價值、可平行研究」的取捨，不能套用成每個系統的固定成本。
成本、Context 與失敗怎麼控制？
先用單 Agent 或固定 workflow 跑同一組測試，記錄正確率、完成時間、Token、工具費與人工重做比例。多代理成本至少包含：
總成本 = 路由／規劃
+ 所有代理的輸入與輸出
+ 工具、搜尋與程式執行
+ 重試與失敗分支
+ 最後合成與驗證每個子代理都要有輸入合約：任務、可用資料、允許工具、禁止操作、輸出 schema、截止條件與預算。回傳長篇自由文字會讓主代理重新讀大量內容；研究型任務可回傳 claim、evidence_url、quote_location、confidence、open_questions 等固定欄位。
Context 隔離仍需保留任務必要資訊。退款代理需要訂單 ID、政策版本和使用者已同意的處理方式，卻不需要整段行銷對話或其他客戶資料。Handoff 時應傳摘要與結構化狀態，並保留原始 artifact 的引用位置，避免多次摘要造成內容失真。
限制 max_turns、代理數、平行數、每個工具呼叫次數與整體金額。相同查詢重試前要有新資訊或明確錯誤，不能讓代理在相同路徑無限循環。涉及退款、刪除、寄信、權限變更和外部發布時，工具層應要求人工批准；只在最終答案做 guardrail 還不夠。
上線前怎麼做 Eval？
建立三個基準：固定程式或單次模型、單 Agent 加工具、Multi-Agent。用相同的 20–50 筆真實但去識別案例，比較任務成功率、事實與引用正確率、P50／P95 延遲、平均與最差成本、轉人工比例，以及外部副作用是否正確。
多代理不能只看最終答案。Trace 還要能回答：為什麼路由到這個代理、傳了哪些資料、用了哪些工具、哪次交接改變了狀態、花了多少 Token、誰核准外部操作。OpenAI Agents SDK、Microsoft Agent Framework 與 LangChain 都提供不同程度的 tracing 或 workflow primitives；框架選擇應跟你的語言、部署和觀測系統相容。
正式發布先限制在低風險、低流量路徑。每次只增加一個專業代理，證明它改善既有失敗案例後再擴張。完整的測試方法可看 LLM 評測流程；單 Agent 的基本設計先讀 AI Agent 設計模式，部署與監控則接著看 AI Agent 正式環境指南。需要自行串工具時，再看 MCP Agent 實作。
FAQ
Multi-Agent 一定比單 Agent 準嗎？
不一定。可平行探索且需要多種專業上下文的任務可能改善；步驟高度依賴、輸入簡單或缺少交接合約時，錯誤反而會累積。應以同一組 Eval 比較。
Subagent 和 Handoff 差在哪？
Subagent 通常像工具，完成範圍明確的工作後回傳主代理，由主代理合成答案。Handoff 會轉移對話控制權，接手的專業代理直接處理後續互動。
Multi-Agent 會省時間嗎？
只有獨立且可平行的工作可能縮短等待時間。序列依賴、共享資源、合成與重試仍會增加延遲；要同時比較 P50、P95 和最差情況，不能只看一次成功展示。
Multi-Agent 會多花多少 Token？
沒有通用倍率。Anthropic 曾報告其特定研究系統約使用普通聊天 15 倍 Token，但代理數、上下文、工具、重試和合成方式都會改變結果。請從自己的單 Agent 基準實測。
第一個 Multi-Agent 專案該選哪種模式？
先選 Router 或 Manager／Subagents，讓流程有單一控制點、輸入輸出可結構化。只有專業代理需要直接接手使用者對話時，才加入 Handoff。
參考來源
- OpenAI Agents SDK：Agent orchestration（2026-08-12 查閱）
- OpenAI Agents SDK：Handoffs（2026-08-12 查閱）
- Anthropic Engineering：How we built our multi-agent research system（2025-06-13）
- Anthropic Engineering：Effective context engineering for AI agents（2025-09-29）
- Microsoft Learn：Workflow orchestrations in Agent Framework（2026-03-31）
- LangChain Docs：Subagents（2026-08-12 查閱）