Claude不到4%，全军覆没，一场大考撕碎Agent「全自动办公」幻想

【导读】许多实习生能轻松完成的任务有时对于AI来说却是一场严酷大考。人类距离真正可用的Agent还有多远一份全新SaaS-Bench实战考卷已经给出了答案。Computer-Use Agent的「奇点」没有来现实的冷水先泼下来了。过去一年各家GUI Agent争先恐后地宣称能替人类干活。Benchmark成绩一路飙升投资人兴奋媒体狂欢「全自动办公」似乎就在眼前。但UniPat AI刚刚用一组数据证明这一切都建立在沙子上Leaderboard23个真系统106个任务一场残酷的实战考试现有的Agent评测说白了就是仿真环境、简单任务、最多几十步搞定。跟真实工作完全是两回事。真实办公长什么样一个医疗管理员写完SOAP病历→填病例上报→生成正式文档。一个财务收到报销申请→审批→打款→记账。跨好几个系统步骤动辄几百步。SaaS-Bench的思路很暴力直接把真系统搬进Docker让Agent在真实的前后端逻辑、数据库状态和业务约束中干活。SaaS-Bench任务——真实工作场景任务SaaS-Bench精心挑选了23个开源SaaSSoftware-as-a-Service系统全部通过Docker本地部署保留了完整的前后端逻辑、数据库状态和业务约束。覆盖六个专业领域软件研发OpenProject、Baserow、Code-Server、Metabase业务财务Twenty CRM、BigCapital、HRMS、Pretix医疗管理OpenEMR、OpnForm、OnlyOffice团队协作SiYuan、Roundcube、Mattermost、ownCloud农业供应链FarmOS、Grocy、Recipya、E-Label独立媒体PhotoPrism、MediaCMS、BookLore、Watcharr更重要的是这些系统不是「空壳网页」每个软件里都填充了真实业务的数据包括用户、项目、订单、文件等实体记录。Agent进入的不是一个空白的测试页面而是一个有历史数据、有干扰项、有跨系统关联的真实工作环境。任务模态、领域、app三层分布106个任务中93.4%跨越至少两个应用三应用任务占了一半53个。纯文本任务74个涉及多模态理解的32个。以Claude Opus 4.6的执行轨迹估算97.3%的文本任务操作步数超过100步最长轨迹达300步。任务难度分析 ——大多数任务是 Cross-App Long-Horizon 的这些任务是怎么来的如何评估Agent的操作能力SaaS-Bench 采用「LLM生成 专家把关」的方式完成任务构建先由LLM围绕六大专业领域和具体职业角色生成任务明确任务目标、跨应用依赖和验证要求并通过多轮修改减少歧义和漏洞。随后专家会对任务进行人工筛选和真实执行检查重点判断任务是否专业、自然、可完成、可验证。对于堆砌步骤、逻辑混乱或验证不准的任务会被修改或剔除最终确保每个任务都能真实运行并能被验证器准确评估。任务构建流程图——四个阶段保证任务质量SaaS-Bench允许Agent使用Browser-Use在SaaS环境中操作计算机并给出了两个指标Resolved Score完全通过分数严苛全部检查点通过才算1否则为0Checkpoint Score检查点分数宽松按权重计算部分检查点完成比例Agent → Browser-Use → 执行 → 验证 → 打分总览图后面的结果会表明——这两个数字之间的巨大落差恰好暴露了Agent最核心的问题。榜单出炉全军覆没来看这组数字 ——主要结果DeepSeek V4 、M2.7和GLM5.1为单模态模型仅测评Text-OnlyDomain最强的Claude Opus 4.7检查点分数43.9%端到端完全通过分数只有3.8%——106个任务只完整通过了4个。Kimi K2.5和Gemini 3.1 Pro完全通过分数为零。一个任务都没走完。这组数字的含义极其残酷Agent可以推进工作的部分中间环节但几乎没有能力将一个完整的长程工作流走完。多跑几次能救吗四个模型的Passk结果把每个模型在同一任务上独立跑3次对一次就算通过。pass3相比pass1整体提升约8个百分点。Sonnet 4.6在多模态任务上从33.9%跳到52.1%18.2pp——它并非完全不行而是执行极不稳定。这不是环境随机性。每次运行的初始状态完全相同。这是路径依赖——模型在某个决策点的微小差异导致后续轨迹完全分叉。多跑几次有帮助但远不是解决方案。越复杂分越低三个结构维度全部单调递减分数 vs 应用数 / 分数 vs 步长 / 分数 vs 检查点个数跨应用数1→4平均分从53%降至20%操作步长增加任务轨迹越长得分显著越低检查点个数≤6 vs ≥18平均分从65%降至27%「跨应用轨迹长细粒度验证」的任务得分最低——这恰恰是真实工作流最常见的形态。四种结构性失败Agent到底在哪翻车SaaS-Bench真正的价值不在于分数本身而在于暴露了Agent在真实环境中的四种致命缺陷。失败1任务越长越做不对即使每个检查点通过率高达95%12个检查点的全部通过概率也只有54%。而SaaS-Bench的平均检查点数远超12。所有模型都呈现同一个模式通过率随任务推进呈下降趋势没有一个模型能在后半段维持住前期表现。模型随着任务执行做对的越来越少这是一条不可逆的下降曲线。越往后走越不可能走完。失败2一步错步步错一个典型案例任务要求创建一个公司客户「Arcturus Digital」。Agent同时填了联系人姓名和公司名触发了个人客户逻辑实际创建的是个人客户Elena Vasquez。此后的10张发票、付款记录、账户对账全部挂在错误实体下。核心检查点权重仅3%但导致了下游30%的权重损失。上游任务导致下游失败链示意图一个3%的错误节点造成30%的分数损失。失败3做完不检查自以为对了Claude Opus 4.6在Step 124识别出日期错误2026-03-19 vs. 2026-03-20执行了修改但没有回到页面复查直接推进后续子任务。Step 210提交时汇报写的是「账单日期2026-03-20已修复」——页面上实际日期仍是03-19。Agent 在意图层面认为成功Verifier 在状态层面发现失败Agent在意图层面认为成功验证器在状态层面发现失败。两者之间的断层是系统性的。当前CUA框架缺少「严谨的反思闭环」 —— Agent是个不会检查自己作业的学生。失败4同一张考卷成绩忽高忽低Claude Sonnet 4.6在同一任务的三次独立运行中分数范围从 0.00 到 0.68。这不是环境随机性造成的 —— 每次运行的初始状态完全相同 —— 而是路径依赖模型在某个决策点的微小差异会导致后续执行轨迹完全分叉这让Agent在长程任务中的执行变成了赌博。Claude Sonnet 4.6在同一任务的三次运行这意味着什么SaaS-Bench撕碎了一个幻觉Agent的Benchmark成绩和真实工作能力之间存在巨大的鸿沟。四种结构性失败模式——越往后越做不对、一步错步步错、做完不检查、次次分数不一样——指向同一个底层事实当前Agent缺少对持久状态的有效推理能力缺少操作后的闭环验证机制缺少从错误中恢复的能力。这些不是靠模型变大、或者加几个工程模块就能解决的问题。它们指向的是当前Agent范式更深层的局限在长程任务中模型缺少对全局状态的持续感知无法像人一样「心里有数」。这不只是技术债而是当前范式的天花板。Computer-Use Agent想要真正替人干活路还很远。SaaS-Bench把地图摊开了——接下来就看各家怎么走了。但这也引向了一个正在逐渐形成的共识今天的SaaS是给人设计的——菜单、按钮、表单都在服务人类的眼睛和手指。但当Agent成为主要用户这些界面就变成了累赘。未来不是让Agent学会操作人类的软件而是软件本身要为Agent重新设计。SaaS-Bench揭示的不只是Agent的短板也是当前软件形态的保质期——面向人类的SaaS可能都要为Agent重做一遍。原文链接Claude不到4%全军覆没一场大考撕碎Agent「全自动办公」幻想-36氪