從“AI Agent”這個(gè)詞火起來之后我就一直有種不太合群的不安。隔三差五就能在方案評審里看到一句話“這里要引入Multi-Agent架構(gòu)讓多個(gè)智能體分工協(xié)作提升系統(tǒng)的泛化能力和魯棒性。”每次聽到這種話我都會(huì)先問一句當(dāng)前的基線是不是已經(jīng)驗(yàn)證過了如果連一個(gè)簡單的單Agent加工具鏈都沒跑通那堆上去的多Agent大概率不是智能而是事故。這篇文章不勸退AI Agent更不是讓你拒絕新技術(shù)。它想解決一個(gè)更實(shí)際的問題什么場景不該用Multi-Agent。我根據(jù)自己的真實(shí)開發(fā)經(jīng)歷以及身邊同行踩過的坑整理了8個(gè)典型場景。每個(gè)場景都會(huì)說清楚為什么不該用、硬用了會(huì)出什么問題、正確且輕量的替代方案是什么。適合那些正在做技術(shù)選型、被老板或客戶追著問“為什么不用多智能體”的人也適合剛接觸Agent架構(gòu)、還沒被生產(chǎn)環(huán)境毒打過的初學(xué)者。1. 為什么“Multi-Agent”容易被捧成銀彈——先看清單Agent和多Agent的本質(zhì)差別1.1 從架構(gòu)本質(zhì)上看多Agent到底增加了什么先統(tǒng)一一個(gè)基礎(chǔ)認(rèn)知。一個(gè)單Agent本質(zhì)上是一個(gè)“循環(huán)”收到任務(wù)后經(jīng)過“思考—調(diào)用工具—觀察結(jié)果—再思考—輸出”的閉環(huán)去完成目標(biāo)。它雖然是一個(gè)人但背后可以掛很多工具搜索引擎、數(shù)據(jù)庫、各種API、代碼解釋器只要工具夠全它能解決不少事。而Multi-Agent是讓多個(gè)這樣的循環(huán)同時(shí)存在并且彼此發(fā)送消息、傳遞結(jié)果、協(xié)商決策。比如最常見的設(shè)計(jì)是“一個(gè)規(guī)劃Agent 一個(gè)執(zhí)行Agent 一個(gè)審查Agent”任務(wù)先由規(guī)劃Agent拆解執(zhí)行Agent干活審查Agent挑毛病然后再循環(huán)。聽起來很合理對吧但工程上的本質(zhì)差異是多Agent不是“多了一個(gè)更聰明的大腦”而是“多了一條數(shù)據(jù)交換和協(xié)作調(diào)度的鏈路”。這條鏈路的代價(jià)非常大每次Agent之間通信都要把大量上下文信息序列化后傳給對方每個(gè)Agent拿到信息后又要用一次獨(dú)立的LLM調(diào)用來理解多個(gè)Agent之間還可能因?yàn)樾畔⒉灰恢露磸?fù)協(xié)商產(chǎn)生無效循環(huán)。換句話說Multi-Agent真正增加的不是“智能”而是“交互次數(shù)”與“調(diào)試難度”。在demo里這種交互看起來驚艷在生產(chǎn)環(huán)境里這種交互往往意味著更高的延遲、更貴的賬單、更模糊的責(zé)任邊界。1.2 為什么“銀彈敘事”會(huì)讓團(tuán)隊(duì)失去判斷力我一直在想為什么那么多團(tuán)隊(duì)會(huì)無條件相信Multi-Agent。后來發(fā)現(xiàn)這件事和“銀彈敘事”的心理機(jī)制有關(guān)。第一大家容易把“復(fù)雜問題”等同于“需要復(fù)雜架構(gòu)”。遇到一個(gè)難搞的業(yè)務(wù)需求第一反應(yīng)不是想怎么把問題拆簡單而是想“我是不是應(yīng)該上多Agent讓幾個(gè)Agent互相協(xié)作總能搞定”。這就好比自己做飯水平不行不去練基礎(chǔ)刀工反而先買一套專業(yè)廚師刀具。問題往往沒有變簡單只是變貴了。第二演示類項(xiàng)目特別容易放大Multi-Agent的價(jià)值。Demo里幾個(gè)Agent你一言我一語看起來很有“智能感”但一旦落到高并發(fā)、強(qiáng)約束、低延遲的真實(shí)業(yè)務(wù)里這種華麗感的代價(jià)會(huì)立刻暴露。第三“別人都在用”會(huì)形成一種盲從壓力。好像不用Multi-Agent就顯得團(tuán)隊(duì)不夠前沿。但架構(gòu)選型不是選秀不是誰花哨誰贏而是誰穩(wěn)、誰省、誰可控誰贏。所以在做選型之前把“銀彈濾鏡”摘掉先看看你的真實(shí)場景條件是什么。下面這8個(gè)場景就是我見過最典型的“不必用Multi-Agent”的情況。2. 8個(gè)不該采用Multi-Agent的場景——每一個(gè)都能找出真實(shí)教訓(xùn)2.1 場景一流程固定清晰單Agent加工具鏈能輕松走通有些任務(wù)看著復(fù)雜實(shí)際上是一個(gè)特別確定的流程。比如表單字段抽取、文本分類、敏感詞過濾、信息校驗(yàn)。輸入長什么樣中間走哪幾步輸出什么結(jié)構(gòu)都是提前定死的。這種場景用單Agent掛幾個(gè)工具調(diào)用就能實(shí)現(xiàn)調(diào)用模型做抽取調(diào)用規(guī)則做校驗(yàn)調(diào)用接口做寫入。整個(gè)鏈路完全線性沒有任何需要兩個(gè)角色“商量”的地方。但有些團(tuán)隊(duì)會(huì)被一句話打動(dòng)“我們需要讓Agent具備協(xié)作能力任務(wù)拆得更細(xì)”。于是把一個(gè)分類任務(wù)拆成“分析Agent”“判斷Agent”“復(fù)核Agent”。結(jié)果是什么成本漲了3倍準(zhǔn)確率并沒有實(shí)質(zhì)提升反而因?yàn)閺?fù)核Agent和判斷Agent的意見不一致產(chǎn)生了很多無效的來回對話。這類場景的正確打開方式是回歸“最短路徑”。能用規(guī)則寫的邏輯絕對不交給LLM能用一次LLM調(diào)用解決的絕不拆成兩次。哪怕你想用Agent概念包裝也只做一個(gè)Agent循環(huán)把所有工具和規(guī)則掛在它身上而不是橫向鋪開多個(gè)角色。我判斷這類場景有個(gè)很簡單的辦法如果能用一張流程圖把每個(gè)分支和結(jié)果寫清楚那就不需要多Agent。流程圖能表達(dá)的邏輯用代碼表達(dá)永遠(yuǎn)更穩(wěn)定、更便宜。2.2 場景二延遲敏感的實(shí)時(shí)交互多一層編排就多一層超時(shí)如果你做的產(chǎn)品需要直接面向用戶實(shí)時(shí)響應(yīng)比如在線客服機(jī)器人、語音助手、協(xié)同辦公里的智能助手那么“快”就是第一生命線。用戶等2秒已經(jīng)不耐煩等5秒就想關(guān)頁面。Multi-Agent的延遲開銷我實(shí)測下來的體感是非常明顯的。一個(gè)Agent任務(wù)通常要經(jīng)過“大模型推理—工具調(diào)用—結(jié)果回傳”幾個(gè)階段這已經(jīng)是1到3秒的量級。而Multi-Agent會(huì)在此基礎(chǔ)上再增加Agent之間的消息傳遞和多輪協(xié)商每一次傳遞都是一次新的LLM調(diào)用。一個(gè)原本3秒能完成的回答到了多Agent架構(gòu)里變成8到10秒是非常常見的事。有個(gè)做語音助手的團(tuán)隊(duì)曾經(jīng)分享過一個(gè)案例原本單Agent版本能做到1.2秒的首響引入多Agent后由于還需要等待另一個(gè)Agent補(bǔ)充信息首響飆到5.6秒。用戶的實(shí)際感受就是“它是不是卡住了”最后只能回滾。如果你確實(shí)要在低延遲場景里用Agent方案不是上多Agent而是把高耗時(shí)的部分拆出去。首次響應(yīng)盡量做到1秒內(nèi)用輕量模型檢索預(yù)置話術(shù)完成真正復(fù)雜的推理在后臺(tái)異步慢慢算算完再推送給用戶。2.3 場景三高頻次高并發(fā)調(diào)用Token開銷會(huì)吃掉所有利潤這一條主要講成本。很多團(tuán)隊(duì)一開始只關(guān)注Multi-Agent在效果上的可能性卻忽略了成本模型。而在生產(chǎn)環(huán)境里成本往往是決定一個(gè)系統(tǒng)能不能持續(xù)跑下去的生死線。我做過的項(xiàng)目里有單日調(diào)用量在百萬次級別的內(nèi)容審核和標(biāo)簽分類任務(wù)。這類任務(wù)的特點(diǎn)是單次任務(wù)邏輯不復(fù)雜但并發(fā)很高對單次成本極其敏感。如果在這種場景上Multi-Agent會(huì)發(fā)生什么Agent之間的每一輪對話都會(huì)把雙方的歷史信息反復(fù)序列化扔進(jìn)彼此的上下文窗口。也就是說同一個(gè)任務(wù)單Agent可能只需要消耗1000個(gè)Token而多Agent可能需要消耗6000甚至10000個(gè)Token。還有一個(gè)隱蔽問題多個(gè)Agent在對話時(shí)上下文會(huì)不斷累積當(dāng)累積超過一定閾值時(shí)系統(tǒng)還要做截?cái)?、摘要、重傳這些操作都在燒錢。簡單算一筆賬假設(shè)業(yè)務(wù)每天要處理100萬次任務(wù)單Agent方案的token消耗是100Token每次多Agent是5000Token每次。假設(shè)每1000Token的成本是0.01美元那么單Agent一天的成本是1000美元多Agent一天就是5000美元一年就多出接近150萬美元的差距。這還沒算額外的機(jī)器開銷和帶寬成本。所以在高并發(fā)場景里我特別建議把Token當(dāng)作錢來精打細(xì)算。能確定性的步驟比如正則、枚舉、查表不要交給大模型。真的需要LLM的地方優(yōu)先單Agent加精簡提示詞。Multi-Agent只適合那些單次調(diào)用價(jià)值極高、數(shù)量不大的任務(wù)而不是海量小任務(wù)。2.4 場景四輸出必須強(qiáng)約束、強(qiáng)規(guī)則非法值必須攔住有些業(yè)務(wù)對輸出結(jié)果的準(zhǔn)確性和合規(guī)性要求極高比如SQL生成、收支流水解析、合同關(guān)鍵條款抽取、稅務(wù)表單填寫。這些任務(wù)的共同點(diǎn)是只要某個(gè)字段填錯(cuò)后續(xù)整條鏈路都會(huì)崩掉。這類場景最重要的是可約束性。你需要的是“一定不會(huì)超出規(guī)則”的輸出但LLM本身的問題是它有“創(chuàng)造性”你問它一個(gè)模糊問題它真的會(huì)給你“創(chuàng)作”一個(gè)答案。單Agent已經(jīng)夠不可控了Multi-Agent在這種場景里會(huì)更可怕。我印象很深的一個(gè)案例某個(gè)合同審核系統(tǒng)原本用單Agent抽取條款結(jié)果還算穩(wěn)定。后來改成“抽取Agent 復(fù)核Agent”結(jié)構(gòu)復(fù)核Agent在一次對話中認(rèn)為某個(gè)字段“看起來不合理”于是主動(dòng)修改了抽取結(jié)果把“甲方付款日期”改成了一個(gè)完全不存在的時(shí)間。原因僅僅是復(fù)核Agent自己對合同法的理解偏差。最后系統(tǒng)上線一周就在審計(jì)環(huán)節(jié)炸了。強(qiáng)約束場景的正確做法是提示詞層級加硬約束明確說明“不能修改原始輸入、不能補(bǔ)充不存在的信息”用函數(shù)調(diào)用Function Calling配合嚴(yán)格的參數(shù)Schema讓模型只能在指定字段里填值在模型輸出后再做一道確定性的代碼校驗(yàn)比如JSON Schema校驗(yàn)、枚舉值檢查、格式校驗(yàn)不合法就直接拒絕。這一切手段都不需要多個(gè)Agent來配合反而需要你把更多精力放在模型和代碼之間那道“硬邊界”上。2.5 場景五需要嚴(yán)格審計(jì)鏈路、出了事故要能定位到具體環(huán)節(jié)在醫(yī)療輔助、金融風(fēng)控、法律意見生成這些領(lǐng)域“可解釋性”和“可追責(zé)性”比“效果上限”更重要。當(dāng)線上出了一個(gè)問題你需要快速回答一個(gè)問題到底是哪一步、哪一個(gè)模型、哪一條提示詞導(dǎo)致了這個(gè)錯(cuò)誤單Agent的時(shí)候鏈路是線性的用戶輸入 → 模型推理 → 工具調(diào)用 → 輸出。你可以非常輕松地把這整條鏈路記錄下來復(fù)盤的時(shí)候?qū)φ彰總€(gè)環(huán)節(jié)的輸入輸出就能定位問題。Multi-Agent則完全不一樣。任務(wù)的結(jié)果是由多個(gè)Agent之間的“協(xié)商”決定的而協(xié)商過程的每一步都會(huì)受到對方話語的影響。你很難說“就是這個(gè)Agent錯(cuò)了”因?yàn)樗呐袛嗫赡苁潜涣硪粋€(gè)Agent誤導(dǎo)的。這種責(zé)任模糊性在出大事的時(shí)候會(huì)變成災(zāi)難。我接觸過一家做內(nèi)部合規(guī)審批輔助的公司他們原本想構(gòu)建“合規(guī)檢查Agent 風(fēng)險(xiǎn)分析Agent 決策建議Agent”的組合但在測試階段就發(fā)現(xiàn)一旦出現(xiàn)錯(cuò)誤的合規(guī)結(jié)論他們完全無法定位是哪一個(gè)Agent的哪一句話導(dǎo)致了這個(gè)結(jié)論。最后他們回到單Agent方案但把所有中間推理過程全部記錄到日志系統(tǒng)里任何結(jié)論都能追溯到原始的輸入和工具結(jié)果才算滿足內(nèi)部審計(jì)要求。所以當(dāng)你所處的行業(yè)要求“每一步?jīng)Q策都有據(jù)可查”時(shí)請盡量保持架構(gòu)簡單可審計(jì)。多Agent的“黑盒協(xié)商”特性與審計(jì)要求天然沖突。2.6 場景六團(tuán)隊(duì)還沒有建立調(diào)試能力與可觀測體系別提前上復(fù)雜度這一條經(jīng)常被忽視但它可能是最致命的一條。一個(gè)團(tuán)隊(duì)能不能駕馭Multi-Agent取決于它有沒有配套的調(diào)試能力包括鏈路追蹤、日志監(jiān)控、在線日志分析、離線回歸評估。單Agent的調(diào)試相對簡單輸入給了提示詞在那工具結(jié)果看得見模型輸出錯(cuò)了可以復(fù)現(xiàn)。而Multi-Agent的調(diào)試你面對的是相互交錯(cuò)的調(diào)用鏈A調(diào)用了BB又調(diào)用了CC又回頭說“信息不足”讓A補(bǔ)充。你看到的日志像一本多人合寫的爛尾小說想說清楚情節(jié)線都難。這種情況下如果沒有一套成熟的Trace系統(tǒng)去記錄每個(gè)Agent的完整調(diào)用鏈沒有一套評估數(shù)據(jù)集去量化系統(tǒng)改動(dòng)前后的效果變化那你做Multi-Agent基本等于摸黑開車。而且Multi-Agent還有一個(gè)常見的獨(dú)特問題死鎖。兩個(gè)Agent為了一個(gè)模棱兩可的任務(wù)互相認(rèn)為自己缺少信息誰也等不到誰完成任務(wù)最后白白空轉(zhuǎn)。我見過不少團(tuán)隊(duì)架構(gòu)圖畫得很漂亮卻在聯(lián)調(diào)階段連續(xù)數(shù)周無法收斂最后項(xiàng)目延期半年。問題不是某個(gè)Agent不夠聰明而是整個(gè)團(tuán)隊(duì)根本不具備調(diào)試這種復(fù)雜體系的基礎(chǔ)設(shè)施和工程經(jīng)驗(yàn)。所以我的建議是基礎(chǔ)設(shè)施成熟之前不要迷信Multi-Agent。至少要先把Trace、評估集、日志管線的能力建起來再考慮往上加復(fù)雜度。2.7 場景七業(yè)務(wù)本質(zhì)是線性流水線協(xié)作協(xié)商是偽需求有些業(yè)務(wù)雖然流程很長但它本質(zhì)上是“一條流水線”比如文檔處理拆包→解析→去重→審核→入庫、內(nèi)容生產(chǎn)流程選題→素材→初稿→校對→發(fā)布、各種ETL任務(wù)。流水線的特點(diǎn)是上一步的輸出是下一步的輸入順序完全固定不需要臨場協(xié)商。這類場景使用Multi-Agent的問題在于你把任務(wù)“人格化”了。給每個(gè)環(huán)節(jié)起了一個(gè)Agent的名字好像它們真的在“協(xié)作”但它們干的事其實(shí)就是一個(gè)函數(shù)接著另一個(gè)函數(shù)。比如“素材Agent”和“初稿Agent”之間沒有真正需要協(xié)商的內(nèi)容只需要把結(jié)構(gòu)化數(shù)據(jù)傳給下一個(gè)環(huán)節(jié)。硬用多Agent會(huì)出現(xiàn)大量無意義的“客套話”Agent A說“我已完成素材整理”Agent B說“好的我收到素材現(xiàn)在開始寫初稿”。這些多出來的輸出全部都要消耗Token、全部都是延遲卻沒有創(chuàng)造任何額外價(jià)值。正確的做法是把這類任務(wù)實(shí)現(xiàn)成確定性流水線每個(gè)階段就是一段代碼加某些局部智能點(diǎn)。只有在某個(gè)節(jié)點(diǎn)需要判斷、抽取、總結(jié)時(shí)才調(diào)用一次LLM工具。其他環(huán)節(jié)統(tǒng)統(tǒng)交給確定的代碼邏輯。用代碼去表達(dá)流水線比用Agent去“商量”一條流水線要快、省、穩(wěn)得多。2.8 場景八評估體系還沒搭起來上了Multi-Agent也說不清好壞最后一個(gè)場景可能是很多團(tuán)隊(duì)最容易踩的坑你還沒有一個(gè)能衡量Agent好壞的評估體系就直接上了Multi-Agent。比如你現(xiàn)在要做一個(gè)簡歷解析系統(tǒng)你的腦子里只有一個(gè)模糊目標(biāo)“解析得越準(zhǔn)越好”。但你沒建立測試集沒有標(biāo)注哪些字段必須100%正確沒有對比基線也沒有定義“準(zhǔn)確率到底怎么算”。這種情況下你引入Multi-Agent之后哪怕系統(tǒng)效果有了一點(diǎn)變化你也說不清是變好了還是變壞了。我在做選型時(shí)有個(gè)鐵律如果一件事無法被衡量我就無法判斷它是否需要更重的架構(gòu)。Multi-Agent之所以被過度使用很大一部分原因是團(tuán)隊(duì)沒有用數(shù)據(jù)說話的習(xí)慣只能用“感覺更強(qiáng)了”來交差。正確的順序是先建立最小評估集哪怕是幾十條典型輸入輸出樣例跑通單Agent基線記錄指標(biāo)再考慮要不要加Multi-Agent同樣的評估集再跑一遍對比兩版指標(biāo)用數(shù)據(jù)和成本說話。如果還沒做評估體系請你先補(bǔ)上這一課再談架構(gòu)升級。否則你只是在“盲飛”的狀態(tài)下給自己增加難度。3. 用可量化決策矩陣替代“感覺”——一張自檢清單與時(shí)機(jī)信號(hào)3.1 通過維度自檢多半能幫你少走彎路與其靠感覺拍板不如用一張決策表把問題攤開來看。下表是我自己經(jīng)常使用的判斷維度你可以直接抄走。判斷維度適合單Agent的信號(hào)適合Multi-Agent的信號(hào)任務(wù)拆分方式流程固定順序可預(yù)先寫清楚需要?jiǎng)討B(tài)規(guī)劃多個(gè)角色并行探索延遲要求要求2秒內(nèi)必須給出響應(yīng)可接受分鐘級乃至更長的處理時(shí)間調(diào)用量級日調(diào)用量達(dá)到數(shù)十萬甚至百萬日調(diào)用量很低單次任務(wù)價(jià)值極高輸出約束必須嚴(yán)格符合Schema錯(cuò)誤代價(jià)高輸出開放允許一定程度的推測和創(chuàng)造可追責(zé)性每一步都必須能審計(jì)、能定位過程可以是黑盒只關(guān)注最終結(jié)果團(tuán)隊(duì)工程能力還沒有成熟的Trace和多Agent調(diào)試工具已有全套可觀測和調(diào)試基礎(chǔ)設(shè)施工作流形態(tài)線性管道輸出即輸入多個(gè)角色需要協(xié)商、競爭或互補(bǔ)評估體系已有回歸測試集和明確指標(biāo)已有能力對比不同架構(gòu)的效果差異你可以對照這張表逐條打勾。只要有兩條以上落在左邊就說明你大概率不需要Multi-Agent。很多項(xiàng)目最后正是被這張表勸住了。3.2 什么時(shí)候才需要從單Agent升級到Multi-Agent反過來也要說清楚我不是說Multi-Agent永遠(yuǎn)不該用。當(dāng)出現(xiàn)以下信號(hào)時(shí)它會(huì)成為一個(gè)合理選擇單Agent的上下文已經(jīng)塞滿了任務(wù)細(xì)節(jié)即使精簡提示詞也無法承載多個(gè)子任務(wù)任務(wù)中的多個(gè)部分必須并行推進(jìn)比如同時(shí)調(diào)研多個(gè)方向、并行撰寫多個(gè)模塊多個(gè)角色之間存在真正的“協(xié)商”需求而不是簡單的數(shù)據(jù)傳遞比如系統(tǒng)需要同時(shí)扮演“生成方”和“評估方”反復(fù)迭代改進(jìn)結(jié)果團(tuán)隊(duì)已經(jīng)具備成熟的觀察體系能準(zhǔn)確看到每個(gè)Agent每一步的調(diào)用記錄和成本。這些信號(hào)意味著你確實(shí)遇到了用一個(gè)獨(dú)立大腦解決不了的問題。這時(shí)候再上Multi-Agent你的成本才花得值。4. 如果不適合Multi-Agent那用什么——三種務(wù)實(shí)的輕量方案4.1 狀態(tài)機(jī)控制的單Agent循環(huán)兼顧可控與智能第一種方案是把智能收斂在“單Agent循環(huán)”里用代碼控制狀態(tài)流轉(zhuǎn)。你可以定義幾個(gè)狀態(tài)解析、校驗(yàn)、決策、輸出。Agent在哪個(gè)狀態(tài)就調(diào)用對應(yīng)的一組工具跑完再根據(jù)結(jié)果進(jìn)行狀態(tài)轉(zhuǎn)移。這樣做的優(yōu)勢是LLM只負(fù)責(zé)它最擅長的部分比如抽取、總結(jié)、判斷而流程控制、條件分支、異常處理全部由代碼完成。你可以在運(yùn)行時(shí)把每一步記錄下來出現(xiàn)問題時(shí)對著日志就能還原全過程。一段極簡的示意states [extract, validate, respond] def run_agent(input_data): extracted llm_extract(input_data) # 第一次LLM調(diào)用 if not validate_schema(extracted): # 確定性校驗(yàn) return {error: invalid_field} response llm_generate(extracted) # 第二次LLM調(diào)用 return response這個(gè)方案看起來樸素但大多數(shù)業(yè)務(wù)場景已經(jīng)夠用。4.2 確定性工作流配合局部智能點(diǎn)流水線模式如果任務(wù)本身是清晰的流水線就把它寫成一串可執(zhí)行的步驟只在需要理解語義的地方插入LLM工具。例如文檔處理流程stages [parse, deduplicate, llm_summarize, validate, store] def process(document): data document for stage in stages: data stage(data) # 每個(gè)stage內(nèi)部可以選擇調(diào)LLM或純代碼 return data這種方式我稱它為“局部智能點(diǎn)”模式。系統(tǒng)整體是確定性的你永遠(yuǎn)知道下一步會(huì)執(zhí)行什么但每一步里又可以插入LLM能力讓智能在其中而不是整個(gè)流程上。它比Multi-Agent好的地方在于不用為Agent之間的通信付費(fèi)不會(huì)被Agent之間的協(xié)商卡住而且每個(gè)階段是否調(diào)用了大模型都是一目了然的。4.3 用Eval和Trace來決策讓數(shù)據(jù)替你做架構(gòu)選型最后一個(gè)替代方案其實(shí)是一種決策方法在糾結(jié)要不要上Multi-Agent之前先把評估和追蹤能力建起來。建一個(gè)最小的回歸測試集覆蓋正常輸入、邊界輸入、錯(cuò)誤輸入給當(dāng)前單Agent方案跑出指標(biāo)作為基線簡單搭一個(gè)調(diào)用鏈追蹤記錄下每次請求哪個(gè)環(huán)節(jié)耗時(shí)最長、失敗最多如果有余力再搭一個(gè)需要比較的Multi-Agent原型用同一套測試集對比效果和成本。你會(huì)發(fā)現(xiàn)大多數(shù)時(shí)候單Agent加精細(xì)的工具設(shè)計(jì)在指標(biāo)上并不輸給Multi-Agent。即使真的輸了你手里也有了清晰的數(shù)據(jù)可以向團(tuán)隊(duì)解釋“多花這些成本換來的指標(biāo)提升是值得還是不值得”而不是拍腦袋吵一架。5. 生產(chǎn)環(huán)境中的踩坑故事以及我沉淀下來的選型原則5.1 一臺(tái)上線事故讓我明白多Agent不是炫技工具那次事故至今印象很深。某個(gè)版本想把客服工單自動(dòng)處理系統(tǒng)從單Agent升級成“意圖識(shí)別Agent、信息抽取Agent、工單分配Agent”三駕馬車的Multi-Agent架構(gòu)。愿景是每個(gè)Agent各管一段讓整體更專業(yè)。結(jié)果上線第一周就出現(xiàn)了一個(gè)詭異的癥狀大約10%的工單在分配階段被卡住。排查后發(fā)現(xiàn)“意圖識(shí)別Agent”和“信息抽取Agent”在一個(gè)模糊工單上產(chǎn)生了分歧一個(gè)認(rèn)為客戶想退款另一個(gè)認(rèn)為客戶想投訴兩個(gè)Agent互相要求對方補(bǔ)充信息形成了死循環(huán)。如果沒有日志系統(tǒng)我們幾乎找不到問題在哪。后來我們把整個(gè)系統(tǒng)改回了一種極其樸素的落地方式先用一個(gè)輕量模型做意圖分類再用確定性規(guī)則抽取關(guān)鍵字段最后調(diào)用一個(gè)LLM Agent生成回復(fù)模板。并發(fā)能力上去了工單卡死問題消失成本反而下降了60%。這次經(jīng)歷給我留下一個(gè)重要認(rèn)知架構(gòu)的復(fù)雜度和系統(tǒng)的穩(wěn)定性是成反比的尤其在沒有足夠配套能力時(shí)。Agent聽起來高大上但生產(chǎn)環(huán)境只要穩(wěn)定、可控、便宜它就是最好的架構(gòu)。5.2 總結(jié)我的選型傾向先測量再架構(gòu)做Agent相關(guān)項(xiàng)目到現(xiàn)在我沉淀下來的選型原則很簡單先測量再架構(gòu)先單智能體后多智能體先規(guī)則后模型先可追溯再談自治。每個(gè)功能上線前我都會(huì)問自己三個(gè)問題這個(gè)問題用一個(gè)Agent工具能不能解決如果必須多個(gè)Agent我能準(zhǔn)確跟蹤和評估每個(gè)Agent的行為嗎多Agent帶來的額外成本和延遲換來的指標(biāo)提升是否值得如果這三個(gè)問題中有一個(gè)答不上來我會(huì)選擇更簡單的那條路。所謂銀彈其實(shí)是自己沒有看清問題全貌時(shí)對某個(gè)技術(shù)抱有的幻想。AI Agent有它的價(jià)值但Multi-Agent絕不是拿來就能用、用了就靈驗(yàn)的萬能藥。最后再多說一句與其把精力花在“把系統(tǒng)做得看起來更智能”不如先把系統(tǒng)做得更可解釋、更可控、更經(jīng)濟(jì)。真實(shí)的智能往往體現(xiàn)在那些不起眼的確定性工程里而不是幾個(gè)Agent之間的靈活對話中。