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