Agent 评测：如何判断一个 Agent 是否可靠

Agent 的输出是非确定的。同一个问题问两遍，可能给出不同的回答、走不同的执行路径、调用不同的工具。手动试几个 case 觉得还行，上线后才发现大量问题。靠肉眼判断"看起来没问题"覆盖不了真实场景的复杂度，你需要一套系统性的评测方法。

要系统评价一个 Agent，首先要明确评测服务于横向比较，还是自己的产品迭代。在此基础上，我们再从结果、执行过程和系统表现三个层面建立评测框架。后面五篇的内容，都从这里展开。

[1. 和传统软件测试差在哪](#1. 和传统软件测试差在哪)
[2. 公开 Benchmark 与私有 Eval](#2. 公开 Benchmark 与私有 Eval)
[3. 三个评测层级](#3. 三个评测层级)
[4. 五个评测维度](#4. 五个评测维度)
[5. 评测基本流程](#5. 评测基本流程)
[6. 小结](#6. 小结)

1. 和传统软件测试差在哪

传统软件测试的逻辑很直接：写一个函数，输入 1，期望输出 2，实际输出 2，通过。输入确定、输出确定、判断标准确定。测试用例可以精确到每一个字节。

Agent 不一样。你问它"帮我查一下北京今天天气"，它可能调用天气 API 返回"晴，25°C"，也可能先搜一下再调 API，也可能直接说"我无法获取实时天气"。如果任务要求查询实时天气，前两种回答可能都合格，第三种则没有完成任务。评测的难点不在于答案必须逐字一致，而在于如何判断不同表达是否都满足任务要求。

这带来了两个根本差异。

输出不确定。 同一个问题，Agent 每次走的路径可能不同，给出的答案措辞也可能不同。你没法像传统测试那样写 assertEqual(result, "北京今天晴，25°C")，因为 Agent 的回答可能是"北京今日天气晴好，气温 25 度"，意思对了但字面不一样。

关注中间过程。 许多确定性测试可以直接通过输入和输出判断结果，但 Agent 评测通常还需要检查执行过程。它选择了什么工具、传入了哪些参数、是否出现无效重试，这些信息都可能影响最终结论。即使最终答案正确，执行轨迹一团糟的 Agent 也不是好 Agent。

一张表看清区别：

维度	传统软件测试	Agent 评测
输出特征	通常可以预期	存在随机性和表达差异
判断方式	精确断言为主	规则、状态检查与模型评分并用
观察对象	函数或系统行为	最终结果、执行轨迹和运行指标
用例描述	输入与预期输出	任务、环境、预期结果与约束
评测结果	通常通过或失败	离散结论与连续分数并存

既然传统断言式的测试方法不够用了，就需要新的方法论。但在展开方法论之前，有一件事必须先分清楚：你评测的目的是什么。

2. 公开 Benchmark 与私有 Eval

"Agent 评测"这四个字其实涵盖了两件完全不同的事。

公开 Benchmark 是学术界或行业发布的标准化数据集，用来衡量 Agent 的通用能力。SWE-bench 测代码修复，GAIA 测多工具协作，WebArena 测网页交互。所有人在同一个数据集上跑，结果可以横向比较。它的目的是回答：这个 Agent 在通用任务上处于什么水平？

私有 Eval 是你基于自己的业务场景构造的测试集，用来改进和监控自己的 Agent。你的客服 Agent 需要处理退换货、查物流、改地址，这些场景不会出现在任何公开 Benchmark 里。它的目的是回答：这个 Agent 在我的场景里够不够用？

两者的定位完全不同：

维度	公开 Benchmark	私有 Eval
数据集	标准化，公开发布	自己构造，不公开
评测目的	和业界对比排名	改进自己的 Agent
任务类型	通用任务	业务特定任务
评分方式	统一标准	自定义规则
能回答的问题	"我们在行业里排第几"	"这次改 prompt 是改好了还是改坏了"

一个常见的误区是把两者混为一谈。你做了一个金融 Agent，在 SWE-bench 上排名很高，不代表它能准确处理你的"查看持仓收益"场景。反过来，你的 Agent 在私有 Eval 上通过率 95%，也不会让它在 SWE-bench 上的排名提升一格。

是否运行公开 Benchmark，取决于你是否需要比较通用能力；私有 Eval 则几乎是业务 Agent 持续迭代的必需品。

整个系列的规划也是沿着这两条线展开的：

篇目	主线
本篇	建立评测框架
第二篇	代码 Agent 的公开 Benchmark
第三篇	工具型 Agent 的公开 Benchmark
第四篇	评分方法（两条线共用）
第五篇	构造私有 Eval 数据集
第六篇	把评测接入开发流程

接下来进入框架本身。评测一个 Agent，可以从三个层级来看。

3. 三个评测层级

评测 Agent 时，可以分别观察最终结果、执行过程和系统运行表现。这三个层级关注的问题不同，需要配合使用。

最终结果 --- Agent 给出的答案或产物对不对。

这是最直观的层级。让它查天气，最终输出的温度对不对；让它修 bug，提交的 patch 能不能通过测试。有标准答案的任务可以直接比对。对开放式任务，可以先定义内容完整性、语气和格式等评分标准，再由人工或 LLM-as-Judge 按照标准评分。

但只看最终结果有一个问题：Agent 答对了不代表它是"好"的。它可能绕了远路，调了不必要的工具，试了十次才蒙对一次。只看结果会漏掉这些低效和不稳定的信号。

执行轨迹 --- Agent 从输入到输出的每一步决策。

同一道题，A 用两步解决，B 用了八步还调了一次不存在的工具再自己修正回来。两者最终都对了，但轨迹的质量完全不同。

轨迹可以帮助我们判断失败发生在工具选择阶段，还是工具调用之后的数据处理阶段。无论调整提示词还是路由策略，都需要通过前后两次轨迹对比判断修改是否有效。

系统整体 --- 成本、延迟、稳定性、安全性。

即使结果对、轨迹干净，Agent 还要过系统指标这一关。一次调用花多少 Token、响应要等几秒、有没有越权访问。这些指标决定了 Agent 能不能上线。

三个层级的关系：

实际评测通常先建立任务完成率基线，再通过轨迹定位失败原因，最后叠加成本、延迟和安全门槛。

4. 五个评测维度

确定观察层级后，还需要把这些观察转化成可记录、可比较的指标。

4.1 任务完成率

给定一个任务，Agent 做对了多少。这是最核心的指标，其他维度都是在这个基础上展开的。

但"做对"本身就有不同的定义。有的任务有标准答案，可以直接比对；有的需要检查最终状态（比如数据库里多了一条记录）；有的要看输出是否符合约束条件（比如"回答必须包含数据来源"）。怎么定义"做对"、怎么打分，是后面第四篇要展开的内容。

4.2 执行效率

同样的任务，Agent A 用 3 次工具调用搞定，Agent B 用了 10 次。Agent A 消耗 2000 Token，Agent B 消耗 8000 Token。效率的差异直接影响成本和用户体验。

常见的效率指标：

指标	含义
Token 消耗	输入 + 输出的总 Token 数
工具调用次数	Agent 调用了多少次工具
推理轮次	AgentLoop 跑了几轮
端到端延迟	从用户提问到拿到答案的时间

效率异常通常需要结合轨迹分析。工具描述不清、上下文冗余、规划策略不合理和重试条件过于宽松，都可能增加调用次数。

4.3 稳定性

同一个输入跑 10 次，Agent 能几次做对？如果 6 次对、4 次错，即使单次成功率看起来还行，这个 Agent 也不够可靠。

稳定性的差异可能来自多个方面：prompt 不够明确，导致模型每次的推理路径不同；工具返回值有波动，Agent 没有做好容错；或者 Agent 对输入中的微小变化过于敏感，换个说法就不会了。

τ-bench 使用 pass^k 衡量重复执行的可靠性。对每个任务运行 k 次，只有 k 次全部成功，才算通过该任务的 pass^k 评测。它通常会低于 pass^1，两者差距越大，说明 Agent 的重复执行能力越不稳定。需要注意，pass^k 应通过实际重复运行统计，不能直接根据单次成功率计算。它和代码生成中表示"k 个候选答案至少一个通过"的 pass@k 不是同一个指标。

4.4 安全与约束遵循

Agent 不仅要做对，还要在允许的范围内行动。

代码 Agent 是否在未经授权的情况下执行了破坏性命令？客服 Agent 是否承诺了不该承诺的退款？金融 Agent 是否访问了未授权的数据源？这些"做对了但不该做"的行为，比答错更危险。

评测时需要明确定义：允许使用的工具有哪些、禁止执行的操作有哪些、哪些信息不能泄露。然后检查 Agent 的执行轨迹是否越界。

4.5 可恢复性

Agent 遇到错误或意外情况时，能不能自己修正。

工具调用失败、输入存在歧义或者上下文信息不足，都会打断 Agent 的正常执行。评测需要观察它能否识别问题，并选择重试、澄清或降级。一个具备恢复能力的 Agent，会根据错误类型进行重试，或者主动向用户补充确认。差的 Agent 会直接报错，或者编造一个看似合理但实际错误的结果。

这个维度经常被忽略，但对用户体验影响很大。真实使用中，工具报错、信息缺失是常态，不是例外。

这些维度没有固定的统一顺序。任务完成率通常是基础指标，效率用于优化成本和体验，而安全与权限约束在高风险场景中属于必须满足的硬性条件。

5. 评测基本流程

理论讲完了，来看实际怎么做。评测的基本流程只有五步：

用一个具体例子走一遍。

第一步：构造任务。

复制代码

用户输入："今天北京天气怎么样，需要带伞吗？"
期望行为：调用天气 API 获取数据，根据降水概率给出建议
期望输出：包含实际天气数据的回答，不能编造
允许工具：get_weather
禁止行为：不能编造天气数据

注意，任务不只是一个输入，还包括期望行为、允许工具和禁止行为。这些是评分的依据。

第二步：执行 Agent。 把任务丢给 Agent，让它正常跑。

第三步：记录轨迹。 Agent 的每一步都被记录下来：

第四步：评分。 对照期望，逐项打分。

维度	评分	说明
任务完成率	通过	回答包含实际天气数据，建议合理
执行效率	1 次工具调用，2 个执行步骤	效率良好
安全与约束	通过	只调用了允许的工具
稳定性	需要多次运行才能判断	单次通过不代表稳定

第五步：分析失败。 如果某项没通过，定位原因。

假设 Agent 没调天气 API，直接编造了"北京今天晴，25°C"，任务完成率判为失败。这次失败发生在工具选择阶段。接下来需要检查天气工具是否成功注册、路由规则是否命中，以及工具描述和系统提示是否明确。确认原因后，再决定修改 Prompt 还是调整运行时约束。可以在系统提示中明确实时数据的使用规则，并在运行时增加校验：如果天气类任务没有产生工具调用，则直接判定本次执行失败。

这就是一次完整的评测循环。看起来简单，但每一步都有细节问题：任务从哪来？怎么定义"正确"？轨迹怎么记录？评分用程序还是用模型？这些问题会在后续五篇中分别展开。

6. 小结

Agent 评测的难点，不是为一次回答生成一个总分，而是把"表现好"拆成可以验证的结果、可以分析的过程和可以接受的运行边界。公开 Benchmark 适合观察通用能力，真正推动产品迭代的，则是覆盖自身业务场景的私有 Eval。

有了这套观察框架，下一步就是选择合适的尺子。下一篇将从代码评测的演进出发，看看评测对象如何从单个函数扩展到完整代码仓库。

Agent 评测：如何判断一个 Agent 是否可靠