我一直觉得，“AI代理能不能把事办成”这句话听起来特别朴素，可它在实际项目里几乎是最难回答的问题。过去两年我跟不少团队聊过，大家演示时都很惊艳，真到了上线，问题就冒出来了：同一个任务，今天跑三遍成功两遍，明天跑三遍成功零遍。你说它行还是不行，谁也给不出一个让人信服的数。
这也是我决定认真做一轮AI代理任务完成率对比的起因。我想要一个能落到纸面上的口径，而不是靠演示视频和口头评价来判断一个Agent到底靠不靠谱。这一章我想先把地基打牢，讲清楚任务完成率到底在量什么、评测基准怎么搭、这种对比研究为什么值得做，还有哪些坑是大家反复踩的。
1.1 AI代理任务完成率的定义与度量边界
我自己的理解是，AI代理任务完成率就是在给定的一批任务里，代理在允许的条件下达成预定目标的比例。它的分子是“被判定为完成的任务数”，分母是“参与评测的任务总数”。这个定义看着简单，真正难的是“完成”这两个字怎么判定。是任务目标全部达成算完成，还是关键结果达到就算完成，不同团队的理解能差出十几个百分点。
度量边界这块我想多说两句。代理完成任务的过程涉及工具调用、网页操作、文件读写、多步规划，评测时得明确哪些环节算在任务范围内，哪些算外部环境故障。比如网络超时导致的操作失败，算不算代理的失败？我的做法通常是单独记录、单独归类，不混进主指标里。不把边界划清楚，最后的对比数字基本没法看。
还有一个容易被忽略的点：完成率是一个带条件的指标。它在“某个模型、某套工具、某种提示词、某个时间点”下才成立。脱离这些条件谈完成率，跟不谈油耗谈续航里程差不多，听着挺唬人，实际参考价值有限。
1.2 对比评测基准的构成要素与选择原则
我搭基准的时候会先问自己三件事：任务从哪来、成功怎么判、环境怎么固定。任务来源要贴近真实使用场景，不能全是教科书式的干净输入。判定规则要么写成可执行的检查脚本，要么给出明确的验收清单，尽量少留人工主观判断的空间。环境这边，模型版本、工具接口、系统提示词、超时阈值都得锁死，不然跑出来的数没法定量比较。
选择原则上我偏向“覆盖要够、颗粒度要细、难度要分层”。覆盖够是指任务类型别太单一，办公自动化、信息检索、代码生成、多步流程都得有。颗粒度细是指评测别只给一个总分，子任务级别的通过情况也要留痕。难度分层是为了看清楚代理的能力拐点在哪，简单任务全过、复杂任务全崩，这种分布比一个平均值有用得多。
任务集的数量我也踩过坑。一开始觉得几十条就够了，跑下来发现方差大得吓人，同一配置不同批次的结果能差好几个点。后来我把任务量加上去，同时固定随机种子，结果才稳下来。基准这东西不是搭完就完事，它本身也需要被验证。
1.3 不同AI Agent任务完成率实测对比的研究价值
做这种横向对比，最直接的收益是给选型提供依据。市面上的代理产品各有各的宣传口径，A家说自己任务完成率九成，B家说自己端到端能力领先，真放到同一套任务上跑，差距可能跟宣传完全不是一回事。我见过一个案例，某代理在演示场景表现亮眼，换到需要连续调用五六个工具的任务上，完成率直接掉到三成以下。
研究价值还体现在问题定位上。单看一个总分，你只知道它行或者不行；做了对比，你能看到它是在哪一类任务上掉链子，是规划能力不足，还是工具调用出错，还是长链路里记忆丢失。这些信息对后续优化特别关键，能帮团队把精力放到真正的瓶颈上。
对行业来说，一套公开、可复现的对比方法也有助于把讨论拉回地面。现在关于AI代理的讨论太多停留在个案体验，缺少系统性的实测数据。多一些人做扎实的对比，整个领域的判断标准才会慢慢清晰起来。
1.4 常见评测误区与结果解读注意事项
我梳理下来，最常见的误区是拿单一指标当结论。完成率只是一个维度，它不告诉你成本、不告诉你时延、也不告诉你失败时的表现。一个代理完成率七成但每次失败都能干净退出，另一个完成率七成五但失败时留下一堆脏数据，这两个在工程上的价值完全不一样。看结果的时候得把成本、时延、稳定性一起摆上来。
第二个误区是测试集与真实场景脱节。有些评测用的任务过于理想化，输入格式规整、步骤固定、没有干扰信息，代理跑出来的分数很漂亮。上线之后用户输入随意、页面结构经常变、工具偶尔抽风，完成率立刻打回原形。我在设计任务时会刻意加一些噪声和边界情况，就是为了让数字更接近真实。
第三个要留意的是统计口径的稳定性。同一套配置跑多次，结果本身就有波动，差个三五个点很正常。如果两个代理的差距在这个波动范围之内，就别急着下“谁更强”的结论。我一般会跑多轮取分布，看中位数和波动区间，而不是只盯着某一次的结果说事。解读对比数据时保持这种克制，结论才站得住。
聊完口径的事，这一章我想把“怎么比”讲透。说实话，设计一套对比实验比我想的要琐碎得多，光是对比对象选谁、场景怎么切，就跟团队来回拉扯了好几轮。我的目标很明确：让跑出来的数字经得起别人复现，也经得起自己过两个月回头看。
2.1 对比对象与任务场景划分
这次我选进来的代理覆盖了三类：一类是绑定了特定生态的通用型Agent，一类是主打浏览器操作的网页代理，还有一类是偏代码和工具调用的工程型代理。选它们的原因不复杂，都是目前实际项目里被问得最多的选项。我没有把那些只在Demo里出现、拿不到稳定接口的产品放进来，跑不起来的东西放进对比表里，对读者没有意义。
任务场景我按真实工作流切成了四块：办公文档处理、网页信息采集与操作、代码生成与调试、多步业务链路。每一块下面再按复杂度分简单、中等、困难三档。这么切是因为我发现同一款代理在不同场景下的表现差异极大，有的一碰网页就露怯，有的代码任务稳得离谱，混在一起算个总分，反而把有价值的信息抹掉了。
场景划分还有个细节我抠得比较细，就是任务之间的独立性。早期测试里我让多个任务共用同一个会话上下文，结果后一个任务的成败受前一个任务残留状态的影响，数据脏得没法用。后来改成每个任务独立开环境、独立起会话，虽然跑起来慢一些，但结果干净多了。
2.2 AI代理任务完成率对比评测基准与测试集设计
测试集的搭建我花了差不多三周。任务来源一部分是从真实项目日志里脱敏出来的，一部分是我按场景手工构造的。手工构造的那部分我特意加了干扰项，比如网页里混入无关广告位、文档里夹着格式错乱的表格、需求描述里留一点模糊空间。太干净的任务测不出代理的真实水平，这一点我在第一章就提过，这里算是把它落实到了具体设计上。
每条任务我都配了验收规则。能脚本化检查的坚决脚本化，比如文件是否生成、字段是否填对、代码能否跑通、页面是否跳转到目标地址。没法完全脚本化的，我列了人工验收清单，把判定标准写到“什么算过、什么算不过”不至于吵架的程度。验收规则和任务本身一起版本化管理，改一条任务就留一次记录，方便后面追溯。
测试集的规模最后定在一百六十条左右，四个场景大致均分，难度上简单占三成、中等四成、困难三成。这个配比不是拍脑袋定的，是我按业务里实际遇到的任务分布做的近似。数量上我也做过扩充实验，加到两百多条后方差改善已经不明显，就没继续堆。测试集本身也要控制维护成本，不然跑一次评测光准备环境就得一天。
2.3 实测流程、评分规则与可复现实验设置
实测流程我定成了固定五步：环境初始化、任务下发、代理执行、结果采集、判定打分。每一步都有检查点，环境初始化失败直接中止并标记，任务下发时记录完整提示词，执行过程录屏加日志双留存。录屏这个事一开始我觉得麻烦，后来排查失败原因时发现它太有用了，代理到底卡在哪一步，看一遍回放比翻日志快得多。
评分规则我采用的是分层判定。任务整体达成目标记端到端成功；目标没完全达成但关键路径走通、只差收尾的，记部分成功；子任务层面单独记录每一步的完成情况。评分由脚本先跑一遍，脚本判不了的交人工复核，复核人不知道具体是哪款代理在跑，减少主观偏差。这套规则写下来有十几页，但真正跑起来之后争议少了很多。
可复现这块我下了硬功夫。模型版本、温度参数、系统提示词、工具接口版本、超时阈值、重试次数全部写进配置文件，跟测试集一起锁版本。每轮评测记录运行时间戳和随机种子。有朋友问我为什么搞得这么重，我的回答很简单：别人拿着我的配置能跑出接近的结果，这个对比才有讨论的基础，否则就只是一家之言。
2.4 端到端完成率、子任务完成率与部分成功率的联合呈现
只报一个端到端完成率，我觉得是不够的。端到端成功回答的是“事情办成没有”，子任务完成率回答的是“办到了哪一步”，部分成功率回答的是“差一点算不算数”。这三个指标摆在一起，才能看出代理的能力轮廓。有的代理端到端数字一般，但子任务完成率很高，说明它方向对、收尾弱，这类问题往往靠工程手段就能补。
呈现方式上我用的是分层表格加分布图。表格里每个场景一行，三列指标并排，后面附上样本量和波动区间。分布图看的是同一配置多轮运行的结果离散程度。我特别在意波动区间这一列，两个代理端到端完成率差三个点，但波动区间大幅重叠，这种差距我不会写成“领先”，只会如实标注“在误差范围内”。
部分成功率的判定最容易引起分歧，我的处理办法是把部分成功的定义写死：关键子任务完成数达到总数的某个比例、且没有产生不可恢复的错误，才算部分成功。定义写死之后，不同批次、不同代理之间的数才有可比性。这一块我在报告里会专门加一段说明，避免读者拿不同口径的数字直接对比。
跑完这一轮实测，我手头的数据量比预想的大不少。一百六十条任务、四类场景、多款代理反复跑，光是整理结果表格就花了我两天。这一章我想把结果摊开来讲，哪些代理在什么场景下能打、哪些场景集体翻车，还有那些数字背后真正起作用的因素。
3.1 办公自动化与网页操作类任务完成率对比
办公文档处理这块，整体表现是四类场景里最稳的。我实测下来，主流代理在简单任务上的端到端完成率普遍能到八成五以上，中等难度掉到七成左右，困难任务就明显分化了，好的能守住六成，差的直接跌破四成。文档问答、表格填写、模板套用这类任务，代理们踩的坑都差不多，格式错乱和字段越界是最常见的失败原因。有一款代理在处理带合并单元格的复杂表格时连错三张表，看回放发现它是把表格当成纯文本在理解，结构信息完全丢了。
网页操作类任务的完成率曲线就难看得多。简单页面跳转和信息抓取还能看，端到端成功率六成出头；一到需要多页面跳转、表单交互、验证码绕不过去的任务，完成率断崖式下跌，困难档平均只有两成八。我印象很深的一条任务是在电商网站下单，五款代理里只有两款完整走完流程，其余三款分别卡在登录态识别、弹窗关闭、地址选择这三个环节。有一款在购物车页面反复刷新了七次，日志里全是重试，最后超时退出。这件事让我意识到，网页代理的瓶颈往往不在模型本身，而在页面状态的理解和恢复能力。
这两类场景放在一起看，差距很清楚：办公场景的输入相对封闭、结构相对稳定，代理发挥空间大；网页场景的输入开放、动态变化多，任何一个小意外都可能让整条链路断掉。我跟团队讨论过这个反差，大家的共识是，网页代理要真正可用，光靠模型升级不够，还得在页面解析和交互容错上下功夫。
3.2 代码生成与工具调用类任务完成率对比
代码生成任务的结果分化得最厉害。简单的函数补全和单文件脚本，几款主力代理的端到端完成率都在九成上下，子任务完成率更接近满分。一到多文件协作、依赖管理、调试修错这类中等和困难任务，数字就开始打架了。表现最好的一款在困难档还能维持六成五左右的端到端完成率，最差的一款直接掉到三成以下，而且失败原因高度集中：依赖装不上、报错信息看不懂、改一处崩三处。
工具调用这块，我的观察是完成率跟工具生态的成熟度强相关。调用搜索、计算、文件读写这类标准工具时，代理的端到端成功率普遍在七成五以上，多步工具链的衔接也比较顺。换成调用企业内部API或者第三方SaaS接口，完成率立刻降一档，困难任务能掉到四成左右。有一条任务要求代理调用库存查询接口再做汇总，结果三款代理在参数格式上反复试错，其中一款把接口文档里的示例参数直接抄进请求，字段名全对、值全错，跑出来的结果看着像样但根本不能用。
我还专门测了工具调用失败后的恢复能力。好的代理在工具报错后能读懂错误码、调整参数重试，两三次内解决问题；差的代理要么死循环重试同一个错误请求，要么干脆放弃转去胡说。这个差异在最终完成率上体现得很明显，但在只看成功率的报表里容易被忽略。工具生态这块，我后面还会展开讲，它可能比模型参数更能解释完成率的差距。
3.3 多步推理与长链路任务完成率对比
多步推理是我最看重的场景，也是最让人清醒的场景。我把任务按步骤数分组统计，三步以内的链路，代理端到端完成率还能维持在六成到七成；五步左右掉到四成五；超过八步的长链路，最差的一款完成率只剩一成出头，最好的也没能突破四成。这条随步骤数递减的曲线，几乎在所有代理身上都能看到，区别只在于斜率陡不陡。
长链路上掉得最狠的环节是状态保持。有一条任务是跨系统处理报销：查单据、核标准、填系统、发通知，四五个环节串起来，中间任何一个环节的信息丢失都会导致后面全错。实测里有款代理在第三步把前面查到的金额记错了，后面三步全按错的数走，最后系统里生成了一张对不上的单据。看日志时候我发现，它在第三步的上下文里只留了金额的模糊描述，精确数字被挤掉了。这类“记忆漂移”的问题，在多步任务里出现的频率相当高。
规划能力的影响也很直接。困难任务里，有的代理会先把任务拆成子目标再逐个执行，虽然慢一些，但关键路径走得稳；有的代理拿到任务就开始动手，走到一半发现方向错了再回头，来回折腾几轮就超时了。我做过一个粗略统计，有显式规划步骤的代理在长链路任务上的端到端完成率平均高出十五个百分点左右。这个差距比我预想的大，也让我调整了后面优化策略的优先级。
3.4 模型能力、工具生态、记忆规划与成本时延对完成率的影响
模型能力这块，我不太想简单说“模型越强完成率越高”。从数据看，同等参数规模下，不同代理的完成率能差出二十多个点，说明模型之外的工程因素权重很大。当然，模型的基础能力还是有底线的，理解指令、生成结构化输出、读懂错误信息这些基本功不过关，后面再怎么优化也补不上。我测过的几款小模型代理，在简单任务上还能靠工程手段追平，一到复杂的多步任务就原形毕露了。
工具生态的影响我在上一节提过，这里想再补一句。工具接口的文档质量、错误码设计、幂等性，这些看起来是工程细节，实测中对完成率的影响非常实在。调用一个文档齐全、错误信息明确的接口，代理的首次调用成功率能到八成以上；换成一个错误信息只有“请求失败”四个字的接口，代理就开始瞎猜，试错次数翻倍，完成率自然往下走。这个因素在选型时最容易被低估。
记忆和规划我放在一起说。记忆解决的是“别忘了”，规划解决的是“别走错”。实测里这两项能力强的代理，长链路任务的完成率优势很明显，部分成功率也高，说明它们即使没全办成，也把关键步骤推进到位了。这部分能力很多是靠prompt和架构设计实现的，模型本身的差距倒是其次。
成本时延这块，我算过一笔粗略的账。同一批任务，完成率最高的代理平均耗时是最低的一款的两倍多，单任务成本将近三倍。但把部分成功和人工接管成本算进去，高完成率代理的综合成本未必更贵。我拿办公场景的数据做了个粗估，端到端完成率每提高十个点，人工返工时间大概能减少三成。这个账因业务而异，不能一刀切，但只看单次调用价格去选代理，很容易掉坑里。
3.5 基准偏差、评估口径与稳定性对对比结论的影响
说到偏差，我得坦白一件事。第一轮跑完的时候，我发现某款代理在网页任务上的成绩好得反常，排查后确认是测试集里有两个任务的验收规则写得偏松，代理只要页面跳转到目标地址就算过，实际上数据根本没抓全。修正规则重跑之后，这款代理的完成率掉了十一个百分点。这件事让我对所有“看起来特别漂亮”的数字都多留了个心眼。
稳定性方面，我做了多轮重复运行。同一款代理、同一套配置，端到端完成率的轮间波动普遍在三到五个点之间，困难任务的波动更大，有款代理在不同轮次之间能差出十二个点。这意味着两款代理如果完成率只差两三个点，基本没法得出谁更强的结论。我在报告里统一加了波动区间，差距落在区间重叠范围内的，一律标注“差异不显著”。有的朋友觉得我太保守，我觉得这是对自己数据负责。
评估口径的影响也不小。端到端完成率、子任务完成率、部分成功率三个指标，不同代理的排序并不完全一致。有一款代理端到端排名靠后，但部分成功率排到中上，说明它能把事情推进大半，只差最后一口气。只看端到端数字就把它淘汰，可能会错过一个通过工程改造就能用的选项。这一块我在第4章的选型建议里还会再聊，怎么把三个指标组合起来看，比单看一个数字有用得多。
前三章把评测口径、实测设计和结果影响因素都摊开讲完了。这一章我想换个角度，不再纠结哪个代理分数高，而是聊聊怎么把这些数字用起来。说实话，跑完那么多轮测试之后，我最大的感受是：完成率排行榜只能当参考，真正决定选型的，是业务场景和工程投入的匹配度。
4.1 按业务场景解读AI代理任务完成率对比结果
我见过太多团队拿着第三方榜单就直接下单，结果用了一个月在真实业务里翻车。问题出在哪？榜单测的是通用任务，你的业务有自己的脏数据、自己的边缘场景、自己的验收标准。我的建议是先把自己业务里的任务按“流程封闭程度”和“失败代价”两个维度切一刀。办公文档、报表生成这类封闭流程，端到端完成率八成五以上的代理基本够用，剩下的差距靠流程约束和人工复核就能补上。网页操作、外部系统对接这类开放流程，我实测下来完成率普遍低得多，选型时得把心理预期调低两档，同时把容错和重试机制做厚。
还有一类场景容易被忽略，就是长链路任务。上一章数据里五步以上的任务完成率掉得厉害，如果你的业务天然涉及跨系统、多环节，那选型时真得把规划和记忆能力当成硬指标看，不能只看简单任务的漂亮数字。我自己踩过的坑是拿单步任务成绩选了一个代理，上线后跑多步流程，第三周就出了状态丢失的事故。
具体到指标怎么组合，我的经验是：端到端完成率决定“能不能用”，部分成功率决定“值不值得优化”，子任务完成率决定“卡在哪一环”。三款代理端到端差距在五个点以内，基本可以判为同一档，这时候看部分成功率，谁把关键步骤推进得更到位，谁就更值得留。差距超过十五个点，端到端数字的参考价值就很大了，但也别急着淘汰落后的那款，先看它是不是被某个单点瓶颈拖累了，很多时候换掉一个工具接口或加一层校验，完成率能往上跳一截。
4.2 提升AI Agent任务完成率的工程化策略
完成率这事儿，模型定上限，工程定下限。我复盘了失败案例，发现超过一半的问题不是模型“不会”，而是工程环节没兜住。最见效的一招是把大任务拆成带校验点的子任务。上一章提到有显式规划的代理完成率高出十五个点，这个优势在工程侧同样成立。我在几个项目里试过给代理加一道“执行前确认”的步骤，让它先把任务拆解和关键参数列出来，人看一眼再放行，长链路的完成率提升相当明显，代价只是多了一次交互。
重试策略也得讲究。我看过太多代理在工具报错后原地重试同一个请求，白白烧钱。工程上给重试加两个约束就够了：一是错误分类，参数类错误换参数重试，网络类错误退避后重试，逻辑类错误直接上报；二是重试次数封顶，超过三次转人工。别小看这一条，实测中能把无效重试砍掉七成以上。再配上幂等性设计，重试就不会搞出重复下单、重复发邮件这种事故。
工具封装这块，我的建议是别让代理直接调裸接口。中间加一层适配层，把参数校验、错误码翻译、结果裁剪都做掉，代理拿到的就是干净的结构化输入输出。我在一个内部系统对接项目里做过对比，加适配层之后，工具调用的首次成功率从五成多提到八成，代理的试错次数直接减半。还有记忆管理，长任务里让代理定期把关键状态落盘，别全靠上下文窗口硬撑，这一条对多步任务的稳定性帮助很大。
人工兜底的设计也得提前想好。完成率再高的代理也有翻车的时候，关键是要让失败可感知、可接管。我给几个流程加了“部分成功标记”，代理没做完的任务带着进度和上下文转给人工，接手的人不用从头查起。这个设计让返工时间平均缩短了四成左右，比一味追求完成率提升划算得多。
4.3 企业级对比评测基准建设与持续监测机制
买代理不是一锤子买卖，评测也不该是一次性动作。我在几家团队里推的做法是：建一套企业私有的评测集，规模不用大，五十到一百条任务就够，但必须覆盖自己业务里最高频和最高风险的场景。这套评测集要跟业务一起迭代，新出现的边缘场景及时补进去，过时的任务定期下掉。我见过有团队拿两年前的测试集选型，结果代理在旧任务上表现很好，新业务一上就露馅。
持续监测这块，我的建议是把完成率当成一个线上指标来盯，别只在采购前测一轮。具体做法不复杂：给代理的每次执行打上场景标签和结果标签，每周出一份按场景切分的完成率报表，波动超过阈值就触发排查。上一章说过轮间波动三到五个点是常态，所以阈值别设太紧，我一般设八个点，低于这个数不折腾。报表里我还习惯加一列“人工接管率”，这个指标比单纯的完成率更能反映真实体验。
评测标准本身也得有人管。我们内部定了个规矩，验收规则每季度由业务方和工程方一起过一遍，防止出现我上一章提到的“规则偏松导致虚高”的问题。评测脚本和测试数据都在版本库里管着，谁改了、为什么改，都有记录。这套机制跑了大半年，最大的收获不是数字更准了，而是团队对“什么算完成”有了共识，选型讨论时扯皮少了很多。
4.4 多代理协作、可验证执行与评测标准的发展趋势
多代理协作这个概念现在很热，我实测过几个编排框架，感受是方向对，但别急着上生产。多个代理分工确实能提升复杂任务的完成率，我测过一个三角色编排的流程，长链路任务完成率比单代理高出十几个点。代价是成本和时延都上去了，链路越长，代理之间的信息传递损耗越明显。我的判断是，多代理适合那种单代理明确搞不定的超长任务，普通业务场景用单代理加工具链就够了，别为了架构好看硬拆。
可验证执行这块，我觉得是接下来一两年最值得关注的方向。代理做完事之后能自己验证结果对不对，比如生成代码后跑一遍测试、填完表单后回读核对，这种能力对完成率的提升是质变级的。我测过带自校验环节的代理，端到端完成率能往上拉八到十个点，因为它能在最后一步把很多“看起来成功实则错误”的结果拦下来。这个方向对工程侧的要求是接口要提供可回读、可校验的能力，选型时可以把这一条加进考察清单。
评测标准本身也在变。现在各家榜单口径不一，跨榜单对比基本没法做，我预计未来会往两个方向走：一是场景化细分，不再搞大而全的综合分，而是按办公、代码、网页等场景分开排名；二是动态基准，测试集定期更新，防止代理在固定题集上过拟合。这些变化对使用方是好事，意味着选型依据会更贴近真实。我的建议是保持关注，但别等标准完美了再动手，先用私有评测集把自己的判断体系建起来，外部标准当参考，别当答案。
回头看这四章，从评测口径到实测结果再到选型优化，我想说的核心就一句：AI代理的完成率不是一个孤立的数字，它跟场景、工程投入、验收标准绑在一起。把这三者理清楚，选型就不会太偏，用得也会更踏实。
