Harness 理論篇 Part 10｜品質與 Evaluation：如何證明 Agent 真的完成任務？

假設一個 Coding Agent 接到任務：替退款流程加入主管批准，並保留完整稽核紀錄。

它修改了程式碼，跑完 12 個 Unit Test，最後回報：

已完成。所有測試通過。

這句話看起來很像任務終點，但系統還不知道幾件事：

測試是否涵蓋「未批准不得退款」的真實流程？
Database Migration 是否真的能在乾淨環境執行？
Worker、API 與前端是否使用同一個狀態定義？
Audit Event 是否寫入正確 Tenant？
Agent 有沒有順手修改無關模組？
所謂的 12 個測試，是原有測試，還是 Agent 為自己新增的低門檻測試？
重跑一次，結果仍然成立嗎？

模型可以描述它做了什麼，也可以對自己的結果提出判斷。完成狀態不能只由執行者的敘述產生。

一套可用的 Harness 必須把「完成」變成受控的狀態轉移：任務先有 Contract，執行前經過 Gate，執行後由外部 Evidence 與 Verifier 判定，再由 Evaluation Harness 觀察這套系統跨案例、版本與時間是否真的變好。

Quality and evaluation evidence loop

Figure 10-1｜單一 Run 的 Completion Decision 與跨 Trial 的 Release Decision 是兩條相連但不同的證據鏈。

Quality Control 與 Evaluation 回答不同問題

兩者經常被放在一起，因為都在談「做得好不好」。責任其實不同。

Quality Control 發生在任務執行期間。它阻止不合法操作、檢查中間結果、要求修復，並決定某個 Run 是否能進入 passed。

Evaluation 站在多個 Case、Trial、版本與設定之上，衡量一套 Agent System 的能力、失敗模式、成本與變化。

可以先用這張表定位：

問題	Quality Control	Evaluation
作用時間	執行前、執行中、完成前	開發、比較、Release 前後與持續監測
主要單位	單一 Run、Step、Artifact、Side Effect	Task、Trial、Suite、Version、Distribution
核心輸入	Contract、Policy、Runtime State、Evidence	Dataset、Harness Config、Trace、Outcome、Grader
主要輸出	allow、deny、revise、pass、fail	score、failure cluster、regression、confidence
最終問題	這次任務能不能算完成？	這套系統在這類任務上是否可靠？

Observability 又是另一層。它提供 Trace、Metric、Event 與 Replay，讓 Quality Control 和 Evaluation 有證據可讀；它本身不等於評分。Part 11 會專門處理這條證據管線。

Task Contract 與 Completion Contract 不應混成同一張願望清單

Task Contract 定義要做什麼，以及執行期間允許什麼。

Completion Contract 定義要看到哪些證據、由誰判斷，以及什麼條件可以讓 Run 進入 passed。

兩者高度相關，但責任不同：

Contract	主要內容	回答的問題
Task Contract	Goal、Scope、Constraints、Allowed Actions、Required Outputs、Stop Conditions	這次工作要做什麼？哪些路徑合法？
Completion Contract	Criterion、Required Evidence、Evidence Authority、Blocking Rule、Decision Authority	系統憑什麼宣布完成？

若只寫「修好退款流程」，Agent 可以產生一個看似合理的 Patch，卻沒有可機械驗收的終點。若只寫一個總分門檻，又可能讓十個風格加分抵消一個跨 Tenant 的阻斷失敗。

退款批准功能可以使用這類 Contract：

contract_id: refund-approval
contract_version: 3
status: approved

task:
  goal: require supervisor approval before refunds above 500 USD
  allowed_paths:
    - services/refunds/**
    - tests/refunds/**
    - migrations/**
  forbidden_paths:
    - services/payments/provider-adapters/**
  required_outputs:
    - implementation
    - migration
    - automated tests
    - verification report

completion:
  authority: refund-completion-gate
  criteria:
    - id: REFUND-STATE-001
      blocking: true
      requirement: refund remains pending before approval
      evidence_authority: integration-test-and-database-state
    - id: REFUND-ONCE-002
      blocking: true
      requirement: approved refund is issued exactly once
      evidence_authority: provider-operation-record
    - id: REFUND-AUDIT-003
      blocking: true
      requirement: audit event records actor, tenant, amount and operation_id
      evidence_authority: audit-store-query
    - id: REFUND-SCOPE-004
      blocking: true
      requirement: no forbidden path changed
      evidence_authority: canonical-diff

這段 Contract 說明了工作邊界與 Proof Obligation。它仍然不能證明實作正確，也不能保證 Contract 本身完整。

Contract 也需要先被驗證

在執行前，至少檢查：

Criterion 是否具體、可觀察，而且不互相矛盾
Required Evidence 是否能由目前 Environment 取得
Evidence Authority 是否真的能看見該 Failure Mode
Blocking／Advisory 分類是否符合風險
Criterion 是否可能只靠 Agent 自我敘述就「通過」
Contract 是否遺漏明顯的 Side Effect、Tenant、Migration 或 Backward-compatibility 邊界
Stop Condition 是否可能讓 Run 無限修補
Completion Authority 是否唯一且可稽核

無法驗證的 Contract 應留在 draft 或 needs_review，不能因為 YAML 可解析就直接進入執行。

Sprint Contract 把高階 Spec 轉成可驗收工作單元

高階 Product Spec 通常描述使用者價值與系統行為，未必適合直接交給一個 Agent Run。

Sprint Contract 負責固定：

本輪交付的 Behavior
明確 Out of Scope
受影響 Interface
Verification Method
Expected Artifact
Risk 與 Rollback
Completion Authority

它應描述交付物與限制，不需要預先指定每一行程式碼或每一步搜尋路徑。過度微管理會把 Agent 降成昂貴的 Macro；過度寬鬆則讓驗收標準在最後一刻才被發明。

Contract 必須版本化。需求、風險或 Evidence Requirement 改變時，建立新版本並記錄原因；已開始的 Run 不能被新版 Criterion 靜默回頭改判。

Pass 應留下 Completion Decision Record

當 Mandatory Evidence 齊全後，Quality Authority 應提交一份不可含糊的決策紀錄：

{
  "run_id": "run_882",
  "contract": "refund-approval@3",
  "evidence_snapshot": "evidence-set@sha256:example-only",
  "criterion_results": [
    {"id": "REFUND-STATE-001", "verdict": "pass"},
    {"id": "REFUND-ONCE-002", "verdict": "pass"},
    {"id": "REFUND-AUDIT-003", "verdict": "pass"},
    {"id": "REFUND-SCOPE-004", "verdict": "pass"}
  ],
  "verifier_versions": [
    "refund-integration-check@5",
    "provider-operation-check@2"
  ],
  "decision": "passed",
  "decision_authority": "refund-completion-gate@4",
  "decided_at": "2026-07-08T12:00:00Z"
}

這份 Record 不能讓錯誤證據變正確。它提供的是可追蹤的 Contract Version、Evidence Snapshot、Criterion Verdict 與 Decision Authority，讓 passed 成為可重建的 State Transition，而不是 UI 上的一個綠色字。

Harness Control Quadrants：把規則與回饋接成閉環

Quality Harness 可以從兩個維度拆開：

Feedforward 或 Feedback：在行動前提供限制，還是在行動後觀察結果。
Computational 或 Inferential：由確定性程式判斷，還是需要模型或人做語意判斷。

Harness control quadrants

Figure 10-2｜成熟的品質控制會混合 Computational／Inferential 與 Feedforward／Feedback，而不是把所有責任塞進同一個 Prompt 或同一個 Judge。

Computational Feedforward

在執行前用程式強制規則，例如：

Schema validation
Allowed path
Dependency rule
Permission policy
Budget
Required precondition

Inferential Feedforward

把需要判斷的標準提供給 Agent，例如：

Task Contract
Design guideline
Domain rule
Examples 與 Counterexamples
Review rubric

Computational Feedback

用外部 Sensor 檢查結果，例如：

Unit／Integration／E2E test
Type check、Lint、Schema check
Database state assertion
Browser automation
Diff、Secret 與 Dependency scan

Inferential Feedback

對難以完全形式化的品質做判斷，例如：

Code review
UX quality
Writing clarity
Policy interpretation
Human approval
Independent LLM evaluator

四格不是採購清單。簡單資料轉換可能只需要 Schema 與 deterministic test；高風險跨系統任務才需要多層 Gate、Independent Verifier 與人工抽驗。重點是形成閉環，而不是把四格全部塞滿，讓每次小修改都經歷一場品質奧運。

Pre-execution Gate 先擋掉不值得執行的錯誤

有些錯誤不需要等 Tool 執行完才發現。

Tool Call 送出前可以檢查：

Arguments 是否符合 Schema
Resource 是否在 Task Scope
Actor 是否有 Permission
Preconditions 是否成立
Risk Class 是否需要 Approval
Operation 是否違反 Architecture Invariant
Budget 是否仍足夠
Tool Version 是否與 Runtime 相容

例如 Agent 準備直接修改 payments/provider-adapters，但 Sprint Contract 明確把該路徑列為 Out of Scope。Quality Gate 應在檔案寫入前拒絕，而不是等 Reviewer 在 400 行 Diff 裡撿到這個越界。

Gate 必須有單一 Authority。若 Hook 說 Allow、Policy 說 Deny、UI 又保留一個舊 Session Grant，系統需要固定的 Precedence，而不是讓最晚回傳的 Boolean 決定命運。

Quality Gate 不應維護第二套 Permission Model。它應呼叫 Part 09 定義的 Canonical Policy Decision，保存 Policy Version 與 Decision ID，再把結果納入 Quality Decision。Pre-execution Gate 能阻止明顯不合法的候選操作，不能證明執行後的真實 Outcome。

Architecture Rule 要能被執行，不只被閱讀

文件可以解釋設計意圖，但 Agent 不一定在每次修改前讀到正確段落，也可能理解錯誤。

適合機械化的 Architecture Constraint 包括：

禁止跨層 Import
Service 不得直接存取另一個 Tenant 的 Repository
API Schema 必須向後相容
Migration 不得修改已發佈歷史檔
Sensitive Operation 必須經過 Domain Service
User-facing Error 不得包含 Secret
指定變更必須更新對應文件或 Generated Index

這些規則可以落在 Linter、Type Checker、Architecture Test、Schema Validator、CI Gate、Runtime Assertion 或 Policy Engine。

文件與 Constraint 的分工是：

Documentation explains intent.
Executable constraints block violations.
Tests verify behaviour.
Trace records decisions and results.

Diagnostic 要讓 Agent 知道怎麼修

只回傳：

Architecture violation.

對人和 Agent 都沒有太大幫助。

較好的 Diagnostic 應包含：

ARCH-DEP-004
services/refunds/approval-handler.ts imports db/refund-record.ts directly.
Application services may depend on refund-service, not repository implementations.
Route access through services/refunds/refund-service.ts or another allowed service interface.

高品質 Diagnostic 說明 Violation、Location、Expected Invariant、Reason 與 Repair Boundary，但不必把唯一 Patch 寫死。目標是縮短修復迴圈，不是讓 Linter 兼任獨裁式程式碼生成器。

Verifier 不是萬能 Judge，Quality Authority 也不等於某一個模型

Agent 可以執行自我檢查，也可以用 Reflection 找出問題。這些訊號有價值，但不足以成為 Canonical Quality Authority。

Verifier 的工作是根據 Pinned Contract，取得、驗證並組合 Evidence。不同 Criterion 應交給能看見該 Failure Mode 的 Authority：

Criterion	較合適的 Evidence Authority
Schema、Type、Import Boundary	Deterministic validator
Database State、Side-effect Uniqueness	External state query／operation record
User Journey	Browser／API／integration runner
Security／Tenant Boundary	Policy check、adversarial case、external state
Writing、UX、Design Quality	Calibrated rubric judge／domain reviewer
Release Exception	Explicit human or organisational authority

這不是一條永遠固定的優先順序。人類不會因為是人類就自動看見 Database Truth，LLM Judge 也不會因為換了 Provider 就自動獨立。

Verification Independence 有幾個維度

Evidence independence：直接讀 Artifact 與 External State，不只讀 Generator Summary。
Execution independence：可以自己重跑必要 Check。
Criterion independence：不能在看到結果後把 Rubric 改成容易通過。
Assumption independence：不繼承 Generator 未驗證的前提。
Authority independence：Generator 無法直接寫入 Verifier Verdict。
Operational independence：Verifier Failure 不會被 UI 自動翻譯成 Pass。

不同模型或不同 Provider 可以降低部分共同偏誤，但不是必要充分條件。

Canonical Quality Authority 負責組合決策

Quality Authority 應明確回答：

誰能把 Run 從 verifying 轉成 passed？
哪些 Criterion 是 Mandatory／Blocking？
Evidence 缺失時是 unresolved、failed 還是 needs_review？
哪些 Exception 可以被誰批准？
Override 是否保留原始 Failure、理由、期限與責任人？
Verifier 或 Evidence Source 失效時是否 Fail Closed？

沒有 Evidence 不等於 Pass，也不一定等於 Fail。 對高風險 Blocking Criterion，通常應停在 unresolved 或 needs_review，直到取得證據或由明確 Authority 接受風險。

平均分、Judge Confidence 或 Human Approval 都不能偷偷覆蓋一個未解決的 Blocking Criterion。

Verification Portfolio 要匹配 Proof Obligation，不是固定爬樓梯

Schema、Static Check、Unit Test、Integration Test、E2E、Human Review 與 Canary 經常被畫成一條由低到高的 Ladder。這張圖適合提醒讀者證據可以逐步加深，但容易產生兩個誤解：

Human Review 永遠比 Integration Test 更高級。
每個高風險任務都必須機械跑完相同七層。

比較精確的做法，是把 Verification 當成一組 Evidence Families：

Risk-based verification portfolio

Figure 10-3｜任務風險決定需要哪些 Evidence Family；它不是一條所有任務都必須走到頂端的成熟度階梯。

Evidence Family	能觀察的問題	常見盲區
Schema／Static	形狀、型別、依賴與明確規則	真實 Runtime 行為
Unit／Property	局部邏輯與邊界條件	跨元件狀態
Integration／External State	Database、Queue、API 與 Side Effect	完整使用者旅程
E2E／Journey	跨介面的行為與操作順序	低機率或難重現的 Production 條件
Security／Adversarial	權限、Injection、Tenant 與濫用路徑	一般功能完整性
Human／Domain Review	開放式品質、風險接受與例外判斷	大規模穩定重複
Canary／Shadow	接近真實流量與環境的證據	無法證明未觀察到的所有情況

選擇 Portfolio 時要看：

變更涉及哪些 Component 與 External Authority
Side Effect 是否可逆
Failure 是否可能跨 Tenant、金流或權限邊界
哪一個 Sensor 真正能看到該 Invariant
Evidence Freshness 與 Environment Fidelity
Verification 成本、延遲與風險

例如高額退款可能需要 Integration State、E2E Approval Journey、Side-effect Uniqueness、Security Case 與 Domain Sign-off；一個純 Markdown 拼字修正則不需要 Production Canary。

Termination Rule 應寫進 Completion Contract。Agent 不能因為某個 Unit Test 綠了就自行刪除其他 Required Evidence，也不應在 Mandatory Criteria 全部通過後無限追求非阻斷分數。

Rubric 要攜帶 Evidence、Authority 與 Uncertainty

一個 8/10 很難指導修復，也不能說明哪一項失敗阻擋 Completion。

Evidence-bearing Criterion 至少應回傳：

Criterion ID 與 Version
Verdict／Score
Blocking／Advisory
Evidence Reference
Evidence Authority
Exact Location
Violated Invariant
Uncertainty 或 Confidence Band
Evidence Freshness
Repair Boundary
Evaluator／Grader Version

例如：

{
  "criterion_id": "REFUND-E2E-003",
  "criterion_version": 4,
  "verdict": "fail",
  "blocking": true,
  "evidence_refs": [
    "test-report://refund_approval_journey/run-781",
    "db-snapshot://refunds/case-781"
  ],
  "evidence_authority": "integration-environment",
  "observed": "refund issued before supervisor approval",
  "expected": "status remains pending_approval",
  "location": "services/refunds/refund-service.ts:148",
  "uncertainty": "low",
  "repair_boundary": "state transition and approval check",
  "grader_version": "refund-domain-verifier@6"
}

confidence: 0.99 只有在經過校準、且確實具有機率語意時才有價值。否則它只是看起來很科學的小數。

這個格式可以支援 Grade-and-Revise：

Generate
→ Verify against pinned criteria
→ Return evidence-bearing diagnostics
→ Revise within allowed scope
→ Re-run affected checks and required regressions
→ Stop, escalate or accept

Loop 還需要：

Pinned Contract／Rubric Version
Max Iterations
Cost／Time Budget
Plateau／Oscillation Detection
Regression Check
Human Sampling or Escalation
Best Valid Artifact Retention

Release Holdout 與 Hidden Case 不應完整暴露給 Generator。否則系統可能學會迎合 Grader，而不是改善對真實任務的能力。

Blocking Criterion 不能被平均分抵消。Advisory 分數可以影響排序或後續改進，但不能把 security_fail 加權成 92/100, pass。

Scope Surface 與 Pass-state Gating

Quality 不只檢查輸出，也要檢查 Agent 動過哪些表面。

Task Item 可以保存：

Allowed Files、Resources 與 Interfaces
Expected Outputs
Required Evidence
Current State
Owner／Lease
Blocker
Verification Status

passed 是 Completion Authority 提交 Decision Record 後的狀態，不能由 Generator、單一 Test Runner 或 UI 直接寫入：

pending
→ in_progress
→ implementation_complete
→ verifying
→ passed | failed | needs_review

若 Agent 修改 Out-of-scope Files，即使所有功能測試通過，也不應自動 Pass。測試只證明它觀察的行為，不能替 Scope Violation 開赦免券。

Pass Transition 應至少綁定：

Expected Run／State Version
Pinned Contract Version
Evidence Snapshot
Criterion Results
Verifier Versions
Decision Authority
Override／Exception Record
Decision Timestamp

Override 不能刪除原始 Failure。它應建立新的 Exception Record，說明誰接受了哪個風險、適用範圍、到期時間與後續處置。

Tool Protocol Integrity 也屬於 Quality：每個 Tool Request 必須有對應 Terminal Result，或明確的 Cancel／Unknown Outcome。若一個 Failed Call 從 Transcript 消失，Trajectory Eval 讀到的就是經過化妝的歷史。

Runtime Completion 與 Release Evaluation 是兩個決策

Runtime Harness 處理真實工作。它根據一個 Pinned Completion Contract，決定這次 Run 是否可以進入 passed、failed 或 needs_review。

Evaluation Harness 在隔離環境中重複執行 Case 與 Trial，控制變數、保存 Trajectory／Outcome、執行 Grader，並產生版本與任務分布層級的 Release Evidence。

Runtime harness and evaluation harness

Figure 10-4｜Runtime Completion Decision 與跨 Trial 的 Release Decision 使用不同 Harness、不同狀態與不同 Authority；兩者可以共享版本化 Contract，但不能共享 Production Side Effect。

Runtime Harness

負責：

接收真實 Request
建立 Context
執行 Agent Loop 與 Tool
維持 Canonical RunState
套用 Permission、Quality Gate 與 Budget
收集 Required Evidence
提交 Completion Decision
產生 User-facing Outcome 與真實 Side Effect

Evaluation Harness

負責：

載入 Dataset Snapshot
建立隔離或可重設 Environment
Pin Model、Harness、Tool、Policy 與 Budget
執行多個 Trial
分開保存 Transcript、Outcome 與 Infra Evidence
執行 Deterministic、Human 或 Model Grader
聚合 Segment、Variance、Failure Cluster 與 Regression
產生 Release／Research Claim 所需 Evidence

Trial Validity 不能省略

Evaluation Harness 還要判斷 Trial 是否有效：

Environment 是否初始化成功
Dependency、Browser、Database 與 Tool 是否可用
Timeout 是 Agent Failure，還是 Infrastructure Failure
Grader 是否完成
Evidence 是否缺失或損壞
Case 是否已過期、污染或不再適用

infra_invalid 不應一律算成模型失敗，也不能被悄悄刪除。它應單獨報告，必要時重跑，並限制可以做出的結論。

Runtime Evidence 可以回流 Dataset Curation；Evaluation Result 可以調整 Release Policy、Contract 或 Harness。這些回饋都應經過 Review 與版本化，不能讓 Eval Harness 直接修改 Production State。

一個 Runtime Run 通過，不等於版本可以發布；一個版本通過 Eval，也不代表每個 Production Run 都自動完成。

Step、Trajectory 與 Task 是三種不同 Proof Obligation

Anthropic 將 Agent Eval 拆成 Task、Trial、Grader、Transcript／Trajectory 與 Outcome。Transcript 是一次 Trial 的互動記錄；Outcome 是 Trial 結束後的外部世界狀態。兩者不能互相代替。¹

Step, trajectory and task evaluation

Figure 10-5｜Step 檢查局部操作，Trajectory 檢查路徑不變式，Task 檢查外部 Outcome；合法替代路徑不必複製一條 Golden Transcript。

Step-level Evaluation

觀察：

Tool 是否選對
Arguments 是否合法
Permission／Approval 是否正確
Result 是否正確解析
單一步驟是否違反安全或 Scope

Step 合法，不代表完整 Task 已完成。

Trajectory-level Evaluation

觀察：

Operation 的 Dependency 與順序
是否有重複 Call、無限 Loop 或無效探索
Failure 後是否使用正確 Recovery
是否繞過 Gate
Budget、Stop、Handoff 與 Approval 是否合理
是否遵守 Mandatory Path Invariant

Trajectory Eval 不應要求 Agent 複製一條唯一 Golden Path。兩條不同路徑都可能安全、有效而且成本相近。應固定的是：

不可繞過的 Gate
必須先於 Side Effect 的 Approval
Required Evidence
禁止的 Operation
Maximum Budget／Deadline
需要維持的 Causal Ordering

其餘可接受路徑可以用 Equivalence Class、Partial Order 或 Outcome Constraint 表示。

Task-level Evaluation

觀察：

Completion Contract 是否滿足
External Outcome 是否正確
Side Effect 是否唯一且對準正確 Tenant
Required Artifact 是否存在
使用者／業務目標是否達成
是否有阻斷 Regression

Task Outcome 正確，不代表 Trajectory 安全；每一步都合法，也不代表 Contract 沒有漏掉需求。

Release Claim 不是三層分數相加。它要根據 Task Distribution、Blocking Criteria、Segment、Variance 與 Trial Validity 說明：這個版本在哪些條件下具備什麼程度的 Evidence。

Tool Evaluation 不只算 Tool Call 成功率

Tool Quality 可以拆成五層：

層級	主要問題
Definition	名稱、Description、Schema、Output 與 Error 是否清楚？
Selection	Agent 是否選對 Tool，是否誤選高風險 Tool？
Argument	Entity、Resource、Scope 與參數是否正確？
Execution	Timeout、Retry、Idempotency、Latency 與 Side Effect 是否正確？
Outcome	Tool 是否真的推動 Task 完成，Evidence 是否足夠？

一個 Tool 的 API 回傳 200，不代表 Tool Integration 成功。它可能查錯 Tenant、使用錯誤 Currency、重複執行，或回傳大量 Raw Payload 把 Context 塞滿。

這也是 Tool Definition 改動需要 Eval 的原因。名稱、Description、Schema 與 Error Contract 都會改變 Model 的選擇與修復行為。

Audit 要從「有檔案」一路走到「有行為改善」

Harness Audit 可以分成四層：

Level 1：Structural

Required artifact 是否存在
Schema 是否有效
Link、Command 與 Reference 是否可解析
Policy 是否有明顯衝突

Level 2：Executable

Clean Setup 是否能跑
Health Check 與 Verification Command 是否有效
State Transition、Resume、Cancel 與 Handoff 是否可執行

Level 3：Behavioral

Task Success 是否提高
False Completion 是否下降
Tool Misuse、Scope Violation 與 Rework 是否減少
Cost、Latency 與 Human Intervention 是否可接受

Level 4：Ablation and Longitudinal

移除一個 Harness Component 後，結果是否真的變差
Model Upgrade 後，舊控制是否仍有價值
Maintenance Burden、Incident Rate 與 Drift 如何變化

Structural Green 最容易製造假安心。Repository 裡有 AGENTS.md、evals/ 與 quality-gates.yaml，只能證明檔案存在。它們是否被讀取、能否執行、是否改善行為，仍要往後三層驗證。

Eval Dataset 也有生命週期

Evaluation Dataset 不是一包永遠正確的題目。

來源可以包括：

Curated happy path
Edge case
Production incident
User-reported failure
Adversarial case
Synthetic variant
經同意與去識別化的 Production sample

每個 Case 應保留 Metadata：

Task class
Risk／Severity
Source 與 Provenance
Expected invariant
Allowed／Forbidden trajectory
Deterministic checks
Human label
Privacy classification
Introduced／retired version

Dataset 至少要分：

Development set
Release gate set
Hidden holdout
Adversarial set
Production shadow sample

如果 Agent 和開發者每天看同一批 Release Case，分數會逐漸變成對題庫的熟悉度，而不是對真實分布的能力。

還要處理 Dataset Decay：產品流程變了、Tool Retire、Policy 更新、Environment 失效、答案洩漏到可搜尋來源，Case 都可能失去測量價值。Anthropic 在 BrowseComp 的研究中發現公開答案可能透過 Web Search 進入 Agent Context，污染結果；這提醒我們，Agent Eval 的資料邊界比靜態問答更難守。²

Case 也需要狀態，例如 active、quarantined、retired。來源或 Ground Truth 失去 Authority 時，先隔離 Case，再決定修復或退役，不能讓過期題目繼續安靜地影響 Release Gate。

OpenAI 在 2026 年的 Agent Improvement Loop 範例中，也把 Trace、人類與模型回饋、可重跑 Eval，以及後續 Harness Change 串成一條循環。這類流程的關鍵是保留 Evidence 與 Review Boundary，不是讓模型自動把自己的建議部署到 Production。³

Evaluator 也需要被評估

Grader 不是天然正確。

要校準：

與人類 Label 的 Agreement
False Approval
Over-rejection
Edge Case
不同語言與 Task Class
對輸出格式、長度與表面風格的 Bias
重複 Trial 的 Variance

還應量測 Criterion-level Confusion Matrix、Judge 順序偏誤、Verbose-output Bias、Pairwise Position Bias，以及不同 Evidence Packaging 對 Verdict 的影響。Evaluator 不確定時，可以輸出 abstain 或 needs_adjudication，而不是硬擠出一個漂亮分數。

Code-based Grader 通常最快、最穩定，但只能檢查可形式化條件；Human Grading 靈活但昂貴；LLM Grader 可擴展語意判斷，前提是 Rubric 清楚、經過校準，而且不被當成唯一 Authority。Anthropic 與 OpenAI 的 Eval 指南都把清楚 Success Criteria、Task-specific Case、Automated Scoring 與 Human Calibration 放在核心位置。⁴⁵

Evaluator 的經濟性也要算：

Expected value of extra evaluation
> evaluator cost + delay + false-positive rework

高風險付款流程值得多層驗證；低風險格式轉換若每次都啟動三個 Judge、Browser Agent 與 Human Review，系統可能在品質上很虔誠，在成本上很有宗教儀式感。

比較 Model 時，不能把 Harness 當成透明空氣

Agent 評估測到的是：

Model × Harness × Task × Environment × Budget

OpenAI 對第三方評估的建議特別指出，Harness、Tool、Context、Budget 與 Elicitation Method 都會改變 Agentic Result；報告必須說明自己在測 Capability Ceiling、Controlled Comparison，還是 Safeguard Robustness。⁶

Anthropic 也量到 Agentic Coding Eval 的 Infrastructure Configuration 可以造成數個百分點差異，甚至超過排行榜前幾名之間的差距。不同 CPU／Memory Enforcement、Timeout 與 Sandbox 行為，代表系統沒有在接受同一場考試。⁷

因此比較時要固定或揭露：

比較設計還要盡量使用 Paired Case、隨機化 Trial Order、相同 Environment Snapshot 與一致的 Invalid-trial Policy。Infrastructure Failure、Grader Failure 與 Agent Failure 要分開報告，否則排行榜可能只是在比較誰遇到比較少的壞容器。

Model identifier 與 Reasoning／Inference profile
Prompt／Agent config version
Tool schema、version 與 Permission
Context／Compaction policy
Dataset snapshot
Grader 與 scoring code
Max turns、timeout、retry 與 concurrency
CPU、Memory、Network、Browser 與 Retrieval availability
Cost、Latency 與 Trial count

Native Harness 是 Baseline，不是宇宙常數

某個 Model 可能對原生 Tool Semantics、Editing Primitive、Parallel Calls 或 Compaction Policy 有較強適配。換成另一套 Harness 後，Tool Argument Error、Repair Turn 或 Early Stop 可能增加。

合理的 Compatibility Matrix 至少比較：

Native model + native harness
Candidate model + candidate harness
Reference model + candidate harness
Same model + tool variant
Same model + context／budget variant

這樣才能分辨：變差的是 Model、Harness、Compatibility，還是 Environment。

Reproducibility 需要 Run Manifest

每次 Eval Run 應產生可追溯 Manifest，例如：

{
  "run_id": "eval_2026_07_08_014",
  "model": "model-version-pinned",
  "agent_config": "refund-agent@3.4.1",
  "tool_catalog": "refund-tools@2.2.0",
  "policy": "refund-policy@7",
  "dataset": "refund-suite@2026-07-01",
  "contract": "refund-completion@3",
  "grader": "refund-grader@1.8.2",
  "evidence_schema": "quality-evidence@2",
  "max_turns": 24,
  "timeout_seconds": 600,
  "trials_per_case": 5,
  "trial_order_seed": 417,
  "environment_image": "sha256:...",
  "infra_validity_policy": "eval-validity@2"
}

這段資料不能保證任何人都能得到完全相同的 Model Output，因為生成仍有變異；它能讓團隊重建測試條件、理解差異來源，並避免只用 Model 名稱解釋所有變化。

Release Gate 也不應只看平均分。至少要看：

Blocking Case 是否通過
Severe Regression
Variance
Timeout／Abstention／Infra Failure
Unsafe Action Rate
Cost 與 Latency
Known Limitation
Validity Check

平均 92 分可能藏著付款任務 100% 通過、跨 Tenant 任務 0% 通過。平均值很平靜，事故半徑並不平靜。

用退款批准案例走一次完整證據鏈

回到開頭的退款批准功能。

1. Contract

Sprint Contract 定義金額門檻、State Transition、Audit Event、Scope、Required Evidence 與 Completion Authority。

2. Pre-execution Gate

Agent 嘗試修改 Provider Adapter，被 Scope Gate 拒絕；Diagnostic 指向允許的 Domain Service Boundary。

3. Implementation

Agent 修改 State Machine、API 與 Migration，並新增 Test。

4. Verification Portfolio

Schema／Type／Lint 通過
Unit Test 驗證 State Transition
Integration Test 驗證 Database 與 Audit Event
E2E 模擬 Supervisor Approval
Operation Record 驗證 Refund 只執行一次
Diff Gate 確認沒有無關檔案

5. Independent Verifier

Verifier 直接讀 Test Report、Database State、Changed Files 與 Operation Record，不只接受 Agent Summary。

6. Runtime Outcome

Run 只有在 Mandatory Evidence 齊全後，才從 verifying 進入 passed。

7. Evaluation Harness

同一版本在多個 Case 上執行多次 Trial：

正常批准
拒絕批准
重複 Callback
Worker Crash
Cross-tenant ID
Migration from previous version

8. Release Gate

Blocking Case 全通過，沒有 Severe Regression，Cost 與 Latency 在範圍內，才允許 Promotion。

這條鏈仍不能證明 Production 永遠不出錯。它能把「Agent 說完成」提升成一組可重播、可比較、可反駁的證據。

看一套 Quality 與 Evaluation Harness，可以先問十六個問題

Task 是否有明確 Goal、Scope、Constraint、Evidence 與 Completion Authority？
高階 Spec 是否被轉成可驗收的 Sprint Contract？
哪些規則在執行前由 Gate 強制？
哪些 Architecture Constraint 已機械化？
Failure Diagnostic 是否包含 Location、Invariant、Evidence 與 Repair Boundary？
Generator 是否能直接把自己的 Run 標成 passed？
Canonical Quality Authority 是誰？
Required Evidence Portfolio 是否對應真正的 Proof Obligation？
Rubric 是否要求 Evidence，而不只是一個 Score？
Grade-and-Revise 是否有 Budget、Stop Rule 與 Escalation？
Eval 是否同時看 Step、Trajectory 與 Task Outcome？
Tool Eval 是否涵蓋 Definition、Selection、Argument、Execution 與 Outcome？
Dataset 是否有 Provenance、Split、Version、Privacy 與 Retirement Policy？
Evaluator 是否用 Human Label 與 Edge Case 校準？
Model Comparison 是否固定或揭露 Harness、Tool、Budget、Environment 與 Grader？
每次 Release Decision 是否能追溯到 Run Manifest、Raw Evidence 與 Validity Check？

若系統只有一個「Agent finished」Event，後面接一個總分 Dashboard，品質鏈中間仍有一大片黑箱。

理論轉實作：Part 10 檢查表

Contract and gate

每個高價值 Task 有 Goal、Scope、Constraint、Required Output、Acceptance Criteria、Evidence、Failure 與 Stop Condition。
Sprint Contract 有版本，且執行中的 Run 綁定固定版本。
Pre-execution Gate 檢查 Schema、Scope、Permission、Precondition、Risk 與 Budget。
Architecture Rule 中適合機械化的部分已落到 Lint、Test、CI、Policy 或 Runtime Assertion。
Diagnostic 回傳 Rule ID、Location、Observed Evidence、Expected Invariant 與 Repair Boundary。

Verification authority

Generator 不能直接寫入 passed。
Canonical Quality Authority、Mandatory Criterion 與 Completion Decision Record 已定義。
Verifier 讀取外部 Evidence，不只讀 Generator Summary。
Verification Portfolio 依 Side Effect、Reversibility、Tenant、External Authority 與業務風險選擇。
Scope Violation 不會因測試通過而被忽略。
Tool Request／Result／Cancel／Unknown Outcome 可完整關聯。

Rubric and revision

Rubric Criterion 具備 Version、Evidence Reference、Evidence Authority、Uncertainty、Blocking 與 Repair Guidance。
Grade-and-Revise 有 Max Iterations、Cost／Time Budget、Plateau Detection 與 Escalation。
LLM Judge 已用人類 Label、反例與 Edge Case 校準。
高風險 Criterion 優先使用 Deterministic Check、External State 或 Human Authority。

Evaluation design

Runtime Completion 與 Release Evaluation 的責任、State、Authority 與 Environment 已分離。
Trial Validity 將 Agent Failure、Infrastructure Failure、Grader Failure、Stale Case 與 Contamination 分開。
Evaluation 同時覆蓋 Step、Trajectory 與 Task Outcome。
Tool Eval 涵蓋 Definition、Selection、Argument、Execution 與 Outcome。
Audit 不只檢查 Artifact 存在，也包含 Executable、Behavioral 與必要的 Ablation。
Eval Dataset 有 Provenance、Metadata、Split、Version、Privacy、Contamination、Quarantine、Decay 與 Retirement Policy。
Incident、User Correction 與 Adversarial Failure 能回流成新 Case。

Compatibility and release

Model、Harness、Tool、Policy、Context、Budget、Environment 與 Grader 版本已 Pin 或揭露。
每個 Eval Run 產生 Run Manifest，保存 Transcript、Outcome 與 Grader Evidence。
多 Trial 結果報告 Variance、Timeout、Abstention 與 Infra Failure，不只報平均分。
Release Gate 分開檢查 Blocking Case、Severe Regression、安全、成本與延遲。
Evaluation Report 明確說明它支持的是 Capability、Controlled Comparison，還是 Safeguard Claim。

Part 11 會接著處理這些 Evidence 怎麼被產生、關聯與保存。沒有 Trace、Metric、Event、Replay 與版本關聯，Quality Gate 和 Evaluation 只能看到零散截圖；有了完整 Observability，團隊才有機會知道失敗發生在哪一個 Turn、哪一個 Tool、哪一個 Worker，以及哪一版 Harness。

References

Anthropic, Demystifying evals for AI agents, 9 January 2026. ↩
Anthropic, Eval awareness in Claude Opus 4.6’s BrowseComp performance, 6 March 2026. ↩
OpenAI, Build an Agent Improvement Loop with Traces, Evals, and Codex, 12 May 2026. ↩
Anthropic, Define success criteria and build evaluations, accessed 8 July 2026. ↩
OpenAI, Evaluation best practices, accessed 8 July 2026. The design guidance remains useful, although OpenAI states that existing hosted evals become read-only on 31 October 2026 and the Evals dashboard and API are scheduled to shut down on 30 November 2026. ↩
OpenAI, A shared playbook for trustworthy third party evaluations, 29 May 2026. ↩
Anthropic, Quantifying infrastructure noise in agentic coding evals, 5 February 2026. ↩