智能体宣传材料里出现频率最高的数字是任务成功率，也最容易注水：同一个 AI Agent，换一套任务定义或判分口径，成绩单能差出一大截。想判断一个智能体到底行不行，或者想给自己搭的 Agent 定改进目标，都得先把“成功”这两个字定义清楚，再谈数字。
先把「成功」定义清楚
定义成功率之前，有三件事必须明确。其一，什么算完成：输出内容正确就算，还是操作真的落地了才算？填完表单和表单真的提交成功，是两个口径。其二，允不允许人工干预：中途有人接管补救，算智能体的成功还是算失败？其三，中间出错但最后修正了，算不算成功？这三处的选择不同，同一个智能体的成功率能差出几十个百分点。看任何宣传数字，先问它用的哪套口径，口径不明的数字只能当故事听。
多步任务的成功率为什么会塌
单步任务的成功率普遍好看，一旦变成多步串联，数字会塌得很快。做个算术：假设单步可靠度是 95%，十步全部顺利的概率是 0.95 的十次方，大约只剩六成。这还是理想情况——实际更糟，因为一步出错之后，后续步骤建立在错误的状态上，错误会滚雪球。所以 demo 里五步演示的效果，完全不能外推到三十步的真实流程上。评测时要按你真实任务的步骤数来测，这是最容易被忽略、也最容易修正的一个误差来源。
比成功率更重要的恢复能力
盯数字之外，更要看失败之后发生什么：能不能发现自己错了（有没有校验环节）、能不能退回上一步（有没有状态快照）、能不能换个路径重试（会不会重新规划）。一个成功率略低但能自我纠正的智能体，往往比一个成功率略高但一错到底的更实用——前者把失败变成可修复的过程，后者把失败直接变成废结果。想看清这些行为，执行过程必须可见，Agent 可观测性讲的就是怎么盯住它的每一步。
按风险分级定标准
风险等级决定该把标准定在哪，以及哪些环节必须留人工确认点。
| 任务风险 | 典型例子 | 建议的标准与确认要求 |
|---|---|---|
| 低（错了可重来） | 信息整理、内容初稿 | 成功率七成上下即可接受，定期抽检 |
| 中（返现有成本） | 批量修改内部文档、数据分析 | 要求明显高于及格线，关键结论人工核对 |
| 高（难以撤回） | 涉及资金的操作、对外发布 | 接近无错，关键步骤逐一人工确认 |
高风险任务里，人工确认点的设置本身就是安全设计的一部分，Agent 的安全边界怎么划给了可操作的划分方法。另有一个前置判断值得做：能写成固定流程的任务，优先用固定工作流而不是自由发挥的智能体，工作流和 Agent 差在哪对比了两条路线的适用条件。
自己搭评测的四个动作
其一，任务从真实工作里挑，不用厂商演示用的那些干净样本。其二，步骤数对齐真实情况，三十步的流程就按三十步测。其三，把判分口径写成文档：什么算成功、边缘情况怎么判，让两次评测的结果可以比较。其四，列出必须人工确认的环节清单，评测时同时记录「哪些步骤要在生产里加确认点」。执行层的不确定性从哪来，可以看浏览器类 Agent 的例子，浏览器 Agent 是怎么点页面的拆过视觉与结构两条路线的差别。
成功率评测速查
- 先问口径：什么算完成、允不允许人工干预
- 单步 95%，十步串联只剩六成左右
- 恢复能力：发现错误、退回重试、重新规划
- 风险越高，人工确认点越多
- 模型一升级，评测重做一遍
衡量成功率前的三个疑问
- 厂商报告里的成功率还能参考吗？：可以，但要追问口径：任务集谁定的、平均步骤数多少、有没有人工兜底。三项都能查到的报告参考价值高，查不到就降低权重。
- 两个智能体成功率相近，怎么选？：比恢复能力和过程可见性。出错时能报警、能回滚、能让你看到卡在哪一步的那个，长期用起来省心得多。
- 评测一次管多久？：底层模型一换就要重测。模型升级后智能体的行为会整体漂移，旧的成功率数字不能沿用，哪怕任务一个字没改。
成功率是衡量工具，别让它变成目标本身。为刷高数字把任务定义改简单，是这类评测里最常见的自欺。
