多代理架構：盲目拆分只會適得其反

「把我的代理拆成多個代理，是不是就會變得更聰明？」

答案是「看情況」。Anthropic 的研究指出，多代理系統的效能可以比單一代理高出 90% - 但前提是你選對了架構。實務上，不同任務類型之間的效能差距可以非常懸殊。

以下用三個具代表性的場景，拆解每種模式真正能發揮效果的時機。

四種架構模式一覽

先快速認識這四種架構：

• 子代理（Subagents）：主代理將專業任務交派給子代理執行。平行處理能力強，但所有結果都必須回傳給主代理彙整
• 技能（Skills）：單一代理根據需求動態載入專業提示詞。運作輕量，但上下文會隨時間不斷累積
• 交接（Handoffs）：每個階段由不同的代理接手執行。專為循序工作流設計，但無法平行處理
• 路由器（Router）：負責分類查詢、平行分派、彙整結果。無狀態設計 - 不保留對話上下文

接下來看看這些模式在實際場景中的表現。

場景一：一次性請求

想像使用者說「幫我買杯咖啡」 - 一個可以直接呼叫 buy_coffee 工具的簡單請求。

效能比較：

• 子代理：4 次呼叫（主代理 → 子代理 → 工具執行 → 回傳主代理 → 回覆）
• 技能 / 交接 / 路由器：3 次呼叫（直接執行）

重點觀察： 一次性任務不需要狀態管理，技能、交接和路由器都是最有效率的選擇。子代理多了一趟回傳主代理的來回，直接反映在延遲上。對於簡單任務，根本沒必要動用多代理架構。

實務應用： FAQ 機器人、簡單指令執行、單次資料查詢，用單一代理就綽綽有餘。在這種場景用多代理，就是過度工程。

場景二：重複性請求

使用者接著說「再幫我買一杯咖啡」 - 同樣的請求執行兩次，對話上下文延續。

效能比較（第二輪）：

• 子代理：4 次呼叫 → 累計 8 次（無狀態，每次都跑完整流程）
• 技能 / 交接：2 次呼叫 → 累計 5 次（減少 40%）
• 路由器：3 次呼叫 → 累計 6 次（減少 25%）

重點觀察： 有狀態的模式在這裡明顯勝出。技能和交接可以重用已載入的上下文，完全跳過路由和初始化步驟。子代理因為設計上就是無狀態的，每次都得從頭來過。不過子代理的優勢在於更好的上下文隔離 - 如果安全性或沙箱環境是優先考量，這筆額外成本是值得的。

實務應用： 聊天機器人、對話式助理、基於工作階段的服務，都需要有狀態的模式。如果使用者經常說「跟上次一樣就好」，優先選擇技能或交接。路由器在需要時也可以包裝在有狀態的代理裡當工具使用。

場景三：跨領域查詢

使用者問「比較 Python、JavaScript 和 Rust」 - 一個橫跨多個專業領域的查詢。假設每種語言大約需要 2K tokens 的參考文件。

效能比較：

• 子代理：5 次呼叫，約 9K tokens（每個子代理在隔離的上下文中運作）
• 技能：3 次呼叫，約 15K tokens（三個技能的上下文全部堆疊在主代理中）
• 交接：7 次以上呼叫，約 14K+ tokens（只能循序執行）
• 路由器：5 次呼叫，約 9K tokens（平行執行）

重點觀察： 支援平行執行的模式 - 子代理和路由器 - 在這裡完勝。子代理在隔離的上下文中分別處理每種語言的文件，token 用量比技能少了 67%（9K 對 15K）。技能雖然呼叫次數較少，但把三個領域的知識全部塞進主代理的上下文中，導致 token 成本暴增。交接因為只能循序執行，是這類任務最糟糕的選擇。

實務應用： 研究系統、多來源比較分析、需要同時查詢多個獨立領域的企業知識庫，都適合用子代理或路由器。當處理大量領域專屬知識時，上下文隔離直接影響 token 成本。

模式選擇指南

場景	建議模式
一次性任務	單一代理就夠了
頻繁的重複請求	技能或交接
同時查詢多個領域	子代理或路由器
循序工作流	交接

最後一個實戰建議

不要一開始就跳進多代理架構。先從單一代理搭配好的提示詞和明確定義的工具開始。只有在遇到明確的瓶頸時，再考慮多代理方案 - 然後用上面的場景分析來選擇正確的模式。

Anthropic 研究的核心結論不是「代理越多越好」，而是針對正確的任務選擇正確的架構，才能帶來那 90% 的效能提升。