Agent 能跑起來，只是第一步。文章作者：elune
文章編譯、來源：ME News
Agent 能跑起來，只是第一步。
真正困難的是判斷：它是否穩定、是否正確、是否因為一次提示詞或模型更新而悄悄退化。
以下 10 種評估方法，值得每一位 AI 工程師了解。
1. 黃金測試集｜Golden Set
Prepare a set of fixed and frozen test cases.
每次修改提示詞、模型、工具或工作流程後，都重新運行這組案例，判斷系統究竟是變好了，還是在某些情境中悄悄失效。
It is the most fundamental baseline in the Agent evaluation system.
推薦工具：OpenAI Evals
可用於建立可重複執行的基準測試集，並對比不同模型或系統版本的表現。
2. LLM 裁判｜LLM as Judge
使用另一個大語言模型，根據預先編寫的評分標準，對開放式回答進行評判。
當任務沒有唯一標準答案，無法透過字串匹配或固定輸出判斷對錯時，這種方法尤其有效。
例如，可讓裁判模型評估回答是否準確、完整、相關，以及是否遵循用戶要求。
推薦工具：OpenEvals
提供面向 LLM 應用的現成評估器，可快速搭建自動化評審流程。
3. 多維評分｜Rubric Scoring
不要只給 Agent 一個籠統的「質量分」。
應分別評估：
- 正確性
- 完整性
- 表達風格
- 安全性
- Response speed
- 調用成本
一個綜合分數可能掩蓋真正的问题。
例如，總分下降，可能不是答案錯誤，而是工具調用成本突然增加；總分上升，也可能建立在安全性下降的基礎上。
推薦工具：DeepEval
支援建立自訂指標，並對不同品質維度進行獨立評分。
4. 軌跡評估｜Trajectory Eval
不要只評估 Agent 最終給出的答案，還要評估它完成任務的整個過程。
包括：
- 是否選擇了正確的工具
- 是否以合理順序調用工具
- 是否重複執行無效操作
- 是否遺漏必要步驟
- 是否根據工具結果正確調整決策
代理可能最終得到正確答案，但中間過程效率低下、脆弱，甚至存在風險。
推薦工具：AgentEvals
可檢查 Agent 在完整執行軌跡中的動作、決策和工具調用。
5. 工具單元測試｜Tool Unit Tests
為 Agent 使用的每一個工具編寫獨立測試。
使用固定輸入，驗證固定輸出，不讓模型參與其中。
這樣可以將問題拆開：
是 Agent 的推理出了問題，還是底層工具、介面或 MCP Server 出了問題？
只有先確保工具本身可靠，才有意義評估 Agent 是否正確調用了工具。
推薦工具：MCP Inspector
可用於檢查和測試 MCP Server、工具參數及返回結果。
6. 回歸測試集｜Regression Suite
Save past real execution cases and re-execute after each update to prompts, models, or toolsets.
隨後對比新舊版本結果，檢查：
- 原本正確的任務是否失敗
- 輸出格式是否發生變化
- 工具調用是否增加？
- 延遲和成本是否上升
- 某些邊緣案例是否退化
新版本的平均表現更好，並不意味著它沒有破壞舊有功能。
推薦工具：Promptfoo
Support running reproducible evaluation suites, capturing regression issues, and integrating check processes into CI.
7. 生產環境 A/B 測試｜A/B Testing in Production
將真實用戶流量隨機分配給兩個不同版本，比較它們在實際環境中的表現。
可以測試：
- 兩套提示詞
- 兩個模型
- 兩種 Agent 工作流
- 不同工具組合
- 不同的回覆策略
離線評分更高的版本，不一定能帶來更高的用戶成功率。
真正重要的是實際結果，例如任務完成率、用戶採納率、轉化率、人工接管率和問題解決率。
推薦工具：GrowthBook
提供功能開關、受控實驗和產品分析能力。
8. 人工審核｜Human Review
定期抽樣真實運行記錄，由人類審核者進行評分。
人工審核不僅可以發現自動化評估遺漏的問題，還可以用於校準 LLM 裁判。
需要重點檢查：
- 模型評分是否與人類判斷一致
- 評分標準是否足夠清晰
- 裁判模型是否偏愛冗長回答
- 自動評估是否遺漏嚴重錯誤
自動化評估不能完全替代人工判斷。
推薦工具：Argilla
協助團隊收集人工反饋、審核模型輸出，並將結果轉化為高質量數據集。
9. 影子運行｜Shadow Run
讓候選版本在真實流量上同步運行，但不將它的輸出展示給用戶。
生產環境仍使用舊版本，而新版本僅在後台執行，用於比較兩者表現。
這種方式適合高風險更新，例如：
- 更換核心模型
- 重寫系統提示詞
- 接入新的外部工具
- 修改 Agent 決策邏輯
- 擴大工具權限
Shadow running helps teams identify issues in real traffic before official release, while avoiding direct impact on users.
推薦工具：Langfuse
追蹤生產運行、比較候選版本，並監控評估結果。
10. 紅隊測試｜Red Teaming
在攻擊者之前，主動攻擊自己的系統。
測試範圍包括：
- 越獄攻擊
- 提示詞注入
- 敏感資料洩露
- 權限繞過
- 工具濫用
- 惡意檔案或網頁內容
- 非預期外部操作
對於能夠調用數據庫、發送郵件、修改文件、執行代碼或訪問內部系統的 Agent，紅隊測試尤其重要。
推薦工具：Garak
可掃描 LLM 系統中的安全漏洞和不安全行為。
Offline evaluation tells you: the system works properly in the testing environment.
The online assessment tells you: the system will continue to function normally after going live.
你現在可能還不需要一次性搭建全部 10 種評估機制。
更實際的做法是：
回顧最近一次 Agent 故障，然後優先部署那兩種本可以提前發現問題的評估方法。
先建立黃金測試集，再補上回歸測試或人工抽檢，往往就能避免大量低級事故。
值得收藏。