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

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

這篇文章資訊量蠻大，小編幫大家整理重點。

為什麼要做 Eval?

文章一開頭就點出: agent 的多輪互動、工具呼叫、狀態變更和動態適應，讓它本質上比單次 prompt 更難評估。但反過來說，沒有 eval 的團隊就只能被動地等用戶 (或是自己) 回報「最近 agent 好像變笨了」，然後手忙腳亂地救火。

文章列了幾個有 eval 帶來的具體好處:

  • 提前發現問題: 不用等 production 出包，CI 階段就能抓到 regression
  • 逼團隊講清楚什麼叫成功: 寫 eval 的過程本身會強迫產品和工程對齊「這個 agent 該做到什麼程度」
  • 加速模型升級: 有 eval 的團隊在新模型發布幾天內就能評估要不要升級，沒 eval 的團隊往往要花好幾週
  • 建立基準: 順便追蹤延遲、token 用量、成本、錯誤率等指標

文章還舉了幾個內外部案例:

  • Claude Code 早期靠員工 dogfood 反饋迭代，後來才加入 eval 來測試簡潔性、檔案編輯、過度工程等具體行為
  • Descript 從人工評分演進到 LLM 評分器，現在跑兩套獨立的 eval suite
  • Bolt 在三個月內從零建出 eval 系統，混用靜態分析、瀏覽器代理測試和 LLM 評判

小編覺得這個「days vs weeks」的差別很現實。新模型一出來，沒 eval 的團隊只能憑感覺說「好像比較好/比較差」，有 eval 的團隊直接跑數據做決策，速度差不只一個量級。

Agent Eval 的基本結構

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

  • Task (任務): 單一測試案例，有明確的輸入和成功標準
  • Trial (試驗): 對同一個 task 的一次嘗試。因為模型輸出有隨機性，通常要跑多次
  • Grader (評分器): 評分邏輯，一個 task 可以有多個 grader
  • Transcript (記錄): 完整的執行紀錄，包含所有輸出、tool calls 和推理過程
  • Outcome (結果): 環境中的最終狀態。Agent 說「已訂好機票」不算數，資料庫裡真的有訂位紀錄才算
  • Eval Framework: 跑 eval 的基礎設施
  • Agent Framework: 讓模型能以 agent 形式運作的系統
  • Eval Suite: 為了測量某個特定能力而設計的一組 tasks

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

三種 Grader: 各有取捨

  1. Code-based (程式碼型)

    方法包含字串比對、二元測試、靜態分析、結果驗證、tool call 檢查。 優點: 快、便宜、客觀、可重現、好除錯。 缺點: 對有效變體很脆弱 (例如 agent 用了不同但合理的措辭就被判錯)，無法捕捉細微度，主觀任務有限。

  2. Model-based (模型型，LLM-as-judge)

    方法包含 rubric 評分、自然語言斷言、成對比較、多評判共識。 優點: 靈活、可擴展、能處理開放式任務和自由格式輸出。 缺點: 非確定性、成本高，需要持續跟人類校準。

  3. Human (人工)

    方法包含專家審查、眾包判斷、抽樣檢查、評分者一致性檢驗。 優點: 金標準品質，最符合專家判斷，常用來校準前兩種。 缺點: 貴又慢，通常需要領域專家。

實務上幾乎都是混搭使用。Coding agent 適合用確定性測試，conversational agent 則更依賴 LLM judge，而所有類型都需要偶爾的人工抽查來確保 grader 本身沒有偏掉。

Capability vs Regression: 兩種 eval 解的問題不同

這個區分小編覺得蠻重要但很多人忽略:

  • Capability eval (能力評估) 問的是「agent 能做什麼好?」目標是難題，所以一開始通過率本來就應該很低，這套 eval 是用來推動模型和 agent 變得更強。
  • Regression eval (回歸評估) 問的是「agent 還能搞定以前能搞定的任務嗎?」應該維持接近 100% 通過率，目的是防止改一個地方壞另一個地方。

兩套東西的成功標準完全不一樣。把它們混在一起看，會讓你誤判 agent 的真實狀況。

不同類型 Agent 的評估策略

🔹 Coding Agent: 最直觀，跑測試就知道對不對。確定性 grader 天然適合 — 程式碼的對錯通常可機器判斷。代表性 benchmark 是 SWE-bench Verified (GitHub 真實 issue 對測試套件) 和 Terminal-Bench (端到端技術任務，從編譯 kernel 到訓練 ML model 都有)。一年內 LLM 在 SWE-bench 上從 40% 進步到 >80%。

文章還給了一個 task 配置的範例骨架，task 上會掛多個 grader 一起評: 確定性測試、LLM rubric、靜態分析、狀態檢查、tool call 檢查，外加 n_turns、n_toolcalls、n_total_tokens 這類 metric 一起追蹤。一個 task 不是只有「過/不過」，而是多維度同時觀察。

🔹 Conversational Agent: 比較有挑戰，因為「互動品質」本身就是要評估的東西。通常需要第二個 LLM 來模擬用戶，然後多維度評分: ticket 有沒有解決、幾輪對話完成、語氣是否恰當、有沒有按規則先驗證身份再處理退款。代表性 benchmark 是 τ-Bench 和 τ2-Bench，模擬零售客服、訂機票等多輪互動場景。

🔹 Research Agent: 最主觀。什麼叫「全面」「有根據」取決於上下文，而且 reference 內容會變動，再加上長篇開放式輸出本身就比較容易出錯。需要多種 grader 組合: groundedness check (claim 是否有來源支持)、coverage check (預先定義哪些關鍵事實一定要提到)、source quality check (來源是否權威，不是隨便抓 SEO 排前面的就用)，再用 LLM 驗一致性和完整性。代表 benchmark 是 BrowseComp — 在開放網路上找「針尖」級別的稀有資訊。

🔹 Computer Use Agent: 透過螢幕截圖、滑鼠鍵盤跟軟體互動。要在真實或沙盒環境中跑，然後檢查 URL、頁面狀態、後端狀態。重點是驗結果 — 訂單真的下了嗎，不是看到「訂單已送出」的畫面就算數。代表 benchmark 是 WebArena (瀏覽器任務) 和 OSWorld (整個作業系統，含檔案系統、應用設定、資料庫狀態)。實作上有趣的取捨是 DOM-based 和 screenshot-based — 前者快但 token 多，後者省 token 但慢。

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

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

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

k=1 時兩者相同，但 k=10 時故事完全不同 — pass@10 可能逼近 100% (機會多)，pass^10 可能逼近 0% (要求嚴)。用哪個取決於產品需求: 如果一次成功就夠 (像 coding agent，可以人工 review)，看 pass@k；如果要求每次都穩定 (像直接面對客戶的客服 agent)，看 pass^k。

從零開始建 Eval: 8 個步驟

這部分文章寫得很務實，小編幫大家整理成 8 步:

0. 不要等。 20-50 個從真實失敗案例抽出來的 task 就夠開始了。早期每個改動的影響都很大，小樣本就能看出趨勢。越晚開始越難回頭補。

1. 從手動測試轉化。 你每次發版前在手動驗的那些東西，就是最好的 eval 起點。bug tracker 和 support queue 裡的真實故障，優先收進來。

2. 寫明確的 task，附 reference solution。 兩個領域專家獨立判斷應該得出一樣的 pass/fail 結論。連你自己都過不了的 task 要再修。任務規格的模糊性會直接變成 eval 的雜訊。0% pass rate 通常是 task 寫壞了，不是 agent 不行，這是文章特別點出的 red flag。reference solution 還能驗證 grader 設定是不是正確。

3. 正反都測。 只測「該搜尋時有沒有搜」會導致 agent 什麼都搜。Claude.ai 的 web search 團隊就在這上面花了很多迭代 — 像「Apple 是誰創辦的?」這種模型本身就知道的問題不該觸發搜尋，但「現在天氣如何」就該搜。要避免類別不平衡的 eval。

4. 環境要隔離。 每次 trial 從乾淨環境開始。共享狀態會造成假優勢或關聯故障 (殘留檔案、cache、資源耗盡)。Anthropic 內部就發現過 Claude 會偷看 git history 來「作弊」。基礎設施的脆弱不該被算到 agent 頭上。

5. Grader 要精心設計。 優先用確定性 grader，必要時才上 LLM grader，人工 grader 用來驗證。LLM grader 一定要跟人工專家校準，給它「不確定」選項避免硬猜，rubric 要按維度拆開分別評分。

6. 讀 transcript。 這是最重要但最容易被忽略的。投資 transcript 檢視工具，定期讀完整的 trial 紀錄。分數不上去的時候要問: 是 agent 真的做錯，還是 grader 拒絕了有效解法? eval 有沒有測到真正重要的東西?

7. 監控 eval saturation。 當 agent 通過所有可解任務，eval 就失去信號了。SWE-bench Verified 一年從 30% 跳到 >80%，已經接近飽和，剩下的進步在分數上看起來都會很小。文章提到 Qodo 的案例: 他們一開始對 Opus 4.5 印象普通，因為單次 coding eval 沒抓到長任務上的躍進，後來開發了新的 agentic eval framework，圖才變清楚。所以不要看到表面分數就下定論，要去翻 transcript 確認: 評分是否公平? task 是否模糊? 有效解是否被罰? framework 是否限制了模型?

8. 長期維護。 文章提到 Anthropic 內部觀察到最有效的組織模式是: 專職 eval 團隊負責核心基礎設施，領域專家和產品團隊貢獻大部分 task。維護 eval 應該像維護單元測試一樣是日常工作。理想狀態是「eval-driven development」: 在能力還沒到的時候就先把成功標準和 eval 寫好，然後對著它迭代；對當前模型「快但不夠好」的功能可以押注未來模型 — 等新模型發布再跑一遍 suite，馬上知道哪些押注贏了。

Grader 設計的常見陷阱

文章特別點出幾個 grader 容易踩的坑:

  • 過度剛性 (over-rigid): 檢查 agent 有沒有按特定順序呼叫 tool 太嚴格了。agent 常找到你沒想到的有效路徑，評分要評結果而不是過程。
  • 沒有 partial credit: 客服 agent 正確驗證了身份、確認了問題，但沒有處理退款 — 這跟一開始就誤判完全不同，要能反映出來。
  • 校準不足: LLM grader 不跟人工校準的話會慢慢漂移，給出看似合理但實際不準的分數。
  • 可被繞過 (gaming): eval 不應該能被輕易「騙過去」，過關必須是真正解決了問題，不是滿足了表面條件。

兩個有意思的案例

CORE-Bench: 42% → 95%

文章提了一個很有說服力的案例。Opus 4.5 在 CORE-Bench 上原本只拿 42%，但研究員仔細翻 transcript 後發現:

  • grading 太嚴格 (期望 “96.124991…” 但 agent 回 “96.12” 就被判錯)
  • task 規格本身就模糊
  • 一些其他校準問題

修完之後分數直接跳到 95%。這個故事的教訓不是「Opus 很強」而是「不要把 eval 分數當絕對真理，先去讀 transcript 確認 agent 跟 grader 誰才是出問題的那個」。

Qodo: 看似平平，背後其實是 eval 跟不上

Qodo 一開始評估 Opus 4.5 時感覺「沒什麼特別」，但深入挖才發現是他們的單次 coding eval 已經飽和，捕捉不到模型在長任務和 agentic 場景上的進步。後來他們開發了新的 agentic eval framework，曲線才變清楚。這個案例搭配上面 saturation 那段一起看，蠻有警示意味的: eval 跟模型一樣會過時。

Eval 不是萬能: 多層驗證像瑞士乳酪

文章最後強調 eval 只是理解 agent 性能的方法之一。每種方法都有自己的盲點，要組合使用:

  • 自動 eval: 快、可重現、能在 CI 跑、規模可大；但需前期投入，可能給虛假信心
  • 生產監控: 真實規模、抓得到合成 eval 漏掉的東西；但是反應式的，問題會先到用戶那邊
  • A/B 測試: 直接量真實業務指標 (留存、完成率)；但慢 (要幾週才有統計顯著)，只能測已部署的東西
  • 用戶回饋: 浮現意外問題、貼近產品目標；但稀疏、有自選擇偏誤、用戶很少解釋「為什麼」
  • 人工讀 transcript: 建立失敗模式直覺、抓細微品質問題；但耗時、無法擴展、有審閱疲勞
  • 系統性人工研究: 主觀判斷的金標準、能處理模糊任務；但慢又貴

時序上的建議: 上線前和 CI/CD 用自動 eval 當第一道防線，上線後加上生產監控偵測分布漂移，流量夠了用 A/B 測試驗證重大改動，並持續用用戶回饋、transcript 抽查、人工研究來校準 LLM grader。

像瑞士乳酪模型一樣，單一層都有洞，多層疊起來才能有效擋住問題。

工具生態 (附錄一瞥)

文章附錄列了幾個 eval 工具，這邊小編快速帶過:

  • Harbor: 容器化的 agent eval 環境，雲規模試驗基礎設施
  • Braintrust: 離線 eval + 生產觀察 + 實驗追蹤一條龍，附 Autoevals 預建 grader 函式庫
  • LangSmith: 跟 LangChain 緊密整合，含追蹤、離線/線上 eval、資料集管理
  • Langfuse: 自架的開源替代，適合資料駐留要求嚴格的場景
  • Arize / Phoenix: LLM 追蹤、除錯、評估，開源 Phoenix 平台搭配 AX SaaS

文章特別提醒: 不要花太多力氣在工具選擇上，挑一個能配合你工作流的，把精力放在 eval task 和 grader 的品質迭代上才是重點。

寫在最後

通篇看下來，小編覺得最重要的幾個觀念是:

  1. Eval 是「主動 vs 被動」的分水嶺: 沒有 eval 的團隊只能等問題發生，有 eval 的團隊可以主動發現問題並加速迭代
  2. 真實失敗 → 測試案例: 不要從零想像 task，從你已經踩過的坑開始最有效
  3. 讀 transcript 不能跳: 這是區分 eval 真實有用還是只是好看數字的關鍵動作
  4. 混搭多種 grader 和多種驗證方法: 沒有單一方法能抓到所有問題

這篇很適合正在做 AI Agent 產品的團隊讀一遍。不管你是剛開始還是已經在 production，從基本術語、grader 設計、不同 agent 類型策略、到從零路線圖和工具生態，都覆蓋到了。

最後文章也誠實地說: AI agent eval 還是個快速演進的早期領域，隨著任務變長、多 agent 協作出現、主觀工作增加，evaluation 技術也得跟著演化。換句話說，這篇是現在的 best practice 整理，但別把它當聖經 — 自己的 eval 也要持續迭代。

原文: Demystifying evals for AI agents