Agent 越多，為什麼反而更容易失敗？

Multi-Agent 系統的迷思與陷阱

我們常以為，一個 Agent 能做的事情有限，那就多找幾個 Agent 分工：有人規劃、有人執行、有人檢查，成果應該會更好。

但 UC Berkeley 的研究《Why Do Multi-Agent LLM Systems Fail?》卻發現：Agent 系統做不好，問題可能不在模型不夠強，而在整套合作方式沒有設計好。

核心問題

多個 Agent 明明可以分工、討論與互相幫忙，為什麼最後做出來的結果，不一定比單一 Agent 更好，甚至可能因為合作而產生更多問題？

關鍵洞察

Agent 不是越多越好。每個 Agent 要負責什麼、彼此之間怎麼交換資訊，以及最後如何確認成果是否正確，這些系統設計往往比單純換一個更強的模型更重要。

多個 Agent，不一定比單一 Agent 更強

研究團隊分析了七套主流的 Multi-Agent System（MAS），以及 1,642 筆 Agent 執行任務時留下的完整過程，發現這些系統的任務失敗率落在 41%～86.7% 之間。

由於每套系統執行的任務與評估方式不同，這些數字不能直接拿來比較哪一套比較好。但它至少說明了一件事：即使是目前主流的 Multi-Agent System，失敗仍然很常見。

更反直覺的是，多個 Agent 合作帶來的進步，往往相當有限。

有時候，它們甚至沒有比「讓同一個 Agent 多回答幾次，再從中挑出最好的答案」（best-of-N sampling）這種簡單做法好多少。

原因是，多一個 Agent，不只多一份能力，也多了一層協作成本。

系統必須處理角色分工、資訊交接、意見衝突與最後決策。如果這些問題沒有設計清楚，增加 Agent 的數量，反而可能讓整個流程變得更複雜。

問題可能不在模型，而在分工方式

當 Agent 系統表現不好時，我們很容易先想到：是不是模型不夠聰明？是不是換一個更強的新模型就好了？

但研究指出，單純升級模型，不一定能解決問題。

研究團隊把觀察到的問題整理成 14 種失敗模式，並歸納成三大類：

• 系統設計問題
• Agent 之間沒有對齊
• 任務驗證不足

其中前兩類合計就占了將近八成。

例如，其中一種常見的失敗是「角色越權」：某個 Agent 沒有取得負責人的同意，就自己宣布任務已經完成。

研究團隊在其中一套系統裡重新調整流程，明確規定最後必須由上層 Agent 做決定，任務成功率就提升了 9.4%。

模型沒有更換，真正改變的是工作流程。

這也說明，Agent 做不好，有時不是因為它不夠聰明，而是系統沒有說清楚：誰負責執行、誰負責決定，以及做到什麼程度才算真正完成。

Agent 可以溝通，不代表知道該說什麼

第二個常見問題，是 Agent 之間沒有正確交接資訊。

研究中有一個例子：負責登入的 Agent 已經知道「帳號欄位必須填手機號碼」，卻沒有把這件事告訴負責提供帳號資料的 Agent。

結果，系統一直拿錯誤的資料登入，也就不斷重複失敗。

問題不是系統裡沒有人知道答案，而是知道答案的 Agent，沒有意識到另一個 Agent 也需要知道。

這也是為什麼，即使導入 A2A、MCP 等標準化協定，問題仍然可能發生。

這些協定可以讓不同 Agent 或工具，用一致的格式交換資訊；但它們無法自動保證 Agent 知道：

• 哪些資訊必須告訴對方
• 應該在什麼時候提供
• 對方還缺少哪些資訊
• 對方是否已經正確理解

換句話說，讓 Agent「可以溝通」，和讓 Agent「知道該溝通什麼」，是兩件不同的事。

除了把工具串起來，系統還需要定義清楚的交接規則：每一步必須提供哪些資訊、由誰接收，以及如何確認資訊沒有遺漏。

程式可以跑，不代表任務真的完成

第三個問題，是系統只確認「有沒有做完」，卻沒有確認「有沒有做對」。

研究中提到，一套 MAS 做出了一個西洋棋程式。這個程式可以正常執行，從表面上看，好像已經完成任務。

但實際測試後才發現，它根本沒有正確實作西洋棋規則。

系統只檢查了：

程式能不能跑？

卻沒有檢查：

這個程式真的能不能下西洋棋？

這也是許多 Agent 系統常見的驗收落差。

系統可能確認流程已經跑完、程式沒有報錯、文件已經產出，卻沒有確認最後的成果能不能實際使用，以及是否真的解決了原本的問題。

因此，就算系統裡有一個專門負責檢查的 Verifier Agent，也不代表驗證一定有效。

真正重要的不是「有沒有人檢查」，而是「檢查的標準有沒有對準真正的任務目標」。

Agent 系統做不好時，先別急著換模型

這篇研究帶來的提醒很直接：

除了模型本身，Agent 怎麼分工、怎麼交接資訊，以及最後怎麼驗收，也同樣重要。

因此，當 Agent 系統表現不如預期時，與其第一時間更換模型，不如先回頭問三個問題：

1. 這個任務真的需要多個 Agent 嗎？增加 Agent 所帶來的好處，是否大於協作成本？
2. Agent 之間需要交接哪些資訊？系統有沒有確認資訊已經被正確接收與理解？
3. 最後驗收的是「流程有跑完」，還是「成果真的能用」？

如果這三個問題沒有先處理好，就算換成更強的模型，也可能只是在同一套有問題的流程裡，跑得更快而已。

金句啟發

「Agent 系統做不好，問題可能不在模型不夠聰明，而在我們沒有把分工、交接和驗收設計清楚。」

延伸閱讀

[1] Why Do Multi-Agent LLM Systems Fail?（Cemri et al.）

[2] MAST：Multi-Agent System Failure Taxonomy

以上文章為【數創電子報 Vol.46】你以為 Agent 越多，系統就越強？研究要你失望了

重點整理

Multi-Agent System 一定比單一 Agent 更好嗎？

不一定。多個 Agent 雖然可以分工、平行處理任務並提供不同觀點，但也會增加角色衝突、資訊遺漏、重複工作與驗證不足等協作成本。研究發現，MAS 相較於單一 Agent 或 best-of-N sampling，表現提升往往有限。

導入 MCP 或 A2A，就能解決 Agent 之間的溝通問題嗎？

不一定。這些協定可以讓不同 Agent 或工具用一致的方式交換資訊，卻無法保證 Agent 知道「另一個 Agent 需要什麼」。系統仍然需要定義哪些資訊必須交接、應該在什麼時候提供，以及如何確認對方已經正確理解。

Agent 系統應該怎麼驗收？

不能只檢查流程是否執行完、程式能不能跑，或輸出格式是否正確。驗收條件必須對準真正的任務目標，確認成果是否符合規則、能否在實際情境中使用，以及是否真的解決了原本的問題。