近兩年 Agent 項(xiàng)目的熱度一直沒降過但真正能把 Agent 從“能跑通的 Demo”推到“穩(wěn)定服務(wù)用戶的生產(chǎn)系統(tǒng)”的團(tuán)隊(duì)少之又少。我見過太多項(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)用工具、成本翻倍的問題。這篇文章不講花哨概念只講我從實(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)化的意圖解析。我見過一個(gè)客服場(chǎng)景的 Agent用戶說(shuō)“我要退換貨”模型直接去調(diào)用退款接口結(jié)果用戶其實(shí)是想問退貨政策——這就是感知層沒有做意圖分類導(dǎo)致的連鎖錯(cuò)誤。正確的做法是在感知層先做一次輕量分類搞清楚用戶是咨詢、操作還是投訴再進(jìn)入后續(xù)決策鏈路。決策層是 Agent 的“大腦”負(fù)責(zé)規(guī)劃任務(wù)、選擇工具、拆分步驟。這里最核心的機(jī)制是 ReAct 循環(huán)也就是“思考-行動(dòng)-觀察”的循環(huán)。規(guī)劃不是一次性的Agent 需要在執(zhí)行過程中不斷根據(jù)中間結(jié)果修正計(jì)劃。我在早期實(shí)現(xiàn)中吃過虧——用了一次性規(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è)問題你需要的是一把刀還是一套廚房單體 Agent 適合任務(wù)路徑明確、工具數(shù)量少的場(chǎng)景多智能體系統(tǒng)適合子任務(wù)可并行、角色邊界清晰的場(chǎng)景。單 Agent 的優(yōu)勢(shì)是狀態(tài)管理簡(jiǎn)單所有上下文都在一個(gè)對(duì)話鏈路里不會(huì)出現(xiàn)消息傳遞丟失的問題。但它的天花板也很明顯當(dāng)工具數(shù)量超過 20 個(gè)時(shí)工具描述和調(diào)用記錄的 token 開銷會(huì)迅速膨脹而且單點(diǎn)故障是致命的一旦決策錯(cuò)誤就是整體失敗。多 Agent 的優(yōu)勢(shì)是角色隔離和故障隔離但它引入了一個(gè)新的問題——通信協(xié)議設(shè)計(jì)。Agent 之間用什么語(yǔ)言交流共享內(nèi)存還是消息傳遞這些問題在 Demo 階段可以含糊在生產(chǎn)階段必須白紙黑字定清楚。我建議的生產(chǎn)落地策略是漸進(jìn)式的先跑通單 Agent確認(rèn)單 Agent 的瓶頸具體在哪再?zèng)Q定是否拆分成多 Agent。如果是上下文長(zhǎng)度不夠?qū)е碌膯栴}優(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ù)沒完成時(shí)就過早收尾。我在項(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í)是什么我踩過的坑是讓 Agent 自己判斷“是否完成”結(jié)果它經(jīng)常覺得“差不多了”就提前結(jié)束用戶根本還沒確認(rèn)。后來(lái)改成強(qiáng)約束只有用戶明確確認(rèn)或人工審核通過任務(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ù)問答系統(tǒng)原本只有單個(gè) Agent既要做意圖識(shí)別又要做知識(shí)庫(kù)檢索還要做權(quán)限過濾提示詞越寫越長(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 出問題不會(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)過多個(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ù)雜越難排查問題。我的建議是控制深度——兩級(jí)嵌套是上限超過兩級(jí)的系統(tǒng)一定要先把基礎(chǔ)的可觀測(cè)性和重試機(jī)制做扎實(shí)再上。2.3 協(xié)作通信消息協(xié)議與共享狀態(tài)多 Agent 之間怎么通信這個(gè)問題在 Demo 階段經(jīng)常被忽略但它是生產(chǎn)系統(tǒng)最先爆炸的地方。我見過兩種極端做法一種是什么都走共享全局狀態(tài)所有 Agent 都能讀寫同一個(gè)大 JSON結(jié)果一個(gè) Agent 改壞了字段其他 Agent 全崩另一種是 Agent 之間直接傳自然語(yǔ)言消息靠大模型理解結(jié)果消息越傳越偏一輪過后任務(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 只能通過接口去讀。這樣才能理清出問題時(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ù)處理這種問題用人工檢查很難發(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í)則不然。我拆過自己的項(xiàng)目也幫朋友排查過類似問題發(fā)現(xiàn)幾個(gè)共性的錯(cuò)位。Demo 的測(cè)試數(shù)據(jù)是挑過的。不管有意無(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)行。單輪問答表現(xiàn)好不代表多輪對(duì)話狀態(tài)能保持住。用戶有可能中途改口、撤回請(qǐng)求、追問半年之前的某個(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í)、如何向用戶交代——這是工程化必須要回答的問題。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í)間盒超過設(shè)定時(shí)間就要中斷或降級(jí)。第二是可觀測(cè)性。大模型是不確定的這意味著 Agent 的行為天然比傳統(tǒng)程序更難排查。必須從一開始就埋好全鏈路的 trace用戶的原始輸入、模型每一步的思考、工具調(diào)用的入?yún)⒊鰠?、中間狀態(tài)遷移全部留痕。我之前在一個(gè)客服 Agent 項(xiàng)目里靠完善的 trace 定位到 80% 以上的問題沒有 trace 那這些問題的排查根本無(wú)從下手。第三是評(píng)估體系。沒有評(píng)估體系A(chǔ)gent 的迭代就是盲改。要建設(shè)“離線評(píng)估集 在線指標(biāo) 回歸測(cè)試”三層防護(hù)。離線評(píng)估集至少要準(zhǔn)備幾百條真實(shí)分布的問題覆蓋正常、邊緣、異常三類輸入在線指標(biāo)關(guān)注任務(wù)成功率、用戶反饋率、平均耗時(shí)每一次改動(dòng)都要跑回歸看是否引入了新問題。第四是權(quán)限與安全控制。Agent 能調(diào)用的工具必須經(jīng)過權(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í)、緩存命中、批量推理、上下文壓縮。我見過不加控制的項(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)目里差這么多我朋友做過一個(gè)內(nèi)部知識(shí)庫(kù)問答 Agent同樣的技術(shù)架構(gòu)基本一樣的提示詞在 A 公司跑得很順在 B 公司卻問題頻發(fā)。剛開始以為是大模型的問題后來(lái)排查發(fā)現(xiàn)根因在數(shù)據(jù)層。A 公司的知識(shí)庫(kù)是結(jié)構(gòu)化的問答對(duì)檢索命中率高B 公司的知識(shí)庫(kù)是大量非結(jié)構(gòu)化的技術(shù)文檔很多問題根本檢索不到答案。模型在檢索不到答案時(shí)會(huì)“試圖”湊一個(gè)答案出來(lái)這在 Demo 里不顯眼但在生產(chǎn)里就是嚴(yá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)證過的落地路線四步走鎖定邊界、改造調(diào)度、建立可觀測(cè)、優(yōu)化迭代。每一步都有關(guān)鍵動(dòng)作和要避開的雷區(qū)。4.1 第一步從 Demo 鎖定能力邊界落地做的第一件事不是寫代碼是畫能力邊界。拿一張大白紙把“這個(gè) Agent 在第一個(gè)生產(chǎn)版本里必須要做的事”和“絕對(duì)不碰的事”分別列出來(lái)。必須要做的事列的是核心高頻場(chǎng)景比如客服 Agent 的訂單查詢、物流查詢、常見問題解答。絕對(duì)不碰的事列的是高風(fēng)險(xiǎn)或低確定性場(chǎng)景比如情緒化投訴處理、大額退款決策、多輪復(fù)雜協(xié)商——這類場(chǎng)景先轉(zhuǎn)人工等 Agent 跑穩(wěn)了再逐步灰度接入。這一步的邏輯是生產(chǎn)系統(tǒng)上線不是證明 Agent 多能干而是先證明 Agent 在受控范圍內(nèi)可靠。我見過很多項(xiàng)目死在“想一次解決所有問題”上模型一遇到邊界外場(chǎng)景就胡說(shuō)用戶信任度瞬間歸零。反過來(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)過這個(gè)運(yùn)行時(shí)方便觀察全局而不是一個(gè)黑盒。另外工具層同步做統(tǒng)一注冊(cè)和鑒權(quán)。工具清單集中管理工具的入?yún)⒑统鰠?schema 注冊(cè)在案調(diào)用要過權(quán)限校驗(yàn)。不要允許 Agent 自由調(diào)用任何內(nèi)部接口這是生產(chǎn)安全的基本底線。4.3 第三步建立可觀測(cè)性和評(píng)估體系沒有可觀測(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)過了哪些 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)必須通過回歸評(píng)估才允許上線。在客服場(chǎng)景里我制定的評(píng)估指標(biāo)包括任務(wù)完成率用戶問題得到有效解決的比例、工具調(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ì)常見問題的標(biāo)準(zhǔn)答案做精確緩存對(duì)相似問題做語(yǔ)義緩存。語(yǔ)義緩存要注意閾值控制相關(guān)性不足時(shí)寧可不命中也不要把錯(cuò)誤答案返回給用戶。上下文壓縮策略不是每次請(qǐng)求都把全部歷史塞給模型而是把歷史摘要化只保留關(guān)鍵事實(shí)與用戶明確確認(rèn)過的信息。設(shè)計(jì)一套摘要更新機(jī)制讓新對(duì)話自動(dòng)覆蓋舊信息防止 token 無(wú)限膨脹。性能優(yōu)化方面關(guān)注兩個(gè)指標(biāo)首 token 延遲和端到端完成時(shí)間。前者受模型推理速度影響后者受工具調(diào)用鏈路影響。可以適度并行化工具調(diào)用、縮短不必要的中間步驟、用流式輸出來(lái)提升用戶的等待體驗(yàn)。5. 常見問題與排查技巧實(shí)錄模型的不確定性決定了 Agent 類系統(tǒng)的排障和普通后端系統(tǒng)完全兩個(gè)套路。任何 Agent 系統(tǒng)都會(huì)遇到同類的詭異問題這一章把我踩過的坑和排查思路整理成了一份速查表順便拆一個(gè)實(shí)際的死循環(huán)案例。5.1 典型故障速查表現(xiàn)象可能原因排查思路任務(wù)反復(fù)不完成一直調(diào)用工具終止條件設(shè)計(jì)缺失模型眼里沒有“完成”邊界檢查狀態(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 過于復(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)求過多做用量分級(jí)和流量整形為高優(yōu)任務(wù)預(yù)留配額非核心場(chǎng)景排隊(duì)或降級(jí)這些坑偶發(fā)性都很強(qiáng)日志和追蹤不到位時(shí)尤其難排查。我的經(jīng)驗(yàn)是先保證異常分支有日志每個(gè)“不該發(fā)生但模型做了”的行為都要留痕后續(xù)才能通過日志回放來(lái)分析。5.2 排障實(shí)例Agent 陷入死循環(huán)一個(gè)具體案例最能說(shuō)明問題——一次客服 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ú)誤”沒有給出可判定的標(biāo)準(zhǔn)。模型沒有明確的規(guī)則可依據(jù)自然無(wú)法收斂。第二層是該場(chǎng)景缺少全局最大步數(shù)兜底模型想查多少次就能查多少次沒有外力打斷。修復(fù)方案分兩步。第一步是給該場(chǎng)景加上“最多查兩次查到結(jié)果后直接基于結(jié)果回答查詢失敗則轉(zhuǎn)人工并說(shuō)明“這種情況需要人工處理”的硬規(guī)則。第二步是補(bǔ)上全局兜底任何任務(wù)超過五步即強(qiáng)制終止并記錄告警。修復(fù)后這類問題的發(fā)生頻率基本歸零。這個(gè)案例典型的點(diǎn)在于死循環(huán)未必是模型的“Bug”更多時(shí)候是系統(tǒng)設(shè)計(jì)沒有給模型足夠的收斂信號(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í)間軸展開。大部分問題的線索都會(huì)在回放里顯露出來(lái)。第二步叫“定位”。把問題歸類到架構(gòu)四層里是感知層意圖識(shí)別錯(cuò)了還是決策層規(guī)劃出問題了還是行動(dòng)層工具調(diào)錯(cuò)了或是記憶層上下文丟了。歸層之后再看模型以外有沒有工程原因比如超時(shí)、并寫、緩存策略很多問題根源不在模型而在工程側(cè)拼圖缺失。第三步叫“最小化復(fù)現(xiàn)”。用一個(gè)最簡(jiǎn)單的輸入在測(cè)試環(huán)境里復(fù)現(xiàn)問題。復(fù)現(xiàn)不出來(lái)就說(shuō)明問題大概率跟特定上下文或狀態(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 可以在沒有人工盯著的情況下穩(wěn)定完成 95% 的常規(guī)任務(wù)剩下 5% 能對(duì)用戶誠(chéng)實(shí)地說(shuō)“請(qǐng)稍等轉(zhuǎn)人工”你就真正跨越了從 Demo 到生產(chǎn)的那道坎。