Agent 评估方法：评估环境、验证器与统计显著性

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 必须重新调用工具才能获知结果。评估指标Passk 与 Pass^k书中区分了两种评估口径Passk能力上限同一任务运行 k 次至少有一次通过即算通过。适合衡量探索时的能力天花板。Pass^k业务可靠性同一任务连续运行 k 次要求每一次都通过且不能触发安全、合规或幻觉等一票否决项。适合支付、退款、权限变更等场景。两者的数学关系很直观Passk1−(1−p)k,Passkpk\mathrm{Passk}1-(1-p)^k,\qquad \mathrm{Pass^k}p^kPassk1−(1−p)k,Passkpk例如单次成功率 p0.6、k5 时Pass5 ≈ 99.0% 看起来几乎总能成功但 Pass^5 ≈ 7.8% 说明连续五次都不出错仍然很难。评估环境的五个组成要素一个可重复运行的评估环境需要五个要素数据集初始状态、工单、行为规范与验收标准打包为一条记录环境状态必须可重置且状态变化符合业务逻辑工具接口原子操作不存在解决问题这类高层抽象评分标准多维度检查加聚合规则执行协议交互顺序与终止条件评估环境分为两类人机交互型如 τ²-bench需用户模拟器和工具调用型如 SWE-bench正确性由执行验证决定。基准设计的横向对照基准被测能力任务来源验证器τ²-bench客服人机交互人工编写组合生成四层检查→二元奖励SWE-bench Verified软件开发GitHub 真实 issueFAIL_TO_PASS PASS_TO_PASSAndroidWorldAndroid GUI 操作参数化模板最终 UI 状态断言OSWorldLinux 桌面 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 定价需计算每个任务的平均成本和成本-性能比性能Pass1、Passk、Pass^k按场景选择预算-能力曲线短预算领先不能直接外推为长时间运行能力成本的非线性增长Agent 场景下的成本远比 token 定价复杂。上下文累积效应使每轮发送的 token 非线性增长——第 1 轮 1000 token第 2 轮 2000 token第 3 轮 3000 token。书中实测了一个八轮客服任务的成本方案总成本比基线节省无缓存、无压缩$0.003776—仅稳定前缀$0.00270728.3%仅压缩历史$0.00311517.5%稳定前缀 压缩$0.00264330.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 测试方法论区分机制指标与目标指标设置护栏指标双层特性开关编译时开关物理移除代码运行时开关服务端下发提示词敏感性评估系统提示能确定性渲染每次变更跑评估回归小结评估体系由四个环节构成先厘清成功定义Passk vs Pass^k再确定任务来源公开基准、自建业务集、生产轨迹回流选定验证方式从确定性验证器到 Rubric LLM 评判最后把分数转化为决策统计显著性、失败归因、回归任务与模型选型。核心方法论是观察→假设→实验→验证→新认识→新假设使 Agent 工程从经验驱动的炼金术转向数据驱动的科学工程。本文内容整理自开源技术书《深入理解 AI Agent》(bojieli/ai-agent-book)采用 Apache 2.0 许可证