Agent 评测是怎么打分的？完成率

智能体跑完一轮任务后，评测打分要回答的问题是：这次到底算不算做成了？听起来简单，拆开却有好几层口径。完成率是最常用的分数，但怎么定义「完成」，直接决定了这组数字有没有参考价值。

类比学生考试：总分一样，有人按答对题数算，有人按步骤分算，得分自然不同。失效之处在于，智能体任务不像选择题有标准答案，很多产出要按「是否达成目标」判定，评分口径稍一松动，分数就失真。

完成率是怎么统计出来的

典型流程是：先准备一批评测用例，每个用例带初始输入与预期目标；跑完后逐例核对终态，达成目标记一分，失败记零，部分达成是否给中间分由口径决定；汇总成完成率。进来的用例要固定，中间的执行环境要一致，出去的分数才可比。DeepSeek、豆包这类模型在同样用例下跑出的数字，才能横向对比。

单看完成率会漏掉什么

同样是完成，代价可以差很远：一个用三步搞定，一个绕了二十步还多花了十倍调用量，完成率却一样。所以完成率通常要搭配步数、调用量、耗时一起看，成本口径的拆法见这篇多 Agent 的成本怎么核算？拆开细算。还有一类是「蒙对的」——结果碰巧正确、过程不可复现，这类要靠抽查执行轨迹识别。

完成率之外还要看什么，几类指标各管一段。

评测集怎么搭才靠得住

三个要点：覆盖主路径也覆盖边角，比如空输入、超长输入、含干扰信息的输入；每条用例写清判定标准，避免凭感觉打分；定期补充真实运行中翻车的案例，评测集才会越长越准。用例之间相互独立，别让一条用例的残留状态影响下一条。

分数波动意味着什么

波动先看三处：换了模型版本或提示词，属于正常变量；执行环境抖动，比如外部接口抽风，会拖低分数，这与能力退化无关；抽样太少则天然不稳，加大样本量再看趋势。把失败案例按环节归类，能定位是规划问题还是工具调用问题，排查思路可参考长时任务看哪些监控指标？内部门道在这。

评测打分速查表

• 先定「什么算完成」再谈分数
• 完成率搭配步数与调用量一起看
• 评测集覆盖主路径与边角情况
• 波动先查变量与环境，再谈能力

一句话记住：口径不清，分数白算。

评测范围也别漏了异常路径：失败后能否恢复、越界操作会不会被拦，这些和安全设计直接相关，见Agent 的安全边界怎么划？一次划清；退回动作是否退干净，则对应补偿事务是怎么回滚的？反向操作。分支设计影响跑测时各条路径的覆盖，可在工作流的分支条件是怎么定的？机制细节全梳理里对齐口径。评测不是一场考试，而是持续盘点，考卷越贴近真实使用，分数越有说服力。

评测用例的维护也有节奏：每月清点一次，长期全部通过的用例说明太简单，可以加难；长期全部失败的说明口径或能力没跟上，要么修能力要么修口径。评测集本身也要有版本概念，用例变了，分数就不能和历史直接比，要在报表上注明断层，避免误读成能力骤降。跨团队复用评测集时，先对齐完成口径再对数字，同一份用例在不同口径下能差出几十个百分点，这是最常见的误会来源。最后留一条底线：任何对外引用的完成率数字，都应该能回溯到具体评测集版本和判定规则。

评测打分快问快答三则

• 完成率多少算及格？：没有统一线，关键看与上一版比的相对变化，以及失败案例是否可解释。
• 要不要让大模型当裁判？：可以，但要抽查裁判结论，必要时用规则判定兜住关键项。
• 多久跑一轮评测？：改动提示词、换模型、升级工具后必跑，平时按固定节奏跑，保证可比性。