為什麼 Agent 評估比模型評估更難
當你的 AI 程式不再是單次問答，而是可以呼叫工具、維護上下文、多步驟推理的 Agent 時，傳統的準確率指標就失效了。一個 Agent 可能在單次對話中表現完美，但在連續 10 輪互動中逐漸偏離目標——例如忘記先前的使用者偏好，或錯誤地呼叫 API 多次。
這就是 Evals（評估）對於 AI Agent 至關重要的原因。它不再簡單地對比輸出 token，而是需要設計能反映「決策品質」和「行為連貫性」的多維任務。
核心機轉：Evals 究竟在測什麼
一個成熟的 Agent Evals 系統通常涵蓋三個層面：
-
任務完成率：Agent 是否在指定輪次內達成使用者目標？例如“幫用戶預訂一家明晚 7 點的意大利餐廳”，成功標準包括：找到餐廳、確認時間、發出預訂請求。這裡容易忽略的細節是，如果 Agent 嘗試了 5 次才成功，算完成嗎？實際部署時，許多失敗恰恰來自重試次數限制和超時處理不當。
-
工具呼叫合規性：Agent 是否呼叫了正確的工具，並以正確的參數呼叫？例如，一個天氣查詢 Agent 應該呼叫天氣 API 而不是搜尋百科。工具呼叫錯誤是 Agent 故障的第一大原因，尤其在工具數量超過 5 個時，內部路由邏輯容易混淆。
-
安全性 & 邊界約束：Agent 是否會執行危險操作？例如刪除用戶資料、發送未經確認的郵件。這部分評估往往依賴規則引擎和人工審核的結合，因為完全自動化的安全評估本身就有漏報風險。
真實場景的失敗複盤：一個 Agent 評估遺漏的邊界
假設你為一個客服 Agent 設計評估資料集。你準備了 100 個測試案例，涵蓋了退貨、退款、物流查詢等常見場景。評估通過後，Agent 上線。
第一周，一個用戶諮詢「我買的商品是假的，可以退款嗎？」——Agent 直接呼叫退款 API，沒有要求用戶上傳證據，也沒有觸發人工審核。這是一個典型的評估覆蓋範圍不足：
- 失敗原因：評估資料集只包含“標準退貨流程”，沒有包含“爭議性退貨”或“詐欺可能性”的變體。
- 邊界問題：Agent 的決策邏輯是“如果用戶提到退款，請調用退款 API”，缺乏對理由的分類和風險分級。
- 可執行做法：在設計評估用例時，必須加入負例和擾動－例如使用者表達不滿但並未明確要求退款，或使用者要求退款但商品已被使用。同時，評估報告應該標記“未涵蓋的邊界場景”，而不是只給出一個“通過/失敗”的分數。
最容易失敗的地方與錯誤理解
1. 評估任務污染（Data Contamination）
如果你用公開的 Agent 基準資料集來評估自己的 Agent，很可能會得到虛高的分數。因為 Agent 模型可能已經在預訓練階段看過這些任務。
判斷依據：檢查基準資料集的發佈時間是否晚於你的模型訓練截止時間。更安全的做法是：自己建構私有評估任務，或至少對公共資料集做隨機擾動。
2. 把成功率當成唯一指標
許多團隊只專注於“任務是否完成”，忽略完成過程中的代價——例如 API 呼叫次數、推理時間、使用者需要糾正的次數。一個成功率 90% 但平均耗時 3 分鐘的 Agent，在實際業務中可能不如一個 80% 但 10 秒內完成的 Agent。
可執行做法：建立多指標看板，至少包含：成功率、平均呼叫輪次、平均推理時間、使用者介入率。
3. 忽視評估成本本身
每次評估都要呼叫一次或多次 LLM 推理。如果你每天有 1000 個評估用例，每個用例平均 5 步推理，總 token 消耗可能會超預算。更關鍵的是，評估結果可能因為模型服務負荷波動而不穩定。
代價邊界：需要預設一個“評估預算上限”，並定期審查評估的 ROI。有時用一個小模型（如 GPT-4o-mini）做快速篩檢，再用大模型做精確判斷，能有效降低成本。
如果你現在就要落地，第一步該怎麼做
步驟鏈：從零建造評估看板
-
定義核心行為（1-2 天） 列出你的 Agent 必須做對的 3-5 個關鍵行為。例如：購物 Agent 必須能正確列出購物車中的商品、修改數量、結算。不要試圖一次覆蓋所有場景。
-
建構 10-20 個基礎測試案例（1 天） 每個行為至少對應 2 個用例：一個正常路徑，一個邊界情況。例如对“修改数量”：正常是改为正数，边界是改为 0（应该触发确认）或改为负数（应该报错并保持原数量）。
-
运行首次评估（半天） 記錄每個用例的通過/失敗，以及 Agent 的推理軌跡。這一步的核心目標是發現「根本不可行」的場景，而不是追求高分。
-
迭代扩展用例库（持续） 根據生產日誌中的真實失敗案例，每週補充 5-10 個新用例。優先順序：先處理導致資料損失或資金損失的高風險案例。
-
建立回歸機制（每月） 每次更新 Agent 後，跑一遍完整的評估套件。必須有一個自動化腳本，能在 30 分鐘內輸出對比報告。
避坑指南
- 不要一開始就追求自動化評估。人工標註 100 個用例並逐條審查軌跡，比跑 10000 個自動化用例但無人審視要有效得多。
- 注意評估用語的模糊性：例如「找到相關商品」的評估標準是什麼？是包含關鍵字、價格區間匹配，還是用戶點擊了推薦？必須明確可操作的定義。
下一步去哪里继续系统化学习
從一般開發者轉型為 Agent 工程師，評估只是其中一環。你需要係統掌握：決策循環（Loop）設計、情境視窗管理、工具定義與呼叫、模型選擇與代價優化。這些知識在碎片化的部落格裡很難拼成完整拼圖。
如果你已經完成了上面第一步的評估看板搭建，表示你具備了實踐基礎。接下来的重点是：如何把你的 Agent 从一个“原型”打磨成“产品级”系统——包括鲁棒性测试、长程任务分解、故障恢复策略等。
我們在高品質原始付費文章和 AI 程式設計進階課程中，會逐步拆解這些模組。每篇文章都是獨立可執行的工程實踐，而非理論闡述。你可以根據自己目前的專案需求，選擇對應的章節切入。
暫無評論，快來發表你的看法吧