幫 AI 分多個角色真的比較好嗎？
2026 最新研究說「先別」
你可能聽過「給 AI 分主管」「PM agent + 工程師 agent + 測試 agent」這種設計。 Anthropic、Stanford、Cognition 三家最新研究結論：多 agent 的價值是「並行覆蓋」、不是「分工」，把 AI 排成公司組織圖通常會更糟。
這篇看 2026 年最新研究結論、告訴你為什麼「給 AI 分角色」的直覺常常是錯的、什麼時候真該用、什麼時候別用。 不需要懂技術、每個名詞第一次出現都會白話解釋。文末有給新手的應用建議跟判斷指引表、看完知道下次該怎麼做。
「給 AI 分主管」聽起來很合理、為什麼研究說別這樣做？
2025 年很多人這樣做：把 AI 設計成「產品經理 agent → 工程師 agent → 測試 agent → 部署 agent」的線性流程。 像公司組織圖一樣分工、聽起來很合理對吧？
結果大部分案例都失敗了。成本爆 3 到 15 倍、效果常常比一個單純的 AI 還差、debug 起來像剝洋蔥。
這個失敗模式有個名字、叫「三省六部幻覺」（中文 AI 社群 @sujingshen 提出、aihao 整理）。直覺把 AI 想成可以排組織圖的人類、但 AI 不是這樣運作的。
Agent 就是「會做事的 AI」。你叫它做一件任務、它會自己拆步驟、用工具、產出結果。 Multi-agent 就是「叫一群 AI 一起做事」、可能分角色、可能並行、可能互相討論。 比喻：Agent 是「一個會自己想辦法的員工」、multi-agent 是「找一個團隊一起做」、聽起來多人比較強、但實際上不一定。
核心觀念：分工 ≠ 並行
多 agent 的價值是 「並行覆蓋」（同時做多件獨立的事）、不是「分工」（把一件事切給多個角色）。 最好的 AI 系統長得像「一個思考者寫多份草稿」、不是「一家公司的組織圖」。
「並行覆蓋」是讓 3 個 AI 同時看同一個問題、各自寫一份答案、再選最好的。 「分工」是把一個任務拆成 5 段、A agent 做第 1 段、B agent 做第 2 段、串成一條線。 這兩個聽起來像、但一個有效、一個沒效。
因為 AI 不是人類員工。人類員工有共識、會問、會補位。AI agent 之間只能用文字傳訊息、每次傳遞都會掉資訊。 比喻：像國小玩的傳話遊戲。第一個人說「明天下午三點開會」、傳到第十個人變成「明天下雪三千開花」。AI agent 串得越多、傳的越歪。
三篇 2026 年最新研究的結論
不是個人意見、是 Anthropic 官方 + Stanford 論文 + Cognition AI（做 Devin 的公司）親身故事。三個來源一致指向同一個方向。
結論 1：在等量「思考預算」下、單一 AI 持平或贏多 agent
Stanford 的 Dat Tran 與 Douwe Kiela 做了一個關鍵實驗：很多人說多 agent 比較強、但都沒有控制 token 用量。 多 agent 系統用 5 倍 token、當然比較強、那不公平。
研究者把 token 預算切到一樣之後重做實驗、跨 Qwen3、DeepSeek、Gemini 三個模型家族測試。結果：單一 agent 在多跳推理（需要多步驟思考的問題）持平或贏多 agent 系統。
AI 處理問題的最小單位叫「Token」、可以想成「AI 用掉的字數」。 一個 AI 用 1000 token 想出一個答案、跟三個 agent 各用 333 token 串起來想、後者每個都被切碎、結論變糟。
結論 2：只在「三個明確場景」該用多 agent、其他都先用單 agent
做 Claude 的 Anthropic、自家經過上百次實驗整理出來：多 agent 只在三個明確場景才贏、其他情況單 agent 配好的 prompt 就夠。
Anthropic 還說：團隊試過很多次、本來打算用多 agent、結果把單 agent 的 prompt 寫好、效果就一樣。 他們的建議：「從最簡單能用的做法開始、有證據才加複雜度」。
結論 3：做 Devin 的公司、從「別做多 agent」到「正確的多 agent」
Cognition 是做世界第一個自動寫程式 AI 工程師 Devin 的公司。2025 年 6 月、他們發了一篇〈Don't Build Multi-Agents〉（別做多 agent）、是當時業界最強烈的反對聲音。
九個月後的 2026 年 3 月、他們推出「Manage Devins」（多個 Devin 協作）。看起來像打臉、實際上不是：他們做的不是線性分工、而是一個主 Devin 把任務拆給多個獨立 Devin、各自在隔離環境跑、結果回來主 Devin 整合。
為什麼「分角色」直覺會踩雷
四個具體的失敗機制、看完你就知道為什麼業界都收手了。
錯誤放大效應
每個 AI 都會犯小錯。90% 正確的 agent、串三個就只剩 72.9%。串五個 = 59%。 分工越多、錯誤越疊。
0.9 × 0.9 × 0.9 = 0.729資訊在傳遞中死亡
AI agent 之間只能用文字傳。每次「我講給下一個 agent 聽」都會丟細節、會誤解、會走樣。 傳話遊戲、傳越多次差越大。
Token 成本非線性爆炸
研究實測：多 agent 平均吃單 agent 的 3 到 15 倍 token。 最糟的 edge case：一個小錯誤觸發重試、可能吃 50 倍。月底帳單看得心臟病。
系統設計差、不是 AI 不夠強
業界調查：41% 到 86.7% 的多 agent 失敗、原因是架構設計問題、不是模型能力不夠。 換更強的模型也救不了爛架構。
Anthropic 官方認可的 3 個適用場景
不是「多 agent 都不能用」、是「只在這三個明確場景該用」。
Context 隔離
子任務會產生大量無關於主任務的資訊、塞給主 AI 反而干擾思考。把它丟給 subagent 跑、結果回來、過程不污染主 AI。
並行化
多個彼此獨立的任務、同時跑比依序跑快很多。一個 subagent 做一個、互不相關。
專業化
工具數量超過 15-20 個、或需要互相衝突的系統指令。例如「寫程式要嚴謹」vs「寫文案要有溫度」、塞同一個 AI 會打架。
正確的「多 agent」長什麼樣？
2026 年業界活下來的多 agent 系統都長同一個樣子：Orchestrator + 短期 isolated subagent。
subagent 做完就消失、不互相對話、不共享狀態、每次都 fresh context。
這個架構叫 Orchestrator + Subagent。重點不是「subagent 有幾個」、是「主 AI 全程掌握 context、subagent 只是工具、做完即丟」。
這跟「分角色」差在哪？
- 分角色：固定流程「PM → 工程師 → 測試」、每個 agent 都活著、互相傳訊息、有共享狀態。會失敗。
- Orchestrator + Subagent：主 AI 看情況臨時叫 subagent 出來做事、做完消失、不對話、不共享。會成功。
因為它不會把雜訊帶回來。subagent 跑去爬 100 篇文章、過程裡讀了 50 萬字、但最後只回報「3 個重點」給主 AI。 過程的 50 萬字消失、主 AI 的記憶保持乾淨。 比喻：派助理去查資料、你只要結論、不需要他把整個圖書館的書搬回辦公室。
不只一種「對的多 agent」、Anthropic 整理了 5 種模式
Orchestrator + Subagent 是最常推薦的入門款、但不是唯一解。 Anthropic 官方 2026/4 文件整理了 5 種協調模式、每種適合不同任務。下面用簡單圖示 + 你會用到的日常場景講一輪。
生成 ↔ 驗證
Generator-Verifier退回時迴圈回生成、最多 N 次直到通過或放棄。一個產出、一個檢查。
📌 你會用到的日常場景
- 寫客戶 Email：一個 AI 寫、另一個 AI 檢查「禮貌、清楚、CTA 都有了沒、有沒踩到禁忌」
- 程式碼產出：AI 寫完、另一個 AI 跑單元測試 + 檢查安全漏洞
- 合約審閱：AI 審完條款、另一個 AI 用法律檢查清單複審
- 事實查核：AI 寫好文章、另一個 AI 對著官方文件逐句驗證
主管 + 短期幫手
Orchestrator-Subagent · 最常推薦的入門款主 AI 持有全部 context、subagent 做完就消失、不對話、不共享狀態。
📌 你會用到的日常場景
- 寫深度文章：主 AI 統籌、派 subagent 平行查 Anthropic / Stanford / Cognition 三家、回來主 AI 整合
- 規劃旅行：主 AI 統籌、subagent 各自查機票 / 住宿 / 景點 / 餐廳、回報後整合行程
- 程式碼審查：主 AI 派 subagent 各看「安全」「測試」「風格」「架構」、整合成一份 review
- 市場研究：派 subagent 各查一個競品、回來整合對比表
持久團隊
Agent Teams每個 agent 自己從任務池挑、做完繼續挑、過程累積經驗。跟 #2 差別：agent 持續活著、累積 context。
📌 你會用到的日常場景
- 批改 100 份學員作業：多個 agent 各自挑作業改、批越多越懂這套教材的常見錯誤
- 整理 200 篇 Notion 文章：多個 agent 並行分類、過程裡學會這個庫的主題結構
- 客服系統：多個 agent 在線值班、各自處理客戶問題、累積常見問題知識
- 大型程式碼遷移：每個微服務派一個 agent 負責、各自做完累積遷移經驗
訊息匯流排
Message Bus事件驅動：訊息到了路由器看內容、丟給對應 agent 處理。新增 agent 不用重接線。
📌 你會用到的日常場景
- Email 自動分類：信進來、AI 判斷是工作 / 家人 / 垃圾、丟給不同 AI 處理
- Discord / Slack 群組 bot：訊息進來、路由器判斷是問題 / 報數據 / 閒聊、各派 agent 處理
- 客服票券系統：客戶提單 → 路由器判斷類型（退款 / 技術 / 投訴）→ 派專科 AI
- 監控告警：系統告警進來、路由器分類（資安 / 效能 / 業務）→ 派對應處理員
共享白板
Shared State沒有中央指揮、agent 各自挖、發現寫進共享白板、互相看到後再延伸。要設「停止條件」避免無限迴圈。
📌 你會用到的日常場景
- 主題深度研究：多個 AI 各挖一個面向（學術文獻 / 產業報告 / 新聞）、寫進共享 DB、互相延伸
- 團隊腦力激盪：多個 AI 各提想法寫進 Notion、看到別人的想法後再深化
- 競品分析：每個 AI 負責一家、寫進共享表格、看到其他 AI 發現的角度後補強自己的
- 長期觀察任務：每個 AI 觀察一個指標、寫進共享 dashboard、定時整合
不確定就從 #2（Orchestrator + Subagent）開始、Anthropic 自己也是這樣建議。 看到實際痛點再升級：需要驗證 → 加 #1、需要累積 → 升 #3、需要動態擴展 → 升 #4、需要去中心化 → 升 #5。
反思：我設計了 12 個「主管」、那算錯嗎？
我經營的公司用 Claude Code 跑日常營運、設計了 12 個「主管」角色：行銷長、銷售長、人才長、財務長、法務長等等。 乍看像是「三省六部」、看完研究我也擔心了一下。仔細檢查、發現我其實做對了、只是差點走錯。
沒有固定流程、Claude 自己決定要不要叫主管
我從來沒有寫「先找行銷長 → 再給銷售長看 → 最後給數據長」這種流程。 我寫的是：「如果這個問題需要行銷專業判斷、就調用行銷長角色；如果不需要、就自己處理」。
Claude 大部分時候都自己處理掉、不叫任何主管。只有真的需要專業視角時才會調出來。 這恰好就是 Anthropic 推薦的 Orchestrator + Subagent 模式：主 AI 持有 context、需要才 spawn。
如果當初我寫成「每個任務都要過 12 個主管討論一輪」、就是經典的失敗模式。 把角色設計成「備用工具」、不是「固定流程」、是這套設計能跑的關鍵。
給自己的提醒
- 角色描述要寫「什麼情況下該調用我」、而不是「我會做什麼」
- 不要設計「角色 A 完成後傳給角色 B」這種 hand-off 流程
- 每個 subagent 都拿乾淨 context 開始、不要塞前一個的對話歷史
- 並行操盤（同時跑多個客戶分析）✓ 用 subagent；單一線性任務 ✗ 別拆
下次你想叫 AI 做事、該用單 agent 還是多 agent？
一張表幫你判斷、不用每次都靠直覺。
| 你的任務情境 | 推薦做法 | 理由 |
|---|---|---|
| 單一線性任務（寫一篇文章、寫一個程式） | 單 agent | 沒理由拆、拆了反而傳話遊戲 |
| 需要連續對話的任務（諮詢攻略、寫策略） | 單 agent | 共享狀態多、不適合拆 |
| 大量重複、彼此獨立的任務（150 個逐字稿） | 多 agent（並行） | 典型的並行化場景 |
| 子任務會塞爆主 AI 記憶（爬 50 篇文章寫摘要） | 多 agent（隔離） | Context 隔離場景 |
| 需要互相衝突的指令（嚴謹程式 + 溫度文案） | 多 agent（專業化） | system prompt 打架、要分開 |
| 線性分工流程（PM → 工程師 → 測試） | 先別、改回單 agent | 典型的「三省六部幻覺」 |
| 不確定、第一次做 | 先用單 agent | 有問題再加複雜度、不要預先過度設計 |
3 個判斷信號（看到就考慮多 agent）
- 主 AI 的記憶快塞爆了（很長的對話、AI 開始忘記前面講過什麼）→ 子任務丟 subagent 隔離
- 同樣的事要做很多次（150 個影片轉錄、20 個客戶分析）→ 並行
- 工具列表超過 15 個、或同一個 AI 要兼顧「工程嚴謹」+「文案溫度」→ 專業化
3 個警告信號（看到就退回單 agent）
- 你開始畫「A → B → C → D」的流程圖 → 三省六部幻覺、別做
- agent 之間需要頻繁互相詢問 → 緊密耦合、合併
- token 帳單莫名暴漲 → 一定是多 agent 在 retry、回頭看架構
從最簡單能用的做法開始、
有證據才加複雜度。
這是 Anthropic 給所有人的建議。
記住這三件事
多 agent 的價值是「並行覆蓋」、不是「分工」。把 AI 排成公司組織圖通常會更糟、別憑直覺做。
預設用單 agent、明確場景才用多 agent。Anthropic 認可的三個場景：context 隔離、並行、專業化。其他情況把 prompt 寫好就夠。
用多 agent 就用「Orchestrator + 短期 isolated subagent」。主 AI 全程掌握、subagent 做完就丟、不要 peer-to-peer 對話、不要共享狀態、不要固定流程。
延伸閱讀
另一個常見混淆。Skill 是 Anthropic 官方規格、Workflow 是描述用詞、別搞混。
給新手的 Skill 跨專案設計入門、不會 Git 也能看懂。
2025/06 業界最強烈的反多 agent 文章原文、英文、奠定後續討論基礎。
Anthropic 官方文件、三個適用場景 + 推薦架構、英文。
中文整理、把這幾篇核心研究串成一個流暢的論述、推薦先看這篇。
Single-Agent Outperforms Multi-Agent 完整論文、Data Processing Inequality 理論基礎、英文。
參考資源（依重要性排序）
- Anthropic · Building Multi-Agent Systems: When and How to Use Them — claude.com/blog
- Anthropic · Multi-Agent Coordination Patterns（5 種協調模式來源）— claude.com/blog
- Stanford · Tran & Kiela: Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets — arXiv:2604.02460
- Cognition AI · Don't Build Multi-Agents（2025/06）— cognition.ai/blog
- LangChain · Benchmarking Multi-Agent Architectures — blog.langchain.com
- Microsoft AutoGen · 多 agent 失敗模式分析（main repo 已 maintenance-only）
- aihao.tw · 多 Agent 反模式與模式中文整理（2026/05/19）— blog.aihao.tw
- @sujingshen · 「三省六部幻覺」原創批評詞、文中引用此用語表示對固定分工式多 agent 設計的批評（透過 aihao 整理轉述）