從 Task、Trial、Transcript 與 Outcome 理解一次 Agent 評估，梳理 Grader 的選擇與組合、pass@k 與 pass^k 的區別，以及能力評估、迴歸評估和評估集的持續維護。
前一篇討論了怎樣為 Agent 準備可理解、可操作、可驗證的工程環境。接下來要回答的是：修改模型、提示詞或工具以後，怎樣知道這套系統真的做得更好了？
對會調用工具的 Agent 來説，回答寫得像完成了任務，與任務實際完成，是兩件事。它可能正確解釋了退款政策，卻沒有創建退款記錄；也可能完成了操作，但向用户報告了錯誤金額。只讀最後一句回答，很難判斷整個任務的質量。
結合 Anthropic 的《Demystifying evals for AI agents》，本文圍繞四個問題展開：
- 評什麼： 怎樣定義任務，記錄一次嘗試的執行過程與實際結果。
- 怎麼評分： 程序、模型和人工分別適合判斷什麼，多個標準怎樣組合。
- 怎麼看穩定性： 同一個任務為什麼要重複運行，pass@k 與 pass^k 分別説明什麼。
- 怎樣持續使用： 能力評估與迴歸評估怎樣分工，真實失敗怎樣成為可重複的測試。
下面用一個假設的售後任務貫穿説明：用户要求退回一筆已取消訂單的 50 元付款。訂單、退款系統和檢查標準都是教學示例，不涉及真實交易。
一、一次 Agent Eval 需要哪些材料h2
一次評估不只是“給問題、看回答、打分”。先把任務條件、執行記錄和完成標準分開，才知道後面的分數究竟在衡量什麼。
1. Task 與 Trial：任務條件和一次具體嘗試h3
Task 是一項有明確輸入與成功標準的測試任務；Trial 是 Agent 對這項任務的一次嘗試。 同一項 Task 可以運行多個 Trial，而每個 Trial 內部又可以包含多次模型調用和工具執行。
在退款例子裏，只寫“幫用户退款”還不夠。任務至少要交代這些條件：
- 用户身份已經驗證，訂單屬於當前用户。
- 訂單已取消，付款為 50 元，當前不存在退款記錄。
- 測試政策允許全額退款，用户已明確確認。
- Agent 可以查詢訂單、讀取政策和提交退款，不能修改其他訂單。
- 成功意味着指定訂單隻產生一筆 50 元的成功退款，且答覆與實際狀態一致。
這些約定把自然語言請求連接到可以檢查的結果。否則，“已經提交申請”究竟算不算完成，兩位評審者都可能給出不同答案。
第一次 Trial 可能先查詢政策，再查詢訂單；第二次可能先讀取訂單，發現取消狀態後再核對政策。只要這些順序沒有違反任務要求，就不必因為路徑不同判其中一次失敗。
Task 固定需要完成什麼，Trial 記錄某一次實際怎樣做。 這也解釋了為什麼一條工具調用不是一個 Trial：查詢訂單只是嘗試中的一步，退款和最終答覆可能還在後面。
2. Transcript 與 Outcome：執行記錄和環境終態h3
Transcript，也常稱 Trace 或 Trajectory，記錄一次嘗試中能夠採集到的交互：用户消息、模型輸出、工具請求、工具返回等。Outcome 則是這次嘗試結束後，環境實際處於什麼狀態。
對於退款任務，可以分別檢查：
| 檢查對象 | 能取得的證據 | 能説明什麼 |
|---|---|---|
| Transcript | 查詢了哪個訂單，提交了什麼金額，工具返回了什麼，最後怎樣答覆 | Agent 做過什麼、依據什麼繼續行動 |
| Outcome | 退款記錄、訂單餘額、其他訂單是否被改動 | 請求的變化是否真的發生，是否產生額外影響 |
假設 Agent 説“50 元已經退回”，但退款工具返回失敗，數據庫裏也沒有成功記錄。答覆出現在 Transcript 中，卻不能代替 Outcome。
反過來，數據庫確實存在正確退款，也不能證明整個過程都合格。如果 Agent 同時告訴用户“退回了 500 元”，溝通仍然有問題；如果它還試圖修改另一位用户的訂單，單看目標訂單的終態也會漏掉重要行為。
因此，結果檢查回答“事情有沒有做成”，過程記錄提供“做了什麼”的證據。 兩者可以參與同一項評估，但不是同一份材料。
這裏的執行記錄也不是模型全部內部活動的快照。能評估的是系統實際記錄到的信息，不能把不可見的推理當成已經採集的證據。
3. Evaluation Harness：組織運行、採集與評分h3
Agent Runtime負責把模型、工具和交互連接成工作過程。Evaluation Harness 在外面組織測試：準備任務環境、啓動一次嘗試、收集證據、運行 Grader，再彙總結果。
可以把兩者的職責分開看：
- Agent Harness： 接收請求，組織推理與工具執行，讓 Agent 能夠行動。
- Evaluation Harness： 安排用什麼任務測試、從什麼起點運行、怎樣檢查和比較結果。
被測對象通常是模型與 Agent Harness 的組合。模型沒換，但工具定義、上下文組織或退出邏輯變了，評估結果同樣可能變化。
一組圍繞某種能力組織的 Task，構成 Evaluation Suite。例如，售後評估集可以包含正常退款、重複申請、信息缺失和需要人工處理的任務。Suite 是任務的集合，不是運行完以後生成的一份分數表。 分數表是對這組任務的執行結果進行彙總。
二、任務的不同部分怎樣評分h2
有了記錄與終態，還需要把“做得好”變成具體判斷。Grader 就是負責檢查某個方面的評分邏輯：它可以檢查一條記錄，也可以依據明確標準評價一份回答。
4. Grader：程序、模型與人工各自判斷什麼h3
三類 Grader 的區別，主要在於怎樣作出判斷，而不只是返回布爾值還是分數。
Code-based：檢查可以明確驗證的條件
退款金額、訂單 ID、成功記錄數量，都可以由程序檢查。例如，讀取測試環境，驗證目標訂單存在且只有一筆成功退款，金額為 5000 分，其他訂單沒有變化。這裏金額採用最小貨幣單位，是示例自己的約定。
程序檢查清楚、便於重複，但檢查範圍也由代碼決定。只檢查 status == succeeded，就可能放過退錯金額或退錯訂單。確定性不等於標準完整。
Model-based：按明確標準評價開放輸出
“是否解釋清楚退款結果”“有沒有作出工具結果不支持的承諾”，很難用幾個關鍵詞可靠判斷。可以把實際證據與回答交給另一個模型，按 Rubric 逐項評價。
在本例中，一份簡短標準可以是：
- 答覆中的訂單、金額和退款狀態是否與證據一致。
- 是否區分提交、處理和完成，而不是把它們混為一談。
- 用户能否看懂當前結果，以及是否仍需要補充信息。
評價模型的判斷也會波動。應當用人工已經判過的樣本核對它：哪些情況容易誤判，標準是否含糊，缺少證據時是否允許返回“無法判斷”。不能因為評審者也是模型，就把它當成自動正確的裁判。
Human：校準標準與處理複雜判斷
人工適合確定質量標準、核對模型評分，以及審閲有爭議的結果。比如一句“退款完成”在模擬系統裏可能對應成功記錄，但真實產品應當怎樣向用户表達到賬狀態，需要結合產品語義確定。
人工也不是沒有分歧。兩位評審者對同一條回答判斷不同，可能需要補充標準，而不是簡單挑一位作為正確答案。
這三類方法可以配合：金額和狀態交給程序，表達質量交給模型，標準制定和抽查交給人工。關鍵是每項判斷都能説清它檢查了什麼證據。
5. Scoring：硬性條件、部分得分與組合h3
一項任務可以有多個 Grader，組合規則決定什麼算整體通過。常見方式有三種：
| 方式 | 怎樣組合 | 在退款例子中的用法 |
|---|---|---|
| Binary | 必須滿足全部指定條件 | 訂單、金額、退款筆數和操作範圍都正確才通過 |
| Weighted | 各維度加權，按總分或閾值判斷 | 對説明是否清楚、信息是否完整分別評分 |
| Hybrid | 必須條件先過關，再評價其他維度 | 退款正確是前提，再比較溝通質量與執行代價 |
退款任務更適合把關鍵狀態設為硬性條件。不能用“語氣很好”的高分抵消“退錯錢”，也不能把越權操作平均進一個看起來尚可的總分。
同時，可以保留部分得分幫助理解表現。Agent 已正確定位訂單、核對政策，卻沒有完成退款，與一開始就查錯訂單的表現不同。兩者都可能整體失敗，但失敗分佈不應被一個零分完全抹平。
因此，結果可以同時包含整體是否通過、各項檢查結果、質量分數與成本指標。調用次數、耗時和 token 消耗有助於比較效率，卻不是脱離任務質量的成功證明。
過程要求也要區分兩類。核實身份、取得確認等任務要求可以檢查；“必須先調用 A 再調用 B”若只是設計者習慣，就不應該成為隱藏的唯一正確路徑。
6. Agent 類型：按任務選擇完成證據h3
同樣的評估框架可以用於不同 Agent，但完成證據不能照搬。退款任務重視業務狀態，寫代碼、做研究和操作界面則需要各自的檢查入口。
| Agent 類型 | 主要檢查什麼 | 容易遺漏的部分 |
|---|---|---|
| Coding | 補丁、相關測試與已有行為 | 新測試通過，卻破壞舊功能；修改了測試而不是修復實現 |
| Research | 答案依據、關鍵內容覆蓋與來源質量 | 有引用，卻不支持結論；資料版本不一致 |
| Computer Use | 頁面、文件或後端的實際狀態 | 到達確認頁，卻沒有真正保存或提交 |
| Conversational | 業務結果與交互質量 | 話説得合理，卻沒有執行；執行了，卻誤報結果 |
對話任務還可能需要模擬用户補充訂單號、確認操作或改變表達方式。模擬器要遵循明確的用户情境，不能把評分器期待的解法直接提示給被測 Agent。
這些差別會影響 Grader 的選擇，但不改變基本原則：先確定完成任務需要什麼證據，再安排怎樣採集和判斷。
三、同一個任務的執行穩定性怎樣衡量h2
一次通過説明這一次做成了，卻不能直接説明同樣條件下能穩定做成。模型採樣、工具選擇和多輪交互，都可能讓不同嘗試走向不同結果。
7. Multiple Trials：在可比較的起點重複運行h3
假設同一退款任務運行五次，其中三次正確，兩次沒有完成。這與只展示一次成功演示提供的信息不同：前者至少暴露了任務存在不穩定的執行結果。
重複運行必須從可比較的初始狀態開始。在本例中，每個 Trial 都應恢復“尚未退款”的測試訂單，而不是讓第二次接着第一次已退款的數據庫繼續操作。否則測到的已經不是同一項任務。
環境也不能無意間留下前一輪的結果文件、緩存或提示。各次執行記錄需要分開保存，並記錄所用模型、指令、工具、預算與評分標準的版本，才能解釋比較條件。
多個 Trial 可以幫助觀察波動，但小樣本成功率仍然只是估計。報告結果時，應當同時給出任務數、每項任務的嘗試次數和成功定義，而不是隻有一個脱離條件的百分比。
8. pass@k 與 pass^k：機會成功和持續可靠h3
這兩個指標問的不是同一件事：
- pass@k： 同一任務嘗試 k 次，至少一次成功的概率。
- pass^k： 同一任務獨立嘗試 k 次，全部成功的概率。
τ-bench 論文用 pass^k 描述多次嘗試的一致可靠性。它不是在統計一個 Trial 內的 k 個步驟，也不是要求把同一筆退款連續執行 k 次。
為了看清區別，假設某項任務每次成功概率都是 p，各次嘗試相互獨立。那麼：
至少一次成功：pass@k = 1 - (1 - p)^k每次都成功： pass^k = p^k取一個自擬例子，p = 0.8：
| 嘗試次數 k | 至少一次成功 | 每次都成功 |
|---|---|---|
| 1 | 80% | 80% |
| 3 | 99.2% | 51.2% |
| 5 | 約 99.97% | 約 32.77% |
更多嘗試讓“至少成功一次”變得容易，卻讓“每次都成功”變得更苛刻。所以高 pass@k 不能直接解釋成“每位用户都能穩定得到正確結果”。
如果任務允許生成多個候選，再用可靠驗證器挑出一個有效解，pass@k 有價值；如果面向用户的每次操作都需要可靠完成，一致性就更重要。即使候選裏有正確答案，沒有可靠的選擇辦法，也不等於產品已經找到了它。
上面的公式是單個任務、獨立且成功概率固定時的説明。實際任務的難度不同，應分別統計或估計再彙總，不能把整套評估的平均成功率直接乘方，當成整套評估的 pass^k；共享故障造成的相關失敗，也不滿足獨立假設。
四、怎樣建立和維護一套有效的 Evalh2
前面定義了任務、證據、評分與穩定性。把它們用於持續開發，還需要一組有代表性的任務，以及明確的使用方式。
9. Dataset：把實際需求寫成可檢驗的任務h3
起點可以是開發中已經手工檢查的行為、真實失敗和用户需求，不必先追求一個龐大的題庫。對於退款 Agent，只收集正常退款會遺漏另一半能力：什麼時候不應該退款，什麼時候需要進一步確認。
可以圍繞同一業務準備不同任務：
- 符合條件，用户已確認，應當完成退款。
- 訂單已退款，不能再創建一筆。
- 訂單不屬於當前用户，不能操作。
- 用户還沒決定，應該先解釋和確認。
- 工具失敗，不能把失敗答覆成成功。
每種任務都需要自己的成功標準。信息不足時正確請求補充，可以是通過；拒絕不允許的操作，也可以是通過。“成功”指符合任務要求，不總是指完成一次寫操作。
還要檢查題目與評分是否一致。如果任務只要求提交退款申請，Grader 卻要求資金已經到賬，Agent 遵循題意也可能失敗。可以準備一份已知合格的參考結果，先驗證這些標準確實允許正確解通過；參考結果用於校驗評分，不是泄露給 Agent 的答案。
10. Capability 與 Regression：能力空間和已有保障h3
兩類 Suite 的目標不同：
- Capability Eval： 測量還不能穩定處理的任務，觀察能力是否提升。
- Regression Eval： 檢查已經可靠處理的任務，防止修改後退步。
例如，普通取消訂單退款已經穩定通過，可以進入迴歸集；多訂單、多種支付方式和信息缺失組合在一起，可能仍是能力集中的挑戰任務。
能力集通過率低，不自動説明題目不好，它可能正在暴露尚未掌握的能力。迴歸集則應接近全通過，下降值得排查。但無論屬於哪類，任務都必須明確、可解，評分不能依賴隱藏要求。
當原先困難的任務逐漸變得穩定，它們可以轉為已有能力的保障。反過來，一套幾乎全通過的能力集，已經很難區分新的改進；它仍能防退步，卻需要補充真正有意義的挑戰任務，才能繼續衡量進步。
11. Eval-driven Development：把改進與迴歸連接起來h3
一次失敗報告，可以變成一條可反覆運行的任務。假設用户反饋“Agent 把退款處理中説成了退款完成”，就可以據此固定一份處理中狀態，要求答覆準確區分兩者。
接着修改指令或工具反饋，重跑這條任務，再跑已有的正常、重複申請和失敗場景。這樣檢查的不只是“這個問題修沒修”，還包括“修復有沒有影響其他行為”。
這條循環可以概括為：
記錄問題 → 明確成功標準 → 固定任務與評分 → 修改 Agent → 重跑與比較 → 保留迴歸任務
比較時，應儘量保持任務、運行條件和 Grader 一致。如果升級 Agent 的同時也修改了評分標準，需要單獨記錄，否則分數上漲可能只是考試方式變了。
維護 Eval 也包括檢查評分器本身。低分可能來自 Agent 的真實錯誤，也可能來自含糊任務、評分 bug 或誤拒合理解法。抽查執行記錄與實際狀態，是確認分數有沒有測對的重要步驟。
自動評估能夠幫助重複比較，但不能覆蓋全部真實使用。線上反饋可以補充遺漏場景，人工抽查可以校準開放質量判斷。它們提供不同證據，不需要由一個總分替代所有觀察。
我理解的一套有效 Eval，不是給 Agent 貼上“好”或“不好”的標籤，而是讓這些判斷有具體對象：在哪些任務上、依據什麼證據、按什麼標準、以多高的穩定性完成。 這些條件清楚，分數才有可解釋的意義。
幾個關鍵問題，串起任務、評分與穩定性h2
Agent 最後回答正確，為什麼任務仍可能失敗？
因為回答只是執行記錄的一部分。需要改變環境的任務還要檢查實際狀態：退款是否創建，金額是否正確，是否重複操作。回答正確可以是一項檢查結果，但不能自動代替其他完成條件。
所有工具都調用成功，是否就證明業務成功？
不是。工具成功表示它完成了自己的操作，未必符合用户目標。查錯訂單的查詢也可能成功，提交申請也不等於退款完成。評分要把工具結果放回任務條件中判斷。
為什麼不用一個模型評價整段執行，直接給總分？
可以用模型評分，但不能把可精確核對的金額、狀態和記錄數量都換成印象判斷。不同維度需要合適證據；拆開檢查還方便定位總分背後的差異，並讓人工校準模型判斷。
檢查過程，會不會限制 Agent 尋找更好的辦法？
要區分必要約束與指定解法。不得越權、必須取得確認，是任務要求；無業務依據的固定調用順序，則可能誤拒有效解。過程檢查應服務於真實要求，不是復刻設計者自己的操作。
pass@5 很高，為什麼不能直接説明五次都可靠？
因為它只要求五次中至少一次成功。五次都成功對應 pass^5，兩者衡量不同問題。還要區分離線獨立嘗試與線上重試：評估裏多試幾次，不代表業務系統可以無條件重複有副作用的操作。
能力評估通過率不高，應該降低標準嗎？
不應只為提高分數降低標準。先確認任務可解、要求明確、評分公平，再判斷是不是確實還不具備能力。能力集需要提供進步空間，迴歸集需要守住已有表現，它們的預期通過率本來就不同。
修復一個失敗場景後，只重跑這一條夠嗎？
不夠。這條任務驗證針對性修復，其他任務檢查它是否引入迴歸。只有結果、執行條件和評分方式都可比較，才容易説明改進發生在哪裏。