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

Rustam 在 Snorkel AI 領導 AI 平台團隊，這家公司專業製作和銷售 agent 評估基準。他開篇指出一個根本問題：許多公司仰賴公開的 benchmark（例如 SWE-bench 評估代碼修復能力、Terminal Bench 評估終端操作）來衡量 agent 能力，但這類公開基準只涵蓋狹窄的領域。真實生產環境中，你需要評估的是自己公司的完整 stack──不只是模型的能力，還包括 prompt、工具組合、公司政策、成本和延遲。因此每家公司都必須建立自己的私有 benchmark。

傳統的 agent 評估方法是分析生產環境中失敗的 traces。一個 trace 記錄了 agent 的輸入、採取的行動和輸出，從中可以看出 agent 是否成功、有無邊界情況。但這方法有嚴重限制：無法重複相同的實驗（因為數據庫狀態、工具版本會變化），無法公平比較不同的 agent 配置，難以測試假想的修復方案。

Snorkel 的解決方案是將生產 traces 「反向工程」成可重複的模擬任務。核心思想是拿一個真實失敗場景，抽象成一個測試任務，包含模擬環境和驗證規則。這樣的好處是可以線下快速迭代：嘗試不同的 agent 配置（換模型、調 prompt、改工具），同時保持環境一致，從而公平地比較多維度指標。

環境構造的做法借鑒集成測試邏輯。講者強調環境要「看起來像真正的生產環境」，但不需要運行完整的生產系統。實際做法是用 Docker 容器編排：agent 運行在主容器，其他容器模擬 API 服務、數據庫、MCP tools。對於長期運行的任務，使用多步驟設計，每步有獨立的 prompt 和驗證邏輯，允許提前停止以節省成本。特別地，用戶互動也要模擬，用一個帶自己 prompt 的 LLM 扮演用戶角色，確保 agent 察覺不到自己在測試環境中。

驗證分三層。首先是確定性檢查，直接檢驗最終輸出或工具調用是否正確──這對像代碼生成這樣的任務很有效。其次是用 LLM-as-judge，讓 LLM 評估 trace 質量、agent 的規劃是否合理。最後是主題專家，不是審查所有任務，而是在不同驗證器產生分歧時介入，特別是當 agent 和驗證邏輯的判斷不一致時。Benchmark 開發本身被視為軟體工程，需要完整的 CI 管線：檢驗依賴是否正確固定、基礎鏡像是否最新、是否有缺失的測試數據；運行 Oracle 解決方案確認任務本身可解決；多次運行驗證 agent 的表現穩定性；根據難度標記任務。

最終形成一個完整的循環。發布前，benchmark 驗證 agent 能否處理邊界情況、邊界工具失敗情況。發布時，benchmark 成為 release gate，確保任何代碼變更不產生迴歸。發布後，生產環境中的失敗被記錄、分析，並轉化為新的 benchmark 任務或 fine-tuning 數據集。講者特別強調一個重要原則：不要把所有問題都堆進 prompt 裡（如「永遠不要輸出 X」「只做 Y」），而是根據問題性質在正確的層面修復──如果是上下文超載，改進 skills 設計；如果是缺失工作流程，加入新 skill；如果是輸出格式問題，用 structured output。