Agent 评估方法：评估环境、验证器与统计显著性
构建 Agent 完成不等于构建正确。只有建立可重复的评估体系，后续的模型训练和系统进化才有可靠方向。本章围绕"如何判断 Agent 变好了还是变差了"这一核心问题，系统讨论了评估指标定义、评估环境构建、数据集设计、自动化评估方法、失败归因与统计显著性等关键环节。
评估体系的四个环节
一套评估体系可以拆成四个环节：什么算成功、任务从何而来、由谁验证、分数如何转化为决策。
一个关键认识是：评估的对象不应只是模型，而应是模型与 Harness 的组合体。同一个模型在不同的 Harness 中表现可能差异悬殊。区分"模型能力不足"和"Harness 设计缺陷"的常用手段是模型替换实验------固定 Harness 只换模型，如果换强模型分数不涨，说明瓶颈在 Harness；反之则说明瓶颈在模型。
一条评估任务的解剖：τ²-bench 的 telecom 领域
书中以 τ²-bench 的一条真实任务为例，完整展示了评估任务定义的四个组成部分：
- 工单（ticket）：提供给 Agent 的任务描述
- 用户模拟器行为规范（user_scenario） ：包括
known_info（用户已知信息）和task_instructions（行为约束） - 初始状态（initial_state）：运行前将两侧状态重置到同一起点
- 评分标准（evaluation_criteria） ：包含
actions、env_assertions、communicate_info等多维度检查
渐进式信息透露与事实锚定
τ²-bench 的设计有两个值得关注的要点：
显式建模用户的认知边界 ------known_info 只包含用户实际知晓的信息，飞行模式开启等故障原因不在其中。Agent 只能通过提问和引导用户查询来获取，而非被动接收完整需求。
事实锚定要求------模拟用户关于设备状态的回答必须以工具返回结果为依据。缺少这一约束时，模拟用户会顺应 Agent 的引导确认问题已解决，评估退化为两个模型之间的相互确认。
双控机制
telecom 领域引入了双控环境：模拟用户拥有独立的工具集（如 check_status_bar、toggle_airplane_mode），可以执行设备侧操作。这一设计使验证覆盖了"Agent 是否真的读到了用户侧的操作结果"------用户改变状态后，Agent 必须重新调用工具才能获知结果。
评估指标：Pass@k 与 Pass^k
书中区分了两种评估口径：
- Pass@k（能力上限）：同一任务运行 k 次，至少有一次通过即算通过。适合衡量探索时的能力天花板。
- Pass^k（业务可靠性）：同一任务连续运行 k 次，要求每一次都通过，且不能触发安全、合规或幻觉等一票否决项。适合支付、退款、权限变更等场景。
两者的数学关系很直观：
P a s s @ k = 1 − ( 1 − p ) k , P a s s k = p k \mathrm{Pass@k}=1-(1-p)^k,\qquad \mathrm{Pass^k}=p^k Pass@k=1−(1−p)k,Passk=pk
例如单次成功率 p=0.6、k=5 时，Pass@5 ≈ 99.0% 看起来几乎总能成功，但 Pass^5 ≈ 7.8% 说明连续五次都不出错仍然很难。
评估环境的五个组成要素
一个可重复运行的评估环境需要五个要素：
- 数据集：初始状态、工单、行为规范与验收标准打包为一条记录
- 环境状态：必须可重置，且状态变化符合业务逻辑
- 工具接口：原子操作，不存在"解决问题"这类高层抽象
- 评分标准：多维度检查加聚合规则
- 执行协议：交互顺序与终止条件
评估环境分为两类：人机交互型 （如 τ²-bench，需用户模拟器）和工具调用型（如 SWE-bench，正确性由执行验证决定）。
基准设计的横向对照
| 基准 | 被测能力 | 任务来源 | 验证器 |
|---|---|---|---|
| τ²-bench | 客服人机交互 | 人工编写+组合生成 | 四层检查→二元奖励 |
| SWE-bench Verified | 软件开发 | GitHub 真实 issue | FAIL_TO_PASS + PASS_TO_PASS |
| AndroidWorld | Android GUI 操作 | 参数化模板 | 最终 UI 状态断言 |
| OSWorld | Linux 桌面 GUI | 预置中间状态 | 134 个独立评估函数 |
| GAIA | 通用信息搜集 | 人工编写+附件 | 精确字符串匹配 |
SWE-bench Verified 将"修复完成"拆解为两个独立命题：FAIL_TO_PASS（证明问题已解决）和 PASS_TO_PASS（证明未引入新缺陷）。只检验前者，Agent 可以通过删改断言蒙混；两组同时检验才使"已修复"与"未破坏"各自可证。
数据泄漏防范
- GAIA 使答案无法从互联网直接检索------问题必须组合多个信息源才能作答
- AndroidWorld 以单个模板派生大量实例，参数每次不同
- Terminal-Bench 在题面中嵌入金丝雀标识符（canary GUID），若模型输出含该 GUID 即说明基准数据已进入训练集
自动化评估方法：从确定性验证到 LLM 评判
公开基准的验证器几乎都是确定性的------SWE-bench 运行测试套件，GAIA 做精确字符串匹配。代价是只能判断最终结果对不对，不能给出错误原因。
LLM-as-a-Judge 与 Rubric 设计
生产场景中，许多判断无法写成代码可检查的断言------投诉回复是否得体、调研报告是否遗漏关键信息。LLM-as-a-Judge 在自动化规模和人类专业判断之间取得平衡。
Rubric（评分标准）是 LLM 评判的依据，书中总结了四条设计准则：
- 基于专家指导------必须反映领域知识
- 全面覆盖------涵盖事实准确性、逻辑连贯性、完整性、安全性，明确陷阱（Pitfall）
- 按重要性加权------分为必要项、重要项、可选项、陷阱项，支持一票否决机制
- 评价标准自包含------每个评价项独立可操作，不依赖评价者的领域知识
LLM-as-a-Judge 的已知局限包括长度偏差（倾向给更长的回复打高分）和同源模型问题（Agent 与评判模型同家族时会利用评判模型的偏好）。缓解策略是多源异构评判------使用不同模型家族的多个 LLM 分别评判。
失败归因：从整条轨迹定位首个错误
端到端评估通常只给出"成功"或"失败"，但生产系统需要知道"为什么失败、从哪一步开始失败"。失败归因的核心是标出首个导致任务偏离的错误------后续错误往往只是连锁反应。
书中以 Coding Agent 为例，给出了实用的错误分类：
| 错误类别 | 典型表现 |
|---|---|
| 需求理解与歧义处理 | 漏掉需求条件、范围理解宽或窄 |
| 流程与规范缺失 | 未执行单元测试就提交 |
| 工具调用错误 | 同一文件反复编辑失败 |
| hack 验证环境 | 直接改断言、声称"测试已通过"但根本没跑 |
| 信息反馈错误 | 环境状态全对，但告诉用户的信息错了 |
归因记录需要结构化（JSON/YAML），引用具体步骤号、工具名和观察证据，并区分根因与后果。
轨迹前缀回归任务
除了端到端回归任务外，书中提出轨迹前缀回归任务 ------截取首个错误之前的状态，只验证那个决策边界是否被修好。答案应定义为可接受动作集合而非唯一答案，同时列出禁止动作。
统计显著性与配对比较
评估集有限、模型输出有随机性，因此分数差异可能只是抽样噪声。100 个用例、成功率 70% 时，95% 置信区间约为 70% ± 9 个百分点------"新模型 73% 对旧模型 70%"不足以支持切换。
比较两个配置时应优先做配对分析：逐题记录谁胜出，用 McNemar 检验或配对 bootstrap 判断差异。每个配置最好用多个随机种子（3-5 次），报告均值和波动范围。
配对比较由 LLM 完成时，还要防范位置偏差------评判模型系统性地偏向先出现的候选。标准缓解方法是交换顺序各评一次，取两次结果平均。
评估驱动的模型选型与成本分析
选型的关键维度
- 吞吐量与延迟：TTFT（首字延迟）、输入/输出吞吐量、p95 尾部延迟
- 成本：输入/输出/缓存 token 定价，需计算每个任务的平均成本和成本-性能比
- 性能：Pass@1、Pass@k、Pass^k，按场景选择
- 预算-能力曲线：短预算领先不能直接外推为长时间运行能力
成本的非线性增长
Agent 场景下的成本远比 token 定价复杂。上下文累积效应使每轮发送的 token 非线性增长------第 1 轮 1000 token，第 2 轮 2000 token，第 3 轮 3000 token。书中实测了一个八轮客服任务的成本：
| 方案 | 总成本 | 比基线节省 |
|---|---|---|
| 无缓存、无压缩 | $0.003776 | --- |
| 仅稳定前缀 | $0.002707 | 28.3% |
| 仅压缩历史 | $0.003115 | 17.5% |
| 稳定前缀 + 压缩 | $0.002643 | 30.0% |
值得注意的是，两项优化同时开启只节省 30%，并非各自相加------压缩历史同时缩短了可命中缓存的前缀。几项上下文优化同时使用时，必须在完整任务中一起实测。
从 Benchmark 到系统改进
书中用一个真实的 AndroidWorld 调优案例展示了从评估报告到系统改进的闭环：
三轮实验中，第一轮增加导航提示（H1）没有提高成功率，说明问题不在提示词；第二轮将 accessibility feed 换成 UIAutomator 元素树（H5），成功率从 25% 提到 100%，但 token 增至 2.5 倍；第三轮精简元素树（H5C），成功率不变，token 降至对照组的 0.5 倍。
关键经验是：看到 Agent 表现下降时，应先检查评测系统本身，再动 Agent。遇到失败时先找失败集中在哪些任务和能力上，再回放轨迹分清问题出在看、想、做还是验。
可观测性与内部评估基础设施
Agent 可观测性的数据基础是追踪（Trace），直接沿用分布式系统的 span 树模型：一次任务对应一条 trace，每个 LLM 调用和工具调用是一个 span。OpenTelemetry 是通用追踪标准，OpenInference 在其上定义了 LLM 应用的语义约定。
优秀的 Agent 产品还内建了持续自我评估的基础设施：
- 消融基础设施：每个主要特性可独立关闭，定期验证真实贡献
- AB 测试方法论：区分机制指标与目标指标，设置护栏指标
- 双层特性开关：编译时开关物理移除代码，运行时开关服务端下发
- 提示词敏感性评估：系统提示能确定性渲染，每次变更跑评估回归
小结
评估体系由四个环节构成：先厘清成功定义（Pass@k vs Pass^k），再确定任务来源（公开基准、自建业务集、生产轨迹回流），选定验证方式（从确定性验证器到 Rubric + LLM 评判），最后把分数转化为决策（统计显著性、失败归因、回归任务与模型选型）。核心方法论是"观察→假设→实验→验证→新认识→新假设"，使 Agent 工程从经验驱动的"炼金术"转向数据驱动的科学工程。
本文内容整理自开源技术书《深入理解 AI Agent》(bojieli/ai-agent-book)，采用 Apache 2.0 许可证