前一天我們談 Observability。

Observability 可以回答：

• Agent 做了什麼
• 呼叫哪些 Tool
• 哪裡失敗
• 花多少 Token
• 花多少錢
• 最後停在哪裡

但它無法回答：

這個 Agent 到底好不好？

例如：

Build A
平均 6 turns

Build B
平均 4 turns

Build B 看起來比較快。

但如果它只是：

少做兩步，就提早宣布完成。

那 4 turns 不是改善。

所以我們需要 Evaluation。

很多團隊第一版 Eval 會做：

Dataset
=
一堆 Prompt + Expected Answer

然後：

Agent Output
vs
Reference Answer

最後算：

Pass Rate

對單輪 Question Answering，這可能夠用。

但對 Agent，問題完全不同。

因為 Agent 會：

• 多輪互動
• 主動問問題
• 呼叫 Tool
• 修改外部 State
• Retry
• 走不同路徑
• 產生 Side Effect
• 同一版本跑兩次結果不同

所以 Agent Eval 真正需要的不是一份 Prompt List。

而是一個：

可控制、可重置、可以互動的 Test Environment。

---

第一個錯誤等號：好的 Answer = 好的 Agent

假設客服 Agent 回答：

已經幫你退款完成。

文字完全正確。

但資料庫中的 Order 根本沒被 Refund。

如果 Eval 只看 Transcript，它會 Pass。

反過來：

Agent 真的完成 Refund。

但從頭到尾沒告訴使用者退款金額。

如果 Eval 只看 Database State，也不完整。

所以 Agent Outcome 至少有兩個世界：

What it said
+
What it actually changed

有些任務還有第三個：

What it must never do

這就是 Agent Rubric 和一般文字 Grading 最大的不同。

---

一個 Agent Evaluation Environment 需要什麼？

可以拆成五個部分：

1. Dataset
2. Environment State
3. Tools
4. Interaction Protocol
5. Rubric

這五個缺一個，最後的 Score 都可能沒有意義。

---

1. Dataset：不是 Prompt List，而是 Task Records

一個 Eval Task 不應該只有：

input
expected_output

更完整的 Task 可以包含：

starting_state
user_goal
hidden_information
allowed_tools
expected_state
must_say
veto
difficulty

例如客服退款：

Starting State:
order_123
status = delivered
amount = $80
refunded = false

User opens with:
「我的訂單有問題。」

Hidden Information:
order number = 123

Expected Outcome:
order_123.refunded = true

Must Say:
refund amount

Veto:
不能 refund 其他 order

這已經不是 Prompt Dataset。

它是一個小型 Scenario。

---

Dataset 最重要的不是數量，是「能不能驗證」

很多 Eval Case 看起來很真實：

幫使用者處理這個複雜問題。

但最後沒有明確 End State。

只能請 Judge 看完後說：

我覺得還不錯。

這種 Dataset 很難穩定。

所以第一個原則是：

先挑可以被驗證的任務，再追求任務看起來多真實。

例如：

有沒有建立檔案
Database 是否更新
Test 是否通過
Order 是否退款
正確 Recipient 是否收到 Email

都比：

回答品質很好

更容易建立可靠 Eval。

---

2. Environment State：每一次 Run 都必須從同一個世界開始

這是 Agent Eval 最容易被忽略的一層。

假設 Run 1：

Agent 成功 Refund order_123

如果 Run 2 沒有 Reset：

order_123
已經 refunded

第二次測試根本不是同一個 Task。

所以每一個 Episode 開始前，Environment 必須 Reset。

可以理解成：

Initial Snapshot
↓
Run Agent
↓
Final State
↓
Grade
↓
Discard
↓
Reset Initial Snapshot

這和 Testing 裡的 Fixture 很像。

沒有 Reset，分數會被前一次 Side Effect 污染。

---

Environment 要真實，但也要可控

如果 Eval 直接打 Production：

• 危險
• 不可重複
• 資料一直變
• 很難 Reset

如果 Environment 太假：

• Tool 行為不真實
• Failure Mode 不真實
• 分數和 Production 沒關係

所以目標是：

Realistic enough to matter, controlled enough to reset.

例如：

• Test Database
• Scratch Repository
• Container
• Fake External API
• Recorded Fixture
• Sandboxed Filesystem

---

3. Tools：要測 Agent，不要把解答藏在 Tool 裡

假設 Tool 是：

solve_customer_problem()

那 Evaluation 測到的可能只是 Tool。

不是 Agent。

更好的 Tool 應該是 Atomic：

get_order
refund_order
update_address
send_message

這樣 Agent 才需要真的：

• 理解問題
• 收集資訊
• 選 Tool
• 排順序
• Recovery

Eval 才能看出 Harness 是否有效。

---

Illegal Tool Call 也應該被記錄

如果 Agent 呼叫不存在的 Tool，或者 Arguments 不合法，不應該直接讓 Eval Runner Crash。

Environment 可以回：

error:
unknown tool

讓 Agent 有機會 Recovery。

同時把這次 Call 記成：

legal = false

這樣最後即使 Outcome Pass，我們還是知道：

它是乾淨完成，還是撞牆五次後才完成。

這就是 Process Metric。

---

4. Interaction Protocol：真實使用者不會第一句把答案全部講完

很多 Benchmark 會把 Task 所需資訊一次交給 Agent：

我的 order number 是 123，
我昨天收到，
我要退款，
金額是 80 元。

但真實使用者常常只說：

我的訂單有問題。

Agent 必須先問：

哪一筆訂單？

這本身就是能力。

所以 Agent Eval 需要 Interaction Protocol。

可以用 Simulated User。

---

Simulated User 的工作不是幫 Agent

一個好的 Simulated User 應該：

• 只知道自己的 Script
• 不主動洩漏所有資訊
• Agent 問對問題才回答
• 不自己補不存在的事實
• 維持同一個 Persona / Goal

例如：

Turn 1
User:
我的訂單有問題

Agent:
請問訂單編號？

Turn 2
User:
123

Agent:
你希望怎麼處理？

這樣才能測：

Agent 會不會問必要問題。

而不是只測它會不會使用已經送到嘴邊的資訊。

---

Simulated User 本身也可能是 Failure Source

如果使用另一個 LLM 模擬 User，它本身也有隨機性。

可能：

• 多透露資訊
• 少透露資訊
• 幫 Agent 圓錯誤
• 改變語氣與行為

所以 Eval 必須區分：

Agent Variance
vs
User Simulator Variance

早期 Dataset 可以先用固定 Script。

需要更真實 Interaction 時，再換成 LLM User。

但最好固定它能知道什麼、能透露什麼。

---

5. Rubric：不要只問「答案好不好」

一個 Agent Episode 可以從三個方向 Grade。

---

A. Outcome Check

最後世界是否變成正確狀態？

例如：

order_123.refunded == true

這是最重要的一層。

而且：

不要要求 Agent 一定走 Reference Path。

如果有三種合法方法都能得到正確結果，都應該 Pass。

Evaluation 應該 Grade Outcome，不是模仿標準答案。

---

B. Communication Check

Agent 有沒有把使用者必須知道的資訊說清楚？

例如：

• Refund Amount
• Deployment Result
• File Location
• Error Limitation
• 下一步需要使用者做什麼

這可以避免：

世界改對了
但使用者完全不知道發生什麼

---

C. Veto

有些事情不能用其他高分抵銷。

例如：

退款正確
+10

回答完整
+5

但退款錯訂單
-100

這類 Safety Violation 不應該用平均分補回來。

可以設成 Veto：

只要觸發
整個 Episode Fail

例如：

• 洩漏 Secret
• 修改禁止 Resource
• 寄錯 Recipient
• Refund 未確認的 Order
• 跳過 Required Approval

這比一般 Weighted Score 更適合安全邊界。

---

Rubric 要讓 Judge 能「檢查」，不是「感覺」

對 Research、Writing、Analysis 這種沒有可直接 Hash 的 End State，常常需要 LLM-as-Judge。

Rubric 最容易犯的錯誤是：

Shows deep understanding.

這句幾乎沒有可重現性。

更好的 Criteria 是：

引用至少兩個 Evidence
並說明每個 Evidence 如何支持結論

或者：

列出至少一個替代解釋
並說明為什麼被排除

Rubric 越像 Checklist，Judge 越穩定。

---

Rubric 可以分 Essential / Important / Optional

例如研究報告：

Essential

• 事實正確
• 沒有 Fabrication
• 回答核心問題

Important

• Evidence 完整
• Trade-off 清楚

Optional

• 額外延伸
• 格式漂亮

並加入 Veto：

Fabricated Source
→ Fail

這比所有項目平均加權更符合 Production 需求。

---

Judge 也會錯

LLM-as-Judge 並不是 Ground Truth。

常見 Bias：

• 偏好比較長的答案
• 第一個 Candidate 有 Position Bias
• 同一 Model Family 可能共享盲點
• Rubric 模糊時靠自己的偏好補完

所以 Judge 需要 Calibration。

---

如何降低 Judge Bias？

可以做：

1. Different Model Family

Agent 和 Judge 不要永遠用同一個 Family。

2. Swap Order

A / B 比較時：

Judge(A, B)
Judge(B, A)

都跑一次。

3. Human Gold Set

先建立一小批人工標記 Case。

比較 Judge 和 Human Agreement。

4. Disagreement Escalation

兩個 Judge 差異很大時交給人類。

Judge 不是因為自動化，就不用 Eval。

---

Pass@k 和 Pass^k：一個字元，兩個完全不同問題

Agent 有隨機性。

所以一個 Task 只跑一次通常不夠。

假設單次成功率：

60%

跑 5 次後有兩種完全不同的問題。

Pass@5

5 次裡至少成功 1 次。

它回答：

這個 Agent 有沒有能力做到？

對 Research、Search、探索型任務很有用。

Pass^5

5 次全部成功。

它回答：

這個 Agent 穩不穩？

對 Production Reliability 更有意義。

如果單次成功率是 60%，Pass@5 會非常漂亮，但 Pass^5 會非常差。

所以：

不要用「偶爾能成功」的 Metric，包裝成「可以可靠上線」。

---

Best@k

對沒有 Binary Pass / Fail 的任務，例如：

• Writing
• Research
• Design

也可以看 Best@k。

它回答：

跑 k 次，最好能做到多好？

這適合 Capability Exploration。

但仍然不能代表 Reliability。

---

Outcome Metric 不夠，還要 Process Metric

假設兩個 Agent 都成功。

Agent A：

4 turns
3 tool calls
$0.05

Agent B：

18 turns
14 tool calls
6 retries
$0.80

只看 Pass Rate，它們一樣。

但 Production 上完全不是同一個品質。

所以 Process Metric 也要一起記：

• Steps
• Legal Tool Call Rate
• Retry
• Latency
• Tokens
• Cost
• Human Handoff
• Permission Denial

Outcome 告訴你：

有沒有成功。

Process 告訴你：

是怎麼成功的。

---

Dataset 決定 Score 到底代表什麼

即使 Runner、Environment、Rubric 都做得完美：

Dataset 爛，Score 還是沒有意義。

Dataset 至少要注意四件事。

1. Verifiable

任務結果可以檢查。

2. Difficulty Tier

不要把 Easy / Medium / Hard 全部平均後只看一個數。

例如：

Easy    99%
Medium  75%
Hard    32%

如果新版本只把 Easy 從 97% 拉到 99%，Overall 可能變高。

但真正需要改善的 Hard 完全沒動。

3. Human Checked

每個 Eval Task 最好有人確認：

• 任務真的可解
• Requirement 沒有缺
• Grader 沒有錯
• Expected State 合理

不然你會一直「修 Agent」，最後才發現是 Benchmark 壞掉。

4. Contamination Defense

Public Benchmark 最後很可能進入新的 Training Data。

模型分數變高，可能是：

看過答案。

所以真正重要的 Internal Eval 可以使用：

• Withheld Answer
• Private Task
• Fresh Production-derived Case
• Parameterized Template
• Canary

Evaluation 也需要 Data Hygiene。

---

3% 提升可能什麼都不是

假設：

Build A
70 / 100

Build B
73 / 100

可以直接宣布：

Success Rate +3%？

不行。

100 個 Task 的樣本並沒有精確到可以穩定區分這種小差距。

Agent 本身又有 Sampling Variance。

所以 Evaluation 還需要基本統計觀念。

---

Repeat

同一 Configuration 不要只跑一次。

可以跑：

3 to 5 runs

看：

• Mean
• Variance
• Spread

如果今天 73%，明天 67%，那 73% 本身沒有太大意義。

---

Paired Comparison

A 和 B 應該跑同一批 Tasks。

然後看：

A pass, B fail
A fail, B pass

而不是只比較兩個 Aggregate Rate。

因為 Task Difficulty 被固定住，Paired Comparison 更容易看到真正差異。

---

Multiple Hypothesis

如果一次試：

• Prompt A
• Prompt B
• Prompt C
• Model D
• Planner E
• Memory F

最後挑一個最高分，很容易只是碰巧。

測越多組，越容易找到一個「看起來有提升」的結果。

所以：

Winner 需要重新跑。

不要只相信第一次最好看的數字。

---

Eval 的目的不是做 Dashboard，而是決定下一個 Change

一份 Benchmark Report 最後應該回答：

下一步要改什麼？

可以用這個流程：

Run Eval
↓
找 Failure Cluster
↓
讀 Trajectory
↓
提出一個 Hypothesis
↓
只改一個 Variable
↓
Run Eval Again

例如：

Overall success:
88%

但：
4 個需要 clarification 的 Task
失敗 3 個

這不是「Agent 普遍不夠好」。

而可能是：

Missing clarification mechanism。

這樣才知道該修什麼。

---

先懷疑 Eval Harness，再懷疑 Agent

當分數突然下降時，不要第一時間改 Prompt。

先檢查：

• Environment 有沒有 Reset？
• Runner 有沒有 Timeout？
• Judge 有沒有換版？
• Task Fixture 有沒有壞？
• Tool Schema 有沒有不同？
• Sandbox 資源是否不足？

Broken Eval Harness 和 Bad Agent，表面上都會顯示：

Score ↓

所以失敗 Trajectory 一定要能被讀回來。

這就是 Day 21 Observability 和今天 Evaluation 連起來的地方。

---

Ablation：這個 Harness Mechanism 到底值多少？

Awesome Agent Architecture 一直強調：

架構不是越複雜越好

那怎麼知道：

• Planning 值不值得？
• Memory 有沒有幫助？
• Subagent 是提升還是拖慢？
• Verification 是否值得成本？
• Context Compaction 有沒有傷害品質？

可以做 Ablation。

例如：

Baseline
Model + Tool Loop

Variant A
+ Planning

Variant B
+ Planning + Memory

Variant C
+ Planning + Memory + Verification

固定 Model、Dataset、Budget。

一次只改一個 Mechanism。

這樣才能回答：

這個 Harness Layer 到底帶來多少價值？

---

Model Attribution

同樣也可以反過來：

Harness 固定
Model A
Model B
Model C

這樣可以拆出：

Model Gain
vs
Harness Gain

否則換了 Model、Prompt、Memory、Tool Schema，分數上升後根本不知道是誰的功勞。

---

Production 和 Eval 應該互相餵資料

最終流程應該是：

Production
↓
Observability
↓
Failure Trace
↓
Scrub
↓
Eval Dataset
↓
Run Benchmark
↓
Improve
↓
Deploy
↓
Observe Again

這讓 Dataset 不會永遠停在最初設計者想像的 Task。

它會跟著真實 Failure Mode 演進。

---

常見錯誤設計

1. Eval = Prompt + Expected String

無法測 Multi-turn、Tool 與 State Change。

2. 只 Grade Transcript

Agent 可以「說做了」，其實沒做。

3. 只 Grade Final State

可能真的做了，但沒有正確通知使用者。

4. 沒有 Veto

危險行為可以被其他高分抵銷。

5. Environment 不 Reset

上一 Run 污染下一 Run。

6. Simulated User 一次把資訊全部給完

測不到 Clarification Ability。

7. 只跑一次

Sampling Noise 被當成能力。

8. 用 Pass@k 當 Reliability

偶爾成功被包裝成穩定。

9. Judge 沒有 Calibration

Judge Bias 被當 Ground Truth。

10. 只看 Overall Score

特定 Failure Cluster 被平均值藏掉。

11. 一次改很多東西

分數上升但無法 Attribution。

12. Benchmark 本身壞掉還一直修 Agent

浪費最多時間的一種失敗。

---

如何設計第一版 Agent Evaluation？

如果要從零開始，我會建議先選 20 到 50 個真正重要的 Task。

每個 Task 至少定義：

Starting State
User Goal
Interaction Script
Allowed Tools
Outcome Checks
Must-say Checks
Safety Veto
Difficulty

Runner 必須：

1. Reset Environment
2. 建立新的 User Simulator
3. 執行 Agent
4. 記錄完整 Trajectory
5. Grade Final State
6. Grade Required Communication
7. Check Veto
8. 保存 Process Metrics
9. 重複多次
10. 與 Baseline 做 Paired Comparison

這已經是一個真正的 Agent Eval Harness。

---

今天新增了什麼能力？

Day 21 我們建立 Observability，知道 Agent 做了什麼。

今天加入：

• Evaluation Environment
• Dataset
• Environment Reset
• Atomic Tools
• Simulated User
• Interaction Protocol
• Outcome Check
• Communication Check
• Safety Veto
• Process Metrics
• Pass@k
• Pass^k
• LLM-as-Judge
• Judge Calibration
• Statistical Comparison
• Ablation
• Regression Loop

從今天開始，我們不只可以 Debug Agent。

還可以回答：

這次修改，真的讓 Agent 變好了嗎？

---

今天的結論

Agent Evaluation 最重要的不是找到一個更厲害的 Judge Model。

也不是做一個漂亮 Dashboard。

真正的核心是：

先建立一個值得相信的測試世界，再談 Score。

一個可靠的 Agent Eval 至少要有：

Task
+
Resettable Environment
+
Tools
+
Interaction Protocol
+
Rubric
+
Repeated Runs

最重要的原則是：

分數只和產生這個分數的 Environment 一樣可信。

如果 Environment 不真實、Task 不可驗證、Rubric 不清楚、Run 不可重複，那 92% 和 72% 都只是看起來很精確的數字。

下一篇，我們會開始進入 Loop Engineering：

當 Agent 已經有這麼多 Harness Mechanism，下一步不是繼續加功能，而是把「失敗 → 修正 → 驗證」本身設計成一個可收斂的 Loop。

完整系列與程式碼範例收錄於 https://github.com/hardness1020/awesome-agent-architecture