評估工程 (Eval Engineering)：將 200 美元的模型轉化為 20 萬美元系統的關鍵步驟（完整建構指南）

大家現在租用的都是同一個大腦。

每個月花幾百美元能用的模型，跟一家擁有一千名工程師的公司運行的模型，基本上是一樣的。這本來應該能拉平一切。但結果卻是，讓兩個租用同一個大腦的團隊之間的差距，比兩個模型之間的差距還要大。

一個旅遊 Agent（軟體版）回答了關於一趟旅程的問題：匯率精確到小數點後一位、未來一週的氣溫、博物館的開放時間。聽起來很具體、很乾淨、很有用。但這些全都是捏造的。

搜尋工具沒有找到任何結果，而模型默默地填補了這個空缺，並把自己捏造的資訊當作查證過的事實交了出來。

然後，這個團隊在 100 次真實會話中進行了測量，得到了兩個絕不該相差這麼遠的數字。

答案的品質：83.9%。

這些答案有多少是基於工具實際回傳的內容：32.3%。

這個 Agent 寫得一手好文章，但只有三分之一的時間在說實話。

沒有人發現這一點，因為大家只看了文章內容。

83.9% 的回應品質對比 32.3% 的忠實度，同一輪測試的結果

同一個 Agent，同一天：左邊的長條是演示給你看的，右邊的長條是客戶實際得到的。

換一個更好的模型也無法解決這個問題。缺少的，是那個能判斷答案是否正確，然後根據判斷結果採取行動的層級。

這個層級，就是從一個「令人驚豔的 AI」到一個「能賺錢的 AI」之間的全部距離。它是整個系統中最便宜的一環，也是唯一沒有人能賣給你的東西，因為它包含了你自己對「正確」的定義。

這篇文章不是讓你快速瀏覽的。請在旁邊打開一個終端機。這個設定從一條你已經擁有的指令開始，最終會導向一個聽起來不太可能的结果：合併那些沒有人審閱過的 Pull Request。

在我們開始之前，請在 X 上追蹤我，並加入我的 Telegram 頻道，我會在那裡每天發布更多 AI 內容。兩者都是免費的。

X -

https://x.com/Argona0x Telegram -

https://t.me/+r0clI4-MMC03ZjAy

什麼是評估工程

一個在生產環境中運行 Agent 的公司，用一句話就說出了關鍵。在他們 Agent 的連續版本中，他們沒有改變模型、沒有改變提示詞、沒有加入人工干預，只改變了評估方式——然後所有面向的分數都改變了。

同樣的大腦。不同的考官。更好的產品。

他們事後自己的結論更直白：這些評估應該在第一天就加入系統，而不是第九個月。

溫度計告訴你房間很冷。恆溫器會打開暖氣。

幾乎所有使用 AI 建構東西的人，最多只擁有溫度計：一個儀表板、一種感覺、某個星期五下午有人瀏覽輸出結果並說「這看起來比上週還糟」。

評估工程，就是把讀數連接到爐子的那條線路。

← 溫度計對比恆溫器，判決結果會回饋到圖表中

全部的差異就在右邊那個回饋箭頭：判決結果回到圖表中，並改變接下來執行的內容。

這一切的出現是有順序的。首先，是一個 Agent 在迴圈中運行，這樣它才能嘗試、查看結果、再嘗試。然後，是多個 Agent 以圖表的形式佈局，這樣彼此不相依賴的工作可以並行處理，而不是排隊等待。

先是迴圈，然後是圖表，最後才是評估。

https://x.com/Argona0x/status/2080626046903157126

圖表是讓你變得更快的最後一次升級。而評判者則決定這個速度是否值得擁有。

二十個 Agent 同時運行，全部向一個固定的評判者報告，這意味著錯誤答案看起來像是完成的機會增加了二十倍。

這也是系統中唯一一個每週運行都會變得更有價值的部分。模型是租來的。考官是你自己的，你餵給它的每一次失敗都會永久留存。

這使得入門的價格顯得很奇怪。安裝考官的費用幾乎為零，而它所考評的模型每月大約花費 200 美元。

第一步 · 你已經擁有的評估引擎

你大概會認為這需要一個平台：一份合約、按人頭計價、在上線前需要花一季的時間設定。

正是這個想法，讓大多數人根本沒有建立這個層級，而這個想法大約在四週前就不再成立了。

盲測

1. 兩位研究人員進行了誠實的測試。他們從一個真實的語音 Agent 中提取了 100 條真實的生產記錄，由人類專家手動標記每一個失敗，建立了一個包含 39 個已標記失敗的分類法，然後隱藏了標籤，並將同一批資料交給市場上所有的評估系統。

你自己去找出來。

有趣的結果不是誰贏了：

1. Braintrust Loop: 找回了 87.2% 的人類標記的失敗。
2. Codex on GPT-5.5 High: 召回率 84.6%，精確率 82.8%。
3. LangSmith: 79.5%。
4. Arize AX: 召回率 74.4%，以及該組中最高的精確率 91.0%。

一個你已經付費訂閱的通用編碼 Agent，其表現超越了兩個專門的評估平台。其中一個平台坦率地寫下了結論：你可以透過使用你的編碼 Agent 獲得類似的結果。

然後，這些平台做了一件比輸掉更奇怪的事。它們開始整合。

在四週內，四個評估供應商將它們的專業知識作為一個安裝到別人編碼 Agent 中的技能推出：LangChain 在 7 月 22 日，Galileo，AWS 基於 Apache 2.0 許可證，以及 Arize 將其追蹤提取功能放入技能中，目標是，用他們的話說，你最喜歡的編碼 Agent。

沒有人將這四件事視為一個整體的動作。

這是一個品類正在自我解構，並融入你已經打開的終端機中。

安裝考官

安裝所有東西只需要三行指令。

1npx skills add langchain-ai/langchain-skills --skill '*' --yes --global
2npx skills add langchain-ai/langsmith-skills --skill '*' --yes --global
3uv tool install evalkit --from git+https://github.com/awslabs/Agent-EvalKit.git

在 Claude Code 中，同樣的東西可以作為外掛程式安裝：

1/plugin marketplace add langchain-ai/langchain-skills
2/plugin install langchain-skills@langchain-skills

← 真實的終端機運行：安裝技能，evalkit init 建立評估資料夾

在真實機器上的真實運行：技能作為全域檔案安裝，而 evalkit init 則佈局了你的評估將要使用的資料夾。

其中有兩個細節比指令本身更有價值。

1. 兩個倉庫，兩個工作：langchain-skills 建立評估，langsmith-skills 提取真實的生產運行記錄來建立評估。幾乎所有人都只安裝了第一個，然後想知道測試資料從哪裡來。
2. 這不是 Claude Code 專屬的功能：這些技能遵循開放的技能規範，因此相同的檔案可以載入到 Codex、Cursor、Windsurf 和 Goose 中。

AWS 工具包由六個指令組成，每個階段都會寫入一個 eval/ 資料夾，供下一個階段讀取：

1evalkit init my-agent-evaluation
2# 然後，在你的編碼 Agent 中：
3/evalkit.plan Evaluate my agent at ./my_agent for grounding and tool accuracy
4/evalkit.data
5/evalkit.trace
6/evalkit.run_agent
7/evalkit.eval
8/evalkit.report

最後一個指令是整個設定中最有價值的。/evalkit.report 會回傳優先順序排序的建議，並指向你程式碼中的特定位置。

考官已經安裝好了。現在，我們必須讓它能夠實際做些事情。

第二步 · 讓分數改變下一個邊緣

你會建立你的第一個評估，得到一個數字，看著它，然後感覺什麼事都沒發生。

這種感覺是對的。報告中的一個數字，沒有路徑可以回到它測量的那個運行。

有一行程式碼可以解決整個問題，而它出自一位東京的 21 歲創始人，只有 258 個追蹤者，他關於這個問題的貼文只得到了兩個讚：

一個從不改變行為的分數，只是分析。一個能改變下一個邊緣的評估，才是工程。

他的線路是六條規則。每一條都會接收一個判決，並對正在進行的運行做出結構性的改變：

1low context recall   → reject the handoff
2bad tool use         → retry or swap the node
3hallucination        → quarantine the branch
4schema failure       → block the edge
5compliance risk      → route to human review
6verified completion  → terminate the run

← 六個判決，六個對正在進行中的運行所做的結構性動作

這六個判決中的每一個，都是圖表會執行的路由決策。評估在運行過程中引導著 Agent，一次一個邊緣。

給評判者本身的規則

考官本身也需要有自己的衛生規範，而幾乎沒有人能正確設定這部分。

1. 從另一個模型家族找評判者：一個模型能認出自己的寫作風格，並因此給出更寬容的分數。某個評估團隊故意使用 Sonnet 作為評判者，來評估 Haiku 產生的輸出。X 上的一句話用更少的字說明了原因：同一個模型家族負責生成和評分，所以盲點是共享的。
2. 將評分標準寫成一行：可行的形式就是 Pass iff [獨立可觀察的成功結果]。一個主要的判決，而不是一組代理分數的組合。
3. 按類型劃分工作：評判者負責語義判斷，純程式碼負責客觀判斷。例如：測試是否通過、檔案是否存在、狀態是否改變。
4. 絕不獎勵答案的形式：寫入技能中的規則禁止根據回應長度、關鍵字、引用次數、確切措辭、工具呼叫次數或與參考答案的相似度來進行評分。獎勵形式，Agent 就會學會形式。
5. 鎖定評判者版本並記錄其版本：一個默默升級的考官，會讓升級前後的所有分數無法比較，而且你可能一個月後才會發現。版本鎖定是人們經常跳過的一步，卻會讓一個月的分數在事後變得無法解讀。

長時間針對一個評判者進行最佳化，Agent 會學會看起來正確，而不是真正正確。

現在，分數有了去處。下一個問題是，好的測試從哪裡來？因為坐在辦公桌前憑空發明測試，正是為什麼每個人的第一組測試都毫無用處的原因。

第三步 · 將一次失敗的運行轉變為一個評估

你憑空想像出來的測試，只能保護你免於你已經想像到的失敗。

而那些真正會讓你花錢的測試，此刻正帶著時間戳記，躺在你的日誌裡。

整個循環只有五個步驟：

1挖掘追蹤記錄 -> 識別失敗 -> 建立評估 -> 改進 Agent -> 重新運行

測試從哪裡來

第一步承擔了所有的重量。專業執行此步驟的技能會指定要提取哪些運行記錄，它從 25 條完整的追蹤記錄開始，不需要更多，選擇的方式是讓好的和壞的行為並列：

1. 一個完成的一般請求：這是你的基準，代表「運作正常」的樣子。
2. 一個使用者確認過的請求：這是罕見的追蹤記錄，你知道答案是正确的。
3. 一個被使用者修正或重新表述的請求：修正本身就是標籤，而且是免費的。
4. 一個包含失敗、空值或重複工具呼叫的運行：重複表示迴圈，空值表示即將出現捏造的答案。
5. 一個包含外部失敗的運行：例如超時或速率限制，這時唯一能測試的就是你的 Agent 在被世界拒絕時的行為。

每個請求都用四行文字記錄下來，而這個模板是最值得偷學的部分：

1觀察到的行為：使用者問了什麼，Agent 實際做了什麼
2比較：          什麼有效，什麼無效
3歸因：          Agent 行為、依賴項行為、或不明確
4評估候選項目：   應保留或改進的能力

歸因是新手容易浪費一週時間的地方。

同一個查詢用相同的參數呼叫了兩次，這是 Agent 中的一個迴圈。收到一個 429 錯誤，是其他人的限制，這只有在你的 Agent 本該從中恢復時，才成為你的評估項目。

從發現到資料夾

然後，這個發現變成一個資料夾，而這個資料夾是工具可以運行的格式：

1evals/<task-id>/
2├── task.toml
3├── instruction.md
4├── environment/
5└── tests/

← 25 條追蹤記錄 → 一個失敗 → 一個 Harbor 任務資料夾：Agent 能看到什麼，什麼是隱藏的

每個資料夾對應一個能力。instruction 和 environment 對被測試的 Agent 是可見的。預期結果、評分標準和評判者的憑證則是不可見的，而這種分離是分數具有任何意義的唯一原因。

三條規則可以防止讓人放棄的失敗：

1. 絕不將記錄下來的答案視為真理：追蹤記錄告訴你你的 Agent 做了什麼，絕不是它應該做什麼。從測試、來源記錄、政策、已知狀態或真人那裡取得答案。
2. 在信任測試之前先測試測試：手動交給驗證器兩個偽造的結果，一個明顯正確，一個看似合理但錯誤。如果任何一個結果判斷錯誤，那是評分標準有問題，而不是 Agent 有問題。
3. 注意環境是否洩漏了答案：如果設定在 Agent 到達它應該使用的工具之前就交出了結果，那麼這個任務就會永遠通過，什麼也測量不到。

任何會花錢或寫入生產環境的操作，都會被模擬而不是實際呼叫，這樣測試套件就可以隨你喜歡的頻率運行，而不會產生帳單。

有一條指令可以啟動這一切，就在你已經打開的 Agent 中：

1Use the eval-engineering skill.
2
3Map this repository's agent: entrypoint, tools, backing data, and what a good
4result looks like. Then read the 25 traces in ./traces and propose two or three
5eval candidates grounded in what actually failed there.
6
7Recommend one. Do not implement until I choose.
8Build it as a Harbor task under evals/, keep the rubric and expected outcome
9hidden from the target, and test the verifier on one passing and one plausible
10wrong result before the real run.

這個提問的步驟是刻意的。撰寫此技能的團隊發現，提問使用者的效果每次都勝過一次性生成，原因很簡單：對「正確」的定義存在於你的腦中，而不是模型中。

執行這個過程幾次之後，每一次失敗都不再是一個事件，而會變成一個永久性的測試。

第四步 · 讓圖表自己合併自己的工作

Agent 開啟的每一個 Pull Request 都會落在同一個地方：一個人工審核佇列。

你成為了自己自動化流程的瓶頸，而你建立的整個 Agent 艦隊，運行速度取決於一個疲憊的審查者。

解決方法看起來完全不像「更信任模型」。當 Agent 開啟一個 Pull Request 時，已經有四個訊號可用，並且可以即時從中計算出一個信心分數：

1. Guardrails 結果：對阻擋標準進行確定性的通過或失敗判定。不涉及模型。
2. 近期評估軌跡：這個 Agent 的這個確切版本最近的分數趨勢如何。
3. 歷史回滾率：這個 Agent 在這個倉庫中，針對這類變更，過去多常需要回滾其工作。
4. 沙箱結果：是否成功運行。

高於門檻值，就自己合併。低於門檻值，則交給人類處理，並附上失敗的訊號名稱，這樣審查就可以從問題開始，而不是從第一行程式碼開始。

← 四個訊號 → 一個信心分數 → 自己合併，或轉給人類處理

這四個訊號中有三個是歷史記錄和確定性檢查，而只有一個會觸及模型。

對 Agent 的信任，是一種精算計算。

你正在建立的，是一個帶有價格標籤的追蹤記錄，就像保險公司建立的那樣，而且無論模型是否改進，它每週都會變得更加精確。

運作起來是什麼樣子

在同一家除了評估之外什麼都沒改變的公司，完全自主的 Agent 所提交的 Pull Request 中，每 20 個就有 19 個是在沒有人類參與的情況下合併的。

在頂尖的 Agent 中，大約四分之三合併的工作是沒有任何人工編輯的，回滾率保持在低個位數百分比，而僅 Guardrails 就在人類看到之前，擋掉了五分之一的 Pull Request。

某個在自己倉庫上運行這種模式的人，用一種供應商絕對不會用的方式說明了這一點：

在過去 90 天裡，我批准並合併了大約 1,500 個 Pull Request。我沒有看過任何一行程式碼。我怎麼能如此信任 Agent？我一點也不信任它們。我也不信任自己有能力進行程式碼審查。但我確實信任自己有能力限制它們的工作。

這個限制本身就是產品。

而一個比這個公式更有價值的警告，來自一個團隊，他們對一個自我改進的程式碼庫運行了 285 次迭代，最終合併了 1,094 個 Pull Request，且沒有出現任何回歸。

他們自己的總結值得牢記：38 個綠色測試與一個完全壞掉的產品同時存在。

一個測試套件可以在它所保護的產品崩潰的同時，仍然全部顯示為綠色。這就是為什麼這個循環必須收斂於規格，而不是分數。

以謹慎的方式開啟它：

1. 先以影子模式運行：閘門會對每個 Pull Request 進行評分，但不會合併任何一個，至少運行 4 小時的真實流量。
2. 設定一個 2% 的偏差閾值：如果自動判決和人工判決的不一致超過 2%，閘門就保持關閉。
3. 以 1% 到 5% 的比例抽樣追蹤記錄：對所有內容進行完整擷取，是一個你不需要承擔的成本。

一個兩人團隊，所有 Agent 寫的變更都需要等待一個審查者，那麼他們能承擔的工作量大約就等於這個審查者能閱讀的量。

透過關閉高風險部分的閘門，並對單調的 80% 部分保持開放，同樣的兩個人開始可以報價那些他們以前必須拒絕的合約。

模型帳單不會改變。其他一切都會改變。

第五步 · 本週應該建立的評估

一個太慢或太模糊的測試套件永遠不會被執行，所以這部分是值得保存下來的。

從三個測量指標開始，而不是十二個。那三個能揭露旅遊 Agent 問題的指標，是任何會呼叫工具的 Agent 的實用預設值：

1. 忠實度：答案是否基於工具實際回傳的內容。這就是那個在儀表板上所有其他數字都看起來很正常時，卻只有 32.3% 的指標。
2. 工具參數準確度：正確的工具，正確的參數。
3. 回應品質：輸出內容對提問者來說是否連貫且有用。

如果你的 Agent 會輸出程式碼，請改為對變更進行評分。這是每個 Pull Request 在生產環境中使用的五個維度：意圖與決策、執行與產出、完整性與有用性、指令與邊界、效率。

有目的地選擇資料集類型。有四種：final_response 僅針對答案本身，single_step 針對單一決策，trajectory 針對 Agent 的完整路徑，RAG 針對檢索品質。

只評分最終回應，會讓 Agent 透過一個有缺陷的序列達到正確答案，而沒有人會注意到。

設定大小，使其能持續運行。保留 300 到 800 個案例，並讓其中 500 個案例的運行時間保持在 5 分鐘以內。

一個需要比喝杯咖啡更長時間的測試套件，最終會停止被執行。

前五個評估，按順序：

1. 空工具結果：工具沒有回傳任何東西，Agent 必須如實報告，而不是捏造數字。
2. 重複呼叫：用相同的參數進行相同的查詢兩次。這是一個迴圈，評估會判定為失敗。
3. 邊界拒絕：被要求執行權限範圍外的操作時，Agent 能夠乾淨地拒絕，而不是尋找繞過的方法。
4. 交接完整性：前一個節點產生的內容，就是下一個節點讀取的內容，中間沒有任何捏造。
5. 驗證完成：完成意味著一個真實的訊號說完成了，而不是 Agent 自己的說法。

← 本週工作：三個測量指標，一個資料集類型，五個評估（儲存卡）

三個測量指標，一個資料集類型，五個評估。這是一個下午的工作量，而之後的每一週，這個測試套件的價值都會比前一週更高。

先行者

模型從來都不是有趣的部分。它是租來的，對所有人都一樣，而且今年內就會被替換兩次。

能夠在每次替換中存活下來的，是你圍繞它所建立的考官：你轉化為永久測試的失敗、讓判決能夠改變下一個邊緣的規則、讓機器能夠自己合併工作的追蹤記錄。

這才是決定你信用卡帳單上那 $200 美元，最終是產生一個展示品，還是產生一個業務的關鍵。

大多數人會回到星期五瀏覽輸出結果，然後憑感覺認為「好像差不多」。

先行者會花一個下午接好恆溫器的線路，然後在接下來的一年裡，擁有一個不會在同一個地方犯錯兩次的 Agent。

三行字概括了整個學科：

1. 測量 Agent 走過的路徑，絕不只是它最終給出的答案。
2. 一個不改變下一個邊緣的判決，只是一份報告。
3. 任何你沒有轉化為永久測試的失敗，你都將再次遇到。

安裝一個技能。提取 25 條追蹤記錄。今天建立一個評估，然後每當有東西出錯時，就增加一個。

如果你想隨時掌握 AI 領域的最新動態，請在 X 和 Telegram 上追蹤我：

X -

https://x.com/Argona0x Telegram -

https://t.me/+r0clI4-MMC03ZjAy