AI Agent 評估Evaluation 全解析：從 Demo 到可上線系統的關鍵方法論（Anthropic 實戰指南）

在實務上，許多團隊構建 AI Agent 的流程大致相同：選模型 → 接工具 → 寫提示詞 → 手動測幾次 → 發布。
但這樣的流程，往往只能產出「看起來可用」的 Demo。一旦進入真實生產環境，各種預期外的錯誤、退化（regression）與品質不穩定問題就會接連出現。

真正被忽略的關鍵環節，其實只有一個：評估（Evaluation）。

近期，Anthropic 發布了一份重量級工程指南〈Demystifying Evals for AI Agents〉，深入拆解 AI Agent 評估的系統性方法。AI 開發工程師 Joe Njenga 也從開發者視角對這份指南進行了實務導讀。

本文將以「專業工程與產品團隊」為核心讀者，重構這份內容，幫助你建立一套能支撐長期演進、可規模化的 Agent 評估體系。

---

為什麼沒有評估，Agent 只會越改越糟？

Anthropic 在文章一開始就點出痛點，並以 Claude Code 的開發經驗為例：

當使用者反饋「改版後變更差」，但團隊卻只能靠猜測與反覆檢查，問題其實不在模型，而在 沒有評估機制。

在缺乏評估的情況下，團隊只能被動循環：

1. 等使用者抱怨
2. 嘗試手動重現
3. 修一個 bug
4. 祈禱沒有引入新的回歸問題

結果是：

• 無法區分「真回歸」與「隨機噪聲」
• 無法在發版前自動測試上百種場景
• 無法量化「這次到底有沒有變好」

Claude Code 早期也曾如此。直到團隊引入 結構化評估（從簡潔度、檔案編輯行為，到後期的過度設計等複雜行為），才讓產品改進開始變得可衡量、可討論、可協作。

---

Agent 的整個生命週期，都離不開評估

評估不是後期補丁，而是全生命週期工具：

• 早期階段：
  評估用例能迫使團隊明確定義「成功是什麼」，避免工程師各自解讀規格。
• 成熟階段：
  評估用來維持一致的品質門檻，確保產品不隨著優化而退化。

更重要的是：
當新模型出現時，有評估的團隊幾天就能完成升級；沒有評估的團隊，往往需要數週人工測試。

---

為什麼 Agent 評估，不能照抄傳統測試？

傳統測試 vs Agent 評估的根本差異

• 傳統函式：相同輸入 → 相同輸出
• Agent：同一任務 → 多條合理路徑

例如，一個「建立 GET API」的編碼 Agent，可能：

1. 先寫路由再查資料庫
2. 先分析既有架構再動手
3. 先反問需求再實作

三條路都可能是「正確解」。
如果你的測試只接受其中一條，就會錯殺真正好的 Agent 行為。

Agent 評估的三個關鍵特性

1. 多步驟、跨工具、跨環境
2. 錯誤會累積（複利效應）
3. 有時「沒照規則走」，反而更好

這也是為什麼 「評結果，而不是評路徑」 是 Anthropic 一再強調的原則。

---

Anthropic 內部通用的 Agent 評估術語

在設計評估前，先對齊語言：

• 任務（Task）：單一測試案例與成功標準
• 試驗（Trial）：同一任務的一次完整嘗試
• 評分器（Grader）：負責判斷表現的邏輯
• 執行記錄（Transcript）：完整對話、工具呼叫與中間狀態
• 結果（Outcome）：環境中的最終真實狀態
• 評測框架（Evaluation Harness）：負責跑測試、收集與彙總
• Agent 框架（Agent Harness）：模型 + 工具編排系統
• 評測套件（Evaluation Suite）：一組針對特定能力的任務集合

---

三種評分器（以及實務怎麼搭配）

1️⃣ 基於程式的評分器（Code-Based）

• 單元測試、靜態分析、狀態驗證
• 適合：客觀、可驗證結果
• 盲點：無法判斷可讀性與設計美感

2️⃣ 基於模型的評分器（Model-Based）

• 使用 LLM + Rubric 打分
• 適合：主觀品質、開放式任務
• 實務技巧：允許模型回傳「未知」，避免亂判

3️⃣ 人工評分器（Human）

• 黃金標準，用來校準模型評分器
• 缺點：慢、貴、不可規模化

👉 最佳實務：混合使用
例如除錯 Agent：

• 單元測試（是否真的修好）
• 靜態分析（有沒有新問題）
• LLM 評分（品質）
• 狀態檢查（有沒有改錯檔）

---

能力評估 vs 回歸評估：別搞混目的

能力評估（Capability Evals）

• 問題是：「它到底能做到什麼程度？」
• 通過率太高，代表測試太簡單
• 用於探索邊界與學習方向

回歸評估（Regression Evals）

• 問題是：「它還能不能持續做到？」
• 期望接近 100%
• 用於確保優化不退步

📌 順序很重要：
能力通過後 → 才「畢業」成回歸測試。

---

非確定性下的關鍵指標：pass@k 與 pass^k

• pass@k：k 次中至少成功一次
  → 適合探索、研發階段
• pass^k：k 次必須全部成功
  → 適合生產環境

如果單次成功率是 73%：

• pass@10 看起來很好
• pass^1 代表 27% 使用者會失敗

👉 結論：

• 研發看 pass@k
• 上線看 pass^k

---

8 步可落地的 Agent 評估行動路線

0. 從 20–30 個真實失敗案例 開始
1. 把「發版前必看 3 件事」自動化
2. 消除任務歧義，對齊成功定義
3. 同時測「該做什麼」與「不該做什麼」
4. 評結果，不評路徑
5. 引入部分分數（不是非黑即白）
6. 讀執行記錄，驗證是 Agent 還是評分器錯
7. 通過率 100% 時，加難度
8. 持續迭代，評估本身也要演進

---

瑞士起司模型：分層防禦才撐得住生產

沒有任何單一評測能抓到所有問題：

• 部署前：
  • 自動化評測（單元測試、靜態分析、LLM rubric）
  • 人工抽查 transcripts
• 部署後：
  • 生產監控（成功率、延遲、token）
  • 使用者回饋 → 轉為新測試用例

每一層，都在補另一層的洞。

---

結語：評估結果，而不是限制 Agent 的創造力

對原型來說，手測或許夠用；
但對任何 面向客戶、影響業務的 Agent，沒有評估，就注定陷入被動循環。

最重要的實務結論：

• 從真實失敗案例開始
• 評「結果」，不是「過程」
• 有策略地組合評分器
• 生產環境重視 pass^k
• 建立多層防線，而非單點信仰
• 定期閱讀 transcripts，確保你「評對問題」

---

給專業人士的未來趨勢與建議

1. Agent 評估將成為 AI 工程的核心基礎設施，就像 CI/CD 之於傳統軟體。
2. 模型越強，評估越重要：否則你無法分辨是模型進步，還是系統退化。

---

參考資料

• Anthropic Engineering Blog（官方）
• Medium｜Joe Njenga（實務解析）