Agentic 评测：如何判断 AI Agent 是否完成了任务，并且下次还能做好 https://t.co/V2VvSubwZO

Agentic 评测：如何判断 AI Agent 是否完成了任务，并且下次还能做好

本文面向发布基于大语言模型（LLM）Agent 的工程师：这些系统能调用工具、修改记录，并代表客户在多个步骤中执行操作。读完本文后，你将能够根据 Agent 实际改变了什么（而非它说了什么）来评判一次运行，在能力指标旁加上可靠性指标，定位一次失败运行出错的步骤，并判断何时可以信任模型评判（model-as-judge）。随后文章范围扩展到这些工程师的管理者，以及决定是否允许 Agent 接触订单、代码或资金的决策者。

文中数据来自文末列出的已发表论文，以及一个关于小型客服 Agent 的可运行实验——Level 0 会对其进行完整描述。本文不假设你之前看过任何相关内容。

快速了解（如果只读这一段，请读这里）

Agent 是一个处于循环中的语言模型：它读取请求，选择一个工具（查询订单、取消订单、退款、发送回复），读取工具的返回结果，再做出选择，直到它认为任务完成。围绕模型运行这个循环的代码——包括提示词、工具和重试逻辑——称为运行框架（harness）。Agent 评测是一种可重复的测试，它用一个你值得信赖的数字告诉你：Agent 是否完成了任务，是否每次都能完成，以及当它失败时错在了哪里。

上一篇文章《评测：如何判断 AI 系统是否真的能用》（Evals: how to know whether an AI system actually works）涵盖了对一个问题给出一个回答的系统：如何构建测试集、如何评分、何时信任模型评判、如何解读数据。这些方法在这里依然适用。不同之处在于可能出现的错误类型。

单次回答模型只可能在文本上出错。而 Agent 可能出错的地方包括：文本、动作、动作顺序、动作次数，以及它在数据库中留下的记录——而且这些可能互相矛盾。回复可能说“您的退款正在处理中“，但数据库里根本没有退款记录。在本文贯穿使用的示例中，一个只读回复的评分器通过了 60 次运行中的 58 次；而一个检查数据库的评分器只通过了 48 次。其余 10 次听起来没问题，但数据库显示并非如此。

工作原理，分五步：

• 为每个任务编写预期的最终状态。 不是“客户感到被帮助了“，而是“订单 O101 已取消，退款 120 美元，未收取手续费“。

• 从相同的初始数据库状态多次运行 Agent 执行每个任务，并保存完整的执行轨迹：工具调用及结果、最终回复、数据库的前后状态。

• 评判最终状态和执行路径。 记录是否以正确的方式变更？是否使用了必要的工具、避免了禁用的工具？是否在允许的步骤数内完成？最后才读回复。

• 报告两个数字。 解决了至少一次的任务数量（能力），以及每次都解决的任务数量（可靠性）。客户感受到的是第二个数字。

• 对于每次失败，找到第一个出错的步骤，统计错误类型，先修复最常见的类型。

适用时机：在 Agent 真正执行操作之前、每次修改提示词、工具或模型之前，以及上线后对抽样的真实流量持续运行。

重要： 评判 Agent 实际改变了什么，而不是它说了什么。回复是最后且最不可靠的证据。 对我们意味着什么： 每个任务都需要一个可验证的最终状态和一份允许操作清单，这些必须在 Agent 运行之前就写好。没有这些的任务还不算评测。 为什么重要： 在示例中，一个什么都不做、只写一条友好回复的 Agent 通过了所有仅检查回复的测试——20 个任务全部通过。一个无法淘汰“什么都不做“Agent 的数字，不能算作数字。

本文接下来逐层深入。

• Level 0 · 一个任务，端到端：商店、工具、评分器和数据

• Level 1 · 什么才算“完成了任务“？

• Level 2 · 它下次还能做好吗？

• Level 3 · 错在了哪一步？

• Level 4 · 模型能评判 Agent 吗？

• Level 5 · 每次成功花了多少代价？

• Level 6 · Agent 交接给 Agent 时会有什么变化？

• Level 7 · 如果 Agent 学会了“骗过“评分器怎么办？

• Level 8 · 让它每天运行起来

• 最后 · 工具、公开基准及解读方法、决策指南和参考文献

Level 0：一个任务，端到端

本级回答：当 Agent 评测实际运行时是什么样子？从客户发来的消息到那两个关键数字。

示例是一家虚构自行车店 Rivertown Cycles 的客服 Agent。它足够小，可以完整描述，也足够真实，会像真实 Agent 一样出错。

环境。 一个包含约二十个客户订单的模拟数据库，每个订单有状态（已下单、处理中、已发货、已送达、已取消、已退货）、总金额、地址、商品、退款总额和退货状态。每次运行前数据库都会重建，因此每次运行都从相同的环境开始。

工具。 Agent 拥有 8 个工具，每个工具内部都强制执行商店政策：

• lookup_order 和 list_orders 只读取数据库，不做任何修改。

• cancel_order 仅在订单处于“已下单“或“处理中“状态时可用，一旦进入处理中状态需收取 5 美元手续费。

• update_address 仅在订单处于“已下单“状态时可用，且需在下单后 24 小时内。

• start_return 仅适用于已送达的订单，需在 30 天内，定制商品不可退，且不涉及资金变动。

• issue_refund 上限为订单总额，退款金额累计计算。

• escalate 将案例转交给人工主管，返回一个工单 ID。

• reply 发送最终文本给客户，结束本次运行。

政策写在工具内部意味着 Agent 可能请求规则不允许的操作，工具会拒绝，数据库保持干净，拒绝被记录为工具错误。

指令。 一个系统提示词给出当前日期、工具使用顺序（如果提到了订单 ID 就先查询该订单，否则列出客户的订单）、上述规则、额外一条规则——任何 200 美元及以上的退款如果不关联已开始的退货必须先转交人工——以及本次运行必须以一条不编造任何内容的回复结束。

模型。 一个可下载的中等规模模型（约 270 亿参数），在单张本地显卡上运行，内置足够的随机性使重复运行可能产生不同结果。更大的模型会改变数字，但不会改变结论。

任务。 20 个手工编写的消息，每个任务在任何运行之前都写好了黄金标准（gold specification）：预期最终状态（以数据库字段和值表示）；必需工具；禁用工具；8 到 12 步的步骤预算；以及回复中必须包含的几个关键词。任务分为 11 个直接操作（取消、改地址、退货、查询）、7 个政策拒绝（不做任何修改并解释原因）和 2 个人工转交（转交给主管）。

运行。 每个任务从干净的环境运行 3 次，共产生 60 个片段（episode）。一个片段是从客户消息到最终回复的完整循环。整个轨迹都被保存：每次工具调用的参数和结果、模型写出的推理过程（如果有）、最终回复、数据库的前后状态及差异。

一个片段的示例。 任务 t01：“你好，我刚发现订单 O101 里的头盔还没付款，我想取消它。请帮我取消。“预期状态是：状态为“已取消”，退款总额 120，手续费 0。运行过程如下：

• lookup_order(O101)。结果：状态为“已下单“，下单于 1.1 天前，总金额 120，退款总额 0。

• cancel_order(O101)。结果：状态为“已取消“，手续费 0，退款 120。

• reply("你好 Ana，我已经取消了订单 O101（Trail 头盔 + 手套，$120.00）。由于订单仍处于已下单状态，未收取取消手续费……")

评分器。 纯代码实现。五项检查，只有全部通过才算这个片段通过：运行后数据库中存在预期状态；轨迹中出现了所有必需工具；没有出现禁用工具；步数在预算范围内；回复存在且包含关键词。上述片段在 8 步中的第 3 步通过了全部五项检查。

数据。 60 个片段的结果：

• 60 个片段中 48 个通过了全部五项检查：通过率 0.80，置信区间为 0.62 到 0.95。置信区间表示如果换一组同类型的 20 个任务，通过率可能落入的范围；区间较宽是因为 20 个任务是一个小样本。置信区间通过重新抽样任务（而非片段）来计算，因为同一任务的 3 个片段会一起升高或降低。

• 20 个任务中 17 个在 3 次尝试中至少通过了 1 次（0.85）。这是能力。

• 20 个任务中 15 个 3 次全部通过（0.75）。这是可靠性。

• 每个片段平均 2.5 次工具调用，最多 5 次，远在预算范围内。

• 60 个片段中有 1 个 Agent 请求了一个规则不允许的操作——超过订单总额的退款；工具拒绝了它，Agent 自行纠正。这就是该设计旨在捕捉的“热心 Agent 做出了错误操作“的情况。

Level 0 带出的要点：

• 一个片段有五项评判内容：最终状态、必需工具、禁用工具、步数、回复。按此顺序评判。

• 每次运行都从相同的环境开始，并保存完整轨迹，否则无法评判路径，也无法在之后调试失败。

• 两个关键数字：至少通过一次（0.85）和每次均通过（0.75）。两个都要报告。

Level 1：什么才算“完成了任务“？

本级回答：评分器应该查看哪些证据？如果它看错了会怎样？

Level 0 的五项检查强度并不相同。示例使这一点变得可测量：同样的 60 个片段用四种方式重新评分，并加入了一个“什么都不做“的 Agent。

四个评分器对同样 60 个片段的评分结果。

• 完整评分器（全部五项检查）通过 48/60。

• 仅回复评分器——只检查最终文本中是否出现预期关键词——通过 58/60。10 个听起来正确的片段被计为完成。

• 仅状态评分器——只检查数据库字段——通过 48/60，与完整评分器通过的是同样的 48 个：这里每一次失败都导致数据库状态错误。

• 模型评判（读取执行记录）通过 49/60，但不是同样的 49 个：它通过了 12 个完整评分器判定失败的片段，同时有 11 个完整评分器判定通过的片段被它判定失败。

仅回复评分器错在哪里。 全部 10 个错误通过的片段都未能通过状态检查，其中 8 个还跳过了必需工具。模式不断重复：Agent 查询了订单，写了一条热情的回复承诺退款或确认退货，但从未调用真正执行该操作的工具。

什么都不做的 Agent。 要测试评分器，给它一个不可能完成任务的 Agent。一个不调用任何工具、仅回复预期关键词的空 Agent，在 20 个任务上用同样方式评分：

• 仅回复评分器：20/20 通过。

• 仅状态评分器：11/20 通过：全部 7 个政策拒绝任务（因为“不做任何修改“在那些任务中就是正确的最终状态），以及 4 个只读任务（预期状态等于初始状态）。

• 完整评分器：6/20 通过，是 6 个没有列出必需工具的拒绝任务。第 7 个拒绝任务要求先查询，因此失败。

第二行是最需要记住的。仅状态评判是必要的，但仅靠它无法区分“因正确原因而拒绝“和“什么都没做“；20 个任务中有 11 个（60 个片段中有 33 个）的预期状态等于初始状态。在这些任务上，必需工具检查和回复检查承担了主要作用——这就是完整评分器需要全部五项检查的原因。

同样的模式在实际领域中也存在。

• ABC 审计（Agentic Benchmark Checklist，Zhu 等人，2025）发现一个平凡的 Agent 在公开客服基准 τ-bench 中通过了 38% 的航司任务，原因和上面空 Agent 通过拒绝任务相同。其清单向每个基准提出两个问题：任务是否可解（task validity），以及评分器能否检测到解决方案（outcome validity）。在审计的 10 个基准中，7 个存在结果有效性缺陷。

• AgentLens（2026）人工重新评定了 2,614 条 Agent 执行轨迹，发现 10.7% 的“通过“是幸运通过：最终状态正确，但路径错误，三位标注者之间几乎完全一致。仅状态评分器会把幸运通过计为通过。

完整评分器仍然漏掉什么。 语气、正确的操作是否被正确解释、无害的绕路：这些是需要配备正确证据的评判器和轨迹指标来处理的任务。

依赖条件。 黄金标准的正确性，而示例中有两个任务的黄金标准就是错的。任务 t14 要求对订单 O104 的退货“在系统中确认“，预期退货记录存在，但禁止发起退货；在干净的数据库上没有退货记录，因此没有 Agent 能通过。任务 t17 预期在订单 O110 上有 240 美元的退款，只有前一个任务的改动才能产生这个退款。两者都好像是假设了前一个任务的改动会持续存在，但实际不会。

在 Level 0 中失败或不稳定的 5 个任务中，3 个是 Agent 的失败，2 个是任务本身的 bug。去掉那两个任务后，通过率从 0.80 上升到 0.89，可靠性从 0.75 上升到 0.83。ABC 清单的第一个问题——在任何运行之前提问——本来就能发现这个问题；空 Agent 无法发现，因为它在那些任务上也失败了。

重要： 评分器的可靠性受限于它所犯的最严重捷径。仅回复评判可以让什么都不做的 Agent 通过每一个任务；仅状态评判可以让它通过一半。 对我们意味着什么： 首先基于状态、必需操作、禁用操作和步骤预算来构建评分器，将回复作为最后一项检查。然后运行一个空 Agent 通过它，并在信任它产生的任何数字之前，检查每个任务在干净环境中的可解性。 为什么重要： 欺骗自己最常见的两种方式是：一条流利的回复，和一个无解的任务。前者由空 Agent 检测，后者由干净环境检查检测。

Level 1 带出的要点：

• 同时评判最终状态和执行路径。仅回复评判无法淘汰什么都不做的 Agent。

• 仅状态评判在“不做修改“任务上是盲区，这里有 11/20。必需操作和回复检查能覆盖它们。

• 让空 Agent 通过每个评分器，并检查每个任务在干净环境中是否可解。这里有 20 个任务中有 2 个不可解。

Level 2：它下次还能做好吗？

本级回答：如何将多次运行转化为一个能力数字和一个可靠性数字？需要多少次运行？

Level 0 从同样的 60 个片段报告了 0.85 和 0.75。它们分别来自一个估计量。

pass@k 和 pass^k。 对每个任务运行 n 次，统计通过次数 c。

• pass@k 是 k 次全新尝试中至少有一次通过的概率。它衡量能力：Agent 能做到。

• pass^k（读作 “pass to the k”）是 k 次全新尝试全部通过的概率。它衡量可靠性：Agent 每次都能做到。在 n 次试验中有 c 次通过时，它等于所有大小为 k 的试验组合中全部通过的组合占比，在所有任务上取平均。一个任务在 3 次试验中有 2 次通过，有 3 种可能的配对和 1 个全部通过的配对，因此它的 pass^2 是三分之一。这是 τ-bench 的估计量，对任何不超过 n 的 k 都是精确的。

每任务 3 次试验下，示例给出：

• k=1：两者都是 0.80，区间 0.62 到 0.95。一次尝试就是一次尝试。

• k=2：pass@2 为 0.83，pass^2 为 0.77。

• k=3：pass@3 为 0.85（区间 0.70 到 1.00），pass^3 为 0.75（区间 0.55 到 0.90）。

两条线之间的差距就是可靠性差距。在 k=1 时按定义为零，随着 k 增大而拉开：pass@k 向“Agent 曾解决过的任务“攀升，pass^k 向“Agent 从未失败过的任务“下降。3 次试验只有两个台阶让它拉开；5 次或 8 次时两条线会进一步分离。

按任务来看，这个差距有名字。 15 个任务三次试验全部通过；2 个不稳定（t04，退货加退款，3 次通过 1 次；t10，人工转交加退款，3 次通过 2 次）；3 个从未通过（t09，以及两个任务 bug t14 和 t17）。按类别：

• 政策拒绝，7 个任务：pass@3 为 1.00，pass^3 为 1.00。拒绝是可靠的。

• 直接操作，11 个任务：pass@3 为 0.82，pass^3 为 0.73。

• 人工转交，2 个任务：pass@3 为 0.50，pass^3 为 0.00。Agent 在 t10 的 3 次尝试中转交了 2 次；t17 是两个没有任何 Agent 能通过的任务之一。

头条数字 0.75 是 1.00、0.73 和 0.00 的加权平均。如果人工转交路径是……