Agent Eval 方法論：架構分層 vs 錯誤分析
AIHAO 2026-08-02 的 draft 比較 Braintrust「六個 agent 世代」與 Ben Hylak／howtoeval 的 error-analysis 路線。兩者都反對只看一次性 benchmark、都要求把 production failure 回收成 eval case，也都把評估單位從答案推到完整 trace；真正差異是從 agent 架構 還是從 實際錯誤與資源限制 開始。
2026-08-22 canonical revision
AIHAO 後續將同一主題發布到正式 canonical URL：https://blog.aihao.tw/2026/08/22/agent-evals-two-approaches/。修訂版不只是把 draft 換網址，而是補上 2025 年 9 月 AI Evals 論戰的前因、howtoeval 的 benchmark maxxing vs floor raising、5–10 個黃金案例、code-aware eval、Stumbles → Issues → Signals → Experiments 的 production 分層，以及 Braintrust 從 Prompt、Chain、ReAct、Workflow Graph、Modern Agent Loop 到 AI Harness 的六代架構。
這個版本也把比較邊界說得更清楚：小流量、資源有限的產品先從 error analysis 與少量高訊號 case 起步；複雜 harness、高風險領域或需要 release gate 的系統，再補 stage／trace／span／budget／harness 分層、simulation、replay、shadow 與 online scoring。離線 eval 應鎖住已知回歸，線上觀測則負責捕捉供應商更新、分布漂移與上游資料變動；兩者不是二選一，而是隨產品風險與成熟度調整投資比重。
新版本新增一個需要保留的反向預測：Hylak 認為 harness 可能塌縮進模型，讓端到端黃金案例與 production monitoring 更重要；Braintrust 則把 harness 視為越來越厚的系統邊界，要求對記憶、sandbox、skills、工具探索與權限逐層評估。這是來源作者的產品方法論與預測，不是 AI Ark 的獨立 benchmark；應以實際 trace、成本、安全與使用者風險驗證。
兩條方法軸
架構分層：先問 agent 長什麼樣
Braintrust 的路線依序從單次 prompt、固定 chain、ReAct loop、workflow graph、modern agent loop 到 AI harness。架構每增加工具、記憶、sandbox、skills、權限與外層控制，就會引入前一代 eval 看不到的失效模式，因此評估也要分層：smoke test、離線案例、模擬干擾、replay／shadow，以及線上 production trace。
這條路線適合架構已複雜、風險高、需要 release gate 的系統。Gen 5 的 pass@k、pass^k 與變異數提醒團隊不要用單次平均分數掩蓋執行不一致；Gen 6 則要求把 harness 本身列入測試對象。
錯誤分析：先問產品哪裡真的壞
Hylak 的路線從 production log 出發，先讀真實錯誤，再重現、加入高訊號 eval、修正並驗證。小流量產品不必先建完整平台：每天執行量低時可以人工讀完 log，流量增加後再追蹤重複問題、監控訊號，最後才做 A/B 實驗。
這條路線適合產品早期、團隊小、資源有限的情境。它把「拉高下限」放在「追求最高分」之前，並提醒不是每個 bug 都值得永久加入 suite；長時間不再失敗的 case 應檢查是否已失去訊號，再決定保留或刪除。
差異與共同點
| 面向 | 架構分層 | 錯誤分析 |
|---|---|---|
| 起點 | agent 的架構世代與 harness 元件 | production log 與真實失敗 |
| 評估重點 | 每一層新增的工具、狀態、權限與執行路徑 | 最昂貴、最常見或最難察覺的錯誤 |
| 維護策略 | 逐層補齊 release、replay、shadow、online gates | 保留高訊號 case，主動修剪低訊號案例 |
| 最適情境 | 複雜、高風險、需要版本上線門檻 | 早期、小流量、先求快速降低錯誤下限 |
兩者可以串成同一個演進路徑：先用 agent-trace-observability 讀 log 和 trace，從真實失敗建立少量 eval；當 agent 加入 workflow、記憶、工具探索或權限控制，再用架構分層補上對應的 component、trajectory 與 release gate。這也符合 eval-is-spec：eval 是產品行為的規格，但規格要隨架構與失敗分布更新。
AI Ark 的最小採用順序
- 先固定任務分布、保留完整 trace，人工讀最有訊號的失敗。
- 將能重現且值得防止重演的錯誤寫成 eval；不要把所有罕見例外都堆進 CI。
- 以 loop-engineering 建立「發現 → 重現 → 修正 → 驗證 → 部署」回饋迴路。
- 當系統進入複雜 harness 或高風險流程，再依 harness-engineering-for-ai-coding 的工具、權限、Goal 與外層 loop 補分層 gate。
- 定期檢查 eval case 是否仍保護重要行為，避免 suite 變大到團隊不再信任失敗訊號。
來源是 AIHAO 對兩套方法論的二次整理；Braintrust、howtoeval、Hamel Husain 與作者提到的產品／數字，保留來源歸屬，不視為 AI Ark 的獨立 benchmark。