別太信任你的 AI 代理，要用科學家的方式測試它們——專訪 Omni Analytics 的 Stephanie Jarmak

Omni Analytics 的 AI 工程師 Stephanie Jarmak 主張，公開基準測試與單一數字分數無法告訴你代理（agent）在你的環境裡能否使用；團隊應自行執行受控評估，並在證明可信之前對代理的執行軌跡（trace）保持懷疑。整場演講大多數時間在討論如何設計此類評估、為何測試框架（harness）與模型本身同樣重要，以及如何使用除錯工具、如何設定人工審核關卡。

Jarmak 出身研究科學家：她原本是天文學家，後來轉入 AI，在 Sourcegraph 工作一年，擔任 AMP 編碼代理的解決方案工程師，之後打造了公開的 Codescale Bench 基準測試，並在演講前幾週加入 Omni Analytics，負責其評估框架。標題的「別信任你的代理」說得沒錯，但範圍偏窄：本集內容主要是一套實用的評估設計方法論，信任與安全關卡只佔最後三分之一。

公開基準測試的分數，不等於對你係統的評估

Jarmak 把兩件常被混為一談的事劃清界線。依她的定義，評估（evaluation）是為了支撐某個產品或流程決策而進行的量測。公開基準測試則是標準化的參考題庫，適合用來瞭解整體局勢、篩選候選方案，卻不能用來決定要部署什麼。她警告不要過度看重基準測試結果，因為「這些模型的訓練過程本身就充滿尖峰起伏」。她舉例：一家律師事務所沒有理由在意 Terminal Bench 的結果，除非它要把編碼代理放到自家開發人員面前。

更有力的證據，是她引用的一份第三方比較：在廣泛使用的編碼代理基準 Terminal Bench 4 上，約 63 項任務中，透過開源測試框架 OpenHands 分別執行 Opus 5 與 Astra，結果 Opus 5 勝出。只換掉測試框架、模型保持不變，結果就翻轉，Astra 明顯表現更好——不同配置之間的有效性差距超過 30 個百分點。

| 配置變數 | Terminal Bench 4 比較結果 |
|---|---|
| 模型（Opus 5 對 Astra） | 在 OpenHands 下由 Opus 5 勝出 |
| 測試框架（換框架、模型固定） | Astra 以大幅差距勝出 |
| 差距幅度 | 配置有效性相差 30% 以上 |
| 任務數 | 約 63 項 |

她給出的結論是：要評估最接近你實際環境的配置，因為基準測試的結果未必能轉移過來。

建立反映真實工作負載的內部基準，再逐步爬坡最佳化

Jarmak 的處方是把評估當作實驗科學來做：先挑出一組候選配置，決定要改哪些變數，然後像飛輪一樣反覆迭代，朝更好的配置推進。她提出四項設計考量——工作負載涵蓋範圍、執行次數、各項變更之間的互動作用，以及可觀測性資料。

談到工作負載涵蓋範圍，她解釋為何要自建 Codescale Bench 而非使用現成方案：當時 SWE-bench 幾乎都是修 bug，但軟體開發生命週期包含的任務型別遠比這廣，且工具在各種任務上的整合方式也不同。一個模型可能擅長理解程式碼，卻不擅長修 bug。她建議把任務分群成能反映真實工作的類別。

談到執行次數，她指出這些系統本身不具確定性，所以每次執行的變異必須實際量測，不能假設它不存在。談到互動作用，前面「模型加測試框架」的結果就是她的例證：多項變更組合起來會產生單變數測試看不到的效果。

在 Omni Analytics，她把這套方法套用到生產資料上，將使用者實際與代理互動的方式分類——從簡單到困難的問答、儀錶板建置、應用程式建置——再用這些類別判斷某項變更是否帶來價值，或失敗會出現在下游哪個環節。她的收尾原則是：「生產環境才是真相。」部署之後，量測系統必須在真實環境中蒐集資料；若某項變更的影響範圍很大，可以採用影子部署。

除錯工具使用，要沿著流程逐段檢查，而不是隻看總體指標

Jarmak 的開場案例來自 Sourcegraph，當時測試程式碼搜尋的 MCP 工具。她改了初始提示，想讓編碼代理使用這個工具。結果那次執行成本降低 28%——她說，這對成本變異與實驗空間來說是一個有趣的訊號——但代理最終還是沒呼叫工具。總體數字變了，她在意的行為卻沒有改變。

她的除錯方法是依序檢查代理實際握有什麼、實際做了什麼：

flowchart TD
    A["工具到底有沒有進到代理的上下文？"] --> B["工具有沒有被呼叫？"]
    B --> C["呼叫回傳了哪些值？"]
    C --> D["任務最終結果有改變嗎？"]
    D --> E["若沒有，代表代理沒在用這些資訊——回頭檢查配置"]

她強調要保留所有執行軌跡，並把「沒使用」和「嘗試失敗」都當成第一等資料。另一個相關陷阱：你可能把工具打磨得很完美，卻發現你在意的結果毫無變化，因為代理根本沒利用工具回傳的內容。找出原因，就是工程師的責任。

先決定你要最佳化什麼，再談打分數

在比較搜尋工具時，Jarmak 最佳化的是精確率與召回率的 F1 平衡，而不是單看召回率。她舉例：用 grep 風格的搜尋，Claude 回傳 295 個檔案，但實際只需要 6 個。如果你只在意「任何可能相關的資訊都被抓進來」，召回率 1 就夠了。但她最佳化的是另一件事。

這也是為什麼她會去追問：某個公開基準測試的驗證器到底量了什麼、作者又為何認為那很重要。正確的指標完全取決於業務需求，而單一數字會把這個選擇藏起來。

標記問題不等於設下關卡，真正受限的是人工審核量能

Jarmak 經營一個她稱為「軟體工廠」的系統，設有審批佇列，盡可能自動化工作，同時定期稽核，因為她並不信任這些系統。她發現的失誤是：代理察覺到事情出錯，但程式碼裡沒有任何機制強制它停下來。她的教訓是把三件事拆開——代理或系統標記出問題、程式碼強制執行關卡、以及升級給人工處理。

量能算術來自另一個系統：該系統的 LLM 即評審（LLM-as-a-judge）誤報率為 1%，她在那裡稽核並修復判斷失誤。若每個警報都送人工處理，就代表需要審查 10,000 次。組織必須自問：有沒有領域專家能吸收這樣的負荷？瓶頸卡在哪裡？每個警報在下游的後果有多嚴重？

「我想盡可能自動化，讓工作真的完成，但我同時也完全不信任這些系統。」

執行軌跡本身也可能說謊

Jarmak 引用的一項研究中，研究人員把安全問題植入代理的輸入，並加裝雜湊校驗來偵測紀錄是否遭竄改。結果全部過關，植入的問題一個都沒被抓到。另一組獨立比對流量歷史與模型變更的方法，則全部偵測出來。言下之意：視你的安全需求而定，你必須對自己留存的事件紀錄有足夠的信任，而代理自己的執行軌跡未必能提供這種信任。

為自主性劃出明確的風險界線

Jarmak 的軟體工廠讓代理對風險較低的決策擁有自主權。當代理希望人工介入時，它必須說明下一步動作、為何需要人工、運作範圍，以及在現有選項下建議的人工檢查方式。她留給聽眾的設計問題是：安全的自動部署與停下來升級處理之間，界線該劃在哪裡。

她請聽眾參考一個 GitHub 技能庫，內容涵蓋評估設計、測試框架的可追溯性與可靠性程式；另外還有一份約 300 頁的資料庫，她建議把代理指向那裡，讓它們把最佳實務吸收進自家系統。

整場演講未解的張力在於：Jarmak 建議的每一層證據——執行軌跡、評審、雜湊校驗、基準測試分數——都有一個她自己也描述過的已知失效模式。她的答案不是找到一個可信的工具，而是冗餘：獨立紀錄、生產環境量測、強制關卡，以及科學家預設懷疑的態度。如今在建置代理評估框架的團隊，實際上是在決定：在上線之前，他們負擔得起多少這樣的冗餘。