Agent的开发，本质上是一场与不确定性博弈的过程。
而评测，正是这场博弈中最关键、也最容易被低估的能力。
本文我会从 why / what / how 三个维度，深度剖析Anthropic最新发布的万字评测方法论，包含多种类型和场景。
最后会提供一份从0到1打造优秀评测体系的路线图。
Why: 为什么要建立评测？
大多数团队都忽视了benchmark的重要性，甚至将严格的评测视为减缓交付不必要的开销。
临界点发生在“自我感觉良好”到“出现故障越改越糟”，在没有评测指标的情况下，调试是极其被动的。
盲目调试无法区分真正的退化与噪音，无法在发布前自动测试更改对数百种场景的影响，也无法衡量改进程度。
那么有评测（evals）呢，不限于如下3点优势：
- 让团队“看得见”质量变化，把主观感受变成客观指标，避免盲目迭代，清晰区分“真实回归”与“随机波动”。
- 评测是Agent规模化迭代的加速器，轻松获取质量基准与回归影响（延迟、令牌使用量、每项任务的成本和错误率），快速判断新模型是否值得切换、优势在哪、短板在哪。
- 评测也是产品团队、工程团队、算法团队之间的沟通利器，轻松对齐Agent成功标准、边界条件和期望行为。
What：评测是什么
既然评测这么重要，那么评测是什么呢？
评测（eval）简单来说，是给AI系统一个输入，然后对其输出打分衡量成功。
在实践中，是建立一套在开发过程中无需真实用户即可运行的自动化评测系统。
简单的AI系统单轮评估就可以，如下图Single-turn所示，一句prompt得到一个响应，设置一个评分逻辑。
Agent系统则更为复杂，多次调用工具、修改环境状态，并不断循环调整，这就可能导致错误蔓延和累积。
先来了解一下在构建Agent评测时，几个概念：
- 任务（Task）：用例case，明确定义输入和成功标准的单一测试；
- 试验（Trial）：对同一任务的一次完整执行。由于模型的随机性，需要多次试验以获得更一致的结果；
- 评分器（Grader）：用于评估Agent表现的评分逻辑。一个任务可以包含多个评分器，每个评分器由多个断言（Assertions）构成，检查不同维度表现。
- 运行轨迹（Transcript）：记录Agent一次试验的完整执行过程，包含模型输出、工具调研、推理步骤、中间结果及其他交互信息。
- 结果（Outcome）：试验结束时环境的最终状态。比如AI说已完成航班预订，在数据库中是否存在预定。
- 评测运行环境（Harness）：评测的基础设施，提供指令和工具、并行运行任务、记录执行过程、评分输出并汇总结果。
- 评测集（Evaluation Suite）：衡量特定功能或行为的任务集合，多个任务共享一个评测目标，用于系统性衡量Agent的整体表现。
How：如何评测AI Agents
Agent评测通常组合这三种类型的评分器：基于代码的、基于模型的，以及人工打分。
对于不同的任务，评分可以是加权的（组合评分器分数必须达到阈值）、二元的（所有评分器必须通过）或混合的。
当然，测评也离不开常规的能力评测和回归评测：
- 能力评测关注该Agent擅长做什么，设定一些有挑战性的任务。
- 回归评测是在每次修改后回归一下之前的任务，避免引起其他问题。
接下来我们依次看下目前常见类型的Agent如何评测，包括：编程智能体、对话智能体、研究智能体，以及使用计算机的Agents。
01 评测编程智能体
针对Coding Agent的评测依赖于明确指定的任务、稳定的测试环境，以及生成代码的全面测试。
因为代码是否运行、测试是否通过，都是明确的，所以需要确定性的评分器。
目前编程Agent广泛使用的两种基础测试，SWE-bench Verified和Terminal-Bench，都遵循这种方法。
- SWE-bench Verified：向Agent提供主流phthon仓库的github问题，通过运行测试任务组来评分，只有修复了bug且没有破坏现有功能，才算通过。一年内，这项评估表现已从40%提升至80%+。
- Terminal-Bench：测试端到端的技术任务，例如从源代码构建linux内核或训练机器学习模型。
在实践中，编程任务会从三个方向测评，优先做单元测试验证代码正确性，并使用LLM评分标准评估代码质量，在需要时添加额外的评分器和指标评测过程**。**
02 评测对话智能体 对话Agent与传统聊天机器人不同，Agent维护状态、使用工具，并在对话中途采取行动。 对话智能体有一个独特的挑战是：交互的质量也是要评测的部分。 因此对话智能体必须同时评测结果和交互过程，甚至需要用另一个 LLM 来扮演用户，通过长时间的对抗性对话来测试模型效果。 基准测试可以参考𝜏-Bench 及其后续版本τ2-Bench，模拟了跨零售支持、航空预订等领域的多轮交互。 评测维度参考如下： • 状态检查：比如是否订票成功 • 文本约束：是否在10轮内完成 • LLM评分：语气是否恰当 以“处理沮丧客户退款请求”为例，评分器设计如下：
03 评测研究智能体
**状态检查：比如是否订票成功**
-
•
文本约束：是否在10轮内完成
-
•
LLM评分：语气是否恰当
Research Agent收集、综合和分析信息，然后产出答案或报告。
研究质量的评测无法像代码一样做二元判断，而需要通过任务评估：什么算是“全面的”、“有良好来源的”、“正确的”。
构建Research Agent评估的一种策略是结合不同类型的评分器。
三种关键检查维度：
- 有依据性检查：验证是否真的能在它引用/检索的资料中找到依据；
- 覆盖度检查：定义了一个优质答案必须哪些关键事实，避免漏掉核心信息；
- 来源质量检查：确认所参考的来源是否权威
如果是客观、有单一正确答案的问题，没必要复杂化，直接精确匹配即可。
LLM在这里扮演一个结构化质检员，用于标出没有证据支持的说法、该讲没讲的重点、评测综合性回答是否逻辑连贯、信息完整。
此外，由于研究质量的主体性，基于LLM的评分标准应该频繁与人类专家进行校准。
04 评测GUI智能体
GUI Agent通过模仿人类使用电脑软件——截图、键盘键入、鼠标点击和滚动...
评测需要在真实或沙盒环境中运行Agent，使其能够使用任何具有GUI的应用程序，并检查是否达到预期结果。
比如WebArena和OSWorld测试：
- WebArena：浏览器任务测试，基于 URL 和页面状态来验证前端执行，通过修改数据的后端状态验证任务是否完成任务。比如：确认订单实际提交，而不仅仅是确认页面出现。
- OSWorld：完整的操作系统控制，在执行完脚本完成任务后检查文件系统状态、应用程序配置、数据库内容和 UI 元素属性。
浏览器任务操作需要在token和延迟之间权衡：
- 基于DOM的交互执行速度快但消耗大量token（适合文本类任务，如总结维基百科信息）
- 基于截图的交互速度较慢但token消耗少（适合图片比如在亚马逊上寻找新手机壳）
所以评测时需要检查Agent是否选择了正确的工具。
05 非确定性测评
由于Agent每次运行都存在不确定性，想要测量Agent在某个任务上的成功频率，可以使用pass@k和pass^k两个指标：
随着试验次数的增加，两者的变化趋势如下图。
从0到1构建优秀评测路线图
接下来，我们看下构建一个评测驱动的Agent开发路线图：早期定义成功，清晰衡量，并持续迭代。
阶段一：构建评测数据集
Step 0 少量测试集启动
将产品需求转换为20-50个简单任务就是一个好开始。
因为早期Agent开发中，每次微小的变更都会系统有明确、显著的影响，前期小样本就足够了。
Step 1 人工深度评测
“Look at your data.”
打造AI产品就一定要亲自深度使用，分析Agent执行轨迹各个节点的信息，并将线上问题转换为测试用例。
Step 2 明确任务标准
评测任务需要有明确的标准。
如果一个任务让两个专家得出了不一致的答案，那不是Agent问题，而是任务问题。
评测的所有内容都应该在任务描述中显式说明，不能有默认路径、默认文件名、默认状态等。
一个小tips：为每个任务创建参考答案（reference solution），证明任务是可解的，并验证评分器设计正确。
Step 3 构建均衡的问题集
评测不能只奖励一种行为，否则模型会无限放大该行为。
比如测试“该搜索时有没有搜索？”，那么模型学到的最优策略是“那我干脆什么都搜索吧。”
所以，在设计测试case时，同一个能力必须同时覆盖“正例”和“反例”。
- “该搜索的时候一定搜索”
- “不该搜索的时候坚决不搜”
出现问题需要修改prompt与调整eval之间多轮迭代，Agent效果 = prompt ✖️ eval 共同塑形。
此外，评测数据集不是一次性设计，随着更多case出现，持续丰富eval suite提升覆盖范围。
阶段二：设计评测系统
Step 4 构建稳定的测评环境
测评环境要与生产环境一致，避免测试环境引入的噪声。
此外，每一次试验都必须是干净隔离的，避免不必要的共享状态（如遗留文件、缓存数据、资源耗尽等）引起不稳定性。
Step 5 精心设计评分器
如何判分呢？这是设计哲学，也是成本✖️稳定性✖️可信度的平衡。
Anthropic给出了三条大原则：
- 优先使用确定性规则，快、便宜、可复现；
- 必须有灵活性或主观判断时，才引入LLM评分；
- 人类只做校准、兜底和抽查；
在设计评分器时，有如下5条经验：
- Agent有灵活性，避免锁死路径，优先看结果；
- 针对多步骤任务，一定要设计「部分评分机制」，看中间步骤执行情况；
- LLM评判需要人类校验，避免幻觉式评分和硬判分数；
- 低分先怀疑eval，再怀疑Agent；
- Agent是个聪明对手，假设它会作弊，设计上要提防漏洞、边界等；
阶段三：长期维护与使用
Step 6 定期查看日志
当分数低时，问题出在agent? prompt? harness? grader?
这就需要定期查看Agent行为轨迹日志（transcript），从行为细节中获取低分真相：
- Agent奇怪但合理的解法
- Prompt中某句话被模型误解的方式
- Eval harness的隐含约束
- grader的边界bug
真正重要的改进点不会直接体现在分数上，而是在transcript中。
Step 7 监控能力评测“饱和”
当eval通过率接近100%时，就已经从「能力评测」退化到「回归测试」了。
随着评测接近饱和，分数变化不明显，剩下的要么是极端困难任务，要么是评测本身设计有问题。
以SWE-Bench为例，从30%优化到80%后，再往上每提升1%，需要巨大的工程、推理、规划能力跃迁，但在分数上几乎看不出来。
这时候就需要深入研究评测细节和行为日志，设计一个新的评测框架。
Step 8 开放贡献和长期维护
评测不是项目交付物，而是长期资产。
在Anthropic，建立了专门评测团队来负责基础设施，同时领域专家和产品团队负责贡献大部分评测任务并自行运行评测。
以评测驱动开发：在Agent能够实现这些功能之前，先构建评测来定义计划中的能力，然后不断迭代直到Agent表现良好。
比如基于对几个月后模型能做什么的预测，设计一些功能任务，当有新模型发布时，运行评测集可以快速揭示哪些赌注成功了。
此外，最接近产品需求和用户的人最适合定义任务，需要让更多的人参与评测集的构建。
阶段四：完备的优化
自动化评测，是 Agent 在上线前最重要的质量底座。
但要真正理解一个 Agent 的完整性能，还必须结合生产监控、用户反馈、A/B 测试、人工转录审查以及系统化的人类评估，形成多层次的评估体系。
这些方法，分别对应着智能体开发的不同阶段：
-
发布前 & CI/CD 阶段
自动化评测是防止质量问题的第一道防线。每一次 Agent 改动、Prompt 调整或模型升级，都会触发评测，确保问题在触达用户前被发现。
-
发布后运行阶段
生产监控用于捕捉分布漂移和真实环境中的异常行为，弥补离线评测无法覆盖的现实复杂性。
-
流量充足、验证重大改动时
通过 A/B 测试，在真实用户场景中比较不同方案的效果，用数据验证决策。
-
持续运营过程中
用户反馈和对话转录审查是长期机制：持续分流和分析用户反馈，每周抽样阅读对话记录，必要时深入追查潜在问题。
-
主观性强或高风险场景
系统化的人类评估作为“最后的校准器”，用于校准 LLM 评分器，或评估高度主观的输出质量，以人类共识作为最终参考标准。
最后，如果你也对Agent感兴趣，欢迎添加我的微信floracat2025。