很多團隊評估 Agent 的方法，其實還停留在評估 Chatbot。

準備一組問題、跑一次模型、比較輸出，再算出一個正確率。

但 Agent 處理的通常不是單輪問答。

它可能需要：

• 主動追問缺少的資訊
• 連續執行多個步驟
• 呼叫工具查詢或修改資料
• 在工具失敗後自行恢復
• 遵守權限與安全限制
• 用不同路徑完成同一個任務

甚至同一個 Agent、同一個任務，執行兩次也可能得到不同結果。

因此，Agent Evaluation 真正要回答的，不只是：

這次回答對不對？

而是：

這個 Agent 能不能在接近真實的環境中，穩定、安全而且有效率地完成任務？

這也是為什麼，Agent 評估需要的不是一份 Prompt 清單，而是一個完整的測試環境。

一、為什麼傳統的標準答案不夠？

假設我們要測試一個客服 Agent。

使用者只說：

我的訂單好像有問題。

一個好的 Agent 不應該立刻猜測訂單編號，也不應該任意退款。

它應該先確認：

• 使用者是哪一位？
• 哪一筆訂單有問題？
• 發生了什麼狀況？
• 使用者希望退款、換貨，還是查詢進度？

確認完資訊後，它才可以呼叫工具查詢訂單，根據公司政策判斷能否退款，執行操作，最後清楚告知使用者處理結果。

這裡至少有五種能力：

1. 能不能發現資訊不足？
2. 會不會問正確的問題？
3. 工具有沒有呼叫正確？
4. 系統資料是否真的被修改？
5. 過程中有沒有違反安全規則？

如果我們只檢查最後一句回覆是否包含「已完成退款」，就可能出現一個很嚴重的問題：

Agent 說自己退款了，實際上卻沒有執行任何操作。

反過來也可能發生：

Agent 真的完成退款，卻沒有告訴使用者退款金額與後續處理方式。

所以，只檢查文字不夠；只檢查資料庫也不夠。

我們必須同時檢查 Agent 說了什麼、做了什麼，以及最後留下了什麼結果。

二、Agent 評估需要的五個部分

一個完整的 Agent Evaluation Environment，可以拆成五個部分。

1. Dataset：要測哪些任務？

每一筆測試資料不只是「問題與答案」，而應該包含：

• 任務開始前的狀態
• 使用者真正想完成的目標
• 使用者會逐步提供哪些資訊
• Agent 可以使用哪些工具
• 任務完成後應該滿足哪些條件
• 哪些行為絕對不能發生

例如退款任務可以包含：

• 初始訂單狀態
• 使用者身分
• 退款資格
• 使用者一開始會說什麼
• Agent 必須詢問哪些資訊
• 最後哪筆訂單應該被退款
• 哪些其他訂單不能被修改

Agent 的測試資料，實際上比較接近一個「情境」，而不是一題考題。

2. Environment State：Agent 操作的世界

Agent 的工具通常會影響外部狀態，例如：

• 訂單資料庫
• Email 草稿與寄送狀態
• GitHub Issue 或 Pull Request
• 檔案系統
• CRM 客戶資料
• 行事曆
• 雲端部署環境

每次測試開始前，環境都必須恢復成相同狀態。

否則第一個測試已經退款，第二次測試就會從「已退款」開始，兩次結果根本無法比較。

因此，每次執行都需要獨立的 Sandbox、Container、資料庫快照，或至少一份完整的 State Copy。

3. Tools：把能力拆成可觀察的操作

工具應該盡量維持原子化。

好的工具可能是：

• 讀取一筆訂單
• 驗證使用者身分
• 查詢退款政策
• 退款指定訂單
• 寄送通知信

不好的工具則是：

• 解決使用者的問題
• 完成退款流程
• 處理客服案件

工具太大，評估系統就無法判斷 Agent 到底做了哪些決策。

工具拆得夠清楚，我們才能觀察：

• Agent 選了哪個工具
• 參數是否正確
• 是否呼叫不存在的工具
• 失敗後有沒有恢復
• 是否執行了多餘的操作

4. Rubric：什麼叫做完成？

Agent 的評分不應該只有一個總分。

至少應該分成三層。

Outcome：最後結果對不對？

例如：

• 指定的訂單已退款
• 退款金額正確
• 其他訂單沒有受到影響
• Email 寄給正確的收件者
• 程式修改通過原本與新增的測試

這一層最好檢查最終狀態，而不是限制 Agent 必須照某一條固定路徑完成。

Communication：該說的有沒有說？

Agent 完成操作後，通常還需要向使用者說明：

• 做了什麼
• 結果是什麼
• 金額或重要數值
• 是否需要下一步行動
• 哪些部分無法完成

只檢查系統狀態，會漏掉溝通失敗。

Veto：有沒有踩到不能接受的錯誤？

某些錯誤不能用其他優點補回來，例如：

• 修改使用者沒有指定的資料
• 洩漏密碼、金鑰或個人資訊
• 未經確認就寄信或付款
• 繞過權限限制
• 編造不存在的資料來源

即使其他項目全部正確，只要踩到安全否決項，整個任務都應該判定失敗。

5. Interaction Protocol：測試怎麼進行？

真實使用者不會在第一句話裡，把所有資訊整理成完整的規格文件。

他們可能只說：

我沒收到東西。

Agent 必須繼續追問，才能知道是哪一筆訂單、預計何時送達，以及使用者希望退款還是補寄。

因此，測試環境需要一個模擬使用者，按照腳本逐步釋出資訊。

這樣才能測到：

• Agent 是否知道缺少什麼資訊
• 是否會主動詢問
• 問題是否具體
• 有沒有在資訊不足時擅自行動
• 對話是否能在合理輪數內結束

這個模擬使用者可以是固定腳本，也可以由另一個模型扮演。

但即使使用模型，也應限制它只能根據腳本回答，不能自己補充不存在的資訊。

三、Agent 到底要測哪些東西？

Agent 評估至少要涵蓋五個維度。

1. 任務成功率

Agent 最後有沒有完成使用者的目標？

這是最直觀的指標，但不能單獨使用。

2. 穩定性

Agent 偶爾成功，和每次都成功，是兩件完全不同的事。

假設某個 Agent 的單次成功率是 60%。

同一題執行五次，只要有一次成功，Pass@5 會接近 99%。

但如果要求五次全部成功，Pass^5 只有大約 8%。

前者回答的是：

它有沒有能力做到？

後者回答的是：

它能不能穩定做到？

探索、研究或生成候選方案時，可以關注 Pass@k 或 Best@k。

準備上線或建立 Regression Gate 時，更應該關注 Pass^k。

3. 過程品質

即使任務成功，Agent 也可能是硬撞過關的。

因此還需要檢查：

• 呼叫工具的總步數
• 合法工具呼叫比例
• 失敗與重試次數
• 是否重複讀取相同資料
• 是否繞了不必要的路
• Token、時間與執行成本

結果指標告訴我們它有沒有過。

過程指標告訴我們它是怎麼過的。

4. 安全與權限

安全不能只當成平均分數中的其中一項。

有些行為必須設定成硬性門檻：

• 沒有權限就不能執行
• 高風險操作必須取得確認
• 敏感資訊不能被輸出
• 工具只能存取必要範圍
• 不確定時應該停止或轉交人工

5. 成本與延遲

一個 Agent 成功率提高，可能只是因為：

• 多跑了三倍步驟
• 呼叫更多昂貴模型
• 重試了很多次
• 花了更長時間

因此，成功率應該和以下指標一起看：

• 每次成功任務的成本
• 平均與 P95 延遲
• Tool Call 數量
• Token 使用量
• 人工介入比例

四、沒有標準答案的任務怎麼測？

研究、資料分析、軟體設計與複雜決策，通常沒有唯一答案。

這不代表它們不能評估。

真正需要改變的，是我們對「標準答案」的理解。

我們不一定要準備一份完整的參考回答，而可以準備一份由領域專家定義的 Rubric。

例如評估一份研究報告，可以檢查：

• 是否回答了原始問題
• 關鍵結論是否有證據支持
• 是否區分事實與推論
• 是否涵蓋重要反例
• 引用來源是否真的支持結論
• 是否揭露限制與不確定性
• 是否編造資料或來源

好的 Rubric 應該具備四個特性。

由專家定義

評分標準應該反映領域真正重視的品質，而不是只檢查文字流暢度。

每一項都能獨立判斷

「展現深入理解」太模糊。

「提出至少兩個可能的反例，並解釋它們是否改變結論」才是可以判斷的標準。

有權重，也有否決項

正確性、完整性、可讀性的重要程度不同。

而編造事實、洩漏資料或違反政策，則應直接判定失敗。

先用人工資料校準

LLM Judge 本身也會有偏誤。

它可能偏好比較長的回答、偏好先看到的候選，也可能和受測 Agent 共享相同盲點。

因此，大規模使用前，應先準備一批由人類專家標註的 Gold Set，確認 Judge 的評分和人工判斷是否一致。

對重要案例，也可以：

• 使用不同模型家族的 Judge
• 交換候選答案順序再評一次
• 將 Judge 意見不一致的案例送人工複核

五、測試資料要怎麼準備？

一份好的 Agent Dataset，至少要符合四個原則。

可驗證

任務的結果必須能夠被清楚檢查。

如果連人類都無法判斷什麼叫完成，就很難建立可靠的自動化評估。

分難度

簡單、中等與困難任務應分開統計。

否則 Agent 可能只是在大量簡單題上進步，卻把真正重要的困難任務弄壞。

經過人工檢查

每一題都應確認：

• 資訊是否足夠
• 任務是否真的有解
• 工具是否能完成任務
• 評分條件是否公平
• 是否存在多種合理解法

防止資料汙染

公開 Benchmark 可能進入下一輪模型訓練資料。

這時高分不一定代表推理能力，也可能只是模型看過類似答案。

實務上可以採用：

• 不公開完整答案
• 保留私有測試集
• 從正式環境收集新的失敗案例
• 使用參數化模板產生新任務
• 定期替換與更新任務

最有價值的 Dataset，通常不是一開始憑空設計出來的。

而是從 Production Trace、客服案例、失敗紀錄與人工接管事件中，持續整理出來的。

六、70% 變成 73%，真的代表有進步嗎？

不一定。

假設兩個版本都測了 100 個任務：

• 舊版成功率：70%
• 新版成功率：73%

看起來提高了三個百分點。

但在這個樣本數下，隨機波動本身可能就有四到五個百分點。

因此，這個差距可能沒有任何意義。

比較 Agent 版本時，至少應該：

1. 在相同任務上進行配對比較
2. 每個設定重複執行多次
3. 報告平均值與波動範圍
4. 分析哪些任務從失敗變成功
5. 同時檢查哪些任務從成功退步
6. 一次只修改一個主要變數

如果預期的提升，小於目前測試集能分辨的範圍，那麼下一步不是繼續調 Prompt。

而是增加任務數量，或改善評估設計。

七、評估的目的不是產生分數，而是決定下一步

Benchmark Report 最終只需要回答一件事：

接下來應該改什麼？

看到分數下降時，不要第一時間就怪模型或 Prompt。

問題也可能來自：

• 測試環境沒有正確重設
• Grader 本身有 Bug
• Tool 回傳格式改變
• 測試任務已經不符合正式環境
• 執行資源不足
• 模擬使用者行為發生變化

因此，正確的改善流程應該是：

1. 先閱讀失敗 Trajectory
2. 確認評估環境沒有問題
3. 找出失敗集中在哪一類任務
4. 提出一個可以驗證的假設
5. 一次只改一個主要變數
6. 使用同一批任務重新測試
7. 比較成功率、穩定性、安全與成本

Agent Evaluation 不是產品完成後才做的一次驗收。

它應該成為 Agent Harness 的常駐基礎設施。

每次修改 Model、Prompt、Tool、Memory、Planning 或 Permission，都應該重新執行同一套評估，確認這項改動究竟改善了什麼，又破壞了什麼。

結語：分數的價值，取決於它背後的環境

Agent 並不是不能量化。

真正的問題是，我們常常只量化最容易取得的東西，例如最後一段文字、單次成功率，或一個看起來很漂亮的平均分數。

但這些數字不一定代表 Agent 能在真實世界完成任務。

一個有意義的 Agent 評估，需要同時建立：

• 可重設的環境
• 接近真實情境的任務
• 逐步互動的模擬使用者
• 可觀察的工具操作
• 結果、溝通與安全檢查
• 穩定性、成本與統計分析

最後真正要問的不是：

這個 Agent 得了幾分？

而是：

這套評估是否能提供足夠的證據，支持我們修改或部署這個 Agent？

延伸閱讀：30 天 AI Agent 架構鐵人賽

如果你想更有系統地理解 AI Agent 架構，我最近也把 Awesome Agent Architecture 整理成 30 天 iT 邦幫忙鐵人賽系列。

這個系列會依照 repo 的內容，從最小可運作的 Agent Loop 開始，逐章拆解工具使用、Context、Memory、Planning、Multi-Agent、Harness 與 Graph Engineering，並搭配 Python 範例。

系列入口：《30 天從零拆解 AI Agent：從 Tool Calling 到多 Agent 協作》

我把這套評估流程整理成 Awesome Agent Architecture 的第 23 章，並附上可執行範例，包含可重設的環境、模擬使用者、工具呼叫紀錄、結果與安全評分、Pass@k、Pass^k，以及不同版本的配對比較。

GitHub 搜尋：https://github.com/hardness1020/awesome-agent-architecture

下一篇會繼續拆解：Agent 的測試資料到底該怎麼準備，以及如何把正式環境中的失敗案例轉成可重複執行的 Evaluation Dataset。