讓科學方法自動跑：Claude Code 學會自建評測並對自家 Agent 爬山最佳化

「改進」一個 AI agent 時有個尷尬的問題：有時候你讓評測分數變好了，agent 本身卻沒有變好。改個 prompt、換個模型、加個工具、把推理強度調高，再跑一次測試——分數上升了，可以上線嗎？也許可以，但也可能你只是教會了系統通過那一套特定測試。

2026 年 9 月 28 至 29 日，Anthropic 在 Claude Code 裡給出了一個有紀律的答案。官方 claude-api skill 新增的自動調校工作流賦予 Claude 兩項任務：第一，協助你建立評測（build-eval），而且內容要真正貼近 agent 在生產環境做的工作；第二，對著這份評測爬山最佳化（hillclimb）——反覆修改 prompt、模型與參數，同時檢查每一項「改進」在它從未見過的題目上是否依然成立。撰寫底層指南的 Anthropic 工程師 Lance Martin 在消息曝光時親自示範了整套方法，The Neuron 也於 9 月 29 日刊出深度解析。

實務核心簡單得近乎樸素：真實任務 → 可靠的評分器 → 基準線 → 一次一個改動 → 測試 → 保留或回滾。聽起來很像「做科學」，只不過現在 Claude 同時兼任實驗室助理。

為什麼這件事比聽起來難

評測（eval）本質上是針對 AI 行為的測試套件。傳統軟體測試是二元的：函式有没有回傳正確數字？Agent 卻麻煩得多——它們寫 email、調查事故、分派支援工單、瀏覽網站，還要在兩個長得完全不同的輸出都算對的情況下做判斷；同一個模型跑同一個任務，兩次結果也可能不同。

Anthropic 的工作流堅持：在最佳化任何東西之前，評測必須滿足四個條件：

1. 題目要像生產環境。 如果客戶問的是退費、帳單、帳號存取，評測就該測這些，而不是一堆方便的玩具問題。
2. 更強的模型應該得分更高。 如果昂貴的前沿模型表現輸給小模型，代表題目、評分器或環境有問題。
3. 必須有進步空間。 分數超過約 95% 時，工具本身會警告你，建議改去最佳化成本或延遲。
4. 分數必須穩定。 如果同一套系統在不同次執行間於 65% 到 90% 之間擺盪，你量到的是雜訊，不是產品品質。

最後一點在你讓 AI 去最佳化 AI 之後尤其關鍵。如果你的尺每次測量都會變長變短，自動化迴圈會非常樂於把時間花在「精通移動那把尺」上。

最陰險的陷阱：拿模型的坑來當基準

Anthropic 特別點名一個每個團隊遲早會踩到的失敗模式：把 agent 跑 1,000 次，挑出 50 個最難看的失敗案例做成基準。聽起來很聰明——直到你想起現代模型有「鋸齒狀的能力表面」，在某個任務上出奇地強，卻在幾乎一樣的任務上出奇地爛。純從單一模型的失敗裡選出來的基準，量到的是那個模型的怪癖。下一個模型一來，你精心策劃的基準就變成博物館展品。

/claude-api build-eval 指令試著把無聊的部分自動化、同時守住安全。它會訪談你正在評什麼，按照清楚的證據優先順序組題目——原生產對話紀錄最優先，其次是 bug 回報與支援工單，再來是五到十個手寫範例，最後才是從程式碼庫生成的合成案例——並產生一個本地頁面，讓人類在任何東西被計分之前先審核輸入。評分器也受到同等檢視：封閉式任務用程式化評分（精確比對、JSON 是否合法、測試是否通過），開放式任務用 LLM 評審搭配由具體可檢核主張構成的評分細則——而且 Anthropic 明確建議，絕不讓受測模型自己當自己的評審。Claude 甚至會對同一份輸出跑兩次評分器，偵測判決會不會翻盤，之後才值得信任。

帶著保留集爬山

評測過關後，/claude-api hillclimb 讓 Claude 開始改系統。你決定它可以動哪些面：系統 prompt、skill、工具描述、模型選擇、推理強度、其他 API 參數，乃至於包住模型的 agent harness。你也宣告你在乎什麼——最高準確率、更低成本，或用更便宜的模型達到相近表現。

接著是整個機制的核心：Claude 把評測隨機切成訓練集與保留測試集。 它可以檢視訓練例的失敗；但在決定改什麼時，它看不到保留集的答案。每一輪都遵循同一個迴圈——檢視訓練失敗 → 找根因 → 提出一個補丁 → 重跑評測 → 比較訓練與測試 → 保留或回滾。一輪只改一件事，因果才歸因得清楚。訓練分數上升但保留集持平？標記為過擬合並回滾。而在一切開始之前，工作流會先量測評測的雜訊下限，確認它小於你真正在乎的最小改善幅度；若不是，它會要求增加樣本，而不是假裝看得見不存在的訊號。

當連續兩三輪沒有進展，Claude 會停止亂戳，把剩餘失敗按根因分組，然後問：問題出在 agent、指示、評分器，還是基準本身？

真正有說服力的數字

值得抄下來的是客服示範。一份 44 張工單的內部基準：30 張供爬山搜尋，14 張保留、從不讓最佳化器看見。起始配置——高強度推理的重型模型，加上一堆儀式性 prompt——拿到 74.4% 準確率，每張工單 4.6 美分。Claude 先審掉強制工具呼叫儀式、草稿步驟與互相矛盾的規則；接著試 Opus 5.5 低強度（87.8%、約 1.9 美分），再降到 Sonnet 5 低強度（88.9%、約 1 美分），最後改善路由 prompt 並加上退費上限交叉檢查。

重點不是它最終在訓練工單上達到的 98.9%——那些題目 Claude 讀過。重點是保留的 14 張：原始配置 78.6%，最終配置 90.5%，成本約只剩五分之一。在沒見過的工作上更準，還便宜 80%。

第二個例子可能更有啟發性。對 Anthropic 自家的 claude-api skill 從約 66% 開始爬山，Claude 找出八個缺失的 API 功能（74%），修掉 C# 與 Java 型別表中的錯誤（77%），並在進度停滯後發現 Claude 總愛寫出預訓練記憶裡的舊 API 模式——加一張新舊模式對照表，分數升到 80%。接著是轉折：某些頑固的「失敗」其實是爛評測。一個評分器期待任務根本沒要求的錯誤鏈；另一個與 Anthropic 自己的文件矛盾，實測 API 後證明文件才是對的。把基準連同 skill 一起修好，最終來到約 88%。有時錯的是 agent，有時錯的是指示，有時錯的是考卷——認真的工作流必須能發現這三種錯。

必須尊重的限制

自動爬山並沒有解決最難的問題：Claude 只能最佳化你給它的目標。獎勵錯的行為，你就會更快地變得更擅長錯的行為。而當生產環境的 agent 依賴即時 Slack 訊息、不斷變動的記憶或外部網站時，離線的保留集仍可能無法代表現實——在生產環境長期運行 agent 的團隊回報的正是這種摩擦。Anthropic 的工作流消除了一類自欺，但沒有讓度量憑空變得客觀。

不過方向很明確。Agent 開發正從 prompt 工藝——更清楚的指示、更多範例、更好的模型——轉向把度量當基礎設施：改系統、評真實任務、量化不確定性、測未見案例、自動回滾回歸。Anthropic 自己的 changelog 顯示工具正在快速迭代，hillclimb 已經會跳過小到評測量不出來的 prompt 改寫。當你的 AI 編碼工具能用「我什麼都沒改，而這是正確決定」結束一輪調校——而且是認真的——評測就不再只是研究配件，而是產品的一部分。