做 Agent 的人常卡在两件事：上线前不知道测什么，上线后看着「成功率还行」却总觉得不对劲。这篇把常用指标拆开讲清楚——每个指标怎么定义、用哪条数据算、什么条件下数字会虚高，再给一个三五人小团队能当天跑起来的最小测试集。只讲怎么测怎么读，不讲选型。
做 Agent 的人常卡在两件事：上线前不知道测什么，上线后看着「成功率还行」却总觉得不对劲。指标不是越多越好，关键要知道每个数字在量什么、用哪条数据算、什么条件下会虚高。这篇把常用指标拆开讲清楚，再给一个三五人小团队能当天跑起来的最小测试集。只讲怎么测怎么读，不讲选型。
先说明一个前提：下面所有指标都依赖同一批任务集和同一套判定标准。没有固定任务集，任何数字都没法比较；没有写死的判定标准，数字只反映你自己当天的心情。所以下面的做法都从攒任务集开始。
核心指标清单：每个指标在量什么
任务完成率是最外层指标：把一批任务跑完，判定「最终交付物是否达标」。注意判定标准要先写成可勾选的条目，比如「包含三个指定字段」「格式能直接被下游解析」，而不是「回答得还不错」。靠感觉判分，数字每次都不一样，没法做回归对比。
步骤正确率看的是过程：Agent 拆出的计划里关键步骤有没有走对、有没有多余绕路。它适合用带标准路径的任务集来算，也就是你事先知道一个合理流程长什么样。工具调用准确率只看动作层面：该调哪个工具、传参对不对、有没有重复调或漏调。这两项和最终成功率经常不是一回事，成功率掉了未必是工具调错，工具全对也可能交付物不合格。
- 任务完成率
- 最终交付物是否达到预先写好的可勾选标准
- 步骤正确率
- 关键步骤有没有走对，是否有明显多余路径
- 工具调用准确率
- 工具选择、参数、调用次数是否符合期望序列
- 成本与延迟
- 单任务 token 消耗、工具调用次数、端到端耗时
- 失败恢复率
- 第一次失败后能否自行换路径走通
成本与延迟要按任务类型分开统计，混在一起没有参考价值，因为单步任务和多步任务的量级天然不同。失败恢复率只有带故障注入的测试集才测得出来，平时正常跑通的任务根本触发不到这条路径。
怎么落地测：从任务集到判定规则
先攒任务集，别一上来就测几百条。三十到五十条真实任务起步，按「单步 / 多步 / 需外部工具」分三档。每条任务写清三样东西：输入、可接受的交付物标准、期望调用的工具。这三样就是后面所有指标的判分依据，缺一样对应指标就废了。
- 攒任务集从真实使用记录里挑 30 到 50 条，按单步、多步、需外部工具分三档，覆盖你要上线的场景
- 写判定依据每条任务补上输入、可勾选的交付物标准、期望工具序列，三样缺一不可
- 跑基线用当前版本跑完整批任务，记录每个指标，作为后续任何改动的对照基准
- 双轨判分完成率和步骤正确率用规则校验加人工抽检双轨跑，纯规则容易被措辞绕过
- 自动统计工具项工具调用准确率全自动统计，把真实调用序列和期望序列做比对，错在哪一步能直接定位
- 看分布不看均值成本和延迟统计单任务分布，长尾那几条往往才是真正拖慢体验的
接口侧的延迟基线可以先用站内工具量一遍，再和 Agent 端到端耗时对照，才知道时间花在模型还是在工具上。对照方法可以到 /tools/speed-test 看，那边有现成的测速入口可以借用，不用自己从零搭。
数字虚高的几种典型情况
任务集太简单或题型单一，完成率天然好看，换个业务场景立刻掉下来。判分标准如果放宽到「只要回答了就算完成」，完成率会虚高，但步骤和工具项会同时掉，这三个指标要一起看才看得出破绽。
| 虚高现象 | 背后原因 | 怎么发现 |
|---|---|---|
| 完成率漂亮 | 只统计跑完的样本，报错超时丢弃 | 把失败样本也计为未完成再算一遍 |
| 工具准确率满分 | 工具是自家实现，错误被内部吞掉 | 查端到端耗时是否悄悄变长 |
| 成功率随重试上升 | 多次重试刷出来的数字 | 加统计重试次数，对延迟敏感场景单独看 |
| 测试集表现异常好 | 混进了调试阶段见过的样例 | 换一批没见过的任务重跑对比 |
还有一种容易被忽略：报错、超时、中途放弃的样本被主动丢掉，等于给自己发安慰奖。补算方式很简单，把这些样本全部计为未完成，重新算一次完成率，两个数字的差距就是虚高程度。测试集里混进训练或调试阶段见过的样例也很常见，尤其在自建 Agent 上，发现方法就是换一批全新任务重跑。
只统计成功跑完的那批，不是评估，是挑好看的说。
小团队先测哪三个，怎么排顺序
人手有限的时候，指标要按「能不能对外汇报」和「改动后能不能立刻看到回归」两条来排。任务完成率排第一，但必须配一份写死的判定标准，这是唯一适合对外说的数字。工具调用准确率排第二，因为它最便宜、最可自动化，改提示词后跑一遍立刻知道有没有退步。成本与延迟排第三，涉及能不能上线的账，等完成率稳定后再作为固定看板跟踪。
- 第一优先任务完成率：配写死的判定标准，是唯一适合对外汇报的数字
- 第二优先工具调用准确率：最便宜最可自动化，改动后回归看得最快
- 第三优先成本与延迟：能不能上线的账，放在完成率稳定之后固定跟踪
- 步骤正确率、失败恢复率往后放：等多步任务样本够了再加，样本不够没有统计意义
- 节奏上先跑一轮拿基线，每次改动只动一个变量，重跑同一批任务
如果你测的是带外部依赖的 Agent，步骤正确率和失败恢复率可以往后放，等任务集里多步任务的占比上来了再加。这批指标的参考数值会随模型和工具变化，具体到当时的数字，到 /rankings 核对就行，不要拿几个月前的印象当基线。
下一步先把你这边的三十条任务和判定标准写出来，再对照站内的评测方法统一口径，跑出你自己的基线数字。→常见问题
任务完成率的判定标准怎么写才不虚？
每条任务列 2 到 4 条可勾选的交付要求，满足全部才算完成，部分满足记为半分。避免用「回答是否合理」这类模糊表述，否则不同人判出来的结果能差一截，同一批数据的结论没法复用。判定人尽量固定，换人时先对同一批样本校准一遍。
小团队没有标注人力，指标还能测吗？
能，但要换口径。把任务设计成有确定答案的形式，比如能从结构化输出里校验字段、能从工具返回里比对结果。工具调用准确率、成本、延迟三项完全可以自动统计，先跑这三项拿到基线，完成率改成每周人工抽检二三十条，够用。
同一个 Agent 换模型后，指标怎么比才公平？
锁定任务集、提示词、工具实现和判分规则，只换模型这一项，其余不动。跑完看完成率和工具调用准确率的变化，同时把延迟和 token 消耗一起记下来，否则容易得出「新模型更好但贵得离谱」这类没结论的对比。
失败恢复率必须做故障注入才能测吗？
基本是的。正常调用路径下工具很少出错，恢复能力根本不会被触发。可以人为在测试环境让某个工具返回超时或错误码，看 Agent 会不会换参数重试、换工具、或直接向用户说明。没有这一步，恢复率这个指标基本是摆设。
