「多 Agent 比較強」可能是算力錯覺：對齊 token 預算後，單一 agent 追平甚至勝出

這篇文章適合你，如果你是…

• 正在設計 agent 系統的 AI 應用開發者: 你在猶豫要不要把任務拆成多個 subagent，需要的不是教學文，是判準
• 要為團隊拍板架構的技術主管: 你需要知道「多 agent」的 15× token 成本換來的到底是什麼
• 已經在跑多 agent 但品質不穩的 ML 工程師: 你需要一張可對照的失效模式表，知道該先修哪一個

---

1. 前言：問題場景

Hook 開場

**** 我在自己的 coding agent 工作流裡做過一件事：把「研究 → 實作 → 審查」拆成三個專職 subagent，每個有自己的 system prompt 和獨立 context window。第一週感覺很好——牆上的時鐘確實變快了，原本要看著它跑十幾分鐘的多檔掃描，現在一分半就回來了。

第三週我開始發現不對勁：review subagent 抓不到 implement subagent 的設計意圖，因為它只拿到一份 800 字的摘要；同一個檔案被兩個 subagent 各改了一次，誰也不知道對方改過。我加了更多 prompt 去描述角色、加了更詳細的交接格式，情況好一點，但沒有真的變好。

**** 從系統架構的角度，這件事其實有跡可循：當你把任務拆給 N 個 agent，你同時改變了兩個變因——架構變了，總算力也變成大約 N 倍。而幾乎所有「多 agent 更強」的公開數據，都沒有把第二個變因固定住。這是實驗設計裡最基本的混淆變因（confounding variable），但在 agent 領域幾乎沒有人談。

**** 直到 2026 年 4 月，Stanford / Contextual AI 的 Dat Tran 與 Douwe Kiela 發表了一篇把這個變因鎖死的對照實驗（arXiv:2604.02460）：固定 thinking token 預算之後，單一 agent 在多跳推理上持續追平、甚至勝過多 agent 系統。

解決方案預告

這篇文章要做的不是「勸你別用多 agent」。多 agent 在對的任務上是壓倒性的——Anthropic 的研究系統就拿到了 90.2% 的相對提升。這篇文章要做的是：把架構效益和算力效益拆開，然後給你一張真正能拿來拍板的判準表。

文章承諾

• 正方與反方的一手數據並排呈現，說明兩者為何不矛盾
• MAST 1,600+ 條標註 trace 的 14 種失效模式完整佔比表（中文）
• 一張「該不該拆」的六維決策表
• 依失效佔比排序的六條改善建議（先修哪個 ROI 最高）

讀者收穫

讀完這篇文章，你將能夠：

1. 分辨一份 agent benchmark 有沒有控制算力變因，不再被 90.2% 這種數字直接說服
2. 用任務的可並行結構（而不是「哪個架構比較先進」）決定要不要拆 agent
3. 找出你自己 multi-agent pipeline 最可能壞掉的那 3 個點，並知道修的順序

---

1.5 TL;DR

• Anthropic 多 agent 系統 +90.2%，但同一篇也寫了：token 用量單獨解釋 80% 的表現變異。你買到的主要是算力，不是架構。
• 對齊 thinking token 預算後（arXiv:2604.02460），單 agent 在多跳推理上追平或勝出。理論依據是 Data Processing Inequality：每次 handoff 只會損失資訊。
• MAST 標註 1,600+ 條 trace：63% 的失效來自你的系統設計（規格 41.77% + 驗證 21.30%），不是模型。單一最大失效模式是「步驟重複」17.14%。
• 唯一有效的判準是任務可並行性：子任務彼此不需要對話才拆。Anthropic 自己說了，多數 coding 任務不符合。
• 「快 40–60%」和「比較準」是兩回事。並行本來就快，那跟正確率無關。

---

2. 核心概念解釋

2.1 什麼是算力混淆

想像有人告訴你：「我們把引擎從 1 顆換成 5 顆，車子快了 90%，所以多引擎架構比較優越。」

你第一個該問的是：如果我把那 5 顆引擎的油全部灌給原本那 1 顆，它會跑多快？

這就是 agent 領域現在的處境。當你開 5 個 subagent 並行，你花掉的是約 5 倍的推理 token。「多 agent」與「5 倍算力」是綁在一起出現的，而公開的比較數據幾乎都是拿「多 agent（5× 算力）」對比「單 agent（1× 算力）」。這個實驗設計無法回答「架構本身有沒有貢獻」。

2.2 為什麼交接一定有代價：Data Processing Inequality

Tran & Kiela 用了一個很乾淨的資訊論框架。對於馬可夫鏈 X → Y → Z：

I(X; Z) ≤ I(X; Y)

簡化版說明：Z 對 X 的資訊量，不可能超過 Y 對 X 的資訊量。資訊經過任何處理只會遞減，不會遞增。

翻成工程語言：subagent A 讀了 20 萬 token 的原始碼，寫了一份 800 token 的摘要交給 lead agent。那 800 token 裡關於原始碼的資訊，數學上保證小於等於原始碼本身。多 agent 架構本身不會憑空產生資訊。

那多 agent 到底貢獻了什麼？拆成三項來看：

項目	方向	說明
更多總算力	正向	但這是花錢買的，不是架構送的
更多獨立 context window	正向，且是架構獨有	繞過單一 context 上限，這是多 agent 真正不可替代的價值
每次交接的資訊損失	負向	會沿著鏈路累積

這張表就是全篇的骨架。 多 agent 唯一無法被「單 agent 加算力」取代的優勢，是第二項——當任務的總資訊量根本塞不進一個 context window。

而這也直接解釋了看似矛盾的實證：

• 任務可切成互不依賴的子問題（例：查出 S&P 500 資訊科技類股所有董事會成員，每家公司一條獨立搜尋路徑）→ 第 2 項收益 >> 第 3 項損失 → 多 agent 大勝
• 任務是多跳推理（第 N 步必須用到第 N-1 步的完整中間狀態）→ 第 3 項損失直接吃掉全部收益 → 單 agent 勝

2.3 關鍵術語

術語	英文	說明
算力混淆	compute confound	架構差異與算力差異綁在一起，無法歸因
思考 token 預算	thinking token budget	只計中間推理 token，不含 prompt 與最終答案
資料處理不等式	Data Processing Inequality	資訊經處理只會遞減
廣度優先任務	breadth-first task	答案需探索多條互相獨立的路徑
Orchestrator-Worker	orchestrator-worker	lead agent 規劃分派，subagent 執行回報
失效模式	failure mode	MAST 定義的 14 種可標註 MAS 失效樣態

視覺素材 1：DPI 資訊漏斗示意圖——原始資料 → subagent → 摘要 → lead agent，每一層漏斗變窄

---

3. 三層證據深度對比（文章核心）

我用三層來源策略把證據分級。這一節請特別注意每個數字的層級標籤——這篇文章最重要的方法論，就是教你分辨數字的份量。

3.1 正方：Anthropic 多 agent 研究系統【Tier 1 一手】

原理簡述：orchestrator-worker 架構。Claude Opus 4 作為 lead agent 負責規劃，一次展開 3–5 個 Claude Sonnet 4 subagent 並行執行，最後由一個獨立的 citation pass 補上引用。

實測效能：

指標	數值	對照基準
內部 research eval 相對提升	+90.2%	vs 單 agent Claude Opus 4
Agent token 用量	約 4×	vs 一般 chat
多 agent 系統 token 用量	約 15×	vs 一般 chat

但請讀完同一篇的這兩段——它們才是重點：

在 BrowseComp 評測上，三個因素解釋了 95% 的表現變異。其中 token 使用量單獨就解釋了 80%，另外兩個是工具呼叫次數與模型選擇。

某些領域需要所有 agent 共享同一份 context、或 agent 之間依賴很多，今天並不適合多 agent 系統。舉例來說，大多數 coding 任務可並行的部分，遠少於研究任務。

我的讀法：Anthropic 自己就把答案寫在旁邊了。這篇文章與其說證明「多 agent 架構比較強」，不如說證明「在廣度優先的研究任務上，把 15× token 花在並行探索是划算的」。這是一個成本效益結論，而不是架構優越性結論——而且第二段等於直接告訴所有做 coding agent 的人：這套結論不要照抄到你身上。

適用場景：

• 適合：廣度優先研究、盤點類任務、資訊總量遠超單一 context
• 不適合：需共享 context、agent 間依賴多的任務；作者點名多數 coding 任務

3.2 反方：對齊 token 預算的對照實驗【Tier 1 一手】

論文：Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets，Dat Tran & Douwe Kiela，arXiv:2604.02460（2026-04-02 投稿，04-11 修訂）。

原理簡述：把「thinking token 預算」鎖死——只計中間推理 token，排除 prompt 與最終答案——然後讓單 agent 與 MAS 在同一預算下比多跳推理。

Before / After 對比（這篇文章的核心對比）：

實驗設計	算力控制	結果
Before：業界主流比較法	未控制（多 agent 自然用掉 N 倍 token）	多 agent 大幅領先
After：對齊 thinking token 預算	嚴格對齊	單 agent 持續追平或勝出

模型家族：Qwen3、DeepSeek-R1-Distill-Llama、Gemini 2.5（三家族交叉驗證，不是單一模型的巧合）。

理論依據：Data Processing Inequality（見 2.2）。作者主張單 agent 在固定推理預算下資訊效率更高。

作者自陳的限制（必須誠實引用）：

• 以 API 控制 token 預算存在明顯假影，Gemini 2.5 尤其嚴重
• 部分 benchmark 本身的性質會人為膨脹多 agent 的表現

我的讀法：這篇不是說「多 agent 沒用」。它說的是——你以為你在選架構，其實你在選預算。而且因為作者自己承認 API 端預算控制不完美，我把它當成強力反證，而不是蓋棺論定。真正的價值在於：它把舉證責任翻轉了。從今以後，宣稱多 agent 更強的一方，有義務說明算力是否對齊。

3.3 多 agent 真正的成本：MAST 失效分類法【Tier 1 一手】

前兩節在爭「多 agent 有沒有加分」。這一節講的是多 agent 額外帶來的扣分項——而這才是實務上真正咬人的部分。

論文：Why Do Multi-Agent LLM Systems Fail?，Cemri et al.（UC Berkeley 等），arXiv:2503.13657。

資料規模與品質：

• MAST-Data：1,600+ 條人工標註的 execution trace
• 涵蓋 7 個主流 MAS 框架
• 分類法由前 150 條 trace 嚴謹分析導出
• Cohen's κ = 0.88（專家標註者間強一致——這個數字很重要，代表這不是一份主觀整理）

三大失效類別佔比：

類別	佔比	白話
FC1 規格與系統設計	41.77%	任務拆錯、角色含糊、沒有終止條件
FC2 Agent 間錯位	36.94%	交接時 context 掉了、彼此矛盾、格式對不上
FC3 任務驗證與終止	21.30%	沒驗、驗不完整、驗錯

14 種失效模式完整佔比（依大小排序）：

代碼	失效模式	佔比
FM-1.3	步驟重複	17.14%
FM-2.6	推理與行動不一致	13.98%
FM-2.2	該問卻不問	11.65%
FM-1.1	不遵守任務規格	10.98%
FM-1.5	不知道該停	9.82%
FM-3.1	過早終止	7.82%
FM-2.3	任務偏離	7.15%
FM-3.2	沒驗證／驗證不完整	6.82%
FM-3.3	驗證錯誤	6.66%
FM-1.4	context 遺失	3.33%
FM-2.1	對話重置	2.33%
FM-2.4	資訊藏私	1.66%
FM-1.2	不遵守角色規格	0.50%
FM-2.5	忽略其他 agent 輸入	0.17%

兩個必須指出的觀察：

1. 榜首不是什麼高深問題。17.14% 是「步驟重複」——同一件事做了兩遍，而且彼此不知道。這完全對上我第三週遇到的狀況：同一個檔案被兩個 subagent 各改一次。
2. FC1 + FC3 = 63.07%，全部都是你自己的系統設計問題，不是模型能力問題。換更強的模型不會修好它們。

介入實驗（ChatDev 案例）：

介入	前	後	提升
新增「高階任務目標」驗證層（原本只有 code-level 檢查）	33.33%	48.93%	+15.6 個百分點
強化系統提示的角色遵循	—	—	+9.4%

（benchmark：ProgramDev）

但作者的結論非常克制，我原文照引：「簡單的修補仍不足以達成可靠的 MAS 表現」，要真正解決需要「更根本的系統設計改變」。

注意：論文明確警告 7 個框架跑在不同 benchmark 上，不可直接互比。網路上很多整理文把它們並排成一張排行榜，那是誤讀。

視覺素材 2：MAST 14 種失效模式橫向長條圖（依佔比排序，FC1/FC2/FC3 三色分組）

3.4 接到企業現場：IBM Research × UC Berkeley【Tier 1 一手，2026-02-18】

把 MAST 套用到 ITBench 上的企業 agent：

模型	Mean Recall	trace 數	每條失敗 trace 的失效模式數
Gemini-3-Flash	75.5%	100	2.6
Kimi-K2	28.6%	105	4.7
GPT-OSS-120B	12.4%	105	5.3

最強失敗預測因子：FM-3.3（驗證錯誤）——在失敗的 Gemini trace 中比成功的高出 52%。Kimi-K2 則以「終止困惑」為主，在失敗 run 中多出 46%。

架構介入（引入 Summarizer Agent 與 State Machine 控制）可帶來最高 53% 的改善。

我的讀法：這張表最狠的一欄是最右邊。弱模型不是「錯得比較多」，是一次錯好幾種、互相纏繞（5.3 vs 2.6 種／次）。這解釋了為什麼多 agent 在弱模型上會災難性放大——每一次 handoff 都在複製一整組互相糾纏的錯誤，而且下游 agent 完全看不出上游交來的東西已經壞了。

如果你在用開源模型跑多 agent，這一欄應該讓你重新考慮架構。

3.5 業界兩大陣營：Cognition vs Anthropic【Tier 2 業界一手】

Cognition（做 Devin，coding agent）的立場：多 agent 協作會產生脆弱系統，因為決策過度分散、context 無法在 agent 間充分共享。建議預設用單執行緒線性 agent，維持 context 連續；只有在 context window 真的溢出時才另尋他法。他們把「如何把正確的 context 餵給模型」定名為 Context Engineering，並坦承實際需要的工作量遠超預期。

Anthropic（做 Research，研究 agent）的立場：見 3.1。

這根本不是一場論戰。 Cognition 做 coding agent，Anthropic 做 research agent。而 Anthropic 自己白紙黑字寫著「大多數 coding 任務可並行的部分遠少於研究任務」。

兩邊都對，因為任務形狀不同。 網路上把這包裝成「AI 領袖架構之爭」的文章，全部都漏掉了這一句。

3.6 Tier 3：廠商與社群宣稱【明確標示為未驗證】

各家 Claude Code subagent 指南普遍宣稱：

• 委派給專職 subagent 可縮短 40–60% 任務時間
• 某案例：12 分鐘的序列多檔掃描縮到 90 秒
• 3–5 個並行 subagent 是甜蜜點，再多「花在合併摘要的時間會超過並行省下的時間」

必須標註：這些數字來自工具指南與部落格，沒有公開方法論、沒有對照組、沒有算力對齊。

但我要說一句公道話：它們與 Tier 1 的結論並不矛盾。並行本來就會縮短牆鐘時間——這是物理，不是魔法。問題出在讀者（和寫的人）常常把它讀成「所以多 agent 比較準」。

牆鐘時間（wall-clock）與正確率是兩個完全不同的指標。 這是全篇最容易被混為一談的地方，也是我自己前三週踩的坑：我看到的是變快，我以為的是變好。

---

4. 決策框架

4.1 六維決策表

訊號	傾向多 agent	傾向單 agent
子任務之間的依賴	幾乎無依賴（各查各的）	第 N 步需要第 N-1 步的完整中間狀態
資訊總量	遠超單一 context window	塞得進單一 context
交接可壓縮性	結論可用短摘要無損表達	中間推理過程本身就是價值
任務型態	廣度優先研究、盤點、掃描	多跳推理、重構、需全域一致性的 coding
驗證是否可獨立進行	每個子結果可獨立驗證	只有最終結果可驗證
任務價值 vs 15× token 成本	價值 > 成本	價值 < 成本

4.2 決策樹（文字版）

這個任務能不能拆成幾個「彼此不需要對話」的子任務？
├─ 不能 ──────────────────────────→ 單 agent。停。不要再想了。
└─ 能
   └─ 總資訊量塞得進一個 context window 嗎？
      ├─ 塞得進 ──→ 單 agent + 更高 thinking budget（更便宜、更準）
      └─ 塞不進
         └─ 每個子結果能獨立驗證嗎？
            ├─ 不能 ──→ 多 agent，但先建驗證層再上線
            └─ 能
               └─ 任務價值 > 15× token 成本？
                  ├─ 否 ──→ 單 agent + 分批處理
                  └─ 是 ──→ 多 agent（3–5 個並行）

4.3 四個真實場景

場景 A：盤點 200 個 repo 有沒有用到某個被棄用的 API

• 需求：廣度掃描，每個 repo 完全獨立
• 推薦：多 agent
• 理由：零依賴、資訊量遠超單一 context、每個子結果可獨立驗證。這是多 agent 的教科書場景。

場景 B：跨 12 個檔案重構一個核心抽象

• 需求：全域一致性，改 A 會影響 B 的設計決策
• 推薦：單 agent
• 理由：中間推理過程本身就是價值，摘要無法無損傳遞設計意圖。Anthropic 自己說了 coding 任務可並行性低。這是我第三週踩坑的場景。

場景 C：用 GPT-OSS-120B 等開源模型跑企業 IT 維運 agent

• 需求：成本敏感，模型能力有限
• 推薦：單 agent，而且先修驗證
• 理由：IBM/Berkeley 數據顯示該模型 Mean Recall 僅 12.4%，且每條失敗 trace 平均纏繞 5.3 種失效模式。在這個基礎上開多 agent 是在放大糾纏。

場景 D：深度研究一個主題，需要查 30 個獨立來源

• 需求：廣度優先，資訊量大，任務價值高
• 推薦：多 agent（3–5 個並行）
• 理由：完全對應 Anthropic 的場景。但要記得配一個獨立的 citation / 驗證 pass。

---

5. 實戰最佳實踐

如果你已經決定要用多 agent，這裡是依 MAST 失效佔比排序 的投資報酬率清單——先修佔比大的。

常見錯誤 → 正確做法

常見錯誤	正確做法	依據
只做 code-level 檢查	加一道「高階任務目標」驗證層	ChatDev 實測 33.33% → 48.93%
沒定義終止條件，靠模型自己判斷	明確寫死終止條件	FM-1.5（9.82%）+ FM-3.1（7.82%）= 17.64%
沒有共享狀態，各 agent 自己記	共享「已完成事項」狀態表	FM-1.3 步驟重複是最大單一失效模式 17.14%
用自然語言交接	結構化 handoff schema，並允許 subagent 回報「我需要澄清」	FC2 佔 36.94%，FM-2.2 該問卻不問 11.65%
直接讓 subagent 互相對話	引入 Summarizer Agent + State Machine 控制	IBM/Berkeley 實測最高 +53%
憑感覺調整	先量測再擴張	見 5.2

5.2 該量測的三個指標

不要抄任何一篇報告的數字當你的基準線。以下三個是可以在你自己 pipeline 上複製的：

1. 每個 subagent 的 token 用量分佈 —— 你才知道你的「15×」實際是幾倍
2. 每條失敗 trace 的失效模式數 —— IBM/Berkeley 的 2.6 vs 5.3 是可直接對照的刻度
3. 零驗證通過率 —— 有多少 subagent 輸出是沒經任何檢查就被 lead agent 採用的

關於數字離散的警告：同一個問題「多少比例的企業遇過 agent 安全事件」，2026 年不同廠商報告給出 50%（DigiCert）／54%／65%（Kiteworks）／88%（Gravitee, n>900）。差距接近 1.8 倍，因為母體、事件定義（「確認」vs「疑似」）、時間窗全都不同。這類數字唯一正確的用法是看趨勢方向，不是當你的基準線。

---

6. 效能調優技巧

技巧 1：先加 thinking budget，再考慮加 agent

這是 Tran & Kiela 論文最直接的實務推論。在拆架構之前，先把單 agent 的 thinking token 上限拉高到跟你預計花在多 agent 上的總量相當，量一次。如果單 agent 就達標了，你省下的不只是 token，是整套 orchestration 的維護成本。

技巧 2：把「去重」做在狀態層，不要做在 prompt 層

FM-1.3（步驟重複）佔 17.14%，是最大單一失效模式。用 prompt 叫 agent「不要重複已完成的工作」效果有限——它看不到別人做了什麼。正確做法是維護一份 lead agent 持有的、subagent 唯讀的「已完成事項」清單，並在每次派工時注入。

技巧 3：驗證層要驗「任務目標」，不要驗「輸出格式」

ChatDev 的 +15.6 個百分點來自新增針對高階任務目標的驗證，而不是加強既有的 code-level 檢查。格式驗證抓不到「它做完了但做錯了事」——而這正是 FM-1.1（不遵守任務規格，10.98%）的樣態。

技巧 4：並行數控制在 3–5

這條是 Tier 3 社群共識（Anthropic 的實作也落在同一區間），但機制上說得通：超過之後，lead agent 合併摘要的成本與資訊損失，會吃掉並行省下的時間。

---

7. 工具與資源推薦

• MAST 論文與資料集 — https://arxiv.org/abs/2503.13657 — 14 種失效模式的完整定義，可直接拿來當你 pipeline 的標註 schema
• Tran & Kiela 對照實驗 — https://arxiv.org/abs/2604.02460 — 想自己複現「對齊預算」實驗的方法論起點
• Anthropic multi-agent research system — https://www.anthropic.com/engineering/multi-agent-research-system — orchestrator-worker 的一手實作細節
• Cognition, Don't Build Multi-Agents — https://cognition.com/blog/dont-build-multi-agents — Context Engineering 的觀念來源
• IBM Research × UC Berkeley, ITBench + MAST — https://huggingface.co/blog/ibm-research/itbenchandmast — 把 MAST 套進企業場景的示範

---

8. 總結與展望

一表看完

主張	證據等級	數據	該怎麼用
多 agent 在廣度優先任務上大勝	Tier 1	Anthropic +90.2%，15× token	成立，但限定任務形狀
那個勝利主要來自算力	Tier 1	token 用量解釋 80% 變異（Anthropic 自陳）	拆架構前先問「加算力行不行」
對齊預算後單 agent 追平／勝出	Tier 1	arXiv:2604.02460，3 個模型家族	舉證責任翻轉；但作者自陳 API 控制有假影
多 agent 的失效 63% 是你的設計問題	Tier 1	MAST 1,600+ traces，κ=0.88	換模型救不了，改設計才行
弱模型上失效會纏繞放大	Tier 1	5.3 vs 2.6 失效模式／失敗 trace	開源模型跑多 agent 要格外謹慎
subagent 快 40–60%	Tier 3	無方法論	只能當牆鐘時間參考，與正確率無關

按讀者類型的推薦

• 個人開發者：預設單 agent。只在「盤點型、零依賴」的任務上開 subagent。
• 企業團隊：先建驗證層再擴張 agent 數。你現在平均跑 12 個 agent、其中一半根本沒串起來（Salesforce 2026 Connectivity Benchmark），那不是多 agent 架構，那是 12 個各自為政的單 agent。
• 研究者：任何 MAS 論文，第一件事是檢查算力是否對齊。這是目前這個領域最大的方法論漏洞。

未來趨勢

1. 「對齊算力」會變成 MAS 論文的標配要求。Tran & Kiela 翻轉了舉證責任，接下來一年應該會看到大量舊結論被重測。
2. 失效模式標註會從論文走進生產監控。IBM/Berkeley 已經示範了把 MAST 當成 observability schema 用——「每條失敗 trace 幾種失效模式」會變成一個真正的 SRE 指標。
3. Context Engineering 會吃掉 orchestration 的地位。Cognition 的賭注是：把 context 傳好，比把 agent 拆多更重要。

今天就可以開始的四步

1. 找出你 pipeline 裡最貴的那個多 agent 流程，量一次總 token 用量
2. 用同樣的 token 預算跑一次單 agent，比對正確率（不是速度）
3. 抽 20 條失敗 trace，用 MAST 的 14 種模式標一遍，找出你的 Top 3
4. 針對 Top 3 的第一名做一次介入，只改一個變因，再量一次

---

8.5 金句

「你以為你在選架構，其實你在選 token 預算。」

「多 agent 唯一無法被『單 agent 加算力』取代的優勢，是任務的資訊量根本塞不進一個 context window。除此之外，你都在花錢買你本來就買得到的東西。」

「Cognition 和 Anthropic 不是在吵架。一個做 coding agent，一個做 research agent——兩邊都對，因為任務形狀不同。」

「63% 的多 agent 失效來自你的系統設計，不是模型。換更強的模型救不了它們。」

「我看到的是變快，我以為的是變好。牆鐘時間和正確率是兩個指標。」

---

9. 延伸思考

1. 你上一次決定「把這個任務拆成多個 subagent」，依據是任務結構，還是「多 agent 聽起來比較先進」？
2. 如果把你花在 orchestration 上的全部 token，改成一次單 agent 的 thinking budget，你猜結果會差多少？你敢不敢真的量一次？
3. 你的 pipeline 裡，有多少 subagent 的輸出是沒有經過任何驗證就被下游採用的？

---

10. FAQ

Q1: 所以我到底該不該用多 agent？
先問一句話：這個任務能不能拆成幾個彼此不需要對話的子任務？不能，就別拆。能，再往下檢查資訊量是否超過單一 context window。

Q2: Anthropic 的 90.2% 是假的嗎？
不是。那是真實的內部 research eval 結果。但它是「多 agent + 15× token」對比「單 agent + 1× token」，而 Anthropic 自己也寫了 token 用量單獨解釋 80% 的變異。數字是真的，歸因需要小心。

Q3: Tran & Kiela 那篇有多可信？
方法論乾淨、跨三個模型家族。但作者自陳 API 控制 thinking budget 有明顯假影（Gemini 2.5 最嚴重），所以我把它當強力反證而非定論。

Q4: MAST 的 1,600 條 trace 和我看到的「200 個任務」哪個對？
兩個都有出處：分類法由前 150 條 trace 導出、涵蓋 7 個框架超過 200 個任務，最終 MAST-Data 資料集是 1,600+ 條標註 trace。引用時說清楚是哪一個。

Q5: 我可以拿 MAST 裡的框架正確率排排名嗎？
不行。論文明確警告這些跑在不同 benchmark 上，不可直接互比。網路上很多整理文做了這件事，那是誤讀。

Q6: 「快 40–60%」不算好處嗎？
算，但那是牆鐘時間的好處。如果你的瓶頸是等待時間、任務又天然可並行，那很有價值。它跟正確率沒有關係。

Q7: coding agent 適合開 subagent 嗎？
分任務。掃描、盤點、跑測試這類零依賴的適合；跨檔案重構、需要全域一致性的不適合。Anthropic 原話：大多數 coding 任務可並行的部分遠少於研究任務。

Q8: 用開源模型跑多 agent 可行嗎？
要非常謹慎。IBM/Berkeley 數據顯示 GPT-OSS-120B 在 ITBench 上 Mean Recall 12.4%，且每條失敗 trace 平均纏繞 5.3 種失效模式（Gemini-3-Flash 是 2.6）。錯誤會沿著 handoff 放大。

Q9: 我該先修哪個失效模式？
依 MAST 佔比：先做去重（FM-1.3，17.14%），再補高階目標驗證層（ChatDev 實測 +15.6 個百分點），然後寫死終止條件（FM-1.5 + FM-3.1 合計 17.64%）。

Q10: 那些企業調查數字（12 個 agent、88% 遇過安全事件）可以引用嗎？
可以引用趨勢，不要當基準線。光是「多少企業遇過 agent 安全事件」，2026 年不同報告就從 50% 到 88%，差 1.8 倍。

Q11: 加驗證層會不會讓成本又上去？
會。但 ChatDev 的數據是正確率從 33.33% 拉到 48.93%——如果你的 pipeline 有重跑成本，驗證層通常是省錢的。

Q12: 有沒有可能未來多 agent 就真的贏了？
有。DPI 說的是「交接會損失資訊」，不是「多 agent 永遠比較差」。如果交接的資訊損失能被壓到夠低（更好的 handoff schema、共享狀態、結構化協定），這個天平會移動。這正是 Context Engineering 在做的事。

---

11. 參考資料

論文

• Cemri et al., Why Do Multi-Agent LLM Systems Fail?, arXiv:2503.13657 — https://arxiv.org/abs/2503.13657
• Tran & Kiela, Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets, arXiv:2604.02460 — https://arxiv.org/abs/2604.02460

業界一手

• Anthropic, How we built our multi-agent research system — https://www.anthropic.com/engineering/multi-agent-research-system
• Cognition, Don't Build Multi-Agents — https://cognition.com/blog/dont-build-multi-agents
• IBM Research × UC Berkeley, ITBench and MAST（2026-02-18）— https://huggingface.co/blog/ibm-research/itbenchandmast

產業調查（引用時請標註為調查數據）

• Salesforce 2026 Connectivity Benchmark Report（12 agents / 50% 獨立運作）
• Anthropic 2026 Agentic Coding Trends Report（60% 工作量 / 0–20% 可完全交辦）
• Futurum Group, 1H 2026 Enterprise Software Decision Maker Survey
• Gravitee, State of AI Agent Security 2026（n > 900）

---