我最早接觸 Multi-Agent 產(chǎn)品化是從一個(gè)被客戶問(wèn)住的瞬間開(kāi)始的。當(dāng)時(shí)我們做了一套通用的多智能體演示平臺(tái)幾個(gè) agent 分角色討論、協(xié)作寫(xiě)方案、自動(dòng)拆解任務(wù)跑起來(lái)特別唬人。跟一個(gè)做供應(yīng)鏈履約的客戶聊對(duì)方看完 demo 點(diǎn)了點(diǎn)頭然后問(wèn)了一句“挺酷但我們倉(cāng)庫(kù)里那套十年前的報(bào)單系統(tǒng)它怎么接你們能讓它自己查庫(kù)存、自己校驗(yàn)合同、自己回郵件還不出錯(cuò)嗎”我一下子意識(shí)到通用工具和垂直行業(yè)解決方案之間隔著的不是幾行 prompt而是一整套關(guān)于業(yè)務(wù)理解、系統(tǒng)邊界、評(píng)測(cè)標(biāo)準(zhǔn)和交付方式的重新設(shè)計(jì)。這篇文章就把我從通用 Multi-Agent 工具轉(zhuǎn)向垂直行業(yè)方案的完整思考寫(xiě)出來(lái)包括底層機(jī)制、通用工具為什么落地難、垂直化改造到底改什么、從調(diào)研到上線的四步流程以及我踩過(guò)的幾個(gè)印象深刻的坑。打算做 Multi-Agent 產(chǎn)品化或者正糾結(jié)“套個(gè)通用框架能不能直接交付”的朋友這篇應(yīng)該能幫上忙。1. 先看清楚Multi-Agent為什么火技術(shù)本意與產(chǎn)品化初期的錯(cuò)配1.1 多智能體解決的是“分工”不是“更聰明”很多人第一次接觸 Multi-Agent 時(shí)最直觀的感受是“多個(gè) AI 一起干活肯定比一個(gè)強(qiáng)”。這個(gè)直覺(jué)方向?qū)Φ珯C(jī)制理解經(jīng)常偏。單 Agent 模型哪怕是參數(shù)規(guī)模再大本質(zhì)上還是一個(gè)上下文窗口里處理全部任務(wù)既要理解用戶意圖又要檢索知識(shí)還要調(diào)用工具最后還得保證輸出風(fēng)格統(tǒng)一。一旦任務(wù)鏈條變長(zhǎng)上下文會(huì)迅速膨脹模型很容易在中間環(huán)節(jié)丟失對(duì)原始目標(biāo)的對(duì)齊。Multi-Agent 的核心價(jià)值在于把一個(gè)大問(wèn)題拆成幾個(gè)小問(wèn)題交給不同角色各自處理再用消息機(jī)制把結(jié)果串起來(lái)。這跟公司里不同崗位協(xié)作是一個(gè)邏輯客服接單、運(yùn)營(yíng)查庫(kù)存、法務(wù)審條款、財(cái)務(wù)做結(jié)算沒(méi)有人會(huì)要求一個(gè)崗位從接單干到對(duì)賬。多智能體的意義不是讓模型“變聰明”而是讓每個(gè) agent 的職責(zé)邊界變得清晰上下文相對(duì)獨(dú)立提示詞可以針對(duì)單一職責(zé)反復(fù)優(yōu)化出了問(wèn)題也知道該去查哪一個(gè)環(huán)節(jié)。1.2 三種協(xié)作模式?jīng)Q定了產(chǎn)品形態(tài)的上限我在實(shí)際項(xiàng)目里看到的多智能體協(xié)作模式基本可以歸成三類對(duì)話式協(xié)作幾個(gè) agent 圍繞一個(gè)議題來(lái)回討論像開(kāi)頭腦風(fēng)暴會(huì)。適合創(chuàng)意生成、方案發(fā)散但產(chǎn)出不穩(wěn)定過(guò)程不可控。工作流式協(xié)作任務(wù)被預(yù)先編排成有向圖每個(gè)節(jié)點(diǎn)由一個(gè) agent 執(zhí)行執(zhí)行完把結(jié)果交給下一個(gè)節(jié)點(diǎn)?？煽匦詮?qiáng)適合流程確定的業(yè)務(wù)場(chǎng)景。自主式協(xié)作一個(gè)“主導(dǎo) agent”動(dòng)態(tài)決定何時(shí)調(diào)用哪個(gè)“執(zhí)行 agent”沒(méi)有固定流程靈活但難調(diào)試、難評(píng)測(cè)。早期大家做通用工具傾向于把三種模式都塞進(jìn)一個(gè)平臺(tái)讓用戶自己選?？雌饋?lái)是大而全實(shí)際上對(duì)行業(yè)客戶來(lái)說(shuō)這是把復(fù)雜度全踢給了用戶。真正到了垂直場(chǎng)景里我們后來(lái)基本只用“工作流式 有限自主”的組合主流程固定局部環(huán)節(jié)允許 agent 做小范圍決策。1.3 為什么第一波產(chǎn)品都選擇做“通用工具”回頭看第一波 Multi-Agent 產(chǎn)品普遍偏“通用工具”不是偶然的。從供給端看做通用編排框架的成本最低。搭一個(gè)角色管理模塊、一套消息路由、幾個(gè)內(nèi)置工具再配個(gè)可視化編排界面技術(shù)上確實(shí)不難。加上那一時(shí)期市面上大量開(kāi)源的通用編排項(xiàng)目提供了現(xiàn)成底座團(tuán)隊(duì)可以用很小的成本快速拼出一個(gè)能演示的東西。從需求端看Multi-Agent 的想象力太大幾乎每個(gè)行業(yè)都有“多角色協(xié)作”的敘事可講資本和市場(chǎng)也愿意為這種想象力買單。但供給端的“做出來(lái)容易”和需求端的“用得起來(lái)”完全是兩回事。通用工具追求的是抽象能力把流程、角色、工具都參數(shù)化理論上什么都能配實(shí)際上什么都要客戶自己配。而行業(yè)客戶要的是特定場(chǎng)景里“開(kāi)箱即用、看得見(jiàn)指標(biāo)”的解決方案。這個(gè)錯(cuò)配就是通用工具熱鬧一陣后集體轉(zhuǎn)向垂直化的根本原因。2. 通用工具的失速點(diǎn)為什么demo驚艷、上線即翻車2.1 行業(yè)知識(shí)不在模型腦子里也不在通用框架里我最開(kāi)始犯的錯(cuò)是低估了行業(yè)知識(shí)的重要性。通用 Multi-Agent 框架里agent 的能力完全依賴模型預(yù)訓(xùn)練時(shí)積累的公開(kāi)知識(shí)。拿來(lái)處理泛化的文字任務(wù)比如寫(xiě)新聞稿、做摘要、翻譯問(wèn)題不大。但一旦進(jìn)入具體行業(yè)模型的知識(shí)就是“聽(tīng)過(guò)很多行業(yè)但真不懂你家業(yè)務(wù)”。舉一個(gè)真實(shí)例子。某家做合同審核的客戶希望 agent 能判斷條款是否有風(fēng)險(xiǎn)。通用框架里的“法務(wù) agent”可以背出法律常識(shí)但當(dāng)客戶問(wèn)“這條逾期違約金上限是否符合我們集團(tuán)內(nèi)部‘單筆不超過(guò)合同總額8%’的規(guī)定”時(shí)模型根本不知道這家集團(tuán)有這個(gè)內(nèi)部標(biāo)準(zhǔn)。它不是能力不夠而是沒(méi)有連接企業(yè)內(nèi)部的規(guī)則庫(kù)。這個(gè)差距在 demo 階段看不出來(lái)因?yàn)槟阊菔镜氖恰巴ㄓ贸ＷR(shí)”一到真實(shí)數(shù)據(jù)上跑準(zhǔn)確率馬上崩。行業(yè)客戶付費(fèi)買的從來(lái)不是“AI 常識(shí)”而是“行業(yè)知識(shí) 企業(yè)私有規(guī)則 業(yè)務(wù)系統(tǒng)的實(shí)時(shí)數(shù)據(jù)”。2.2 評(píng)估方式存在系統(tǒng)性偏差通用工具時(shí)代對(duì) Multi-Agent 的評(píng)估基本停留在“內(nèi)容質(zhì)量”層面回答是否有邏輯、是否全面、語(yǔ)氣是否自然。這種評(píng)估方式有一個(gè)前提假設(shè)——任務(wù)的終態(tài)是“生成一段文字”。但行業(yè)業(yè)務(wù)里任務(wù)的終態(tài)往往是“完成一個(gè)動(dòng)作并且結(jié)果正確”庫(kù)存是否扣對(duì)、工單是否派給正確的人、報(bào)表數(shù)字是否和對(duì)賬系統(tǒng)一致。有一個(gè)客戶項(xiàng)目讓我印象很深。某個(gè)用通用框架搭的客服問(wèn)答 agent在演示時(shí)對(duì)答如流客戶滿意度測(cè)試也很高。但我們把線上真實(shí)對(duì)話導(dǎo)入后發(fā)現(xiàn) agent 在無(wú)法處理的時(shí)候會(huì)“一本正經(jīng)地編造解決方案”。從 NLP 角度看它生成的內(nèi)容很流暢從業(yè)務(wù)角度看它在制造事故。根本問(wèn)題就是評(píng)測(cè)指標(biāo)設(shè)計(jì)錯(cuò)了——只看了“生成了什么”沒(méi)有看“做的事情對(duì)不對(duì)”。垂直行業(yè)方案在這一點(diǎn)上有本質(zhì)區(qū)別必須在產(chǎn)品定義階段就明確業(yè)務(wù)指標(biāo)比如異常處理率、平均處理時(shí)長(zhǎng)、人工復(fù)核率、誤判成本而且這些指標(biāo)要有歷史基線做對(duì)照。沒(méi)有基線就沒(méi)有“更好”只有“感覺(jué)看起來(lái)不錯(cuò)”。對(duì)比維度通用工具思路垂直行業(yè)解決方案知識(shí)來(lái)源模型預(yù)訓(xùn)練知識(shí)為主企業(yè)知識(shí)庫(kù)私有規(guī)則實(shí)時(shí)數(shù)據(jù)為主任務(wù)邊界開(kāi)放域什么都能聊明確流程節(jié)點(diǎn)只處理約定場(chǎng)景評(píng)測(cè)方式文本質(zhì)量、內(nèi)容相關(guān)性業(yè)務(wù)結(jié)果、成本節(jié)約、時(shí)效提升系統(tǒng)對(duì)接通用API演示級(jí)企業(yè)老系統(tǒng)適配權(quán)限與審計(jì)全打通交付模式平臺(tái)自助配置解決方案持續(xù)運(yùn)營(yíng)2.3 系統(tǒng)集成的復(fù)雜度被嚴(yán)重低估第三個(gè)失速點(diǎn)是技術(shù)層面的把 agent 接入客戶的真實(shí)系統(tǒng)難度遠(yuǎn)超“調(diào)個(gè) API”。大多數(shù)行業(yè)客戶的業(yè)務(wù)系統(tǒng)不是為新工具準(zhǔn)備的有的是老掉牙的本地部署系統(tǒng)數(shù)據(jù)庫(kù)表結(jié)構(gòu)混亂得讓人懷疑人生接口文檔過(guò)時(shí)字段含義要靠問(wèn)老員工才知道。通用工具通常在架構(gòu)上只考慮了“標(biāo)準(zhǔn)化的數(shù)據(jù)接入方式”一旦遇到真實(shí)系統(tǒng)集成時(shí)間會(huì)遠(yuǎn)超預(yù)想。這個(gè)坑我后來(lái)有一個(gè)比較務(wù)實(shí)的應(yīng)對(duì)思路不要一上來(lái)就追求“全系統(tǒng)的 agent 化”而是先畫(huà)清楚客戶的系統(tǒng)地圖、數(shù)據(jù)流和關(guān)鍵操作點(diǎn)然后選取與流程最相關(guān)、數(shù)據(jù)質(zhì)量最高的兩三個(gè)節(jié)點(diǎn)先做。用一個(gè)細(xì)分的工具連接器去適配一個(gè)具體的系統(tǒng)操作比做一個(gè)“萬(wàn)能連接器”靠譜得多。系統(tǒng)集成不是技術(shù)活是梳理業(yè)務(wù)脈絡(luò)的過(guò)程。2.4 成本與延遲是通用方案最容易爆掉的隱形雷還有一個(gè)容易被 demo 階段忽略的問(wèn)題就是成本和延遲。多智能體天然比單模型調(diào)用更貴、更慢。每個(gè) agent 都要獨(dú)立的上下文agent 之間來(lái)回通信一次完整任務(wù)下來(lái)token 消耗可能是單輪問(wèn)答的幾十倍。通用工具對(duì)成本的控制手段無(wú)非是設(shè)上限或者限制輪數(shù)但業(yè)務(wù)場(chǎng)景里任務(wù)復(fù)雜度往往不可控。我在一個(gè)電商場(chǎng)景里遇到過(guò)極端情況一個(gè)簡(jiǎn)單問(wèn)題四個(gè) agent 來(lái)回串了十幾輪最后給了一個(gè)其實(shí)可以一句話回答的結(jié)論。技術(shù)上沒(méi)錯(cuò)但放在真實(shí)環(huán)境里既慢又貴客戶看完說(shuō)“這還不如人工”。后來(lái)我們所有垂直項(xiàng)目都強(qiáng)制加入輪次上限和降級(jí)邏輯默認(rèn)最多兩輪協(xié)作解決不了就直接轉(zhuǎn)人工把關(guān)鍵決策交給確定性規(guī)則而不是讓 agent 無(wú)限發(fā)散。成本意識(shí)必須從產(chǎn)品第一天就建立晚了就變成事故。3. 垂直化的關(guān)鍵改造把行業(yè)規(guī)則做進(jìn)agent的工作流3.1 讓“流程劇本”替代碼替 promp 兜底通用工具習(xí)慣讓 agent 擁有很高的自由度——任務(wù)來(lái)了自己拆解自己執(zhí)行。垂直方案要反過(guò)來(lái)先定義好流程劇本再讓 agent 在劇本框架內(nèi)做事。我舉一個(gè)實(shí)際做過(guò)的供應(yīng)鏈訂單異常處理場(chǎng)景?？蛻舻臉I(yè)務(wù)是訂單進(jìn)來(lái)后需要檢查庫(kù)存是否充足、合同條款是否允許分批交貨、賬期是否正常然后決定是正常履約還是走異常審批。如果用通用 agent 來(lái)處理prompt 會(huì)把所有情況都語(yǔ)義化地寫(xiě)在提示詞里讓模型自己判斷。現(xiàn)實(shí)情況是模型容易漏分支而且出了錯(cuò)很難定位。我們后來(lái)的設(shè)計(jì)是三段式劇本數(shù)據(jù)采集階段由一個(gè)固定的工具 agent 調(diào)用訂單、庫(kù)存、合同、客戶信用四個(gè)數(shù)據(jù)源把結(jié)果整理成統(tǒng)一字段。規(guī)則判定階段這條路徑不經(jīng)過(guò)模型走確定性規(guī)則引擎用 if-else 判斷訂單是否異常、異常類型是什么。協(xié)同處理階段只有觸發(fā)“合同補(bǔ)助”“信用預(yù)警告”這種需要解釋和溝通的場(chǎng)景才啟動(dòng)多個(gè) agent 協(xié)作。這個(gè)結(jié)構(gòu)的好處非常明顯把所有能用規(guī)則完成的部分從模型那里拿回來(lái)agent 只處理真正需要語(yǔ)義理解和溝通的部分。模型的不可控性被壓縮到最小系統(tǒng)整體可解釋性大幅提高。流程劇本的本質(zhì)是把業(yè)務(wù)專家腦子里的經(jīng)驗(yàn)顯式畫(huà)出來(lái)而不是指望模型隱式學(xué)會(huì)。3.2 行業(yè)知識(shí)底座的“三層結(jié)構(gòu)”垂直化必然要解決行業(yè)知識(shí)注入問(wèn)題。我的做法是把知識(shí)體系拆成三層第一層是企業(yè)規(guī)則庫(kù)。這是最核心的也是最高優(yōu)先級(jí)的。比如審核規(guī)則、折扣規(guī)則、風(fēng)險(xiǎn)紅線、合規(guī)要求。它們有明確的邏輯表達(dá)式適合做成結(jié)構(gòu)化規(guī)則放進(jìn)規(guī)則引擎或作為檢索底庫(kù)里的高權(quán)重文檔。在 agent 做任何決策時(shí)規(guī)則庫(kù)要先于模型知識(shí)生效。第二層是行業(yè)語(yǔ)料庫(kù)。包括行業(yè)內(nèi)的標(biāo)準(zhǔn)術(shù)語(yǔ)、操作手冊(cè)、歷史案例、常見(jiàn)問(wèn)題解決方案。這些通常是非結(jié)構(gòu)化的文本通過(guò)向量化后做成檢索增強(qiáng)庫(kù)供 agent 在需要時(shí)按語(yǔ)義檢索。這里需要特別注意版本管理——行業(yè)條款和政策會(huì)變語(yǔ)料庫(kù)必須做時(shí)間戳和生效標(biāo)記不能把廢止的規(guī)則喂給 agent。第三層才是模型通用知識(shí)。它只是兜底的處理那些規(guī)則庫(kù)和語(yǔ)料庫(kù)都沒(méi)有覆蓋到的邊界問(wèn)題。設(shè)計(jì)原則很簡(jiǎn)單模型的能力用在對(duì)規(guī)則的解讀和解釋上而不是用來(lái)創(chuàng)造新的業(yè)務(wù)規(guī)則。3.3 用最小協(xié)作模型跑通閉環(huán)垂直化改造最容易失敗的方法是一上來(lái)就鋪一個(gè)大而全的架構(gòu)。我建議先選一條價(jià)值最明確、數(shù)據(jù)條件最好的真實(shí)業(yè)務(wù)線用最小協(xié)作模型跑通端到端閉環(huán)。以訂單異常處理的場(chǎng)景為例我當(dāng)時(shí)定義的 agent 集合特別克制就三個(gè)角色訂單識(shí)別 agent負(fù)責(zé)讀取訂單信息和客戶資料完成目標(biāo)識(shí)別、標(biāo)簽提取不決策只產(chǎn)出結(jié)構(gòu)化描述。方案 agent根據(jù)規(guī)則引擎給出的異常類型從歷史類似案例庫(kù)中檢索最優(yōu)處理路徑給出一個(gè)帶置信度的建議方案。通知 agent把建議方案翻譯成不同對(duì)象能看懂的文本比如給客服的完整說(shuō)明、給客戶的簡(jiǎn)短解釋、給法務(wù)的風(fēng)險(xiǎn)提示。三個(gè) agent 之間只通過(guò)結(jié)構(gòu)化 JSON 消息通信每個(gè) agent 的工具調(diào)用范圍也被嚴(yán)格限定。# 簡(jiǎn)化示意最小協(xié)作模型的執(zhí)行骨架 def run_order_exception_pipeline(order_id): order_data call_data_source(order, order_id) exception_code rules_engine.check(order_data) # 確定性規(guī)則引擎判定 if not exception_code: return {action: normal_fulfill, reason: no rule triggered} candidate_plan plan_agent.search_cases(exception_code, order_data) user_notice notify_agent.render(candidate_plan, audiencecustomer) internal_ticket notify_agent.render(candidate_plan, audienceoperations) return { action: exception_review, plan_id: candidate_plan.id, needs_human_approval: candidate_plan.confidence 0.85 }這套設(shè)計(jì)的關(guān)鍵點(diǎn)在于真正的主流程是規(guī)則引擎控制的agent 只負(fù)責(zé)“理解并豐富”它經(jīng)手的那一小塊內(nèi)容。這既發(fā)揮了模型的理解與生成優(yōu)勢(shì)又把決策可靠性交給確定性邏輯客戶最終能接受正是因?yàn)檫@個(gè)邊界清晰。3.4 指標(biāo)必須從“回答得好”換成“業(yè)務(wù)向好”垂直行業(yè)方案上線后衡量的標(biāo)準(zhǔn)完全不同。通用工具看的是內(nèi)容質(zhì)量分垂直方案看的是三類業(yè)務(wù)指標(biāo)時(shí)效類平均處理時(shí)長(zhǎng)從多少小時(shí)降到多少分鐘。準(zhǔn)確類判定準(zhǔn)確率、漏報(bào)率、重做率、合規(guī)通過(guò)率。成本類單位處理成本、人工介入率、人力節(jié)省。每類指標(biāo)都必須有上線前的歷史基線并且要有一個(gè)“如果新系統(tǒng)不如基線就回滾”的保護(hù)機(jī)制。有一次客戶問(wèn)我們“這個(gè) agent 準(zhǔn)確率到底多少算好”我的回答是“不要問(wèn)絕對(duì)數(shù)問(wèn)相比人工基線的提升。人工處理同一批異常訂單的正確率是多少你的方案要能比這個(gè)基線高否則 AI 就沒(méi)有存在價(jià)值?！敝挥邪言u(píng)測(cè)語(yǔ)言換成業(yè)務(wù)方聽(tīng)得懂、算得清的口徑垂直方案才不再是技術(shù)展示而真正變成可以談?lì)A(yù)算的產(chǎn)品。4. 從調(diào)研到上線的四步落地法場(chǎng)景選擇決定生死4.1 第一步流程盤(pán)點(diǎn)找“高頻、高痛、規(guī)則可表達(dá)”的切入點(diǎn)垂直方案的第一步不是畫(huà)架構(gòu)而是做流程盤(pán)點(diǎn)。我通常會(huì)跟客戶的運(yùn)營(yíng)負(fù)責(zé)人、一線執(zhí)行員工各聊一輪收集他們?nèi)粘９ぷ髦械母哳l操作、等候時(shí)間、出錯(cuò)點(diǎn)然后整理成一張流程清單。一個(gè)容易踩的誤區(qū)是只聽(tīng)管理層的描述管理層往往描述的是“流程應(yīng)當(dāng)怎樣”一線員工說(shuō)的才是“流程實(shí)際怎樣”。兩者之間的差距通常正是垂直方案能創(chuàng)造價(jià)值的地方。拿到流程清單后要做一輪初步篩選把范圍縮小到兩三個(gè)候選場(chǎng)景。篩選的核心標(biāo)準(zhǔn)是三句話業(yè)務(wù)頻率高不高人工痛點(diǎn)大不大規(guī)則能不能被表達(dá)成可編程的判定邏輯。第三個(gè)標(biāo)準(zhǔn)特別關(guān)鍵如果一個(gè)流程非常依賴人的直覺(jué)判斷短期內(nèi)就不要硬做 agent先做知識(shí)輔助類功能可能更穩(wěn)妥。4.2 第二步場(chǎng)景打分用表格把決策逼到墻角篩選完就是場(chǎng)景打分。我用的表格很簡(jiǎn)單四個(gè)維度每項(xiàng) 1-5 分維度說(shuō)明權(quán)重流程確定性是否有明確規(guī)則和分支30%數(shù)據(jù)可得性所需數(shù)據(jù)是否已有結(jié)構(gòu)化存儲(chǔ)且質(zhì)量可靠25%效益可量化處理量、耗時(shí)、成本是否有歷史統(tǒng)計(jì)25%風(fēng)險(xiǎn)可控性出錯(cuò)下限是造成不便還是重大損失20%打分表的作用很直接避免團(tuán)隊(duì)?wèi){感覺(jué)選一個(gè)“技術(shù)上有意思”但“業(yè)務(wù)上沒(méi)用”的場(chǎng)景。我們有一次在物流客戶那里同時(shí)評(píng)估了“運(yùn)單信息補(bǔ)錄”和“異常配送協(xié)商”兩個(gè)場(chǎng)景前者的流程確定性接近滿分后者需要大量臨場(chǎng)溝通。公司內(nèi)部有人傾向后者覺(jué)得更有挑戰(zhàn)性但打分表明確顯示前者風(fēng)險(xiǎn)低、見(jiàn)效快。最終先做了前者上線三個(gè)月后積累了足夠數(shù)據(jù)和客戶信任才推動(dòng)后者。先贏一次比什么都重要。4.3 第三步POC設(shè)計(jì)先定義“贏了”再說(shuō)POC 不是 demo不是拿真實(shí)數(shù)據(jù)跑一遍給領(lǐng)導(dǎo)看。一份合格的 POC 設(shè)計(jì)要先寫(xiě)清楚三個(gè)東西。一是“現(xiàn)有人工基線”的量化數(shù)據(jù)過(guò)去一個(gè)月這個(gè)場(chǎng)景的平均處理時(shí)長(zhǎng)、正確率、人工成本。沒(méi)有這些后續(xù)任何效果數(shù)據(jù)都沒(méi)有參照物。二是“POC 成功指標(biāo)”比如異常處理自動(dòng)率要超過(guò) 40%、平均處理時(shí)長(zhǎng)要降低 30%、人工復(fù)核率要低于 20%。三是“邊界清單”明確 agent 在什么情況下必須轉(zhuǎn)人工、什么事情絕不允許 agent 自動(dòng)決定。邊界清單比能力說(shuō)明更重要因?yàn)樗x了兜底安全網(wǎng)。POC 的周期我建議控制在四周以內(nèi)。第一周做數(shù)據(jù)抽取和基線復(fù)核第二周搭最小協(xié)作模型第三周在前兩周基礎(chǔ)上做規(guī)則補(bǔ)全和 prompt 調(diào)優(yōu)第四周并行試運(yùn)行、收集反饋并凍結(jié)效果數(shù)據(jù)。拖得越久業(yè)務(wù)方越容易失去耐心產(chǎn)品口碑越難建立。4.4 第四步規(guī)模化部署從“跑通”走向“能養(yǎng)”P(pán)OC 通過(guò)后規(guī)?；渴鹈鎸?duì)的是另一批問(wèn)題權(quán)限管理、審計(jì)日志、監(jiān)控告警、持續(xù)迭代機(jī)制。權(quán)限和審計(jì)在垂直行業(yè)里不是“加分項(xiàng)”而是入場(chǎng)券。agent 調(diào)用哪些數(shù)據(jù)、做了哪些操作、給誰(shuí)發(fā)了通知必須有完整記錄這既是合規(guī)要求也是出錯(cuò)后有據(jù)可查的基礎(chǔ)。監(jiān)控方面我比較看重兩類告警一類是效果類告警比如人工復(fù)核率突然升高說(shuō)明 agent 的輸出質(zhì)量在下降可能是上游數(shù)據(jù)變化導(dǎo)致的。另一類是流程類告警比如某類請(qǐng)求在規(guī)則引擎里大量觸發(fā)“未匹配分支”說(shuō)明業(yè)務(wù)出現(xiàn)了新情況規(guī)則庫(kù)需要及時(shí)更新。持續(xù)迭代機(jī)制是垂直方案區(qū)別于普通軟件項(xiàng)目的關(guān)鍵。行業(yè)規(guī)則、業(yè)務(wù)數(shù)據(jù)、客戶需求都會(huì)變固定版本的部署模式不適用于 Multi-Agent 產(chǎn)品。我在項(xiàng)目里會(huì)預(yù)留一個(gè)輕量級(jí)的“規(guī)則更新”運(yùn)營(yíng)流程由業(yè)務(wù)方代表每周審核一次新增/變更規(guī)則確認(rèn)后由產(chǎn)品團(tuán)隊(duì)實(shí)施更新。這樣產(chǎn)品既靈活又有邊界不會(huì)變成無(wú)人維護(hù)的一次性項(xiàng)目。5. 我踩過(guò)的五個(gè)坑角色、協(xié)議、評(píng)測(cè)與成本5.1 以為 agent 能當(dāng)“流程專家”實(shí)際它只適合做“流程演員”最早在某個(gè)項(xiàng)目里我試圖讓一個(gè)“主導(dǎo) agent”來(lái)動(dòng)態(tài)判斷流程路徑想著這樣更智能。結(jié)果發(fā)現(xiàn)它經(jīng)常在自己不確定的時(shí)候自作主張地跳到某個(gè)分支而且跳錯(cuò)之后沒(méi)有任何容錯(cuò)機(jī)制。后來(lái)我很后悔——當(dāng)時(shí)太迷信模型的推理能力。糾正后所有決定流程走向的邏輯都搬回確定性代碼和規(guī)則引擎agent 只負(fù)責(zé)把指定步驟演好。如果你的垂直場(chǎng)景里發(fā)現(xiàn) agent 經(jīng)常需要判斷“下一步該干嘛”說(shuō)明你的流程劇本還沒(méi)寫(xiě)好。好的劇本不會(huì)給演員太多臨場(chǎng)發(fā)揮的發(fā)揮空間。5.2 職責(zé)過(guò)寬的 agent是系統(tǒng)最大的不穩(wěn)定性來(lái)源另一個(gè)典型錯(cuò)誤是角色設(shè)計(jì)貪大。一開(kāi)始我設(shè)計(jì)過(guò)一個(gè)“全流程協(xié)調(diào) agent”讓它同時(shí)負(fù)責(zé)意圖識(shí)別、數(shù)據(jù)檢查、方案生成、結(jié)果解釋。邏輯上覺(jué)得自己少寫(xiě)了好幾個(gè) agent實(shí)際上這個(gè) agent 的 prompt 極其臃腫每次任務(wù)要攜帶的上下文巨大回答風(fēng)格在不同任務(wù)間漂移調(diào)試時(shí)完全不知道該改哪里。后來(lái)我把這個(gè) agent 拆成四個(gè)職責(zé)非常單一的小 agent識(shí)別只做識(shí)別檢索只做檢索決策只做決策表達(dá)只做表達(dá)。看起來(lái)數(shù)量變多了但每個(gè)都很穩(wěn)定測(cè)試用例可以覆蓋完整性能總和反而提升。多智能體的正確用法是“能力足夠小邊界足夠清”。5.3 過(guò)早把 agent 間的通信協(xié)議“標(biāo)準(zhǔn)化”導(dǎo)致后期返工做通用工具時(shí)留存下來(lái)的一個(gè)習(xí)慣是把 agent 之間的通信協(xié)議設(shè)計(jì)得特別超前。比如我早期就定義了完整的消息總線、事件溯源、歷史回溯機(jī)制。聽(tīng)起來(lái)很高級(jí)但實(shí)際上在業(yè)務(wù)還不穩(wěn)定時(shí)這些機(jī)制反而拖慢迭代。在垂直方案里agent 通信協(xié)議第一步只要約定好最簡(jiǎn)單的 JSON 格式就夠了關(guān)鍵字段、調(diào)用方、任務(wù) ID、數(shù)據(jù)載荷。等流程跑通、理解了真實(shí)的數(shù)據(jù)流之后再?zèng)Q定哪些信息需要持久化、哪些需要事件機(jī)制、哪些可以做重試。過(guò)早的架構(gòu)抽象在大模型時(shí)代是浪費(fèi)時(shí)間因?yàn)楫a(chǎn)品形態(tài)演進(jìn)得太快前期定義得再完美后期大概率都要推翻。5.4 沒(méi)有先建立人工基線上線后差點(diǎn)背鍋這是最狼狽的一次。當(dāng)時(shí)我們給一個(gè)客戶的法務(wù)團(tuán)隊(duì)做合同風(fēng)險(xiǎn)預(yù)審 agentPOC 階段自己覺(jué)得效果不錯(cuò)準(zhǔn)確率也挺高在客戶內(nèi)部試運(yùn)行時(shí)反饋也積極。結(jié)果要寫(xiě)效果報(bào)告時(shí)客戶問(wèn)了一句“你們說(shuō)的準(zhǔn)確率跟人工審核的準(zhǔn)確率比怎么樣”我們愣住了因?yàn)槲覀儔焊鶝](méi)有拉過(guò)人工審核的歷史結(jié)果數(shù)據(jù)。后來(lái)補(bǔ)了半個(gè)月數(shù)據(jù)才發(fā)現(xiàn)人工審核對(duì)某類風(fēng)險(xiǎn)的召回率其實(shí)非常高agent 的優(yōu)勢(shì)根本沒(méi)有那么大。這件事教會(huì)我一個(gè)鐵律任何效果聲明都必須有一個(gè)“對(duì)照組基線”。沒(méi)有參考系的高準(zhǔn)確率沒(méi)有意義尤其當(dāng)客戶已經(jīng)在用某個(gè)基準(zhǔn)工作的時(shí)候。5.5 無(wú)限輪次協(xié)作的魔鬼藏在 token 賬單里成本問(wèn)題前面講過(guò)這里補(bǔ)充一個(gè)具體的教訓(xùn)。某次給客戶做多語(yǔ)言客服工單分類設(shè)計(jì)時(shí)用了兩個(gè) agent 來(lái)回協(xié)作一個(gè)做意圖識(shí)別一個(gè)做情感分析最后還有個(gè)聚合 agent。邏輯正常但真實(shí)數(shù)據(jù)里有大量噪音和歧義。有的工單觸發(fā) retryagent 之間會(huì)反復(fù)就同一個(gè)問(wèn)題多次確認(rèn)。月底看賬單token 消耗超出預(yù)估的 4 倍多客戶險(xiǎn)些叫停項(xiàng)目。從那以后我所有項(xiàng)目都強(qiáng)制設(shè)置硬性上限單個(gè)任務(wù)的協(xié)作輪數(shù)不超過(guò)兩輪超出直接轉(zhuǎn)人工或者走保底規(guī)則每個(gè) agent 的工具調(diào)用次數(shù)單獨(dú)計(jì)數(shù)上線前做一次基于真實(shí)語(yǔ)料數(shù)據(jù)的成本模擬。大模型能力再?gòu)?qiáng)也抵不過(guò)無(wú)節(jié)制地空轉(zhuǎn)。寫(xiě)在最后的一點(diǎn)體會(huì)從通用工具轉(zhuǎn)向垂直行業(yè)解決方案回頭看并不是一個(gè)“降維”的過(guò)程反而是對(duì) Multi-Agent 認(rèn)知的一次升級(jí)。通用工具讓人看見(jiàn)技術(shù)的可能性垂直方案才讓人真的可以把技術(shù)變成利潤(rùn)表上的數(shù)字。我現(xiàn)在做新項(xiàng)目很少再問(wèn)“這里能不能塞一個(gè) agent”而是先問(wèn)“這個(gè)環(huán)節(jié)的業(yè)務(wù)規(guī)則是什么、數(shù)據(jù)在哪、失敗了下限是否可以被接受”。如果這三個(gè)問(wèn)題沒(méi)有答案再?gòu)?qiáng)的多智能體架構(gòu)也只是空中樓閣。如果你正打算在這個(gè)方向推產(chǎn)品我的建議很簡(jiǎn)單別貪多選一個(gè)足夠痛、足夠窄的場(chǎng)景把流程劇本、知識(shí)底座、評(píng)測(cè)基線三件事做扎實(shí)然后用一個(gè)真實(shí)的業(yè)務(wù)指標(biāo)證明給客戶看。初期的幾個(gè)成功案例比任何架構(gòu)理念都更有說(shuō)服力。Multi-Agent 本身不是產(chǎn)品產(chǎn)品是它在某個(gè)業(yè)務(wù)里交付的明確結(jié)果。