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