2025 年是 agent 爆發(fā)之年。

基于處理復(fù)雜、多步驟任務(wù)以及與不同環(huán)境實時互動的能力，由大語言模型（LLM）驅(qū)動的 agent 系統(tǒng)，尤其是多 agent 系統(tǒng)（MAS），被認(rèn)為非常適合用來解決現(xiàn)實世界中的問題，也因此被越來越多地應(yīng)用在各個領(lǐng)域中，如軟件工程、藥物發(fā)現(xiàn)、科學(xué)模擬，以及通用 agent 系統(tǒng)。

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

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

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

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

相關(guān)研究論文以“Why Do Multi-Agent LLM Systems Fail?”為題，已發(fā)表在預(yù)印本網(wǎng)站 arXiv 上。

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

具體而言，他們提出了首個基于經(jīng)驗的多 agent 系統(tǒng)故障分類法——MASFT，理解和緩解多 agent 系統(tǒng)故障提供了一個結(jié)構(gòu)化框架。

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

另外，針對 agent 規(guī)范、對話管理和驗證策略，他們還進行了干預(yù)研究，盡管將任務(wù)完成率提高了 14%，但仍未能完全解決多 agent 系統(tǒng)故障問題，這凸顯了結(jié)構(gòu)性多 agent 系統(tǒng)重新設(shè)計的必要性。

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

150 多個標(biāo)注的多 agent 系統(tǒng)會話軌跡；

可擴展的 LLM-as-a-judge 評估管道和 150 多個軌跡的 LLM 標(biāo)注；

15 個選定軌跡的詳細(xì)專家標(biāo)注。

多達 14 種故障模式

在這項工作中，研究團隊使用了扎根理論（Grounded Theory）這一定性研究方法，直接從經(jīng)驗數(shù)據(jù)中構(gòu)建理論，而不是檢驗預(yù)定義的假設(shè)，使故障模式的識別有機地產(chǎn)生。

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

圖｜系統(tǒng)研究多 agent 系統(tǒng)的方法流程

為了實現(xiàn)自動故障識別，他們開發(fā)了基于 LLM 的標(biāo)注器，并驗證了它的可靠性。

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

圖｜多 agent 系統(tǒng)故障模式分類法

最終，MASFT 包含了 3 個總體故障類別：規(guī)范和系統(tǒng)設(shè)計故障；agent 間錯位；任務(wù)驗證和終止，確定了多 agent 系統(tǒng)在執(zhí)行過程中可能遇到的 14 種細(xì)粒度故障模式。

MASFT 還將多 agent 系統(tǒng)的執(zhí)行劃分為 3 個階段：執(zhí)行前、執(zhí)行中和執(zhí)行后，確定了每個細(xì)粒度故障模式可能發(fā)生的多 agent 系統(tǒng)執(zhí)行階段。

圖｜多 agent 系統(tǒng)故障類別相關(guān)矩陣

另外，他們發(fā)現(xiàn)，多 agent 系統(tǒng)面臨著與復(fù)雜的人類組織類似的問題，其故障模式與在人類組織中觀察到的常見故障模式一致?！安灰蟪吻濉逼茐牧恕白鹬貙I(yè)知識”，“agent 錯位”體現(xiàn)了加強等級區(qū)分和協(xié)調(diào)角色分配的必要性。

多 agent 協(xié)作的有效性，仍有待提高

針對以上所有的故障類別，研究團隊提出了戰(zhàn)術(shù)策略和結(jié)構(gòu)策略。

戰(zhàn)術(shù)策略涉及針對特定故障模式的直接修改，如改進提示、agent 網(wǎng)絡(luò)的拓?fù)浣Y(jié)構(gòu)和對話管理。然而，兩個案例研究證明，這些方法的有效性并不一致。

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

圖｜多 agent 系統(tǒng)的解決策略和故障分類

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

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

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

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

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

他們實施了兩種不同的干預(yù)措施。第一個是改進特定角色的提示，以強化層次結(jié)構(gòu)和角色一致性；第二個是嘗試涉及對框架拓?fù)浣Y(jié)構(gòu)的根本性改變，將框架的停止結(jié)構(gòu)從有向無環(huán)圖（DAG）修改為循環(huán)圖。

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

圖｜各種方案的性能準(zhǔn)確度

研究團隊表示，許多“顯而易見”的解決方案實際上存在嚴(yán)重的局限性，需要概述的結(jié)構(gòu)性策略來實現(xiàn)更加一致的改進。

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

“基于 LLM 的多 agent，在分布式科研協(xié)作、應(yīng)急響應(yīng)系統(tǒng)等領(lǐng)域仍具有一定的潛力?！?/p>

作者：與可