你的 Agent 真的變好了還是「感覺」變好了
最後更新於
好的 Agent 評估能把「這個版本的 Agent 好像變差了」這種模糊感受，變成團隊真正可以行動的數字。 Anthropic 工程團隊寫了一篇相當扎實的 《Demystifying evals for AI agents》，把他們在 Claude Code 等產品上踩過的坑沉澱成了方法論。 在這篇貼文中分享一下自己讀完後感觸頗深的幾個點。
為什麼 Agent 評估比想像中難
單輪 LLM 評估很乾淨：輸入 prompt、輸出回答、評分器打分。 Agent 把這種簡單性徹底打破。它會在多輪裡使用工具、修改環境狀態、根據中間結果調整策略， 錯誤會傳播，副作用會疊加。即使過程看起來很醜，最終結果也可能是對的，反之亦然。
以 Memex 自己的知識庫 Agent 為例。當你記錄一段內容時，Agent 會呼叫 LS、Grep、Read、Edit、Write 這類工具，加上更高層的「更新洞察」「跳過組織」等動作，在多個回合裡反覆操作檔案系統。 其中一些結果可以客觀驗證（檔案寫對了嗎？關聯還在嗎？）， 另一些則只能主觀判斷（這個洞察值得嗎？拆得粒度對不對？）。
為什麼 Agent 評估這麼難
以 Memex 知識庫 Agent 為例
fact_id 是否關聯？結構是否符合 P.A.R.A.？
分類是否合理？
拆分粒度對不對？
Agent 通常配備多樣工具，需要在當前環境根據指令多輪呼叫，修改狀態並根據變化調整策略， 最終產出既包含可客觀驗證的部分，也包含只能主觀評價的部分。
評估框架的核心術語
Anthropic 在文章裡給出了一組精確的術語，理解了它們後續討論會順暢很多：
- 任務（Task）：一組明確輸入和成功標準的測試樣例。
- 試驗（Trial）：對一個任務的單次嘗試。因為輸出不穩定，所以要跑多次。
- 評分器（Grader）：為產出某個維度打分的邏輯，一個任務可以有多個。
- 運行記錄（Transcript）：一次試驗的完整記錄，包含推理與工具呼叫。
- 最終結果（Outcome）：試驗結束時環境的最終狀態。
- 評估框架（Eval harness）：驅動整個過程的執行器，編排試驗、記錄步驟、彙總結果。
- 評估場景（Eval suite）：一組圍繞同一能力或行為的任務集合。
Anthropic 的評估框架
harness、suite、task、grader、metric、trial 的層級關係
評估框架提供 Agent 運行環境，定義 Agent，定義評估場景，平行執行任務，追蹤每一步， 對輸出進行評分，最後彙總結果。
三類 Agent 評分器
實際工作裡，Agent 評估通常會同時用上三種評分器，對不同維度選擇最合適的工具。
基於程式碼的評分器
透過字串比對、相似度計算、工具呼叫驗證、單元測試通過/不通過等方式給結果打分， 評分器本身就是確定性的程式碼：快速、便宜、可重現、易於除錯。 缺點是對正確結果的變體不友善，對主觀維度也無能為力，所以只用在能機械驗證的產出上。
基於模型的評分器（LLM-as-judge）
讓一個 LLM 充當評委，按自然語言寫的評分標準打分。引入參考解或多位評委可以提升置信度。 代價是：你正在用一個不確定的評估器去對一個不確定的 Agent 打分， 所以基於模型的評分器必須和人工評分反覆校準才靠得住。
基於人工的評分器
透過領域專家評審、群眾打分、A/B 測試、評分員一致性來評估結果，慢但權威。 它的主要工作是校準基於模型的評分器，以及解決主觀維度上的爭議。
如何評估 Agent？
Agent 評估通常結合三種類型的評分方式
非確定性：pass@k 與 pass^k
Agent 行為在多次運行間會發生波動，今天通過的任務明天可能就失敗了。 原文給出了兩個互補的指標來刻畫這種不確定性。
pass@k：k 次裡至少成功一次
pass@k 是在 k 次嘗試裡至少成功一次的機率。 隨著 k 增大，這個值上升：嘗試越多，「至少有一次成功」就越容易。 通常我們希望 pass@1 越接近 100% 越好，因為終端使用者很少重試。
pass^k：k 次全部成功
pass^k 是 k 次嘗試裡全部成功的機率。 隨著 k 增大，這個值下降：要求越多次都不出錯，標準就越苛刻。 面向終端使用者、必須「次次都成」的 Agent 格外關心這條曲線。
Agent 評估中的非確定性如何捕捉
Anthropic 給出了兩種互補的指標
嘗試多少次能至少成功一次。我們希望 pass@1 接近 100%， 即首次嘗試就完成的比例越高越好。
連續 k 次能否全部成功。能容忍的 k 越大， 代表 Agent 在生產環境裡越穩定。
在 k=1 時兩條曲線相同（都等於單次成功率）。 到 k=10 時它們講的故事完全相反：pass@k 趨近 100%，pass^k 趨近 0%。 到底用哪條，要看你真正需要滿足的使用者期望。
從零做 Agent 評估的建議
原文最後給出了一份操作手冊，下面是我們最常翻看的精華部分。
Anthropic 給出的評估建議
為什麼 / 什麼時候 / 如何做
有效的評估讓團隊更有信心地發布 Agent。 無論是改了 prompt、換了運行時還是升級了模型，評估都能回答那個核心問題：「Agent 真的變好了嗎？」
在 Agent 開發的任何階段做評估都有用。 早期能促使你明確成功標準，後期能維持一致的品質。開始得越早，建立成本越低。
靈活組合多種評分器，並明確分數如何合成：加權？必須全過？還是混合？
早期定義 20–50 個簡單任務，從真實失敗案例中收集，少量樣本就能帶來巨大收益（80/20 法則）。
任務要明確到兩位領域專家會得出相同結論。0% pass@100 通常說明任務有問題，而不是 Agent 不行。
同時涵蓋應該和不應該兩類情況，避免單邊最佳化。
評估環境要相互隔離，避免共享狀態、剩餘檔案、資源耗盡等帶來的關聯失敗。
把評估集當作活的成品，定期閱讀 transcripts， 將穩定下來的能力任務「畢業」到回歸任務集，發現異常時回頭審視評分器。
把任務集開放給領域專家和產品團隊，他們離使用者最近，最了解需求邊界。
原文還提到了 Harbor、Braintrust、LangSmith、Arize、Langfuse 等評估框架。 等我們在 Memex 的 Agent harness 中用得更多以後，再來分享實際體驗。
Agent 評估對 Memex 來說意味著什麼
Memex 在你手機上跑著一整套多 Agent 系統：Card Agent、PKM Agent、Comment Agent、Insight Agent， 再加上你自己寫的自訂 Agent。每個 Agent 都自治、會呼叫工具、會修改你的知識庫狀態。 Anthropic 這套術語正好對應了我們思考品質時的方式： 為每類記錄定義任務，混合用客觀與主觀的評分器， 再用 pass^k 這種「次次都成」的指標來約束使用者每天看到的體驗。
評估其實是團隊和自己關於「更好」的對話。 這場對話開始得越早，Agent 就越不像「吃角子老虎」，越像一個每個版本都在變靠譜的隊友。
想看完整原文，請閱讀 Anthropic 工程部落格。如果對 Memex 的實作感興趣，原始碼已開源，在手機上執行 AI Agent 真正需要什麼一文也涵蓋了 Agent 架構的更多細節。
FAQ：AI Agent 評估常見問題
什麼是 AI Agent 評估？
Agent 評估是給 AI Agent 的程式化測試：給它一個輸入任務，讓它在自己的工具集裡跑完，再用評分器去看它的運行記錄和最終狀態是否達標。和單輪 LLM 測試不一樣，Agent 評估必須能處理多步工具呼叫、狀態變化和部分得分。
pass@k 和 pass^k 有什麼區別？
pass@k 是 k 次嘗試裡至少成功一次的機率，k 越大值越大；pass^k 是 k 次嘗試全部成功的機率，k 越大值越小。pass@1 通常用來衡量首次成功率；pass^k 則用來衡量 Agent 是否每次都靠得住，決定終端使用者體驗。
程式碼、模型、人工三類評分器應該用哪一種？
三種都用，按維度配。能用程式碼確定性驗證的，用程式碼評分器；開放式輸出和語氣這類，用模型評分器（LLM-as-judge）；用來校準模型評分器、解決主觀爭議的，用人工評分器。Anthropic 的建議是混合搭配，而不是只挑一種。
搭一個 Agent 評估集需要多少個任務？
從真實失敗案例裡挑 20 到 50 個就夠開始了。Anthropic 反覆強調 80/20 法則：少量精挑的任務在迭代早期能帶來最大收益。後面隨著 Agent 成熟再擴，把穩定的任務「畢業」到回歸任務集。
為什麼 pass@100 = 0% 通常說明任務有問題，而不是模型不行？
如果一個前沿模型 100 次都做不出來，最大機率是任務定義模糊、評分器太嚴，或者執行環境攔掉了正確解法。Anthropic 建議先去複核任務規格和評分器，再考慮模型本身的能力問題。