多智能體大語言模型（Multi-Agent LLM）系統(tǒng)會失?。孔罱?，伯克利大學發(fā)表了一篇重磅論文《Why Do Multi-Agent LLM Systems Fail?》，深入剖析了MAS系統(tǒng)的失敗原因，整理出14種具體失敗模式，并提出了相應改進建議。 以下是該論文譯文，Enjoy。 簡介

盡管人們對多智能體系統(tǒng) (MAS) 的熱情日益高漲，其中多個 LLM 智能體協(xié)作完成任務，但與單智能體框架相比，它們在流行基準上的性能提升仍然微乎其微。這一差距凸顯了分析阻礙 MAS 有效性的挑戰(zhàn)的必要性。

在本文中，我們首次全面研究了 MAS 挑戰(zhàn)。我們分析了五種流行的 MAS 框架，涉及 150 多個任務，涉及六位專家人工Annotator。我們確定了 14 種獨特的故障模式，并提出了適用于各種 MAS 框架的綜合分類法。該分類法從每項研究中三位專家Annotator之間的一致意見中迭代出現(xiàn)，Cohen's Kappa 得分為 0.88。這些細粒度的故障模式分為 3 類：(i) 規(guī)范和系統(tǒng)設計故障，(ii) 代理間錯位，以及 (iii) 任務驗證和終止。為了支持可擴展評估，我們將 MASFT 與 LLM-as-a-Judge 集成在一起。我們還探討了是否可以通過提出兩種干預措施輕松預防已識別的故障：改進代理角色的規(guī)范和增強編排策略。我們的研究結果表明，已識別的故障需要更復雜的解決方案，這為未來的研究指明了明確的路線圖。我們開源了我們的數(shù)據(jù)集和 LLM解釋器。

“成功的系統(tǒng)都是一樣的，失敗的系統(tǒng)都有自己的問題?！保?a class="keyword-search" >伯克利，2025）

最近，基于大型語言模型 (LLM) 的代理系統(tǒng)在人工智能社區(qū)中引起了廣泛關注。這種日益增長的興趣源于代理系統(tǒng)能夠處理復雜的多步驟任務，同時與不同的環(huán)境進行動態(tài)交互，這使得基于 LLM 的代理系統(tǒng)非常適合解決現(xiàn)實世界的問題，基于這一特點，多智能體系統(tǒng)在軟件工程等各個領域得到了越來越多的探索，比如藥物發(fā)現(xiàn)、科學模擬，以及最近的通用劑。

圖 1：五種流行的多智能體 LLM 系統(tǒng)與 GPT-4o 和 Claude-3 的失敗率。

在本研究中，我們將基于 LLM 的代理定義為具有提示規(guī)范（初始狀態(tài)）、對話跟蹤（狀態(tài)）和與環(huán)境（例如工具使用情況（操作））交互的能力的人工實體。然后將多代理系統(tǒng)( MAS ) 定義為旨在通過編排進行交互的代理集合，從而實現(xiàn)集體智慧。MAS 的結構旨在協(xié)調努力，實現(xiàn)任務分解、性能并行化、上下文隔離、專門的模型集成和多樣化的推理討論。

圖 2：MAS 故障模式分類。

盡管 MAS 的采用率不斷提高，但與單智能體框架或簡單基線（例如流行基準測試中的最佳 N 采樣）相比，其準確性或性能的提升仍然微乎其微。我們的實證分析表明，最先進的 (SOTA) 開源 MAS ChatDev的正確性可能低至 25%，如圖 1 所示。此外，對于如何構建穩(wěn)健可靠的 MAS，目前還沒有明確的共識。這引出了一個我們首先需要回答的基本問題：MAS 為什么會失敗？

為了了解 MAS 故障模式，我們使用GT理論 (Glaser & Strauss, 1967) 對 MAS 執(zhí)行軌跡進行了首次系統(tǒng)評估。我們分析了五種流行的開源 MAS，雇用了六位專家Annotator來識別 150 條對話軌跡中的細粒度問題，每條軌跡平均超過 15,000 行文本。我們將故障定義為 MAS 未實現(xiàn)預期任務目標的情況。為了確保故障模式和定義的一致性，三位專家Annotator獨立標記了 15 條軌跡，實現(xiàn)了Annotator間一致性，Cohen’s Kappa 分數(shù)為 0.88。通過這項綜合分析，我們確定了 14 種不同的故障模式，并將它們聚類為 3 個主要故障類別。我們引入了多智能體系統(tǒng)故障分類法 (MASFT)，這是 MAS 的第一個結構化故障分類法，如圖 2 所示。我們并不聲稱 MASFT 涵蓋了所有潛在的故障模式；相反，它是分類和理解 MAS 失敗的第一步。

為了實現(xiàn)可擴展的自動評估，我們引入了使用 OpenAI 的 o1 的 LLM-as-a-judge 流程。為了驗證此流程，我們在 10 條軌跡上將其Annotator與三位人類專家Annotator進行交叉驗證，最終獲得 0.77 的 Cohen's Kappa 一致性率。

直觀地看，更好的規(guī)范和提示策略可能會緩解 MAS 故障。為了檢驗這一假設，我們使用提示工程和增強的代理拓撲編排實施了干預措施。我們對 AG2 的案例研究和 ChatDev表明，盡管這些干預措施為 ChatDev 帶來了 +14% 的改進，但它們并不能解決所有故障情況。此外，改進后的性能對于實際部署來說仍然不夠好。

這些發(fā)現(xiàn)表明，MASFT不僅僅是現(xiàn)有多智能體框架的產(chǎn)物，而是 MAS 中存在根本設計缺陷的體現(xiàn)。為了構建強大而可靠的 MAS，MASFT可作為指導未來研究的框架，概述 14 種故障模式中每一種的潛在解決方案。此外，我們還開源了我們的Annotator，以供 MAS 的進一步研究。

雖然人們可以簡單地將這些失敗歸咎于當今 LLM 的局限性（例如幻覺、錯位），但我們推測基礎模型能力的改進不足以解決完整的 MASFT。相反，我們認為良好的 MAS 設計需要組織理解——如果組織結構存在缺陷，即使是由經(jīng)驗豐富的個人組成的組織也可能災難性地失敗

先前對高可靠性組織的研究表明，明確的設計原則可以防止此類故障。與這些理論一致，我們的研究結果表明，許多 MAS 故障源于代理間交互中的挑戰(zhàn)，而不是單個代理的局限性。MASFT 能夠系統(tǒng)地識別這些故障，并為下一代 MAS 的設計原則提供信息。

本文的貢獻如下：

• 我們引入了MASFT，這是第一個基于經(jīng)驗的MAS 故障分類法，為理解和減輕 MAS 故障提供了一個結構化框架。

• 我們開發(fā)了一個可擴展的 LLM-as-a-judge評估流程，用于分析新的 MAS 性能和診斷故障模式。

• 我們針對代理規(guī)范、對話管理和驗證策略開展了盡力干預研究。盡管任務完成率提高了 14%，但它們未能完全解決 MAS 故障，凸顯了結構性 MAS 重新設計的必要性。

• 我們完全開源：（1）所有 150 多個帶Annotator的 MAS 對話軌跡、（2）可擴展的 LLM-as-a-judge 評估流程和 150 多個軌跡上的 LLM Annotator，以及（3）15 個選定軌跡上的詳細專家Annotator。

2.2 代理系統(tǒng)設計原則

一些研究強調了構建強大的代理系統(tǒng)的挑戰(zhàn)，并提出了新的策略（通常用于單代理設計）來提高可靠性。例如，Anthropic 的博客文章強調了模塊化組件（如快速鏈接和路由）的重要性，而不是采用過于復雜的框架。同樣，Kapoor等人表明，復雜性可能會阻礙代理系統(tǒng)在現(xiàn)實世界中的應用。我們的工作通過系統(tǒng)地研究 MAS 中的故障模式、提供說明 MAS 故障原因的分類法以及為代理系統(tǒng)設計提出符合這些見解的解決方案來擴展這些見解。

2.3 LLM 系統(tǒng)中的故障分類

盡管人們對 LLM Agent的興趣日益濃厚，但對其失效模式的專門研究卻出奇地有限。與Bansal 等人的研究對代理系統(tǒng)中人機交互中面臨的挑戰(zhàn)進行了分類，我們的貢獻代表了研究 MAS 故障模式的開創(chuàng)性努力。這突出了未來研究的必要性，即開發(fā)強大的評估指標、識別常見的故障模式以及設計緩解策略以提高 MAS 的可靠性。

3研究方法 圖 3： 系統(tǒng)研究 MAS 的方法工作流程，包括識別故障模式、開發(fā)分類法、通過Annotator間一致性研究進行迭代細化，達到 Cohen's Kappa 分數(shù) 0.88。

本節(jié)介紹了我們識別 MAS 中的主要故障模式并建立故障模式結構化分類的方法。圖3概述了此工作流程。

為了系統(tǒng)地、無偏見地發(fā)現(xiàn)故障模式，我們采用了GT理論方法，這是一種定性研究方法，它直接從經(jīng)驗數(shù)據(jù)構建理論，而不是測試預定義的假設。GT 的歸納性質使故障模式的識別有機地出現(xiàn)。我們通過理論抽樣、開放式編碼、持續(xù)比較分析、備忘和理論化迭代收集和分析 MAS 執(zhí)行軌跡。

在獲得 MAS 軌跡并討論初步發(fā)現(xiàn)后，我們通過收集觀察到的故障模式得出初步分類法。為了完善分類法，我們進行了inter-annotator一致性研究，通過添加、刪除、合并、拆分或修改定義來迭代調整故障模式和故障類別，直到達成共識。此過程反映了一種學習方法，其中分類法不斷完善，直到實現(xiàn)穩(wěn)定性，通過 Cohen 的 Kappa 分數(shù)通過Annotator間一致性來衡量。此外，為了實現(xiàn)自動故障識別，我們開發(fā)了一個基于 LLM 的Annotator并驗證其可靠性。

3.1 數(shù)據(jù)收集與分析

我們采用理論抽樣以確保所識別的MAS 的多樣性，以及要收集數(shù)據(jù)的任務集 (MAS 執(zhí)行軌跡)。 這種方法根據(jù) MAS 的目標、組織結構、實施方法和底層代理角色的變化來指導MAS 的選擇。 對于每個MAS，選擇的任務都代表系統(tǒng)的預期能力，而不是人為挑戰(zhàn)的場景。 例如，如果系統(tǒng)報告了特定基準或數(shù)據(jù)集的性能，我們會直接從這些基準中選擇任務。 分析的 MAS 涵蓋多個領域和上下文，如表1和附錄B所述。 在收集 MAS 軌跡后，我們應用開放式編碼來分析我們收集的代理-代理和代理-環(huán)境交互的痕跡。開放編碼將定性數(shù)據(jù)分解為標記的段，允許Annotator創(chuàng)建新的代碼并通過備忘錄記錄觀察結果，從而實現(xiàn)Annotator之間的迭代反思和協(xié)作。具體來說，Annotator識別他們遇到的故障模式，并系統(tǒng)地將他們創(chuàng)建的新代碼與現(xiàn)有代碼進行比較，這在GT中也稱為持續(xù)比較分析。這種故障模式識別和開放編碼的迭代過程一直持續(xù)，直到我們達到理論飽和，即從額外數(shù)據(jù)中不再出現(xiàn)新見解的點。通過這個過程，Annotator標記了 5 個 MAS 中的 150 多條痕跡。接下來，我們對相關的開放代碼進行分組，以揭示MASFT初始版本中的細粒度故障模式。最后，我們鏈接故障模式，形成錯誤類別的分類，如圖2所示。該過程在圖3中用點 1 和 2 表示。在提出初始分類法后，一個重要的問題是該分類法的可靠性如何，以及我們如何找到一種自動化方法來評估 MAS 故障。為此，我們進行了Annotator間一致性研究，其中三位Annotator旨在驗證、改進和最終確定最初得出的分類法。

3.2 A nnotator間一 致性研究和迭代改進

Annotator間研究主要針對驗證給定的測試或評分標準，這樣當多個不同的Annotator根據(jù)相同的評分標準Annotator同一組測試用例時，他們應該得出相同的結論。盡管我們最初根據(jù)上一節(jié)中解釋的理論抽樣和開放編碼得出了一個分類法，但仍然需要驗證該分類法的無歧義性。

對于Annotator之間的一致性，我們在初步得出分類法的基礎上進行了三輪主要討論。在第一輪中，我們從上一節(jié)中解釋的理論抽樣獲得的 150 多條軌跡中抽取了 5 條不同的 MAS 軌跡，三位Annotator使用初始分類法中的故障模式和定義對這些軌跡進行Annotator。我們觀察到，Annotator在第一輪中達成的一致性非常弱，Cohen's Kappa 得分為 0.24。接下來，這些Annotator對分類法進行改進。這涉及迭代地更改分類法，直到我們達成共識，即每種故障模式是否存在于某種故障模式中，以及是否存在于所有 5 條收集到的軌跡中。在迭代改進中，我們根據(jù)需要更改故障模式的定義，將它們分解為多個細粒度故障模式，將不同的故障模式合并為一種新的故障模式，添加新的故障模式或從分類法中刪除故障模式。

這一過程可以比作一項學習研究，其中不同的代理（這次是人類Annotator）獨立地從共享狀態(tài)空間收集觀察結果，并彼此分享他們的發(fā)現(xiàn)以達成共識。此外，為了不陷入將訓練數(shù)據(jù)用作測試數(shù)據(jù)的謬誤，當我們在第 1 輪結束時進行細化研究時，我們在第 2 輪中測試了新的Annotator間一致性和分類法在另一組軌跡中的性能。在下一階段（第 2 輪），我們采樣另一組 5 條軌跡，每條軌跡來自不同的 MAS。然后，Annotator在第一次嘗試中就達成了很好的一致，彼此之間的平均 Cohen's Kappa 分數(shù)為 0.92。受此啟發(fā)，我們進入第 3 輪，在那里我們采樣了另一組 5 條軌跡并再次使用相同的最終分類法進行Annotator，其中獲得了 0.84 的平均 Cohen's Kappa 分數(shù)。請注意，Cohen's Kappa 分數(shù)超過 0.8 被認為是強的，超過 0.9 被認為是幾乎完美的對齊。

受分類法可靠性的啟發(fā)，我們提出了以下問題：我們能否想出一種自動化的方法來Annotator軌跡，以便開發(fā)人員或用戶可以將此自動化管道與我們的分類法一起使用，以了解其模型失敗的原因？因此，我們使用 LLM-as-a-judge 管道開發(fā)了一個自動化MASFT Annotator，我們將在第3.3節(jié)中對其進行描述。

3.3 LLM A nnotator

在開發(fā)了我們的分類法MASFT并完成了Annotator之間的一致性研究之后，我們的目標是想出一種自動化的方法，使用我們的分類法來發(fā)現(xiàn)和診斷 MAS 軌跡中的故障模式。為此，我們開發(fā)了一個 LLM-as-a-judge 管道。在這個策略中，我們?yōu)?LLM 提供了一個系統(tǒng)提示，其中包括我們MASFT中的故障模式、它們的詳細解釋以及這些故障模式的一些示例。在該策略中，我們決定使用 OpenAI 的 o1 模型，并且嘗試了不提供上述示例和提供示例的情況?；诘?.2節(jié)中提到的第 3 輪Annotator間一致性研究的結果，我們測試了 LLM Annotator的成功性，如表2所示。由于我們達到了 94% 的準確率和 77% 的 Cohen's Kappa 值，我們認為 LLM Annotator（提供上下文示例）是一個可靠的Annotator。受此結果的啟發(fā)，我們讓 LLM Annotator標記我們收集的 150+ 條痕跡語料庫中的其余痕跡，其結果如圖4所示，最終的分類法與故障模式分布如圖2所示。

4研究結果

圖4：按類別和系統(tǒng)分布的故障模式。

我們對一系列不同的 MAS 進行的扎根理論研究和Annotator間一致性研究促成了圖2中所示的MASFT的開發(fā)。MASFT 組織了 3 個總體故障類別，確定了 MAS 在執(zhí)行過程中可能遇到的 14 種細粒度故障模式。MASFT 還將MAS執(zhí)行分為與代理相關的 3 個階段：執(zhí)行前、執(zhí)行和執(zhí)行后，確定了每種細粒度故障模式可能發(fā)生的 MAS 執(zhí)行階段。

FC1. 規(guī)范和系統(tǒng)設計失敗。由于系統(tǒng)架構設計缺陷、對話管理不善、任務規(guī)范不明確或違反約束以及對代理角色和職責的定義或遵守不充分而導致的失敗

在 MAS 中，任務失敗通常源于不完整或模糊的指令。然而，即使給出了明確的規(guī)范，MAS 也可能與用戶輸入不一致。此類失敗的一個例子是違反任務規(guī)范。當被要求設計一款以經(jīng)典國際象棋走法符號（如“Ke8”、“Qd4”）作為輸入的雙人國際象棋游戲時，MAS 框架 ChatDev 會生成一款以 (x1, y1)、(x2, y2) 作為輸入的游戲，這些符號表示棋盤上棋子的初始坐標和棋子的最終坐標，因此無法滿足初始要求。此類失敗的另一種模式是未遵守角色規(guī)范。例如，在 ChatDev 的需求分析階段，CPO 代理偶爾會通過單方面定義產(chǎn)品愿景并做出最終決策來承擔 CEO 的角色。

FC2. 代理間錯位。由于溝通不暢、協(xié)作不力、代理間行為沖突以及逐漸偏離初始任務而導致的失敗。

圖5： 電話代理未能向主管傳達 API 規(guī)范和登錄用戶名要求。在對話的另一端，主管代理也未能澄清登錄詳細信息。經(jīng)過幾次來回嘗試后，主管代理將任務標記為失敗。

多智能體系統(tǒng)經(jīng)常遭受對話效率低下的問題，智能體會進行無效的交流，消耗計算資源卻沒有取得有意義的進展。例如，在涉及創(chuàng)建類似 Wordle 的游戲的 ChatDev 跟蹤中，程序員智能體在七個周期內與多個角色（CTO、CCO 等）進行了交互，但未能更新初始代碼。由此產(chǎn)生的游戲可玩但缺乏穩(wěn)健性，只有五個簡單的單詞，破壞了可重玩性并導致額外的通信輪次浪費。此類別中的另一種故障模式是智能體隱瞞有價值的信息。例如，在圖 5 中，主管智能體指示電話智能體使用電子郵件 ID 作為用戶名來檢索聯(lián)系信息。電話智能體在閱讀文檔并發(fā)現(xiàn)正確的用戶名應該是電話號碼后，仍然使用錯誤的憑據(jù)繼續(xù)操作，導致錯誤。

FC3. 任務驗證與終止。由于執(zhí)行過早終止而導致的故障，以及缺乏足夠的機制來保證交互、決策和結果的準確性、完整性和可靠性。

MAS 可能在開發(fā)時沒有經(jīng)過專門的驗證步驟，或者可能包含無法有效執(zhí)行其任務的驗證代理。例如，在涉及國際象棋游戲實現(xiàn)的 ChatDev 場景中，驗證代理僅檢查代碼是否編譯，而不運行程序或確保符合國際象棋規(guī)則。國際象棋是一種成熟的游戲，具有廣泛的規(guī)范、規(guī)則和實現(xiàn)，可在線輕松獲取。即使是簡單的檢索也應該直觀地防止微不足道的故障，例如接受格式錯誤的輸入。但是，如果沒有適當?shù)尿炞C，無效輸入處理或格式錯誤的接口等缺陷就會持續(xù)存在，導致游戲無法玩。

圖4顯示了所研究 MAS 中細粒度故障模式以及故障類別的分布。不同的顏色代表MASFT中的不同故障類別，不同的色調代表類別內不同的細粒度故障模式。我們強調，沒有任何單一錯誤類別占主導地位，這表明故障發(fā)生具有多樣性，并且用于對故障進行分類的分類法具有穩(wěn)健性。此外，我們注意到，正如預期的那樣，不同的 MAS 表現(xiàn)出不同的故障類別和模式分布。例如，與規(guī)范和驗證問題相比，AG2 的代理間錯位實例較少，而 ChatDev 遇到的驗證問題比規(guī)范和代理間錯位挑戰(zhàn)少。這些差異源于不同的問題設置，這會影響系統(tǒng)拓撲設計、通信協(xié)議和交互管理。反過來，這些因素塑造了具有自身優(yōu)勢和劣勢的系統(tǒng)。

打開網(wǎng)易新聞 查看精彩圖片

圖6：MAS 故障類別相關矩陣。

圖6突出顯示了MASFT中不同故障類別之間的相關性。觀察到的相關性不是特別強，它們表明所提出的分類法是一個合理的分類框架。此外，這還表明故障不是孤立事件；相反，它們可能具有連鎖效應，可以影響其他故障類別。

圖 7： MAS 故障模式相關矩陣

4.3 都是驗證者的錯嗎？

我們已經(jīng)確定了 MAS 中的一系列故障模式。然而，可以說，歸根結底，每個故障都可能源于缺乏適當?shù)尿炞C或不正確的驗證流程。如果我們假設驗證代理功能完美，那么所有故障都是可檢測的，因此可以避免。

在我們的研究中，我們專注于系統(tǒng)可以有效受益于驗證過程結果的情況中的驗證問題。但是，我們還會檢查在最終驗證步驟之前發(fā)生的其他故障模式。在許多情況下，我們可以將驗證視為防止故障的最后一道防線。這使我們得出結論，雖然許多問題確實可以追溯到驗證不足，但并非每個問題都可以完全歸因于這一因素。其他因素，例如規(guī)格不佳、設計不足、溝通效率低下，也會導致故障。因此，全面理解和解決 MAS 故障的方法必須考慮更廣泛的因素，而不僅僅是驗證缺陷。

4.4 MASFT 故障模式違反 HRO 定義特征

盡管我們遇到了一些常見的 LLM 故障模式，例如文本重復，但我們將它們排除在MASFT之外，因為這些問題并非專門與MAS 有關，甚至可能在單LLM 調用管道中發(fā)生。另一方面，我們發(fā)現(xiàn)MAS 面臨與復雜人類組織類似的問題的證據(jù)，因為故障模式與人類組織中觀察到的常見故障模式一致。Roberts & Rousseau (1989)確定了高可靠性組織 (HRO) 共有的八個主要特征。 通過 GT 發(fā)現(xiàn)的MASFT沒有任何先前的偏見，包括幾種與Roberts & Rousseau確定的 HRO 獨特特征相關的故障模式具體來說，“ FM1.2：不遵守角色規(guī)范”

代理試圖超越其角色，違反了 HRO 特征“極端層級分化”。同樣，“FM2.2 ：未能要求澄清”破壞了“尊重專業(yè)知識”。MASFT中確定的故障模式直接違反了 HRO 特征，這驗證了MASFT的適用性，以及需要受 HRO 啟發(fā)的非平凡干預措施。例如，為了防止 MAS 中發(fā)生“FM1.2：不遵守角色規(guī)范”，編排和角色分配可以強制層級分化。

5邁向更好的多智能體 LLM 系統(tǒng)

在本節(jié)中，我們討論了一些使 MAS 更能抵御故障的方法。我們將這些策略分為兩大類：（i）戰(zhàn)術方法，（ii）結構策略。戰(zhàn)術方法涉及針對特定故障模式量身定制的直接修改，例如改進提示、代理網(wǎng)絡拓撲和對話管理。在第6節(jié)中，我們在兩個案例研究中試驗了這些方法，并證明這些方法的有效性并不一致。這促使我們考慮第二類策略，它們是具有全系統(tǒng)影響的更全面的方法：強驗證、增強通信協(xié)議、不確定性量化以及內存和狀態(tài)管理。這些策略需要更深入的研究和細致的實施，并且仍然是有待未來探索的開放研究課題。表3了解我們提出的不同解決方案策略與故障類別之間的映射。

5.1 戰(zhàn)術方法

此類別包括與改進提示和優(yōu)化代理組織和交互相關的策略。MAS 代理的提示應提供清晰的指令描述，并應明確指定每個代理的角色。提示還可以明確角色和任務，同時鼓勵主動對話。如果出現(xiàn)不一致，代理可以重新參與或重試，如下提示詞所示。完成復雜的多步驟任務后，在提示中添加一個自我驗證步驟，通過重述解決方案、檢查條件和測試錯誤來追溯推理過程。然而，它可能會遺漏缺陷、依賴模糊的條件，或者不切實際。此外，可以通過定義對話模式和設置終止條件來強化明確的角色規(guī)范。采用簡單、定義明確的代理（而不是復雜、多任務的代理）的模塊化方法可以提高性能并簡化調試。群體動力學還使多智能體系統(tǒng)的其他有趣可能性成為可能：不同的智能體可以提出各種解決方案，采用多智能體策略模擬學術同行評審過程，以捕捉更深層次的不一致之處。

Prompt：
您的角色是逐步批判性地評估其他代理提出的解決方案并提供最終解決方案。
1. **解決方案要求**：在做出任何決定之前，請確保您已收到來自代理代碼執(zhí)行器和代理問題解決器的解決方案。如果缺少任何建議的解決方案，請不要得出任何結論；而是建議下一位發(fā)言者，說明：建議的下一位發(fā)言者：_建議的代理名稱_ 。
2. **避免假設**：注意原始問題陳述中提供的變量與代理假設的變量。**假設值對解決方案無效** ，并且可能導致不準確。切勿以假設值為基礎解決問題。始終以明確給出的變量為基礎解決問題，以確保正確性。如果由于缺少信息而導致問題無法解決，則返回：** SOLUTION_FOUND \\ boxed { ' None ' } ** 。
3. **評估相互沖突的解決方案**：如果討論過程中出現(xiàn)不同的答案，請根據(jù)您的證據(jù)選擇最合適的解決方案或開展進一步的討論以澄清。
4. **最終解決方案聲明**：當您對最終解決方案有信心時，請按如下方式返回：** SOLUTION_FOUND \\ boxed { _solution_value_here_ } ** 。確保只有數(shù)值放在\\ boxed { }內；任何附帶的文本都應放在外面

另一套交叉驗證的策略方法包括多次 LLM 調用，并進行多數(shù)表決或重采樣，直到驗證完成。然而，這些看似簡單的解決方案往往被證明是不一致的，這與我們的案例研究的結果相呼應。這強調了需要更強大的結構化戰(zhàn)略，如下節(jié)所述。

5.2 結構性策略

除了我們上面討論的戰(zhàn)術方法之外，還需要更多復雜的解決方案來塑造手頭的 MAS 結構。我們首先觀察驗證過程和驗證代理在多代理系統(tǒng)中的關鍵作用。我們的Annotator表明，薄弱或不充分的驗證機制是導致系統(tǒng)故障的重要因素。雖然單元測試生成有助于軟件工程中的驗證, 創(chuàng)建一個通用的驗證機制仍然具有挑戰(zhàn)性。即使在編碼中，覆蓋所有邊緣情況也很復雜，即使對于專家來說也是如此。驗證因領域而異：編碼需要全面的測試覆蓋，QA 需要經(jīng)過認證的數(shù)據(jù)檢查，并且推理受益于符號驗證?？珙I域適應驗證仍然是一個持續(xù)的研究挑戰(zhàn)。

驗證的補充策略是建立標準化的通信協(xié)議。基于 LLM 的代理主要通過非結構化文本進行通信，這會導致歧義。明確定義意圖和參數(shù)可增強一致性，并在交互期間和之后進行正式的一致性檢查。引入了多智能體圖注意力機制，利用圖注意力機制來模擬智能體交互并增強協(xié)調性。同樣提出了注意力溝通，使代理能夠有選擇地關注相關信息。同樣，開發(fā)一種學習選擇性通信協(xié)議，以提高合作效率。

另一個重要的研究方向是使用強化學習對 MAS 代理進行微調。代理可以使用特定于角色的算法進行訓練，獎勵與任務一致的操作并懲罰效率低下的行為。MAPPO優(yōu)化了代理對定義角色的遵守。同樣，SHPPO在應用異構決策層之前使用潛在網(wǎng)絡來學習策略。Optima通過迭代強化學習進一步提升溝通效率與任務效果。

另一方面，將概率置信度度量納入代理交互可以顯著提高決策和通信可靠性。從 Horvitz 等人提出的框架中汲取靈感。代理可以被設計為只有當其置信度超過預定義的閾值時才采取行動。相反，當置信度較低時，代理可以暫停以收集更多信息。此外，系統(tǒng)可以從自適應閾值中受益，其中置信度閾值是動態(tài)調整的。

盡管記憶和狀態(tài)管理通常被視為單智能體屬性，但對于多智能體交互來說，它們至關重要，可以增強上下文理解并減少交流中的歧義。然而，大多數(shù)研究都集中在單智能體系統(tǒng)上。MemGPT引入了受操作系統(tǒng)啟發(fā)的上下文管理，用于擴展上下文窗口，而TapeAgents使用結構化、可重播的日志（“磁帶”）來迭代記錄和改進代理操作，促進動態(tài)任務分解和持續(xù)改進。

6案例研究

在本節(jié)中，我們將介紹應用一些戰(zhàn)術方法的兩個案例研究。

6.1案例研究 1：AG2 - MathChat

在本案例研究中，我們使用 AG2 中的 MathChat 場景實現(xiàn)作為我們的基線，其中學生代理與能夠執(zhí)行 Python 代碼的助理代理協(xié)作解決問題。為了進行基準測試，我們從 GSM-Plus 數(shù)據(jù)集中隨機選擇了 200 個練習, GSM8K 的增強版本并添加各種對抗性擾動。第一種策略是改進原始提示，使其結構清晰，并增加一個專門用于驗證的新部分。詳細的提示在附錄E.1和E.2中提供。第二種策略是將代理配置細化為一個更專業(yè)的系統(tǒng)，該系統(tǒng)具有三個不同的角色：問題解決者，使用思路鏈方法解決問題，不使用工具；編碼員，編寫并執(zhí)行 Python 代碼以得出最終答案；驗證者，負責審查討論并批判性地評估解決方案，要么確認答案，要么引發(fā)進一步的辯論。在這種情況下，只有驗證者才能在找到解決方案后終止對話。為了評估這些策略的有效性，我們使用兩個不同的 LLM（GPT-4 和 GPT-4o）在三種配置（基線、改進的提示和新拓撲）中進行了基準測試實驗。我們還進行了六次重復實驗，以評估結果的一致性。表4總結了結果。

表 4：案例研究準確度比較。在 AG2 下，使用 GPT-4 和 GPT-4o 報告 GSM-Plus 結果；在 ChatDev 下，報告 ProgramDev 和 HumanEval 的結果。

表4的第二列顯示，使用 GPT-4，經(jīng)過驗證的改進提示明顯優(yōu)于基線。但是，新拓撲并沒有產(chǎn)生相同的改進。Wilcoxon 檢驗的 p 值為 0.4，表明小幅提升并不具有統(tǒng)計學意義。對于 GPT-4o（表4的第三列），在將基線與改進的提示和新拓撲進行比較時，Wilcoxon 檢驗得出的 p 值為 0.03，表明統(tǒng)計上有顯著的改進。這些結果表明，優(yōu)化提示和定義明確的代理角色可以減少失敗。但是，這些策略并不是通用的，并且它們的有效性會因底層 LLM 等因素而異。

6.2案例研究2：ChatDev

ChatDev模擬了一個多智能體軟件公司，其中不同的智能體具有不同的角色規(guī)范，例如 CEO、CTO、軟件工程師和審閱者，他們試圖協(xié)作解決軟件生成任務。為了解決我們在跟蹤中經(jīng)常觀察到的挑戰(zhàn)，我們實施了兩種不同的干預措施。我們的第一個解決方案是改進特定于角色的提示以強制執(zhí)行層次結構和角色遵守。例如，我們觀察到CPO 過早結束與 CEO 的討論而沒有完全解決約束的情況。為了防止這種情況，我們確保只有高級代理才能完成對話。此外，我們增強了驗證者角色規(guī)范，以專注于特定于任務的邊緣情況。這些干預措施的詳細信息位于F節(jié)中。第二個解決方案嘗試涉及對框架拓撲的根本更改。我們將框架的拓撲從有向無環(huán)圖 (DAG) 修改為循環(huán)圖?，F(xiàn)在，只有當CTO 代理確認所有評論都得到適當滿足時，該過程才會終止，并具有最大迭代截止以防止無限循環(huán)。這種方法可以實現(xiàn)迭代細化和更全面的質量保證。我們在兩個不同的基準測試中測試了我們的干預措施。第一個是自定義生成的 32 個不同任務集（我們稱之為 ProgramDev），我們要求框架生成各種程序，從“為我編寫一個可在終端上玩的雙人象棋游戲”到“為我編寫一個 BMI 計算器”。另一個基準是 OpenAI 的 HumanEval 任務。我們在表4中報告了我們的結果。請注意，盡管我們的干預措施成功地提高了框架在不同任務中的性能，但它們并沒有帶來實質性的改進，需要我們在第5.2節(jié)中列出的更全面的解決方案。

7結論

在本研究中，我們首次系統(tǒng)地研究了基于 LLM 的多智能體系統(tǒng)的故障模式，在GT理論的指導下，我們收集并分析了 150 多個軌跡，并通過Annotator間研究迭代地完善我們的分類法并進行驗證。我們確定了 14 種細粒度故障模式，并將它們歸入 3 種不同的故障類別，為未來 MAS 的研究提供了標準。我們還提出了一種 LLM Annotator作為分析 MAS 軌跡的自動化方法，并展示了其有效性和可靠性。我們還討論了所有故障類別的兩套解決方案，即戰(zhàn)術和結構策略。在對一些戰(zhàn)術策略進行案例研究后，我們的研究結果表明，許多這些“明顯”的修復實際上存在嚴重的局限性，需要我們概述的結構策略來實現(xiàn)更一致的改進。

原文鏈接：https://arxiv.org/html/2503.13657v1