AI Agent 任务成功率，指在事先定义的成功标准下，企业级 AI Agent 完成的任务数占全部可评估任务数的比例。常用算法是：
任务成功率 = 达标任务数 ÷ 可评估任务数 × 100%
例如让 Agent 处理 100 条客户资料更新，其中 90 条同时满足字段完整、来源可追溯、格式正确和写入成功，任务成功率就是 90%。
这个比例看似只是一次除法，实际受四个变量影响：任务怎么选、成功怎么判、失败怎么算、同一任务跑了几次。企业级 AI Agent 的评估，难点主要在这些口径上。口径不同，两个都叫 90% 的数字，含义可能完全不同。
任务成功率是什么
任务成功率衡量结果，不衡量过程是否顺利。一次运行要记为成功，通常需要同时满足全部必选条件，包括最终状态正确、必要产物齐全、没有禁止的副作用、格式与权限符合要求。表达质量、响应速度可以另算，不能用高分抵消必选条件的失败。
计算前要先确定三件事。任务单位是单次运行还是单个任务；分母是否只包含有效任务；失败、取消、超时和结果未知分别怎么记。比较稳妥的做法是，把无效输入、重复任务和执行前取消单列，不把执行中的失败从分母里悄悄删掉。分母被美化，成功率就会虚高。
Atlan 在 2026 年 8 月的评估指南中把成功运行定义为通过全部必选评分项，并建议把环境故障和评测系统故障单独记录。这个处理方式值得借鉴，因为评测环境自身出错时，把它算成 Agent 失败会低估能力，直接删掉又会高估能力。
任务级和运行级也要分开。同一个任务跑三次，两次成功，按运行级算约 67%；按任务级算，只要至少一次成功就算通过，结果接近 96%。两种算法都可能有价值，关键是报告时写清楚。
为什么系统显示完成，任务仍然失败
很多系统把返回答案、工具调用成功、流程走到终点记为任务完成。完成只说明执行链路结束，成功还要看结果是否满足业务目标。两者混用，是成功率失真的常见原因。
| 系统看到的信号 | 可能记录为 | 结果层还要确认什么 |
|---|---|---|
| 返回一段回答 | 已完成 | 数据口径是否正确，范围是否完整 |
| 工具调用成功 | 已完成 | 是否调用了正确的系统，参数是否符合业务规则 |
| 流程无报错结束 | 已完成 | 产物能否直接使用，是否产生副作用 |
举个财务场景的例子。让 Agent 汇总第三季度各区域年度经常性收入，它成功查到数据、生成表格，流程没有报错，但用了错误的收入定义，漏掉一个区域。系统里是完成状态，业务上仍然是失败。
因此，任务成功率的判定要尽量落在可观察的结果上，例如数据库里的最终状态、生成的文件能否通过校验、代码能否通过测试、业务系统是否返回成功回执。开放性问题才交给 LLM 评审或人工评审，并且要用同一套评分标准校准。
同一个 Agent，为什么报出的成功率不一样
两个团队都说自己的 Agent 成功率达到 90%，直接比较意义有限。至少四个口径会让数字变化。
任务集不同
公开榜单用统一任务集，企业内部用自己的业务流程。任务难度、长度、工具数量、异常比例不同，成功率自然不同。一个在短问答上达到 90% 的 Agent，换到需要跨三个系统、处理十几种异常的长流程，数字可能大幅下降。看报告时，先看任务分布，再看总平均数。
成功标准不同
同一件事，有的团队只要最终答案沾边就算通过，有的团队要求字段、口径、格式、权限、副作用全部合格。标准越宽，成功率越高。对外比较时，至少要确认成功标准是否包含必选条件，部分完成是否被计为成功。
判定方式不同
规则校验适合精确值、字段、数据库状态和公式；LLM 评审适合完整性、相关性、语气等开放标准；人工评审适合高风险和边界案例。LLM 评审会受提示词和评分细则影响，结果并不完全稳定，需要和人工判断做校准。判定方式换了，分数也会变。
运行次数不同
Agent 的输出有随机性，同一任务跑多次，结果可能不同。只跑一次得到的 pass@1，衡量第一次就成功的比例；跑 k 次至少成功一次，叫 pass@k，衡量能力上限；跑 k 次全部成功，叫 pass^k，衡量稳定性。
按独立事件粗略估算，单次成功率 90% 时，连续三次都成功的概率约 72.9%，连续十次都成功约 34.9%。单次 95% 时，连续十次约 59.9%。如果任务有 100 个步骤，每步 99% 正确，全部做对约 36.6%；每步 99.9%，约 90.5%。这些计算简化了步骤之间的相关性，但足以说明长流程会放大偶发错误。
| 单次成功率 | 连续 3 次全对 | 连续 10 次全对 |
|---|---|---|
| 90% | 72.9% | 34.9% |
| 95% | 85.7% | 59.9% |
| 99% | 97.0% | 90.4% |
支付、删除、对外发送这类不容易回滚的任务，pass@k 的高分参考价值有限，更应看 pass@1 或 pass^k，并单独统计人工接管和严重错误。
公开 benchmark 的高分能说明什么
公开 benchmark 的价值在于提供统一任务、统一评分和可复现的比较。它适合观察能力趋势，不能直接推到企业生产环境。任务分布、权限和工具环境不同，公开题目还可能进入训练数据，评分器也覆盖不到业务副作用。
GAIA：人和模型的差距
GAIA 由 Meta、Hugging Face 等团队在 2023 年 11 月发布，包含 466 个需要推理、多模态处理、网页浏览和工具使用的问题，答案短且可验证。论文报告人类回答者的成功率为 92%，带插件的早期 GPT-4 为 15%。这个差距说明，题目对人类简单，对当时的 AI 仍然很难。
引用这组数字时要注意时间和版本。它是 2023 年的评测结果，不能用来给 2026 年的模型排名。GAIA 的题目也偏短、偏可验证，和企业在权限、审批、异常处理上的长流程不是一回事。
METR：50% 时间跨度是一个边界
METR 用人类专家完成任务所需的时间来衡量任务长度，再拟合模型成功率随任务长度变化的曲线，报告成功率为 50% 的时间点。假设某模型的 50% 时间跨度是 4 小时，含义是在人类专家大约需要 4 小时的任务上，它的成功概率约为 50%。这不等于所有 4 小时以内的任务都能稳定交付。
METR 在 2026 年 1 月的说明里提醒，50% 时间跨度的置信区间可能很宽，20% 和 80% 时间跨度也提供了不同成功率下的参考，但它们与 50% 时间跨度并非完全独立的估计。企业如果要求连续多次成功，应该看更高成功率对应的时间跨度，或者直接看 pass^k。
看到一个成功率，先核对六个问题
不论数字来自厂商、公开榜单还是内部测试，都可以用下面六个问题做一次快速核验。
| 要问的问题 | 为什么重要 | 可接受的信号 |
|---|---|---|
| 测了哪些任务 | 任务分布决定难度 | 覆盖高频、困难、异常和高风险场景，并分场景报告 |
| 成功标准是什么 | 标准宽窄直接改变分子 | 必选条件写清楚，部分完成和失败单列 |
| 样本有多大 | 10 个任务里的 9 个成功，和 1000 个任务里的 900 个成功，证据强度不同 | 报告样本量、置信区间和评测时间 |
| 第一次就成功吗 | 重试会抬高表面成功率 | 区分 pass@1、重试后成功和人工接管 |
| 失败怎么分类 | 总数不能指导修复 | 按模型、上下文、工具、权限、环境等维度拆分 |
| 成本是多少 | 成功任务也可能不划算 | 报告每个成功任务的模型、工具、人工和返工成本 |
这六个问题答不上来，这个成功率更适合当作宣传口径，不适合直接作为采购或上线依据。
企业怎么把任务成功率用起来
任务成功率要服务于业务判断，先确定用它回答什么问题：能不能上线、哪个环节最影响体验、改完有没有变好。围绕这三个问题，落地顺序可以这样安排。
先选可验证的任务
在 Agent 落地路线图里，第一步通常是选任务。优先选择高频、人工成本高、数字化程度高、结果可验证、错误可撤销的任务。五个条件占得越多，越容易做出可信的评估。支付、删除、对外承诺等高风险任务可以纳入试点，但要先设置权限、审批和人工复核，不能只用成功率一个指标决定是否放开。
把验收条件写成检查项
把业务目标拆成可检查的条件，例如最终状态、必填字段、数据来源、计算公式、格式、权限、禁止的副作用和安全门禁。每条条件写明通过和失败的判定，尽量用规则、数据库状态、测试和业务回执来验证。开放内容再交给 LLM 评审，并用人工样本校准。
用运行数据定位失败
只看总成功率，很难知道下一步改什么。需要把任务、会话、模型、工具、Skill 和用户反馈放在同一条链路上，记录每次调用的状态、耗时、Token 和失败原因。常见做法是先看失败率最高的任务类型，再下钻到单次执行，判断问题出在意图理解、上下文缺失、工具参数、权限还是结果校验。
这也是 ThinkingAI 在企业级 Agent 平台里强调 运行监控 和持续优化的原因。一次任务完成只是起点，团队还要判断运行质量、资源投入和用户反馈之间的关系。
运行数据要和业务结果放在一起看，才能判断一次失败是体验问题还是成本问题。完成一次调整后，用相同口径重跑同一批任务，比较任务成功率、首次成功率、人工接管率、延迟和每个成功任务成本。A/B 实验适合比较模型、工具、Skill 或交互策略的变化，但前提是任务集和验收标准保持不变。
这些比较要建立在同一批任务和同一套验收标准上，否则改动的效果无法归因。ThinkingAI 将用户与 Agent 行为分析、智能运营与 A/B 实验、Agent 观测平台放在同一套数据基础上，让团队用相同口径比较不同模型、Tool、Skill 或交互策略带来的变化，判断任务完成率、用户体验和资源消耗是否改善。目前 ThinkingAI 已服务全球超 1500 家企业，接入产品超 8000 款。
常见问题
任务成功率和任务完成率有什么区别？
任务完成率看流程是否结束，任务成功率看结果是否达到验收标准。系统日志里的完成状态不能替代业务验收。对外比较时，先确认对方用的是哪一个口径。
任务成功率多少算合格？
没有通用阈值。内部草稿、客服建议、支付、删除等场景的风险不同，合格线也不同。高风险、不可逆的任务需要更高的首次成功率和更严格的人工复核；低风险、可撤销的任务可以把部分完成单独统计，再看人工接管成本。
只测几十个任务，90% 可信吗？
样本越小，估计越不稳定。10 个任务成功 9 个，和 1000 个任务成功 900 个，都写作 90%，可信程度差别很大。至少报告样本量、任务分布和置信区间，并按任务类型拆分。任务多样性比单纯增加重复次数更重要。
pass@k 和 pass^k 有什么区别？
pass@k 表示同一任务跑 k 次，至少成功一次就算通过，衡量能力上限。pass^k 表示 k 次全部成功才算通过，衡量连续运行的稳定性。前者适合探索能力边界，后者更接近支付、删除、对外发送等不能重试的场景。
提升任务成功率，应该先换模型吗？
通常先检查上下文、工具和验收环节。数据口径不统一、工具参数错误、权限不足、缺少结果校验，都会让成功率停在低位，换模型未必能解决。把失败按环节分类，优先修复出现频率最高、影响最大的问题，再用同一批任务验证改动效果。
参考资料
- Atlan. Measuring AI Agent Task Success Rate Without Fooling Yourself. 2026-08-04. https://atlan.com/know/ai-agent/ai-agent-task-success-rate/
- Mialon, G. et al. GAIA: a benchmark for General AI Assistants. arXiv:2311.12983, 2023-11-21. https://arxiv.org/abs/2311.12983
- METR. Clarifying limitations of time horizon. 2026-01-22. https://metr.org/notes/2026-01-22-time-horizon-limitations/
