上線前最后一天我盯著測(cè)試日志里的一條回答差點(diǎn)沒(méi)把水噴到屏幕上——我負(fù)責(zé)的智能客服 Agent 對(duì)用戶說(shuō)“您的退貨申請(qǐng)已經(jīng)通過(guò)”可這個(gè)訂單根本沒(méi)有提交過(guò)退貨申請(qǐng)。更離譜的是它在給出這個(gè)答復(fù)之前還一本正經(jīng)地引用了“平臺(tái)規(guī)則第 12 條”而資料庫(kù)里壓根沒(méi)這條。這種經(jīng)歷做過(guò) Agent 的人都懂。跑 Demo 的時(shí)候一切正常一旦進(jìn)入真實(shí)業(yè)務(wù)場(chǎng)景模型就開始“自由發(fā)揮”了。亂編、連鎖、失憶這三個(gè)毛病幾乎是所有 Agent 的通病。亂編是憑空捏造事實(shí)連鎖是一步錯(cuò)后面步步錯(cuò)失憶是聊著聊著把關(guān)鍵信息全忘了。這篇文章我把自己沉淀的一套“五維體檢”方法論完整寫出來(lái)從體檢樣本構(gòu)建、打分規(guī)則、執(zhí)行流程到典型病例的診斷邏輯和修復(fù)手段全部是可復(fù)制、可落地的實(shí)操路徑。如果你正在調(diào)試 AI Agent或者準(zhǔn)備把 Agent 接入真實(shí)業(yè)務(wù)這份體檢手冊(cè)可以直接拿去用。1. 先把三個(gè)病認(rèn)清楚亂編、連鎖、失憶很多人拿到一個(gè)跑不通的 Agent第一反應(yīng)是改 prompt第二反應(yīng)是換模型但改來(lái)改去問(wèn)題還是一樣。我個(gè)人的經(jīng)驗(yàn)是改之前先花點(diǎn)時(shí)間把病灶分類。Agent 的故障并不全是模型能力問(wèn)題更多時(shí)候是特定的機(jī)制性缺陷。1.1 亂編模型把想象當(dāng)事實(shí)輸出亂編業(yè)內(nèi)常說(shuō)的幻覺(jué)指的是模型產(chǎn)出了和輸入上下文、知識(shí)庫(kù)、真實(shí)數(shù)據(jù)不一致的內(nèi)容但語(yǔ)氣卻極其篤定。客服 Agent 里最常見的表現(xiàn)形式是偽造訂單狀態(tài)、杜撰售后條款、憑空生成一個(gè)不存在的轉(zhuǎn)人工入口。比如用戶問(wèn)“退貨后多久能退款”模型可能回答“3-5 個(gè)工作日”但業(yè)務(wù)真實(shí)規(guī)則是“材料審核通過(guò)后 7-15 個(gè)工作日”。這個(gè)問(wèn)題的麻煩之處在于模型對(duì)自己的編造通常沒(méi)有任何“心虛”的跡象。在問(wèn)答場(chǎng)景里用戶還能憑常識(shí)判斷但在 Agent 自動(dòng)化執(zhí)行業(yè)務(wù)動(dòng)作的場(chǎng)景里亂編就直接變成線上事故。我遇到過(guò)真實(shí)案例Agent 根據(jù)一段并不存在的“用戶授權(quán)記錄”給后臺(tái)系統(tǒng)提交了改地址請(qǐng)求這種錯(cuò)誤如果不靠日志留痕幾乎沒(méi)法追溯。1.2 連鎖一步錯(cuò)后面全跟著錯(cuò)連鎖錯(cuò)誤是 Agent 特有的故障模式也是和普通聊天機(jī)器人最大的區(qū)別。普通問(wèn)答模型只對(duì)單輪輸出負(fù)責(zé)錯(cuò)了也就錯(cuò)了影響范圍有限。但 Agent 是多步驟流水線——先做意圖識(shí)別再做槽位填充然后調(diào)工具最后生成回答。每一環(huán)的輸出都是下一環(huán)的輸入誤差沿著鏈路逐級(jí)放大。舉個(gè)很簡(jiǎn)單的例子客服 Agent 的第一步是把用戶問(wèn)題分類成“售前咨詢”和“售后維權(quán)”。如果這一步判斷錯(cuò)了后續(xù)的售后知識(shí)檢索、流程查詢、答復(fù)生成全部基于錯(cuò)誤的方向運(yùn)行。有時(shí)候用戶問(wèn)的明明是“我想買一個(gè)支持快充的手機(jī)”如果意圖識(shí)別成了“投訴產(chǎn)品質(zhì)量問(wèn)題”那 Agent 就會(huì)去翻質(zhì)量投訴的應(yīng)答模板最后給用戶車轱轆話繞圈子。更麻煩的是中間環(huán)節(jié)的錯(cuò)誤不一定立刻在即時(shí)回答里暴露可能要到最終答案生成時(shí)才“病情發(fā)作”。1.3 失憶上下文被截?cái)嗷蛑匾愿兄蛔闶涀置嬉馑际?Agent 把之前說(shuō)過(guò)的內(nèi)容忘了。最典型的表現(xiàn)是用戶第 5 輪說(shuō)過(guò)“我的收貨地址是 B”第 12 輪 Agent 還在按第 2 輪的地址 A 校驗(yàn)訂單。你以為是模型能力不行打開日志一看——上下文早就被截?cái)嗔嘶蛘呤谴翱诶锶颂酂o(wú)關(guān)內(nèi)容模型在注意力分配上主動(dòng)忽略了早期信息。這種失憶還有更隱蔽的一種模型不是完全沒(méi)有看到歷史信息而是對(duì)“關(guān)鍵約束”和“普通聊天內(nèi)容”的重視程度沒(méi)有區(qū)分。比如用戶在對(duì)話中明確說(shuō)“不要自動(dòng)給我發(fā)短信通知”但這條約束藏在第 20 輪前面全是閑聊。到第 26 輪模型直接默認(rèn)用戶接受短信通知觸發(fā)了一次外呼。這類問(wèn)題用單純的“擴(kuò)大窗口”很難解決因?yàn)榇翱谠酱笮畔⒚芏仍降湍Ｐ头炊菀缀雎躁P(guān)鍵項(xiàng)。把三類病摸清楚之后下一個(gè)問(wèn)題是怎么量化沒(méi)有量化你沒(méi)法知道自己改完 prompt 到底是變好了還是變差了也沒(méi)法在團(tuán)隊(duì)里用同一套語(yǔ)言討論 Agent 質(zhì)量。2. 五維體檢給 Agent 定一套可以量化的健康指標(biāo)我自己做 Agent 調(diào)試時(shí)最大的痛點(diǎn)就是“好不好全靠感覺(jué)”。同樣一條問(wèn)題今天測(cè)通過(guò)明天換一種問(wèn)法就崩自己調(diào)沒(méi)問(wèn)題交給同事一跑就亂。要解決這個(gè)問(wèn)題必須先定義“健康”不能等出 bug 再排查。我花了很長(zhǎng)時(shí)間整理出一套五個(gè)維度的度量體系它覆蓋了 Agent 從輸入到輸出全鏈路的關(guān)鍵質(zhì)量屬性。2.1 為什么先設(shè)計(jì)維度而不是直接開寫測(cè)試用例很多人一聽“給 Agent 做測(cè)試”第一反應(yīng)是準(zhǔn)備 500 條問(wèn)題逐個(gè)跑一遍看回答好不好。問(wèn)題在于單條問(wèn)題的“好與壞”沒(méi)有可積累的判斷依據(jù)你只能得到一堆零散的失敗案例得不到一個(gè)可以橫向比較的“分?jǐn)?shù)”。五個(gè)體檢維度的本質(zhì)是把“Agent 表現(xiàn)好”這個(gè)大概念拆解成可以分別打分、分開優(yōu)化的指標(biāo)。每個(gè)維度都有相對(duì)獨(dú)立的改進(jìn)手段。準(zhǔn)確性低優(yōu)先查知識(shí)庫(kù)和輸出校驗(yàn)連貫性差優(yōu)先改流程編排和工具調(diào)用記憶力差優(yōu)先改上下文管理穩(wěn)定性差優(yōu)先查 prompt 里的隨機(jī)性和工具超時(shí)效率差優(yōu)先壓縮提示詞和減少不必要調(diào)用。不分維度你面對(duì)一個(gè)失敗案例時(shí)根本不知道該動(dòng)哪一塊。2.2 五個(gè)維度定義與度量方式我最終敲定的五個(gè)維度是準(zhǔn)確性、連貫性、記憶力、穩(wěn)定性、效率。為了自己好記我把它們打包叫 ACMSE 五維。維度它度量什么客觀度量參考健康時(shí)應(yīng)該呈現(xiàn)的表現(xiàn)準(zhǔn)確性回答與事實(shí)、知識(shí)庫(kù)、業(yè)務(wù)數(shù)據(jù)的一致性無(wú)中生有的比例關(guān)鍵實(shí)體錯(cuò)誤數(shù)無(wú)編造每個(gè)斷言都能追蹤到資料來(lái)源或工具返回結(jié)果連貫性多步驟鏈條上各環(huán)節(jié)的一致性與遞進(jìn)關(guān)系中途轉(zhuǎn)向次數(shù)重復(fù)提問(wèn)數(shù)流程中斷率從意圖識(shí)別到工具調(diào)用再到最終答復(fù)鏈條完整且方向一致記憶力關(guān)鍵信息跨輪次保持能力關(guān)鍵約束遺忘次數(shù)重復(fù)確認(rèn)次數(shù)跨越多輪對(duì)話的關(guān)鍵實(shí)體、約束、偏好都能在需要時(shí)被喚起穩(wěn)定性同一輸入下多次執(zhí)行結(jié)果的一致性相同用例重復(fù)執(zhí)行的結(jié)果漂移率同一用例跑多次答案方向與技術(shù)細(xì)節(jié)不隨隨機(jī)性大幅變化效率完成目標(biāo)所需的計(jì)算與調(diào)用開銷總 token 消耗工具調(diào)用次數(shù)完成時(shí)長(zhǎng)用最少的中間步數(shù)達(dá)成相同質(zhì)量結(jié)果無(wú)冗余自問(wèn)自答這個(gè)表格我建議你打印出來(lái)貼在工位邊上。原因有兩個(gè)其一五個(gè)維度之間的邊界經(jīng)常會(huì)重疊有了這張表團(tuán)隊(duì)評(píng)審用例時(shí)可以快速對(duì)齊口徑其二打分時(shí)最怕主觀每個(gè)維度下面一定要有“客觀度量參考”這一列先看數(shù)據(jù)再看感受。2.3 評(píng)分規(guī)則五分制量規(guī)與加權(quán)總分單維度打分我用 1-5 分每個(gè)分?jǐn)?shù)檔位都做了錨點(diǎn)描述避免“我覺(jué)得還行”這類無(wú)效打分。5 分完全符合該維度的健康表現(xiàn)無(wú)扣分項(xiàng)。4 分整體健康存在 1-2 個(gè)輕微瑕疵但不影響業(yè)務(wù)正確性。3 分存在部分錯(cuò)誤但通過(guò)觸發(fā)兜底邏輯可以恢復(fù)錯(cuò)誤不擴(kuò)散。2 分明顯錯(cuò)誤且錯(cuò)誤的根因是結(jié)構(gòu)性缺陷例如上下文丟失、意圖識(shí)別方向錯(cuò)誤。1 分完全不可用輸出會(huì)導(dǎo)致業(yè)務(wù)事故。最終總分是加權(quán)和。我最常用的權(quán)重方案是準(zhǔn)確性 30%、連貫性 25%、記憶力 20%、穩(wěn)定性 15%、效率 10%。這個(gè)權(quán)重不是拍腦袋定的而是根據(jù)真實(shí)業(yè)務(wù)中“錯(cuò)誤造成的損失程度”反推的。如果你的業(yè)務(wù)對(duì)成本極度敏感可以把效率權(quán)重提到 20%準(zhǔn)確性和連貫性各降 5%所有權(quán)重加起來(lái)保持 100% 就可以。舉例說(shuō)明計(jì)算方式某 Agent 體檢后五維得分分別為準(zhǔn)確性 4、連貫性 4、記憶力 5、穩(wěn)定性 3、效率 4加權(quán)總分是 4×0.3 4×0.25 5×0.2 3×0.15 4×0.1 4.05對(duì)應(yīng)百分制約 81 分屬于“亞健康需局部修復(fù)”。2.4 體檢樣本集30 條基線用例怎么設(shè)計(jì)有了維度體系還要有統(tǒng)一的“考試卷”。我給每一次體檢準(zhǔn)備 30 條基線用例既不貪多也能覆蓋主要風(fēng)險(xiǎn)面。用例分三類每類 10 條正常主線、邊界輸入、對(duì)抗輸入。正常主線覆蓋業(yè)務(wù)中的高頻場(chǎng)景比如客服 Agent 的“查訂單”“改地址”“申請(qǐng)退貨”。邊界輸入覆蓋模糊表述、多條件疊加、超長(zhǎng)輸入、生僻術(shù)語(yǔ)比如用戶把地址和收件人打包在一句話里。對(duì)抗輸入覆蓋誘導(dǎo)性提問(wèn)、否定表達(dá)、反復(fù)追問(wèn)、多輪后修改條件專門用來(lái)測(cè)試 Agent 在高壓和混亂輸入下會(huì)不會(huì)亂編或失憶。每個(gè)用例不光要有“輸入”還要有“基線答案”?；€答案不是隨意寫的而是由兩條路徑獨(dú)立產(chǎn)出一條是業(yè)務(wù)專家按業(yè)務(wù)規(guī)則手工填寫另一條是讓 Agent 在沒(méi)有額外干擾的條件下跑出來(lái)的最優(yōu)回答。兩個(gè)版本做交叉核對(duì)一致的部分作為參考答案不一致的部分擇期再對(duì)齊。這個(gè)雙軌制很關(guān)鍵因?yàn)橛行I(yè)務(wù)問(wèn)題本身沒(méi)有唯一標(biāo)準(zhǔn)答案你必須有可追溯的基線才能給 AI 打分。3. 體檢實(shí)操?gòu)幕胤拍_本到診斷報(bào)告維度體系和樣本集準(zhǔn)備好之后就進(jìn)入執(zhí)行環(huán)節(jié)。體檢不是把 30 條用例手工跑一遍再人工評(píng)個(gè)分那樣既不科學(xué)也不可持續(xù)。我的做法是搭一套輕量回放框架把執(zhí)行、記錄、初篩、人工復(fù)核流水線化。3.1 回放工具與執(zhí)行流程我不會(huì)為體檢單獨(dú)開發(fā)一套復(fù)雜平臺(tái)現(xiàn)有條件下的最小閉環(huán)是體檢驅(qū)動(dòng)腳本 Agent 框架的 SDK JSONL 日志存儲(chǔ)。體檢驅(qū)動(dòng)腳本負(fù)責(zé)逐條讀取用例調(diào)用 Agent 的接口把整個(gè)執(zhí)行過(guò)程完整記錄下來(lái)。下面這個(gè)偽代碼展示了回放腳本的核心邏輯你可以直接照著在自己的項(xiàng)目里改改跑起來(lái)import json import time TEST_CASES load_cases(cases/golden_set.jsonl) AGENT_CONFIG load_config(agent_config.yaml) results [] for case in TEST_CASES: trace { case_id: case[id], category: case[category], input: case[input], timeline: [], final_answer: , token_usage: 0, tool_calls: [], error: None, } start time.time() try: final run_agent_with_trace( agent_configAGENT_CONFIG, inputcase[input], historycase.get(history, []), trace_sinktrace[timeline], ) trace[final_answer] final except Exception as exc: trace[error] str(exc) trace[elapsed] time.time() - start results.append(trace) write_jsonl(report/execution_trace.jsonl, results)這段腳本重點(diǎn)看三點(diǎn)細(xì)節(jié)。第一trace_sink參數(shù)把內(nèi)部每一步推理、工具調(diào)用、中間結(jié)果全部放進(jìn) timeline 數(shù)組這是后續(xù)歸因分析的原始證據(jù)。第二異常被吞掉并記錄成 trace 里的 error 字段說(shuō)明體檢測(cè)試不能容忍直接崩潰因?yàn)?Agent 的真實(shí)用戶會(huì)在各種異常下繼續(xù)和它對(duì)話。第三執(zhí)行過(guò)程中沒(méi)有做任何回答后的規(guī)則過(guò)濾先把原始行為完全保留下來(lái)看的就是不加干預(yù)下的真實(shí)表現(xiàn)。3.2 客觀數(shù)據(jù)自動(dòng)匯總執(zhí)行完成后腳本會(huì)輸出一份客觀指標(biāo)匯總表。這部分不需要人看直接由代碼生成指標(biāo)數(shù)值說(shuō)明平均完成時(shí)長(zhǎng)6.8s從請(qǐng)求發(fā)出到最終響應(yīng)返回平均 token 消耗1542含工具返回內(nèi)容平均工具調(diào)用次數(shù)2.4每次完整任務(wù)執(zhí)行中的工具調(diào)用鏈無(wú)輸出率3.3%轉(zhuǎn)人工插件的確定性跳轉(zhuǎn)不計(jì)入超時(shí)重試率6.7%調(diào)用外部服務(wù)部分的超時(shí)占比結(jié)果漂移率13.3%同一用例重復(fù)執(zhí)行 3 次后答案關(guān)鍵要素不一致率這些客觀數(shù)據(jù)是我用來(lái)快速定位的“第一篩網(wǎng)”。比如結(jié)果漂移率過(guò)高穩(wěn)定性維度基本不可能及格平均工具調(diào)用次數(shù)偏高效率維度大概率扣分?？陀^數(shù)據(jù)不直接生成主觀質(zhì)量分但它告訴你應(yīng)該把人工精力投到哪幾條用例上不用每條都精讀。3.3 質(zhì)量評(píng)分怎么打客觀篩選 人工復(fù)核30 條用例全部跑完后我不會(huì)讓人去逐條打分時(shí)間和精力都撐不住。我的流程是兩級(jí)篩查先由腳本根據(jù)幾個(gè)硬性規(guī)則過(guò)濾把明顯異常的用例撈出來(lái)再交給兩個(gè)標(biāo)注者獨(dú)立給這些異常用例打“質(zhì)量分”。硬性過(guò)濾規(guī)則包含四類其一回答中出現(xiàn)了知識(shí)庫(kù)里不存在的規(guī)則編號(hào)或條款直接劃入“疑似亂編”轉(zhuǎn)人工打分其二多步任務(wù)出現(xiàn)中間環(huán)節(jié)返回異?；蚬ぞ哒{(diào)用失敗自動(dòng)標(biāo)記“疑似連鎖”其三跨多輪用例中關(guān)鍵約束出現(xiàn)兩次以上丟失直接標(biāo)記“疑似失憶”其四重復(fù)執(zhí)行的答案關(guān)鍵差異超過(guò)閾值進(jìn)入“疑似漂移”池。被標(biāo)記的用例統(tǒng)一由兩個(gè)標(biāo)注者背靠背評(píng)分再把分?jǐn)?shù)取平均。如果兩個(gè)人的分差超過(guò) 1 分就說(shuō)明這條用例的評(píng)估口徑?jīng)]對(duì)齊需要一起復(fù)盤統(tǒng)一標(biāo)準(zhǔn)。這個(gè)流程解決了 AI 評(píng)測(cè)里最大的坑純客觀腳本過(guò)于死板純?nèi)斯び植豢沙掷m(xù)。兩級(jí)篩查的核心思想是“用機(jī)器省人力用人力看本質(zhì)”。3.4 輸出一張?bào)w檢報(bào)告所有評(píng)分完成后匯總輸出體檢報(bào)告。報(bào)告結(jié)構(gòu)不復(fù)雜但信息密度要高頂部是總分和各維度的雷達(dá)數(shù)據(jù)中間是客觀指標(biāo)對(duì)照表下面是問(wèn)題用例清單每條問(wèn)題用例附上“病例鏈接”——指向執(zhí)行日志里對(duì)應(yīng)的 trace 片段。報(bào)告里最值錢的部分是“高頻問(wèn)題歸類”。我會(huì)把問(wèn)題用例按根因打標(biāo)簽比如“先誤判再誤答”“發(fā)生在第 6 輪后的記憶衰退”“工具返回空值后自創(chuàng)默認(rèn)答案”。標(biāo)簽聚合以后修復(fù)方向的優(yōu)先級(jí)就非常清楚如果 80% 的問(wèn)題集中在同一類根因那一個(gè)針對(duì)性改動(dòng)就能大幅提升總分而不是零敲碎打地修個(gè)案。4. 真實(shí)體檢記錄一次跑完 30 條用例后發(fā)現(xiàn)的 8 個(gè)錯(cuò)誤方法論說(shuō)再多都不如看一次完整記錄。下面我把自己做的一次客服 Agent 體檢全過(guò)程拆給你看項(xiàng)目代號(hào)“某客服 Agent v0.9”基座用的是通用 LLM知識(shí)庫(kù)接了售后規(guī)則和訂單查詢接口。這次體檢跑了 30 條基線用例最終發(fā)現(xiàn) 8 個(gè)有效錯(cuò)誤包含亂編、連鎖、失憶三類。4.1 業(yè)務(wù)場(chǎng)景與樣本準(zhǔn)備該 Agent 的職責(zé)范圍是三件事查訂單狀態(tài)、查詢售后政策、提交售后申請(qǐng)。樣本集按 2.4 的規(guī)則構(gòu)建正常主線 10 條覆蓋高頻問(wèn)法邊界 10 條覆蓋一句話里塞多個(gè)信息點(diǎn)的情況對(duì)抗 10 條覆蓋用戶連續(xù)修改條件、否定前面結(jié)論的極端場(chǎng)景。每條用例都提前寫好了基線答案整個(gè)準(zhǔn)備過(guò)程花了兩個(gè)工作日其中第三個(gè)時(shí)間項(xiàng)花在“基線答案的口徑對(duì)齊”上——業(yè)務(wù)專家和 AI 跑出的最優(yōu)答案在“退回運(yùn)費(fèi)由誰(shuí)承擔(dān)”這類細(xì)節(jié)上存在分歧最后以業(yè)務(wù)規(guī)則文案為準(zhǔn)。4.2 五維得分匯總30 條用例跑完后匯總結(jié)果如下維度得分主要扣分原因準(zhǔn)確性3.32 條回答編造了不存在的售后條款編號(hào)連貫性3.71 條意圖識(shí)別錯(cuò)誤導(dǎo)致后續(xù)流程整體跑偏記憶力4.02 條跨輪次用例出現(xiàn)關(guān)鍵約束遺忘穩(wěn)定性4.2同一退貨咨詢重復(fù)執(zhí)行 3 次出現(xiàn) 2 種不同表述效率4.4部分用例多調(diào)用了一次訂單查詢接口總分算下來(lái)是 3.78百分制約 76 分屬于需要局部修復(fù)的狀態(tài)。單純看這個(gè)數(shù)字可能覺(jué)得“也沒(méi)那么糟”但你要注意準(zhǔn)確性只有 3.3——在這個(gè)業(yè)務(wù)里準(zhǔn)確性是權(quán)重最高的一指標(biāo)任何一條無(wú)中生有的輸出都可能導(dǎo)致用戶投訴或資金風(fēng)險(xiǎn)。4.3 三個(gè)典型病例的完整現(xiàn)場(chǎng)挑三個(gè)最有代表性的病例詳細(xì)展開你會(huì)看到同一個(gè)結(jié)論錯(cuò)誤不是突然產(chǎn)生的而是沿著某條鏈路慢慢滾大的。病例 A亂編用戶問(wèn)“申請(qǐng)售后后多久能收到處理通知”。該 Agent 的回答是“根據(jù)平臺(tái)規(guī)則售后處理通知將在 2 個(gè)工作日內(nèi)發(fā)出緊急情況可在 1 個(gè)工作日內(nèi)獲得反饋”。但基準(zhǔn)確認(rèn)后實(shí)際規(guī)則是“3-5 個(gè)工作日”且不存在“緊急情況加急”條款。打開 trace 一看根因是知識(shí)庫(kù)檢索階段未返回有效結(jié)果模型于是“合理想象”了一個(gè)看起來(lái)合理的數(shù)字。這個(gè)病例清楚地說(shuō)明當(dāng)檢索模塊返回空值時(shí)模型傾向于用默認(rèn)的“業(yè)務(wù)常識(shí)”填充造成編造。病例 B連鎖用戶輸入“我上周買的東西壞了想退掉地址是上海”。意圖識(shí)別模塊把它歸類成了“訂單查詢”于是該 Agent 去調(diào)訂單查詢接口拿到訂單后機(jī)械地展示物流狀態(tài)沒(méi)有進(jìn)入退貨流程。后續(xù)再追問(wèn)的時(shí)候它已經(jīng)帶著錯(cuò)誤的流程方向做下一步越走越遠(yuǎn)。這條病例里每一環(huán)單獨(dú)看都“不嚴(yán)重”但把它們串聯(lián)起來(lái)用戶體驗(yàn)就是災(zāi)難。病例 C失憶用戶在第 6 輪說(shuō)“不要自動(dòng)給我發(fā)短信通知”第 11 輪詢問(wèn)“現(xiàn)在進(jìn)度怎么樣了”。該 Agent 回復(fù)時(shí)默認(rèn)把“通過(guò)短信告知”列為已選通知方式而實(shí)際上用戶已經(jīng)在 5 輪前明確拒絕。追溯 trace 發(fā)現(xiàn)在第 9 輪時(shí)上下文窗口被壓縮第 6 輪的約束項(xiàng)被截掉。這個(gè)病例最有教學(xué)意義不是模型不聰明而是工程層面的窗口壓縮策略把關(guān)鍵信息當(dāng)作無(wú)用內(nèi)容丟棄了。4.4 從病例反推根因日志軌跡怎么讀拿到三個(gè)病例后歸因不要只盯著“最終回答哪里不對(duì)”我一般沿 trace timeline 逐層回溯回答三個(gè)問(wèn)題在哪一步開始出現(xiàn)偏差偏差的那一步輸入了什么內(nèi)容為什么那一步?jīng)]有觸發(fā)兜底校驗(yàn)以病例 C 為例偏差最早發(fā)生在第 9 輪上下文壓縮時(shí)。壓縮策略是“截?cái)嘧钤绲挠脩粝ⅰ边@個(gè)策略對(duì)普通聊天內(nèi)容有效但不區(qū)分“閑聊”和“不可丟棄的約束”。修復(fù)方向因此不是加大模型上下文長(zhǎng)度而是調(diào)整壓縮策略——把帶有關(guān)鍵約束的消息固定保留優(yōu)先裁剪體積大的工具返回結(jié)果。根因不在模型而在工程策略這就是 trace 回溯的價(jià)值。5. 對(duì)癥下藥三個(gè)高頻病癥的修復(fù)方案與驗(yàn)證體檢的意義在于指導(dǎo)修復(fù)。每個(gè)病癥的修復(fù)手段不同但統(tǒng)一原則是先做最小改動(dòng)驗(yàn)證再全量回歸絕不一次性上多個(gè)改動(dòng)。下面是我在項(xiàng)目里驗(yàn)證過(guò)有效的方案你可以直接套用。5.1 亂編修復(fù)給模型裝一個(gè)“剎車系統(tǒng)”亂編的核心是模型在證據(jù)不足時(shí)強(qiáng)行補(bǔ)全。修復(fù)思路就是兩條要么讓它有據(jù)可依要么讓它承認(rèn)自己不知道。第一刀是強(qiáng)制檢索引用。在生成回答前Agent 先執(zhí)行知識(shí)庫(kù)檢索并且把檢索到的片段作為上下文注入同時(shí)要求回答中引用對(duì)應(yīng)的片段編號(hào)。這一步不是讓模型參考資料而是用結(jié)構(gòu)化的輸出約束引用標(biāo)記迫使它只能在檢索結(jié)果上組織語(yǔ)言。第二刀是設(shè)置置信度閾值當(dāng)相似度分?jǐn)?shù)低于閾值時(shí)模型不是強(qiáng)行編一條答案而是進(jìn)入“拒答模板”比如“這個(gè)問(wèn)題我這邊沒(méi)有查到明確政策建議轉(zhuǎn)人工確認(rèn)”。這個(gè)設(shè)計(jì)在客服場(chǎng)景中至關(guān)重要把模型從“永遠(yuǎn)要回答”的困境中解放出來(lái)。跑完復(fù)測(cè)亂編率從初檢的 23% 降到了 4%。值得注意的是修復(fù)后出現(xiàn)了一個(gè)新現(xiàn)象模型開始“過(guò)度拒答”連一些可以推理的常見問(wèn)題也不愿意回答了。這就到了下一輪的調(diào)優(yōu)把閾值往下微調(diào)再跑一輪讓比例收斂到 8% 左右的健康區(qū)間。你會(huì)有一種看醫(yī)生調(diào)藥量的既視感。5.2 連鎖修復(fù)在關(guān)鍵節(jié)點(diǎn)加“檢查閘門”連鎖錯(cuò)誤的修復(fù)重點(diǎn)不是“讓每一步更準(zhǔn)”而是在錯(cuò)誤發(fā)生后能及時(shí)攔截。AI 的推理不是確定性代碼不能指望每一環(huán)都 100% 正確你要做的是在關(guān)鍵轉(zhuǎn)換點(diǎn)加“檢查閘門”。具體做法是第一步把大任務(wù)拆成多個(gè)子步驟明確每個(gè)子步驟的輸出契約。第二步對(duì)子步驟的輸出做規(guī)則校驗(yàn)。比如意圖分類模塊的輸出必須從預(yù)設(shè)的意圖列表里取值如果分類置信度低于 0.6則不允許直接進(jìn)入后續(xù)流程必須改成反問(wèn)用戶“請(qǐng)問(wèn)您是想辦理退貨還是查詢狀態(tài)”工具返回的值如果是空數(shù)組不允許自動(dòng)生成“沒(méi)有符合條件的記錄”這種斷言必須走一次數(shù)據(jù)再確認(rèn)或轉(zhuǎn)人工。第三步任何中間環(huán)節(jié)一旦觸發(fā)異常就觸發(fā)一條旁路兜底直接交給人工或回到上一步重新詢問(wèn)而不是帶著不確定性往下跑。修復(fù)后病例 B 這類事件的復(fù)現(xiàn)率從 16.7% 降到了 3.3%。等價(jià)的表達(dá)是100 次請(qǐng)求里只會(huì)有 3 次意圖識(shí)別失敗且這 3 次都會(huì)在被用戶察覺(jué)前被攔截回問(wèn)。閘門機(jī)制的本質(zhì)是“用一次反問(wèn)的代價(jià)避免一連串錯(cuò)誤的成本”。5.3 失憶修復(fù)把關(guān)鍵信息從“對(duì)話流”挪到“記憶卡片”失憶的修復(fù)方案要分層處理。第一層是工程兜底調(diào)整上下文壓縮策略不再簡(jiǎn)單從最早消息開始截?cái)喽窍劝压ぞ叻祷氐拈L(zhǎng)文本優(yōu)先裁剪或摘要保留用戶消息中的關(guān)鍵實(shí)體與約束。第二層是信息結(jié)構(gòu)重構(gòu)在運(yùn)行時(shí)維護(hù)一個(gè)獨(dú)立的“記憶卡片模塊”從每一條用戶消息中抽取關(guān)鍵信息——地址、時(shí)間范圍、禁止項(xiàng)、偏好——寫入固定結(jié)構(gòu)并在每次工具調(diào)用前把卡片內(nèi)容作為系統(tǒng)級(jí)上下文注入。有了記憶卡片即使模型窗口被壓縮關(guān)鍵約束也不會(huì)丟。原因很簡(jiǎn)單用戶消息是動(dòng)態(tài)的、變化的但記憶卡片是一個(gè)穩(wěn)定的結(jié)構(gòu)化摘要系統(tǒng)提示詞里永久掛著它模型在生成時(shí)天然會(huì)更重視系統(tǒng)級(jí)指令里的內(nèi)容。實(shí)測(cè)數(shù)據(jù)也支持這個(gè)判斷失憶類問(wèn)題的復(fù)現(xiàn)率從 13.3% 降到 0。5.4 修復(fù)后全量回歸防止治好一個(gè)病引出新病每一項(xiàng)修復(fù)上線后都必須跑全量 30 條基線用例而不是只跑之前失敗的那幾條。原因非?，F(xiàn)實(shí)你為了防止模型亂編讓它“不確定就拒答”但這樣做可能直接傷害準(zhǔn)確性維度把一些簡(jiǎn)單問(wèn)題也拒掉了。你為了防止連鎖錯(cuò)誤加了閘門但閘門觸發(fā)次數(shù)過(guò)多又會(huì)把效率維度拖垮用戶被反問(wèn)了太多次。所以我的建議是每修復(fù)一類病用同一套體檢流程復(fù)測(cè)五次維度把“修復(fù)前 VS 修復(fù)后”的雷達(dá)圖疊加在一起對(duì)比。如果總分提升了 8 分以上但某一個(gè)非目標(biāo)維度掉了 2 分以上就說(shuō)明這個(gè)修復(fù)有副作用需要微調(diào)參數(shù)后再跑一輪。這種“一次改一個(gè)每次全量回測(cè)”的做法雖然看起來(lái)慢實(shí)際上是把試錯(cuò)成本前移到了測(cè)試階段而不是上線后由真實(shí)用戶來(lái)買單。6. 體檢體系中幾個(gè)容易踩的坑方法論部分講完了最后分享幾個(gè)我反復(fù)踩過(guò)的坑。這些東西不寫在任何文檔里但沒(méi)有它們整套體檢流程很容易從“工具”變成“形式主義”。第一個(gè)坑是基線答案的“版本漂移”。業(yè)務(wù)規(guī)則是活的客服政策可能每個(gè)月變一次。如果你的基線答案還是上個(gè)季度的Agent 可能正確回答了最新規(guī)則卻因?yàn)楹团f基線不一致被打零分。我的解決辦法是給體檢加一個(gè)“基線有效期”概念每次跑全量前先核對(duì)最近一次規(guī)則變更更新受影響用例的基線答案并在報(bào)告中標(biāo)記“基線更新日期”。第二個(gè)坑是主觀評(píng)分的“口徑蔓延”。兩位標(biāo)注者各評(píng)各的時(shí)間一長(zhǎng)對(duì)“扣 1 分”的感知會(huì)悄然改變。我開始以為靠培訓(xùn)就能解決后來(lái)發(fā)現(xiàn)最有效的手段是每一條異常用例都附帶“基線答案 規(guī)則片段”讓標(biāo)注者的任務(wù)從“憑感覺(jué)打分”變成“對(duì)比材料找差異”。差異找到了分?jǐn)?shù)自然對(duì)齊了。第三個(gè)坑是回放腳本和線上環(huán)境不一致。如果你只在固定的離線用例上跑Agent 在真實(shí)任務(wù)中用的外部依賴比如訂單服務(wù)的返回值結(jié)構(gòu)可能完全不同。測(cè)試環(huán)境測(cè)出來(lái) 0 失憶線上接入高并發(fā)訂單版本后突然失憶率飆升。解決辦法是在回放腳本里支持 mock 和新數(shù)據(jù)注入兩種模式至少每?jī)芍苡蒙a(chǎn)環(huán)境脫敏日志里的真實(shí)用戶請(qǐng)求混入體檢樣本集中做一輪“漂移檢測(cè)”。第四個(gè)坑是只測(cè)單輪不測(cè)長(zhǎng)程。很多 Agent 的單輪回答質(zhì)量非常高但一進(jìn)入多輪連續(xù)對(duì)話就開始退化。體檢樣本集里必須包含一條“10 輪以上長(zhǎng)對(duì)話鏈”用例專門用來(lái)觀察記憶衰退和上下文漂移。我自己的經(jīng)驗(yàn)是很多 Agent 在 5 輪以內(nèi)表現(xiàn)優(yōu)秀超過(guò) 10 輪才開始露出失憶的馬腳所以至少要讓部分用例跑夠 15 輪才能發(fā)現(xiàn)真實(shí)交互場(chǎng)景里的隱患。整個(gè)五維體檢體系用下來(lái)最大的感受是它把一個(gè)玄學(xué)問(wèn)題變成了工程問(wèn)題。過(guò)去你說(shuō)“這個(gè) Agent 感覺(jué)不太行”別人不知道你在說(shuō)什么現(xiàn)在你說(shuō)“準(zhǔn)確性 3.3、連貫性 3.7、失憶率 13%”所有人都知道該怎么動(dòng)。最后再分享一個(gè)小技巧體檢腳本一定要沉淀到倉(cāng)庫(kù)里和每次發(fā)版綁定prompt 一改就跑一遍相關(guān)用例子集而不是等用戶投訴了再做亡羊補(bǔ)牢。Agent 這個(gè)領(lǐng)域變化很快但“先體檢、后上線、?；販y(cè)”這個(gè)流程短期看多花點(diǎn)時(shí)間長(zhǎng)期看省的是無(wú)數(shù)個(gè)在用戶面前翻車的現(xiàn)場(chǎng)。