從 trace 走向 agent 模擬評測

041Rustem Feyzkhanov（Snorkel AI）20:232026-07-25 上架

From Agent Traces to Agent Simulations — Rustem Feyzkhanov, Snorkel AI

Snorkel AI 的 Rustem Feyzkhanov 主張每家公司都要有自己的 benchmark，把 production trace 變成可重複跑的模擬任務，當成 agent 的發版關卡與改進迴圈。

這場講了什麼

• trace 能找問題，卻難比較版本：Rustem 說 trace 適合在 production 找失敗案例，但 A/B 測試每次的資料庫狀態、工具版本都不同，很難公平比較。模擬可以把 trace 變成任務，離線平行跑不同的 agent 設定。
• 公開 benchmark 只能當參考：公開 benchmark 各自專攻特定領域，也多半只看 pass rate。上線時要看的還有成本、延遲和重試次數，所以要用貼近自家用例、工具與政策的私有 benchmark。
• 測的是整套系統，不只是模型：在模擬裡固定環境與評分方式，就能改 prompt、harness、skills 與工具，比較整個系統。Rustem 把 benchmark 的用途分成確認可用、當發版關卡、再往下優化成本與延遲甚至做 RL 訓練。
• 一個任務分成三組檔案：agent 看得到的指示與環境、agent 看不到的 Oracle 解答與 verifier，再加上 metadata。環境要像縮小版的 production，使用者可以用 LLM 模擬；verifier 可混用確定性檢查與 LLM、harness 或 agent 當評審。
• benchmark 是軟體，要有自己的 CI：任務可能太簡單、verifier 太寬或太嚴、agent 也可能鑽模擬環境的漏洞。Rustem 建議檢查依賴有沒有釘版本、Oracle 能不能通過，並多跑幾次 agent 來標記難度。
• 失敗收進 benchmark，修在對的層：Rustem 認為不該把所有修正都塞進 prompt。context 太滿就改 harness，缺流程就放進 skill，要固定格式就用 structured output。上線後的失敗再回頭擴充 benchmark。

影片從哪一段開始看15 段

1. 00:13開場與三個重點Rustem 自我介紹是 Snorkel 的 AI 平台團隊負責人，說這場要記住的是：每家公司都需要 benchmark，要貼近 production，還要成為 agent 生命週期的一部分。
2. 01:28為什麼是 SnorkelSnorkel 是服務公司，大規模製作 benchmark，每月跑數百萬次 agent 模擬，並用 agent 搭配領域專家來建環境。
3. 01:45trace 的侷限trace 能在 production 找失敗，但 A/B 測試很難重現，模擬則把 trace 變成任務，離線平行比較成功率、成本、延遲與重試。
4. 03:05公開 benchmark 不夠公開 benchmark 各專攻一個領域且偏重 pass rate，貼近自家領域的私有 benchmark 才適合拿來決定能不能上線。
5. 04:38測整套系統與三種用途環境與評分固定後，可以換 prompt、harness、skills 與工具；benchmark 用來發版前確認、當發版關卡，也能拿來優化與訓練。
6. 06:30任務的解剖agent 跟環境互動後產出 trace、環境最終狀態與檔案，再由 verifier 算指標；Oracle 用來證明任務本身解得開。以 Harbor 格式為例，檔案分成指示、環境、Oracle 與 verifier、metadata。
7. 08:29環境怎麼建環境要像縮小版 production 又不能跑完整 production：用資料庫快照、sidecar 容器、mock 的 API，使用者則由 LLM 模擬，長任務拆成多步並可提早結束。
8. 10:27verifier 的做法verifier 看最終狀態、trace 與產出檔案；可用確定性檢查，也可用 LLM、harness 或 agent 當評審，領域專家只複審有分歧的案例。
9. 11:56benchmark 任務會出什麼錯agent 可能鑽模擬環境的漏洞；任務太簡單、verifier 太寬或太嚴，或 agent 表現不穩，都要在開發 benchmark 時抓出來。
10. 12:57把 benchmark 當軟體管為 benchmark 另外建 CI：檢查依賴與 base image、跑 Oracle，並多跑幾次 agent 把任務標成簡單、中等或困難，通過後才收進 benchmark。
11. 14:04改進流程與 prompt 反模式先建基準線，看失敗、一次只改一件事再重跑；問題要修在對的層，不要全塞進 prompt。
12. 15:22上線後的迴圈production 的失敗回頭擴充 benchmark，模擬 runner 在新設定上跑實驗並記錄，當成發版關卡，觀測與實驗要接在一起。
13. 16:54Q&A：訓練與驗證切分有聽眾問 benchmark 怎麼切分。Rustem 說做法接近傳統機器學習，需要一份 agent 沒看過的獨立資料集，比例看用例，經典做法是 80 比 20。
14. 17:45Q&A：資料來源與覆蓋要同時涵蓋主要用例與邊緣案例，例如工具失效或資料庫出問題，思路像整合測試的 happy path 加 edge case；大家都用 agent 寫程式，很多部分可以自動化。
15. 19:24Q&A：專家與 verifierSnorkel 有大量領域專家，但不必讓專家看全部，只看 agent 與各 verifier 意見不一致的案例，再據此調整負責評審的 agent。

值得記的話5 句

• Because in your production, you don't care about the model, you care about the full system.因為在 production 裡，你在乎的不是模型，而是整套系統04:55

• One thing, though, you cannot put a real user in your simulation task. So you can simulate the user.不過有一點，你不能把真人放進模擬任務裡，所以要去模擬使用者08:46

• Tasks could be too simple, or verifiers could be too broad, and in this case, agent will always pass, even if it does something incorrectly.任務可能太簡單，或 verifier 太寬，這時 agent 就算做錯也一定會過12:19

• Because as you saw, effectively, benchmark is software. It's code. It's files.因為如你所見，benchmark 其實就是軟體，是程式碼，是檔案12:57

• Traces are useful for finding edge case in production, but simulation helps to test what would happen.trace 適合在 production 找出邊緣案例，模擬則能測試接下來會發生什麼16:13

名詞與人物9 個

Snorkel AI

Rustem 任職的公司，自述是販售並大規模製作 benchmark 的服務公司

Oracle solution

由 benchmark 作者自己建的標準解法，用來證明任務確實解得開

verifier

分析環境最終狀態、trace 與產出檔案並算出指標的評分程式

Harbor format

Rustem 說是目前最普遍的任務格式之一，由維護 Terminal-Bench 的同一團隊做出，檔案分成指示、環境、Oracle 與 verifier、metadata

Terminal-Bench

Rustem 舉的公開 benchmark 之一，專注在 agent 於終端機中的工作

sidecar 容器

與 agent 主環境並行的容器，裝 API 服務、資料庫、MCP 工具等

simulated user

用 LLM 加上專屬 prompt 與額外 context 來模擬真人使用者的行為

reward hack

agent 發現並鑽模擬環境的漏洞來過關

Arize

Rustem 舉的工具，用來記錄實驗與收集 production 的失敗

提到但沒有展開

• Rustem 提到 Snorkel 做過一個例子：用模擬環境微調小模型，讓它在特定任務上追上大模型。
• 對團隊來說，Rustem 說 benchmark 同時是三樣東西：agent 評估的一部分、發版前的整合測試，以及讓 agent 進步的訓練集。

Agent評估開發工具

在 YouTube 看原片 ↗