核對日：2026-10-29。 好多團隊見到 AI agent 嘢就諗住一開波就起個 multi-agent swarm，但其實 Anthropic 官方嘅建議好簡單直接：多數情況先用單一 agent 已經夠。佢哋喺 multi-agent 系統指南入面講到，唔少團隊花咗幾個月起複雜嘅 multi-agent 架構，最後先發現原來改善單一 agent 嘅 prompt 已經解決到問題。呢篇就同你拆解：幾時真係值得上 multi-agent，幾時係白做。
先問自己：單 agent 係咪已經試到盡？
Anthropic 喺另一篇 building effective agents 提出一個核心原則：先簡單、可組合；有真實需要先加複雜。
意思係話，單一 agent 加好工具、寫好驗收條件，好多時表現已經夠好。複雜架構帶嚟嘅係更多 debug 位、更多協調成本、更難測試。你未試盡簡單方案之前，起 swarm 好大機會係為複雜而複雜。
Multi-agent 嘅真實成本：token 開支
呢樣好多人忽略。根據 Anthropic 官方文檔，multi-agent 系統通常用多 3–10 倍嘅 tokens。點解會咁貴？
- Context 重複：幾個 agent 各自要帶住相關背景資料
- 協調訊息：agent 之間要互相溝通、傳遞狀態
- Handoff 摘要：任務交收時要寫總結，都係燒 token
即係話，明明一個 agent 做得到嘅嘢，拆開做隨時貴幾倍，仲要未必好啲。
三個真係值得上 multi-agent 嘅情境
官方文件列咗三種情境，認清楚先好郁手：
- Context pollution：子任務產生大量 output，但對主任務冇用。例如深度研究時，中間讀咗幾十版文件，最後只用得幾句。呢啲時候用 subagent 隔離，等佢消化完先交精華返嚟。
- 可平行處理：如果任務可以拆成幾個獨立面向，同時跑會快好多，例如研究報告可以分幾條線同時查。
- 需要專精：唔同子任務需要嘅工具集、persona 或者領域知識互相衝突，硬塞俾一個 agent 反而亂，拆開做專精 agent 更乾淨。
唔係以上情況？協調成本大過收益
官方講得好白：除咗上述三種情境，拆 multi-agent 嘅協調成本通常大過個收益。你會花時間處理 agent 之間點樣傳話、點樣同步狀態、點樣合併結果——呢啲全部都係工程開支，冇對應到實際產出。
另外有個好有用嘅模式可以記住：verification subagent。主 agent 做完嘢之後，另開一個 verifier agent，用清晰嘅成功準則做黑盒測試——佢唔需要知道成個實作過程，只需要核對結果對唔對。呢個係用多 agent 提升質素，而唔係濫拆。
仲有一個拆工原則值得留意：按 context 邊界拆，唔好按角色拆。即係話唔好做「一個負責規劃、一個負責實作、一個負責測試」嗰種電話傳話式架構——每次傳話都會流失 context，錯誤會滾雪球。
幾時用乜：快速判斷
| 情境 | 先單定多 | 點核對 |
|---|---|---|
| 一般自動化任務 | 先單 agent | 改好 prompt 同工具，試到極限先諗拆 |
| 子任務產出好多無用 context | 考慮 subagent 隔離 | 睇主任務嘅 context 有冇俾雜訊淹沒 |
| 幾個獨立面向可同時做 | 可以 multi-agent | 確認啲面向真係互不依賴 |
| 工具／persona／領域衝突 | 拆專精 agent | 睇單 agent 係咪成日混亂出錯 |
| 想提升產出質素 | 主 agent + verifier | 定義清晰成功準則做黑盒測試 |
香港角度：freelancer 同小團隊點做
如果你係香港嘅 freelancer，或者一兩個人用 Claude Code 做嘢嘅小組，呢個建議對你特別貼身：token 開支係真金白銀，協調複雜度係你自己嘅時間。
建議次序好簡單：
- 先把單一 agent + 工具 + 驗收條件寫到最好
- 真係撞到 context 爆棚、或者有嘢明顯要平行先拆
- 拆嘅時候按 context 邊界拆，唔好按角色拆
若果你想睇多啲點樣同 AI agent 合作時保留自己判斷，可以參考站內 Agents Judgment Calls 解讀。
至於 Anthropic 嘅相關產品同收費安排，以官網當日為準。
結論
Multi-agent 唔係越高級越好，而係有明確情境先值得起。記住三個門檻：context pollution、可平行、需要專精；加上成本意識——3–10 倍 token 唔係講玩。香港嘅獨立開發者同小團隊，先把簡單嘢做好，往往已經夠跑好遠。
更新於 2026-10-29（Asia/Hong_Kong）。
