2025 年是 agent 爆發之年。

基于處理復雜、多步驟任務以及與不同環境實時互動的能力，由大語言模型（LLM）驅動的 agent 系統 ，尤其是多 agent 系統（MAS）， 被認為非常適合用來解決現實世界中的問題 ，也因此被越來越多地應用在各個領域中，如軟件工程、藥物發現、科學模擬，以及通用 agent 系統。

然而， 相比于單個 agent 系統甚至更簡單的 baseline，多 agent 系統卻在處理實際問題時更易出錯 。 如下圖所示，AppWorld 的故障率可高達 86.7%。

圖｜使用 GPT-4o 和 Claude-3 的 5 種常用多 agent LLM 系統的故障率

這是為什么呢？來自加州大學伯克利分校和意大利聯合圣保羅銀行的研究團隊給出了答案——

他們首次對多 agent 系統面臨的挑戰進行了全面研究，并確定了 14 種獨特的故障模式，并劃分為 3 大類：（1）規范和系統設計故障；（2）agent 間錯位；（3）任務驗證和終止。

相關研究論文以“Why Do Multi-Agent LLM Systems Fail?”為題，已發表在預印本網站 arXiv 上。

論文鏈接：https://arxiv.org/abs/2503.13657

具體而言，他們提出了首個基于經驗的多 agent 系統故障分類法——MASFT，理解和緩解多 agent 系統故障提供了一個結構化框架。

同時，他們也開發了一個可擴展的“LLM-as-a-judge”評估管道，用于分析新的多 agent 系統性能和診斷故障模式。

另外，針對 agent 規范、對話管理和驗證策略，他們還進行了干預研究， 盡管將任務完成率提高了 14%，但仍未能完全解決多 agent 系統故障問題 ，這凸顯了結構性多 agent 系統重新設計的必要性。

此外，他們也將研究成果進行 開源 ，包括：

• 150 多個標注的多 agent 系統會話軌跡；

• 可擴展的 LLM-as-a-judge 評估管道和 150 多個軌跡的 LLM 標注；

• 15 個選定軌跡的詳細專家標注。

多達 14 種故障模式

在這項工作中，研究團隊使用了扎根理論（Grounded Theory）這一定性研究方法，直接從經驗數據中構建理論，而不是檢驗預定義的假設，使故障模式的識別有機地產生。

他們通過理論抽樣、開放式編碼、持續比較分析、備忘錄和理論化等方法反復收集和分析多 agent 系統的執行軌跡，獲得多 agent 系統跟蹤記錄并討論初步發現后，通過收集觀察到的故障模式得出了 MASFT。

圖｜系統研究多 agent 系統的方法流程

為了實現自動故障識別，他們開發了基于 LLM 的標注器，并驗證了它的可靠性。

然后，他們進行了標注器之間的協議研究，通過添加、刪除、合并、拆分或修改定義反復調整故障模式和故障類別，直到達成共識。這一過程反映了一種學習方法，即不斷完善分類法，直至達到穩定性，并通過 Kappa 系數來衡量標注器之間的一致性。

圖｜多 agent 系統故障模式分類法

最終，MASFT 包含了 3 個總體故障類別：規范和系統設計故障；agent 間錯位；任務驗證和終止，確定了多 agent 系統在執行過程中可能遇到的 14 種細粒度故障模式。

MASFT 還將多 agent 系統的執行劃分為 3 個階段：執行前、執行中和執行后，確定了每個細粒度故障模式可能發生的多 agent 系統執行階段。

圖｜多 agent 系統故障類別相關矩陣

另外，他們發現，多 agent 系統面臨著與復雜的人類組織類似的問題，其故障模式與在人類組織中觀察到的常見故障模式一致。“不要求澄清”破壞了“尊重專業知識”，“agent 錯位”體現了加強等級區分和協調角色分配的必要性。

多 agent 協作的有效性，仍有待提高

針對以上所有的故障類別，研究團隊提出了戰術策略和結構策略。

戰術策略涉及針對特定故障模式的直接修改，如改進提示、agent 網絡的拓撲結構和對話管理。然而，兩個案例研究證明，這些方法的有效性并不一致。

結構策略，即對整個系統有影響的更全面的方法：強驗證、增強型通信協議、不確定性量化以及內存和狀態管理。這些策略需要更深入的研究和細致的實施，仍是有待未來探索的研究課題。

圖｜多 agent 系統的解決策略和故障分類

研究團隊在兩個案例研究中應用了這些策略方法。

在第一個案例中，他們使用 AG2 中的 MathChat 場景實現作為基線，在該場景中，學生 agent 與能夠執行 Python 代碼的助理 agent 合作解決問題。

為了進行基準測試，他們從 GSM-Plus 數據集中隨機選取了 200 個練習。第一種策略是改進原始提示，使其具有清晰的結構和專門用于驗證的新部分。第二種策略是將 agent 配置細化為一個更專業的系統，其中包含三個不同的角色：問題解決者（Problem Solver），不使用工具，使用思維鏈方法解決問題；編碼者（Coder），編寫并執行 Python 代碼，得出最終答案；驗證者（Verifier），審查討論并批判性地評估解決方案，要么確認答案，要么引發進一步討論。

在這種情況下，一旦找到解決方案，只有驗證人可以終止對話。

在第二個案例中，ChatDev 模擬了一個多 agent 軟件公司，不同的 agent 有不同的角色定位，如首席執行官、首席技術官、軟件工程師和審核員，他們試圖合作解決一個軟件生成任務。

他們實施了兩種不同的干預措施。第一個是改進特定角色的提示，以強化層次結構和角色一致性；第二個是嘗試涉及對框架拓撲結構的根本性改變，將框架的停止結構從有向無環圖（DAG）修改為循環圖。

現在，只有當 CTO agent 確認所有審查都得到適當滿足時，該過程才會終止，并設定了最大迭代截止時間，以防止出現無限循環。這種方法可以實現迭代改進和更全面的質量保證。

圖｜各種方案的性能準確度

研究團隊表示，許多“顯而易見”的解決方案實際上存在嚴重的局限性，需要概述的結構性策略來實現更加一致的改進。

考慮到目前多 agent 協調中的信息冗余與沖突，協作中放大的模型偏差，未來的多 agent 系統需要做到快速響應、實時驗證和動態協調，以提高團隊協作的有效性。

“基于 LLM 的多 agent，在分布式科研協作、應急響應系統等領域仍具有一定的潛力。”

作者：與可

如需轉載或投稿，請直接在公眾號內留言