近兩年 Agent 項(xiàng)目的熱度一直沒(méi)降過(guò)但真正能把 Agent 從“能跑通的 Demo”推到“穩(wěn)定服務(wù)用戶的生產(chǎn)系統(tǒng)”的團(tuán)隊(duì)少之又少。我見過(guò)太多項(xiàng)目卡在同一個(gè)地方單輪對(duì)話表現(xiàn)驚艷多輪一跑就亂精心設(shè)計(jì)的 CoT 提示詞在 Demo 數(shù)據(jù)上效果很好換一波真實(shí)用戶請(qǐng)求就頻繁出錯(cuò)單智能體勉強(qiáng)可用一上多智能體協(xié)作就會(huì)出現(xiàn)互相覆蓋狀態(tài)、重復(fù)調(diào)用工具、成本翻倍的問(wèn)題。這篇文章不講花哨概念只講我從實(shí)際項(xiàng)目里拆出來(lái)的東西Agent 的架構(gòu)分層、多智能體系統(tǒng)的協(xié)作模式以及從 Demo 走向生產(chǎn)時(shí)要補(bǔ)齊的工程化能力。適合已經(jīng)在做 Agent 應(yīng)用、正準(zhǔn)備做多智能體改造、或者想把原型推向生產(chǎn)的開發(fā)者看。1. Agent 的架構(gòu)先看清那套“無(wú)人駕駛”的隱喻很多人聊 Agent 架構(gòu)喜歡拿“自動(dòng)駕駛”類比說(shuō) Agent 就是讓大模型像司機(jī)一樣自主決策。這個(gè)類比有道理但不完整——自動(dòng)駕駛有明確的交通規(guī)則、傳感器融合和冗余設(shè)計(jì)Agent 生產(chǎn)系統(tǒng)同樣需要這套東西只是我們把“傳感器”換成了工具調(diào)用把“交通規(guī)則”換成了狀態(tài)機(jī)和權(quán)限控制。1.1 Agent 的四個(gè)基礎(chǔ)模塊拆解我在實(shí)際項(xiàng)目里習(xí)慣把一個(gè) Agent 拆成四層來(lái)看感知層、決策層、行動(dòng)層、記憶層。這四層不只是一個(gè)概念框架它直接決定了代碼怎么組織、異常往哪里拋、日志在哪里打。感知層負(fù)責(zé)接收用戶輸入并完成意圖識(shí)別和實(shí)體抽取。這一層最容易犯的錯(cuò)誤是直接把原始用戶輸入扔給大模型缺少結(jié)構(gòu)化的意圖解析。我見過(guò)一個(gè)客服場(chǎng)景的 Agent用戶說(shuō)“我要退換貨”模型直接去調(diào)用退款接口結(jié)果用戶其實(shí)是想問(wèn)退貨政策——這就是感知層沒(méi)有做意圖分類導(dǎo)致的連鎖錯(cuò)誤。正確的做法是在感知層先做一次輕量分類搞清楚用戶是咨詢、操作還是投訴再進(jìn)入后續(xù)決策鏈路。決策層是 Agent 的“大腦”負(fù)責(zé)規(guī)劃任務(wù)、選擇工具、拆分步驟。這里最核心的機(jī)制是 ReAct 循環(huán)也就是“思考-行動(dòng)-觀察”的循環(huán)。規(guī)劃不是一次性的Agent 需要在執(zhí)行過(guò)程中不斷根據(jù)中間結(jié)果修正計(jì)劃。我在早期實(shí)現(xiàn)中吃過(guò)虧——用了一次性規(guī)劃就讓 Agent 按部就班執(zhí)行結(jié)果中間一步失敗后整個(gè)任務(wù)就死了。后來(lái)改成逐步規(guī)劃、逐步校正成功率明顯提升。行動(dòng)層就是工具調(diào)用的執(zhí)行層。這一層要解決的不僅是“調(diào)不調(diào)得動(dòng)”更是“調(diào)得對(duì)不對(duì)”。工具的參數(shù)校驗(yàn)、權(quán)限校驗(yàn)、超時(shí)控制、結(jié)果解析都應(yīng)該在這一層做標(biāo)準(zhǔn)化處理。我建議把工具調(diào)用封裝成統(tǒng)一協(xié)議輸入一個(gè)結(jié)構(gòu)化的 JSON輸出一個(gè)結(jié)構(gòu)化的 JSON哪怕是調(diào)用一個(gè)內(nèi)部 HTTP 接口也走同一套包裝。這樣后續(xù)有多智能體協(xié)作時(shí)工具層可以無(wú)縫復(fù)用到不同 Agent 上。記憶層分為短期記憶和長(zhǎng)期記憶。短期記憶是當(dāng)前會(huì)話的上下文長(zhǎng)期記憶是用戶偏好、歷史事實(shí)這類跨會(huì)話信息。很多項(xiàng)目把記憶簡(jiǎn)單理解成“把歷史聊天記錄塞進(jìn)上下文”這是誤區(qū)——短期記憶要做摘要壓縮長(zhǎng)期記憶要做向量檢索加事實(shí)校驗(yàn)。1.2 架構(gòu)選型背后的關(guān)鍵取舍選 Agent 架構(gòu)時(shí)要先想清楚一個(gè)問(wèn)題你需要的是一把刀還是一套廚房單體 Agent 適合任務(wù)路徑明確、工具數(shù)量少的場(chǎng)景多智能體系統(tǒng)適合子任務(wù)可并行、角色邊界清晰的場(chǎng)景。單 Agent 的優(yōu)勢(shì)是狀態(tài)管理簡(jiǎn)單所有上下文都在一個(gè)對(duì)話鏈路里不會(huì)出現(xiàn)消息傳遞丟失的問(wèn)題。但它的天花板也很明顯當(dāng)工具數(shù)量超過(guò) 20 個(gè)時(shí)工具描述和調(diào)用記錄的 token 開銷會(huì)迅速膨脹而且單點(diǎn)故障是致命的一旦決策錯(cuò)誤就是整體失敗。多 Agent 的優(yōu)勢(shì)是角色隔離和故障隔離但它引入了一個(gè)新的問(wèn)題——通信協(xié)議設(shè)計(jì)。Agent 之間用什么語(yǔ)言交流共享內(nèi)存還是消息傳遞這些問(wèn)題在 Demo 階段可以含糊在生產(chǎn)階段必須白紙黑字定清楚。我建議的生產(chǎn)落地策略是漸進(jìn)式的先跑通單 Agent確認(rèn)單 Agent 的瓶頸具體在哪再?zèng)Q定是否拆分成多 Agent。如果是上下文長(zhǎng)度不夠?qū)е碌膯?wèn)題優(yōu)先做記憶壓縮而不是拆 Agent如果是任務(wù)類型差異太大導(dǎo)致指令沖突才考慮拆。1.3 狀態(tài)機(jī)Agent 循環(huán)的隱藏骨架這是我特別想強(qiáng)調(diào)的一點(diǎn)——Agent 循環(huán)本質(zhì)是一個(gè)狀態(tài)機(jī)而不是一段無(wú)限的 while 循環(huán)。生產(chǎn)系統(tǒng)里最危險(xiǎn)的就是讓大模型自由決定“什么時(shí)候結(jié)束”模型可能會(huì)陷入死循環(huán)也可能在任務(wù)沒(méi)完成時(shí)就過(guò)早收尾。我在項(xiàng)目中定義了五個(gè)核心狀態(tài)INIT、PLANNING、EXECUTING、OBSERVING、FINISHED加上兩個(gè)異常態(tài)TIMEOUT 和 ERROR。Agent 就在這些狀態(tài)之間流轉(zhuǎn)每一步都記錄狀態(tài)遷移日志。這讓調(diào)試變得直接可追蹤——用戶投訴說(shuō) Agent 反應(yīng)不對(duì)我拉出狀態(tài)機(jī)日志一看就知道卡在哪一步。狀態(tài)設(shè)計(jì)的關(guān)鍵是要顯式定義“終止條件”。一個(gè)任務(wù)什么時(shí)候算完成是用戶確認(rèn)了還是工具執(zhí)行成功了還是達(dá)到最大步數(shù)了這三個(gè)條件的優(yōu)先級(jí)是什么我踩過(guò)的坑是讓 Agent 自己判斷“是否完成”結(jié)果它經(jīng)常覺得“差不多了”就提前結(jié)束用戶根本還沒(méi)確認(rèn)。后來(lái)改成強(qiáng)約束只有用戶明確確認(rèn)或人工審核通過(guò)任務(wù)才允許進(jìn)入 FINISHED 狀態(tài)。2. 多智能體協(xié)作從單兵作戰(zhàn)到團(tuán)隊(duì)協(xié)作單 Agent 做不了的事多智能體不一定就能做。但在某些特定場(chǎng)景下多 Agent 的收益是實(shí)實(shí)在在的。這章節(jié)我用實(shí)際經(jīng)驗(yàn)聊聊什么時(shí)候該拆、怎么編排、以及協(xié)作時(shí)最容易掉進(jìn)去的坑。2.1 為什么需要多智能體我最早做多 Agent 是被一個(gè)實(shí)際需求逼的一個(gè)企業(yè)知識(shí)庫(kù)問(wèn)答系統(tǒng)原本只有單個(gè) Agent既要做意圖識(shí)別又要做知識(shí)庫(kù)檢索還要做權(quán)限過(guò)濾提示詞越寫越長(zhǎng)模型越來(lái)越“精神分裂”——回復(fù)咨詢時(shí)帶著操作味處理操作時(shí)又忍不住解釋。拆分的核心動(dòng)力不是“多智能體聽起來(lái)更高級(jí)”而是角色沖突的不可調(diào)和性?！安僮鲉T Agent”需要簡(jiǎn)潔直接、快速調(diào)工具“會(huì)話 Agent”需要禮貌周全、解釋清楚“審查 Agent”需要嚴(yán)格挑剔、不輕易放行。三種角色塞進(jìn)同一套提示詞誰(shuí)都會(huì)內(nèi)耗。多 Agent 的收益第一是上下文隔離。每個(gè) Agent 只需關(guān)注自己角色的指令和工具上下文更干凈決策噪聲更少。第二是故障隔離。某個(gè) Agent 出問(wèn)題不會(huì)連帶整個(gè)鏈路崩潰可以有重試和降級(jí)空間。第三是并行能力。檢索、分析、生成這類無(wú)依賴的子任務(wù)可以分頭執(zhí)行延遲從串行相加變成并行取最大。2.2 常見的協(xié)作編排模式多 Agent 協(xié)作的編排模式我根據(jù)自己的項(xiàng)目經(jīng)驗(yàn)總結(jié)出四種常用且易落地的主管-下屬模式一個(gè)主管 Agent 負(fù)責(zé)任務(wù)拆解和結(jié)果匯合多個(gè)下屬 Agent 分別處理子任務(wù)。適合任務(wù)類型多樣、需要統(tǒng)一調(diào)度的場(chǎng)景穩(wěn)定性高但主管可能成為瓶頸。流水線模式任務(wù)按固定順序依次經(jīng)過(guò)多個(gè) Agent每個(gè) Agent 只處理自己擅長(zhǎng)的一環(huán)。適合流程固定、順序依賴強(qiáng)的場(chǎng)景比如說(shuō)內(nèi)容審核流水線初篩、深度審查、格式校驗(yàn)三道關(guān)卡。市場(chǎng)模式多個(gè) Agent 爭(zhēng)搶任務(wù)根據(jù)匹配度或報(bào)價(jià)決定誰(shuí)來(lái)處理。這種模式最靈活但也最難控制我建議除非必要否則不要輕易上。辯論模式多個(gè) Agent 分別提出方案并互相質(zhì)詢最后投票或由裁決者拍板。適合高風(fēng)險(xiǎn)決策場(chǎng)景比如大額審批、內(nèi)容合規(guī)判斷但 token 開銷巨大。這四種模式可以嵌套使用比如主管下屬模式中的某個(gè)下屬本身是一個(gè)小型辯論團(tuán)隊(duì)。但嵌套越多鏈路越復(fù)雜越難排查問(wèn)題。我的建議是控制深度——兩級(jí)嵌套是上限超過(guò)兩級(jí)的系統(tǒng)一定要先把基礎(chǔ)的可觀測(cè)性和重試機(jī)制做扎實(shí)再上。2.3 協(xié)作通信消息協(xié)議與共享狀態(tài)多 Agent 之間怎么通信這個(gè)問(wèn)題在 Demo 階段經(jīng)常被忽略但它是生產(chǎn)系統(tǒng)最先爆炸的地方。我見過(guò)兩種極端做法一種是什么都走共享全局狀態(tài)所有 Agent 都能讀寫同一個(gè)大 JSON結(jié)果一個(gè) Agent 改壞了字段其他 Agent 全崩另一種是 Agent 之間直接傳自然語(yǔ)言消息靠大模型理解結(jié)果消息越傳越偏一輪過(guò)后任務(wù)就跑題了。我的做法是結(jié)構(gòu)化消息加開放接口。Agent 與 Agent 之間不發(fā)自然語(yǔ)言句子而是發(fā)結(jié)構(gòu)化的任務(wù)對(duì)象包含任務(wù) ID、輸入?yún)?shù)、預(yù)期輸出 schema、截止時(shí)間。這樣每個(gè) Agent 只需要按 schema 解析輸入、填充輸出不依賴自然語(yǔ)言理解也能協(xié)作。自然語(yǔ)言描述只作為人可讀的調(diào)試輔助字段存在。共享狀態(tài)不是完全不能有但必須分級(jí)。全局共享的只有角色無(wú)關(guān)的、只讀的公共信息可寫狀態(tài)必須歸屬于某個(gè) Agent其他 Agent 只能通過(guò)接口去讀。這樣才能理清出問(wèn)題時(shí)到底是誰(shuí)改壞了數(shù)據(jù)。2.4 多 Agent 協(xié)作容易踩的坑多 Agent 系統(tǒng)的坑個(gè)個(gè)都是生產(chǎn)事故級(jí)別的。通信開銷膨脹是我最先撞上的坑。多個(gè) Agent 來(lái)回傳遞消息每一步都在消耗 token一輪任務(wù)下來(lái)開銷比單 Agent 高三四倍。優(yōu)化方向是能并行就并行能精簡(jiǎn)就精簡(jiǎn)主管只做拆解和匯合不要干預(yù)下屬的每一步細(xì)節(jié)。死循環(huán)是第二個(gè)坑。兩個(gè) Agent 互相等待對(duì)方確認(rèn)或者 A 把 B 的輸出當(dāng)作自己的輸入反復(fù)處理這種問(wèn)題用人工檢查很難發(fā)現(xiàn)因?yàn)閷?duì)話看起來(lái)還挺合理。我的做法是全局統(tǒng)一的步數(shù)上限和超時(shí)中斷每個(gè)任務(wù)最多執(zhí)行 N 步超時(shí)強(qiáng)制走降級(jí)流程。第三個(gè)坑是角色退化。多個(gè) Agent 跑久了會(huì)互相同化——下屬 Agent 開始模仿主管的口吻和策略審查 Agent 開始放松標(biāo)準(zhǔn)當(dāng)老好人。這和提示詞里角色設(shè)定不夠強(qiáng)有關(guān)也和行為反饋機(jī)制缺失有關(guān)。解決思路是定期用評(píng)估集測(cè)試每個(gè) Agent 的獨(dú)立表現(xiàn)不只看整體鏈路效果。3. 從 Demo 到生產(chǎn)真實(shí)的工程化差距Demo 和生產(chǎn)之間的差距可以用一句話概括Demo 證明“能跑”生產(chǎn)要求“能扛、能查、能修、能評(píng)估”。3.1 Demo 看著能跑生產(chǎn)卻總出錯(cuò)的原因很多人以為 Demo 到生產(chǎn)只是部署環(huán)境的區(qū)別實(shí)則不然。我拆過(guò)自己的項(xiàng)目也幫朋友排查過(guò)類似問(wèn)題發(fā)現(xiàn)幾個(gè)共性的錯(cuò)位。Demo 的測(cè)試數(shù)據(jù)是挑過(guò)的。不管有意無(wú)意Demo 用的都是我們自己準(zhǔn)備的數(shù)據(jù)覆蓋的是“理想場(chǎng)景”用戶的真實(shí)輸入往往是含糊的、帶情緒的、有錯(cuò)別字的、省略上下文的。生產(chǎn)環(huán)境里這些雜音才是常態(tài)。Demo 是單輪驗(yàn)證生產(chǎn)是多輪長(zhǎng)期運(yùn)行。單輪問(wèn)答表現(xiàn)好不代表多輪對(duì)話狀態(tài)能保持住。用戶有可能中途改口、撤回請(qǐng)求、追問(wèn)半年之前的某個(gè)細(xì)節(jié)——這些在 Demo 里都不會(huì)出現(xiàn)生產(chǎn)里全都會(huì)來(lái)。Demo 的成功標(biāo)準(zhǔn)是“看起來(lái)有道理”生產(chǎn)的成功標(biāo)準(zhǔn)是“精確完成任務(wù)”。比如信息查詢類 AgentDemo 里答得不完整用戶可能還能忍生產(chǎn)環(huán)境里手續(xù)費(fèi)算錯(cuò)一分錢就是事故。這種容錯(cuò)的消失要求 Agent 的每一步都有可量化的正確性保障。另外一個(gè)隱蔽的錯(cuò)位是工具的真實(shí)狀態(tài)。Demo 里工具都是 mock 的返回值干凈整潔生產(chǎn)里工具是真實(shí)系統(tǒng)有網(wǎng)絡(luò)延遲、有返回超時(shí)、有數(shù)據(jù)異常、有并發(fā)沖突。Agent 調(diào)工具失敗后如何重試、如何降級(jí)、如何向用戶交代——這是工程化必須要回答的問(wèn)題。3.2 六個(gè)必須補(bǔ)齊的工程化能力從我的實(shí)踐出發(fā)一個(gè) Agent 要從 Demo 走到生產(chǎn)至少需要補(bǔ)齊下面六個(gè)能力。第一是可靠的執(zhí)行環(huán)境。Agent 不能直接裸跑在 request 里要有一個(gè)受控的執(zhí)行環(huán)境支持超時(shí)熔斷、內(nèi)存限制、并發(fā)配額。每一輪 Agent 循環(huán)都要有明確的時(shí)間盒超過(guò)設(shè)定時(shí)間就要中斷或降級(jí)。第二是可觀測(cè)性。大模型是不確定的這意味著 Agent 的行為天然比傳統(tǒng)程序更難排查。必須從一開始就埋好全鏈路的 trace用戶的原始輸入、模型每一步的思考、工具調(diào)用的入?yún)⒊鰠?、中間狀態(tài)遷移全部留痕。我之前在一個(gè)客服 Agent 項(xiàng)目里靠完善的 trace 定位到 80% 以上的問(wèn)題沒(méi)有 trace 那這些問(wèn)題的排查根本無(wú)從下手。第三是評(píng)估體系。沒(méi)有評(píng)估體系A(chǔ)gent 的迭代就是盲改。要建設(shè)“離線評(píng)估集 在線指標(biāo) 回歸測(cè)試”三層防護(hù)。離線評(píng)估集至少要準(zhǔn)備幾百條真實(shí)分布的問(wèn)題覆蓋正常、邊緣、異常三類輸入在線指標(biāo)關(guān)注任務(wù)成功率、用戶反饋率、平均耗時(shí)每一次改動(dòng)都要跑回歸看是否引入了新問(wèn)題。第四是權(quán)限與安全控制。Agent 能調(diào)用的工具必須經(jīng)過(guò)權(quán)限校驗(yàn)高危操作必須有二次確認(rèn)或人工審批。這個(gè)在 Demo 里可以省略生產(chǎn)環(huán)境里省略的后果可能是直接事故。第五是成本控制。生產(chǎn)環(huán)境里 token 費(fèi)用是真實(shí)的運(yùn)營(yíng)成本。要做的優(yōu)化包括模型分級(jí)、緩存命中、批量推理、上下文壓縮。我見過(guò)不加控制的項(xiàng)目單次任務(wù)消耗幾十萬(wàn) token成本完全不可持續(xù)。第六是兜底降級(jí)方案。Agent 肯定會(huì)失敗。生產(chǎn)系統(tǒng)必須要預(yù)設(shè)失敗的兜底路徑模型超時(shí)了直接轉(zhuǎn)人工客服工具失敗后給用戶一個(gè)明確的錯(cuò)誤說(shuō)明而不是讓模型編一個(gè)結(jié)果這些兜底邏輯必須提前寫好。3.3 案例拆解為什么同一個(gè) Demo 在兩個(gè)項(xiàng)目里差這么多我朋友做過(guò)一個(gè)內(nèi)部知識(shí)庫(kù)問(wèn)答 Agent同樣的技術(shù)架構(gòu)基本一樣的提示詞在 A 公司跑得很順在 B 公司卻問(wèn)題頻發(fā)。剛開始以為是大模型的問(wèn)題后來(lái)排查發(fā)現(xiàn)根因在數(shù)據(jù)層。A 公司的知識(shí)庫(kù)是結(jié)構(gòu)化的問(wèn)答對(duì)檢索命中率高B 公司的知識(shí)庫(kù)是大量非結(jié)構(gòu)化的技術(shù)文檔很多問(wèn)題根本檢索不到答案。模型在檢索不到答案時(shí)會(huì)“試圖”湊一個(gè)答案出來(lái)這在 Demo 里不顯眼但在生產(chǎn)里就是嚴(yán)重的信任問(wèn)題。這個(gè)案例給我的啟發(fā)是Agent 系統(tǒng)的上限往往不取決于模型多強(qiáng)而取決于數(shù)據(jù)層、工具層、業(yè)務(wù)層的支撐能力。工程化改造不能只關(guān)注 Agent 內(nèi)部的算法鏈路還要打通上下游的數(shù)據(jù)質(zhì)量和工具穩(wěn)定性。這個(gè)鏈條上任何一環(huán)薄弱Agent 都會(huì)在生產(chǎn)環(huán)境里暴露出來(lái)。4. 落地實(shí)操漸進(jìn)式遷移路線與關(guān)鍵步驟理論說(shuō)完了說(shuō)點(diǎn)能直接上手的。以下是我在一個(gè)客服 Agent 項(xiàng)目里驗(yàn)證過(guò)的落地路線四步走鎖定邊界、改造調(diào)度、建立可觀測(cè)、優(yōu)化迭代。每一步都有關(guān)鍵動(dòng)作和要避開的雷區(qū)。4.1 第一步從 Demo 鎖定能力邊界落地做的第一件事不是寫代碼是畫能力邊界。拿一張大白紙把“這個(gè) Agent 在第一個(gè)生產(chǎn)版本里必須要做的事”和“絕對(duì)不碰的事”分別列出來(lái)。必須要做的事列的是核心高頻場(chǎng)景比如客服 Agent 的訂單查詢、物流查詢、常見問(wèn)題解答。絕對(duì)不碰的事列的是高風(fēng)險(xiǎn)或低確定性場(chǎng)景比如情緒化投訴處理、大額退款決策、多輪復(fù)雜協(xié)商——這類場(chǎng)景先轉(zhuǎn)人工等 Agent 跑穩(wěn)了再逐步灰度接入。這一步的邏輯是生產(chǎn)系統(tǒng)上線不是證明 Agent 多能干而是先證明 Agent 在受控范圍內(nèi)可靠。我見過(guò)很多項(xiàng)目死在“想一次解決所有問(wèn)題”上模型一遇到邊界外場(chǎng)景就胡說(shuō)用戶信任度瞬間歸零。反過(guò)來(lái)能力邊界清晰、拒絕果斷的 Agent 反而更容易贏得用戶信任。關(guān)鍵動(dòng)作是定義清晰的“拒答”策略。明確什么場(chǎng)景下 Agent 必須說(shuō)“這個(gè)我處理不了轉(zhuǎn)人工”拒絕本身不是失敗亂答才是。4.2 第二步改造調(diào)度與狀態(tài)管理Demo 里的 Agent 循環(huán)通常是“模型自己決定下一步”生產(chǎn)環(huán)境里要把這套改造得更受控。我推薦的做法是接入可編排的調(diào)度框架把任務(wù)的運(yùn)行方式從“模型自驅(qū)”變成“平臺(tái)可控”。在自研場(chǎng)景下實(shí)現(xiàn)思路是多加一道調(diào)度層調(diào)度層規(guī)定 Agent 每一步可選的操作范圍、每步最大耗時(shí)、全局最大步數(shù)一旦越界調(diào)度層強(qiáng)制切斷。這樣即使模型推理出錯(cuò)也只會(huì)執(zhí)行調(diào)度層允許范圍內(nèi)的動(dòng)作風(fēng)險(xiǎn)被限制在一定幅度內(nèi)。多 Agent 場(chǎng)景下狀態(tài)管理更是重中之重。要有一個(gè)全局的運(yùn)行時(shí)狀態(tài)存儲(chǔ)記錄每個(gè)任務(wù)的狀態(tài)遷移軌跡。每個(gè) Agent 的消息收發(fā)都要經(jīng)過(guò)這個(gè)運(yùn)行時(shí)方便觀察全局而不是一個(gè)黑盒。另外工具層同步做統(tǒng)一注冊(cè)和鑒權(quán)。工具清單集中管理工具的入?yún)⒑统鰠?schema 注冊(cè)在案調(diào)用要過(guò)權(quán)限校驗(yàn)。不要允許 Agent 自由調(diào)用任何內(nèi)部接口這是生產(chǎn)安全的基本底線。4.3 第三步建立可觀測(cè)性和評(píng)估體系沒(méi)有可觀測(cè)性談生產(chǎn)就是空話。我在 Agent 項(xiàng)目里至少接入三類遙測(cè)數(shù)據(jù)日志、指標(biāo)、追蹤。日志至少要覆蓋每一次模型調(diào)用的請(qǐng)求與響應(yīng)摘要、每一次工具調(diào)用的入?yún)⑴c出參、每一條狀態(tài)遷移記錄。指標(biāo)至少包括全局任務(wù)成功率、平均輪數(shù)、平均延遲、token 消耗分布、工具調(diào)用失敗率。追蹤要能把一個(gè)用戶請(qǐng)求全鏈路串起來(lái)看它經(jīng)過(guò)了哪些 Agent、哪些工具、在哪一步耗時(shí)最長(zhǎng)或出錯(cuò)。評(píng)估體系建設(shè)分三步走先準(zhǔn)備一批高質(zhì)量測(cè)試集覆蓋正常、邊緣、異常三類再制定打分標(biāo)準(zhǔn)并安排人工評(píng)估最后把評(píng)估固化進(jìn)發(fā)布流程任何 Prompt 或代碼改動(dòng)必須通過(guò)回歸評(píng)估才允許上線。在客服場(chǎng)景里我制定的評(píng)估指標(biāo)包括任務(wù)完成率用戶問(wèn)題得到有效解決的比例、工具調(diào)用準(zhǔn)確率實(shí)際調(diào)用是否正確、拒絕率不確定時(shí)正確拒答的比例、用戶滿意度回訪或評(píng)分。這套指標(biāo)定期跑每次改造都有數(shù)據(jù)對(duì)照。4.4 第四步成本與性能的持續(xù)優(yōu)化生產(chǎn)環(huán)境的成本是動(dòng)真格的。下面是幾個(gè)親測(cè)有效的優(yōu)化手段。模型分級(jí)策略簡(jiǎn)單意圖用輕量模型識(shí)別復(fù)雜推理用強(qiáng)模型。在客服場(chǎng)景意圖分類完全可以用輕量模型只有真正需要多步推理的任務(wù)才調(diào)用強(qiáng)模型。實(shí)測(cè)下來(lái)這樣最多能省去一半以上的“模型稅”。緩存策略對(duì)常見問(wèn)題的標(biāo)準(zhǔn)答案做精確緩存對(duì)相似問(wèn)題做語(yǔ)義緩存。語(yǔ)義緩存要注意閾值控制相關(guān)性不足時(shí)寧可不命中也不要把錯(cuò)誤答案返回給用戶。上下文壓縮策略不是每次請(qǐng)求都把全部歷史塞給模型而是把歷史摘要化只保留關(guān)鍵事實(shí)與用戶明確確認(rèn)過(guò)的信息。設(shè)計(jì)一套摘要更新機(jī)制讓新對(duì)話自動(dòng)覆蓋舊信息防止 token 無(wú)限膨脹。性能優(yōu)化方面關(guān)注兩個(gè)指標(biāo)首 token 延遲和端到端完成時(shí)間。前者受模型推理速度影響后者受工具調(diào)用鏈路影響?？梢赃m度并行化工具調(diào)用、縮短不必要的中間步驟、用流式輸出來(lái)提升用戶的等待體驗(yàn)。5. 常見問(wèn)題與排查技巧實(shí)錄模型的不確定性決定了 Agent 類系統(tǒng)的排障和普通后端系統(tǒng)完全兩個(gè)套路。任何 Agent 系統(tǒng)都會(huì)遇到同類的詭異問(wèn)題這一章把我踩過(guò)的坑和排查思路整理成了一份速查表順便拆一個(gè)實(shí)際的死循環(huán)案例。5.1 典型故障速查表現(xiàn)象可能原因排查思路任務(wù)反復(fù)不完成一直調(diào)用工具終止條件設(shè)計(jì)缺失模型眼里沒(méi)有“完成”邊界檢查狀態(tài)機(jī)遷移日志確認(rèn)是否存在包含循環(huán)的路徑補(bǔ)全局步數(shù)上限回答看似流暢但信息是編的檢索/工具未命中時(shí)模型“腦補(bǔ)”不肯承認(rèn)失敗檢查工具返回是否為空觀察模型是否有“猜測(cè)式回答”傾向引導(dǎo)在拿不到數(shù)據(jù)時(shí)明確說(shuō)明工具調(diào)用參數(shù)頻繁錯(cuò)誤工具描述模糊、入?yún)?schema 過(guò)于復(fù)雜簡(jiǎn)化和標(biāo)準(zhǔn)化工具描述把參數(shù)映射做進(jìn)執(zhí)行層必要時(shí)用正則約束枚舉值長(zhǎng)對(duì)話開始“忘事”或混淆細(xì)節(jié)上下文長(zhǎng)度超限、早期信息被截?cái)嗷驂嚎s失真檢查實(shí)際發(fā)送給模型的上下文長(zhǎng)度優(yōu)化摘要壓縮策略關(guān)鍵事實(shí)單獨(dú)置頂多 Agent 互相等對(duì)方任務(wù)卡住通信協(xié)議存在二義性雙方都在等一個(gè)不存在的信號(hào)查消息隊(duì)列中的未消費(fèi)消息檢查是否存在環(huán)狀依賴統(tǒng)一消息超時(shí)策略請(qǐng)求量一大接口頻繁限流模型 API 配額耗盡、并發(fā)請(qǐng)求過(guò)多做用量分級(jí)和流量整形為高優(yōu)任務(wù)預(yù)留配額非核心場(chǎng)景排隊(duì)或降級(jí)這些坑偶發(fā)性都很強(qiáng)日志和追蹤不到位時(shí)尤其難排查。我的經(jīng)驗(yàn)是先保證異常分支有日志每個(gè)“不該發(fā)生但模型做了”的行為都要留痕后續(xù)才能通過(guò)日志回放來(lái)分析。5.2 排障實(shí)例Agent 陷入死循環(huán)一個(gè)具體案例最能說(shuō)明問(wèn)題——一次客服 Agent 上線后某類退款咨詢總會(huì)長(zhǎng)時(shí)間不結(jié)束。從用戶角度看表現(xiàn)就是一直回復(fù)“讓我再確認(rèn)一下”卻遲遲不給出結(jié)論。隨后我拉出它的狀態(tài)機(jī)日志發(fā)現(xiàn)它始終在調(diào)用退款規(guī)則查詢工具、拿到結(jié)果、準(zhǔn)備回答、又認(rèn)為需要再核實(shí)。查對(duì)應(yīng)的工具調(diào)用記錄發(fā)現(xiàn)它反復(fù)用相同參數(shù)調(diào)用同一個(gè)查詢接口返回結(jié)果幾乎一致但模型每次都會(huì)選擇再次查詢而不是基于已有結(jié)果完成回答。根因有兩層。第一層是終止條件設(shè)計(jì)軟弱——提示詞里只說(shuō)“確認(rèn)無(wú)誤后回答”但對(duì)“什么算確認(rèn)無(wú)誤”沒(méi)有給出可判定的標(biāo)準(zhǔn)。模型沒(méi)有明確的規(guī)則可依據(jù)自然無(wú)法收斂。第二層是該場(chǎng)景缺少全局最大步數(shù)兜底模型想查多少次就能查多少次沒(méi)有外力打斷。修復(fù)方案分兩步。第一步是給該場(chǎng)景加上“最多查兩次查到結(jié)果后直接基于結(jié)果回答查詢失敗則轉(zhuǎn)人工并說(shuō)明“這種情況需要人工處理”的硬規(guī)則。第二步是補(bǔ)上全局兜底任何任務(wù)超過(guò)五步即強(qiáng)制終止并記錄告警。修復(fù)后這類問(wèn)題的發(fā)生頻率基本歸零。這個(gè)案例典型的點(diǎn)在于死循環(huán)未必是模型的“Bug”更多時(shí)候是系統(tǒng)設(shè)計(jì)沒(méi)有給模型足夠的收斂信號(hào)。Agent 排障時(shí)不要總想著“換更強(qiáng)的模型”先審視狀態(tài)機(jī)、終止條件和兜底邏輯是否閉環(huán)。5.3 一套可復(fù)用的排障方法論總結(jié)幾次排障經(jīng)歷我沉淀了一套對(duì) Agent 系統(tǒng)尤其對(duì)癥的排障方法論可以分成四步。第一步叫“回放”。從追蹤系統(tǒng)里拉出完整鏈路——輸入、思考、動(dòng)作、觀察按時(shí)間軸展開。大部分問(wèn)題的線索都會(huì)在回放里顯露出來(lái)。第二步叫“定位”。把問(wèn)題歸類到架構(gòu)四層里是感知層意圖識(shí)別錯(cuò)了還是決策層規(guī)劃出問(wèn)題了還是行動(dòng)層工具調(diào)錯(cuò)了或是記憶層上下文丟了。歸層之后再看模型以外有沒(méi)有工程原因比如超時(shí)、并寫、緩存策略很多問(wèn)題根源不在模型而在工程側(cè)拼圖缺失。第三步叫“最小化復(fù)現(xiàn)”。用一個(gè)最簡(jiǎn)單的輸入在測(cè)試環(huán)境里復(fù)現(xiàn)問(wèn)題。復(fù)現(xiàn)不出來(lái)就說(shuō)明問(wèn)題大概率跟特定上下文或狀態(tài)有關(guān)會(huì)進(jìn)一步縮小排查范圍。能穩(wěn)定復(fù)現(xiàn)反而好辦逐個(gè)消解變量就能找到觸發(fā)條件。第四步叫“加防護(hù)而非改提示詞”。排查清楚后先不急著調(diào) Prompt先想清楚該加哪個(gè)硬性防護(hù)比如狀態(tài)約束、超時(shí)熔斷、權(quán)限硬校驗(yàn)再考慮用示例或規(guī)則去引導(dǎo)模型行為。硬性防護(hù)兜底提示詞做引導(dǎo)兩者缺一不可只靠提示詞猜次數(shù)是治標(biāo)不治本。ChatGPT來(lái)了。 我并不是指某個(gè)具體的模型而是指Agent應(yīng)用已經(jīng)處在從“玩具”走向“工具”的階段。我對(duì)這個(gè)階段的體會(huì)是Agent的工程化深度決定了它最終的落地高度。Demo 里只能看到模型有多聰明生產(chǎn)環(huán)境里才能看出一套系統(tǒng)到底有多抗造。如果你正打算把一個(gè) Agent 原型推向生產(chǎn)我的建議是先冷靜地畫清楚能力邊界、再扎扎實(shí)實(shí)把狀態(tài)機(jī)、可觀測(cè)性、評(píng)估體系和兜底邏輯四件事做好。這四件事聽著不性感做起來(lái)也確實(shí)辛苦但它們是 Agent 從炫技變成服務(wù)的分水嶺。等你的 Agent 可以在沒(méi)有人工盯著的情況下穩(wěn)定完成 95% 的常規(guī)任務(wù)剩下 5% 能對(duì)用戶誠(chéng)實(shí)地說(shuō)“請(qǐng)稍等轉(zhuǎn)人工”你就真正跨越了從 Demo 到生產(chǎn)的那道坎。