文章类型技术长文 所属专栏Agent 观测 预计阅读59 分钟 文档状态已发布

第 7 篇：Agent 评测体系设计——从任务、轨迹、环境结果到回归门禁

围绕 Task、Trial、Trace、Artifact、Environment Outcome 与 Grader，建立五层评测、隔离环境、故障恢复统计和发布回归门禁。

开始阅读全文11877 字 · 59 分钟 查看系列目录Agent 观测

作者Jupiter 发布日期2026/08/06 最近更新2026/08/06 正文规模11877 字

关键词 AgentEvaluation可观测性Grader回归测试

栏目 AgentObservability；专栏 Agent 观测；标签 Agent、Evaluation、可观测性、Grader、回归测试

文章目标#

Agent 评测不能被简化为“给最终回答打一个分”。

普通生成模型通常可以把一次评测表示为：

1
Input
2
→ Model Output
3
→ Reference / Judge
4
→ Score

Agent 的一次运行则更接近：

1
Task Contract
2
→ 多轮模型调用
3
→ Tool Call
4
→ Environment Mutation
5
→ Error / Retry / Recovery
6
→ Final Response
7
→ Environment Outcome

它具有五个显著特征：

执行链很长：错误可能在早期发生，却在最终阶段才暴露；
会改变环境：文件、数据库、浏览器、工单和外部服务可能被真实修改；
路径不唯一：同一个任务可能有多条正确轨迹；
结果具有随机性：同一配置多次运行可能得到不同结果；
模型不是唯一变量：Prompt、Tool Schema、Agent Runtime、Retriever、权限、网络和评测环境都会改变结果。

因此，一套可执行的 Agent 评测体系必须同时回答：

1
任务是否完成
2
工具是否选对
3
参数是否正确
4
轨迹是否有效
5
环境副作用是否符合约束
6
故障后是否安全恢复
7
成本和延迟是否可接受
8
多次运行是否稳定
9
新版本是否允许发布

本文继续使用一个 Coding Agent 任务作为贯穿案例：

用户要求 Agent 修复订单模块中的折扣计算 Bug；只允许修改 orders/ 和 tests/orders/，不得修改 payments/；Agent 需要搜索仓库、修改代码、运行测试，并提交最终 Diff。

本文不再单独展开 Evaluation Harness 的编码教程，而是把 Harness 必须实现的能力沉淀为系统设计原则：

Task Contract；
Trial 隔离；
环境恢复；
Tool 与网络 Fixture；
分层 Grader；
故障注入；
多 Trial 统计；
Evaluation Suite；
CI、Shadow 和 Canary 门禁。

Anthropic 将 Agent Eval 的基本对象概括为 Task、Trial、Transcript、Outcome、Grader、Harness 和 Suite，并强调 Agent 的自述与环境真实状态可能不一致；同一个 Task 需要多个 Trial 才能得到稳定结论。¹ Inspect AI 的 Task、Dataset、Agent/Solver、Sandbox、Scorer、Limit、Checkpoint 和 Eval Set 等接口，则提供了这些概念在工程系统中的一套公开实现参考。²³

1. Agent 评测的基本对象#

Agent 评测对象与证据链

Agent 评测最常见的问题，不是缺少指标，而是对象边界混乱。

例如团队可能把以下内容都称为“一个 Case”：

1
用户任务
2
一次模型调用
3
一次完整 Agent Run
4
一条生产 Trace
5
一份环境快照
6
一个测试脚本

这些对象粒度不同，必须分开建模。

1.1 Task#

Task 是一个具有明确输入、约束、初始环境和成功标准的评测问题。

一个 Task 不是一句 Prompt。
一个完整 Task 至少应包含：

1
task_id
2
task_version
3
user_goal
4
initial_environment
5
available_tools
6
permission_policy
7
network_policy
8
success_criteria
9
forbidden_actions
10
budgets
11
acceptable_solution_paths
12
grader_configuration

Coding Agent 示例：

1
task:
2
  id: fix-discount-zero-quantity
3
  version: 3
4
  user_goal: >
5
    修复 quantity=0 时折扣计算错误，
6
    并确保订单折扣相关测试全部通过。
7

8
  visible_constraints:
9
    allowed_paths:
10
      - orders/**
11
      - tests/orders/**
12
    forbidden_paths:
13
      - payments/**
14

15
  initial_environment:
16
    repository_revision: abc123
17
    workspace_snapshot: ws_discount_v3
18
    container_image: coding-eval:2026-08-01

Task 是所有 Trial 共享的逻辑定义。

Task 必须验证可解#

每个 Task 都应有至少一个 Reference Solution 或 Human Baseline，证明：

1
初始环境可启动
2
任务说明足够明确
3
工具可以完成任务
4
所有 Grader 能接受正确答案
5
预算合理

Anthropic 建议为每个 Task 准备可通过全部 Grader 的 Reference Solution；当大量 Trial 都是 0% 时，应首先检查任务或 Grader 是否损坏，而不是直接断言 Agent 没有能力。¹

1.2 Trial#

Trial 是某个 Agent 配置对某个 Task 的一次独立尝试。

1
Task
2
├── Trial 1
3
├── Trial 2
4
├── Trial 3
5
└── Trial k

Trial 必须记录：

1
trial_id
2
task_id
3
agent_version
4
model
5
prompt_version
6
tool_schema_version
7
environment_revision
8
random_seed
9
start_time
10
end_time
11
trace_id
12
outcome
13
scores
14
cost
15
latency

Trial 与 Run 的关系#

在评测平台中，两者可以这样区分：

1
Experiment Run：
2
一次完整实验，例如 Agent v3.2 在 Regression Suite 上运行
3

4
Trial：
5
某个 Task 在这次 Experiment 中的一次尝试

独立不等于“只换随机数”#

Trial 独立要求：

恢复相同初始环境；
清理前一个 Trial 的文件和数据库修改；
使用独立缓存或明确缓存策略；
不继承前一个 Trial 的记忆；
不共享未清空的 Tool Result；
不复用已经被改变的外部业务对象。

如果 Trial 2 看到 Trial 1 写入的数据，它们就不再独立。

1.3 Transcript#

Transcript 是一次 Trial 的完整时序记录。

它可以包含：

1
用户消息
2
System Instruction 的版本引用
3
模型输入和输出
4
Tool Call
5
Tool Result
6
人工审批
7
错误
8
重试
9
环境事件
10
最终回答

Transcript 更像“发生过什么”的顺序日志。

1
[
2
  {
3
    "type": "user_message",
4
    "content": "修复折扣错误"
5
  },
6
  {
7
    "type": "assistant_tool_call",
8
    "tool": "search_code",
9
    "arguments": {
10
      "query": "calculate_discount"
11
    }
12
  },
13
  {
14
    "type": "tool_result",
15
    "tool_call_id": "tool_01",
16
    "result_ref": "artifact://search-result-01"
17
  }
18
]

Transcript 不应假定包含隐藏推理#

可评测证据应以：

模型可见输入；
对外输出；
Tool Call；
Tool Result；
结构化决策；
环境状态；

为主。

如果某个框架公开 Reasoning Summary，可以作为 Transcript 的一个字段；但一套评测体系不应依赖不可获得的隐藏 Chain-of-Thought。

Transcript 与 Artifact 分离#

过大的对象：

1
完整仓库文件
2
数万行 Shell Output
3
浏览器录像
4
数据库 Dump

不应直接内嵌 Transcript，而应保存 Artifact Reference。

1.4 Trace 与 Trajectory#

这两个概念经常混用，但用途不同。

Trace#

Trace 是带有 Parent-child、时间、错误和属性的运行结构。

1
agent
2
├── generation
3
├── retriever
4
├── tool
5
│   └── shell process
6
├── generation
7
└── outcome verifier

Trace 适合回答：

1
哪一步触发下一步
2
哪里最慢
3
哪次调用发生错误
4
Retry 属于哪个逻辑操作
5
子 Agent 如何汇合

Trajectory#

Trajectory 是为了行为评测而构造的动作—观察序列。

1
state_0
2
→ action_1
3
→ observation_1
4
→ action_2
5
→ observation_2
6
→ ...
7
→ terminal_state

它可以是 Trace 的规范化投影：

1
[
2
  {
3
    "step": 1,
4
    "action": {
5
      "type": "tool_call",
6
      "tool": "search_code"
7
    },
8
    "observation": {
9
      "candidate_count": 12
10
    }
11
  },
12
  {
13
    "step": 2,
14
    "action": {
15
      "type": "tool_call",
16
      "tool": "read_file"
17
    },
18
    "observation": {
19
      "path": "orders/discount.py"
20
    }
21
  }
22
]

Trajectory 适合评价：

工具选择；
参数；
顺序；
重复；
无效步骤；
是否违反策略；
是否在得到足够证据后停止。

TRAJECT-Bench 等工作说明，仅评价最终结果会遗漏工具选择、参数正确性和依赖顺序等关键能力。⁴

1.5 Artifact#

Artifact 是 Trial 执行过程中产生或读取的证据对象。

常见 Artifact：

1
Git Diff
2
修改后的文件
3
测试报告
4
Shell stdout / stderr
5
浏览器截图
6
DOM Snapshot
7
数据库快照
8
网络响应
9
检索候选清单
10
最终生成文档

Artifact 至少需要：

1
artifact_id
2
type
3
content_hash
4
uri
5
created_at
6
producer_observation_id
7
environment_revision
8
data_classification

Artifact 不等于 Outcome#

例如：

1
Agent 生成了一个 Patch

只说明 Artifact 存在，不说明：

1
Patch 能应用
2
测试能通过
3
没有副作用

Artifact 是 Outcome Grader 的证据输入。

1.6 Environment Outcome#

Environment Outcome 是 Trial 结束时环境的真实状态。

这是 Agent 评测中最关键的对象。

对于客服 Agent：

1
数据库中订单是否真的取消
2
退款金额是否正确
3
是否违反业务政策

对于 Coding Agent：

1
目标测试是否通过
2
原有测试是否退化
3
修改文件是否在允许范围
4
是否新增安全问题

对于 Browser Agent：

1
表单是否提交
2
订单是否创建
3
收件人是否正确
4
是否发生重复操作

τ-bench 通过比较对话结束时数据库状态与标注目标状态来判断 Agent 是否完成任务，并使用 pass^k 衡量多次运行的可靠性。⁵

Outcome 应有结构化 Schema#

1
{
2
  "task_status": "success",
3
  "assertions": {
4
    "target_tests_passed": true,
5
    "regression_tests_passed": true,
6
    "only_allowed_paths_changed": true,
7
    "unexpected_side_effects": false
8
  },
9
  "state_diff_ref": "artifact://state-diff-092",
10
  "verifier_version": "coding-outcome-v4"
11
}

Agent 的成功声明不是 Outcome#

1
Assistant:
2
“问题已修复，所有测试已通过。”

只是一条 Final Response。

真正的 Outcome 必须由环境独立验证。

1.7 Grader#

Grader 是对 Trial 某个方面做出判定的逻辑。

一个 Task 通常需要多个 Grader：

1
Outcome Grader
2
Tool Grader
3
Trajectory Grader
4
Safety Grader
5
Cost Grader
6
Response Grader

Grader 输出至少包含：

1
grader_name
2
grader_version
3
target_type
4
target_id
5
value
6
reason
7
evidence_refs
8
status

1
{
2
  "grader_name": "forbidden-path-check",
3
  "grader_version": "2.1.0",
4
  "target_type": "trial",
5
  "target_id": "trial_003",
6
  "value": 0,
7
  "reason": "payments/service.py was modified",
8
  "evidence_refs": [
9
    "artifact://git-diff-final"
10
  ]
11
}

Grader 也会失败#

必须区分：

1
agent_failed
2
grader_failed
3
environment_failed

如果测试容器无法启动，这次 Trial 不能直接计为 Agent Failure。

状态建议：

1
valid_score
2
grader_error
3
environment_invalid
4
insufficient_evidence
5
needs_human_review

1.8 Evaluation Suite#

Evaluation Suite 是围绕某个目标组织的一组 Task。

1
Coding Agent Suite
2
├── Capability
3
├── Regression
4
├── Safety
5
├── Recovery
6
└── Production Long-tail

Suite 需要自己的 Manifest：

1
suite_id
2
suite_version
3
task_ids
4
task_weights
5
strata
6
required_trials
7
grader_versions
8
environment_versions
9
release_gate_policy

Suite 不是把所有 Task 放进一个目录。
它必须说明：

测量什么；
不测量什么；
Task 分布；
各层用途；
如何解释结果；
何时阻止发布。

2. 为什么不能只评价最终回答#

2.1 Agent 声称成功但环境没有变化#

最典型的失败：

1
Agent:
2
“已经成功创建退款。”
3

4
数据库：
5
没有退款记录。

或：

1
Agent:
2
“所有测试已经通过。”
3

4
实际：
5
测试根本没有执行。

最终回答评测只能判断：

1
表达是否像成功

不能判断：

1
环境是否成功

这种误差会让模型学会“说得像完成”，而不是“真正完成”。

2.2 最终结果正确但执行了危险动作#

Agent 最终可能得到正确结果，但过程违反约束。

示例：

1
最终测试通过
2
但 Agent：
3
- 修改了 payments/
4
- 删除了安全校验
5
- 使用了生产凭证
6
- 向外部网络上传了源码

如果只看最终结果，这类 Trial 会被错误标为成功。

因此应将：

1
Outcome Correctness
2
Safety Compliance

作为两个独立维度。

严重安全违规通常应成为硬门禁：

1
unsafe_side_effect = true
2
→ Trial Final Pass = false

不能用更高的回答质量或更低的成本抵消。

2.3 错误轨迹偶然得到正确答案#

Agent 可能：

1
读取错误文件
2
猜测根因
3
执行无关修改
4
碰巧通过不完整测试

最终分数看起来正确，但轨迹不可复用、不可解释，也可能在环境稍变时失败。

最近针对 Coding Benchmark 的研究进一步指出，测试不足可能让错误 Patch 被判通过；UTBoost 报告了原测试未覆盖而错误标记为成功的 Patch，说明“测试通过”本身也依赖 Grader 的完备性。⁶

因此需要同时评估：

1
最终 Outcome
2
轨迹合理性
3
测试覆盖
4
副作用

2.4 完成任务但成本和延迟不可接受#

两个 Agent 都完成任务：

1
Agent A：
2
8 次模型调用
3
12 次 Tool Call
4
耗时 40 秒
5
成本 0.18 美元
6

7
Agent B：
8
35 次模型调用
9
109 次 Tool Call
10
耗时 11 分钟
11
成本 4.90 美元

如果只看 Success，它们完全相同。

生产系统还要评价：

1
End-to-end Latency
2
Token
3
Tool Cost
4
Retry Amplification
5
Human Wait
6
Cost per Successful Task

成本不一定直接进入“正确性”分数，但应成为发布门禁或 Pareto 比较维度。

2.5 失败来自系统组件而不是模型能力#

Agent 失败可能来自：

1
模型决策
2
Prompt
3
Tool Schema
4
Retriever
5
Memory
6
网络
7
MCP
8
Sandbox
9
权限
10
环境初始化
11
Grader
12
Harness

例如：

1
Agent 选择了正确工具
2
但工具服务返回 500

不能直接计为模型 Tool Selection Failure。

建议每个失败先归因：

1
MODEL
2
AGENT_RUNTIME
3
TOOL
4
ENVIRONMENT
5
INFRASTRUCTURE
6
GRADER
7
TASK_SPEC
8
UNKNOWN

评测报告应同时给出：

1
Raw Failure Rate
2
Valid Agent Failure Rate
3
Infrastructure Invalid Rate
4
Grader Invalid Rate

否则基础设施故障会被误认为模型回归。

3. 五层评测结构#

五层评测结构与组合式 Grader

完整 Agent Evaluation 应由五层组成。

1
flowchart TB
2
    A[Final Response] --> B[Tool Call]
3
    B --> C[Step]
4
    C --> D[Trajectory]
5
    D --> E[Environment Outcome]
6

7
    E --> F{Hard Gates}
8
    F -->|通过| G[综合质量与成本分析]
9
    F -->|失败| H[Trial Fail]

五层不是简单加权平均。

推荐输出一个 Score Vector：

\mathbf{S} = (s_{\text{response}}, s_{\text{tool}}, s_{\text{step}}, s_{\text{trajectory}}, s_{\text{outcome}})

再单独应用：

1
Safety Gate
2
Forbidden Action Gate
3
Environment Integrity Gate

3.1 Final Response Evaluation#

评价最终用户可见输出。

维度：

1
是否回答用户问题
2
是否准确描述真实 Outcome
3
是否包含必要说明
4
是否隐瞒失败
5
是否引用有效证据
6
格式是否符合要求

Coding Agent 示例：

1
应说明：
2
- 修改了什么
3
- 测试结果
4
- 最终 Diff
5
- 未修改禁止目录

Final Response 不能自行成为 Ground Truth。

Response Consistency#

应检查：

1
Final Response
2
vs
3
Environment Outcome

例如：

1
claimed_tests_passed = true
2
actual_tests_passed = false

形成：

1
claim_outcome_mismatch = true

3.2 Tool Call Evaluation#

评价单次工具选择和调用。

维度：

1
工具是否适合当前目标
2
Tool Arguments 是否合法
3
是否满足前置条件
4
权限是否允许
5
是否正确处理 Result
6
是否安全重试

示例：

1
{
2
  "tool": "edit_file",
3
  "arguments": {
4
    "path": "payments/service.py"
5
  }
6
}

Schema 可能合法，但违反 Task Contract。

因此 Tool Call Grader 应同时检查：

1
Schema
2
Business Rule
3
Permission
4
Current State

3.3 Step Evaluation#

Step 是一次局部决策或动作。

评价：

1
当前状态下该 Step 是否合理
2
是否推进任务
3
是否使用已有证据
4
是否引入新风险
5
是否重复无效工作

Step-level 评测比 Tool-level 更宽。

例如：

1
Tool Call 合法
2
但 Agent 在已经读取文件后又重复搜索五次

Tool 本身没有错，Step 的信息增益却接近零。

可以定义：

\text{StepUtility} = \Delta \text{TaskProgress} - \lambda \cdot \text{Cost} - \mu \cdot \text{Risk}

实际不一定要精确计算该公式，但需要明确：

1
动作是否带来可观察进展

3.4 Trajectory Evaluation#

Trajectory 评价整条动作—观察序列。

核心问题：

1
工具顺序是否满足依赖
2
是否存在循环
3
是否遗漏必要步骤
4
是否进行了不必要动作
5
是否在错误后正确恢复
6
是否过早结束

常见指标：

1
trajectory_length
2
tool_call_count
3
unique_tool_count
4
repeated_action_count
5
loop_count
6
invalid_transition_count
7
required_step_recall
8
forbidden_step_count

不要求唯一标准轨迹#

错误设计：

1
只有与 Reference Tool Sequence 完全一致才算正确。

Agent 可能有多条有效路径。

更好的做法：

1
检查必要依赖
2
检查禁止动作
3
检查最终 Outcome
4
允许多种合法顺序

3.5 Environment Outcome Evaluation#

这是最高优先级的结果层。

评价：

1
目标状态是否达到
2
环境是否保持一致
3
禁止副作用是否发生
4
是否可以验证和复现

Coding Agent：

1
Fail-to-pass Tests
2
Pass-to-pass Tests
3
Build
4
Static Analysis
5
Changed Paths
6
Security Scan
7
Git Diff

SWE-bench 使用容器化执行环境来复现代码问题并运行测试；其公开 Harness 也强调 Docker 化以提高可重复性。⁷⁸

Outcome Grader 应接受多种正确实现#

DeepSWE 采用针对请求功能手写的 Verifier，而不是只继承某个历史 PR 的测试，以减少“正确替代方案被拒绝”或“不完整方案被通过”的问题。⁹

这说明 Outcome Grader 的目标是：

1
验证用户要求的性质

而不是：

1
验证是否复制 Reference Patch

4. Task Contract#

Task Contract 与隔离评测环境

Task Contract 是评测系统的核心合同。

它必须同时约束：

1
Agent 看到什么
2
环境如何初始化
3
哪些动作允许
4
哪些动作禁止
5
怎样判断成功
6
预算是多少
7
哪些数据只能给 Grader

4.1 用户目标#

用户目标应描述：

1
要完成什么
2
业务意图是什么
3
哪些条件必须满足

避免：

1
“请修好这个问题。”

除非产品真实场景就是这种模糊请求，并且评测目标是 Agent 的澄清能力。

目标和实现分开#

好的 Task：

1
当 quantity=0 时返回零折扣，
2
且其他折扣逻辑不变。

不应强制：

1
必须在第 42 行添加 if。

除非任务就是测试特定实现能力。

4.2 初始环境#

初始环境必须版本化：

1
container_image
2
repository_revision
3
workspace_snapshot
4
database_snapshot
5
browser_profile
6
current_time
7
locale
8
timezone
9
seed

示例：

1
initial_environment:
2
  image: coding-agent-eval@sha256:...
3
  repository:
4
    url: private://orders-service
5
    commit: abc123
6
  workspace:
7
    dirty: false
8
  clock:
9
    mode: fixed
10
    instant: 2026-08-01T00:00:00Z
11
  locale: zh-CN
12
  timezone: Asia/Tokyo

没有环境版本，评测结果无法比较。

4.3 可用工具#

工具定义需要固定：

1
tool_name
2
schema_version
3
description_hash
4
implementation_version
5
side_effect_class
6
timeout

Task Contract 中应说明：

1
可用工具
2
每个工具权限
3
是否可并行
4
是否需要审批
5
是否允许网络

工具集合影响能力#

模型相同，但 Tool Description 变化，结果可能显著变化。

所以比较 Agent Version 时，应同时记录：

1
tool_schema_set_hash

4.4 权限和网络边界#

明确：

1
只读目录
2
可写目录
3
禁止目录
4
网络 Allowlist
5
MCP Server
6
外部 API
7
审批策略

示例：

1
permissions:
2
  filesystem:
3
    read:
4
      - /**
5
    write:
6
      - /workspace/orders/**
7
      - /workspace/tests/orders/**
8
    deny:
9
      - /workspace/payments/**
10
  network:
11
    default: deny
12
    allow:
13
      - github.example.internal
14
  approval:
15
    irreversible_actions: always

权限本身也是评测对象。

Agent 尝试越权并被 Sandbox 拒绝，仍然可能构成安全失败：

1
系统阻止了危险动作
2
但 Agent 安全决策能力不足

应同时记录：

1
attempted_forbidden_action
2
actual_forbidden_side_effect

4.5 成功标准#

成功标准应可执行。

1
测试通过
2
数据库状态匹配
3
页面状态匹配
4
文件存在
5
业务字段正确

推荐使用断言：

1
success_criteria:
2
  all:
3
    - tests:
4
        passed:
5
          - test_zero_quantity
6
          - test_discount_boundaries
7
    - filesystem:
8
        changed_paths_subset_of:
9
          - orders/**
10
          - tests/orders/**
11
    - outcome:
12
        final_response_matches_environment: true

不要只写：

1
“输出应当高质量。”

4.6 禁止行为#

禁止行为必须独立列出。

1
forbidden_actions:
2
  - modify: payments/**
3
  - network_request:
4
      not_in_allowlist: true
5
  - tool_call:
6
      tool: git_push
7
  - secret_access:
8
      path: /secrets/**
9
  - duplicate_side_effect:
10
      operation: create_pull_request

禁止行为分两类：

1
Attempted：
2
Agent 尝试执行，但被阻止
3

4
Committed：
5
副作用实际发生

二者都应评估，但严重度不同。

4.7 时间、Token、费用和工具调用预算#

预算必须是 Task Contract 的一部分，而不是事后观察。

1
budget:
2
  max_wall_time_seconds: 600
3
  max_model_calls: 20
4
  max_tool_calls: 60
5
  max_parallel_tools: 4
6
  max_input_tokens: 250000
7
  max_output_tokens: 40000
8
  max_cost_usd: 2.00

Inspect AI 支持在 Task、Sample 和 Agent 层设置时间、消息、Token 和 Cost Limit，并可配置并发与 Sandbox 数量。³

Budget Exhausted 的语义#

应区分：

1
Agent Failure：
2
在合理预算内无法完成
3

4
Budget Invalid：
5
预算本身不足以让 Reference Solution 完成

4.8 可接受的多种完成路径#

Task Contract 应表达不变量，而不是唯一动作脚本。

示例：

1
acceptable_paths:
2
  - name: direct-fix
3
    required:
4
      - inspect_target_file
5
      - modify_order_module
6
      - run_relevant_tests
7

8
  - name: test-first
9
    required:
10
      - add_regression_test
11
      - modify_order_module
12
      - run_relevant_tests

Trajectory Grader 可以检查：

1
是否满足任一合法路径

而不是：

1
是否等于 Reference Sequence

5. 评测环境设计原则#

5.1 每次 Trial 独立#

每个 Trial 必须获得独立：

1
文件系统
2
数据库
3
浏览器 Profile
4
端口
5
临时目录
6
缓存命名空间
7
Tool Execution Ledger
8
Session / Memory

不能共享的状态#

1
前一 Trial 的修改
2
前一 Trial 的测试缓存
3
前一 Trial 的模型 Conversation ID
4
前一 Trial 写入的长期记忆
5
前一 Trial 创建的 PR

可共享的只读资源#

1
容器镜像层
2
只读模型 Cache
3
不可变代码仓库镜像
4
只读依赖包

但必须确认共享不会泄漏答案或改变计费。

5.2 初始状态可恢复#

理想 Trial 生命周期：

1
Create Sandbox
2
→ Restore Snapshot
3
→ Validate Environment
4
→ Run Agent
5
→ Freeze Outcome
6
→ Grade
7
→ Destroy Sandbox

恢复方式：

1
Docker Image
2
VM Snapshot
3
Database Snapshot
4
Browser Storage Snapshot
5
Git Reset + Clean
6
Filesystem Overlay

Inspect 的 Checkpointing 可以保存 Agent State、Sandbox 文件系统和 Sample Event History，但不会保存任意进程内状态、运行中的工具或外部副作用。这种边界提示我们：Checkpoint 不是万能快照，外部写操作仍需单独 Ledger。¹⁰

5.3 文件、数据库和浏览器环境固定#

文件系统#

固定：

1
Git Commit
2
依赖 Lockfile
3
编译器
4
操作系统
5
文件权限
6
当前工作目录

数据库#

固定：

1
Schema Version
2
初始数据
3
事务隔离级别
4
时区
5
序列值
6
触发器

浏览器#

固定：

1
Browser Version
2
Viewport
3
Locale
4
Timezone
5
Cookie / Storage
6
Network Fixture
7
DOM 初始状态

Clock#

涉及：

1
促销
2
过期时间
3
时区
4
定时任务

时应使用 Fake Clock 或固定时间。

5.4 外部服务使用真实、Mock 或 Record-and-replay 的边界#

三种模式各有用途。

模式	优点	风险	适合
真实服务	真实协议和行为	不稳定、昂贵、有副作用	Release 前少量验证
Mock	快、确定、易注入故障	可能偏离真实实现	PR 和单元回归
Record-and-replay	保留真实响应形态	数据过期、请求匹配复杂	稳定集成回归

真实服务#

需要：

1
测试租户
2
测试账号
3
清理逻辑
4
费用上限
5
Rate Limit
6
网络隔离

Mock#

不要只返回永远成功。

应覆盖：

1
错误
2
延迟
3
分页
4
部分结果
5
Schema 变化
6
重复事件

Record-and-replay#

Fixture 应记录：

1
request_match_key
2
response
3
latency
4
headers
5
service_version
6
recorded_at
7
redaction_version

过旧 Fixture 可能让系统“在过去的世界中通过”。

5.5 不可逆操作隔离#

禁止在真实生产环境执行：

1
付款
2
真实邮件
3
真实部署
4
删除线上数据
5
创建真实用户
6
向外部地址上传文件

应使用：

1
Local Blockchain / Sandbox
2
Fake SMTP
3
Test Payment Processor
4
Disposable Project
5
Ephemeral Account
6
Transaction Rollback

OpenAI 的 EVMbench 将 Exploit Task 放在隔离的本地 Anvil 环境，通过事务重放和链上验证评分，并限制危险 RPC，而不是让 Agent 攻击真实链。¹¹

即使隔离，也要评价意图#

Agent 尝试执行危险行为，应记录：

1
attempted_unsafe_action

不能因为 Sandbox 阻止了副作用，就给安全满分。

5.6 环境泄漏和任务捷径检查#

Agent 可能通过不符合任务意图的捷径拿到答案。

常见泄漏：

1
Reference Patch 留在 Git History
2
隐藏测试文件可读
3
Expected Output 写在环境变量
4
Fixture 文件名透露答案
5
Grader API 可被 Agent 调用
6
生产 Trace 包含 Gold
7
网络可以搜索原 PR

检查策略：

1
删除 .git 或重写 History
2
隐藏 Grader-only 目录
3
禁止访问评测服务
4
网络默认关闭
5
随机化无关 ID
6
扫描 Reference String
7
红队任务环境

DeepSWE 通过原创、未回传上游的任务降低公开答案污染风险；SWE-bench-Live 则通过持续更新的新任务降低静态 Benchmark 过拟合和污染。⁹¹²

6. 核心评测维度#

6.1 任务完成度#

推荐分层：

1
0 = 未完成
2
1 = 部分完成
3
2 = 核心目标完成但有缺项
4
3 = 完整完成

但发布门禁通常还需要 Boolean：

1
verified_task_success

Partial Score 用于诊断和优化，Boolean 用于可靠性指标。

6.2 工具选择正确性#

评价：

1
正确工具是否被选择
2
不必要工具是否被调用
3
相似工具是否混淆
4
写工具是否在只读工具之前错误执行

指标：

\text{ToolSelectionPrecision} = \frac{\text{正确工具调用数}} {\text{全部工具调用数}}

\text{RequiredToolRecall} = \frac{\text{已调用的必要工具}} {\text{全部必要工具}}

对多路径 Task，“必要工具”应按合法路径定义，而不是全局固定列表。

6.3 Tool Arguments 正确性#

检查：

1
Schema
2
字段类型
3
必填参数
4
资源 ID
5
作用域
6
业务约束
7
当前状态

可以分成：

1
syntactic_validity
2
schema_validity
3
semantic_validity
4
policy_validity

示例：

1
path 合法
2
但修改了禁止目录

Schema Valid，Policy Invalid。

6.4 轨迹有效性#

评价：

1
是否有进展
2
是否重复
3
是否循环
4
是否漏掉关键步骤
5
是否正确利用 Tool Result
6
是否过早停止

可记录：

1
trajectory_length
2
no_progress_steps
3
duplicate_tool_fingerprints
4
dependency_violations
5
required_step_recall

轨迹越短不一定越好。
应比较：

1
有效步骤 / 总步骤

而不是盲目奖励最短路径。

6.5 环境副作用正确性#

评价：

1
预期写操作是否发生
2
额外写操作是否发生
3
写入对象是否正确
4
操作次数是否正确
5
是否可回滚

指标：

1
unexpected_mutation_count
2
duplicate_side_effect_count
3
forbidden_resource_count
4
rollback_success

对于安全敏感动作，应使用硬门禁。

6.6 故障恢复能力#

评价：

1
是否检测故障
2
是否采用正确恢复策略
3
是否尊重 Retry-After
4
是否超过 Retry Budget
5
是否重复副作用
6
是否能从 Checkpoint 继续

指标：

\text{RecoveryRate} = \frac{\text{发生可恢复故障后最终成功的 Trial}} {\text{发生可恢复故障的有效 Trial}}

同时记录：

1
attempt_count
2
recovery_latency
3
recovery_cost
4
duplicate_side_effect

6.7 安全和权限遵循#

至少评价：

1
Policy Compliance
2
Approval Compliance
3
Sandbox Compliance
4
Secret Handling
5
Network Egress
6
Prompt Injection Resistance
7
Cross-tenant Isolation

Agent-SafetyBench 等工作表明，工具和交互环境带来了超出普通模型问答的新型安全风险，安全评测应独立于普通任务成功率。¹³

Attempt 与 Outcome 分开#

1
Agent 尝试危险动作，但被阻止
2
Agent 成功执行危险动作

严重程度不同，但二者都不能忽略。

6.8 成本与延迟#

记录：

1
End-to-end Latency
2
Model Latency
3
Tool Latency
4
Human Wait
5
Retry Wait
6
Input Token
7
Output Token
8
Cache Token
9
Tool/API Cost
10
Total Cost

推荐指标：

\text{CostPerSuccess} = \frac{\sum_i \text{Cost}_i} {\sum_i \mathbb{1}[\text{Success}_i]}

\text{LatencyPerSuccess} = \frac{\sum_i \text{Latency}_i \cdot \mathbb{1}[\text{Success}_i]} {\sum_i \mathbb{1}[\text{Success}_i]}

成本必须包含失败 Trial，否则会掩盖浪费。

6.9 多次运行稳定性#

同一 Task 的 Trial 结果可能是：

1
成功
2
成功
3
失败
4
成功
5
失败

单次 Success 不能说明可靠。

稳定性应报告：

1
per-task success probability
2
pass@k
3
pass^k
4
variance
5
failure mode entropy
6
cost variance
7
latency variance

τ-bench 引入 pass^k，就是为了暴露 Agent“偶尔成功但不可靠”的问题。⁵

7. Grader 类型#

7.1 状态断言#

直接检查环境状态。

1
assert database.order.status == "cancelled"
2
assert filesystem.exists("output/report.pdf")
3
assert browser.url == "/confirmation"

状态断言通常是最可靠的 Grader，因为它直接评价 Outcome。

7.2 单元测试和集成测试#

Coding Agent 评测通常以执行测试为主：

1
Fail-to-pass
2
Pass-to-pass
3
Build
4
Integration Test
5
Security Test

Inspect Scorer 可以访问每个 Sample 的 Sandbox 文件和进程，用状态检查实现 Grader；SWE-bench 也使用容器化 Harness 执行 Repository Test。¹⁴⁸

测试不是天然完美#

必须验证：

1
Gold Patch 能通过
2
原始代码会失败
3
隐藏测试覆盖需求
4
正确替代方案不会被拒绝
5
不完整方案不会被误放行

7.3 规则 Grader#

适合确定性规则：

1
JSON Schema
2
字符串格式
3
字段完整性
4
路径 Allowlist
5
调用次数
6
Token Budget
7
引用存在性

优点：

快；
低成本；
可解释；
稳定。

缺点：

容易漏掉合法变体；
对开放任务不灵活；
规则可能被 Agent 利用。

7.4 Tool Sequence 检查#

Tool Sequence Grader 不应要求完整序列完全相等。

推荐检查：

1
必须先完成的依赖
2
禁止顺序
3
缺失必要步骤
4
重复执行
5
并行合法性

示例：

1
sequence_constraints:
2
  - before:
3
      tool: read_file
4
    after:
5
      tool: edit_file
6

7
  - before:
8
      tool: edit_file
9
    after:
10
      tool: run_tests
11

12
  - at_most:
13
      tool: create_pull_request
14
      count: 1

7.5 Forbidden Action 检查#

检查：

1
禁止工具
2
禁止路径
3
禁止网络
4
禁止资源
5
未经审批写入
6
重复不可逆动作

可以作为 Scanner、Rule Grader 或 Sandbox Event Grader。

Inspect 的 Scanner 可以在线或离线扫描 Transcript，也可以作为 Scorer 聚合 Reward Hacking、Eval Awareness 等行为。¹⁵

7.6 LLM-as-a-Judge#

适合：

1
回答帮助性
2
解释完整性
3
轨迹合理性
4
工具使用质量
5
政策解释
6
开放式结果

不适合替代：

1
数据库状态
2
文件是否存在
3
测试是否通过
4
金额是否精确
5
禁止目录是否被修改

AgentRewardBench 对 Web Agent Trajectory Judge 的研究发现，不同 LLM Judge 在不同 Benchmark 上表现不一致，且规则评测也可能低估真正成功的轨迹，说明自动 Judge 和规则都需要人工 Gold 校准。¹⁶

7.7 人类专家评分#

适合：

1
高风险领域
2
复杂开放任务
3
Judge 校准
4
新失败模式
5
事故样本

专家评分必须使用：

固定 Rubric；
Blind Identity；
双标；
仲裁；
一致性统计。

Inspect Human Agent 允许人类在与模型相同的 Dataset、Sandbox 和 Scorer 配置下完成任务，并记录终端动作，可用于 Human Baseline。¹⁷

7.8 组合式 Grader#

实际 Agent Eval 应组合多种 Grader。

1
flowchart LR
2
    A[Environment Tests] --> H{Hard Gates}
3
    B[Forbidden Action] --> H
4
    C[Security Check] --> H
5

6
    D[Tool / Step Grader] --> S[Soft Scores]
7
    E[Trajectory Judge] --> S
8
    F[Final Response Judge] --> S
9
    G[Cost / Latency] --> S
10

11
    H -->|Fail| X[Trial Fail]
12
    H -->|Pass| Y[综合质量报告]
13
    S --> Y

推荐判定：

1
hard_pass = (
2
    environment_valid
3
    and outcome_success
4
    and not unsafe_side_effect
5
    and not forbidden_action
6
)
7

8
soft_quality = weighted_mean(
9
    response_quality,
10
    tool_quality,
11
    trajectory_quality,
12
)
13

14
trial_pass = (
15
    hard_pass
16
    and soft_quality >= quality_threshold
17
)

不要让软分抵消硬失败#

错误：

1
安全 = 0
2
回答质量 = 10
3
平均分 = 5
4
→ 通过

正确：

1
安全硬门禁失败
2
→ Trial Fail

PaperBench 使用分层 Rubric 将复杂研究复制任务拆成大量可独立评分的子任务，并单独评测自动 Judge 本身，说明复杂开放任务需要层级化 Grader 和 Judge Benchmark。¹⁸

8. LLM Judge 设计#

8.1 Rubric#

Rubric 必须原子化。

错误：

1
请判断这个 Agent 是否优秀。

正确：

1
trajectory_quality:
2
  4:
3
    description: >
4
      必要步骤完整，无明显重复，
5
      Tool Result 被正确使用。
6
  3:
7
    description: >
8
      有少量冗余，但不影响正确性。
9
  2:
10
    description: >
11
      有明显重复或一次不必要工具调用。
12
  1:
13
    description: >
14
      路径严重偏离，最终结果主要依赖偶然。
15
  0:
16
    description: >
17
      轨迹导致失败、违规或危险副作用。

Rubric 应包含：

1
定义
2
等级
3
正例
4
反例
5
边界案例
6
不确定处理
7
允许证据
8
禁止证据

8.2 Evidence#

Judge 应只看到与 Rubric 相关的 Evidence Pack。

示例：

1
{
2
  "task_contract": {
3
    "goal": "fix discount bug",
4
    "forbidden_paths": ["payments/**"]
5
  },
6
  "trajectory": [
7
    {
8
      "tool": "search_code",
9
      "result_summary": "..."
10
    },
11
    {
12
      "tool": "edit_file",
13
      "arguments": {
14
        "path": "orders/discount.py"
15
      }
16
    }
17
  ],
18
  "outcome": {
19
    "tests_passed": true,
20
    "forbidden_changes": []
21
  }
22
}

Evidence 必须有来源#

1
observation_id
2
artifact_id
3
state_snapshot_id
4
tool_call_id

否则 Judge Reason 无法审计。

8.3 结构化输出#

Judge 输出必须使用 Schema。

1
{
2
  "score": 3,
3
  "label": "acceptable",
4
  "confidence": 0.82,
5
  "reason_codes": [
6
    "MINOR_REDUNDANCY"
7
  ],
8
  "evidence_refs": [
9
    "obs_search_03"
10
  ],
11
  "explanation": "Agent repeated one repository search."
12
}

禁止只返回：

1
“整体不错，给 7 分。”

结构化输出有利于：

聚合；
版本迁移；
冲突分析；
人工复核；
规则检查。

Judge 不应看到：

1
候选模型名称
2
供应商
3
Agent 版本
4
实验组名称
5
Baseline / Candidate 标签
6
开发者姓名
7
期望哪组胜出

使用：

1
System A
2
System B

或单样本绝对评分。

Pairwise Judge 应随机化顺序。

8.5 Position Bias 与 Length Bias#

LLM Judge 可能偏好：

1
第一个候选
2
更长的候选
3
与自身风格相似的候选

MT-Bench / Chatbot Arena 研究系统讨论了 Position、Verbosity 和 Self-enhancement Bias，并提出交换候选顺序、使用 Reference 和混合人类评测等缓解方式。¹⁹

Position Bias 缓解#

Pairwise 比较运行两次：

1
A, B
2
B, A

只有结果一致时接受：

1
if judge(A, B) == "A" and judge(B, A) == "A":
2
    verdict = "A"
3
else:
4
    verdict = "uncertain"

Length Bias 缓解#

Rubric 明确要求：

1
不奖励冗余
2
按信息充分性评分
3
将 conciseness 独立评分

不要简单截断长答案，因为截断可能删除关键证据。

8.6 Judge 自洽性#

同一个 Judge 对同一个样本可能不稳定。

记录：

1
judge_trial_id
2
temperature
3
seed
4
response_hash
5
score

可以运行多次：

1
Judge Trial 1
2
Judge Trial 2
3
Judge Trial 3

输出：

1
majority score
2
score variance
3
disagreement flag

不确定样本升级人工#

1
confidence < threshold
2
or judge disagreement
3
or rule conflict
4
→ Annotation Queue

8.7 与人工 Gold 校准#

校准集应来自：

1
双人独立标注
2
专家仲裁
3
覆盖正常和边界案例
4
覆盖不同 Task 类型

指标：

Boolean / Categorical#

1
Accuracy
2
Precision
3
Recall
4
F1
5
Confusion Matrix
6
Cohen's Kappa

Numeric#

1
MAE
2
Spearman
3
Pearson
4
Threshold Agreement

Judge 版本上线需要：

1
校准报告
2
已知偏差
3
适用范围
4
不可用范围

G-Eval 表明 LLM Judge 可以提高与人类评测的相关性，但也指出 Judge 可能偏向 LLM 生成文本；所以“Judge 很强”不等于“无需 Gold”。²⁰

8.8 Judge 不应看到的内部信息#

不要给 Judge：

1
Agent 未看到的 Hidden Test 答案
2
Reference Patch 原文
3
候选模型名称
4
实验目标
5
未来环境状态
6
训练标签
7
人工 Gold 结论

需要区分两种使用。

Reference-guided Judge#

适合：

1
数学
2
结构化事实
3
代码功能
4
有明确 Gold 的任务

Judge 可以看到 Reference，但 Reference 必须只在评测阶段可见。

Open-ended Judge#

适合：

1
表达质量
2
方案合理性
3
用户体验

不应把一个唯一 Reference 当成唯一合法答案。

9. 故障与恢复能力评测#

故障恢复评测与多 Trial 统计

故障评测不是“让系统报错”，而是验证：

1
检测是否正确
2
恢复是否正确
3
副作用是否安全
4
成本是否受控
5
最终 Outcome 是否可靠

每个 Fault Case 应定义：

1
fault:
2
  injection_point: model_stream
3
  type: disconnect
4
  trigger: after_complete_tool_call
5
  duration_ms: 3000
6

7
expected:
8
  detection:
9
    - stream_disconnected
10
  recovery:
11
    - reconnect
12
    - preserve_tool_call_id
13
  forbidden:
14
    - duplicate_tool_execution
15
    - claim_success_before_outcome

9.1 429 限流#

注入：

1
第一次模型请求返回 429
2
带 Retry-After
3
连续多次 429
4
某个子 Agent 遇到 429

检查：

1
是否尊重 Retry-After
2
是否指数退避和 Jitter
3
是否限制 Attempt
4
是否共享 Retry Budget
5
是否触发重试风暴
6
是否正确记录成本

失败条件：

1
立即无限重试
2
所有子 Agent 同时重试
3
超过 Budget
4
最终成功却抹去中间错误

9.2 网络断流#

至少覆盖：

1
首 Token 前断开
2
文本中途断开
3
Tool Name 中途断开
4
Tool Arguments 中途断开
5
完整 Tool Call 后断开
6
Finish 后 Usage 前断开

检查：

1
部分文本是否被误当完整答案
2
半截 Tool Arguments 是否被执行
3
完整 Tool Call 是否重复执行
4
Usage 缺失是否被写成 0

9.3 Tool Timeout#

注入窗口：

1
工具开始前
2
只读工具执行中
3
写操作副作用前
4
写操作副作用后、Ack 前
5
子进程无法响应 Cancel

检查：

1
Cancellation 是否传播
2
孤儿进程是否清理
3
远端 Outcome 是否查询
4
是否使用 Idempotency Key
5
是否重复写入

9.4 MCP 失联#

注入：

1
Server Discovery 失败
2
Tool List 获取失败
3
调用中断
4
Resource Read 中断
5
重连后 Schema 变化
6
Trace Context 丢失

检查：

1
是否刷新 Capability
2
是否使用旧 Tool Schema
3
是否保留 Tool Call ID
4
是否重复写操作
5
Client / Server Trace 是否可关联

9.5 权限拒绝#

注入：

1
文件写权限拒绝
2
网络出站拒绝
3
Approval 拒绝
4
凭证过期
5
Sandbox 拒绝

期望：

1
识别为 Policy / Permission
2
而不是 Network Error
3

4
尝试低权限替代路径
5
请求人工
6
生成 Patch 而非直接写入

检查 Agent 是否反复请求同一权限。

9.6 错误 Tool Result#

注入：

1
malformed
2
stale
3
partial
4
contradictory
5
empty
6
oversized
7
prompt_injection
8
wrong_resource_version

检查：

1
Schema Validation
2
来源验证
3
Result 是否被写入 Memory
4
是否交叉检查
5
是否直接驱动危险动作

9.7 Context Compaction#

注入：

1
逼近 Context Window
2
强制 Compaction
3
截断长 Tool Result
4
删除早期硬约束

检查压缩前后：

1
goal
2
must
3
must_not
4
allowed_scope
5
pending_actions
6
completed_side_effects

核心指标：

1
hard_constraint_recall
2
forbidden_constraint_recall
3
pending_action_consistency
4
duplicate_side_effect_count

9.8 状态恢复和重复副作用#

场景：

1
写工具成功
2
→ Tool Result 丢失
3
→ Agent 进程崩溃
4
→ 从 Checkpoint Resume

检查：

1
是否查询 Execution Ledger
2
是否复用已有结果
3
是否盲目重放
4
是否产生重复资源

不可逆操作必须有：

1
operation_id
2
attempt_id
3
idempotency_key
4
remote_status

10. 多 Trial 与统计#

10.1 单次 Trial 的局限#

单次 Trial 可能受：

1
模型随机性
2
Provider 路由
3
网络抖动
4
工具延迟
5
缓存
6
用户模拟器
7
并发调度

影响。

一个版本从：

1
Trial 1：成功

不能推断：

1
成功率 = 100%

同样：

1
Trial 1：失败

不能推断：

1
完全没有能力

10.2 Pass@k#

pass@k 表示 k 次尝试中至少有一次成功的概率。

如果单次成功概率为 $p$ ，且 Trial 独立同分布：

\mathrm{pass@k} = 1-(1-p)^k

它适合：

1
允许生成多个候选
2
只需其中一个成功
3
搜索、代码候选、规划候选

如果一个 Task 运行 $n$ 次，其中 $c$ 次成功，常用无偏估计为：

\widehat{\mathrm{pass@k}} = 1- \frac{\binom{n-c}{k}} {\binom{n}{k}}

条件：

1
n >= k

pass@k 会随 k 上升#

所以不能拿：

1
System A pass@1

和：

1
System B pass@10

直接比较。

10.3 Pass^k#

pass^k 表示 k 次尝试全部成功的概率。

在独立同分布假设下：

\mathrm{pass^k} = p^k

它适合：

1
客户服务
2
写操作
3
生产自动化
4
要求每次可靠的 Agent

如果一个 Task 有 $n$ 次 Trial、其中 $c$ 次成功，可以用：

\widehat{\mathrm{pass^k}} = \frac{\binom{c}{k}} {\binom{n}{k}}

理解为从 n 次 Trial 中随机选 k 次，它们全部成功的比例。

若每个 Task 恰好运行 k 次，也可以直接统计：

1
该 Task 是否 k 次全部成功

再对 Task 求平均。

pass@k 与 pass^k 回答相反的问题#

1
pass@k：
2
“给它 k 次机会，至少成功一次吗？”
3

4
pass^k：
5
“连续运行 k 次，它能每次都成功吗？”

Anthropic 和 τ-bench 都强调这两个指标的用途不同：前者反映多次尝试的上限，后者反映一致性。¹⁵

10.4 均值、方差和分位数#

均值#

适合：

1
平均成功率
2
平均成本
3
平均 Tool Count

方差#

适合：

1
成本波动
2
延迟波动
3
Score 稳定性

分位数#

对延迟和成本更重要：

平均延迟可能掩盖少数 20 分钟的长尾 Trial。

按 Task 先聚合#

不要把所有 Trial 混在一起直接求均值。

10.5 Bootstrap 置信区间#

Agent 指标通常不满足简单正态假设：

Task 难度差异大；
Score 离散；
成本长尾；
每个 Task 有多个 Trial。

推荐使用 按 Task 聚类的 Bootstrap。

单系统 Bootstrap#

1
1. 从 Task 集合有放回抽样
2
2. 保留每个 Task 的全部 Trial
3
3. 计算指标
4
4. 重复 B 次
5
5. 取 2.5% 和 97.5% 分位数

A/B 对比使用配对 Bootstrap#

如果两个版本运行相同 Task：

1
每次 Bootstrap 抽同一组 Task
2
计算 metric_candidate - metric_baseline

得到差值置信区间。

为什么不能按 Trial 独立抽样#

同一 Task 的多个 Trial 共享：

1
任务难度
2
环境
3
Grader

它们不是完全独立样本。
按 Trial 抽样会低估不确定性。

Stratified Bootstrap#

Suite 含多个领域时：

1
Coding
2
Browser
3
Customer Support

可在每个 Stratum 内抽样，再合并，保持任务分布。

10.6 成本—质量联合比较#

不要只用一个综合分数压平所有信息。

推荐报告：

1
Success
2
pass^k
3
Cost per Success
4
p95 Latency
5
Unsafe Side-effect
6
Human Escalation

Pareto Frontier#

如果系统 A：

1
质量更高
2
成本也更高

它可能与系统 B 同时处于 Pareto Frontier。

预算约束下比较#

1
在 Cost <= 0.50 美元下，谁的成功率最高？
2
在 Latency <= 60 秒下，谁的 pass^4 最高？

Reliability-adjusted Utility#

可以定义业务 Utility：

U = V_{\text{success}} \cdot \mathbb{1}[\text{success}] - C_{\text{cost}} - \lambda L_{\text{latency}} - R_{\text{risk}}

但安全硬门禁不应仅作为一个可被抵消的负数。

10.7 模型随机性与基础设施噪声分离#

失败来源要分层实验。

模型响应 Replay#

固定模型输出，重新执行：

1
Parser
2
Agent Runtime
3
Tool
4
State

如果仍失败，问题不在模型随机性。

Tool Result Replay#

固定 Tool Result，重新运行模型。

用于判断：

1
外部服务变化
2
还是模型误读

环境 Snapshot Replay#

固定完整初始环境，重新运行 Agent。

控制组#

每次 Candidate Evaluation 同时运行固定 Baseline。

如果两者同时下降：

1
更可能是环境或基础设施问题

基础设施指标#

同步记录：

1
model_provider_error
2
tool_service_error
3
environment_setup_error
4
grader_error
5
network_latency

无效 Trial 应单独报告，不能静默删除。

11. Evaluation Suite 分层#

Evaluation Suite 分层与回归门禁

11.1 Capability Eval#

目标：

1
测量当前能力上限
2
推动新能力
3
区分强弱版本

特点：

1
较难
2
有改进空间
3
覆盖新能力
4
允许较高成本

当 Suite 接近 100% 时，它更适合 Regression，不再适合测进步。Anthropic 将这种现象称为 Eval Saturation。¹

11.2 Regression Eval#

目标：

1
防止已有能力退化

特点：

1
Task 稳定
2
环境稳定
3
Grader 稳定
4
代表核心用户路径
5
运行较快

Regression Set 应冻结：

1
Task Version
2
Environment Version
3
Grader Version
4
Prompt-visible Contract

不能每次发布都偷偷调整 Task。

11.3 Safety Eval#

目标：

1
验证系统在恶意、模糊或冲突条件下不执行危险动作

覆盖：

1
权限绕过
2
Prompt Injection
3
Secret Exfiltration
4
越权写入
5
跨租户
6
不可逆操作
7
欺骗性成功声明

Safety Eval 的严重失败不应被平均分掩盖。

11.4 Recovery Eval#

目标：

1
验证网络、工具和状态故障后的恢复正确性

覆盖：

1
429
2
5xx
3
Stream Disconnect
4
Tool Timeout
5
MCP 失联
6
Checkpoint Resume
7
重复副作用

Recovery Eval 必须包含：

1
正常检测
2
正确重试
3
Budget
4
幂等
5
最终 Outcome

11.5 长尾和真实生产案例集#

来源：

1
用户投诉
2
人工接管
3
线上事故
4
高成本 Trace
5
低频工具组合
6
Judge 冲突
7
新失败模式

这类 Suite 应分成：

1
Frozen Core
2
Rolling Production Set

Frozen Core 用于可比性。
Rolling Set 用于捕捉真实分布变化。

不要把生产 Trace 原样直接当 Task；需要：

脱敏；
环境重建；
Ground Truth；
去重；
防泄漏；
可解性验证。

12. 回归门禁与发布流程#

1
flowchart LR
2
    A[开发修改] --> B[PR 小型回归]
3
    B -->|通过| C[Nightly 完整 Suite]
4
    C -->|通过| D[Release Candidate]
5
    D --> E[Shadow]
6
    E --> F[Canary]
7
    F -->|健康| G[逐步放量]
8
    F -->|回归| H[自动回滚]
9
    G --> I[生产 Trace]
10
    I --> J[新案例进入 Suite]

12.1 PR 级小型回归集#

目标：

1
快速反馈
2
定位明显回归
3
保护核心路径

应优先使用：

确定性 Task；
低成本模型配置；
关键 Tool Contract；
安全硬门禁；
最近修复的 Bug；
少量固定 Trial。

PR Gate 不适合运行全部长尾任务。

PR Gate 输出#

1
通过 / 阻塞
2
失败 Task
3
Trace Link
4
Grader Evidence
5
与 Baseline 差异

12.2 Nightly 完整评测#

Nightly 适合：

1
完整 Regression
2
多 Trial
3
Capability Subset
4
Safety
5
Recovery
6
成本和延迟

Nightly 必须保留：

1
Experiment Manifest
2
Git Commit
3
Model Snapshot
4
Prompt Version
5
Environment
6
Dataset Version
7
Grader Version

失败后可以自动 Retry 基础设施错误，但不应自动抹掉 Agent Failure。

Inspect Eval Set 支持任务集合、自动 Retry 和 Resume，可作为实现完整评测调度的一种参考。³

12.3 发布前门禁#

Release Gate 应包含三类条件。

绝对硬条件#

1
P0 / P1 Safety Failure = 0
2
Forbidden Side-effect = 0
3
Environment Invalid Rate < threshold
4
Reference Solution 全通过

相对回归条件#

1
Candidate - Baseline

例如：

1
Task Success 下降不超过 1 个百分点
2
pass^4 不显著下降
3
Cost per Success 上升不超过 10%
4
p95 Latency 上升不超过 15%

具体阈值必须由产品风险确定，不应照抄示例。

统计条件#

1
置信区间
2
最小样本量
3
有效 Trial 数
4
Infrastructure Invalid 上限

如果样本不足，应输出：

1
inconclusive

而不是强行通过。

12.4 Shadow 与 Canary Evaluation#

Shadow#

将真实生产请求复制给 Candidate，但不让它产生真实副作用。

1
Production Agent → 用户
2
Candidate Agent → Shadow Sandbox

比较：

1
Tool Decision
2
Output
3
Outcome
4
Cost
5
Latency
6
Safety

Canary#

让 Candidate 处理少量真实流量。

要求：

1
租户 Allowlist
2
风险任务排除
3
明确回滚
4
实时 SLO
5
人工值守
6
副作用幂等

Shadow 主要测试分布真实性。
Canary 才测试真实依赖和用户反馈。

12.5 回归结果定位到具体 Trace#

门禁失败必须可下钻。

1
Suite
2
→ Task
3
→ Trial
4
→ Grader
5
→ Evidence
6
→ Trace
7
→ Observation / Step
8
→ Artifact / State Diff

报告不能只显示：

1
Success Rate 从 82.1% 降到 79.8%

还应显示：

1
哪些 Task 下降
2
失败模式
3
首个异常 Step
4
工具和参数
5
环境 Outcome
6
是否与最近改动相关

Trace Grading 和生产 Trace 转 Eval 的价值就在于把聚合回归定位回执行链。OpenAI 也将 Datasets、Trace Grading、自动评分和人工 Annotation 作为 Agent Evals 的核心闭环组件。²¹

12.6 哪些波动应阻塞发布#

必须阻塞#

1
任何严重安全副作用
2
真实数据污染
3
跨租户泄漏
4
Reference Solution 失败
5
核心任务显著回归
6
幂等失效
7
Harness 无法验证环境

条件阻塞#

1
质量下降且置信区间排除 0
2
Cost / Latency 超预算
3
Recovery Rate 显著下降
4
Judge 与 Human Gold 偏差扩大

不应仅凭此阻塞#

1
单个随机 Trial 失败
2
极小样本平均分变化
3
无用户影响的格式变化
4
已知基础设施故障
5
Judge 自身 Error

Flaky Task#

Flaky Task 不应被静默删除。

状态：

1
active
2
quarantined
3
under_investigation
4
fixed
5
retired

Quarantine Task 仍应报告，只是不作为硬门禁，直到修复。

13. 常见评测陷阱#

13.1 将 Agent 自己的成功声明当 Ground Truth#

错误：

1
final_answer contains "completed"
2
→ success

正确：

1
Environment Outcome
2
→ Grader
3
→ success

同时检查：

1
Claim vs Outcome

13.2 Rubric 过于抽象#

错误：

1
“轨迹是否优秀？”

正确：

1
是否重复
2
是否违反依赖
3
是否漏掉必要步骤
4
是否安全停止

抽象 Rubric 会导致：

人工不一致；
Judge 漂移；
无法解释；
难以优化。

13.3 只测正常路径#

只测：

1
API 永远成功
2
Tool 永远快速
3
权限永远允许

会得到虚假的生产可靠性。

至少加入：

1
429
2
断流
3
Timeout
4
Permission Denied
5
MCP Disconnect
6
Malformed Result
7
Compaction
8
Resume

13.4 测试环境存在捷径#

常见捷径：

1
Reference Patch 在 Git History
2
Hidden Test 可读
3
文件名透露答案
4
网络可以搜索原 PR
5
Grader Endpoint 可访问
6
Expected Output 被注入 Prompt

Agent 通过捷径获得高分，不代表能力提高。

需要专门的环境红队。

13.5 Judge 可以看到答案泄漏#

错误：

1
Judge 和 Agent 使用同一 Context
2
Hidden Gold 留在 Agent 可见变量
3
Judge Result 回流当前 Trial

正确隔离：

1
Agent-visible Channel
2
Grader-only Channel

Judge 可以在 Trial 结束后看到 Gold，但 Agent 不能。

13.6 Harness 或环境变化被误认为 Agent 能力提升#

如果同时修改：

1
Agent
2
Prompt
3
Tool
4
Docker Image
5
Test
6
Judge

无法知道谁导致变化。

每次 Experiment 必须保存完整 Manifest。

13.7 使用平均分掩盖严重安全失败#

错误报告：

1
平均分 = 92
2
系统表现优秀

但其中可能有：

1
1 次跨租户写入
2
2 次重复付款
3
3 次 Secret 外传

报告必须同时包含：

1
Mean Quality
2
Task Success
3
pass^k
4
P0/P1 Safety Count
5
Unsafe Side-effect Rate
6
Worst-case Failure

安全门禁采用：

1
max severity

而不是：

1
average safety score

落地后的统一评测合同#

一套成熟的 Agent Evaluation 可以输出下面的 Trial Record：

1
{
2
  "task": {
3
    "id": "fix-discount-zero-quantity",
4
    "version": 3
5
  },
6
  "trial": {
7
    "id": "trial_005",
8
    "agent_version": "3.2.0",
9
    "model": "model-x",
10
    "prompt_version": "planner-v7",
11
    "environment_revision": "coding-eval-2026-08-01",
12
    "trace_id": "trace_005"
13
  },
14
  "outcome": {
15
    "verified_success": true,
16
    "tests_passed": true,
17
    "forbidden_changes": [],
18
    "unexpected_side_effects": false
19
  },
20
  "scores": {
21
    "final_response": 0.92,
22
    "tool_selection": 1.0,
23
    "tool_arguments": 1.0,
24
    "trajectory": 0.83,
25
    "environment_outcome": 1.0,
26
    "safety": 1.0
27
  },
28
  "metrics": {
29
    "wall_time_seconds": 74.2,
30
    "model_calls": 6,
31
    "tool_calls": 11,
32
    "input_tokens": 48200,
33
    "output_tokens": 6300,
34
    "cost_usd": 0.42
35
  },
36
  "recovery": {
37
    "fault_injected": "stream_disconnect",
38
    "recovered": true,
39
    "attempt_count": 2,
40
    "duplicate_side_effects": 0
41
  },
42
  "validity": {
43
    "environment_valid": true,
44
    "grader_valid": true,
45
    "infrastructure_error": false
46
  }
47
}

Suite Report 则应同时展示：

1
Task Success
2
pass@k
3
pass^k
4
Cost per Success
5
p95 Latency
6
Recovery Rate
7
Safety Failure Count
8
Infrastructure Invalid Rate
9
A/B Difference + Confidence Interval

结语#

Agent 评测体系的核心，不是增加更多自动分数，而是建立一条可信的证据链：

1
Task Contract
2
→ Independent Trial
3
→ Transcript / Trace / Trajectory
4
→ Artifact
5
→ Environment Outcome
6
→ Layered Graders
7
→ Multi-trial Statistics
8
→ Evaluation Suite
9
→ Release Gate

本文可以归纳为七条原则。

Task 不等于 Prompt。
Task 必须包含初始环境、工具、权限、预算、成功标准和禁止行为。
Trial 必须独立。
文件、数据库、浏览器、缓存、记忆和副作用状态不能跨 Trial 泄漏。
最终回答不是 Ground Truth。
Agent 成功必须由 Environment Outcome 验证。
评测必须分层。
Final Response、Tool、Step、Trajectory 和 Outcome 分别回答不同问题。
硬门禁与软分数分开。
安全违规、禁止副作用和环境无效不能被平均分抵消。
单次运行不能代表可靠性。
pass@k 测试“至少成功一次”，pass^k 测试“每次都成功”。
评测必须进入发布流程。
PR、Nightly、Release、Shadow 和 Canary 形成连续门禁，并能从聚合指标定位回具体 Trace。

最终，一个真正可执行的 Agent Evaluation 不只是回答：

1
“这个 Agent 得了多少分？”

而应回答：

1
它在什么任务和环境中运行
2
走了什么轨迹
3
调用了什么工具
4
是否真正改变了环境
5
失败来自模型还是系统
6
故障后是否安全恢复
7
多次运行是否稳定
8
新版本是否值得发布

只有这些问题都有结构化、可复现、可审计的答案，评测体系才能成为 Agent 工程的质量基础设施，而不是发布前临时运行的一组 Demo。

参考资料#

第 7 篇：Agent 评测体系设计——从任务、轨迹、环境结果到回归门禁

https://jupiter-ws.cn/posts/agent-observability/07-agent-evaluation-system/

作者

Jupiter

发布于

2026-08-06

许可协议

CC BY-NC-SA 4.0