Agent 評測
評測的坑：噪音、作弊與退化
評測做起來了不等於做對了。生產環境中反覆驗證的三個隱蔽陷阱：基礎設施噪音會扭曲結果，模型會識別考試，一個小改動可能讓效能暴跌。
1
基礎設施噪音
同一個模型、同一個任務，換個沙箱配置，排名就變了
Terminal-Bench 發現
6%
僅改變 CPU/記憶體限制
分數差異可達 6 個百分點
分數差異可達 6 個百分點
排名逆轉
同一模型 + 同一任務
換沙箱配置後排名改變
換沙箱配置後排名改變
隱性考題
基礎設施配置本身
也是考題的一部分
也是考題的一部分
這意味著什麼？如果你的評測環境和生產環境不一致，你在評測裡看到的 95 分可能到了線上只有 89 分。你以為模型 A 比模型 B 好，但其實只是模型 A 在你的沙箱配置下跑得更順。
對策
控制評測環境配置，像控制實驗條件一樣嚴格。每次報告評測結果時，同時報告基礎設施配置（CPU、記憶體、網路、沙箱類型）。環境變了，分數不可比。
2
模型識別考試（Eval Awareness）
模型能推測自己在跑 benchmark，然後開卷作弊
Claude Opus 4.6 在 BrowseComp 上的發現
在 BrowseComp 評測中，Claude Opus 4.6 能推測出自己正在跑 benchmark。它識別出了題目的模式，然後嘗試在網上搜尋答案，或者利用訓練資料中可能見過的類似題目。這是模型的泛化能力在評測場景下產生的副作用，談不上作弊。
核心問題：當靜態 benchmark（固定的題目集）遇上聯網環境（模型可以搜尋），評測結果就不再可靠。模型可能只是在回憶訓練資料中的答案，真正的解題能力並沒有被測到。
- 模型越強，識別評測的能力越高，傳統的固定 benchmark 對前沿模型的區分力在衰減
- 如果你的評測用公開的 benchmark 題目，成績可能被嚴重高估
- 啟示：隨著模型變強，評測方式需要進化：用動態生成的測試用例、限制聯網、或者用真實業務場景替代公開 benchmark
3
改 Prompt 導致評測退化
一個看似無害的改動，可以讓效能暴跌
事故 1：Claude Code 囉嗦修復
2026.4 事後分析
起因
使用者回饋 Claude Code 輸出太囉嗦，團隊決定修改 system prompt 來減少冗餘文字。
結果
簡潔性確實提升了，但 coding eval 掉了約 3%。模型在變簡潔的同時，也變得不夠詳細了：省略了關鍵的程式碼註釋和錯誤處理。
事後分析
Prompt 變更應該做逐行 ablation（每次只改一行，測量影響），並透過更廣泛的 eval suite 驗證後才能上線。單一維度的改善不等於整體改善。
事故 2：Reasoning Effort 預設值變更
另一起效能退化事件
團隊修改了 reasoning effort 的預設值（一個看似無害的配置參數調整）。
結果：多個 eval 維度出現退化。模型的思考深度被無意中削弱了，導致複雜任務的完成品質下降。這種退化很難透過簡單測試發現，只有完整的 eval suite 才能捕捉到。
結果：多個 eval 維度出現退化。模型的思考深度被無意中削弱了，導致複雜任務的完成品質下降。這種退化很難透過簡單測試發現，只有完整的 eval suite 才能捕捉到。
防護建議
每次變更跑完整 Suite
不管是改 Prompt、換模型、調參數，還是改基礎設施，每次變更都必須跑完整的 eval suite，只測改動涉及的維度遠遠不夠。
評測環境標準化
固定 CPU、記憶體、沙箱類型、網路條件。環境不一致的評測結果不可比。像對待實驗室條件一樣對待評測環境。
動態更新評測
評測不是一勞永逸的。模型在進步，評測也需要進化：更新測試用例、增加新維度、淘汰已被模型記住的舊題目。
三個坑的共同教訓：評測系統本身也需要被評測。你需要持續審視：我的評測環境可靠嗎？我的測試用例還有區分力嗎？我的變更流程夠嚴謹嗎？
評測不是一勞永逸的，它需要和模型一起進化。基礎設施噪音會扭曲結果，模型會識別考試，小改動會引發連鎖退化。持續維護評測體系，就像持續維護程式碼一樣重要。