如何量化评估 Agent 输出质量或任务成功率？

核心回答

Agent 评估要先定义任务在什么条件下算完成，再同时衡量结果质量、执行过程和运行代价。回答流畅、工具返回成功，都不能直接代替任务成功。

1. 建立有代表性的任务集：固定输入、初始状态、权限和验收条件，覆盖正常任务、信息不足、工具异常与高风险边界，并留出不参与调参的测试集。
2. 按任务选择评分器：问答检查事实、完整性和依据；建单检查实际记录、关键字段和重复单；代码修改检查需求用例、原有功能与修改范围。能用规则或执行结果验证的优先自动检查，开放式质量由明确量表的模型裁判辅助，并用人工样本校准。
3. 统计成功与稳定性：报告固定预算内的任务成功率，区分一次通过、重试后通过和人工接管；同一任务重复运行，按场景看波动，不能用挑出的最好结果代表日常表现。
4. 同时比较代价：记录端到端耗时、费用、工具错误和人工介入。用相同任务与评分规则比较新旧版本，再通过线上抽样验证实际表现。

例如建单任务，成功应是“正确客户下创建了字段齐全且无重复的订单”，而不只是最后回复“已建单”。如果身份或必填信息缺失，正确行为可能是先澄清，而非强行创建。

先把“正确”写成可验证的条件

一条评测任务至少要包含用户目标、起始数据、可用工具与权限、完成预算，以及可检查的预期结果。预期不一定是一段唯一答案，也可以是一组应满足的条件。

问答任务分别检查结论是否正确、关键条件是否覆盖、引用是否支持结论。忠实于给定材料和现实中正确是两个维度：过期材料也可能被准确复述，所以还要核对材料版本。对无答案、信息冲突的请求，也要定义合理的澄清或拒答行为。

建单任务检查目标系统中的最终状态：单据是否存在，客户、商品、金额等字段是否正确，是否重复创建，是否遵守必需的确认和权限约束。异步接口返回“已受理”时，要等待约定的终态再判定；测试环境应可重置，防止上一轮留下的单据污染下一轮。

代码修改任务检查需求对应的用例是否通过、原本正确的功能是否保持，以及有没有改动范围外文件。测试集要能区分真正修好与删除断言、绕过功能等取巧做法。只看编译成功或某一条新增测试，覆盖不到这些问题。

必须满足的正确性和权限条件应单独判定。表达清晰、语气友好可以另评分，但不能用这些得分抵消订单金额错误。可以保留部分完成度帮助分析，例如已识别需求、已填完字段但提交失败；这不等于整条任务成功。

分开评估结果、单步和完整轨迹

结果评估回答“事情是否做成”；单步评估检查工具选择、参数或某次回答；轨迹评估观察是否遵守必要约束、发生多少无效循环，以及工具错误后怎样继续。三者作用不同，通常组合使用。单步全部通过也不能自动推出端到端完成。

轨迹保留用户输入、模型可见上下文、工具请求与返回、状态变更和各段耗时即可。并非所有任务都有唯一合法路径：先查商品再查客户，和先查客户再查商品，都可能正确；身份核验必须先于敏感写入，则属于不能省略的业务顺序。评分时应区分两者。

评分器可以分工：

• 规则或代码检查字段、数值、数据库终态、测试结果及禁止动作，结果容易复查，但要允许合法的等价输出。
• 模型裁判对照资料和量表，分别评事实、覆盖、依据与表达，保存判定理由。固定裁判版本，在人工标注的代表样本上检查误判；评估方案 A/B 时，还要注意展示顺序和长答案偏好。
• 人工评审处理标准制定、专业争议和高风险样本，并帮助检验自动评分器是否测到了真正目标。

如果一个本来正确的方案被评分器拒绝，先修订错误的评分条件，再统一重评所有比较组。公开基准适合了解工具调用或多步任务能力，但自己的工具、数据和业务约束仍需要自己的任务集。

成功率的分母与重试口径要固定

可以把任务成功率定义为：

任务成功率 = 在约定预算内满足全部必要条件的运行次数 / 纳入评估的总运行次数。

这里的一次运行可以包含系统内部允许的重试，但重试上限、总时长、费用和人工是否介入要预先固定。工具超时、达到上限和执行失败也要进入结果；因评测环境损坏而无法评分的情况另列数量与原因，不能只汇总成功返回的请求。需要评估无需人工的能力时，另报自主完成率；人机协作成功率则以整个协作流程为对象。

下面是说明口径的假设例子：100 条任务各运行一次，80 条首次通过，10 条在允许重试后通过，10 条仍失败，那么首次通过率是 80%，预算内完成率是 90%。这 90% 不是“每次都能一次做对”。若从失败任务里人工挑出一个成功版本，也不能回填成首次通过。

对同一任务运行多次，还可以区分两个问题：pass@k 看 k 次尝试中至少一次成功，适合允许产生多个候选再验证的场景；pass^k 看 k 次是否全部成功，更强调重复服务的稳定性。报告时要说明尝试次数和选择成功结果的机制。真实任务难度和失败原因常不相同，不能把一次总体成功率简单乘方，当作重复可靠性的实测结果。

样本还应按任务类型、难度和风险分组。总成功率上升，可能只是简单任务比例变大；多次重复同一道题也不能当成同样数量的独立业务样本。比较版本时固定样本与环境，报告样本量、差异和不确定性，小幅变化需要更多证据。

质量之外，还要观察付出的代价

记录成功与失败任务的端到端耗时分布、模型和工具费用、循环次数、工具错误与人工接管。只统计成功请求的延迟，会漏掉最慢的失败；只看每次调用便宜，也可能漏掉多轮重试的总费用。

例如增加自检后，成功率上升但耗时和人工审阅量大幅增加，就要结合业务要求决定是否采用。上线后抽样检查任务结果、投诉和接管原因，按实际流量观察变化；复杂任务合理转人工，不应与越权或错误执行混成同一种失败。如何证明这些变化带来业务收益，可继续看Agent 解决了什么业务问题，如何证明实际提效？。

追问：没有唯一标准答案，怎么评？

把目标拆成可核验的事实、必须覆盖的内容和禁止行为，再为开放部分设置评分量表。例如调研报告可以检查关键问题是否回答、引用是否支持事实、是否区分证据与推断，而不要求复现某篇参考报告的文字。模型裁判能扩大检查规模，但其判断仍要用专家样本验证；没有可靠参考时，单看相关性和流畅度不足以证明事实正确。

如果分数低，需要进一步定位具体原因，参见Agent 效果不达预期时，如何分析 Bad Case 并确定优化方向？；RAG 的检索覆盖、生成忠实性等细分指标，参见如何设计 RAG 评估方案和指标？。

对应教程

参考资料