Agent 评估是用可重复的任务、环境和评分方法，测量 Agent 是否能够正确、安全且稳定地完成目标。它不仅检查最终回答，还要检查工具调用、环境变化、成本、延迟和失败过程。
评估对象通常不是孤立的模型，而是模型与 Agent Harness 的组合。同一个模型在不同提示词、工具、上下文装配、权限规则和错误恢复机制下可能表现不同；分数变化不一定意味着模型本身变强或变弱。
基本术语
| 术语 | 含义 |
|---|---|
| 任务（Task） | 一条具有输入、初始状态和成功条件的测试用例 |
| 试验（Trial） | Agent 对一条任务的一次实际运行 |
| 轨迹（Trace / Trajectory） | 本次运行的消息、决策、工具调用、结果和状态变化 |
| 结果（Outcome） | 试验结束时环境中的真实状态 |
| 验证器（Grader） | 根据结果或轨迹计算分数的规则或程序 |
| 评估集（Evaluation Suite） | 围绕某种能力或行为组织的一组任务 |
模型输出具有随机性，因此一条任务通常需要运行多次。只运行一次，难以区分稳定能力、偶然成功和基础设施噪声。
评估体系要回答的四个问题
- 什么算成功：最终状态、必要过程、安全底线和质量标准是什么；
- 任务从哪里来：公开基准、产品需求、专家设计还是生产失败案例；
- 由谁验证：确定性程序、规则清单、模型评判或人工评审；
- 分数如何影响决策：用于模型选型、回归检查、Harness 改进还是上线门槛。
如果这四项没有明确约定，一个总分很难说明 Agent 是否真的可用。
评估任务与环境
一条可执行的 Agent 评估任务通常包含：
- 提供给 Agent 的目标、背景和限制；
- 每次运行前可恢复的初始环境状态；
- Agent 能调用的工具及其权限；
- 交互协议、步数限制和终止条件；
- 对最终状态、关键动作和沟通质量的验证规则。
评估环境需要至少具备数据集、环境状态、工具接口、评分标准和执行协议。环境应能重置到可比较的起点，并真实反映工具产生的状态变化。否则，前一次运行残留的数据、网络波动或资源不足都可能被误判为 Agent 能力差异。
对话型 Agent 还可能需要用户模拟器。模拟用户应拥有明确的已知信息、行为规则和可观察状态；不能为了配合 Agent 而编造事实。τ²-bench 进一步允许 Agent 和模拟用户分别使用工具操作共享环境，用于评估双方协作才能完成的任务。
成功指标
最基础的指标是单次任务成功率，但生产决策通常还需同时记录安全违规、成本、Token、延迟、步骤数和人工接管次数。
Pass@k 与 Pass^k
- Pass@k：同一任务运行 k 次，只要至少一次成功就算通过，用于观察能力上限；
- Best@k：输出为连续分数时，取 k 次试验中的最好结果；
- Pass^k：同一任务连续运行 k 次，要求每次都成功，用于观察稳定交付能力。
若每次试验相互独立且单次成功率为 p，则 Pass@k = 1 - (1 - p)^k，而 Pass^k = p^k。评估报告必须说明 k、采样方式、失败是否包含安全一票否决项，以及多次运行能否共享状态。对会产生副作用的任务，不能在真实环境中简单重试到成功。
验证方法
应优先使用最接近真实结果、最容易重复的验证方法：
- 确定性验证器：单元测试、数据库断言、文件内容、Schema 或业务状态检查；
- 规则与检查项：检查必需字段、禁止动作、来源覆盖和格式要求；
- LLM-as-a-Judge：依据明确 Rubric 评判开放式结果或交互质量；
- 人工评审：处理高风险、专业性强或主观差异大的结果，并校准自动验证器。
验证最终状态通常比匹配 Agent 的文字声明更可靠。Agent 说“已经预订成功”，不代表订单真实存在；Agent 说“测试通过”，也不能代替测试输出。
使用 LLM-as-a-Judge
模型评判适合正确答案不唯一、难以用代码完整表达的任务，例如研究报告的覆盖度或客服对话的沟通质量。使用时应：
- 将正确性、完整性、遵循指令和表达质量拆成明确维度；
- 提供评分尺度、边界案例和必要参考事实；
- 要求结构化输出评分与理由；
- 用人工标注集校准一致性，并定期复查漂移；
- 对候选结果顺序、长度和措辞造成的偏差进行测试；
- 在适合时采用配对比较，而不是让模型直接给绝对分数。
LLM 评判仍可能误判，不能因为评判模型更强就把它当作客观真值。
评估数据集
数据可以来自三类来源：
- 公开基准：便于与其他系统比较，但未必代表具体业务；
- 自建业务任务：直接对应产品目标，应覆盖常见路径和重要边界；
- 生产轨迹回流：把真实失败脱敏后转成回归任务，持续补充未知问题。
每条任务应写清初始状态、输入、允许动作和完成条件。数据集还需要控制重复、歧义、难度分布、版本变化和数据泄漏。训练、调试和最终评估集合应隔离，避免 Agent 只记住公开答案或固定界面。
能力评估可以包含当前较难、成功率较低的任务，用来寻找提升空间；回归评估则保护已经能够稳定完成的行为，目标应接近全部通过。能力任务成熟后可以进入回归集。
轨迹分析与失败归因
端到端分数只能说明任务是否通过，完整轨迹才能解释失败原因。分析时应定位第一个使后续结果偏离目标的错误，而不只记录最后一次失败。常见类别包括：
- 观察缺失或读取错误；
- 推理基于错误假设；
- 选错工具、对象或参数；
- 已获得纠错证据，却没有更新状态；
- 动作执行失败但被当成成功；
- 缺少最终验证或过早结束；
- 评估环境、验证器或基础设施自身故障。
除了完整端到端任务，还可以从历史轨迹的关键边界截取前缀，直接测试 Agent 在获得某项证据后能否作出正确下一步。这类小型回归任务比重复运行整个长任务更快，也更容易定位变化原因。
模型与 Harness 的对比实验
- 模型替换：固定 Harness，只更换模型，观察瓶颈是否随模型能力变化；
- 消融实验：关闭某个工具、提示或恢复机制，测量该组件的真实贡献；
- 配对实验：让新旧方案运行同一批任务与随机种子，减少任务差异；
- A/B 测试：在满足安全和样本量要求时比较真实用户结果；
- 护栏指标：即使主指标改善，安全、成本或用户体验底线也不能退化。
实验应记录模型版本、Harness 版本、任务集版本、环境配置、采样参数和随机种子。样本量很小时，百分比变化可能只是偶然波动；应报告样本数、置信区间或重复试验，而不是只展示最好的一次结果。
可观测性与生产监控
评估依赖可观测性。Harness 应记录任务 ID、模型和提示版本、工具调用与结果、环境状态变化、成本、延迟、停止原因和人工审批，使一次失败能够重放和归因。
离线评估不能覆盖所有真实输入。上线后还需要生产监控、用户反馈和抽样轨迹审查，发现分布变化与未知失败，再将有代表性的案例脱敏后加入回归集。日志采集应遵循最小必要原则，避免把用户凭据、私密文件和完整敏感对话直接写入评估数据。
评估驱动的改进闭环
- 从失败轨迹中提出一个可验证假设；
- 每次只改变一个主要变量；
- 在小型目标任务集上快速验证方向；
- 同时检查成功率、成本、延迟和安全护栏；
- 方向成立后运行完整回归集；
- 保存结果与适用边界，再决定是否部署；
- 将新的生产失败补入评估集。
小样本实验通过，只说明值得扩大测试，不等于系统整体能力已经提高或可以直接上线。