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 的過程中，反而理清了長期模糊的產品定義。
評測的價值是複利：前期每一分鐘的投入，後期都會在迴歸測試、模型遷移、團隊協作中持續產生收益。最好的開始時間是三個月前，次好的是現在。