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