前一篇讨论了怎样为 Agent 准备可理解、可操作、可验证的工程环境。接下来要回答的是：修改模型、提示词或工具以后，怎样知道这套系统真的做得更好了？

对会调用工具的 Agent 来说，回答写得像完成了任务，与任务实际完成，是两件事。它可能正确解释了退款政策，却没有创建退款记录；也可能完成了操作，但向用户报告了错误金额。只读最后一句回答，很难判断整个任务的质量。

结合 Anthropic 的《Demystifying evals for AI agents》，本文围绕四个问题展开：

• 评什么： 怎样定义任务，记录一次尝试的执行过程与实际结果。
• 怎么评分： 程序、模型和人工分别适合判断什么，多个标准怎样组合。
• 怎么看稳定性： 同一个任务为什么要重复运行，pass@k 与 pass^k 分别说明什么。
• 怎样持续使用： 能力评估与回归评估怎样分工，真实失败怎样成为可重复的测试。

下面用一个假设的售后任务贯穿说明：用户要求退回一笔已取消订单的 50 元付款。订单、退款系统和检查标准都是教学示例，不涉及真实交易。

一、一次 Agent Eval 需要哪些材料h2

一次评估不只是“给问题、看回答、打分”。先把任务条件、执行记录和完成标准分开，才知道后面的分数究竟在衡量什么。

1. Task 与 Trial：任务条件和一次具体尝试h3

Task 是一项有明确输入与成功标准的测试任务；Trial 是 Agent 对这项任务的一次尝试。 同一项 Task 可以运行多个 Trial，而每个 Trial 内部又可以包含多次模型调用和工具执行。

在退款例子里，只写“帮用户退款”还不够。任务至少要交代这些条件：

• 用户身份已经验证，订单属于当前用户。
• 订单已取消，付款为 50 元，当前不存在退款记录。
• 测试政策允许全额退款，用户已明确确认。
• Agent 可以查询订单、读取政策和提交退款，不能修改其他订单。
• 成功意味着指定订单只产生一笔 50 元的成功退款，且答复与实际状态一致。

这些约定把自然语言请求连接到可以检查的结果。否则，“已经提交申请”究竟算不算完成，两位评审者都可能给出不同答案。

第一次 Trial 可能先查询政策，再查询订单；第二次可能先读取订单，发现取消状态后再核对政策。只要这些顺序没有违反任务要求，就不必因为路径不同判其中一次失败。

Task 固定需要完成什么，Trial 记录某一次实际怎样做。 这也解释了为什么一条工具调用不是一个 Trial：查询订单只是尝试中的一步，退款和最终答复可能还在后面。

2. Transcript 与 Outcome：执行记录和环境终态h3

Transcript，也常称 Trace 或 Trajectory，记录一次尝试中能够采集到的交互：用户消息、模型输出、工具请求、工具返回等。Outcome 则是这次尝试结束后，环境实际处于什么状态。

对于退款任务，可以分别检查：

假设 Agent 说“50 元已经退回”，但退款工具返回失败，数据库里也没有成功记录。答复出现在 Transcript 中，却不能代替 Outcome。

反过来，数据库确实存在正确退款，也不能证明整个过程都合格。如果 Agent 同时告诉用户“退回了 500 元”，沟通仍然有问题；如果它还试图修改另一位用户的订单，单看目标订单的终态也会漏掉重要行为。

因此，结果检查回答“事情有没有做成”，过程记录提供“做了什么”的证据。 两者可以参与同一项评估，但不是同一份材料。

这里的执行记录也不是模型全部内部活动的快照。能评估的是系统实际记录到的信息，不能把不可见的推理当成已经采集的证据。

3. Evaluation Harness：组织运行、采集与评分h3

Agent Runtime负责把模型、工具和交互连接成工作过程。Evaluation Harness 在外面组织测试：准备任务环境、启动一次尝试、收集证据、运行 Grader，再汇总结果。

可以把两者的职责分开看：

• Agent Harness： 接收请求，组织推理与工具执行，让 Agent 能够行动。
• Evaluation Harness： 安排用什么任务测试、从什么起点运行、怎样检查和比较结果。

被测对象通常是模型与 Agent Harness 的组合。模型没换，但工具定义、上下文组织或退出逻辑变了，评估结果同样可能变化。

一组围绕某种能力组织的 Task，构成 Evaluation Suite。例如，售后评估集可以包含正常退款、重复申请、信息缺失和需要人工处理的任务。Suite 是任务的集合，不是运行完以后生成的一份分数表。 分数表是对这组任务的执行结果进行汇总。

二、任务的不同部分怎样评分h2

有了记录与终态，还需要把“做得好”变成具体判断。Grader 就是负责检查某个方面的评分逻辑：它可以检查一条记录，也可以依据明确标准评价一份回答。

4. Grader：程序、模型与人工各自判断什么h3

三类 Grader 的区别，主要在于怎样作出判断，而不只是返回布尔值还是分数。

Code-based：检查可以明确验证的条件

退款金额、订单 ID、成功记录数量，都可以由程序检查。例如，读取测试环境，验证目标订单存在且只有一笔成功退款，金额为 5000 分，其他订单没有变化。这里金额采用最小货币单位，是示例自己的约定。

程序检查清楚、便于重复，但检查范围也由代码决定。只检查 status == succeeded，就可能放过退错金额或退错订单。确定性不等于标准完整。

Model-based：按明确标准评价开放输出

“是否解释清楚退款结果”“有没有作出工具结果不支持的承诺”，很难用几个关键词可靠判断。可以把实际证据与回答交给另一个模型，按 Rubric 逐项评价。

在本例中，一份简短标准可以是：

• 答复中的订单、金额和退款状态是否与证据一致。
• 是否区分提交、处理和完成，而不是把它们混为一谈。
• 用户能否看懂当前结果，以及是否仍需要补充信息。

评价模型的判断也会波动。应当用人工已经判过的样本核对它：哪些情况容易误判，标准是否含糊，缺少证据时是否允许返回“无法判断”。不能因为评审者也是模型，就把它当成自动正确的裁判。

Human：校准标准与处理复杂判断

人工适合确定质量标准、核对模型评分，以及审阅有争议的结果。比如一句“退款完成”在模拟系统里可能对应成功记录，但真实产品应当怎样向用户表达到账状态，需要结合产品语义确定。

人工也不是没有分歧。两位评审者对同一条回答判断不同，可能需要补充标准，而不是简单挑一位作为正确答案。

这三类方法可以配合：金额和状态交给程序，表达质量交给模型，标准制定和抽查交给人工。关键是每项判断都能说清它检查了什么证据。

5. Scoring：硬性条件、部分得分与组合h3

一项任务可以有多个 Grader，组合规则决定什么算整体通过。常见方式有三种：

退款任务更适合把关键状态设为硬性条件。不能用“语气很好”的高分抵消“退错钱”，也不能把越权操作平均进一个看起来尚可的总分。

同时，可以保留部分得分帮助理解表现。Agent 已正确定位订单、核对政策，却没有完成退款，与一开始就查错订单的表现不同。两者都可能整体失败，但失败分布不应被一个零分完全抹平。

因此，结果可以同时包含整体是否通过、各项检查结果、质量分数与成本指标。调用次数、耗时和 token 消耗有助于比较效率，却不是脱离任务质量的成功证明。

过程要求也要区分两类。核实身份、取得确认等任务要求可以检查；“必须先调用 A 再调用 B”若只是设计者习惯，就不应该成为隐藏的唯一正确路径。

6. Agent 类型：按任务选择完成证据h3

同样的评估框架可以用于不同 Agent，但完成证据不能照搬。退款任务重视业务状态，写代码、做研究和操作界面则需要各自的检查入口。

对话任务还可能需要模拟用户补充订单号、确认操作或改变表达方式。模拟器要遵循明确的用户情境，不能把评分器期待的解法直接提示给被测 Agent。

这些差别会影响 Grader 的选择，但不改变基本原则：先确定完成任务需要什么证据，再安排怎样采集和判断。

三、同一个任务的执行稳定性怎样衡量h2

一次通过说明这一次做成了，却不能直接说明同样条件下能稳定做成。模型采样、工具选择和多轮交互，都可能让不同尝试走向不同结果。

7. Multiple Trials：在可比较的起点重复运行h3

假设同一退款任务运行五次，其中三次正确，两次没有完成。这与只展示一次成功演示提供的信息不同：前者至少暴露了任务存在不稳定的执行结果。

重复运行必须从可比较的初始状态开始。在本例中，每个 Trial 都应恢复“尚未退款”的测试订单，而不是让第二次接着第一次已退款的数据库继续操作。否则测到的已经不是同一项任务。

环境也不能无意间留下前一轮的结果文件、缓存或提示。各次执行记录需要分开保存，并记录所用模型、指令、工具、预算与评分标准的版本，才能解释比较条件。

多个 Trial 可以帮助观察波动，但小样本成功率仍然只是估计。报告结果时，应当同时给出任务数、每项任务的尝试次数和成功定义，而不是只有一个脱离条件的百分比。

8. pass@k 与 pass^k：机会成功和持续可靠h3

这两个指标问的不是同一件事：

• pass@k： 同一任务尝试 k 次，至少一次成功的概率。
• pass^k： 同一任务独立尝试 k 次，全部成功的概率。

τ-bench 论文用 pass^k 描述多次尝试的一致可靠性。它不是在统计一个 Trial 内的 k 个步骤，也不是要求把同一笔退款连续执行 k 次。

为了看清区别，假设某项任务每次成功概率都是 p，各次尝试相互独立。那么：

至少一次成功：pass@k = 1 - (1 - p)^k
每次都成功：  pass^k = p^k

取一个自拟例子，p = 0.8：

更多尝试让“至少成功一次”变得容易，却让“每次都成功”变得更苛刻。所以高 pass@k 不能直接解释成“每位用户都能稳定得到正确结果”。

如果任务允许生成多个候选，再用可靠验证器挑出一个有效解，pass@k 有价值；如果面向用户的每次操作都需要可靠完成，一致性就更重要。即使候选里有正确答案，没有可靠的选择办法，也不等于产品已经找到了它。

上面的公式是单个任务、独立且成功概率固定时的说明。实际任务的难度不同，应分别统计或估计再汇总，不能把整套评估的平均成功率直接乘方，当成整套评估的 pass^k；共享故障造成的相关失败，也不满足独立假设。

四、怎样建立和维护一套有效的 Evalh2

前面定义了任务、证据、评分与稳定性。把它们用于持续开发，还需要一组有代表性的任务，以及明确的使用方式。

9. Dataset：把实际需求写成可检验的任务h3

起点可以是开发中已经手工检查的行为、真实失败和用户需求，不必先追求一个庞大的题库。对于退款 Agent，只收集正常退款会遗漏另一半能力：什么时候不应该退款，什么时候需要进一步确认。

可以围绕同一业务准备不同任务：

• 符合条件，用户已确认，应当完成退款。
• 订单已退款，不能再创建一笔。
• 订单不属于当前用户，不能操作。
• 用户还没决定，应该先解释和确认。
• 工具失败，不能把失败答复成成功。

每种任务都需要自己的成功标准。信息不足时正确请求补充，可以是通过；拒绝不允许的操作，也可以是通过。“成功”指符合任务要求，不总是指完成一次写操作。

还要检查题目与评分是否一致。如果任务只要求提交退款申请，Grader 却要求资金已经到账，Agent 遵循题意也可能失败。可以准备一份已知合格的参考结果，先验证这些标准确实允许正确解通过；参考结果用于校验评分，不是泄露给 Agent 的答案。

10. Capability 与 Regression：能力空间和已有保障h3

两类 Suite 的目标不同：

• Capability Eval： 测量还不能稳定处理的任务，观察能力是否提升。
• Regression Eval： 检查已经可靠处理的任务，防止修改后退步。

例如，普通取消订单退款已经稳定通过，可以进入回归集；多订单、多种支付方式和信息缺失组合在一起，可能仍是能力集中的挑战任务。

能力集通过率低，不自动说明题目不好，它可能正在暴露尚未掌握的能力。回归集则应接近全通过，下降值得排查。但无论属于哪类，任务都必须明确、可解，评分不能依赖隐藏要求。

当原先困难的任务逐渐变得稳定，它们可以转为已有能力的保障。反过来，一套几乎全通过的能力集，已经很难区分新的改进；它仍能防退步，却需要补充真正有意义的挑战任务，才能继续衡量进步。

11. Eval-driven Development：把改进与回归连接起来h3

一次失败报告，可以变成一条可反复运行的任务。假设用户反馈“Agent 把退款处理中说成了退款完成”，就可以据此固定一份处理中状态，要求答复准确区分两者。

接着修改指令或工具反馈，重跑这条任务，再跑已有的正常、重复申请和失败场景。这样检查的不只是“这个问题修没修”，还包括“修复有没有影响其他行为”。

这条循环可以概括为：

记录问题 → 明确成功标准 → 固定任务与评分 → 修改 Agent → 重跑与比较 → 保留回归任务

比较时，应尽量保持任务、运行条件和 Grader 一致。如果升级 Agent 的同时也修改了评分标准，需要单独记录，否则分数上涨可能只是考试方式变了。

维护 Eval 也包括检查评分器本身。低分可能来自 Agent 的真实错误，也可能来自含糊任务、评分 bug 或误拒合理解法。抽查执行记录与实际状态，是确认分数有没有测对的重要步骤。

自动评估能够帮助重复比较，但不能覆盖全部真实使用。线上反馈可以补充遗漏场景，人工抽查可以校准开放质量判断。它们提供不同证据，不需要由一个总分替代所有观察。

我理解的一套有效 Eval，不是给 Agent 贴上“好”或“不好”的标签，而是让这些判断有具体对象：在哪些任务上、依据什么证据、按什么标准、以多高的稳定性完成。 这些条件清楚，分数才有可解释的意义。

几个关键问题，串起任务、评分与稳定性h2

Agent 最后回答正确，为什么任务仍可能失败？

因为回答只是执行记录的一部分。需要改变环境的任务还要检查实际状态：退款是否创建，金额是否正确，是否重复操作。回答正确可以是一项检查结果，但不能自动代替其他完成条件。

所有工具都调用成功，是否就证明业务成功？

不是。工具成功表示它完成了自己的操作，未必符合用户目标。查错订单的查询也可能成功，提交申请也不等于退款完成。评分要把工具结果放回任务条件中判断。

为什么不用一个模型评价整段执行，直接给总分？

可以用模型评分，但不能把可精确核对的金额、状态和记录数量都换成印象判断。不同维度需要合适证据；拆开检查还方便定位总分背后的差异，并让人工校准模型判断。

检查过程，会不会限制 Agent 寻找更好的办法？

要区分必要约束与指定解法。不得越权、必须取得确认，是任务要求；无业务依据的固定调用顺序，则可能误拒有效解。过程检查应服务于真实要求，不是复刻设计者自己的操作。

pass@5 很高，为什么不能直接说明五次都可靠？

因为它只要求五次中至少一次成功。五次都成功对应 pass^5，两者衡量不同问题。还要区分离线独立尝试与线上重试：评估里多试几次，不代表业务系统可以无条件重复有副作用的操作。

能力评估通过率不高，应该降低标准吗？

不应只为提高分数降低标准。先确认任务可解、要求明确、评分公平，再判断是不是确实还不具备能力。能力集需要提供进步空间，回归集需要守住已有表现，它们的预期通过率本来就不同。

修复一个失败场景后，只重跑这一条够吗？

不够。这条任务验证针对性修复，其他任务检查它是否引入回归。只有结果、执行条件和评分方式都可比较，才容易说明改进发生在哪里。

参考资料h2

• Anthropic — Demystifying evals for AI agents
• τ-bench — A Benchmark for Tool-Agent-User Interaction in Real-World Domains
• 配套阅读：Harness Engineering
• 配套阅读：Tool Design