Quartz 5

Agent 評估

Properties1
tagsai, llm, agent, evaluation, testing, reliability

9 min read

對應原題（Common ‧ Evaluation and Observability）

  • How would you evaluate an agent, as opposed to a single model response?
    — Asked at: Moonshot AI, Zhipu AI, Scale AI, Cognition

🎯 什麼情境該想到我

當你「要證明一個 agent 可以上線，但它每次跑的路徑都不一樣」的時候。

⚙️ 怎麼用

★ 五個根本差異（先講這個）

#差異後果
1產出是一條軌跡 + 對世界的副作用，不是一段文字不能只評估最後那句話
2步數不定成本與延遲是隨機變數，不是常數——必須看分布
3★ 多條路徑都可能對不能用「和參考軌跡比對」評分，那會懲罰合理的替代解法
4★ 錯誤會複合單步 95% 正確，20 步後只剩
5有副作用評估環境必須沙箱化、可重置

★ 第 4 點是面試最值得講的一句：
「agent 的難題不是單步能力，是可靠度的複利衰減。」
這也解釋了為什麼「模型更強了但 agent 還是不能用」——單步從 95% 提到 97%，20 步的成功率從 36% 跳到 54%，差距巨大。

四個評估層次

層次評估什麼怎麼做
① ★ 結果（outcome）任務到底完成了沒可程式驗證的終端狀態檢查——檔案存在？測試通過？資料庫欄位對了？
★ 這是主指標，而且一定要客觀可驗證（見 GRPO 與 RLVR）
② 軌跡（trajectory）路徑品質步數、是否繞路、是否重複相同動作、工具選擇正確率
③ 步驟（step-level）每一步的決策是否合理裁判或人工（貴，用於診斷不用於 gate）
④ 成本token、延遲、金額★ 看分布不看平均

★ 核心指標

指標定義為什麼重要
任務成功率終端驗證通過的比例主指標
pass@kk 次嘗試中至少一次成功衡量「能力上限」
★ pass^kk 次嘗試全部成功★ 衡量可靠度。
產品上線看的是這個——一個 pass@5 = 90% 但 pass^5 = 20% 的 agent，使用者體感是「很不穩」
步數分布p50 / p95長尾才是痛點
成本分布p50 / p95 / max★ p95 成本決定你敢不敢開放給所有人用
人類介入率需要求助或被接管的比例真實的自動化程度
★ 危險動作嘗試率嘗試執行 L3 動作的次數（見 可逆性、審計與人類把關）即使被擋下來了，「嘗試」本身就是風險訊號
護欄觸發率—趨勢變化代表行為飄移

★ pass@k vs pass^k 的區分是這題的高分點。
研究論文愛報 pass@k（好看），產品需要的是 pass^k。

★ 評估環境：agent 評估最貴的部分

單一回應的評估只需要一個資料集；agent 評估需要一個「可重置的世界」。

要件說明
可重置每次評估從同樣的初始狀態開始——資料庫快照、檔案系統快照、容器映像
確定性時間、隨機數、外部資料都要可控
★ 工具要能錄放（record/replay）或 mock否則外部 API 的變動會讓兩次評估不可比，你會不知道是 agent 變差還是對方改了 API
終端驗證器客觀判定任務是否完成的程式
包含髒資料與失敗★ 評估環境不能太乾淨——要刻意注入逾時、429、格式怪異的回傳，測錯誤處理（見 ReAct 與 Agent Loop）

這套環境的建置成本常常比 agent 本身還高，但沒有它就無法做回歸測試。
面試時能講出「我會先投資評估環境」比講一堆指標更有說服力。

★ 分層診斷：任務失敗了，錯在哪一步

任務失敗
 ├─ 規劃錯      → 一開始的拆解就不對
 ├─ 工具選錯    → 工具描述不清（見 [[工具集設計]]）
 ├─ 參數給錯    → schema 不好用 / 沒有 enum
 ├─ 觀察誤讀    → 工具回傳的格式讓模型誤解
 ├─ 偏題（drift）→ 見 [[多 Agent 編排與 Agent Drift]]
 ├─ 預算用盡    → 步數/時間/token 上限
 └─ 環境問題    → 外部服務掛了（★ 要能和 agent 的錯分開統計）

這個分類要能從 trace 自動標記，否則每次失敗都要人工看。
分類的分布會直接告訴你該修哪裡——「60% 的失敗是工具選錯」和「60% 的失敗是預算用盡」，完全不同的修法。

常見陷阱

陷阱說明
★ 只看成功率不看成本一個跑 200 步、花 $4 才完成的 agent「成功」了，但完全不能上線
用固定參考軌跡比對懲罰了合理的替代路徑。應該驗證終端狀態，不是路徑
環境太乾淨真實世界的逾時、髒資料、權限錯誤沒被測到
★ 不測「該停不停」agent 在該放棄或該求助時硬做下去
★ 不測破壞性任務完成了，但它順手刪了別的東西。 終端驗證要同時檢查「該做的做了」和「不該動的沒動」
只跑一次步數與成本是隨機變數，單次結果沒有意義。每個任務至少跑 3–5 次

⚠️ 注意 / 什麼時候不適用

  • ★ agent 評估的方差很大。同一個任務跑 5 次可能 3 成 2 敗。任何結論都要基於多次重複，否則你在讀雜訊。
  • 評估成本很高。每個任務 × 每次重複 × 幾十步 = 大量 token。要用抽樣 + 分層，不可能每次 PR 都跑全量。
  • 公開的 agent benchmark 污染更嚴重（任務與解法都在網路上）。見 Benchmark 污染與分數失真。
  • 步驟級裁判很貴也不太準。用來診斷可以，用來當 gate 不行。
  • 沙箱與生產有落差。沙箱通過不代表生產可行——要有金絲雀階段。
  • 不要拿 agent 評估取代單元測試。工具本身的正確性用一般測試驗，別讓 agent 評估去抓工具的 bug。
  • 終端驗證器有 bug 時，你的所有數字都是假的。驗證器本身要被測試（見 GRPO 與 RLVR 的同一個警告）。

🧪 我實際套用的紀錄

  • 2026-09-20：從面試題庫展開。待辦：把 agent 的評估從 pass@k 改成同時報 pass^k 與成本 p95。

🔗 相關

Graph View

Backlinks