Agent 評測
為什麼評測比訓練更重要
沒有評測的 Agent 開發就像矇眼開飛機。評測是貫穿整個開發週期的核心基礎設施，遠不止上線前的 checklist。
沒有評測的後果
飛行盲區：修一個 Bug，製造三個新的
沒有評測體系的團隊，每次改動都是一場賭博。你修了使用者 A 回饋的問題，卻可能悄悄破壞了使用者 B、C、D 依賴的功能。更糟的是：你根本不知道自己破壞了什麼，直到下一波使用者投訴湧來。
真實場景
使用者回饋「Agent 這周明顯變差了」，團隊翻了三天 commit 記錄，試了十幾種回滾方案，最後發現是兩週前一個看起來無害的 Prompt 微調導致的。如果有評測，這個問題會在合併程式碼前就被發現。
猜測-檢查迴圈
沒有評測的除錯過程是：猜問題在哪 -> 改一下 -> 手動試幾個 Case -> 感覺好像行了 -> 上線 -> 發現又壞了。這種迴圈可以持續數週，消耗大量工程資源卻毫無信心保障。
評測的價值時間線
早期 -- 定義成功
評測的第一個價值是迫使團隊定義成功長什麼樣，測試反而是其次。當你寫不出 eval，往往說明你對任務的理解還不夠清晰。這個過程本身就能幫助產品經理更好地理解需求。
中期 -- 迴歸測試 & 變更驗證
每次改 Prompt、換模型、調參數，都能在幾分鐘內知道改動對整體效能的影響。迴歸測試防止你在優化一個維度時不小心破壞其他維度；變更驗證讓你有資料支撐每一次決策。
後期 -- 新模型快速採納
當新模型發布時（比如 Claude Opus 4.6、GPT-5），有完善評測的團隊可以幾天內完成遷移：跑一遍 eval suite，確認效能不降，直接切換。而沒有評測的團隊，需要花數週甚至數月手動驗證，錯過最佳視窗期。
評測的核心概念
理解這 7 個術語，你就掌握了整個評測體系的語言。
Task（任務）
一個測試用例。包含輸入（給 Agent 的指令）和成功標準（怎樣算完成）。
Trial（試驗）
同一個 Task 的一次執行嘗試。因為模型輸出有隨機性，同一個 Task 需要跑多次 Trial 才有統計意義。
Grader（評判器）
打分邏輯。可以是程式碼規則、LLM 評審、或人工打分。決定一次 Trial 的結果是通過還是失敗。
Transcript（記錄）
完整的執行軌跡：Agent 的每一步推理、每一次工具呼叫、每一個中間結果，全部記錄下來。
Outcome（結果）
環境中的最終狀態。不只看 Agent 說了什麼，更看它實際做了什麼：檔案是否正確修改、API 是否正確呼叫。
Harness（腳手架）
執行評測的基礎設施。負責建立沙箱環境、啟動 Agent、收集結果、呼叫 Grader 打分。
Suite（套件）
一組相關 Task 的集合。例如「檔案編輯能力 Suite」包含 20 個不同難度的檔案編輯任務。
Claude Code 的評測演進故事
從 Dogfooding 到系統化評測
起初
靠內部工程師日常使用（dogfooding）收集回饋。「感覺最近寫的程式碼品質不如上週」，這種直覺有用，但不精確、不可擴展。
第一步
加入簡潔性和檔案編輯的 eval。終於能量化「生成的程式碼是不是太囉嗦了」和「檔案編輯是不是準確」。
進階
發現使用者抱怨「過度工程化」，於是專門加了過度工程化 eval：測量 Agent 是否在簡單任務上引入了不必要的複雜度。
效果
評測幫助團隊聚焦改進方向：判斷從「感覺哪裡不對」升級為「簡潔性從 72 分提升到 85 分，但過度工程化指標從 3% 惡化到 7%，需要回退」。
關鍵建議
先從 20 條開始
不要等到有幾百條測試用例才開始做評測。20 條精心設計的 Task，就能覆蓋你最核心的場景。關鍵在於開始，數量是其次。一個有 20 條 eval 的團隊，比一個有 0 條 eval 但「計劃做 500 條」的團隊，領先了一整個時代。
評測也是產品理解的手段
寫評測用例的過程，會逼你回答最難的產品問題：「使用者到底想要什麼結果？」「什麼算好，什麼算不好？」「邊界情況怎麼處理？」很多團隊在寫 eval 的過程中，反而理清了長期模糊的產品定義。
評測的價值是複利：前期每一分鐘的投入，後期都會在迴歸測試、模型遷移、團隊協作中持續產生收益。最好的開始時間是三個月前，次好的是現在。