到端到端工程實踐)
做 Agent 評測這件事我踩過最深的一個坑是拿評測大模型的老思路硬套 Agent。以前做 LLM 評測整理一批輸入輸出對寫腳本離線跑一遍把文本和參考答案比對一下交付就完了?？?Agent 一旦跑起來就是多輪推理加行動要查數(shù)據(jù)庫、調(diào)外部接口、改配置、做狀態(tài)變更中間任何一環(huán)出錯最終結(jié)果都可能和預期差出十萬八千里。大概從兩年前開始我陸續(xù)幫著幾個業(yè)務團隊搭過不同形態(tài)的 Agent 自動化評測體系。越搭越明白端到端的 Agent Evaluation 并不是寫幾個評測腳本那么簡單它是一整套圍繞任務設計、環(huán)境模擬、結(jié)果觀測、指標定義和數(shù)據(jù)迭代搭建起來的工程系統(tǒng)。這篇文章把我在實操中怎么拆解 Agent 自動化評測、怎么搭端到端評測體系、以及踩過的那些坑完整記錄下來。正在為“Agent 怎么做自動化評測”發(fā)愁的同學可以重點看測評集已經(jīng)跑起來但結(jié)果總是被業(yè)務方挑戰(zhàn)的人也能從這里找到一些排查思路。1. Agent 評測為什么不能直接套用 LLM 評測的方案1.1 傳統(tǒng) LLM 評測的本質(zhì)是一次性答卷過去做大模型評測最常見的形式就是準備一批輸入輸出對讓模型生成一次答案然后和參考答案對比。不管是基于規(guī)則的比對、算 BLEU/ROUGE還是用評判模型打分本質(zhì)上都是在給“一份答卷”評分。一張卷子一錘定音交完就完事。這套模式對文本生成、摘要、分類、問答這些場景沒問題它考驗的是模型在給定輸入下的“一次性推理能力”。但放到 Agent 上情況就完全變了。Agent 的產(chǎn)出不是一個最終文本而是一連串行動序列。比如一個客服 Agent 處理退款申請讀郵件、查訂單系統(tǒng)、判斷是否符合退款政策、調(diào)用退款接口、給用戶寫回復。每一步都有取舍下一步往往依賴上一步的結(jié)果。如果只看最后那句“我已經(jīng)為您辦理退款”你根本不知道它是不是真的把退款接口調(diào)成功了。所以把 Agent 評測簡單當成“給最終回復打分”是最大的誤解也是很多評測體系做出來沒人信的直接原因。1.2 Agent 評測的差異從“考背誦”變成“考辦事”我經(jīng)常給團隊里的同學打個比方LLM 評測像是考背誦Agent 評測更像考辦事?？嫁k事有個特點過程和結(jié)果同等重要。辦事的人要打開瀏覽器搜索資料、要撥打電話核實信息、要填寫表單提交申請這些動作都有對錯。更有意思的是辦事過程中還會遇到突發(fā)情況——電話沒人接、系統(tǒng)報錯、用戶改主意這時能否恢復過來、繼續(xù)把事辦成才是真正要測的能力。落到 Agent 上這幾點和 LLM 評測完全不同環(huán)境交互。Agent 必須真實或近似真實地和外部環(huán)境交互評測需要模擬環(huán)境并觀察狀態(tài)變化。多步?jīng)Q策。每一步都可能錯錯誤會累積中間一步錯了后面再多步都可能白費。工具調(diào)用正確性。不僅要看是否調(diào)用了工具還要看參數(shù)對不對、調(diào)用時機對不對、返回值有沒有被正確解析。故障恢復。工具拋異常時Agent 是繼續(xù)亂撞還是冷靜處理這直接影響任務成功率。這四個差異決定了評測設計必須同時關(guān)注“最終效果”和“完成過程”只看一頭都不行。1.3 端到端評測要分三個層級去看既然 Agent 評測和 LLM 評測完全不是一回事那評測體系也不能只有一層。我給自己搭評測體系定了一個三層結(jié)構(gòu)每個層級解決不同問題第一層是單元能力評測。單獨驗證 Agent 里頭某個能力模塊比如工具調(diào)用參數(shù)生成是否正確、某個 prompt 分支是否穩(wěn)定。這一層跑得快適合開發(fā)階段頻繁自測。第二層是流程鏈路評測。把 Agent 放進 mock 環(huán)境里給定初始狀態(tài)跑完一個完整任務但環(huán)境里的外部依賴都用可控的樁替代。這是主力既能端到端觀察又能控制變量。第三層才是真正貼近線上的端到端評測。在盡量接近生產(chǎn)的環(huán)境里跑外部服務用沙箱或測試賬號數(shù)據(jù)用脫敏后的真實數(shù)據(jù)。這一層最真實、也最貴適合發(fā)布前做全量回歸。很多團隊一上來就想直接做第三層發(fā)現(xiàn)又貴又不穩(wěn)定做了幾天就跑不下去了。實際踩下來還是得從第二層起步先把可控性做扎實再往真實環(huán)境逼近。這也是這篇文章主推的思路。2. 端到端評測體系怎么設計任務、指標和過程觀測2.1 評測任務集定義把業(yè)務需求翻譯成可執(zhí)行任務構(gòu)建端到端評測體系第一步不是選框架也不是寫腳本而是定義評測任務集。評測任務集不是隨便列一些用戶問題就完事每個任務必須包含以下要素初始狀態(tài)任務開始前系統(tǒng)處于什么狀態(tài)比如訂單待支付、客戶資料缺失、庫存不足。用戶請求用戶自然表達的一句話或一段話盡量模擬真實語氣。可用工具與權(quán)限Agent 在當前任務里能調(diào)用什么調(diào)不了什么。預期最終狀態(tài)任務成功后系統(tǒng)狀態(tài)應該變成什么樣這是最核心的驗收標準。參考軌跡可選一名熟練操作者大概會按什么順序調(diào)用哪些工具不一定要求 Agent 完全一致但可以作為過程評分參考。難度標簽單步任務、多步任務、異?；謴腿蝿?、長程任務方便后續(xù)按難度拆分分析。拿客服場景舉例初始狀態(tài)是“訂單 A100 狀態(tài)為已發(fā)貨用戶發(fā)起退款請求”用戶請求是“我要退掉剛收到的這個商品”預期最終狀態(tài)是“該訂單進入退款審核流程且原支付渠道生成了退款申請記錄”。只要最終狀態(tài)不對不管 Agent 回復得多么客氣這個用例都算失敗。任務集定義得越細后面所有分析才越有抓手。否則出了問題連是 Agent 的問題還是任務描述不清晰都分不清。2.2 結(jié)果層指標任務完成率、完成質(zhì)量和失敗分布結(jié)果層是所有指標里最核心的一層它回答的問題是Agent 到底把活干成沒有。我實際在用的指標組合是這樣任務完成率是最直觀的指標也就是預期終態(tài)斷言全部通過的用例占總用例的比例。這個指標必須字節(jié)級明確比如“訂單狀態(tài)字段變成 cancelled且取消原因字段等于用戶申請原因”不能寫“大體上完成”。部分完成率也很關(guān)鍵。有些任務 Agent 做了一半比如查到了訂單信息但退款環(huán)節(jié)沒執(zhí)行。我傾向于給這類任務單獨記一個“部分完成”標簽而不是簡單歸入失敗。部分完成率高說明 Agent 的信息理解、工具選擇能力還行但關(guān)鍵動作的執(zhí)行策略存在問題。失敗類型分布是我后來才補上的但價值極高。每跑完一輪評測把失敗用例按原因歸類統(tǒng)計是調(diào)用參數(shù)錯誤、信息缺失、政策誤判、還是中途放棄。這個分布能直接指向下一步優(yōu)化方向比單一通過率有用得多。另外對于有“參考答案”的任務我會引入一個質(zhì)量分由大模型或規(guī)則對最終產(chǎn)出質(zhì)量做五檔評價。但對這個打分我始終保持謹慎它只能作為輔助不能替代狀態(tài)斷言。2.3 過程層指標步數(shù)、工具使用和錯誤恢復結(jié)果層只能告訴你成沒成功不能告訴你為什么成功或失敗。所以必須有過程觀測。我最?？吹倪^程指標有這幾個平均步數(shù)。完成同一個任務Agent 用了 5 步和用了 25 步差距很大。步數(shù)過長往往意味著無效探索和反復試錯。步數(shù)暴漲通常對應評測結(jié)果惡化即使最終通過率還沒掉也值得警惕。工具調(diào)用序列。把每條用例的軌跡拉出來看 Agent 調(diào)了哪些工具、順序是什么、有沒有重復調(diào)用。如果在取消訂單任務里Agent 先調(diào)了五次查詢接口才發(fā)起取消請求說明工具選擇效率有明顯問題。錯誤恢復次數(shù)。統(tǒng)計 Agent 遇到工具異常后能自行修正并繼續(xù)完成的占比。這是衡量 Agent“辦事能力”很重要的維度。真實業(yè)務里總有接口抖動恢復能力決定了系統(tǒng)能否長期穩(wěn)定運行。無效循環(huán)檢測。如果 Agent 在同一個工具、同一個參數(shù)上反復調(diào)用超過三次基本可以認定它陷入了死循環(huán)這類用例必須單獨標記。過程層指標跑在一起本質(zhì)上是把 Agent 的“行為軌跡”轉(zhuǎn)成可量化數(shù)據(jù)這樣才能把每個失敗都定位到具體環(huán)節(jié)。2.4 成本與穩(wěn)定性指標Agent 評測本身是有成本的每一輪評測都是真實的模型調(diào)用。長期跑下來不看成本是不行的。我常記錄的指標包括單任務平均 token 消耗、工具調(diào)用總次數(shù)、單任務平均耗時、API 請求失敗率。這些指標不直接反映能力但直接決定評測能不能持續(xù)。如果某個版本平均 token 消耗暴漲了 50%即使通過率沒變也得看是不是 Agent 開始產(chǎn)生大量低效重試了。有時候我也會把“成本/通過率”看成一個綜合效率指標。通過率差不多的情況下成本更低的實現(xiàn)方案明顯更優(yōu)。這也是評測體系能在技術(shù)選型和 prompt 優(yōu)化里發(fā)揮價值的地方。3. 從零搭建 Agent 自動化評測環(huán)境的實操步驟3.1 評測環(huán)境三件套運行時、沙箱和工具樁到現(xiàn)在為止指標定義都有了下一步就要讓評測真的跑起來。實際操作里評測環(huán)境我從來不用生產(chǎn)環(huán)境而是自建一套隔離環(huán)境包含三個部分。第一是 Agent 運行時。就是被測 Agent 本身包括它的模型、prompt、工具注冊表、記憶模塊。評測時要能通過參數(shù)切換模型、切換 prompt 版本方便做對比實驗。第二是沙箱環(huán)境。任何可能有副作用的操作都要在沙箱里完成。最簡單的方式是用 Docker 起一個獨立容器容器里跑一個模擬業(yè)務系統(tǒng)比如模擬訂單庫、模擬支付網(wǎng)關(guān)。Agent 在沙箱里的任何操作都不會影響真實數(shù)據(jù)評測完可以隨手重置環(huán)境。第三是工具樁。核心思想是把外部依賴全部換成可控的模擬服務。比如真實支付接口在網(wǎng)絡抖動和冪等性上不可控但評測需要穩(wěn)定可復現(xiàn)所以我會啟動一個本地 HTTP 服務模擬支付接口返回碼、響應延遲、異常路徑全部由測試腳本指定。工具樁最妙的地方在于可以“注入故障”。想讓 Agent 遇到支付超時直接讓樁服務返回超時想看空結(jié)果的場景就讓查詢接口返回空列表。這種可控性在真實環(huán)境里是根本做不到的。3.2 評測用例在代碼里怎么落地環(huán)境搭好之后評測用例本身最好用代碼表達這樣才能集成 CI、做回歸。下面是我在項目里常見的一個用例骨架字段用了偽代碼思路可以直接落地# 評測用例骨架示例 async def test_cancel_order_success(agent_factory, sandbox): # 1. 準備初始業(yè)務狀態(tài) sandbox.db.create_order(order_idA100, statusactive) # 2. 構(gòu)造用戶請求 request 我要取消昨天下的那個訂單單號是A100 # 3. 運行被測 Agent result await agent_factory(requestrequest).run() # 4. 重點:校驗環(huán)境最終狀態(tài),而不是只看agent回復文本 assert sandbox.db.get_order(A100).status cancelled # 5. 輔助校驗過程:檢查軌跡里是否出現(xiàn)了預期工具調(diào)用 assert any(tool.name cancel_order for tool in result.trajectory)這段代碼里的核心思想是“用環(huán)境狀態(tài)斷言代替文本斷言”。Agent 的回復文本千變?nèi)f化直接解析文本既脆弱又容易誤判。狀態(tài)斷言是穩(wěn)定的、可精確驗證的這才是端到端評測該有的姿勢。實際用例會比這個復雜比如要處理超時、并發(fā)、依賴初始化。但骨架思路就是三步準備初始狀態(tài)、跑 Agent、斷言最終狀態(tài)。永遠不要試圖在評測腳本里逐字解析 Agent 回復里的客套話。3.3 用現(xiàn)成框架還是自建 harness我的取舍標準市面上已經(jīng)有一些評測框架比如 LangSmith、LangFuse以及各家模型服務商自帶的評測工具也常有人問我是直接用還是自己寫。我的個人經(jīng)驗是評測 harness 和 Agent 框架的關(guān)系應該是解耦的。評測 harness 的職責是加載評測集、初始化環(huán)境、運行 Agent、收集結(jié)果、執(zhí)行斷言、產(chǎn)報告。Agent 本身是 harness 的“被測物體”兩者之間只暴露標準接口。如果評測框架和 Agent 框架綁得過死一旦 Agent 換架構(gòu)評測體系也跟著推倒重來。所以我的取舍標準很直接如果你還在快速迭代階段Agent 的結(jié)構(gòu)都可能變那先用簡單的自定義 harness保持輕量別急著上大而全的框架。如果你的 Agent 框架穩(wěn)定了并且現(xiàn)有評測工具支持無侵入式接入可以考慮引入現(xiàn)成框架省去維護成本。不管選哪種評測腳本里盡量不要出現(xiàn) Agent 框架特有的內(nèi)部 API最好只通過一個 run() 方法交互。我自己長期用的是 pytest 加一層自定義 runner評測集是純數(shù)據(jù)文件。Agent 換過兩次底座評測體系基本沒傷筋動骨這就是解耦的好處。3.4 并發(fā)評測和成本控制的具體辦法評測集一旦變多幾百條用例順序跑可能要跑一個晚上所以并發(fā)是必然選擇。但并發(fā)也會帶來成本失控這兩者必須一起設計。我的做法是先給每類任務定一個并發(fā)上限。日常冒煙評測并發(fā) 8全量回歸并發(fā) 32 左右具體看模型服務端的限流策略。跑之前先估計總 token 消耗如果超出預算按任務難度分層抽樣優(yōu)先跑高價值用例。另外兩個習慣也值得養(yǎng)成一是用評測結(jié)果緩存。同一個任務集、同一個 Agent 版本、同一次運行之間如果評測輸入沒變化可以復用上次的緩存結(jié)果避免重復消耗。特別是開發(fā)調(diào) prompt 時只跑受影響的子集就夠了。二是對失敗用例做“二次確認”。第一次跑失敗的用例我會自動重跑一次區(qū)分偶發(fā)失敗和確定失敗。這一步常被忽略但能幫你過濾大量因為外部抖動產(chǎn)生的虛假失敗。4. 評測集怎么構(gòu)建才經(jīng)得起業(yè)務考驗4.1 從真實業(yè)務日志里挖評測任務評測集不能靠拍腦袋寫。評測集構(gòu)建的第一原則是盡可能從真實業(yè)務場景里來。真實場景的數(shù)據(jù)才有足夠的“野性”那些用戶千奇百怪的表達方式才是 Agent 每天要面對的真實壓力。我的操作路徑是這樣的第一步拉歷史業(yè)務日志篩出用戶真實請求比如客服會話里用戶提出的退款、改簽、查詢需求。第二步按意圖聚類。把表達不同但意圖相同的請求歸到一組比如“我要退錢”“這個商品我不想要了”“怎么申請退款”都歸到“退款申請”這個意圖下。第三步為每組請求補全任務要素初始狀態(tài)、預期最終狀態(tài)、期望工具序列。從日志里挖出來的任務最大的價值是它帶著真實噪聲。用戶不會按教科書說話會省略信息、會有錯別字、會一次提多個需求。這些在人工構(gòu)造里很難模擬到位。不過我提醒一句真實日志只解決“像不像真實用戶”的問題不等于覆蓋了所有關(guān)鍵路徑。因此還需要人工補齊邊界和異常場景。4.2 人工構(gòu)造和難度分級的思路補齊人工用例時我一般按這幾類去寫極簡表達用戶給的信息特別少看 Agent 會不會主動追問。信息冗余一句話里塞五六個意圖看 Agent 能不能拆解和排序。權(quán)限受限用戶想執(zhí)行某個操作但沒有權(quán)限看 Agent 是否及時告知并引導替代方案。工具異常外部服務返回超時、錯誤碼、空結(jié)果看 Agent 如何恢復。狀態(tài)沖突比如訂單已經(jīng)取消了用戶又要求取消看 Agent 正確理解新狀態(tài)并避免重復操作。寫完之后按難度分級。我習慣分成 P0 到 P3 四級P0 是最核心的主流程任何發(fā)布都必須通過P1 是常見變體P2 是邊界和異常P3 是長程復雜任務。分級的目的是讓回歸策略有彈性小改動跑 P0 P1大改動再擴大到全量。4.3 評測標簽體系與數(shù)據(jù)質(zhì)量維護評測集不是靜態(tài)資產(chǎn)它要隨著業(yè)務演進持續(xù)更新。為了讓更新有序我堅持給每條用例打標簽。標簽至少包括業(yè)務領域訂單、售后、營銷、能力類型信息查詢、狀態(tài)變更、多步驟協(xié)調(diào)、難度級別P0-P3、意圖聚類 ID、失敗模式用于分析時回填。有了標簽分析結(jié)果時可以快速切片。比如想知道“售后場景 P2 級別的通過率是不是下降了”一條查詢就能出來。沒有標簽的評測集跑完只能看個總通過率什么都定位不了。評測集本身也會“壞”。有些用例寫的時候預期狀態(tài)和后來業(yè)務調(diào)整不一致有些用例描述本身有歧義。所以我每輪全量回歸后都會掃一遍長期失敗的用例。如果同一個用例連續(xù)兩周失敗并且 Agent 改動和它無關(guān)大概率是用例本身有問題我寧可先把它標記為“待審核”也不讓它繼續(xù)污染通過率數(shù)字。5. Agent 評測踩坑實錄假通過、不穩(wěn)定和超時排查5.1 同一個用例第一次過、第二次掛怎么判斷Agent 評測最讓人頭疼的就是同一個用例這次跑通過下次跑就失敗看起來毫無規(guī)律。第一次遇到這種情況我花了好幾天排查代碼和環(huán)境最后發(fā)現(xiàn)根因在一部分隨機性上——模型采樣本身就不是確定性的?，F(xiàn)在的處理辦法是雙管齊下第一在評測配置里固定 temperature、top_p 等采樣參數(shù)能固定 seed 的盡量固定。這能降低一部分隨機波動但坦白說不能完全消除尤其是明顯基于某個前沿模型的 Agent。第二用“多次運行取多數(shù)”的策略。關(guān)鍵用例默認跑 3 次至少 2 次通過才算通過。這樣做單條用例成本上去了但穩(wěn)定性大幅提升。全量集跑一次花的時間多了可結(jié)果更有說服力。另外還要區(qū)分兩類失敗偶發(fā)失敗和趨勢性失敗。偶發(fā)失敗是同一用例多次運行有概率通過也有概率掛掉通常不是代碼問題。趨勢性失敗是某個模型版本或 prompt 修改后通過率持續(xù)下降這類必須當回歸處理。建立這種區(qū)分能幫你少折騰很多無謂的排查。5.2 “假通過”的識別與防御假通過是評測體系里最隱蔽的問題。表面上看用例跑通了實際上 Agent 根本就沒完成任務。我遇到過最典型的情況Agent 在工具執(zhí)行失敗后沒有重試也沒繼續(xù)處理只是回復用戶“非常抱歉系統(tǒng)暫時無法處理您的請求請稍后再試”。從回復文本上看它既禮貌又合理但環(huán)境狀態(tài)根本沒變。如果用文本匹配來驗收這個用例大概率會被判通過。防御手段只有一個就是在評測腳本里強制做“環(huán)境狀態(tài)斷言”。如果訂單狀態(tài)沒有變成 cancelled不管 Agent 回復得多誠懇一律判失敗。另一個假通過場景是工具樁返回了假數(shù)據(jù)。比如模擬查詢接口里預制了所有訂單狀態(tài)為“已取消”那 Agent 無論怎么查都是已取消最終斷言當然能過。所以每次跑評測前工具的初始數(shù)據(jù)都要由測試用例顯式重置不能依賴上一次運行留下的狀態(tài)。5.3 超時、卡死和工具異常的處理套路Agent 測評跑久了一定會遇到超時和卡死不提前處理的話會拖垮整個評測流程。我目前的標準配置是整個任務設置最大時長我常用 10 分鐘超過就直接終止并標記“超時失敗”。單個工具調(diào)用設置超時我常用 20 秒。超時的工具返回一個標準錯誤給 Agent觀察它能不能恢復。設置最大步數(shù)一般 40 步。超過 40 步仍然沒完成基本可以認定是低效循環(huán)直接斷掉。循環(huán)檢測也很有用。同一工具、同一參數(shù)調(diào)用超過三次評測腳本可以給 Agent 發(fā)一個系統(tǒng)提示或者直接終止。工具異常不光是超時還有返回格式異常、內(nèi)容為空的邊界情況。評測時要有意把這些情況注入到工具樁里。真實系統(tǒng)里接口不會永遠是理想狀態(tài)Agent 有沒有預案靠評測見分曉。5.4 把評測掛進 CI 前要想清楚這幾件事很多團隊做到一定程度就想把評測塞進 CI每次提交代碼都跑全量。我的建議是別急著全量先做分層。我把評測拆成兩層。第一層是冒煙評測十幾條 P0 用例覆蓋主流程跑完只要幾分鐘。任何變更包括 prompt 調(diào)整、工具改動、模型切換都要跑冒煙。第二層是全量評測幾百條用例在夜間跑或發(fā)布前跑。全量過了才允許上線。另外 CI 里跑評測要注意緩存。如果評測集沒變化、Agent 版本沒變化同樣的用例不應該在每次 CI 里重復消耗 token。配合結(jié)果緩存能把 CI 成本壓到一個合理范圍。還有一點不能忽視評測頻率別太高。真沒必要每次 push 都跑幾百條用例。按變更范圍動態(tài)選擇評測子集改 prompt 就只跑 prompt 敏感用例改工具才跑工具相關(guān)用例這是控制預算最有效的手段。5.5 問題排查快速判定清單把最常見的現(xiàn)象、可能原因和優(yōu)先動作列成一張表排查時直接對表操作效率會高很多現(xiàn)象可能原因優(yōu)先動作用例首次通過、二次失敗模型采樣隨機、外部服務抖動固定采樣參數(shù)多次運行取多數(shù)區(qū)分偶發(fā)與趨勢失敗通過率高但上線后表現(xiàn)差評測集與真實分布偏差大環(huán)境斷言漏回真實日志補任務補強環(huán)境狀態(tài)斷言Agent 反復調(diào)用同一個工具工具參數(shù)生成錯誤、缺少終止條件檢查軌跡中的參數(shù)增加循環(huán)檢測某個用例一直超時工具樁響應慢、Agent 陷入死循環(huán)增加單工具超時減少困惑路徑觀察軌跡并發(fā)一高就大量失敗API 限流、資源競爭降低并發(fā)增加重試策略檢查評測資源獨立部署連續(xù)多輪通過率驟降模型版本升級、prompt 變更對比歷史軌跡差異回滾變更定位回歸這張表我打印出來貼在工位旁邊每次評測出問題都對一遍省了很多重復排查的時間。6. 如果重來一遍我會最先做哪兩件事6.1 把真實業(yè)務日志轉(zhuǎn)評測集這件事提前做最開始搭評測時我的評測集大多靠團隊“想出來”后來又花了大功夫去業(yè)務日志里挖真實請求。兩者之間差別極大真實的用詞、真實的情緒、真實的省略都會影響評測效果。如果重來一遍我會在第一天就安排人去拉日志、聚類意圖、建初版評測集。這是讓評測體系有生命力的關(guān)鍵也是最難后期補的功課。6.2 把環(huán)境狀態(tài)校驗寫進每條用例第二個會提前做的是環(huán)境狀態(tài)斷言。我在早期很多用例里只校驗 Agent 的回復文本導致漏掉一批“假通過”的垃圾結(jié)果。現(xiàn)在每條用例的第一條斷言都是“業(yè)務環(huán)境狀態(tài)是否符合預期”文本判斷只作為輔助。環(huán)境狀態(tài)斷言看起來簡單但需要業(yè)務方深度參與定義“什么才算真正完成”。這個過程本身就是和業(yè)務對齊預期的過程價值遠超技術(shù)本身。最后再分享一個心得評測體系的價值不在跑出多漂亮的數(shù)字而在每次數(shù)字波動時能幫團隊快速定位到具體問題、具體用例、具體軌跡。別追求一百分先把“可解釋”做到六十分這套體系在團隊里就自然站得住腳了。 Agent自動化評測體系搭建：從LLM評測誤區(qū)到端到端工程實踐
做 Agent 評測這件事我踩過最深的一個坑是拿評測大模型的老思路硬套 Agent。以前做 LLM 評測整理一批輸入輸出對寫腳本離線跑一遍把文本和參考答案比對一下交付就完了?？?Agent 一旦跑起來就是多輪推理加行動要查數(shù)據(jù)庫、調(diào)外部接口、改配置、做狀態(tài)變更中間任何一環(huán)出錯最終結(jié)果都可能和預期差出十萬八千里。大概從兩年前開始我陸續(xù)幫著幾個業(yè)務團隊搭過不同形態(tài)的 Agent 自動化評測體系。越搭越明白端到端的 Agent Evaluation 并不是寫幾個評測腳本那么簡單它是一整套圍繞任務設計、環(huán)境模擬、結(jié)果觀測、指標定義和數(shù)據(jù)迭代搭建起來的工程系統(tǒng)。這篇文章把我在實操中怎么拆解 Agent 自動化評測、怎么搭端到端評測體系、以及踩過的那些坑完整記錄下來。正在為“Agent 怎么做自動化評測”發(fā)愁的同學可以重點看測評集已經(jīng)跑起來但結(jié)果總是被業(yè)務方挑戰(zhàn)的人也能從這里找到一些排查思路。1. Agent 評測為什么不能直接套用 LLM 評測的方案1.1 傳統(tǒng) LLM 評測的本質(zhì)是一次性答卷過去做大模型評測最常見的形式就是準備一批輸入輸出對讓模型生成一次答案然后和參考答案對比。不管是基于規(guī)則的比對、算 BLEU/ROUGE還是用評判模型打分本質(zhì)上都是在給“一份答卷”評分。一張卷子一錘定音交完就完事。這套模式對文本生成、摘要、分類、問答這些場景沒問題它考驗的是模型在給定輸入下的“一次性推理能力”。但放到 Agent 上情況就完全變了。Agent 的產(chǎn)出不是一個最終文本而是一連串行動序列。比如一個客服 Agent 處理退款申請讀郵件、查訂單系統(tǒng)、判斷是否符合退款政策、調(diào)用退款接口、給用戶寫回復。每一步都有取舍下一步往往依賴上一步的結(jié)果。如果只看最后那句“我已經(jīng)為您辦理退款”你根本不知道它是不是真的把退款接口調(diào)成功了。所以把 Agent 評測簡單當成“給最終回復打分”是最大的誤解也是很多評測體系做出來沒人信的直接原因。1.2 Agent 評測的差異從“考背誦”變成“考辦事”我經(jīng)常給團隊里的同學打個比方LLM 評測像是考背誦Agent 評測更像考辦事?？嫁k事有個特點過程和結(jié)果同等重要。辦事的人要打開瀏覽器搜索資料、要撥打電話核實信息、要填寫表單提交申請這些動作都有對錯。更有意思的是辦事過程中還會遇到突發(fā)情況——電話沒人接、系統(tǒng)報錯、用戶改主意這時能否恢復過來、繼續(xù)把事辦成才是真正要測的能力。落到 Agent 上這幾點和 LLM 評測完全不同環(huán)境交互。Agent 必須真實或近似真實地和外部環(huán)境交互評測需要模擬環(huán)境并觀察狀態(tài)變化。多步?jīng)Q策。每一步都可能錯錯誤會累積中間一步錯了后面再多步都可能白費。工具調(diào)用正確性。不僅要看是否調(diào)用了工具還要看參數(shù)對不對、調(diào)用時機對不對、返回值有沒有被正確解析。故障恢復。工具拋異常時Agent 是繼續(xù)亂撞還是冷靜處理這直接影響任務成功率。這四個差異決定了評測設計必須同時關(guān)注“最終效果”和“完成過程”只看一頭都不行。1.3 端到端評測要分三個層級去看既然 Agent 評測和 LLM 評測完全不是一回事那評測體系也不能只有一層。我給自己搭評測體系定了一個三層結(jié)構(gòu)每個層級解決不同問題第一層是單元能力評測。單獨驗證 Agent 里頭某個能力模塊比如工具調(diào)用參數(shù)生成是否正確、某個 prompt 分支是否穩(wěn)定。這一層跑得快適合開發(fā)階段頻繁自測。第二層是流程鏈路評測。把 Agent 放進 mock 環(huán)境里給定初始狀態(tài)跑完一個完整任務但環(huán)境里的外部依賴都用可控的樁替代。這是主力既能端到端觀察又能控制變量。第三層才是真正貼近線上的端到端評測。在盡量接近生產(chǎn)的環(huán)境里跑外部服務用沙箱或測試賬號數(shù)據(jù)用脫敏后的真實數(shù)據(jù)。這一層最真實、也最貴適合發(fā)布前做全量回歸。很多團隊一上來就想直接做第三層發(fā)現(xiàn)又貴又不穩(wěn)定做了幾天就跑不下去了。實際踩下來還是得從第二層起步先把可控性做扎實再往真實環(huán)境逼近。這也是這篇文章主推的思路。2. 端到端評測體系怎么設計任務、指標和過程觀測2.1 評測任務集定義把業(yè)務需求翻譯成可執(zhí)行任務構(gòu)建端到端評測體系第一步不是選框架也不是寫腳本而是定義評測任務集。評測任務集不是隨便列一些用戶問題就完事每個任務必須包含以下要素初始狀態(tài)任務開始前系統(tǒng)處于什么狀態(tài)比如訂單待支付、客戶資料缺失、庫存不足。用戶請求用戶自然表達的一句話或一段話盡量模擬真實語氣。可用工具與權(quán)限Agent 在當前任務里能調(diào)用什么調(diào)不了什么。預期最終狀態(tài)任務成功后系統(tǒng)狀態(tài)應該變成什么樣這是最核心的驗收標準。參考軌跡可選一名熟練操作者大概會按什么順序調(diào)用哪些工具不一定要求 Agent 完全一致但可以作為過程評分參考。難度標簽單步任務、多步任務、異?；謴腿蝿?、長程任務方便后續(xù)按難度拆分分析。拿客服場景舉例初始狀態(tài)是“訂單 A100 狀態(tài)為已發(fā)貨用戶發(fā)起退款請求”用戶請求是“我要退掉剛收到的這個商品”預期最終狀態(tài)是“該訂單進入退款審核流程且原支付渠道生成了退款申請記錄”。只要最終狀態(tài)不對不管 Agent 回復得多么客氣這個用例都算失敗。任務集定義得越細后面所有分析才越有抓手。否則出了問題連是 Agent 的問題還是任務描述不清晰都分不清。2.2 結(jié)果層指標任務完成率、完成質(zhì)量和失敗分布結(jié)果層是所有指標里最核心的一層它回答的問題是Agent 到底把活干成沒有。我實際在用的指標組合是這樣任務完成率是最直觀的指標也就是預期終態(tài)斷言全部通過的用例占總用例的比例。這個指標必須字節(jié)級明確比如“訂單狀態(tài)字段變成 cancelled且取消原因字段等于用戶申請原因”不能寫“大體上完成”。部分完成率也很關(guān)鍵。有些任務 Agent 做了一半比如查到了訂單信息但退款環(huán)節(jié)沒執(zhí)行。我傾向于給這類任務單獨記一個“部分完成”標簽而不是簡單歸入失敗。部分完成率高說明 Agent 的信息理解、工具選擇能力還行但關(guān)鍵動作的執(zhí)行策略存在問題。失敗類型分布是我后來才補上的但價值極高。每跑完一輪評測把失敗用例按原因歸類統(tǒng)計是調(diào)用參數(shù)錯誤、信息缺失、政策誤判、還是中途放棄。這個分布能直接指向下一步優(yōu)化方向比單一通過率有用得多。另外對于有“參考答案”的任務我會引入一個質(zhì)量分由大模型或規(guī)則對最終產(chǎn)出質(zhì)量做五檔評價。但對這個打分我始終保持謹慎它只能作為輔助不能替代狀態(tài)斷言。2.3 過程層指標步數(shù)、工具使用和錯誤恢復結(jié)果層只能告訴你成沒成功不能告訴你為什么成功或失敗。所以必須有過程觀測。我最?？吹倪^程指標有這幾個平均步數(shù)。完成同一個任務Agent 用了 5 步和用了 25 步差距很大。步數(shù)過長往往意味著無效探索和反復試錯。步數(shù)暴漲通常對應評測結(jié)果惡化即使最終通過率還沒掉也值得警惕。工具調(diào)用序列。把每條用例的軌跡拉出來看 Agent 調(diào)了哪些工具、順序是什么、有沒有重復調(diào)用。如果在取消訂單任務里Agent 先調(diào)了五次查詢接口才發(fā)起取消請求說明工具選擇效率有明顯問題。錯誤恢復次數(shù)。統(tǒng)計 Agent 遇到工具異常后能自行修正并繼續(xù)完成的占比。這是衡量 Agent“辦事能力”很重要的維度。真實業(yè)務里總有接口抖動恢復能力決定了系統(tǒng)能否長期穩(wěn)定運行。無效循環(huán)檢測。如果 Agent 在同一個工具、同一個參數(shù)上反復調(diào)用超過三次基本可以認定它陷入了死循環(huán)這類用例必須單獨標記。過程層指標跑在一起本質(zhì)上是把 Agent 的“行為軌跡”轉(zhuǎn)成可量化數(shù)據(jù)這樣才能把每個失敗都定位到具體環(huán)節(jié)。2.4 成本與穩(wěn)定性指標Agent 評測本身是有成本的每一輪評測都是真實的模型調(diào)用。長期跑下來不看成本是不行的。我常記錄的指標包括單任務平均 token 消耗、工具調(diào)用總次數(shù)、單任務平均耗時、API 請求失敗率。這些指標不直接反映能力但直接決定評測能不能持續(xù)。如果某個版本平均 token 消耗暴漲了 50%即使通過率沒變也得看是不是 Agent 開始產(chǎn)生大量低效重試了。有時候我也會把“成本/通過率”看成一個綜合效率指標。通過率差不多的情況下成本更低的實現(xiàn)方案明顯更優(yōu)。這也是評測體系能在技術(shù)選型和 prompt 優(yōu)化里發(fā)揮價值的地方。3. 從零搭建 Agent 自動化評測環(huán)境的實操步驟3.1 評測環(huán)境三件套運行時、沙箱和工具樁到現(xiàn)在為止指標定義都有了下一步就要讓評測真的跑起來。實際操作里評測環(huán)境我從來不用生產(chǎn)環(huán)境而是自建一套隔離環(huán)境包含三個部分。第一是 Agent 運行時。就是被測 Agent 本身包括它的模型、prompt、工具注冊表、記憶模塊。評測時要能通過參數(shù)切換模型、切換 prompt 版本方便做對比實驗。第二是沙箱環(huán)境。任何可能有副作用的操作都要在沙箱里完成。最簡單的方式是用 Docker 起一個獨立容器容器里跑一個模擬業(yè)務系統(tǒng)比如模擬訂單庫、模擬支付網(wǎng)關(guān)。Agent 在沙箱里的任何操作都不會影響真實數(shù)據(jù)評測完可以隨手重置環(huán)境。第三是工具樁。核心思想是把外部依賴全部換成可控的模擬服務。比如真實支付接口在網(wǎng)絡抖動和冪等性上不可控但評測需要穩(wěn)定可復現(xiàn)所以我會啟動一個本地 HTTP 服務模擬支付接口返回碼、響應延遲、異常路徑全部由測試腳本指定。工具樁最妙的地方在于可以“注入故障”。想讓 Agent 遇到支付超時直接讓樁服務返回超時想看空結(jié)果的場景就讓查詢接口返回空列表。這種可控性在真實環(huán)境里是根本做不到的。3.2 評測用例在代碼里怎么落地環(huán)境搭好之后評測用例本身最好用代碼表達這樣才能集成 CI、做回歸。下面是我在項目里常見的一個用例骨架字段用了偽代碼思路可以直接落地# 評測用例骨架示例 async def test_cancel_order_success(agent_factory, sandbox): # 1. 準備初始業(yè)務狀態(tài) sandbox.db.create_order(order_idA100, statusactive) # 2. 構(gòu)造用戶請求 request 我要取消昨天下的那個訂單單號是A100 # 3. 運行被測 Agent result await agent_factory(requestrequest).run() # 4. 重點:校驗環(huán)境最終狀態(tài),而不是只看agent回復文本 assert sandbox.db.get_order(A100).status cancelled # 5. 輔助校驗過程:檢查軌跡里是否出現(xiàn)了預期工具調(diào)用 assert any(tool.name cancel_order for tool in result.trajectory)這段代碼里的核心思想是“用環(huán)境狀態(tài)斷言代替文本斷言”。Agent 的回復文本千變?nèi)f化直接解析文本既脆弱又容易誤判。狀態(tài)斷言是穩(wěn)定的、可精確驗證的這才是端到端評測該有的姿勢。實際用例會比這個復雜比如要處理超時、并發(fā)、依賴初始化。但骨架思路就是三步準備初始狀態(tài)、跑 Agent、斷言最終狀態(tài)。永遠不要試圖在評測腳本里逐字解析 Agent 回復里的客套話。3.3 用現(xiàn)成框架還是自建 harness我的取舍標準市面上已經(jīng)有一些評測框架比如 LangSmith、LangFuse以及各家模型服務商自帶的評測工具也常有人問我是直接用還是自己寫。我的個人經(jīng)驗是評測 harness 和 Agent 框架的關(guān)系應該是解耦的。評測 harness 的職責是加載評測集、初始化環(huán)境、運行 Agent、收集結(jié)果、執(zhí)行斷言、產(chǎn)報告。Agent 本身是 harness 的“被測物體”兩者之間只暴露標準接口。如果評測框架和 Agent 框架綁得過死一旦 Agent 換架構(gòu)評測體系也跟著推倒重來。所以我的取舍標準很直接如果你還在快速迭代階段Agent 的結(jié)構(gòu)都可能變那先用簡單的自定義 harness保持輕量別急著上大而全的框架。如果你的 Agent 框架穩(wěn)定了并且現(xiàn)有評測工具支持無侵入式接入可以考慮引入現(xiàn)成框架省去維護成本。不管選哪種評測腳本里盡量不要出現(xiàn) Agent 框架特有的內(nèi)部 API最好只通過一個 run() 方法交互。我自己長期用的是 pytest 加一層自定義 runner評測集是純數(shù)據(jù)文件。Agent 換過兩次底座評測體系基本沒傷筋動骨這就是解耦的好處。3.4 并發(fā)評測和成本控制的具體辦法評測集一旦變多幾百條用例順序跑可能要跑一個晚上所以并發(fā)是必然選擇。但并發(fā)也會帶來成本失控這兩者必須一起設計。我的做法是先給每類任務定一個并發(fā)上限。日常冒煙評測并發(fā) 8全量回歸并發(fā) 32 左右具體看模型服務端的限流策略。跑之前先估計總 token 消耗如果超出預算按任務難度分層抽樣優(yōu)先跑高價值用例。另外兩個習慣也值得養(yǎng)成一是用評測結(jié)果緩存。同一個任務集、同一個 Agent 版本、同一次運行之間如果評測輸入沒變化可以復用上次的緩存結(jié)果避免重復消耗。特別是開發(fā)調(diào) prompt 時只跑受影響的子集就夠了。二是對失敗用例做“二次確認”。第一次跑失敗的用例我會自動重跑一次區(qū)分偶發(fā)失敗和確定失敗。這一步常被忽略但能幫你過濾大量因為外部抖動產(chǎn)生的虛假失敗。4. 評測集怎么構(gòu)建才經(jīng)得起業(yè)務考驗4.1 從真實業(yè)務日志里挖評測任務評測集不能靠拍腦袋寫。評測集構(gòu)建的第一原則是盡可能從真實業(yè)務場景里來。真實場景的數(shù)據(jù)才有足夠的“野性”那些用戶千奇百怪的表達方式才是 Agent 每天要面對的真實壓力。我的操作路徑是這樣的第一步拉歷史業(yè)務日志篩出用戶真實請求比如客服會話里用戶提出的退款、改簽、查詢需求。第二步按意圖聚類。把表達不同但意圖相同的請求歸到一組比如“我要退錢”“這個商品我不想要了”“怎么申請退款”都歸到“退款申請”這個意圖下。第三步為每組請求補全任務要素初始狀態(tài)、預期最終狀態(tài)、期望工具序列。從日志里挖出來的任務最大的價值是它帶著真實噪聲。用戶不會按教科書說話會省略信息、會有錯別字、會一次提多個需求。這些在人工構(gòu)造里很難模擬到位。不過我提醒一句真實日志只解決“像不像真實用戶”的問題不等于覆蓋了所有關(guān)鍵路徑。因此還需要人工補齊邊界和異常場景。4.2 人工構(gòu)造和難度分級的思路補齊人工用例時我一般按這幾類去寫極簡表達用戶給的信息特別少看 Agent 會不會主動追問。信息冗余一句話里塞五六個意圖看 Agent 能不能拆解和排序。權(quán)限受限用戶想執(zhí)行某個操作但沒有權(quán)限看 Agent 是否及時告知并引導替代方案。工具異常外部服務返回超時、錯誤碼、空結(jié)果看 Agent 如何恢復。狀態(tài)沖突比如訂單已經(jīng)取消了用戶又要求取消看 Agent 正確理解新狀態(tài)并避免重復操作。寫完之后按難度分級。我習慣分成 P0 到 P3 四級P0 是最核心的主流程任何發(fā)布都必須通過P1 是常見變體P2 是邊界和異常P3 是長程復雜任務。分級的目的是讓回歸策略有彈性小改動跑 P0 P1大改動再擴大到全量。4.3 評測標簽體系與數(shù)據(jù)質(zhì)量維護評測集不是靜態(tài)資產(chǎn)它要隨著業(yè)務演進持續(xù)更新。為了讓更新有序我堅持給每條用例打標簽。標簽至少包括業(yè)務領域訂單、售后、營銷、能力類型信息查詢、狀態(tài)變更、多步驟協(xié)調(diào)、難度級別P0-P3、意圖聚類 ID、失敗模式用于分析時回填。有了標簽分析結(jié)果時可以快速切片。比如想知道“售后場景 P2 級別的通過率是不是下降了”一條查詢就能出來。沒有標簽的評測集跑完只能看個總通過率什么都定位不了。評測集本身也會“壞”。有些用例寫的時候預期狀態(tài)和后來業(yè)務調(diào)整不一致有些用例描述本身有歧義。所以我每輪全量回歸后都會掃一遍長期失敗的用例。如果同一個用例連續(xù)兩周失敗并且 Agent 改動和它無關(guān)大概率是用例本身有問題我寧可先把它標記為“待審核”也不讓它繼續(xù)污染通過率數(shù)字。5. Agent 評測踩坑實錄假通過、不穩(wěn)定和超時排查5.1 同一個用例第一次過、第二次掛怎么判斷Agent 評測最讓人頭疼的就是同一個用例這次跑通過下次跑就失敗看起來毫無規(guī)律。第一次遇到這種情況我花了好幾天排查代碼和環(huán)境最后發(fā)現(xiàn)根因在一部分隨機性上——模型采樣本身就不是確定性的?，F(xiàn)在的處理辦法是雙管齊下第一在評測配置里固定 temperature、top_p 等采樣參數(shù)能固定 seed 的盡量固定。這能降低一部分隨機波動但坦白說不能完全消除尤其是明顯基于某個前沿模型的 Agent。第二用“多次運行取多數(shù)”的策略。關(guān)鍵用例默認跑 3 次至少 2 次通過才算通過。這樣做單條用例成本上去了但穩(wěn)定性大幅提升。全量集跑一次花的時間多了可結(jié)果更有說服力。另外還要區(qū)分兩類失敗偶發(fā)失敗和趨勢性失敗。偶發(fā)失敗是同一用例多次運行有概率通過也有概率掛掉通常不是代碼問題。趨勢性失敗是某個模型版本或 prompt 修改后通過率持續(xù)下降這類必須當回歸處理。建立這種區(qū)分能幫你少折騰很多無謂的排查。5.2 “假通過”的識別與防御假通過是評測體系里最隱蔽的問題。表面上看用例跑通了實際上 Agent 根本就沒完成任務。我遇到過最典型的情況Agent 在工具執(zhí)行失敗后沒有重試也沒繼續(xù)處理只是回復用戶“非常抱歉系統(tǒng)暫時無法處理您的請求請稍后再試”。從回復文本上看它既禮貌又合理但環(huán)境狀態(tài)根本沒變。如果用文本匹配來驗收這個用例大概率會被判通過。防御手段只有一個就是在評測腳本里強制做“環(huán)境狀態(tài)斷言”。如果訂單狀態(tài)沒有變成 cancelled不管 Agent 回復得多誠懇一律判失敗。另一個假通過場景是工具樁返回了假數(shù)據(jù)。比如模擬查詢接口里預制了所有訂單狀態(tài)為“已取消”那 Agent 無論怎么查都是已取消最終斷言當然能過。所以每次跑評測前工具的初始數(shù)據(jù)都要由測試用例顯式重置不能依賴上一次運行留下的狀態(tài)。5.3 超時、卡死和工具異常的處理套路Agent 測評跑久了一定會遇到超時和卡死不提前處理的話會拖垮整個評測流程。我目前的標準配置是整個任務設置最大時長我常用 10 分鐘超過就直接終止并標記“超時失敗”。單個工具調(diào)用設置超時我常用 20 秒。超時的工具返回一個標準錯誤給 Agent觀察它能不能恢復。設置最大步數(shù)一般 40 步。超過 40 步仍然沒完成基本可以認定是低效循環(huán)直接斷掉。循環(huán)檢測也很有用。同一工具、同一參數(shù)調(diào)用超過三次評測腳本可以給 Agent 發(fā)一個系統(tǒng)提示或者直接終止。工具異常不光是超時還有返回格式異常、內(nèi)容為空的邊界情況。評測時要有意把這些情況注入到工具樁里。真實系統(tǒng)里接口不會永遠是理想狀態(tài)Agent 有沒有預案靠評測見分曉。5.4 把評測掛進 CI 前要想清楚這幾件事很多團隊做到一定程度就想把評測塞進 CI每次提交代碼都跑全量。我的建議是別急著全量先做分層。我把評測拆成兩層。第一層是冒煙評測十幾條 P0 用例覆蓋主流程跑完只要幾分鐘。任何變更包括 prompt 調(diào)整、工具改動、模型切換都要跑冒煙。第二層是全量評測幾百條用例在夜間跑或發(fā)布前跑。全量過了才允許上線。另外 CI 里跑評測要注意緩存。如果評測集沒變化、Agent 版本沒變化同樣的用例不應該在每次 CI 里重復消耗 token。配合結(jié)果緩存能把 CI 成本壓到一個合理范圍。還有一點不能忽視評測頻率別太高。真沒必要每次 push 都跑幾百條用例。按變更范圍動態(tài)選擇評測子集改 prompt 就只跑 prompt 敏感用例改工具才跑工具相關(guān)用例這是控制預算最有效的手段。5.5 問題排查快速判定清單把最常見的現(xiàn)象、可能原因和優(yōu)先動作列成一張表排查時直接對表操作效率會高很多現(xiàn)象可能原因優(yōu)先動作用例首次通過、二次失敗模型采樣隨機、外部服務抖動固定采樣參數(shù)多次運行取多數(shù)區(qū)分偶發(fā)與趨勢失敗通過率高但上線后表現(xiàn)差評測集與真實分布偏差大環(huán)境斷言漏回真實日志補任務補強環(huán)境狀態(tài)斷言Agent 反復調(diào)用同一個工具工具參數(shù)生成錯誤、缺少終止條件檢查軌跡中的參數(shù)增加循環(huán)檢測某個用例一直超時工具樁響應慢、Agent 陷入死循環(huán)增加單工具超時減少困惑路徑觀察軌跡并發(fā)一高就大量失敗API 限流、資源競爭降低并發(fā)增加重試策略檢查評測資源獨立部署連續(xù)多輪通過率驟降模型版本升級、prompt 變更對比歷史軌跡差異回滾變更定位回歸這張表我打印出來貼在工位旁邊每次評測出問題都對一遍省了很多重復排查的時間。6. 如果重來一遍我會最先做哪兩件事6.1 把真實業(yè)務日志轉(zhuǎn)評測集這件事提前做最開始搭評測時我的評測集大多靠團隊“想出來”后來又花了大功夫去業(yè)務日志里挖真實請求。兩者之間差別極大真實的用詞、真實的情緒、真實的省略都會影響評測效果。如果重來一遍我會在第一天就安排人去拉日志、聚類意圖、建初版評測集。這是讓評測體系有生命力的關(guān)鍵也是最難后期補的功課。6.2 把環(huán)境狀態(tài)校驗寫進每條用例第二個會提前做的是環(huán)境狀態(tài)斷言。我在早期很多用例里只校驗 Agent 的回復文本導致漏掉一批“假通過”的垃圾結(jié)果。現(xiàn)在每條用例的第一條斷言都是“業(yè)務環(huán)境狀態(tài)是否符合預期”文本判斷只作為輔助。環(huán)境狀態(tài)斷言看起來簡單但需要業(yè)務方深度參與定義“什么才算真正完成”。這個過程本身就是和業(yè)務對齊預期的過程價值遠超技術(shù)本身。最后再分享一個心得評測體系的價值不在跑出多漂亮的數(shù)字而在每次數(shù)字波動時能幫團隊快速定位到具體問題、具體用例、具體軌跡。別追求一百分先把“可解釋”做到六十分這套體系在團隊里就自然站得住腳了。