為什么多智能體不會成功？

提供AI咨詢+AI項目陪跑服務，有需要回復1

今年接觸了很多Agent的項目，怎么說呢？多數項目的表現是很差的。

其中不乏一些想要快速搶占市場的小公司，他們刻意用低價和漂亮的PPT首先打開了局面，而這對于很多慢慢打磨產品的團隊是很難受的，因為根本沒他們的生存空間與試錯場景了...

于是很多團隊也被迫卷了起來，過程中各種執行變形，其結果就是：Agent市場鬧得個厲害，但實際好用的應用卻很少...

于是稍微總結下各個AI Agent產品失敗的原因，無非兩個：

1. 第一，模型使用錯誤，過于迷信模型能力，覺得AI無所不能，也輕視了提示詞工程的難度，最終產品一直在60分徘徊；
2. 第二，數據跟不上，更多的產品，數據一塊積累太差，RAG分塊和微調一塊做得很差，進一步導致模型表現很差，這也很正常，吃垃圾數據的模型拉不出黃金的屎；

同時，我也在關注業內的動態，發現有篇論文寫得不錯：為什么多智能體總是失?。?strong>Why Do Multi-Agent LLM Systems Fail? （https://arxiv.org/abs/2503.13657）

他給出了一個結果，5種主流Agent框架的各種應用的表現情況：

1. MetaGPT，模擬軟件公司中的不同角色，執行標準操作程序（SOP），用于創建開放式的軟件應用；
2. ChatDev，模擬不同的軟件工程階段（如設計、編碼、質量保證），通過模擬軟件工程公司中的角色；
3. HyperAgent，模擬一個軟件工程團隊，使用中央計劃者(agent)與專業化的子代理（如導航員、編輯器、執行器）進行協調；
4. AppWorld，調用專業化的工具服務（例如Gmail、Spotify等），通過一個主管協調執行跨服務任務；
5. AG2，提供一個開源的編程框架，用于構建和管理代理系統及其交互；

PS：從這個角度來看，國內外對于Agent的使用或者說發力方向還是有很大的不同

接下來，我們來簡單讀讀這篇文章。

摘要

盡管人們對多智能體系統 (Multi-Agent LLM Systems) 的熱情日益高漲，即多個 LLM 智能體協作完成任務，但與單智能體框架相比，MAS 在熱門基準測試中的性能提升仍然微乎其微。

這一差距凸顯了分析阻礙 MAS 有效性的挑戰的必要性。

論文對 MAS 挑戰進行了全面的研究，他分析了五種流行的 MAS 框架，涉及 150 多個任務，每次任務包括 15000 多行對話記錄，涉及六位專家人工參與。

確定了 14 種獨特的故障模式，并提出了適用于各種 MAS 框架的綜合分類法，他們將系統失敗的原因歸類為三種：

1. 系統設計錯誤；
2. Agent之間交互錯誤；
3. 任務驗證與終止錯誤；

優化方式無非兩種：改進代理角色的規范和增強編排策略。

這里翻譯翻譯就是：提示詞優化以及數據層面的一些優化策略。接下來看看實際的情況。

Agents常見錯誤

當前Agent平臺，倡導的還是減少工作流，讓模型自己玩的策略，也就是依賴于模型的規劃能力自建Workflow或者說SOP：

理論上，這是一個命令行的事情，AI就自主像員工一樣工作起來了：

1. 任務拆解：將復雜任務拆解成多個模塊（例如，程序員、測試員、設計師分別負責不同部分）。
2. 并行處理：通過分工合作，提升效率。
3. 協作與討論：各個智能體共同討論，找出最優解。

然而，現實中，多智能體系統常常未能達到預期效果，甚至在一些情況下，比簡單的單一AI系統更差。

例如，在軟件開發任務中，某些MAS的準確率低至25%，遠不及單一AI或簡單的重復調用方式。就像組建了一支全明星球隊，但比賽時卻各自為戰，無法形成有效的協作。

研究人員對150多個任務記錄進行了分析，發現失敗的原因主要可以歸為三大類：

一、角色混亂

在理想的MAS中，每個智能體都有明確的角色分工，例如產品經理、開發人員、測試員等。

然而，在實際操作中，許多智能體往往會跨越自己的角色范圍，導致效率低下和錯誤的發生。

比如，在需求收集任務中，本應負責收集需求的CPO（首席產品官）卻越權決定了產品方向，打亂了正常的流程，他的具體表現為：

1. 智能體不遵守崗位職責（例如，測試員參與編碼工作）；
2. 重復性勞動消耗了大量的計算資源；
3. 忘記了之前的討論內容，導致重復工作；

其實，所有的這一切都可以回歸到模型問題的根因：幻覺...

二、溝通障礙

Agent之間的正常通信是任務成功的基礎，但多Agent在這方面卻表現得不好。

比如在一個API集成任務中，手機助手代理錯誤地使用了一個郵箱作為登錄憑證，而正確的應該是電話號碼，這主要源于“溝通不暢”，會加劇這些問題的因素在于：

1. 討論內容偏離了任務目標，浪費了大量時間；
2. 智能體沒有共享關鍵信息，影響了決策；
3. 無視其他智能體的建議，或者在不確定時不主動尋求幫助；

三、驗收漏洞

在MAS中，任務的驗證是一個至關重要的環節，但許多系統缺乏有效的驗證機制，導致任務的提前或不完整完成。

比如，在開發一個象棋游戲的任務中，驗證代理只檢查了代碼是否能運行，但沒有確保游戲遵循象棋規則。

類似這種任務在未完成所有步驟的情況下就被過早結束；缺乏對關鍵步驟的驗證，導致錯誤被遺漏。在Manus或者最近發布的扣子空間中都經常發生。

錯誤原因

這些故障模式與人類組織中的問題驚人地相似。MAS的失敗往往違背了高可靠性組織（HRO）的原則。

高可靠性組織通常能夠在高風險的環境中完美運作，避免了類似的失敗。以下是MAS失敗的常見規律：

1. 角色混亂 → 破壞層級分工：當智能體不遵循自己的角色定義時，會打亂系統的層級結構，使得協作變得混亂。
2. 信息隱瞞 → 忽視專業建議：智能體沒有共享重要信息，導致決策失誤。
3. 敷衍的驗證 → 缺乏質量把控：沒有有效的驗證機制，導致任務結果不可靠。

這些失敗表明，需要一個明確的結構和質量控制機制來確保任務的順利完成。

而解決方案也很簡單，也就是Agent框架宣稱的那樣：為模型加上更多的控制！

1. 角色明確：為每個智能體設定明確的職責范圍，避免跨界行為。
2. 交叉驗證：實施機制讓智能體之間進行互相驗證，類似于同行評審過程。
3. 檢查清單：強制執行關鍵步驟的驗證，確保任務完成的質量。
4. 結果：雖然這些戰術調整顯著提升了部分MAS的表現（提高了14%），但效果仍然不足以支撐大規模的實際部署。

這與我們之前做的多角色解決醫療幻覺是類似的：

因為我原來是醫療行業的，真實場景的方式比較敏感不能放出來，在網上找了一篇不錯的文章做說明：《醫療 CoT 全面分析》

你是臨床問診專家，有強大的臨床思維和海量的醫學疾病的模式識別，你和頂尖醫生在這次案例中對決，請拿出你的全部實力！

必須遵循的原則，如下：
1. **禁止跳過結構**: 每個分析師必須完整填寫所有規定部分，不得省略任何一個環節

2. **強制回溯要求**: 
   - 每輪下，每位分析師必須明確評估新要素對其初始判斷的影響
   - 必須使用格式："針對{具體新要素}，我的判斷需要修正，因為..."或"我的判斷不需修正，因為..."

3. **真正的迭代**:
   - 禁止簡單重復第一輪觀點
   - 每輪必須有實質性的思考進展
   - 如果需要修正，必須明確指出與初始判斷的差異
### 1. 引入問題

- 明確要解決的問題本身。  


- 全面的癥狀檢查-疾病網絡：把所有癥狀、檢查結果要組成單起點（如流鼻涕）、多個實體對組合（如流鼻涕 + 頭疼組合，注意不重不漏），再分別分析 -> 分別提示什么？-> 網絡組合在一起是否有發現新的隱性關系？

	比如，用戶輸入是一段關于多個癥狀、檢查結果的描述：流鼻涕、頭疼、發熱、咳嗽……
	請將其中所有出現的實體（如疾病、癥狀、體征、檢查、指標等）全部提取出來，不得遺漏。
	然后，針對每個實體都進行逐兩兩組合，例如(流鼻涕+頭疼)、(流鼻涕+發熱)、(頭疼+發熱)、(頭疼+咳嗽)……
	最后，請給出單個實體分析、每對組合各自可能的提示或結論。
	【注意1】請務必列出所有實體，并給出覆蓋所有實體的兩兩組合，不要省略?！?	【注意2】當用戶文本中提取到的實體數量≥3，你需要在兩兩組合基礎上，再對三元、四元或更多元素的組合進行綜合分析。
	【注意3】當實體很多時，所有組合數量可能過大。你可聚焦臨床最具意義、或用戶文本中最突出的關鍵組合，進行更深層的臨床思路推演，幫助用戶發現多重癥狀/檢查/疾病同時出現時的潛在含義，進一步探尋隱性關系、罕見病或多系統交叉等關鍵點。

- 向所有分析師公布問題背景和已知條件（包括全面的癥狀檢查-疾病網絡）。

### 2. **10 位分析師分角色，分別思考"第一輪"**

#### 分析師 1（從問題本身形態出發）  
- 必須分析癥狀、檢查結果與特定解剖結構的關系，所以，推理每個癥狀、檢查結果有什么提示。  
- 根據自己前面的分析，給出 5 種可能診斷，可能性從大到小排序。
	**解決寬泛模糊大標簽和相似癥狀**：一定要深入具體的疾病上，使用假設推演，不能停留在大標簽上。 如感染，要定位到具體xx病原體上。

#### 分析師 2（從環境出發）  
- 問題如果在不同環境（季節、地域、社會環境、家庭環境、集體場所），會如何影響結果？  
- 考慮環境因素對癥狀表現的可能影響和相關流行病學信息，所以會有什么提示？  
- 根據自己前面的分析，結合用戶的所有特征（如年齡、癥狀、體征、檢查結果等），給出 5 種可能診斷，可能性從大到小排序。
		**解決寬泛模糊大標簽和相似癥狀**：一定要深入具體的疾病上，使用假設推演，不能停留在大標簽上。 如感染，要定位到具體xx病原體上。

......

這里內容很長，大家自己去原文感受吧...

其實如果要用模型自己完成多Agent的協作，很多策略需要更加清晰。

我的一些看法

說實話，論文讀起來還是比較晦澀的，很多地方只能隱約的知道他想要表達什么，但總的來說，還是有一定收獲，這里就結合我的理解給一些看法：

一、大模型沒那么強

RL 之父 Rich Sutton在 2019 年的文章《苦澀的教訓》

現在市面上有一種說法是：模型的通用能力，正在取代現在那些復雜的 Workflow。垂直模型是在開歷史倒車...

怎么說呢，這個在我看來可能是錯誤的，因為知識的有損性。

知識/數據是對真實世界的描述，就簡單一個事物，事實上我們平時只會關注他不到1/10的部分，以糖尿病為例：

我們討論的最多的是其癥狀和藥物，文化經濟模塊很少會涉及，這里造成的結果就是數據殘缺性與知識表征瓶頸。

比如醫生在實際診斷過程中，不僅依賴臨床指南，還有大量的內化知識，包括：

1. 患者微表情解讀（疼痛忍耐度）；
2. 社會經濟因素權衡（治療方案可行性）；
3. 倫理判斷（生命質量 vs 延長壽命）；

這是當前AI難以跨越的困局：隱性知識難以結構化，導致訓練數據本質殘缺。

輸入不足，勢必導致輸出不足，這是大模型底層缺陷所致

AlphaGo的成功建立在圍棋規則完全透明、狀態空間有限的基礎上。而真實醫療場景存在：

1. 模糊邊界（癥狀相似的不同疾?。?；
2. 動態演化（患者病情突變）；
3. 價值沖突（不同科室意見相左）；

這類開放性問題需要元認知能力（反思自身決策局限），而當前AI仍停留在“統計擬合”層面。

綜上，RL 之父所謂的算力碾壓需要一個大前提：算力需作用于正確架構。

若基礎模型無法表征某類知識（如醫學倫理），單純堆算力可能陷入“自以為是又嚴密而精準的錯誤”。

而GPT的預訓練是基于詞序列的條件概率建模，其核心是通過海量文本學習在特定上下文中，下一個詞的概率分布。

所有這一切都在表述一個問題：大模型沒那么強，他只能做有限的工作，暫時各種表現得很好的場景如發發郵件、規劃下旅游路線、寫個游戲腳本全部是有限世界的水平，這并不代表他在無限時間里面玩得轉！

二、模型是提示詞

雖然我們在使用提示詞讓模型產出我們需要的內容，但我想表達的是：其實模型產出的才是提示詞。

或者換個描述，模型產出的是專業術語，是對一段文字的精煉，我們要做的是根據這個精煉的提示詞，去本地知識庫里面找到最應該表達的部分。

這里的原因是，在第一點我們說清楚了模型在訓練階段，數據可能只能表達真實世界的60%，但這并不表示模型是一精準的數據庫！

反而，模型的輸入輸出都是基于概率的玩法，所以我們一定要基于RAG技術對其進行校準、增強。

將模型用對是做好Agent設計的前提，不要妄想將大模型變成數據記憶的大腦，人類在記憶一塊也沒有那么靠譜。

三、垂直模型是下一個方向

所謂垂直大模型，可以是用行業數據進行微調的公司，也可以是基于大量算法數據調優過后的模型。

垂直領域的玩家當前多半基于Workflow自己玩，而類似DeepResearch、Genspark、Agent、Manus甚至門檻更高的Coze這種玩家當然是希望：你們什么都別做，等我好了，就用我的！

于是，大家都在以一種遠離垂直模型的方向在發展，只不過就算宣稱減少控制的Agent產品也在用一些方式調優。

以Genspark為例，他們發現直接抓取網絡或者完全依賴大模型只能解決簡單問題時，就有一系列改進策略了，包括：

1. 加入專業數據源（如學術、財經、旅游等）；
2. 并行搜索處理復雜問題；
3. 多代理交叉驗證信息避免幻覺；
4. 引入專門的深度調研 Agent；

特別是這點需要特別引人注意：
使用高質量數據源、專家審核內容；數據由離線 Agent 審核，確保準確性，避免信息冗雜和虛假。

雖然鼓吹的是更少的控制，更多的工具，只不過什么是工具就需要仔細揣摩了。

舉個例子，如果我現在要做醫療場景的Agent，那么我完全可以基于Workflow做基礎實現，然后開啟用戶驗證。

而當我驗證的差不多后，立馬宣傳大家都不要使用Workflow，并且馬上用DeepSeek包裝出一套Agent框架，將我的Workflow、數據全部以知識的形式內置進模型。

那么，此時這個所謂Agent框架，他到底是框架還是垂直模型呢？

綜上，垂直模型這條路雖然難點，但他一定是正確的，現在各種Agent平臺如Manus、扣子空間，都有些隔靴搔癢。

還是那句話：垂直模型發展遲緩是經濟問題不是錯誤問題。

四、記憶問題，是下一個核心

幾乎所有Agent應用，不管是基于Workflow在做的還是純Agent平臺，都在致力于解決模型的記憶問題。

其本質是在關注模型幻覺問題，如果再往前走一步，就又回到垂直模型是否必須的問題了...

記憶問題當前非常粗暴的被全部拋給了RAG，事實上這也是可以的，只不過無論是做AI知識庫還是做AI Agent的團隊，其產品體驗總是差點意思！

卡點也很清晰，多數人在數據組織一塊遇到了大量的問題，因為數據組織的背后是行業KnowHow，搞不清楚數據好壞，自然就沒法整理好數據，于是再次回到，垃圾輸入與垃圾輸出了...

只不過，記憶問題可能即將得到緩解，至少從LLama4和GPT最近的發布來說，超長上下文時代即將來臨，畢竟他們都宣稱自己提供百萬上下文呢！

所以，各個公司不要試圖去做跟模型重合的領域，想辦法組織好自有領域結構化數據，后續看看怎么在保證安全的前提下與模型互相配合吧！

......

結語

文章已經很長了，這里就不再增加篇幅了，最后還是常說的那句話：

一定要注意AI項目的非對稱性：我們可以用一周的時間做一個60分的demo，但未來半年你可能都會在為追求90分的產品而奔波！

AI產品這個東西，是不存在MVP就是結束這個事情的，而MVP可能才是真正的開始，所以，做AI產品一定要有足夠的耐心。

當前做Agent的各個公司也是如此，其實并不是多Agents會失敗，而是大家都沒準備好，推得太急咯......