評估 AI Agent 的兩種方法論：六個世代的分層體系 vs 拉高下限的 error analysis
- Source URL: https://blog.aihao.tw/draft/agent-evals-two-approaches/
- Published: 2026-08-02
- Source: 愛好 AI 工程 Blog（AIHAO）
- Capture notes: 擷取 canonical draft page 的
div.post-content可見正文；正文保留來源文章內容，未加入衍生摘要或改寫。
2026 年 5 月同一個月出了兩篇談 agent evals 的長文，放在一起讀特別有意思：一篇是 eval 平台 Braintrust 的 The six generations of AI agents and how to eval them，另一篇是 Raindrop 創辦人 Ben Hylak 寫的 How to evaluate AI agents: The 2026 Guide。兩篇都是實務派、都在講怎麼評估 production agent，但路線差異很大：一篇把評估體系越蓋越完整，另一篇開頭就表態「事情沒那麼複雜」。小編先分別整理兩篇的重點，再來比較分歧在哪、為什麼，以及各自適合什麼場景。
- Braintrust：架構每換一代，eval 就要跟著換
作者是 Ameya Bhatawdekar 和 Tony Xu，全文超過 30 分鐘的閱讀量。核心論點是：agent 架構跟著模型能力演進，而每一代架構都會產生「前一代 eval 看不見的失效模式」，所以 eval 策略必須跟著架構換代。
文章最讚的地方是用同一個範例貫穿六個世代：一個叫 Sentinel 的 SRE 事件回應 agent，收到 checkout-service 的 5xx 警報後要找出根因。同一個任務，六種架構，六種評估策略，對照非常具體：
世代 架構 Eval 重點
-
The Prompt 單次 LLM 呼叫，無工具無檢索 50-500 筆黃金資料集，評答案品質（事實性、涵蓋度、安全性）
-
The Chain 固定管線：檢索 → prompt → LLM 分階段評分：解析準確度、檢索 recall、上下文忠實度、最終答案
-
The ReAct Loop LLM 當迴圈控制器，自己選工具 評估單位變成 trace：工具選擇、參數品質、停止時機、成本預算
-
The Workflow Graph 顯式 DAG／狀態機，高風險決策移回確定性程式碼 像測軟體：節點單元測試、合約測試、分支涵蓋率
-
Modern Agent Loop 模型變強，回到迴圈架構 多次試驗看分佈：pass@k、pass
-
The AI Harness 迴圈外層加上記憶、sandbox、skills、工具探索、權限審批 分層體系：smoke test → 離線 → 模擬 → replay／shadow → 線上
幾個值得記的點：
評估單位一直在變：Gen 1 評的是「答案」，Gen 2 開始分階段評分，把解析、檢索、推理分開算，才能定位失敗發生在哪一段。Gen 3 之後評估單位變成整條「trace」：工具選對了嗎、參數合理嗎、該停的時候有沒有停、成本有沒有超標。
Gen 5 的重點是「分佈」，不是「點估計」：模型變強後大家又回到迴圈架構（架構跟 Gen 3 相同，這也說明世代不是線性進步），但同一個輸入跑兩次可能走出不同路徑。所以要對同一個 case 跑多次試驗，追蹤 pass@k（k 次裡至少成功一次，量的是能力）和 pass^k（k 次全部成功，量的是一致性），還要看變異數。文中這句講得很白：「使用者體驗到的不是你的平均表現，而是眼前的那一次執行。」
Gen 6 的 harness 讓 eval 變成分層體系：當 agent 包上記憶、sandbox、skills、工具探索、權限審批之後，失效來源多到單一層級的測試涵蓋不了，例如記憶被壞筆記污染、工具註冊表載錯 MCP server、政策漏了新的危險工具。於是評估分成五層：冒煙測試（smoke test）確認 harness 本身正常、離線評估已知案例、模擬環境測干擾反應、replay 與影子執行（shadow run）驗證新版本上線安全性、線上評估持續抽樣生產 trace，並把失敗回收成新的 eval case。
貫穿全文的主張是：「evals 是 AI 的 TDD（測試驅動開發）」。理由是這句：「隨著模型進步，重新實作一個 AI 功能的邊際成本越來越低；沒有變便宜的，是判斷新版本有沒有比舊版本好。」所以「實作會一直換，eval 集才是耐久資產：它是你的規格、你的回歸測試，也是你的組織記憶。」
- howtoeval：拉高下限，而不是追求高分
howtoeval.com 是 Ben Hylak 做的指南網站，他是 evals 公司 Raindrop 的創辦人，平常跟 Framer、Clay、Vercel 這些做 agent 產品的團隊合作。開頭他就先表態：大家把 evals 講得太複雜了，他寫這份指南就是要說「其實沒那麼複雜」。
先選路線：benchmark maxxing 還是 raise the floor：前者追求把分數做高，適合輸出有專家把關的輔助場景；後者追求「拉高下限」，優先消滅最貴的那種失誤，適合 agent 直接替使用者做事、沒人幫忙檢查的場景。他認為多數 agent 產品該走後者，因為「一個自信的錯誤答案，比誠實說『我不知道』更糟」。
方法論核心是 error analysis：拉高下限靠的不是預先設計完整測試集，而是從生產日誌找真實錯誤。他引用 Hamel Husain 的話：「error analysis 是 AI 開發裡最有價值、ROI 最高的活動。」真正傷害產品的「通常不是 prompt 的第一千種合成變體，而是那次退款政策的幻覺」。
照流量規模決定工作流：每天 1-100 次執行，直接人工讀每一筆原始日誌；100-1,000 次改成追蹤浮現的問題；1,000 次以上監控訊號；5,000 次以上才有條件跑對照實驗。這個分層對小團隊很實用：流量還小的時候，把 log 全部讀完就是最好的 eval。
Code-aware evals：eval 要在真實 harness 裡跑完整條執行路徑，驗證工具呼叫、狀態、檔案、結構化輸出，而不是孤立地對 prompt 打分。他給的範例直接用 TypeScript 測試框架的寫法，把 eval 當一般測試寫進 codebase。
修錯的四種做法：這是 Making fixes and changes 這章的重點：
1️⃣ 有時直接修：壞掉的工具呼叫、prompt 少了指令、檢索回傳過時資料，修完直接部署。但要分清楚「真修復」和「表面的權宜處理」：如果發現自己在為特定使用者措辭加特例，那是治標不治本。
2️⃣ 先重現再修：不簡單的問題要先在本地重現，重現不了就代表還沒真正理解它。流程是：生產發現 → 本地重現 → 加進 eval → 修 → 驗證 → 部署。
3️⃣ 但不是每個 bug 都值得變成 eval case：這是全文最有立場的一點。每修一個 bug 就加一個 case，半年後你會有 500 個 case，其中 400 個是罕見的邊界案例，CI 要跑 20 分鐘，團隊開始無視失敗。他主張「20 個高訊號 case 勝過 200 個低訊號 case」，還給了一條修剪法則：一個 case 三個月沒 fail 過，要嘛它沒在測重要的東西，要嘛 agent 真的進步了，兩種情況都該考慮刪掉。
4️⃣ 很多改動只能在生產驗證：換模型、換 prompt、換工具配置，最終要靠真實流量的 A/B 測試。他給的換模型實驗例子，任務完成率從 76% 提升到 88%。
一個特別的技巧：直接問 agent：把完整執行 trace 傳回給模型，直接問它：
“You were wrong. The answer was X. What would I need to have changed for you to get this right?”
（你答錯了，正確答案是 X。我需要改變什麼，才能讓你答對？）
用模型自己的推理能力診斷失敗原因，常常比人工逐行讀 trace 快。
最後他給了時間配置建議：把 10-20% 的 agent 開發時間花在評估和監控上。而他對 eval suite 的定義是：「一套拉高下限的 eval，是一份你拒絕讓它們重演的 bug 記憶。」
- 分歧在哪，為什麼
有意思的是，兩篇的基本面其實一致：都反對一次性 benchmark、都主張把生產失敗回收成 eval case、都認為要評整條 trace 而不只是最終輸出。分歧在優先順序和維護策略：
面向 Braintrust howtoeval
出發點 架構驅動：先看你的 agent 是哪一代，決定該測什麼 錯誤驅動：先讀生產日誌，錯什麼補什麼
Eval set 維護 持續累積，是耐久資產與組織記憶 積極修剪，三個月沒 fail 就考慮刪
對複雜度的態度 分層體系越蓋越完整，Gen 6 有五層 「沒那麼複雜」，20 個高訊號 case 就能起步
主要投資 離線評估基礎設施，生產負責回收 case 生產日誌與實驗，離線 eval 負責鎖住不退步
最直接的衝突是 eval set 的維護策略。兩篇都把 eval set 形容成「記憶」：Braintrust 說它是組織記憶、是規格、是耐久資產，言下之意是要累積；Hylak 說它是 bug 的記憶，但記憶要定期整理，三個月沒用到的就該刪。一個怕測不夠，一個怕測太多、多到團隊不再信任 CI。
為什麼會這樣？小編認為有兩層原因：
作者的位置不同。Braintrust 是 eval 平台，文中的 replay、shadow run、線上評分都是平台級功能；Hylak 的 Raindrop 從生產監控切入，所以他強調讀原始日誌、跑生產實驗。兩篇的重點恰好都對應到自家產品的強項。這不是說誰在打廣告，而是各自每天接觸的客戶問題本來就不同，讀的時候留意這層背景就好。
回答的問題不同。Braintrust 回答的是「你的架構長這樣時，該測什麼」，是按架構分類的對照清單；Hylak 回答的是「資源有限時，該先做什麼」，是按產品成熟度排的行動順序。一個是架構軸、一個是時間軸，本來就不是同一題。
適用場景，小編的判斷是：
產品早期、流量小、團隊小：走 Hylak 路線。讀 log、做 error analysis、維持少量高訊號 case，他的流量分層可以直接照做。
架構走到 workflow graph 或 harness（Gen 4-6）、高風險領域、需要 release gate：Braintrust 那套分層評估遲早要補上，特別是 replay 和 shadow run 這種上線前驗證，等出事再補就晚了。
兩者可以接續：先用 error analysis 起步，讓 eval 從真實錯誤累積出來；隨著架構換代和流量成長，再逐層補上 Braintrust 式的體系。修剪法則和累積策略也不衝突：累積的是「還在保護你的 case」，修剪掉的是已經沒有訊號的。
結語
兩篇放在一起看，2026 年的 evals 論述有個共同轉向：重心從離線 benchmark 移到生產回饋迴路，evals 從 data science 的工作變成 product engineering 的工作。Hylak 文中引用的那句話，也是 ihower 之前上 Hamel 的 AI Evals 課程時反覆聽到的：error analysis 是 AI 開發裡最有價值的活動。方法論可以選邊站，但這件事沒得選：你得親自去讀你的 log。