看到 Anthropic 這篇 Demystifying evals for AI agents，覺得寫得蠻扎實的。這是繼他們之前 Building effective agents 之後，又一篇很實用的工程指南，這次聚焦在 Agent 的評估方法論。

做 AI Agent 的人大概都有這種經驗: 早期靠手動測試和直覺可以走很遠，但一旦上了 production 開始 scale，沒有系統化的 eval 就會陷入「修 A 壞 B」的惡性循環。用戶回報 agent 變差了，你卻沒辦法分辨是真的 regression 還是只是噪音。

以下是一些重點摘要:

Agent Eval 的基本結構

文章先定義了一組清楚的術語，這很重要因為大家講 eval 常常在講不同的事:

  • Task: 單一測試案例，有明確的輸入和成功標準
  • Trial: 對同一個 task 的一次嘗試。因為模型輸出有隨機性，通常要跑多次
  • Grader: 評分邏輯，一個 task 可以有多個 grader
  • Transcript: 完整的執行紀錄，包含所有 tool calls 和中間結果
  • Outcome: 環境中的最終狀態。Agent 說「已訂好機票」不算數，資料庫裡真的有訂位紀錄才算

這邊很關鍵的區分是 transcript vs outcome — agent 說它做完了不代表真的做完了，eval 要驗的是環境的實際狀態。

三種 Grader

  1. Code-based: 字串比對、單元測試、靜態分析。快、便宜、可重現，但對有效變體很脆弱
  2. Model-based: 用 LLM 當 judge，用 rubric 評分。靈活但不確定性高，需要跟人類校準
  3. Human: 金標準，但貴又慢

實務上通常是混搭使用。Coding agent 適合用確定性測試，conversational agent 則更依賴 LLM judge。

不同類型 Agent 的評估策略

🔹 Coding Agent: 最直觀，跑測試就知道對不對。SWE-bench Verified 和 Terminal-Bench 是兩個代表性的 benchmark。一年內 LLM 在 SWE-bench 上從 40% 進步到 >80%

🔹 Conversational Agent: 比較有挑戰，因為「互動品質」本身就是要評估的東西。通常需要第二個 LLM 來模擬用戶，然後多維度評分: ticket 有沒有解決、幾輪對話完成、語氣是否恰當

🔹 Research Agent: 最主觀。什麼叫「全面」「有根據」取決於上下文。需要 groundedness check、coverage check、source quality check 等多種方式組合

🔹 Computer Use Agent: 要在真實或沙盒環境中跑，然後檢查環境狀態。有趣的是 DOM-based 和 screenshot-based 的取捨 — 前者快但 token 多，後者慢但省 token

處理非確定性: pass@k vs pass^k

這段我覺得特別實用。Agent 每次跑結果都不一樣，那怎麼解讀評估結果?

  • pass@k: k 次嘗試中至少成功一次的機率。k 越大分數越高
  • pass^k: k 次嘗試全部成功的機率。k 越大分數越低

k=1 時兩者相同，但 k=10 時故事完全不同。用哪個取決於產品需求: 如果一次成功就夠（像 coding），看 pass@k；如果要求每次都穩定（像客服），看 pass^k。

從零開始建 Eval 的路線圖

這部分很務實:

  1. 不要等: 20-50 個從真實失敗案例抽出來的 task 就夠開始了
  2. 從手動測試轉化: 你每次發版前都在手動測的那些東西，就是最好的 eval 起點
  3. 寫明確的 task: 兩個領域專家獨立判斷應該得出一樣的 pass/fail 結論。0% pass rate 通常是 task 寫壞了，不是 agent 不行
  4. 正反都測: 只測「該搜尋時有沒有搜」會導致 agent 什麼都搜。Claude.ai 的 web search 團隊在這上面花了很多迭代
  5. 環境要隔離: 每次 trial 從乾淨環境開始。他們內部發現 Claude 會偷看 git history 來「作弊」
  6. 評結果不評過程: 不要檢查 agent 有沒有按特定順序呼叫 tool，agent 常常找到你沒想到的有效路徑
  7. 讀 transcript: 這是最重要但最容易被忽略的。分數不上去的時候，要去看是 agent 真的做錯還是 grader 有問題

文章提了一個很有說服力的案例: Opus 4.5 在 CORE-Bench 上原本只拿 42%，但研究員仔細檢查後發現是 grading 太嚴格（期望 “96.124991…” 但 agent 回 “96.12”）、task 規格模糊等問題。修完之後分數跳到 95%。

Eval 不是唯一

最後文章強調 eval 只是理解 agent 性能的方法之一，完整的圖景還包括 production monitoring、A/B testing、user feedback、manual transcript review 等。像瑞士乳酪模型一樣，單一層面都有漏洞，多層組合才能有效捕捉問題。

以上，這篇很適合正在做 AI Agent 產品的團隊讀一遍。不管你是剛開始還是已經在 production，裡面的建議都蠻實操的。特別推薦「從零開始建 Eval」那段路線圖，把很多人模模糊糊知道但沒整理好的東西講清楚了。

原文: Demystifying evals for AI agents