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