掌握AI代理評估的路線圖

在AI代理的開發中，許多團隊仍然沿用評估大語言模型的方法：運行幾個任務，檢查最終輸出，然後假設一切正常。然而，這種方法往往忽略了最重要的失敗點。模型可能選擇了不合適的工具或生成了錯誤的工具參數，代理系統可能無法妥善處理工具失敗或遵循了低效的行動序列。僅評估最終響應很難識別這些失敗發生在哪裏。

代理評估正是為了解決這一差距而設計的。它不只關注結果，而是檢查完整的執行過程——代理如何推理、決策、使用工具以及隨着任務展開而適應。這提供了更準確的可靠性、效率和整體性能圖景，幫助團隊在問題進入生產環境之前發現它們。

評估的第一步是理解為什麼代理評估很重要。當代理失敗時，本能的反應是將其視為提示問題：系統提示需要更清晰。但很多時候，失敗是測量問題：評估沒有設計來捕捉問題所在。AI代理在多個層上運行，這些層可能獨立失敗：推理層（由語言模型驅動）負責規劃、任務分解和工具選擇；行動層（由工具調用和外部系統響應驅動）負責執行。一個代理可以正確推理該做什麼，然後調用正確的工具但參數格式錯誤。將代理評估視為單一的端到端準確率檢查會遺漏這兩個失敗面。

有用的代理評估在兩個範圍內運行：組件級評估（單獨測量推理質量和工具調用準確性）和端到端評估（測量任務完成和執行效率）。80%的任務完成率並不能告訴你20%的失敗來自糟糕的規劃、錯誤的工具選擇、錯誤的參數還是工具基礎設施故障。步驟級跟蹤——記錄每次工具調用、其參數、結果以及隨後的模型決策的日誌——是進行診斷所必需的。沒有跟蹤，調試生產故障就是猜測。

第二步是定義代理評估成功的標準。評估的好壞取決於其成功標準。一個格式良好的評估任務是兩個領域專家獨立工作也能得出相同通過/失敗判定。從明確的規格説明和參考解決方案開始——已知正確的輸出能通過所有評分器。它們證明任務可解決，並驗證評分邏輯配置正確。在評分運行之前，你需要為評估定義以下內容：任務（代理接收的輸入、預期行為和環境狀態）、成功標準（不僅是最終答案，還有中間結果：是否調用了正確的工具？狀態是否正確更新？響應是否基於檢索的上下文？）、以及負例（單側評估導致單側優化。平衡的數據集——涵蓋行為應該發生和不應該發生的情況——防止代理對某項能力過度觸發或觸發不足）。從實際使用中的失敗中提煉的一組良好規格任務，比等待完美的數據集更好的起點。評估越晚構建就越困難。

第三步是使用基於代碼的檢查來評分代理的行動層。確定性評分器——無需模型參與評分的代碼——是代理評估堆棧中最快、最便宜且最可重複的選項。對於行動層，它們應始終是起點：工具調用驗證（代理是否按正確順序調用了正確的工具）、參數驗證（輸入是否具有正確的類型、所需參數和有效值）、結果驗證（環境是否處於預期狀態）、以及記錄分析（步數、令牌消耗和延遲）。這些通常快速、客觀且易於調試，但脆弱。檢查“confirmation_code”: “CONF-789”的評分器會錯過以不同格式呈現相同數據的正確響應。

第四步是使用基於模型的評判來評分代理的推理和輸出質量。某些代理評估維度難以用確定性檢查——輸出質量、語調、對檢索上下文的忠實度、適當的同理心。對於這些，使用語言模型作為評判（LLM-as-a-Judge）是合適的工具：靈活且能處理開放式輸出，但會引入非確定性和校準漂移。以下實踐可保持基於模型的評分器可靠：編寫結構化評估標準（“評估響應是否有幫助”會產生噪聲，而指定響應必須回答用户問題、基於檢索上下文、避免超出範圍建議的評估標準會產生信號。對每個維度進行獨立判斷）、定期對照人類判斷進行校準（在分歧出現時，評估標準幾乎總是問題所在。給評分器一個明確的“無法確定”選項，避免強制判斷模糊情況）、對多組件任務構建部分學分（一個能正確識別問題並驗證客户但未能處理退款的客服代理，比第一步就失敗的代理有意義得多。二元通過/失敗掩蓋了代理實際崩潰的地方）。

第五步是將評估策略與代理類型相匹配。編碼代理編寫、測試和調試代碼。軟件在很大程度上是確定性的：代碼運行嗎？測試通過嗎？修復是否在不破壞現有功能的情況下關閉了問題？基準如SWE-bench Verified和Terminal-Bench遵循這種通過/失敗方法，並輔以基於評估標準的質量檢查（安全性、可讀性、邊界情況處理）。對話代理在支持、銷售和輔導工作流中與用户交互。交互質量本身也是評估的一部分——不僅工單是否解決，還包括語調是否合適以及解決是否清晰解釋。這需要第二個語言模型模擬用户；τ-bench正是模擬了這一點，其評分器評估任務完成和交互質量。研究代理收集和綜合跨來源的信息。基於性檢查驗證聲明是否由檢索來源支持，覆蓋範圍檢查定義好答案必須包含的內容，來源質量檢查確認代理諮詢了權威材料。

第六步是處理代理評估結果中的非確定性。代理行為因運行而異；相同任務、相同輸入、相同代理可能產生不同的工具選擇、推理路徑和結果。單次試驗評估因此可能誤導，因為它隱藏了簡單準確率指標無法捕捉的變異性。這是由於代理系統非確定性的直接後果。隨機模型輸出、工具延遲、部分失敗和自適應決策都引入了運行間的變異性。因此，評估代理需要對結果分佈進行推理，而不是單一執行軌跡。常見的指標包括pass@k（至少一次成功）和pass^k（所有嘗試都成功）。例如，單次成功率75%的代理在三次嘗試中全部成功的概率僅為42%，顯示了可靠性在重複運行中的快速下降。選擇這些指標最終是產品決策而非純粹技術決策。

第七步是區分能力評估和迴歸測試套件。能力評估旨在回答前瞻性問題：這個代理能做之前不能做的事嗎？因此，它們應從相對較低的通過率開始，專注於系統仍有挑戰性的任務。當能力評估達到非常高的分數（例如90%）時，它通常不再測量能力，而只是確認已解決問題上的可靠性。迴歸評估則不同：它們問的是代理是否仍能執行之前能做的所有事情。這些測試應接近100%運行，作為防止性能退化的保障。任何有意義的分數下降都是某物損壞的信號，應在發佈前調查。隨着時間的推移，能力評估自然變得更容易。通過率上升且性能穩定後，這些任務可以升級到迴歸套件。但一旦套件完全飽和，它對真正改進的敏感性就會降低——意味着有意義的進步可能作為噪聲出現。因此，應在現有套件飽和之前引入新的、更具挑戰性的評估，而不是之後。

第八步是將代理評估擴展到生產監控。開發評估捕捉你預期會失敗的東西；生產揭示實際失敗的東西。真實用户引入輸入、邊界情況和上下文在合成測試套件中很少出現，使生產監控成為評估的必要延伸。一個完整的評估系統結合多種互補信號：自動化評估（每次提交運行，覆蓋已知失敗模式，但可能產生虛假信心）、生產監控（跟蹤延遲、錯誤率、工具失敗和令牌使用，但通常在發生後才發現）、用户反饋（突出顯示代理指標正確但用户意圖失敗的情況，稀疏但高度信息豐富）、以及手動記錄審查（提供對推理、工具使用和決策路徑的定性洞察，幫助驗證自動評分器是否測量了正確行為）。這些層共同形成更完整的代理性能視圖。