指标体系

一句话理解：指标要分层看：用任务成功率回答“做成没有”，用过程指标解释“为什么”，用成本、延迟与人工介入率回答“值不值得上线”，再用安全指标守住底线。

“我们的 Agent 准确率 87%”，这句话几乎没有信息量。87% 是怎么算的？“无法判断”算对还是算错？剩下 13% 里有多少是自信地给错了结论？每个任务花多少钱、多长时间、要不要人来兜底？不同类型的异常是不是都在 87% 左右？

这一课建立一套 Agent 指标体系：每个指标怎么定义、回答什么问题，怎样读一份评测报告，以及怎样把指标变成上线门槛。

四层指标

Agent 的指标可以分成四层，外加一条贯穿各层的底线：

离线评测主要覆盖第 2–4 层；第 1 层要靠线上数据，见线上评估与回归。Anthropic 在关于为 Agent 编写工具的工程文章中也建议，除了准确率，还要收集单次工具调用与整个任务的运行时间、工具调用总次数、Token 总消耗和工具错误数。这些“过程数据”往往能暴露低效的工作流。

核心指标定义

指标	计算方式	回答的问题	客服工单场景的解读
任务成功率	判定为成功的任务数 ÷ 总任务数	整体做成了多少	结论正确、处置合规，才算成功
错误率	给出结论但结论错误的任务数 ÷ 总任务数	有多少是自信地错了	最危险的一类，要单独盯
无法判断率	输出“无法判断”的任务数 ÷ 总任务数	有多少没有给出结论	要区分“本应无法判断”和“本可以判断”
覆盖率	给出结论的任务数 ÷ 总任务数	Agent 能独立处理多大比例	覆盖率高而错误率也高，不是好事
自动结论准确率	正确任务数 ÷ 给出结论的任务数	Agent 下了结论时，有多可信	决定用户敢不敢直接采纳
一致性	同一任务多次试验全部成功的比例	每次都靠谱吗	对应 pass^k
工具选择准确率	选对工具的决策数 ÷ 需要选择工具的决策数	该查的查了、不该调的没调吗	可以简化为“必调工具全部调用且未调用禁用工具”的任务比例
参数正确率	参数正确的工具调用数 ÷ 工具调用总数	工具调用有没有传错	工单号格式、时间范围、枚举值
重试率	发生过重试的工具调用数 ÷ 工具调用总数	工具或参数稳定吗	高重试率会推高成本与延迟
人工介入率	需要人工接手、修改或审批的任务数 ÷ 总任务数	离“自动完成”还有多远	包括主动升级和被审核拦下的错误
单任务成本	模型费用 + 工具费用（+ 人工复核成本）÷ 任务数	每单花多少钱	详见成本模型
延迟	P50 / P95 的端到端耗时	用户要等多久	平均值会掩盖长尾，要看 P95
安全违规数	未审批写操作、越权工具调用、泄露敏感信息的次数	有没有越线	硬指标，目标为 0

两个定义上的细节最容易引起争议，务必在团队内写清楚：

1. “无法判断”算什么？ 如果标准答案本身就是“无法判断”（数据确实缺失），Agent 输出无法判断就是正确；如果数据齐全、本可以判断，Agent 却说无法判断，应该计为未完成，而不是“错误”。
2. 一个任务跑多次，怎么计分？ 可以按平均成功率统计，也可以按多数票统计，还可以按“全部成功”统计（即 pass^k）。选哪种都行，但版本之间必须用同一种。

读一份评测报告：100 个客服工单案例

下面是一份评测报告的摘要（全部为示例数字）：

评测集：support-tickets v1.2（100 个任务，每个任务 3 次试验，按多数票判定）
Agent 版本：prompt v7 + tools v3

任务结果
  正确            87
  错误             8
  无法判断          5
  覆盖率          95%    （87 + 8）÷ 100
  自动结论准确率   约 92%  87 ÷ 95
  3 次全部成功     76 个任务

过程质量
  工具选择准确率   94%
  平均工具调用     5.2 次 / 任务
  重试率           6%

运行效率
  单任务成本       约 0.38 元
  P95 延迟         41 秒

安全
  未审批写操作     0

把报告里的任务结果画出来，几个比率之间的关系会更清楚：

读这份报告，至少要得出以下几个判断：

• 87% 与 92% 讲的是两件事。 87% 是整体成功率；92% 是“Agent 一旦给出结论，有多大把握是对的”。对于要不要让业务人员直接采纳结论，后者更关键。
• 8 个错误比 5 个无法判断更值得优先看。 无法判断至少是诚实的，错误会直接造成损失。
• 87 与 76 的差距说明稳定性不足。 有 11 个任务虽然多数票正确，但 3 次里至少有 1 次失败，用户会遇到“时灵时不灵”。
• 下一步是归因。 把 8 个错误和 5 个无法判断逐条读记录，按工具错误、数据缺失、推理错误、规则错误分类，见错误归因。

切片：平均数会骗人

把同一份结果按工单类型拆开（示例数字）：

切片	案例数	正确	错误	无法判断	正确率
支付回调失败	30	29	1	0	97%
退款未到账	25	23	1	1	92%
日志缺失	20	15	2	3	75%
账号问题	15	13	1	1	87%
企业客户退款规则	10	7	3	0	70%
合计	100	87	8	5	87%

把各切片的正确率画在同一条刻度上：

整体 87% 看起来还行，但“企业客户退款规则”只有 70%，而且 3 个错误全是自信地给错，这恰恰是金额最大、客户最敏感的一类。常用的切片维度有：工单类型、客户等级、数据完整度、任务难度、样本来源（典型、边界、对抗）。

从指标到上线门槛

指标太多等于没有指标。建议分成三类：

• 北极星指标：一个最能代表“任务做成”的指标，例如任务成功率。
• 护栏指标：不能变差的指标，例如错误率、安全违规数、成本、P95 延迟。
• 诊断指标：用来解释变化，不直接作为门槛，例如工具调用次数、重试率。

把门槛写成明确的规则，在每次发布前自动检查（示例阈值）：

release_gate:
  eval_set: support-tickets v1.2
  must_pass:
    task_success_rate: ">= 0.85"
    confident_error_rate: "<= 0.05"
    pass_hat_3: ">= 0.75"
    safety_violations: "== 0"
    cost_per_task_cny: "<= 0.50"
    p95_latency_seconds: "<= 60"
  slices:
    key_account_refund:
      task_success_rate: ">= 0.80"

别被噪声骗了

100 道题的评测集，分数本身就有波动。Anthropic 的研究文章《A statistical approach to model evaluations》建议报告评测分数时附上标准误，而不是只给一个点估计。

做个粗略计算：成功率 87%、样本 100 时，标准误约为 √(0.87 × 0.13 ÷ 100) ≈ 3.4 个百分点，95% 置信区间大约是 ±6.6 个百分点。这意味着，v8 比 v7 高 2 个百分点，很可能只是噪声。

同一篇文章还提到几种减少误判的方法：同一题目多次采样时，要注意题目之间的相关性，使用聚类标准误；比较两个版本时，用同一批题目做配对差异分析。实践中最直接的做法是：看分数变化的同时，逐条查看“由对变错”和“由错变对”的题目，这部分放在线上评估与回归展开。

常见误区

• 只看一个平均成功率。 错误率、无法判断率、切片表现和一致性都被藏起来了。
• “无法判断”的计分规则不清楚。 有人算作失败，有人算作成功，版本间的比较就失去意义。
• 成本只算模型 Token。 工具调用费用、重试和人工复核的成本同样是单任务成本的一部分。
• 指标列了二十个，没有门槛。 每次评审都在讨论“这个指标降了一点要不要紧”，最后谁也做不了决定。
• 把 2 个百分点的变化当成显著提升。 样本量不足时，先看置信区间和逐题翻转情况。

产品经理检查清单

• 北极星指标是什么？护栏指标有哪些？
• “成功”“错误”“无法判断”的定义是否写成了文档，并且团队一致认可？
• 是否单独统计了“自信地错”的比例？
• 是否按关键切片（工单类型、客户等级、数据完整度）拆开看？
• 单任务成本是否包含工具费用、重试与人工复核？
• 上线门槛是否写成了可以自动检查的规则？
• 评审分数变化时，是否考虑了样本量带来的波动？

练习

某发票审核 Agent 在 200 张发票上的评测结果如下（示例数字）：正确 170，错误 12，无法判断 18；其中 18 个无法判断里有 10 个的标准答案本来就是“需补充材料”；安全违规 0；单任务成本 0.21 元；P95 延迟 25 秒；按供应商类型切片，“境外供应商”40 张中正确 26 张。

请完成：

1. 按本课的定义，计算任务成功率（注意那 10 个“本应无法判断”）、错误率、覆盖率和自动结论准确率。
2. 为这个 Agent 写一份上线门槛（北极星 1 个、护栏 3–4 个、切片门槛 1 个）。
3. 判断它现在能否上线，并用三句话说明理由和下一步优化方向。

延伸阅读

• Demystifying evals for AI agents（Anthropic）：pass@k 与 pass^k 等 Agent 评估指标。
• A statistical approach to model evaluations（Anthropic）：标准误、聚类标准误、配对差异与功效分析。
• Writing effective tools for agents — with agents（Anthropic）：评估工具时建议收集的运行时间、调用次数、Token 与错误数。

下一步

指标需要有人来“判分”。下一课「评分方式」讲代码断言、LLM-as-Judge 与人工评审各自适合判什么，以及怎样把三者组合成一条评分流水线。