跳到主要內容
Foxyko
AI Agent

多代理系統是什麼？Multi-Agent AI 的運作方式、適用時機與成本

多代理系統（multi-agent）是讓多個 AI agent 分工合作。這篇說明 orchestrator-worker 運作方式、何時值得用、為何更耗 token，以及常見失敗與避免方法。

Foxyko5 分鐘

簡短回答：多代理系統（multi-agent system）是讓多個 AI agent 分工合作完成任務：通常由一個主導 agent 拆解問題，交給多個子 agent 平行處理，再整合結果。它適合可平行拆分的高價值任務，但 token 用量大幅增加，簡單任務用單一 agent 就夠。

本文重點

  • 多代理最常見的做法是 orchestrator-worker：主導者拆解任務，子 agent 平行執行，最後整合。
  • Anthropic 在自家研究評測中，多代理版本比單一 agent 高出 90.2%，但 token 用量約為一般對話的 15 倍。
  • 適合廣度優先、可平行、資訊量超出單一上下文的任務；步驟互相依賴的任務（如多數程式開發）較不適合。
  • 先用最簡單的做法，證明有效才增加複雜度。

多代理系統是什麼？

多代理系統是由多個各自有指示、工具與獨立上下文的 AI agent，一起完成同一個目標。以 Anthropic 的研究功能為例，主導 agent 先規劃，再派出子 agent 平行搜尋，每個子 agent 使用自己的 context window；結果回到主導 agent 整合，最後由專門的引用 agent 補上來源。

如果你還不熟悉單一 agent 的概念，可以先讀AI Agent 是什麼，再回來看分工的部分。

多代理系統、單一 agent 與 workflow 有什麼差別？

Anthropic 的區分是：workflow 沿著預先寫好的程式路徑走，agent 則由模型自己決定流程與工具，多代理是多個 agent 協作。越往右，彈性越高，延遲與成本也越高，Anthropic 也提醒自主性可能讓錯誤累積。

做法誰決定流程適合的情況代價
單次模型呼叫（加檢索與範例）你多數簡單任務最低，Anthropic 建議優先考慮
Workflow預先寫好的程式路徑步驟固定、可預測的任務較低，行為容易追蹤
單一 agent模型自己決定步驟無法事先確定延遲與成本上升，錯誤可能累積
多代理系統主導 agent 分派給子 agent可平行、超出單一上下文的高價值任務最高，約為對話 token 的 15 倍

orchestrator-worker 模式要怎麼運作？

orchestrator-worker 是由一個中央 agent 拆解任務、交給多個執行者，再整合結果的模式。Anthropic 說它適合「子任務無法事先預測」的工作，例如同時改動多個檔案，或跨多個來源搜尋資料。流程可以拆成四步：

  1. 主導者分析問題並制定計畫

    主導 agent 讀取使用者的問題，判斷需要哪些方向，並依問題複雜度決定要派出多少子 agent。

  2. 為每個子 agent 寫清楚的簡報

    簡報要包含目標、輸出格式、可用的工具與來源，以及邊界。Anthropic 發現簡報太模糊，子 agent 會重複工作或留下空缺。

  3. 子 agent 平行執行

    每個子 agent 在自己的上下文裡搜尋或處理資料，各自回報結果。這是多代理能處理超過單一上下文資訊量的原因。

  4. 主導者整合並查核

    主導 agent 彙整所有回報，決定是否還需要補查；Anthropic 的做法是另外用一個引用 agent，替結論補上來源。

什麼時候適合用多代理系統？

當任務價值夠高、又能拆成可平行的部分時，多代理才值得。判斷時可以先看任務本身，再看成本。

適合的情況

  • 需要廣度優先、同時查很多方向的研究型任務。
  • 資訊量超出單一上下文能容納的範圍。
  • 需要接很多複雜工具，分工後各自專精。

不適合的情況

  • 所有 agent 都需要共用同一份脈絡的任務。
  • 步驟之間依賴很多的任務；Anthropic 指出多數程式開發可平行的部分比研究少。
  • 需要即時協調的任務；Anthropic 說目前 agent 在即時協調上還不夠好。

為什麼多代理系統比較花 token？

因為每個子 agent 都要各自讀資料、呼叫工具、回報結果。Anthropic 估計一般 agent 約使用對話 4 倍的 token，多代理系統約 15 倍；在其 BrowseComp 評測中，光是 token 用量就解釋了 80% 的表現差異。多代理也確實更強：其內部研究評測裡，多代理組合比單一 agent 高出 90.2%。

多代理系統常見會出什麼問題？

Anthropic 在實際使用中看到的問題集中在分工與判斷。常見狀況如下，每一項後面是對應的做法：

  • 簡單問題派出太多子 agent。例子是為一個小問題啟動 50 個子 agent。做法：在提示詞寫明規則，依問題複雜度決定投入多少；簡單查證用 1 個 agent、3 到 10 次工具呼叫即可。
  • 簡報模糊，導致重複或遺漏。做法：每個子 agent 的簡報都寫清楚目標、輸出格式、工具與邊界。
  • 選錯工具或來源。agent 可能偏好 SEO 內容農場而非權威來源。做法：把工具說明寫得明確且不重疊，Anthropic 提到重寫工具描述讓任務時間縮短 40%。
  • 無止境地搜尋不存在的資料，或編造答案。做法：設定停止條件、要求附來源，並對重要結論人工查核，參考怎麼查證 AI 的回答。

在可靠性上，Anthropic 建議支援從中斷點續跑、加入重試，並用最終結果而不是每一步來評估；一開始約 20 個真實查詢就足夠看出趨勢。它也承認目前子 agent 同步執行會形成瓶頸。

OpenAI Agents SDK 與 Google ADK 怎麼做多代理？

兩家的文件都把多代理視為「專門化分工」，只是協調方式不同。OpenAI 的文件說明可以由模型來決定編排，也可以由程式碼決定，後者在速度、成本與表現上更可預期；它也建議用專門的 agent，而不是一個什麼都做的 agent。

OpenAI 文件另外區分兩種分派方式：當管理者應該保有對話並負責最後回答時，用 agents-as-tools；當專家應該接手本輪剩下的對話時，用 handoffs，兩者可以並用。Google 的 ADK 文件則指出，單一龐大 agent 在應用變大後難以開發、評估與維護，並列出圖狀、動態、協作（協調者加子 agent）與範本式（循序、迴圈、平行）幾種工作流程；其中部分模式需要 ADK 2.0 以上，agent 路由仍屬實驗性質。

給子 agent 的任務簡報要怎麼寫？

簡報要讓一個沒有任何背景的人也能照做。以下範本整理自 Anthropic 建議的四個要素：目標、輸出格式、工具與來源指引、邊界。

子 agent 任務簡報範本
目標：［這個子 agent 要回答的單一問題］
輸出格式：［例如：5 個重點，每點附來源網址與一句原文依據］
工具與來源：只使用［工具名稱］；優先官方文件與原始報告，不採用內容農場。
邊界：只處理［範圍］，其他方向由別的子 agent 負責；最多進行［N］次搜尋；找不到就明說找不到，不要推測。

什麼時候不該用多代理系統，替代方案是什麼？

如果任務簡單、步驟固定，或成本比價值更敏感，就不需要多代理。Anthropic 的建議是先採用最簡單的方案，只在能證明改善時才增加複雜度，且常常用單次模型呼叫加檢索與範例就已足夠。框架可以加快起步，但多出的抽象層可能讓提示詞與除錯變得不透明，建議先從直接呼叫 API 開始，理解框架程式碼後再採用。

相關文章

資料來源

常見問題

多代理系統一定比單一 agent 好嗎？
不一定。Anthropic 在自家研究評測中看到多代理明顯較強，但也說明它只適合高價值、可平行拆分的任務。步驟互相依賴或需要共用脈絡的工作，單一 agent 通常更穩、更省。
orchestrator-worker 是什麼意思？
這是一種分工模式：中央的主導者（orchestrator）把任務拆成子任務，交給多個執行者（worker）處理，再把結果整合。適合子任務無法事先決定的工作，例如跨多個來源的研究或多檔案程式修改。
多代理系統為什麼比較花 token？
每個子 agent 都有自己的上下文，要各自讀取資料、呼叫工具並回報結果。Anthropic 估計一般 agent 約用掉對話 4 倍的 token，多代理系統約 15 倍，所以任務價值要夠高才划算。
workflow 和 agent 差在哪？
依 Anthropic 的定義，workflow 沿著預先寫好的程式路徑執行，流程固定可預測；agent 則由模型自己決定流程與工具使用，彈性較高，但延遲、成本與錯誤累積的風險也較高。
想嘗試多代理，應該從哪裡開始？
先從最簡單的做法開始：單次模型呼叫加上檢索與範例。不夠用再改成固定流程的 workflow，確認真的需要動態分工，才試多代理。每加一層複雜度，都要有可衡量的改善。
主題標籤AI Agent多代理系統Multi-Agentorchestrator-worker

延伸閱讀