Demystifying Evals for AI Agents 技术阅读

Agent 可以生成令人信服的完成说明，也可以留下未完成的文件、错误的订单或没有依据的研究结论。Anthropic 的这篇文章把评测对象拆成任务、试验、轨迹、环境结果和评分器，要求评价模型与运行框架共同完成的行为。它还解释了怎样组合程序检查、模型裁判与人工校准，怎样处理多次运行的不确定性，以及怎样维护能够持续发现问题的任务集。

对正在开发 Agent、训练或微调模型的读者，评测决定优化目标是否正确。训练损失下降、工具调用更整齐或公开榜单更高，都不足以单独回答自己的系统有没有进步。需要固定一组有明确成功条件的任务，保存运行证据，再判断一次改动提高了哪些能力、损害了哪些已有行为。

评测单元从一条回答扩展到一次完整执行

单轮问答可以把输入送给模型，再比较回答。Agent 会读取材料、调用工具、改变环境并继续做决定。错误可能逐步传播，正确方案也可能与设计者预想的路径不同，因此评测需要记录完整交互和最终环境状态。

先看原文中的组成关系。任务规定初始条件，trial 执行一遍 Agent 循环，grader 对轨迹或结果做判断，harness 管理运行和聚合。

来源：原文，Components of evaluations for agents；归档 PDF 第 4 页。

区分两个 harness 尤其重要。一个 Agent 的运行框架可能决定工具格式、上下文截断、错误重试和停止策略；评测框架决定试验环境、评分与汇总。即使底座模型相同，这些条件变化也可能改变分数。模型微调前后对比，应记录两套框架的版本和预算，避免将基础设施差异误认为权重收益。

怎样把成功标准变成评分器

程序评分：明确条件交给明确检查

程序评分可以检查字符串、单元测试、静态分析、工具参数、数据库状态和轨迹统计。代码 Agent 修复缺陷时，已有失败测试应转为通过，原本通过的测试继续通过。前者检查目标是否实现，后者检查是否引入回归。

优势是便宜、快速、易于定位错误。限制是判定可能过于狭窄。只按特定文件名、精确措辞或唯一工具顺序判断，会拒绝其他有效方案。原文提到，任务若没有说明输出路径，评分却暗中要求某路径，失败来自任务与评分约定不一致。

程序评分的输入需要与目标一致。检测到工具调用只证明发生过调用；数据库状态可以支持操作是否完成；完整测试套件则验证代码在特定条件下的功能。不要用较弱证据代替较强结论。例如看到 process_refund 被调用，仍需要检查实际退款状态和金额。

模型评分：把开放判断拆成有依据的维度

模型评分可以使用明确 rubric、自然语言断言、两份答案的成对比较、参考答案或多个裁判。研究报告的覆盖、论证连贯性和引用支持关系，都可能需要这类判断。

裁判需要获得足够证据。若判断回答是否被来源支持，应提供相应检索材料和待检查主张；若评估代码质量，应提供相关实现或差异。只给最后一段回答，要求裁判判断全过程是否可靠，信息通常不够。

原文建议按维度拆开评分，并允许证据不足时返回 Unknown。这样可以区分“没有完成”“没有证据确认”和“评测基础设施失败”，避免裁判强行给出确定判断。不同维度分开审查，也便于定位长报告中是哪条主张缺乏支持。

模型裁判存在随机性和偏差，需要与人工判断校准。校准要抽取多种成功、失败和边界案例，检查裁判是否将语言流畅度当成正确性，是否偏爱某种风格，是否会漏看违反硬约束的内容。反复调裁判直到分数好看，不能替代人工一致性检查。

人工评分：校准主观维度与专业判断

人工可用于领域专家审查、抽样检查、标注一致性或系统化用户研究。它能帮助定义复杂任务中什么叫有效结果，也能发现自动评分忽略的问题。代价是慢、昂贵，且人之间也可能意见不一致。

专家分歧本身需要记录。若两名专家对同一报告是否通过无法达成一致，就要检查 rubric 是否模糊、任务是否缺少用途背景，或该判断天然属于多维偏好。把一个争议很大的人工分数作为唯一训练奖励，会把不稳定标准传播到模型优化中。

任务可以按加权总分、全部通过或混合方式验收。硬约束适合单独检查；质量维度可以使用部分分数。若未经授权修改了环境，再高的表达分也不能抵消该失败。具体权重由任务目标决定，原文没有要求所有 Agent 使用相同评分公式。

四类 Agent 的评测设计怎样变化

代码 Agent：功能结果与代码质量分开

代码任务通常拥有可运行检查。SWE-bench Verified 用仓库问题与测试验证修复，Terminal-Bench 则覆盖更广的终端任务。阅读原文中的模型成绩，应保留其文章时间，不能当成当前榜单。

核心检查可以围绕目标功能与既有行为，再根据需要增加静态分析或模型 rubric。原文给出的 YAML 演示包含多类 grader，作者同时说明实际任务不必全部使用。若目标可以由测试和少量质量判断覆盖，不需要为了形式把所有评分工具加入流程。

轨迹能帮助判断为什么失败，例如有没有阅读错误文件、是否在环境错误后仍然盲目继续。一般功能任务应优先检查产物；只有流程本身是要求时，才强制必要步骤，例如身份验证或指定授权检查。原文提醒，严格规定所有工具调用的固定顺序容易惩罚有效的新方案。

对话 Agent：交互质量也是结果的一部分

客服、销售或辅导 Agent 既需要行动成功，也需要合理沟通。退款任务可能检查退款记录已处理、解释准确、身份验证完成，以及交互轮数是否受控。最终环境状态与模型评分可以共同覆盖这些维度。

对话测试经常使用另一个模型模拟用户，这使评价还依赖用户模拟器。用户是否提供了正确信息、是否遵循角色、是否改变目标，都会影响任务难度。两个 Agent 版本应使用相同模拟设置，并保留完整交互。模拟用户的限制也应作为评测范围说明。

研究 Agent：主张、覆盖和来源各自核验

研究报告没有统一的完整性标准。市场概览、收购尽调和科研阅读需要的事实不同，因此 rubric 必须围绕用途建立。原文提出组合检查：主张是否被检索来源支持，必需事实是否覆盖，以及引用来源是否具有足够质量。

准确引用还包含支持关系。链接可访问不代表它支持段落结论，某条材料的日期也可能已经超出任务范围。明确问答可使用精确判断，开放综合则需要拆分事实、来源和推断。长文本评测特别需要避免只看开头或摘要，把重要遗漏隐藏在总体流畅度后面。

这也适用于论文阅读博客。可以把核心机制、关键步骤、实验条件和局限列为覆盖项，再对每项检查来源与解释。字数是排查遗漏的信号，逐项解释能否帮助读者理解，才是主要目标。

计算机操作 Agent：确认真实环境发生了什么

浏览器或桌面 Agent 使用截图、鼠标和键盘与应用交互。评测应检查页面、文件、数据库或应用状态。订单确认页面出现只是一个中间观察，后台订单是否真实存在仍需要另外验证。

原文还讨论 DOM 与截图工具的选择。文本提取适合网页总结，页面截图可能更适合定位视觉对象。两者的 token 与延迟代价依任务而异，因此需要评价工具选择是否服务当前任务。文章中的产品经验不能自动扩展为所有网页都适用的速度排序。

多次运行时，成功率在回答什么问题

一个任务一次通过，不能说明每次都能通过。模型采样、工具响应和环境变化会导致 trial 之间的差异。原文使用 pass@k 与 pass^k 区分两种目标：在 k 次尝试中至少成功一次，以及 k 次全部成功。

来源：原文 How to think about non-determinism in evaluations for agents；归档 PDF 第 13 页。图解释两个指标随尝试次数变化的不同含义。

为帮助理解，假设一个固定任务每次成功概率为 p，各次运行独立且条件相同，则有：

第一式来自排除全部失败，第二式来自要求全部成功。这是对指标的教学推导，独立性是假设。原文用 p=0.75、k=3 说明连续三次成功约为 42%；在相同假设下，三次里至少成功一次约为 98.4%。相同 Agent 可以同时拥有较高的多次尝试成功率和较低的连续可靠性。

如果产品允许多次生成，并且有可靠方式选出成功结果，pass@k 有意义。若每次运行面对真实用户，且一次错误就会产生重要损失，则连续成功率更接近可靠性要求。多次尝试还带来成本：必须报告 k、预算、选择机制和每次运行消耗，不能把增加试验次数得到的高分称为模型本身变得更可靠。

这些公式不能直接使用整个任务集的平均成功率替代每个任务的 p。不同任务的难度不同，先对每个任务测量，再汇总才保留分布信息。共享文件、残留状态或同一环境故障也可能使运行相关，导致独立假设失效。实践中应报告实际 trial 结果和不确定性，而不是只用理论公式给出漂亮数字。

从零建立评测：原文路线的执行含义

原文给出 Step 0 到 Step 8 的建设路线，按任务收集、框架与评分、长期维护三部分组织。下面把每一步转成可理解的操作与失败边界。

来源：原文 The process of creating an effective evaluation；归档 PDF 第 19 页。图对应从任务收集到长期维护的流程。

尽早开始。 作者建议早期可从 20—50 个真实失败相关任务起步。此时系统改动常产生较大效果，小任务集能帮助定位明显问题。这个建议不意味着 20 个样本就能精确证明细小收益；成熟系统测量小幅变化，需要更多任务、重复运行与适当统计判断。

把已有人工检查转成任务。 收集发布前反复验证的行为、用户报告的故障和高影响场景。真实失败可以提供具体输入与环境状态，避免只写设计者容易想到的理想任务。需要筛选是否代表目标使用分布，不能让某个频繁报告问题占据全部任务集。

任务明确并提供参考解。 原文要求任务应能由正确遵循指令的 Agent 完成，专家能够独立得到一致判断。参考解需要通过所有评分器，证明任务可解、检查可运行。任务要求与评分器应一致，文件路径、单位、容差、工具限制和成功阈值都应可从任务中理解。

同时覆盖行为应该发生与不该发生的场景。 只检查搜索是否触发，容易把 Agent 优化成所有问题都搜索；只惩罚搜索，又可能压制必要检索。成对覆盖能避免单边优化。其他例子包括有信息时回答与证据不足时保留未知，以及授权内行动与越过范围的行动。

稳定并隔离环境。 每个 trial 从干净状态开始，保持评测中的 Agent 与实际运行系统基本一致。上一次遗留的文件、缓存或 git 历史可能泄漏答案；共享资源限制可能制造相关失败。因基础设施失败而没有完成的试验，应与 Agent 的有效尝试区分记录。

有针对性地设计评分器。 可明确验证的条件优先使用程序检查，开放内容按 rubric 评分，并通过人工校准。多组件任务可保留部分分数，帮助识别 Agent 完成到了哪一步，同时保留真正决定任务成功的硬约束。

阅读轨迹。 当分数下降时，检查模型动作、工具返回、运行限制和评分理由，区分真实错误与拒绝有效答案。只看汇总分会将这些原因混为一谈。人工阅读样本也能校验裁判是否与实际目标一致。

检查能力评测是否饱和。 已几乎全部通过的任务适合守住回归，但难以分辨新能力。应补充更复杂、更接近新目标的任务，同时保留旧任务作可靠性检查。不要为了提高榜单分数，只删除模型尚未解决的困难任务。

建立长期维护责任。 基础设施可以由专门人员维护，领域专家与产品人员贡献任务和标准。任务集需要随着产品、环境和模型变化更新，并保存版本，让历史比较仍能解释。

评测错误会怎样制造模型能力的假象

原文报告 Opus 4.5 在 CORE-Bench 上最初为 42%，后来在修复评分问题并采用限制更少的 scaffold 后达到 95%。作者提到的问题包括过于严格的数值匹配、任务规格歧义和难以精确重现的随机任务。

这组数字说明评测条件足以大幅影响观察结果。调整过程同时改变了任务或评分问题和运行限制，因此不能把差值当作一次模型训练收益，也不能全部归因于单项评分修复。原文的案例值得用来建立诊断习惯，而非直接预测你自己的收益。

另一个问题是判定要求与任务文字不一致。原文提到某些任务要求达到一个阈值，实际评分却要求严格超过阈值，这会惩罚遵循文字要求的模型。检查符号、边界和容差是评测设计的一部分：>= 与 >、四舍五入与精确小数，都可能改变结论。

还要防止绕过评分。若 Agent 能修改检查器或找到不完成任务也能通过的漏洞，得分就无法支持目标能力。检查器可信、环境边界明确、评分证据独立，是避免这种问题的基础。原文同时强调保留有效解法空间，不能为了防绕过而把所有行动路径锁死。

用一个完整任务理解评价过程

以下是根据原文整理的教学案例，配置用于解释设计，未在项目里运行。任务是让代码 Agent 修复空密码造成的认证绕过，并保持原登录行为。

task:
  id: auth-empty-password
  input: 拒绝空字符串和缺失密码，保留正确密码登录
  initial_state: 固定代码版本与独立测试环境
  success:
    - 空密码与缺失密码均被拒绝
    - 正确密码仍能登录
    - 目标修改没有破坏既有测试
graders:
  correctness: 功能测试与最终环境状态
  quality: 按明确标准检查修改范围和实现质量
metrics:
  - 每项约束结果
  - 总体成功与部分完成情况
  - 工具调用、token、运行时间

评测框架先恢复初始代码与环境，将任务和允许工具交给 Agent harness。模型可以自行阅读、修改并测试，框架记录所有实际调用和返回结果。结束后，程序检查目标功能与回归测试，质量评分器检查产物，最后聚合结果。

若 Agent 回复修好了，但空密码测试仍通过认证，就应失败。若它采用另一种有效实现，全部功能条件通过，则不能因调用顺序不同而拒绝。若试验环境无法启动，则应记录基础设施故障，并保留它与模型失败的区别。

重复 k 次时，每次恢复相同初始状态，记录逐次结果。对比微调前后，应固定任务集、工具权限、预算、运行框架和评分版本。这样才能将改善与权重更新建立较清晰联系。

能力集、回归集与训练奖励的关系

能力评测用来探索系统尚不擅长的任务，初始通过率可以低；回归集用于保护已经可靠完成的行为，预期通过率应高。能力任务随着模型进步，可以转为长期回归任务，但仍要保持相同成功定义。

这套区分对微调很有用。新数据可能改善某个领域，同时损害通用指令遵循或工具格式。只测训练目标，会错过这种变化。应在领域能力集、已有可靠任务和相关边界任务上共同观察，并检查成本是否增加。

把评测转换成奖励，还需要更严格审查。训练会反复优化评分标准，裁判漏洞、文本长度偏好和工具调用形式偏好都可能被放大。训练用任务、调参用任务与最终报告用任务应适当隔离；保留未经训练循环反复使用的评测材料。这里是根据原文对评分可靠性的要求提出的训练迁移建议，文章没有提供统一 RL 奖励实现。

训练数据也应包含经过验证的结果，避免模型学会自报完成。对于开放研究任务，可将事实覆盖、来源支持和结构要求拆成检查维度；对于代码任务，实际测试结果比最后一句完成说明更有价值。

自动评测之外，还需要哪些证据

自动评测适合频繁回归与模型比较，线上监测能观察真实使用分布，A/B 测试能比较用户结果，反馈与轨迹审查能揭示未覆盖失败。系统化人工研究则适合校准主观维度。

来源：原文 How evals fit with other methods for a holistic understanding of agents；归档 PDF 第 22 页。各层存在不同盲区，需要组合使用。

这些手段提供的证据不同。自动任务分数提高后，线上用户可能因为延迟、任务分布或交互方式而没有获得同样收益；线上指标下降也可能来自流量变化。把离线任务、线上日志和人工案例连起来，才能解释变化发生在哪里。

附录列举 Harbor、Braintrust、LangSmith、Langfuse、Arize Phoenix 等框架，分别涉及运行环境、可观测性、任务集和评分能力。这是文章发表时的工具说明。本文不据此推荐当前产品版本或价格，也不把选用某框架当作评分标准已经可信。优先明确任务、结果和证据，再选择匹配现有系统的实现方式。

阅读后可以怎样开始

先挑一组真实任务，写清输入、初始环境、完成条件和允许预算。为每项硬条件选择可检查的环境证据，为开放判断定义 rubric，并用人工样本检查裁判。保存逐次轨迹，固定版本后比较当前 Agent 与一个改动版本。

第一轮分析应能回答：失败发生在模型、工具、环境还是评分；哪项能力改善；旧行为有没有退化；多次成功是否稳定；每个成功任务花了多少资源。若这些问题仍无法从记录中回答，应先补评测信息，再扩大训练规模。

来源

1. Anthropic 原文，2026-01-09。定义与组成见归档 PDF 第 2—4 页，三类 grader 与能力/回归区分见第 6—8 页。

2. 四类 Agent 评测见第 9—12 页；多次试验指标见第 13 页；Step 0—8 的完整路线与评分错误案例见第 14—19 页。

3. 多层评价与框架附录见第 19—24 页。本文公式推导、认证修复任务和微调迁移说明为教学整理，未声称在本项目运行或复现作者系统。