我一直覺得 Agent 評測最危險的地方，不是分數不夠高，而是我們太快把分數當成能力的直接觀測。TRACE 這篇工作真正值得帶走的，不是某個工具名稱會讓分數掉多少，而是它把一個常被藏在附註裡的問題推到檯面上：當 Agent 的行為沒有改變，評測器改了一點點，結果還能不能代表同一件事？

這個問題在傳統模型 benchmark 裡已經夠麻煩，到了 Agent 系統更嚴重。Agent 的輸出不是單一答案，而是一條包含規劃、工具呼叫、參數、觀察、重試與最終回覆的軌跡。任何一個環節都可能被 verifier 讀錯。換句話說，最後的 reward 同時混合了三個變數：模型真的做了什麼、環境允許它怎麼做、評分器選擇看什麼。若只報一個總分，我們根本不知道下降的是哪一項。

因此，我認為「可重播軌跡」應該被視為產品能力，而不是研究報告的附錄。每次執行至少要保存工具與參數、觀察內容、狀態變更、評測器輸入，以及當時使用的版本。可重播不只是方便除錯，它讓團隊能把一次模糊的失敗，轉成可比較的實驗：固定模型與軌跡，只換 verifier；固定 verifier，只換模型；固定兩者，只換任務描述。沒有這個切分，所謂模型迭代很可能只是評測器漂移。

第二個應該產品化的是評分器版本。很多團隊會鎖定模型 checkpoint，卻讓 prompt、解析器、工具 schema 或 judge model 在背景更新。這等於把測量儀器換掉後，仍把新舊數字畫在同一張趨勢圖上。我的建議是讓每一筆分數都帶著 evaluator version、規則版本與依賴的 schema hash，並把評測器當成需要 changelog、回歸測試和發布門檻的軟體元件。

第三個是配對測試。除了在新任務上測 Agent，也要建立語意等價的任務對，刻意只改工具名稱、輸出格式、敘述順序或無關欄位，觀察行為與分數是否同步。若行為軌跡幾乎相同，分數卻大幅改變，這不是 Agent 退步，而是 verifier 對表面線索過敏。更進一步，可以把誤導性名稱、格式變體和隨機重跑放進 CI，將 evaluator brittleness 變成可量化的品質指標。

TRACE 提到的結果讓我特別警覺：重跑會得到不同結論，甚至不同 judge 對同一紀錄也可能用不同標準判斷。這表示平均分數不應該是唯一的 dashboard 指標。我會同時追蹤配對差異、重跑一致率、逐步錯誤定位率，以及人工與自動評分的一致性。對 Agent 團隊來說，真正成熟的評測不是能產生漂亮排行榜，而是能回答「這次變好，究竟是哪裡變好」以及「這個結論在換一種表達後還成立嗎」。

我的結論很簡單：可重播軌跡是可觀測性，評分器版本是可治理性，配對測試是對外推性的壓力測試。三者缺一，Agent 分數就更像儀表板上的故事，而不是可以信任的工程證據。