Agent评测
一句话理解
Agent 评测的重点，不是看模型"会不会回答"，而是看它能不能稳定地把事情做成。
因为 Agent 会多轮推理、调用工具、修改环境、连续决策，所以评测必须覆盖完整任务过程，而不能只看单次输出。
1. 总览：Agent 评测到底在评什么
以 Coding Agent 为例，评测时通常会给它任务、工具和可执行环境。Agent 在多轮交互中持续推理、调用工具、修改环境，并把结果写回环境，最后再通过测试或状态检查判断任务是否真正完成。
1.1 为什么比普通模型评测更复杂
| 维度 |
普通问答模型 |
Agent |
| 交互形态 |
单轮输出为主 |
多轮决策与行动 |
| 工具使用 |
通常没有或较少 |
高频调用工具 |
| 环境影响 |
基本不改环境 |
会持续修改环境状态 |
| 误差传播 |
单次输出误差 |
前一步错误会影响后续步骤 |
| 评分难点 |
看答案质量 |
看任务完成、过程稳定性、环境结果 |
1.2 核心判断
| 问题 |
结论 |
| 只看最终答案够吗 |
不够 |
| 只跑一次够吗 |
通常不够 |
| 只测模型本身吗 |
不是，测的是整体系统 |
| 评分规则能写死吗 |
不能完全写死，要防止误伤有效但非预设路径的解法 |
⚠️ Agent 评测要同时关注最终结果、执行过程、稳定性，以及评分规则是否真正符合用户价值。
2. 三个关键定义
| 概念 |
含义 |
直观理解 |
| 评测框架（Evaluation Harness） |
提供任务、工具、环境，执行测试，记录过程并汇总结果 |
整套评测流水线 |
| Agent 框架（Agent Harness / Scaffold） |
让模型以 Agent 方式运行，包括输入处理、工具调度、多轮交互管理 |
Agent 的运行系统 |
| 评测套件（Evaluation Suite） |
围绕某类能力设计的一组任务集合 |
一套题库 |
2.1 常见术语
| 术语 |
含义 |
实际作用 |
| 任务（Task） |
一个独立测试用例，包含输入、环境和成功标准 |
定义"测什么" |
| 试验（Trial） |
对同一任务的一次运行 |
处理随机性 |
| 评分器（Grader） |
负责给任务结果打分的规则或程序 |
定义"怎么判" |
| 转录（Transcript / Trace） |
一次试验的完整过程记录 |
用于排查失败原因 |
| 结果（Outcome） |
试验结束时环境的最终状态 |
判断任务是否真的完成 |
2.2 最容易忽略的一点
评测对象不是"裸模型"，而是下面这套整体：
| 被评对象 |
说明 |
| 模型 |
推理和生成能力 |
| Agent 框架 |
决定如何拆解任务、调用工具、管理多轮 |
| 工具系统 |
决定能做什么、怎么做 |
| 环境配置 |
决定任务能否稳定复现 |
所以同一个模型，换一个 scaffold、工具协议或环境隔离方式，成绩可能完全不同。
3. 为什么必须做评测
3.1 没有评测时的常见问题
| 问题 |
后果 |
| 用户投诉后才发现问题 |
响应被动 |
| 手动复现成本高 |
排查慢 |
| 修旧问题引入新问题 |
容易回归 |
| 无法判断改动是否真的有效 |
迭代失真 |
| 难比较模型、提示词和 Agent 方案 |
决策低效 |
3.2 建立评测后的价值
| 价值 |
说明 |
| 定义成功标准 |
明确什么叫"任务完成" |
| 自动验证 |
上线前批量检查场景 |
| 指标量化 |
成功率、错误率、延迟、Token、成本等可追踪 |
| 方案对比 |
更容易比较模型、提示词、工具链 |
| 回归保护 |
为升级和调优提供安全网 |
评测的价值贯穿 Agent 全生命周期：前期帮助定义成功标准，后期帮助稳定扩展规模。
4. 三类常见评分器
4.1 评分器对比
| 类型 |
常见方法 |
优势 |
劣势 |
适合场景 |
| 基于代码的评分器 |
字符串匹配、单元测试、静态分析、状态检查、工具调用检查、日志分析 |
快、便宜、客观、可重复 |
灵活性有限，难处理开放任务和细微质量差异 |
编程类、规则明确任务 |
| 基于模型的评分器 |
标准打分、自然语言断言、成对比较、参考答案评估、多评委共识 |
灵活、可扩展，适合开放任务 |
非确定性强、成本更高、需要校准 |
对话、研究、开放输出 |
| 人工评分器 |
专家审查、众包判断、抽样检查、A/B 反馈、一致性检查 |
最接近真实判断，可做黄金标准 |
成本高、速度慢、难规模化 |
高风险任务、抽检、校准 |
4.2 实用选择原则
- 能用确定性评分器，就优先用确定性评分器
- 需要灵活判断时，再引入模型评分器
- 关键任务或高风险场景，再用人工评分校准
5. 两类核心评测目标
| 类型 |
要回答的问题 |
通过率特点 |
主要用途 |
| 能力评测（Capability / Quality Eval） |
这个 Agent 哪些方面强，哪些方面还不够强 |
通常不会太高 |
找短板、看上限、找提升空间 |
| 回归评测（Regression Eval） |
以前能做好的事，现在还能不能稳定做对 |
通常接近 100% |
防止退步、做版本安全网 |
5.1 两者关系
| 维度 |
能力评测 |
回归评测 |
| 看什么 |
上限 |
底线 |
| 题目难度 |
偏难 |
偏稳定、偏已验证 |
| 主要作用 |
暴露增长空间 |
守住已有能力 |
当某些能力任务长期高通过后，可以"毕业"为回归任务，用来监控长期漂移。
6. 四类主流 Agent 怎么评
| Agent 类型 |
核心评测重点 |
常用评分方式 |
常见 Benchmark |
| 编程 Agent |
代码能否运行、测试是否通过、功能是否可用、工具调用是否合理 |
确定性评分为主，必要时补充 LLM 质量评分 |
SWE-bench Verified、Terminal-Bench |
| 对话 Agent |
问题是否解决、是否在合理轮数内完成、语气和策略是否合适、工具使用是否一致 |
LLM 模拟用户 + 规则/模型混合评分 |
tau-Bench、tau2-Bench |
| 研究 Agent |
事实性、覆盖率、来源质量、综合分析质量 |
多评分器组合，常需人工校准 |
BrowseComp |
| 电脑操作 Agent |
是否完成真实任务链、页面或系统状态是否正确变化、成本和延迟是否合理 |
环境状态检查 + 轨迹分析 |
WebArena、OSWorld |
6.1 各类 Agent 的实际抓手
| 类型 |
更具体的抓手 |
| 编程 Agent |
单元测试、静态分析、数据库/日志/配置状态、工具调用链、是否存在无意义反复试错 |
| 对话 Agent |
工单是否关闭、是否越权、是否轮数过多、语气是否清晰礼貌、工具调用是否贴合对话 |
| 研究 Agent |
是否给出来源、关键点是否覆盖、来源是否可信、结论是否有证据支撑 |
| 电脑操作 Agent |
URL/页面状态、后端状态是否变化、是否完成整条任务链、DOM 交互与视觉交互的效率权衡 |
7. 如何理解非确定性
同一个 Agent 在同一个任务上，多次运行结果不一致，是常态，不是例外。
7.1 主要来源
| 来源 |
说明 |
| 模型随机性 |
同样输入可能给出不同决策 |
| 多轮放大效应 |
早期误差会在后续步骤累积 |
| 工具与环境波动 |
调用结果、状态变化会影响后续路径 |
7.2 常用指标
| 指标 |
含义 |
更适合的场景 |
pass@k |
k 次尝试中，至少一次成功的概率 |
允许多试几次、成功一次就有价值的任务 |
pass^k |
k 次尝试中，每一次都成功的概率 |
对一致性和稳定性要求很高的任务 |
7.3 怎么理解 pass@k 和 pass^k
| 问题 |
更对应的指标 |
| 这项能力有没有 |
pass@k |
| 这项能力稳不稳定 |
pass^k |
对最终用户来说，pass^k 往往更接近真实体验，因为用户关心的是"这次用就得成"。
8. 从 0 到 1 搭建高质量 Agent 评测
8.1 整体路线
| 阶段 |
核心任务 |
关键要求 |
| 搭任务集 |
从真实场景收集 case |
真实、可验证、与用户影响相关 |
| 搭评测框架 |
建环境、调度、记录、汇总 |
稳定、隔离、可追踪 |
| 细化评分器 |
定义怎么判成功和失败 |
优先确定性，防误判、防刷分 |
8.2 初始任务集从哪里来
| 来源 |
价值 |
| 手动测试清单 |
容易快速启动 |
| 高频用户任务 |
最贴近真实价值 |
| Bug 跟踪系统 |
直接对应历史失败 |
| 客服/支持工单 |
补充真实边界问题 |
| 用户失败案例 |
常是高价值 bad case |
8.3 好任务的要求
| 要求 |
说明 |
| 指令明确 |
不靠猜 |
| 成功标准清晰 |
能清楚判断是否完成 |
| 尽量无歧义 |
降低错判 |
| 最好有参考答案 |
便于一致评审 |
| 同时覆盖正例和反例 |
避免把 Agent 优化偏 |
理想状态是，两位领域专家独立评审，也能得出一致结论。
8.4 评测框架设计原则
| 原则 |
说明 |
| 环境尽量贴近生产 |
结果更有参考价值 |
| 每次运行从干净环境开始 |
避免残留状态污染结果 |
| 避免共享状态 |
减少额外噪声 |
| 记录完整轨迹 |
方便排查失败原因 |
| 先确定性、后模型评分 |
提高稳定性和可解释性 |
| 关键场景加人工验证 |
防止自动化误导 |
⚠️ 一个典型坑是环境没隔离好，导致 Agent 利用了上一次试验残留信息，分数虚高。
8.5 评分器设计原则
| 原则 |
含义 |
| 评结果，少评路径 |
不要把完成方式写死 |
| 多阶段任务设置部分得分 |
便于看清卡在哪一步 |
| 仔细排查评分器本身的 bug |
防止错判 |
| 防止投机刷分 |
防止 Agent 利用规则漏洞 |
强模型常会找到设计者没预料到、但同样有效的完成方式，所以"评结果而不是评路径"非常关键。
8.6 任务始终 0% 成功时先查什么
| 优先检查项 |
为什么先查 |
| 任务本身是否可完成 |
可能题目就不可解 |
| 参考答案是否合理 |
可能目标定义错了 |
| 评分器是否配置正确 |
可能是错判，不是 Agent 真失败 |
9. 评测要和其他方法结合
自动化评测很重要，但不是全部。
| 方法 |
作用 |
局限 |
| 自动化评估 |
快速迭代、重复执行、大规模覆盖 |
需要前期建设，且不一定完全等于真实使用 |
| 生产监控 |
观察真实用户行为和线上错误 |
发现问题较被动，信号也可能有噪声 |
| A/B 测试 |
比较不同版本在真实流量中的效果 |
成本较高，反馈更慢 |
| 用户反馈 |
暴露意料之外的问题 |
稀疏、非结构化、偏被动 |
| 人工记录审查 / 系统化人工研究 |
补充自动评测看不到的细微质量问题，并用于校准标准 |
耗时、昂贵、难扩展 |
9.1 瑞士奶酪模型
| 层次 |
主要作用 |
| 自动化评测 |
上线前和 CI/CD 中持续发现回归与显性错误 |
| 生产监控 |
上线后发现分布漂移、异常失败和真实使用问题 |
| A/B 测试 |
在真实流量下验证重大改动是否真的更优 |
| 用户反馈与轨迹审查 |
补充自动化覆盖不到的边角问题 |
| 系统性人工研究 |
校准 LLM 评分器，评估主观质量和复杂行为 |
核心意思只有两点：
- 没有单一方法能抓住全部问题
- 多层方法叠加后，才更接近可靠质量保障
10. 长期维护比第一次搭建更重要
10.1 长期维护重点
| 重点 |
为什么重要 |
| 读转录轨迹 |
只看分数，很难知道是 Agent、评分器还是任务出了问题 |
| 监控评测是否饱和 |
长期接近满分的题集不再提供改进信号 |
| 持续补充新失败样本 |
防止评测老化 |
| 让更多角色参与贡献任务 |
更接近真实产品需求和用户问题 |
10.2 谁应该参与贡献任务
| 角色 |
价值 |
| 产品经理 |
更清楚用户目标和关键路径 |
| 客户成功 |
更了解高频问题 |
| 支持团队 |
更接近真实报错与失败场景 |
| 销售或前线使用者 |
更容易发现落地阻力和边界 case |
离用户越近的人，越容易提出高价值测试任务。
11. 可参考的框架与工具
如果不想从零搭基础设施，可以参考这些方案：
| 工具 / 框架 |
特点 |
适合团队 |
Harbor |
面向容器化环境，支持跨云厂商大规模跑试验 |
重视环境隔离和规模化运行的团队 |
Promptfoo |
轻量、开源、YAML 配置，上手快 |
想快速启动评测的团队 |
Braintrust |
离线评估、生产可观测性、实验追踪一体化 |
想把评测和线上观测连起来的团队 |
LangSmith |
与 LangChain 生态集成紧 |
已在用 LangChain 体系的团队 |
Langfuse |
自托管开源方案 |
对数据驻留、自建基础设施有要求的团队 |
但工具只是加速器，不是答案本身。真正决定效果的，还是任务质量、评分器设计、失败样本积累和持续迭代机制。
12. 补充：Agent 时代评测的"变与不变"
补充材料最重要的观点是：
💡 Agent 时代，评测的底层哲学没变，但执行方式、自动化程度，以及它和研发流程的关系，已经明显变了。
12.1 不变的部分：科学评测的底层原则
| 原则 |
含义 |
| 评测的终极产出不是报告，而是迭代闭环 |
更重要的是缩短发现问题、定位根因、修复、验证的总周期 |
| 评测集要略微领先于当前能力 |
只有这样才能持续暴露"还不会"的部分 |
| 好评测集要故意比真实世界更难 |
极端、复杂、边界 case 更能拉开能力差距 |
| 评测集应尽量以真实数据为主 |
评测集规模小，更值得投入高质量人工成本 |
再好的总分，也替代不了 look at your data |
必须能从 bad case 回溯到根因 |
12.2 为什么评测集要比真实世界更难
| 原因 |
说明 |
| 真实世界最贵的问题往往不是高频简单问题 |
贵的是复杂和边界场景 |
| 真正区分系统上限的通常是偏难题 |
容易题只能说明"基础还行" |
13. Agent 正在重写评测执行链路
13.1 执行链路的变化
| 环节 |
过去 |
现在/趋势 |
| 数据采集与标注 |
人工主导挖 case、清洗、标注 |
自动化漏斗：抓取、清洗、预标注、人工只审高价值样本 |
| Trigger |
关键词、规则、脚本匹配 |
语义触发，由小模型或 Agent 判断是否有评测价值 |
| 打分 |
LLM-as-Judge 为主 |
向 Agent-as-Judge 演进，可读长轨迹、比较多候选、输出结构化判断 |
| 运行 |
死脚本执行 |
Agent 看护评测过程，重试、重启、补操作 |
| 报告 |
静态网页或分数表 |
可交互工作台，支持下钻、回放、按任务类型定制展示 |
13.2 Agent-as-Judge 为什么重要
| 优势 |
适合场景 |
| 能读长轨迹 |
多轮复杂任务 |
| 能比较多个候选答案 |
没有唯一标准答案的任务 |
| 能做结构化判断与汇总 |
需要综合多个模型结果的复杂评审 |
一个实用思路是：用顶尖模型作为参照系，让多个模型投票或求最大公约数，再由下游 Agent 聚类、汇总并生成报告。
13.3 双层 Agent 看护评测
| 角色 |
作用 |
| 执行看护 Agent |
在评测执行过程中负责重试、重启、补操作 |
| 验收 Agent |
在后处理阶段检查 trace 和结果 |
这对长批量、端到端评测特别有用，因为它把"执行环境脆弱"也纳入了自动修复链路。
14. 一个更强的方向：评测直接驱动自动改代码
这是补充材料里最值得单独记住的新增观点。
14.1 闭环正在变化
| 传统闭环 |
新闭环 |
| 发现 bad case |
评测自动发现 bad case |
| 人工排查 |
Agent 自动进入代码库分析问题 |
| 人工改 prompt / harness / 编排代码 |
自动修改 prompt、harness 或相关代码 |
| 人工回归验证 |
自动跑测试验证 |
核心意思是：在 AI coding 时代，一套好的 Agent 评测集加上自动评价器，已经可以直接接到代码迭代链路里，评测开始从"发现问题"走向"驱动修复"。
15. 最值得记住的结论
| 结论 |
解释 |
| Agent 评测看的是任务完成能力 |
不是单次回答质量 |
| Agent 必须做端到端评测 |
因为它是多轮行动系统 |
| 评测是迭代、上线和升级模型的基础设施 |
不是锦上添花 |
| 评分器通常要组合使用 |
代码、模型、人工各有边界 |
| 能力评测和回归评测要一起跑 |
一个看上限，一个守底线 |
| 非确定性是常态 |
要通过多次运行和合适指标理解结果 |
| 不只看分数，要读轨迹 |
否则很难定位根因 |
| 自动化评测要和生产监控、人工审查结合 |
才能形成完整质量保障 |
16. 可以直接带走的落地原则
- 尽早开始，不要等完美体系
- 优先从真实失败和高频任务里收集 case
- 给每个任务写清楚成功标准，尽量避免歧义
- 先用确定性评分器，再逐步补充 LLM 和人工评分
- 环境必须隔离，评测过程必须可追踪
- 能力评测和回归评测要同时跑
- 不只看分数，一定要读转录轨迹
- 把自动化评测、生产监控和人工审查组合起来看
