為什么多Agent總是失敗,因為急躁唄…

1 評論 3142 瀏覽 5 收藏 19 分鐘

在AI領(lǐng)域,多Agent系統(tǒng)(MAS)的開發(fā)和應(yīng)用一直是熱門話題,但實際效果卻往往不盡如人意。許多團隊在嘗試構(gòu)建多Agent系統(tǒng)時,常常因為急躁和缺乏系統(tǒng)性規(guī)劃而失敗。

今年接觸了很多Agent的項目,怎么說呢?多數(shù)項目的表現(xiàn)是很差的。

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

于是很多團隊也被迫卷了起來,過程中各種執(zhí)行變形,其結(jié)果就是:Agent市場鬧得個厲害,但實際好用的應(yīng)用卻很少…

于是稍微總結(jié)下各個AI Agent產(chǎn)品失敗的原因,無非兩個:

第一,模型使用錯誤,過于迷信模型能力,覺得AI無所不能,也輕視了提示詞工程的難度,最終產(chǎn)品一直在60分徘徊;

第二,數(shù)據(jù)跟不上,更多的產(chǎn)品,數(shù)據(jù)一塊積累太差,RAG分塊和微調(diào)一塊做得很差,進一步導(dǎo)致模型表現(xiàn)很差,這也很正常,吃垃圾數(shù)據(jù)的模型拉不出黃金的屎;

同時,我也在關(guān)注業(yè)內(nèi)的動態(tài),發(fā)現(xiàn)有篇論文寫得不錯:

為什么多智能體總是失???

Why Do Multi-Agent LLM Systems Fail?

(https://arxiv.org/abs/2503.13657)

他給出了一個結(jié)果,5種主流Agent框架的各種應(yīng)用的表現(xiàn)情況:

  1. MetaGPT,模擬軟件公司中的不同角色,執(zhí)行標(biāo)準(zhǔn)操作程序(SOP),用于創(chuàng)建開放式的軟件應(yīng)用;
  2. ChatDev,模擬不同的軟件工程階段(如設(shè)計、編碼、質(zhì)量保證),通過模擬軟件工程公司中的角色;
  3. HyperAgent,模擬一個軟件工程團隊,使用中央計劃者(agent)與專業(yè)化的子代理(如導(dǎo)航員、編輯器、執(zhí)行器)進行協(xié)調(diào);
  4. AppWorld,調(diào)用專業(yè)化的工具服務(wù)(例如Gmail、Spotify等),通過一個主管協(xié)調(diào)執(zhí)行跨服務(wù)任務(wù);
  5. AG2,提供一個開源的編程框架,用于構(gòu)建和管理代理系統(tǒng)及其交互;

PS:從這個角度來看,國內(nèi)外對于Agent的使用或者說發(fā)力方向還是有很大的不同

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

摘要

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

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

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

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

  1. 系統(tǒng)設(shè)計錯誤;
  2. Agent之間交互錯誤;
  3. 任務(wù)驗證與終止錯誤;

優(yōu)化方式無非兩種:改進代理角色的規(guī)范和增強編排策略。

這里翻譯翻譯就是:提示詞優(yōu)化以及數(shù)據(jù)層面的一些優(yōu)化策略。接下來看看實際的情況。

Agents常見錯誤

當(dāng)前Agent平臺,倡導(dǎo)的還是減少工作流,讓模型自己玩的策略,也就是依賴于模型的規(guī)劃能力自建Workflow或者說SOP:

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

  • 任務(wù)拆解:將復(fù)雜任務(wù)拆解成多個模塊(例如,程序員、測試員、設(shè)計師分別負(fù)責(zé)不同部分)。
  • 并行處理:通過分工合作,提升效率。
  • 協(xié)作與討論:各個智能體共同討論,找出最優(yōu)解。

然而,現(xiàn)實中,多智能體系統(tǒng)常常未能達(dá)到預(yù)期效果,甚至在一些情況下,比簡單的單一AI系統(tǒng)更差。

例如,在軟件開發(fā)任務(wù)中,某些MAS的準(zhǔn)確率低至25%,遠(yuǎn)不及單一AI或簡單的重復(fù)調(diào)用方式。就像組建了一支全明星球隊,但比賽時卻各自為戰(zhàn),無法形成有效的協(xié)作。

研究人員對150多個任務(wù)記錄進行了分析,發(fā)現(xiàn)失敗的原因主要可以歸為三大類:

一、角色混亂

在理想的MAS中,每個智能體都有明確的角色分工,例如產(chǎn)品經(jīng)理、開發(fā)人員、測試員等。

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

比如,在需求收集任務(wù)中,本應(yīng)負(fù)責(zé)收集需求的CPO(首席產(chǎn)品官)卻越權(quán)決定了產(chǎn)品方向,打亂了正常的流程,他的具體表現(xiàn)為:智能體不遵守崗位職責(zé)(例如,測試員參與編碼工作);重復(fù)性勞動消耗了大量的計算資源;忘記了之前的討論內(nèi)容,導(dǎo)致重復(fù)工作;

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

二、溝通障礙

Agent之間的正常通信是任務(wù)成功的基礎(chǔ),但多Agent在這方面卻表現(xiàn)得不好。

比如在一個API集成任務(wù)中,手機助手代理錯誤地使用了一個郵箱作為登錄憑證,而正確的應(yīng)該是電話號碼,這主要源于“溝通不暢”,會加劇這些問題的因素在于:討論內(nèi)容偏離了任務(wù)目標(biāo),浪費了大量時間;智能體沒有共享關(guān)鍵信息,影響了決策;無視其他智能體的建議,或者在不確定時不主動尋求幫助;

三、驗收漏洞

在MAS中,任務(wù)的驗證是一個至關(guān)重要的環(huán)節(jié),但許多系統(tǒng)缺乏有效的驗證機制,導(dǎo)致任務(wù)的提前或不完整完成。

比如,在開發(fā)一個象棋游戲的任務(wù)中,驗證代理只檢查了代碼是否能運行,但沒有確保游戲遵循象棋規(guī)則。

類似這種任務(wù)在未完成所有步驟的情況下就被過早結(jié)束;缺乏對關(guān)鍵步驟的驗證,導(dǎo)致錯誤被遺漏。在Manus或者最近發(fā)布的扣子空間中都經(jīng)常發(fā)生。

錯誤原因

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

高可靠性組織通常能夠在高風(fēng)險的環(huán)境中完美運作,避免了類似的失敗。以下是MAS失敗的常見規(guī)律:

  1. 角色混亂 → 破壞層級分工:當(dāng)智能體不遵循自己的角色定義時,會打亂系統(tǒng)的層級結(jié)構(gòu),使得協(xié)作變得混亂。
  2. 信息隱瞞 → 忽視專業(yè)建議:智能體沒有共享重要信息,導(dǎo)致決策失誤。
  3. 敷衍的驗證 → 缺乏質(zhì)量把控:沒有有效的驗證機制,導(dǎo)致任務(wù)結(jié)果不可靠。

這些失敗表明,需要一個明確的結(jié)構(gòu)和質(zhì)量控制機制來確保任務(wù)的順利完成。

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

  1. 角色明確:為每個智能體設(shè)定明確的職責(zé)范圍,避免跨界行為。
  2. 交叉驗證:實施機制讓智能體之間進行互相驗證,類似于同行評審過程。
  3. 檢查清單:強制執(zhí)行關(guān)鍵步驟的驗證,確保任務(wù)完成的質(zhì)量。
  4. 結(jié)果:雖然這些戰(zhàn)術(shù)調(diào)整顯著提升了部分MAS的表現(xiàn)(提高了14%),但效果仍然不足以支撐大規(guī)模的實際部署。

這與我們之前做的多角色解決醫(yī)療幻覺是類似的:

因為我原來是醫(yī)療行業(yè)的,真實場景的方式比較敏感不能放出來,在網(wǎng)上找了一篇不錯的文章做說明:《醫(yī)療 CoT 全面分析》

這里內(nèi)容很長,大家自己去原文感受吧…

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

我的一些看法

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

一、大模型沒那么強

RL 之父 Rich Sutton在 2019 年的文章《苦澀的教訓(xùn)》

現(xiàn)在市面上有一種說法是:模型的通用能力,正在取代現(xiàn)在那些復(fù)雜的 Workflow。垂直模型是在開歷史倒車…

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

知識/數(shù)據(jù)是對真實世界的描述,就簡單一個事物,事實上我們平時只會關(guān)注他不到1/10的部分,以糖尿病為例:

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

比如醫(yī)生在實際診斷過程中,不僅依賴臨床指南,還有大量的內(nèi)化知識,包括:

  1. 患者微表情解讀(疼痛忍耐度);
  2. 社會經(jīng)濟因素權(quán)衡(治療方案可行性);
  3. 倫理判斷(生命質(zhì)量 vs 延長壽命);

這是當(dāng)前AI難以跨越的困局:隱性知識難以結(jié)構(gòu)化,導(dǎo)致訓(xùn)練數(shù)據(jù)本質(zhì)殘缺。

輸入不足,勢必導(dǎo)致輸出不足,這是大模型底層缺陷所致

AlphaGo的成功建立在圍棋規(guī)則完全透明、狀態(tài)空間有限的基礎(chǔ)上。而真實醫(yī)療場景存在:

  1. 模糊邊界(癥狀相似的不同疾病);
  2. 動態(tài)演化(患者病情突變);
  3. 價值沖突(不同科室意見相左);

這類開放性問題需要元認(rèn)知能力(反思自身決策局限),而當(dāng)前AI仍停留在“統(tǒng)計擬合”層面。

綜上,RL 之父所謂的算力碾壓需要一個大前提:算力需作用于正確架構(gòu)。

若基礎(chǔ)模型無法表征某類知識(如醫(yī)學(xué)倫理),單純堆算力可能陷入“自以為是又嚴(yán)密而精準(zhǔn)的錯誤”。

而GPT的預(yù)訓(xùn)練是基于詞序列的條件概率建模,其核心是通過海量文本學(xué)習(xí)在特定上下文中,下一個詞的概率分布。

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

二、模型是提示詞

雖然我們在使用提示詞讓模型產(chǎn)出我們需要的內(nèi)容,但我想表達(dá)的是:其實模型產(chǎn)出的才是提示詞。

或者換個描述,模型產(chǎn)出的是專業(yè)術(shù)語,是對一段文字的精煉,我們要做的是根據(jù)這個精煉的提示詞,去本地知識庫里面找到最應(yīng)該表達(dá)的部分。

這里的原因是,在第一點我們說清楚了模型在訓(xùn)練階段,數(shù)據(jù)可能只能表達(dá)真實世界的60%,但這并不表示模型是一精準(zhǔn)的數(shù)據(jù)庫!

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

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

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

所謂垂直大模型,可以是用行業(yè)數(shù)據(jù)進行微調(diào)的公司,也可以是基于大量算法數(shù)據(jù)調(diào)優(yōu)過后的模型。

垂直領(lǐng)域的玩家當(dāng)前多半基于Workflow自己玩,而類似DeepResearch、Genspark、Agent、Manus甚至門檻更高的Coze這種玩家當(dāng)然是希望:你們什么都別做,等我好了,就用我的!

于是,大家都在以一種遠(yuǎn)離垂直模型的方向在發(fā)展,只不過就算宣稱減少控制的Agent產(chǎn)品也在用一些方式調(diào)優(yōu)。

以Genspark為例,他們發(fā)現(xiàn)直接抓取網(wǎng)絡(luò)或者完全依賴大模型只能解決簡單問題時,就有一系列改進策略了,包括:

  1. 加入專業(yè)數(shù)據(jù)源(如學(xué)術(shù)、財經(jīng)、旅游等);
  2. 并行搜索處理復(fù)雜問題;
  3. 多代理交叉驗證信息避免幻覺;
  4. 引入專門的深度調(diào)研 Agent;

特別是這點需要特別引人注意:使用高質(zhì)量數(shù)據(jù)源、專家審核內(nèi)容;數(shù)據(jù)由離線 Agent 審核,確保準(zhǔn)確性,避免信息冗雜和虛假。

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

舉個例子,如果我現(xiàn)在要做醫(yī)療場景的Agent,那么我完全可以基于Workflow做基礎(chǔ)實現(xiàn),然后開啟用戶驗證。

而當(dāng)我驗證的差不多后,立馬宣傳大家都不要使用Workflow,并且馬上用DeepSeek包裝出一套Agent框架,將我的Workflow、數(shù)據(jù)全部以知識的形式內(nèi)置進模型。

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

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

還是那句話:垂直模型發(fā)展遲緩是經(jīng)濟問題不是錯誤問題。

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

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

其本質(zhì)是在關(guān)注模型幻覺問題,如果再往前走一步,就又回到垂直模型是否必須的問題了…

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

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

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

所以,各個公司不要試圖去做跟模型重合的領(lǐng)域,想辦法組織好自有領(lǐng)域結(jié)構(gòu)化數(shù)據(jù),后續(xù)看看怎么在保證安全的前提下與模型互相配合吧!

……

結(jié)語

文章已經(jīng)很長了,這里就不再增加篇幅了,最后還是常說的那句話:

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

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

當(dāng)前做Agent的各個公司也是如此,其實并不是多Agents會失敗,而是大家都沒準(zhǔn)備好,推得太急咯……

本文由人人都是產(chǎn)品經(jīng)理作者【葉小釵】,微信公眾號:【葉小釵】,原創(chuàng)/授權(quán) 發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載。

題圖來自Unsplash,基于 CC0 協(xié)議。

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 咩咩……

    來自廣東 回復(fù)