多代理架構：亂拆只會適得其反

「將我個代理拆成幾個，係咪會變聰明啲？」呢個問題我最近收到好多次。答案係：視乎情況。

Anthropic 嘅研究數據顯示，多代理架構可以喺表現上贏過單代理高達 90% - 但前提係你揀咗啱嘅架構模式。如果唔理三七廿一就拆，唔單止冇提升，反而會引入額外嘅延遲、token 消耗同協調成本。

呢篇文章會拆解四種主流嘅多代理模式，用實際場景比較佢哋嘅優劣，幫你判斷幾時應該拆、幾時應該留。

四大架構模式

子代理模式（Subagents）

主代理將專業任務分派俾子代理，每個子代理就好似一個工具噉俾主代理呼叫。

• 天然支持並行執行 - 幾個子代理可以同時跑
• 所有通訊都要經過主代理路由，主代理係唯一嘅協調者
• 適合需要同時處理多個獨立領域嘅場景

好處係分工清晰，壞處係主代理變成瓶頸 - 所有結果都要匯報返去佢度做彙整。

技能模式（Skills）

單一代理按需載入專業提示詞同能力包。代理本身唔變，但佢嘅行為會根據載入嘅技能動態調整。

• 架構最輕量，唔使管理多個代理實例
• 上下文會累積 - 每一次互動嘅記憶都保留喺同一個上下文入面
• 特別適合需要跨步驟共享狀態嘅重複性任務

技能模式嘅優勢在於簡單同低開銷。但當上下文累積到某個程度，效能就會開始下降。

交接模式（Handoffs）

活躍代理喺每個階段完成之後，將控制權交俾下一個代理。好似接力賽 - 棒交出去就收唔返。

• 嚴格順序執行，冇辦法並行
• 每個代理專注處理流程中嘅一個環節
• 上下文喺交接時傳遞，但每個代理只睇到佢需要嘅部分

適用於有明確階段劃分嘅流水線式工作流，例如：分析 → 規劃 → 實現 → 審查。

路由模式（Router）

一個分類器喺最前面，根據請求類型將任務分派到對應嘅處理代理，最後聚合結果。

• 無狀態設計 - 路由器本身唔保留任何上下文
• 支持並行分派，唔同請求可以同時處理
• 適合需要處理多種類型請求嘅系統

路由模式同子代理模式有啲似，但路由器本身唔做任何實質工作，佢只係負責分流同聚合。

場景對比：邊個模式贏？

場景一：一次性任務

一個簡單嘅任務，例如「幫我寫個函數計算折扣」。

• 子代理：4 次呼叫（路由 + 分派 + 執行 + 彙整）
• 其他模式：3 次呼叫
• 結論：單代理已經夠用，拆開反而多咗開銷

對於呢類直接嘅任務，多代理完全係殺雞用牛刀。

場景二：重複性任務

需要多次迭代嘅工作，例如「審查呢十個 Pull Request」。

• 子代理：每次都要經主代理路由，累計 8 次呼叫
• 技能 / 交接模式：狀態保留令重複工作更高效，累計 5 次呼叫（少 40%）
• 結論：有狀態嘅模式完勝

當任務需要重複執行，上下文保留帶嚟嘅效率優勢會隨住迭代次數放大。

場景三：跨領域任務

需要同時處理前端、後端、數據庫嘅任務，例如「加一個新嘅 API endpoint 連埋前端表單」。

• 子代理 / 路由模式：5 次呼叫，約 9K tokens - 並行處理唔同領域
• 技能模式：所有嘢塞喺同一個上下文，約 15K tokens
• 結論：並行模式節省 67% token 消耗

跨領域任務係多代理架構最能發揮價值嘅場景。將唔同領域隔離到獨立代理，可以避免上下文膨脹，同時利用並行執行加速。

揀模式嘅決策指南

場景特徵	建議模式
一次性、簡單任務	單代理（唔使拆）
重複性、需要記憶	技能模式 / 交接模式
跨領域、可並行	子代理模式 / 路由模式
嚴格順序流水線	交接模式

最重要嘅一條建議

由單代理開始。寫好嘅提示詞。只有當你撞到明確嘅樽頸 - 上下文爆咗、任務太多元、需要並行加速 - 先至考慮拆成多代理。

好多團隊犯嘅錯誤係一開始就設計過度複雜嘅多代理系統。事實上，一個寫得好嘅單代理配合精準嘅提示詞，已經可以處理到大部分場景。多代理架構係解決特定問題嘅工具，唔係銀彈。

先確認你個問題真係需要多代理嚟解決，然後再根據場景特徵揀啱嘅模式。噉先至係正確嘅做法。