先记住这个答案
任务成功率应以预先定义的任务验收条件为准，检查真实产物或环境结果，并满足必要约束。最基础口径是在固定运行预算和环境条件下，成功试验数除以全部纳入统计的试验数。需要同时说明任务集合、每题尝试次数、允许的恢复策略和失败处理方式。部分完成可以单独计分，但不能悄悄当作完整成功；多次尝试后至少成功一次，也不能冒充单次成功率。
- 成功判据看实际结果和必要条件，不能只看 Agent 自报完成
- 分母、重试规则和运行预算必须随指标一起说明
- 按任务类型与失败原因分层，避免总分掩盖退化
先定义不可含糊的完成条件
例如 Agent 要更新文档中的配置说明，成功可以要求目标文件修改正确、示例与当前实现一致、相关链接有效。最终回复说已更新只是一条声明，不能代替文件检查。若用户还要求保留原有章节，这一约束也必须纳入验收，而不是只看新增文字存在。
在任务开始前固定判据，避免看到结果后调整门槛。对无法完成但按要求正确解释原因的情况，需要按产品契约判断：如果任务本来要求识别不可行条件，合理拒绝可能是成功；如果用户目标仍未达成，则应明确记录未完成，不能统一计入成功。
说明重试和分母如何计算
假设同一任务允许内部修复两次后交付，这些恢复属于一次试验的执行策略，成功率应连同预算一起报告。如果把整个任务重开五次，只挑最好结果展示，就测量了另一种能力。至少一次成功的指标可以有用，但需要说明筛选依据与额外成本。
工具故障、超时和主动取消都要有稳定的处理规则。可以把系统可用性和 Agent 决策质量分开统计，同时保留总体任务完成结果；不应在结果不理想时临时移除失败试验。没有进入评分的样本也要说明数量与原因。
避免一个平均值掩盖问题
当简单任务很多时，总成功率上升可能同时伴随复杂任务下降。可以按场景、难度或所需工具分层，报告每组样本数。比较版本时使用相同集合，观察每个任务从成功变失败或从失败变成功的变化，而不只看两个总数。
对重复试验要给出波动或不确定性，少量样本的几个百分点不能轻易解释为稳定提升。效率指标也应与结果一起看：一个版本靠无限重试获得更高成功率，可能不符合用户等待时间。成功率、耗时和每个成功任务的成本需要共同支撑产品判断。
容易答错的地方
- 把部分完成加进成功分子
- 可以展示步骤覆盖率或质量分，但完整成功仍要满足预设门槛，否则指标失去清楚含义。排查“AI Agent 任务成功率定义与统计口径”时还要核对输入、版本和执行顺序，并用反例确认修复后的边界。
- 只统计正常结束的运行
- 把超时或崩溃排除后，分母会偏向容易完成的任务。应保留一致规则并单独说明系统失败。排查“AI Agent 任务成功率定义与统计口径”时还要核对输入、版本和执行顺序，并用反例确认修复后的边界。
面试官还会怎么问？
pass@k 和单次成功率可以直接比较吗？
不能。前者关注多次尝试中至少一次成功，单次成功率关注一次试验的结果，资源预算和筛选机制不同。
每个任务重复次数不同怎么办？
先明确是按任务平均还是按试验汇总，避免重复次数较多的任务获得隐含更高权重，并公开计算口径。
用户满意度能替代成功率吗？
不能完全替代。用户满意度反映体验，任务结果检查反映约定目标是否达到，两者可能不一致，应联合分析。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。