Agent Eval 怎麼做? 2026 兩大方法論的交鋒與共識

2025 年 9 月有過一場 AI Evals 大辯論，起因是 Claude Code 創始人 Boris 在訪談中說他們評估新模型的方式就是「拿它來做我當天的工作」，沒有複雜測試套件，靠感覺判斷。這句話點燃了整個社群的爭論。支持方有 Shreya Shankar、Hamel Husain、Eugene Yan，還有 Braintrust 的 CEO Ankur Goyal，他甚至寫文主張「未來屬於 evals 而非 A/B 測試」。反對方則有 AgentOps 的 Alex Reibman(標題直接叫《Evals are a scam》)、前 GitHub Copilot 的 Julia Neagu，以及 Raindrop 的 Ben Hylak。Hylak 當時的批評是: evals 只是「已知問題的集合」，發現不了未知問題，真正關鍵的還是生產環境測試和 A/B 測試。

八個月後，這兩邊各自交出了一份完整的方法論，而且都在 2026 年 5 月:

• Ben Hylak 的 How to evaluate AI agents: The 2026 Guide
• Braintrust 的 The six generations of AI agents and how to eval them(Ameya Bhatawdekar 與 Tony Xu)

所以這不只是兩篇剛好同期的文章，而是去年那場論戰的延續。有趣的是雙方都往中間靠了一些: Hylak 寫了一整份離線 eval 指南，承認 eval 有用，只是堅持它應該小而精;Braintrust 則把線上評分、影子執行、生產飛輪寫進體系裡，承認生產環境是評估的一部分。但底層的分歧還在。

小編下面先講 Hylak 那篇(小編自己比較認同這條路線)，再講 Braintrust 的六個世代，最後比較分歧在哪、為什麼會這樣、各自適合什麼場景。

一、howtoeval: 先做 error analysis，把下限拉高

Ben Hylak 在開頭先劃清範圍: 這份指南講的是 agent，classifier、RAG pipeline 和其他 AI 系統的評估方式不一樣。他也直接點名自己要反對什麼:「做 agent 評估生意的公司，常常在推銷越來越荒謬、過度複雜的策略。這些在賣的工具，跟真正在好公司裡奏效的做法，從沒有像現在差這麼遠。」

他反對的是工具供應商堆出來的複雜度，不是說評估本身簡單。他自己談 error analysis 時的說法是「流程很簡單，但不容易(simple, but not easy)」。

先選路線: benchmark maxxing 還是 floor raising

在想 evals 之前，要先決定你想取得哪一種進展。他說多數團隊從來沒有明確做過這個選擇:「他們從實驗室借來 eval 的語言，複製 benchmark 的形狀，最後追著一個從來不是為他們設計的目標跑。」

兩條路線是:

• Benchmark maxxing: 把分數做高、追求 99% 通過率
• Floor raising(拉高下限): 在可靠性真正重要的地方做到可靠，也就是使用者實際會走的流程、失誤代價昂貴的時刻、以及那些「一想到就讓你對出貨不安」的案例

他用金融 agent 舉例: 它能跨帳戶對照、預測支出、自動取消訂閱當然很好，但如果它偶爾答不出「我戶頭裡有多少錢」這種基本問題，你就不會再信任它。

文章裡有一張光譜圖，把常見產品排在兩端之間，判準是「人會不會審查輸出」:

他給了一個判斷自己站在哪邊的石蕊測試: 如果你可以選擇用 90% 通過率或 99% 通過率出貨，你選哪個?如果你的直覺是「當然 99%」，你還在用 benchmark 的思維;如果你的第一個問題是「掛掉的是哪 1%?」，你在做的是拉高下限。

拉高下限就是 error analysis

這是全文的方法論核心:「拉高下限看起來不像 benchmark 設計，比較像 error analysis。你不是從一份抽象的測試集開始，你在做偵探工作: 找出系統彎折的地方、把它們分類、決定哪些值得投入工程資源。」

具體做法是審查使用者訊息、agent 回應、以及 agent 走到答案的軌跡，同時盡量用 AI 擴大你能看的 trace 數量(過濾、分群、摘要)。但不管怎麼擴大規模，要問的問題始終不變:

• 最後一個成功的步驟是什麼?
• 第一個真正的失敗是什麼?
• 檢索漏掉了嗎?
• agent 忽略了 context 嗎?
• 工具呼叫出錯了嗎?
• 最終答案有沒有誇大系統實際知道的東西?

接著修的是模式，不是個案。有時候是改善檢索，有時候是約束 agent，有時候是換一個工具、加一道 guardrail，或是教系統停下來說「我不知道」。

「只有到這個時候才加 evals。而且加的時候是針對性的。你不是在測想像出來的涵蓋率，你是在把真實失敗的教訓鎖起來。一套拉高下限的 eval，是一份你拒絕讓它們重演的 bug 記憶。」

他也解釋為什麼大型 eval 集通常是干擾:「真正傷害你的，通常不是某個 prompt 的第一千種合成變體。是那次退款政策的幻覺、那個無限迴圈、那個三次工具呼叫之後不著痕跡的 context 遺失。」

教 agent 說「我不知道」

這是他認為最容易做到的拉高下限技巧之一，也是使用者最不喜歡的一個: 信心低於閾值就說不知道，查詢超出領域就說不知道，檢索到的 context 不足就說不知道。

「Benchmark maxxer 討厭這個做法，因為它會拉低通過率。但拉高下限的人知道，一個自信的錯誤答案比誠實的『我不知道』更糟。對於要取代人力的產品，信任比展示能力重要。」

出貨前: 先認識你的 agent

黃金案例: 挑 5 到 10 個代表關鍵路徑的案例寫下來就好，不需要檔案格式、不需要 harness。從最簡單的版本開始: 一個常見的、agent 應該永遠答對的使用者問題。規則很簡單，如果 agent 開始在黃金案例上失敗，就不出貨。

本地理解你的 agent: 對這些黃金案例，不要只看最終輸出，要檢視完整軌跡: 使用者訊息、工具呼叫、檢索到的 context、推理鏈。「路徑跟答案一樣重要。」

Pro tip: 直接問你的 agent。他說這個做法很少有人提到。注意，他指的不是叫另一個 agent 去讀 trace 然後猜原因，而是把那次執行照原樣重建成當初傳給 agent 的內容，加上最新的回應，直接問它發生了什麼事。

為什麼這樣做有用: 推理 trace 常常是加密的，你自己讀不到那段 chain of thought。把 trace 傳回給同一個模型，是最接近「直接問 agent 到底發生什麼事」的做法，因為它可以拿手上的 trace、context 和先前訊息當作回答的證據。這常常能讓你發現 agent 誤解了什麼、或過度執著於 prompt 裡的某一段。可以這樣問:

“You were wrong. The answer was X. What would I need to have changed for you to get this right?”

(你答錯了，正確答案是 X。我需要改變什麼，你才能答對?)

他也補了一句提醒: agent 的回答不一定是真相，把它當線索用。

離線評估: code-aware evals

「一旦 agent 跟程式碼、工具、檢索、權限和產品狀態糾纏在一起，單獨測 prompt 就沒有意義了。行為活在整個系統裡，不在 prompt 字串裡。」

所以離線評估看起來不像 prompt 評分，比較像一般的軟體測試，Vitest、pytest、jest 那種。一個好的離線評估會拿一個輸入，跑真實的 agent 路徑，然後對結果做斷言: 輸出、工具呼叫、被改動的檔案、結構化資料、或最終狀態。

describeEval('refund agent', { harness: refundAgentHarness() }, (it) => {
  it('approves refundable invoice', async ({ run }) => {
    const result = await run('Refund invoice inv_123')
    expect(result.output.status).toBe('approved')
    expect(toolCalls(result.session).map((c) => c.name))
      .toEqual(['lookupInvoice', 'createRefund'])
  })
})

他指出 Sentry 把這個叫做 harness-backed，OpenAI 在 agentic systems cookbook 裡叫 macro evals，做的是同一件事: 在有代表性的輸入上驅動真實的 agent 迴圈，評整條軌跡，包含工具呼叫、中間狀態和最終答案。「叫它什麼我不在乎，重點是你在評估 agent，不是在評估一次 LLM 呼叫。」

還有一個立場鮮明的建議: 他不建議用 hosted 的 eval dashboard 來跑 agent evals。理由不是難做，而是「報表 UI 是最好做的那部分，也是最該跟你的產品緊密耦合的部分」。他建議先自己弄一個本地的 HTML viewer 看通過與否就好，evals 甚至可以直接存成 markdown 檔，叫 coding agent 去跑。

上線後: 從生產學習

「出貨前，你在猜它可能會在哪裡出問題。出貨後，使用者會告訴你這個產品實際上哪裡令人困惑、脆弱、或規格不足。」

從原始日誌開始: 讀原始互動(使用者訊息、agent 回應、工具呼叫、以及使用者期待 A 但 agent 做了 B 的時刻)，一直讀到飽和，讀到同樣的模式一再出現為止。他引用 Hamel Husain 的話:「error analysis 是 AI 開發中最有價值的單一活動，而且始終是 ROI 最高的活動。」然後補上:「這是乏味的工作，但也是建立系統心智模型的唯一方法。跳過它，你會去自動化錯誤的指標。」

照流量規模選擇做法: 一天 10 次執行你可以全部讀完，一天 10,000 次你需要系統告訴你什麼值得注意。他的提醒是:「錯誤在於，還沒累積夠原始素材、不知道自己在找什麼之前，就先去拿高流量那套機制。」

自我診斷的誠實評價: Raindrop 有個功能是讓 agent 回報自己的問題，做法是在 agent 執行時注入一個隱藏工具，讓 agent 在覺得自己缺 context、遇到能力缺口、工具出錯或任務失敗時呼叫它來回報。難得的是他對自家功能給了保留的評價:「實務上，這沒有表面看起來那麼有用。把自我診斷當成 Stumbles 看待就好: 一堆隨機東西裡面可能撈到一兩個有趣的。要把敏感度調校到讓它變成有用的通用訊號，需要真功夫。特定的措辭會影響 agent 到底會不會回報。說到底，這是一個二元分類問題。」

修錯的四種做法

這是 Making fixes and changes 這一章的內容，也是全文最有立場的部分。

1️⃣ 有時候就是直接修: 壞掉的工具呼叫、system prompt 少了一條指令、檢索查詢回傳過時資料，修完出貨就好。關鍵是分清楚「真正的直接修復」跟「掩蓋更深問題的權宜處理」: 一個只處理症狀、沒處理成因的快修，之後會製造更奇怪的 bug。判斷標準很具體: 如果你發現自己在為特定的使用者措辭加特例處理，你多半是在治標。

2️⃣ 先重現，再修: 不簡單的問題，第一步永遠是重現。你能讓這個失敗再次發生嗎?如果不能，代表你還沒真的理解它，回去重讀 trace、再找一個例子。能重現之後，先把它加成黃金案例再開始修，這樣才保證不會退步。完整流程是: 在生產發現 → 本地重現 → 加進 evals → 修 → 確認 eval 通過 → 出貨。

3️⃣ 但把每個 bug 都加成 eval case，報酬遞減: 「這是一個陷阱: 每次找到 bug 就加進 eval 套件。六個月後你有 500 個案例，其中 400 個是生產環境從來不會發生的奇怪邊界情況。你的 CI 要跑 20 分鐘。你的團隊開始無視 eval 失敗，因為『反正每次都會紅一些』。」

他給的判斷標準是三個問題: 這是關鍵路徑嗎?它會退步嗎?它代表某一類失敗，還是真的只是一次性事件?然後「對修剪你的 eval 套件要果斷。20 個高訊號案例勝過 200 個低訊號案例。」

還有一條具體的修剪法則:「如果一個 eval case 三個月沒有失敗過，那它要嘛沒在測重要的東西，要嘛你的 agent 真的進步了。兩種情況都值得質疑它還需不需要留著。」

4️⃣ 很多改動只能在生產驗證: 換模型、換 prompt、換工具配置，唯一能知道有沒有用的方法是拿真實使用者測。他說得很清楚:「eval 套件會告訴你有沒有弄壞黃金案例。生產環境才會告訴你這個改動有沒有真的幫上忙。」文中的 A/B 例子是把 GPT-5.3 對比 Claude 4.5 Sonnet，任務完成率從 76% 提升到 88%，p < 0.001。

迴圈、時間投入、以及對未來的判斷

這就是整個迴圈: 出貨、觀察發生什麼、理解失敗、修重要的那些、把有用的教訓留成回歸測試。「每次迭代應該讓 agent 少尷尬一點，讓 eval 套件更貼近現實一點。你不是要把所有可能的測試案例前置寫完，你是在建一個能從生產學習、又不會忘記已經學到什麼的系統。」他補了一句提醒:「如果這個迴圈停了，測試集會過期，信心就變成表演。」

時間投入: 「打算把 agent 開發時間的 10 到 20% 花在評估和監控上。不只是寫 eval case，還包括讀 trace、調校訊號、調查問題。這是打造可靠 AI 系統的成本。想跳過的團隊會在生產事故上付出代價。」

對未來的判斷: harness 會塌縮。這段小編覺得是全文最值得注意的部分，因為它跟下一節 Braintrust 的方向正好相反。他認為「agent SDK 呼叫模型」這個模式已經出現裂痕: 模型越來越有能力、越來越 agentic，「模型」和「agent」之間的界線越來越模糊，Claude Code、Cursor CLI、還有正在成形的 Cursor Agent SDK 都反映了這個趨勢。

「當 agent 只是一個 prompt 加一個模型，評估會長什麼樣?當沒有框架程式碼可以插樁、沒有顯式的工具迴圈可以追蹤時?agent 周圍的鷹架(scaffolding)，塌縮進模型裡面。」

他認為這會改變監控方式:「今天我們追蹤工具呼叫，是因為我們必須。明天我們可能只記錄輸入輸出對，然後問模型它做了什麼。中間步驟變得不透明，像是問一個人他當時在想什麼: 你會得到一個答案，但驗證變難了。」推論是端到端評估會變得更重要，「如果你無法檢查內部，你就必須信任(並驗證)輸出。黃金案例和生產監控本來就是我們的建議，到那時會變成唯一的選擇。」

不管怎麼變都成立的五件事(他的收尾):

1. 你需要跟真實使用者行為接觸，合成 evals 會跟現實脫節
2. 軌跡很重要，不管是顯式的(工具呼叫)還是隱式的(推理)，agent 怎麼走到那裡都有診斷價值
3. 黃金案例有效，一小組高訊號測試勝過一大堆低訊號測試
4. 生產監控是必要的，你無法預先想到所有失效模式
5. 評估是持續的工作，不是一次性的設定

二、Braintrust: 架構每換一代，eval 就要跟著換

Braintrust 這篇的切入點完全不同: 不是從失敗出發，而是從架構出發。核心論點是 agent 架構跟著模型能力演進，每一代架構都會產生「前一代 eval 看不見的失效模式」，所以 eval 策略必須跟著架構換代。

文章開頭先定義 eval 是「對 AI 系統可重複執行的測試」，由三個部分組成: Data(有代表性的案例，含輸入、context、預期行為)、Task(受測系統本身)、Scores(定義什麼叫好的評分方式，可以是程式碼、啟發式規則、LLM judge 或人工審查)。

貫穿全文的主張是「evals 是 AI 的 TDD(測試驅動開發)」，理由是這段:「隨著模型進步，重新實作一個 AI 功能的邊際成本越來越低。沒有變便宜的，是判斷新版本有沒有比舊版本好。實作會一直換，eval 集才是耐久資產: 它是你的規格、你的回歸測試，也是你的組織記憶。」

貫穿全文的例子: Sentinel

這篇最好的地方是用同一個系統貫穿六個世代，讓每一代的差異變得具體。

Sentinel 是一個 SRE 事件回應 agent。它看顧一個由大約 40 個微服務組成的關鍵業務應用，有真正的 on-call 職責: 監控、告警、提出緩解方案，有時候直接執行。它的工具分兩類，唯讀的有 query_metrics、search_logs、read_dashboard、get_recent_deploys 等，寫入的有 rollback_deploy(回滾部署)、restart_pod、page(呼叫待命人員)、post_slack。它有破壞性的操作權限，後果是真實的，所以不是聊天機器人。

貫穿全文的事件是: UTC 時間 02:14，PagerDuty 觸發告警「checkout-service 的 5xx 錯誤率連續 5 分鐘超過 3%」，值班工程師正在睡覺。Sentinel 的任務是找出可能的根因、建議或執行一個動作，並在不確定時升級給人類。

同一個任務、同一個事件，接下來看它在六種架構下分別長什麼樣。

Gen 1: The Prompt(單一提示)

架構: 一個 prompt、一次 LLM 呼叫，沒有工具、沒有檢索、沒有記憶。這是 2022 年底 ChatGPT 之後第一波 AI 功能的形態。Sentinel 在這一代只能產出一份通用檢查清單(查部署、看 log、確認資源飽和)，但它做不到其中任何一件事，也不知道 02:11 到底發生了什麼。

失效模式幾乎全是答案品質問題，因為沒有中間步驟可以怪罪、沒有工具可以誤用: 幻覺出不存在的服務或指標、似是而非但錯誤的建議(回滾一個根本沒發生的部署)、漏掉明顯步驟、優先序排錯。

評估單位是「答案」。準備 50 到 500 筆有代表性的告警黃金資料集，每筆配上一個資深值班工程師會寫的回答。原文強調多樣性勝過數量: 涵蓋不同嚴重度、不同服務類型、不同事件原型，還要加幾筆「假警報」，正確答案是「升級，不要臆測」。評分器則搭配使用事實性 LLM-as-judge、涵蓋度 rubric、校準檢查(告警模糊時有沒有表達不確定)、安全檢查(有沒有在沒證據時建議破壞性動作)。這些接著變成 CI 門檻，其中安全必須維持 100%。

Gen 2: The Chain(固定管線)

架構: 固定的步驟管線，仍然是線性的，但可以在執行期檢索。這是重要的轉折，因為很多任務都依賴當下的 context: 最新的那次部署、今天的 log、特定那筆客戶記錄。Sentinel 在這一代會先 parse_alert 解析告警，再依序抓部署、儀表板、log，最後交給 LLM 產生報告。關鍵是每一步都寫死了，模型不能決定要拉寬部署的回看時間或換一個 log 查詢。

失效模式是一整類 prompt eval 抓不到的 bug，因為模型不再是唯一可能出錯的東西:

• 檢索漏掉相關證據: 觸發事件的那次部署發生在 75 分鐘前，但管線只回看 60 分鐘。模型收到的資料看起來乾淨、其實漏掉了真正的原因，然後產出一份自信而錯誤的報告
• 早期錯誤級聯: parse_alert 抓錯服務名稱，後面每一個呼叫都在查錯的東西，Sentinel 最後對著錯誤的系統寫出一份流暢的分析
• 端到端分數藏住問題在哪: 只告訴你它失敗了，沒告訴你為什麼

評估策略是加上分階段評分來定位失敗: parse 階段測 schema 與欄位準確度、檢索階段測 recall 與 precision、推理階段測 context 忠實度(有沒有只用檢索到的事實)。資料集每一列除了輸入還要帶「正確的中間狀態」。

分階段的分數讓你能分類每一個失敗，這是這代最實用的部分: parse 就失敗 → 修 parser;parse 過了但檢索失敗 → 拉寬回看時間或修索引;檢索過了但推理失敗 → 改推理 prompt;全部都過但答案還是錯 → 你的黃金標註可能標錯了。原文說，這一代 eval 從「一個分數」變成「一份對應你管線結構的分數清單」。

Gen 3: The ReAct Loop(推理行動迴圈)

架構: LLM 變成工具迴圈裡的控制器，Thought(思考)、Action(行動)、Observation(觀察)反覆進行，直到模型自己決定完成。一旦任務需要多個工具、多個步驟，固定管線就變成束縛，真實的調查是互動的。ReAct 把模型從文字產生器變成流程的控制者，這是「agent」開始有現在這個意思的起點。

Sentinel 在這一代的執行過程大致是: 先想「確認是不是跟某次部署有關」，呼叫 get_recent_deploys 拿到「deploy-checkout-7842 在尖峰前 8 分鐘上線」;再想「建議回滾前需要執行期的證據」，呼叫 search_logs 看到「來自 payments-api 的 UpstreamConnectionError」;然後判斷證據夠了，停止呼叫工具並給出結論。

失效模式從「答案錯了」轉移到「行為錯了」: 工具選錯(該查部署卻去查 log)、參數錯(搜錯服務或時間窗)、無限迴圈或過早停止、早期誤讀感染後面每一個決定、成本爆增(5 次工具呼叫變成 25 次)、以及不安全的動作(凌晨三點為了錯的理由叫醒某個人，或回滾錯的那次部署)。原文這段講得很清楚: 兩次執行可能產出同樣的報告，但走的是天差地遠的兩條軌跡，而其中一條可能既不安全也付不起。

評估單位從 output 變成 trace。要評工具選擇準確度(5xx 尖峰的正確第一步是看儀表板或查部署，不會是回滾)、參數品質(schema 合法性、語意正確性、安全約束)、軌跡相似度(完全比對太嚴格，改成評有沒有包含必要的呼叫、有沒有避開禁用的呼叫)、終止品質、以及破壞性動作前有沒有滿足前置條件。

另外，預算變成一等公民指標。原文的說法是「正確還不夠」: 一個花掉 40 次工具呼叫的完美答案是成本問題。原文說這是第一個 eval 真的長得像行為測試的世代，比起傳統 ML 指標，更接近 fuzzing 和合約測試。

Gen 4: The Workflow Graph(工作流程圖)

架構: 把控制流程顯式化，編成一張 DAG 或狀態機，由執行期決定下一個跑哪個節點。動機很務實: 早期的 ReAct agent 太不可靠，2023 年那時的模型會跑掉格式、幻覺工具參數、無限迴圈。所以團隊做了工程師面對不可靠元件時一貫會做的事: 把關鍵控制權從它手上收回來。

state["incident"]   = classify_incident(state["alert"])      # LLM，有邊界
state["evidence"]   = gather_evidence(state["incident"])     # 確定性工具
state["hypotheses"] = rank_hypotheses(state["evidence"])     # LLM，有邊界

if state["incident"]["severity"] == "SEV1" and state["hypotheses"][0]["confidence"] < 0.7:
    state["action"] = {"type": "page_oncall"}   # 嚴重且沒把握就叫人
else:
    state["action"] = {"type": "recommend"}

失效模式是用彈性換確定性的代價: 分布外的事件掉出這張圖(第三方 DNS 造成的 SEV1 不符合「分類→蒐證→假設→行動」的形狀)、特例堆積(半年後 30 幾個節點，沒人記得哪些分支還走得到)、Gen 3 的問題跑進節點裡、以及新的「圖設計」失效(guard 閾值設錯、節點輸出 schema 漂移、兩條分支對嚴重度的定義不一致)。

評估策略非常像軟體測試，分四層: 節點層評估等於單元測試(分類節點測準確度、檢索節點測 recall、決策節點測政策合規);合約評估等於整合測試，在節點之間寫型別斷言，原文特別指出這類檢查很便宜，而且在模型行為還沒介入之前就攔下一大類回歸;分支涵蓋率要求把黃金集按分支切分，像程式碼涵蓋率一樣追蹤;端到端評估但按分支分開報告，這樣才看得到某條路徑的品質掉了，即使全域平均持平。

Gen 5: The Modern Agent Loop Returns(迴圈回歸)

架構: 回到迴圈，因為模型變得夠好了。當前沿模型經過工具使用和長程推理的後訓練之後，workflow 的「彈性稅」開始壓過它的好處: 圖在有邊界的問題空間很好用，但在長尾很脆弱、演進成本很高。程式碼幾乎跟 Gen 3 一樣，差別是執行期多了工具呼叫上限這類護欄。原文的說法是「迴圈沒有變，變的是模型」。

失效模式是 Gen 4 當初想壓制的那些又回來了，而且是在更強的模型、更長的軌跡之下: 非決定性(同一事件的兩次執行走不同但都合理的路徑，會讓「預期軌跡」評分器狂噴誤報)、成本爆增、eval 變脆弱(假設只有一個正確答案的資料集根本是錯的)、失敗變得罕見而奇怪(早期一個誤分類在 15 步後複合成大錯)、變異數變成關鍵指標。原文的結論是點估計會騙人，eval 必須承認 agent 是一個「合理行為的分佈」。

評估策略轉向多次試驗與分佈。每個案例跑 N 次，追蹤 pass@k(k 次裡至少成功一次，量的是能力)和 pass^k(k 次全部成功，量的是一致性)，加上工具呼叫數、成本、延遲的中位數與 p95。這兩個指標回答的是不同的產品問題: pass@k 告訴你「這個功能做不做得到」，pass^k 告訴你「這個功能能不能出貨」。原文指出對面向客戶的 agent，pass^k 通常更重要:「使用者體驗到的不是你的平均表現，而是眼前的那一次執行。」

另外三個重點: Span-level 評分把軌跡裡的每一步拆開獨立評分，不再只看最終答案。即使最終答案正確，中間某一步的品質也可以單獨判定，因為一個正確答案完全可能是經由一條有問題的路徑得到的。比較式評估把問題從「B 正確嗎」改成「在同一批案例上 B 有沒有比 A 好」，用成對評審來判，而且平手也有意義(品質打平但少花 40% 工具呼叫就是勝利)。預算內成功變成頭條指標，SEV1 的成功條件是不超過 10 次工具呼叫、30 秒，SEV3 是不超過 5 次、0.1 美元。原文這句很直接:「用 35 次工具呼叫解掉一個 SEV3 不算通過，那是一起偽裝成成功的成本事故。」

也是在這一代，生產到 eval 的飛輪開始重要: 生產失敗的 trace 被擷取下來轉成新的 eval 資料列，資料集從「我們想像會壞的東西」變成「實際壞過的東西」。

Gen 6: The AI Harness

架構: 把迴圈包進一層 harness，外圍是記憶、sandbox、skills、工具探索、權限、持久狀態、審批和各種整合。這個模式出現是因為現代模型有能力把更豐富的周邊用好: 給它 sandbox，它會寫腳本跑出來而不是用英文推理 20 步;給它記憶工具，它會替下一個 session 留線索;給它一堆參考文件，它會抽出真正重要的那一段。

四個主要周邊是工具探索(透過 MCP 形式的註冊表按需載入，讓預設 context 保持精簡)、記憶(跨 session 持久，不用每次重新解釋整個世界)、程式執行(sandbox 環境，對很多任務比純語言推理更便宜可靠)、Skills(可重用的指令與參考資料包，按需載入)。代價是新的瓶頸: context。原文的說法是，context engineering 取代 prompt engineering 成為日常工作。

失效模式擴散到整個系統，模型不再是唯一要評估的東西: context engineering 失效(拉進 300MB 無關記憶)、工具註冊表載錯 MCP server(SRE 工具箱裡出現「行銷 CRM」工具)、記憶污染(一則「回滾總是能解決這個問題」的錯誤舊筆記被持久化，之後每次執行都被帶偏)、sandbox 濫用、政策缺口(新增破壞性工具但審批政策沒更新)、整合漂移、以及只在生產出現的失敗。原文的判斷是: 評估單位現在是「系統」，不是「一次執行」。

評估策略變成五層，要回答的是「我們信任這個 agent 再到真實世界跑一次嗎?」:

1. 冒煙測試: 先證明管線是通的。記憶讀得到嗎、skills 載得動嗎、sandbox 回得了有效結果嗎、破壞性工具在政策不允許時有沒有被擋? 原文特別註明這不是上線關卡，而是接線檢查
2. 離線評估: 跑前面幾代那些評估，但評完整 trace。分成 stage、trace、span、預算、harness 五種分數。回答「在我們已經理解的事件上，新版本有沒有比舊版本好」
3. 模擬: 造一個受控版本的世界，包含會中途回覆新約束的假值班工程師、隨事件推進而改變的工具輸出、注入的故障(壞掉的 log 行、過時記憶、不穩定的依賴)。這樣才測得到: 第一次查詢撈到雜訊時能不能恢復? 會不會忽略藏在 log 裡的 prompt injection? 注意得到記憶跟當前證據矛盾嗎?
4. Replay 與影子執行: replay 是把過去的生產事件在候選版本上重跑，問「如果上週就上了這版，結果會更好還是更差」;影子執行是把即時流量也送給候選版本但不讓它行動，只有品質、安全、預算都贏過現行版本才升級
5. 線上評分: 抽樣生產 trace 評分、監控行為漂移、把失敗轉成新的 eval case。原文說這是 evals 和 observability 合流的地方，「評估變成執行期的一部分」

不是每個團隊都該走到 Gen 6

文章結尾有一段很重要，而且容易被世代編號誤導:「這裡的教訓不是每個團隊最後都該走到同一個架構。有些團隊需要 prompt。有些需要 chain。有些需要確定性的 workflow。有些準備好用迴圈和 harness 了。正確的架構取決於任務、風險、模型、以及產品的成熟度。」

也就是說，六個世代不是六個等級。Gen 5 回到 Gen 3 的架構就是最好的證據: 這是取捨隨模型能力變動，不是後面的一定比前面好。真正到處都一樣的是運作模式: 把生產行為變成資料、審查失敗和差點出事的案例、把 trace 分群成失效模式、把重要的失敗轉成 eval case，然後用這些 eval 當作每次變更的關卡。這個運作模式，跟 Hylak 講的其實是同一件事。

三、兩篇的分歧在哪，為什麼

先講共同點，因為其實不少: 兩篇都反對一次性的 benchmark、都要求把生產失敗回收成 eval case、也都反對用想像力預先造出大量測試案例(Braintrust 說資料集要從「我們想像會壞的」變成「實際壞過的」，Hylak 說大型 eval 集通常是干擾，這其實是同一個主張)。

軌跡這件事要講得精確一點，因為兩邊的共識是有但書的。現在兩邊都主張評軌跡: Braintrust 從 Gen 3 起就把評估單位從 output 換成 trace，Hylak 的 code-aware evals 要斷言工具呼叫，他在講黃金案例時也強調「路徑跟答案一樣重要」，甚至把「軌跡很重要」列進不管怎麼變都成立的五件事。但 Hylak 對未來加了但書: 當 harness 塌縮進模型、中間步驟變得不透明，他認為端到端評估會變得更重要，「如果你無法檢查內部，你就必須信任(並驗證)輸出」。也就是說他不是主張只看輸出，而是預測「能看到軌跡」這個前提會被侵蝕。Braintrust 沒有這層疑慮，Gen 6 的評估體系整套都建立在「trace 拿得到、harness 內部可以插樁」之上，這也是下面分歧三的根源。

比起去年那場論戰，雙方的距離明顯縮短了。Hylak 當時說「evals 只是已知問題的集合」，現在他自己寫了一整份離線 eval 指南;Braintrust 的 CEO 當時說「未來屬於 evals 而非 A/B 測試」，現在這篇文章把線上評分和影子執行寫成 Gen 6 體系的兩層。但剩下的分歧集中在以下四點。

分歧一: eval 集要修剪還是累積。兩篇都把 eval 集形容成「記憶」，但推出的結論相反。Hylak 說它是「你拒絕讓它們重演的 bug 記憶」，但記憶要整理，三個月沒 fail 就該質疑它的存在;Braintrust 說它是耐久資產、是組織記憶，言下之意是要累積下去。一邊擔心的是測太多，多到 CI 跑 20 分鐘、團隊不再認真看 eval 失敗;另一邊擔心的是測不夠。

分歧二: 起點是錯誤還是架構。Hylak 是「先讀 log，找到真正在痛的模式，才針對性地加 eval」;Braintrust 是「你的 agent 是第幾代，對應這一套評分器」。差別在資源分配的順序: 前者要求評估跟真實失敗對齊(痛過才加)，後者要求評估跟系統結構對齊(有幾個節點就有幾組節點評估)。

分歧三: harness 會塌縮還是會變厚。這是小編覺得最值得注意的一組相反預測。Hylak 認為框架程式碼會消失，agent 塌縮成一個 prompt 加一個模型，沒有顯式工具迴圈可以追蹤，所以那些針對 harness 內部的評估設施會失去著力點，剩下能做的就是黃金案例和生產監控。Braintrust 的 Gen 6 正好倒過來，把 harness 當成當前的終點: 記憶、sandbox、skills、權限、審批越包越多，所以評估要分成冒煙、離線、模擬、replay、線上五層才管得住。

這個分歧不是學術問題，它直接影響你現在該投資什麼。如果 harness 會繼續變厚，建立 harness 層的評估設施(工具探索正確性、記憶載入正確性、政策執行)是划算的;如果它會塌縮，那些設施會白做，力氣該放在端到端的黃金案例和生產監控上。

分歧四: 要不要用 hosted eval 平台。Hylak 直說不建議用 hosted dashboard 跑 agent evals，理由是報表 UI 最好做、也最該跟產品緊密耦合，建議先自己寫個本地 viewer;Braintrust 本身就是 hosted 平台，文中的 replay、影子執行、線上評分都是平台級功能。這裡有明顯的商業位置差異，兩篇的重點也剛好都落在自家產品的強項上(Raindrop 是生產監控與 trace 擷取，Braintrust 是離線評估與發布關卡)，讀的時候留意這層背景就好。

為什麼會這樣，除了商業位置，還有一個更根本的原因: 兩篇回答的問題本來就不同。Hylak 回答的是「資源有限時，該先做什麼」，是一份按產品成熟度排序的行動順序;Braintrust 回答的是「你的架構長這樣時，該測什麼」，是一份按架構分類的對照清單。一個是時間軸，一個是架構軸。

四、什麼場景用哪一套

• 產品早期、流量小、團隊小: 走 Hylak 那套。5 到 10 個黃金案例、把 log 全部讀完做 error analysis、維持少量高訊號 case。他的流量分層(Stumbles → Issues → Signals → Experiments)可以直接照做，不用一開始就架監控機制。
• 架構走到 workflow graph 或 harness、高風險領域、需要發布關卡: Braintrust 那套遲早要補上。特別是 Gen 4 的合約檢查(便宜、在模型行為介入前就攔下一大類回歸)和 Gen 6 的 replay / 影子執行，這種上線前驗證等出事再補就晚了。
• agent 會執行破壞性動作: 兩篇都適用但重點不同。Hylak 的「教 agent 說我不知道」和石蕊測試(你在意的是那 1% 嗎)是決定產品定位的問題;Braintrust 的安全與影響半徑評分、審批政策評估、預算內成功則是硬需求。
• 模型或 prompt 換版: 兩邊的答案是互補的。Hylak 的生產 A/B 回答「使用者那邊有沒有真的變好」，Braintrust 的成對比較評審回答「B 有沒有比 A 好」。前者要真實流量、慢、但更接近真相;後者離線、快、可進 CI。這也正是去年論戰的核心爭點，現在兩邊都承認要有。
• 兩者可以接續: 先用 error analysis 起步，讓 eval 從真實錯誤累積出來;隨著架構換代和流量成長，再逐層補上 Braintrust 式的體系。累積和修剪也不真的衝突: 累積的是還在保護你的 case，修剪掉的是已經沒有訊號的。

五、小編的看法

先補一篇: eval 集要能維護

最近看到 Langfuse 的 Lotte Verheyden 寫的 How to build an eval set you can maintain，光標題就講到重點了: 你要建的是一套「你維護得下去」的 eval 集。小編做了一陣子 AI 應用開發，越來越覺得可持續性才是關鍵，因為大家總是說得比做得多。一開始都很有幹勁，但幾個月後還在跑、還有人在看的有幾個?

這篇的做法跟 Hylak 同一個方向，但把「怎麼決定哪些指標留下來」講得更細:

• 三種指標各有分工: Goal metrics 是你要主動推高的品質，Guardrails 是一次都不能壞的(合規、安全、格式契約，第一天就要有，即使從沒看它壞過)，Operational metrics 是成本與流量，從 tracing 免費拿到。
• 每個指標都要綁一個決策: 指標動的時候，什麼行動會改變? 擋住 deploy、回滾 prompt、還是開一個調查? 如果沒有任何行動會改變，這個指標就是雜訊。她舉的例子是對話長度: 使用者投入時會變長，卡住時也會變長，數字為了不相關的理由變動，沒辦法單獨據以行動。
• 先分辨一次性修復和泛化問題: 輸出不是合法 JSON、日期格式錯、在不支援 markdown 的純文字環境輸出了 markdown、機器人沒揭露自己是 AI，這種改個 prompt 就結案，不用建指標。該建指標的是「答案有沒有被檢索到的 context 支持」「有沒有選對工具傳對參數」這種改 prompt 解決不了、需要長期追蹤的。
• 退役已經抓不到東西的指標: 除了 guardrail 之外，一個分數連續幾個月都停在 100% 就沒有資訊量了。這跟 Hylak 的三個月法則是同一件事，但多了 guardrail 的例外，小編覺得這個例外很重要: 合規和安全檢查本來就該長期維持 100%，不能因為它沒 fail 過就刪掉。
• Goodhart 定律會找上你: 對著指標調 prompt，調久了會過擬合，要定期用新的人工標註重新驗證。

裡面還有一個 OpenAI 收據處理的例子: 商家名稱抽取有 85% 是錯的，但那些錯誤跟系統真正要做的稽核決策不相關，所以團隊決定不再追蹤它。錯誤率很高但不影響決策，這種指標留著只會讓儀表板變吵。

offline 和 online 的適用場景

先講清楚這兩個詞各自在指什麼，因為前面兩篇一直在談，但沒有並排比較過:

對回前面兩篇: Hylak 的黃金案例和 code-aware evals 是 offline，Stumbles / Issues / Signals 那套分層和生產 A/B 是 online;Braintrust Gen 6 五層裡的冒煙測試、離線評估、模擬是 offline，replay 算是拿過去的生產事件離線重跑，影子執行和線上評分才是 online。

兩個都要做，但比重不同，而且這個比重是被場景決定的，不是被方法論偏好決定的。

offline 為主的場景: 醫療、銀行這類高度隱私的領域，開發團隊很可能根本拿不到 production log，log 由另一組維運團隊分開管控，權限切得很乾淨。這種情況下 Hylak 那套「先讀原始日誌做 error analysis」是做不到的，只能在 offline 多花時間把它做好。另一種是 AI 的操作本身高風險，一開始就要做對。例如一個會直接執行 SQL 的資料 agent，DELETE 或 UPDATE 送出去就沒有回頭路了，你不會想用「先上線看看使用者會不會遇到」的方式來發現它偶爾會漏掉 WHERE 條件。這類操作的共同點是沒辦法復原，事後補救的成本遠高於事前多測幾輪，那 offline 評估的份量自然就重。

但 offline 做太多有個代價: 你測的東西很可能跟實際上線的情況不同。Galtea 那篇 Offline vs. Online LLM evaluation 講得蠻精確的:「離線評估抓的是你自己弄壞的東西。線上評估抓的是沒有人動過任何東西、卻壞掉的東西。」他們列出離線評估結構上抓不到的三類問題: 供應商悄悄更新模型、真實查詢的分佈漂移、上游知識庫或 API 改變。更根本的差別在問題是怎麼提出來的: eval 驗證的是「你已經知道要測的東西」，得先想得到某個失效模式，才寫得出對應的 case;線上的行為分析才找得出你根本不知道該問的問題，找到之後它才變成一個你寫得出來的 eval case。

所以小編的判斷是: 初期 offline eval 很有效，中後期重心該移到 online eval。初期你對系統還不了解，隨便幾個黃金案例都能擋掉明顯的錯誤，這時候 offline 的投報率很高;但做到一定程度之後，你補的案例會越來越像你想像出來的問題，而不是真正會發生的問題。同樣一份力氣放到線上，找到的都是真實發生過的。這個轉折點大概在哪，下面那張圖會再說明。

不過有個沒辦法迴避的問題: 使用者是實際承受這些問題的人。你能讓使用者替你發現問題嗎?

答案完全看場景。如果是寫作助理、程式碼補全這類使用者會審查輸出的產品，遇到問題的代價是浪費幾秒鐘，在線上跑實驗完全合理。但如果是銀行 agent 直接動帳戶、醫療 agent 給臨床建議，你不能把「發現問題」的成本轉嫁給使用者。這也是為什麼 Hylak 那張光譜圖蠻好用的: 光譜左邊(人會審查輸出)可以放心用 online 推進，右邊(agent 自主工作)就必須先在 offline 把該擋的擋下來。

兩篇該用哪一篇

就這兩篇看下來，小編認為 Braintrust 的體系太龐大了。如果你的系統是簡單的 workflow，它那套分階段、分節點的評估很好用，確實也好評估。但 agent 越複雜，要完整照它的方式做，光是建評估設施就會花掉很大的成本: Gen 6 那五層要全部撐起來，等於在維護一套跟產品一樣複雜的系統。相比之下 Hylak 的做法比較實際: 從真實失敗開始，維持一組小而有用的 case。

最後用一張圖表示小編的判斷。X 軸是投入的評估成本，Y 軸是成效:

• offline eval 初期成效上升很快，中後期趨緩。前面那幾十個黃金案例的投資報酬很高，能擋掉最明顯的回歸;但你補到第 300 個案例時，多出來的那些大多在測不會發生的邊界情況，曲線就平了。這也正是 Hylak 說 CI 跑 20 分鐘、團隊開始無視失敗的那個階段。
• online eval 初期、中期、後期都持續上升。一開始它不會比 offline 快，因為你需要流量累積、需要建監控;但它抓到的一直是真實發生的問題，所以成效不會停下來。

兩條線的交叉點，就是前面說的那個轉折: 在那之前多做 offline 是划算的，在那之後把力氣移到 online 才有效。這也解釋了為什麼 Hylak 要對 eval 集這麼果斷地修剪: 他是在把資源從已經平掉的那一段，挪到還在上升的那一段。

至於交叉點會落在哪，每個產品不一樣，而且不完全是技術問題: 回到上一節的判斷，你的使用者承受不承受得起，決定了你能多早把重心移過去。另一個判斷方式是產品目標: 還在確認「能不能跑起來」的階段，人工逐筆讀 trace 就夠了;等到目標變成規模化、要做到最好，逐筆讀看不出全貌，得再建一套把大量 trace 分群、看行為分佈的機制。沒走到這一步的團隊只能被動應付使用者回報，有人抱怨才知道有問題，卻不知道還有多少問題根本沒被回報過。

結語

從 2025 年 9 月那場「evals 到底有沒有用」的辯論，到 2026 年 5 月這兩份方法論，爭論的題目已經換了。現在沒有人說 evals 沒用，也沒有人說離線 eval 夠了，吵的是資源該先放在哪一端: 是先把評估體系照架構鋪開，還是先從真實失敗整理出最小的那組 case。

兩篇也有一個共同轉向: 重心從離線 benchmark 移到生產回饋迴路，evals 從 data science 的工作變成 product engineering 的工作。Braintrust 把它寫成「評估變成執行期的一部分」，Hylak 把它寫成「如果這個迴圈停了，信心就變成表演」，講的是同一件事。

方法論可以選邊站，但有件事兩篇沒有分歧: 你得親自去讀你的 log。Hylak 引用 Hamel Husain 那句「error analysis 是 AI 開發中最有價值的單一活動」，也是 ihower 上 AI Evals 課程時反覆聽到的。Braintrust 那套分層體系再完整，第一層資料的來源仍然是有人真的去看了失敗的 trace，並且判斷哪些值得變成 eval case。