06. Agent 专项评测
读完本章，你应该能：
本章回答：会调用工具、改变环境、跨多轮交互的 Agent，应该怎样评估。
学习目标
读完本章，你应该能：
- 区分 output eval、trajectory eval 和 outcome/state eval。
- 为 agent 设计 task、trial、environment、trace 和 scorer。
- 解释 pass^k 为什么比 pass@k 更贴近 agent 上线可靠性。
- 识别 runtime shift、工具设计和环境状态对 eval 的影响。
本章导读
Agent 的难点在于，它不只是生成一段文本，而是在环境里做事。它可能查询数据库、打开网页、编辑文件、调用支付接口、等待 CI、读取用户历史，再决定下一步。这样的系统一旦失败，失败也不会只停留在语言层面，而会留下状态、成本、权限和副作用。
这就是为什么 agent eval 不能只问“最后回答是否正确”。一个 agent 可以礼貌地告诉用户“我已经帮你改好了”，但数据库里没有任何改签记录；也可以真的改签成功，却顺手取消了另一张不该动的票。前者是 output 与 outcome 不一致，后者是 outcome 局部正确但副作用失败。只看最终文本，两者都可能被漏掉。
本章要建立的核心意识是：评估 agent，就是评估一个会行动的系统。你要看它说了什么，也要看它怎么做，更要看世界最后变成了什么样。只有把这三层分开，agent 的可靠性才有可能被认真讨论。
Agent eval 的本质
Agent 不是“回答问题的模型”，而是“在环境中循环使用工具的系统”。因此 agent eval 不能只看最后一句回答，而要看：
- 是否理解任务。
- 是否选择了正确工具。
- 是否传入正确参数。
- 是否处理工具错误。
- 是否遵守政策和权限。
- 是否真的改变了环境状态。
- 是否没有造成副作用。
- 是否多次运行都稳定。
Wolfe 的 agent eval anatomy 是一个很好的起点：tasks → trials → transcripts → outcomes → gradersWolfeAgentEvals2026。也就是说，你先定义任务，再多次运行，每次保存完整 transcript/trace，再用 output、trajectory 或 outcome scorer 打分。
Agent eval 的最小结构
task:
id: airline_change_flight_001
user_goal: "将航班改签到明天下午，并确认价格差额"
initial_state:
bookings:
- id: "B001"
user: "U123"
flight: "MU5101"
date: "2026-07-01"
status: "confirmed"
policy_docs:
- id: "change-fee-policy"
text: "24 小时内改签需确认差价和手续费。"
tools:
- search_flights
- change_booking
- calculate_fee
- respond
trial:
model: "your-agent-v3"
seed: 42
isolated_environment: true
logged_trace:
messages:
- role: "user"
content: "我想改到明天下午"
tool_calls:
- name: "search_flights"
args:
date: "2026-07-02"
time_window: "afternoon"
observations:
- "找到 2 个可改签航班"
final_state:
booking_id: "B001"
status: "changed"
scorers:
- required_state_change
- no_extra_booking
- required_confirmation_text
metrics:
- pass@1
- pass^3
- cost_per_success三类评分：output、trajectory、outcome
Output eval：看最终回答
适合：
- 格式、语言、引用。
- 是否提供必要确认号。
- 是否清楚说明下一步。
- 是否符合渠道限制。
缺点：无法证明实际操作发生。
Trajectory eval：看过程
适合：
- 工具是否按合理顺序调用。
- 关键参数是否正确。
- 是否出现无进展循环。
- 是否读取了必要文档。
- 是否在高风险操作前检查权限。
工具：trajectory match、LLM trajectory judge、人工 trace 审计。
缺点：多条路径可能都合理；严格顺序匹配会误杀。
Outcome/state eval：看最终状态
适合：
- 订单是否真的取消。
- 退款是否真的写入。
- PR 是否真的通过测试。
- DB 是否只有期望变化。
- 文件是否正确修改。
Anthropic、tau-bench、AppWorld 都把这种状态验证作为 agent eval 的核心AnthropicAgentEvals2026TauBench2024AppWorld2024。
State grading：评估“做成了什么”
状态评分的基本模式：
- 初始化一个干净环境。
- 运行 agent。
- 保存最终环境状态。
- 与 expected state 比较。
- 检查没有 collateral damage。
示例：
def grade_expense_draft(before, after, employee_id):
draft = after.expense_reports.latest_for_employee(employee_id)
expected = [
draft.status == "draft",
draft.project_code is not None,
draft.amount == after.receipts.total_for_report(draft.id),
draft.has_over_budget_explanation(),
not draft.submitted_without_employee_confirmation,
after.audit.no_unrelated_changes(before),
]
return all(expected)关键是同时检查正向和负向：
- 正向：该发生的状态变化发生了。
- 负向：不该发生的状态变化没有发生。
AppWorld 特别强调 collateral damage：agent 完成目标但改变了不相关状态，也应该失败或扣分AppWorld2024。
Trajectory eval：过程有诊断价值
如果 outcome 失败，trajectory 可以告诉你为什么失败：
- 没查 policy。
- 查了错文档。
- 工具参数错。
- 工具失败后没有 retry。
- 在没有权限时执行操作。
- 循环调用同一个工具。
PATTERNS.md 区分了两类 trajectory scorerAwesomeEvalsPatterns2026：
| 方法 | 优点 | 缺点 | 适合 |
|---|---|---|---|
| Deterministic trajectory match | 便宜、稳定、适合 CI | 只承认参考路径，容易误杀 | 流程固定的工作流 |
| LLM trajectory judge | 能承认替代路径 | 容易 over-credit，需要校准 | 开放路径、多工具任务 |
实践上，trajectory eval 应用于诊断和辅助，不要轻易替代最终 outcome。
多轮用户模拟
真实 agent 往往不是单轮任务。tau-bench 的重要贡献之一，是引入模拟用户与 agent 多轮互动，并用领域状态检查最终结果TauBench2024。多轮 eval 要特别注意：
- 用户可能信息不完整。
- 用户可能改变主意。
- 用户可能给出矛盾信息。
- agent 需要追问、确认和解释。
- agent 需要在多轮中保持状态一致。
评价多轮 agent 时，不要只测“给一大段完整需求能不能完成”。现实里用户经常逐步透露信息。
连续任务与人类在环
多轮 eval 还不等于真实长期任务。Yao 对传统 eval 的 i.i.d. 假设提出批评：真实 agent 常常不是在互不相关的独立样本上工作，而是在同一个用户、同一个 repo、同一个企业流程或同一组业务对象上连续行动Yao2025。这会带来两类额外评估问题。
第一类是人类在环。agent 不能只假设用户一开始就给出完整需求。差旅报销 agent 要在缺项目编号时追问；coding agent 要在需求不清时请求确认；采购 agent 要在预算、供应商或审批链缺失时停下来。这里要评估的不是“模型有没有能力一次性完成任务”，而是“它是否知道什么时候应该继续、什么时候应该问人、什么时候应该升级”。
第二类是跨任务状态。一个 coding agent 连续修同一个仓库的 10 个 issue，理想情况下会逐渐熟悉目录结构、测试入口和领域术语；一个企业助手连续处理同一个员工的报销、差旅和采购，也会积累项目、成本中心和审批偏好。完全隔离的单次 trial 有利于可复现，但它测不到这种累积熟悉度。更完整的 agent eval 往往需要两套视角：一套隔离 trial 用来控制变量和做回归；另一套 session/repo/user 级连续任务，用来测长期状态、记忆污染、上下文累积和跨任务学习是否真的带来 utility。
pass^k：Agent 上线可靠性的底线
Agent 很容易在 demo 中显得可靠，因为人会挑成功样本。但上线时同类任务会重复发生。一个 customer-service agent 单次成功率 80%，连续 5 次都成功的概率只有 0.8^5 = 0.32768。
所以：
- capability demo 可以看 pass@k。
- deployment reliability 应看 pass^k、repeat success rate、failure rate by scenario。
- 长任务还要看可靠性随任务时长如何衰减。
Khanal 等的长时程可靠性框架指出，能力排名和可靠性排名会在长任务上出现倒置KhanalReliability2026。这对 agent 产品非常关键：最会“尝试复杂策略”的模型，未必是最稳的模型。
Runtime shift：评测环境不等于生产环境
Lee 的 runtime shift 概念很重要：agent 会适应它运行时的工具延迟、shell 行为、文件系统布局、网络边界和错误模式；如果 eval 在训练 runtime 中运行，而生产换了 runtime，就可能出现 eval 没抓到的静默质量回退LeeRuntime2026。
典型差异：
| 训练/评测 runtime | 生产 runtime |
|---|---|
| 干净、短生命周期环境 | 长生命周期、用户会回来继续 |
| 网络录制或 mock | 开放互联网和真实 API |
| 工具稳定、失败少 | 工具超时、权限变化、限流 |
| 失败就重采样 | 失败要降级、重试、人工接管 |
| 状态可随时重置 | 状态要持久、可审计 |
Agent eval 应尽量贴近生产 runtime，或者显式把 runtime 作为变量测试。
Agent task 设计原则
1. 任务要真实
任务应该来自真实用户目标，而不是为了模型方便而写成考试题。Yao 批评传统 eval 的 i.i.d. 和 no-human-in-loop 假设，因为真实 agent 要连续工作、与人互动、积累上下文Yao2025。
2. 环境要隔离
每次 trial 都应从干净状态开始。否则前一次运行的状态会污染下一次结果。
3. 成功要可验证
至少对核心 outcome 写 verifier。主观部分再用 judge。
4. 要记录完整 trace
没有 trace，就没有诊断。至少记录 messages、tool calls、args、observations、latency、cost、errors 和 final state。
5. 要测试副作用
只检查目标完成，会鼓励 agent 用危险捷径。必须检查不相关状态没有被改变。
6. 要重复运行
单次成功不是可靠。至少对关键任务跑多次，报告 pass^k 或重复成功率。
常见 benchmark 的启发
| Benchmark | 值得学习的点 |
|---|---|
| tau-bench / tau2-bench | 多轮用户模拟、业务状态 diff、pass^k |
| AppWorld | 多应用模拟世界、状态单元测试、副作用检查 |
| Terminal-Bench | Docker 环境、oracle solution、测试套件、可复现任务 |
| SWE-bench | FAIL_TO_PASS/PASS_TO_PASS，修复与回归同时检查 |
| WebArena / VisualWebArena | web 环境、浏览器操作、多路径完成 |
| OSWorld / AndroidWorld | 真实 GUI/OS 状态，任务初始化与执行验证 |
Yehudai 等的 survey 把 agent eval 按能力、应用、generalist agent、benchmark dimensions 和工具生态组织，是建立全局地图的好参考YehudaiSurvey2025。
常见误区
误区 1：只看最后回答。
Agent 可以说“完成了”，但没有做任何事。
误区 2：只看工具顺序。
合理替代路径很多，严格轨迹匹配可能低估成功。
误区 3：只检查正向成功。
没有副作用检查，agent 可能完成任务同时破坏其他状态。
误区 4：eval runtime 与生产 runtime 差异巨大。
这会导致上线后出现 eval 没覆盖的质量回退。
误区 5：只跑一次。
Agent 的关键问题常常是重复运行不稳定。
本章练习
设计一个 agent eval task，包含：
- 初始环境状态。
- 用户目标。
- 可用工具。
- 必须记录的 trace 字段。
- 至少 2 个 outcome/state checks。
- 至少 1 个 side-effect check。
- pass^3 的运行计划。
- 如果失败，如何用 trajectory 定位问题。
延伸阅读
- AnthropicAgentEvals2026：agent eval 任务设计和状态检查。
- TauBench2024：多轮工具-用户交互 benchmark。
- AppWorld2024：状态单元测试和副作用检查。
- WolfeAgentEvals2026：agent eval 详细指南。
- LeeRuntime2026：runtime shift 和 sandbox 技术债。