Claude 通过率不到 4%，SaaS-Bench 撕碎了 Computer-Use 的「全自动办公」幻想

想象一个真实的工作日：项目经理要更新项目状态，财务人员要整理客户账单，医疗管理员要核对预约和保险信息。

这些并不是高级专家任务，很多时候，一个认真一点的实习生照着流程也能完成。

但对今天的 AI Agent 来说，这些 “日常工作” 却远没有看起来那么简单。

它需要理解业务目标、跨应用查找信息、保持状态一致，还要在几十甚至上百步操作后，把所有细节正确落到系统里。

这也是 SaaS-Bench 想揭示的现实：Agent 不只是要会点按钮、填表格，更要能完成真实办公室里的长流程工作。

如果连实习生日常能做的任务都无法稳定完成，那我们就需要重新审视：距离真正可用的 Agent，还有多远。

• Blog 链接：https://unipat.ai/blog/SaaS-Bench
• GitHub 链接：https://github.com/UniPat-AI/SaaS-Bench
• 论文链接：https://arxiv.org/abs/2605.15777

Computer-Use Agent 的「奇点」没有来，现实的冷水先泼下来了。

过去一年，各家 GUI Agent 争先恐后地宣称能替人类干活。Benchmark 成绩一路飙升，投资人兴奋，媒体狂欢，「全自动办公」似乎就在眼前。

但 UniPat AI 刚刚用一组数据证明：这一切，都建立在沙子上！

Leaderboard

23 个真系统，106 个任务，一场残酷的实战考试

现有的 Agent 评测，说白了就是：仿真环境、简单任务、最多几十步搞定。

跟真实工作完全是两回事。

真实办公长什么样？一个医疗管理员写完 SOAP 病历→填病例上报→生成正式文档。一个财务收到报销申请→审批→打款→记账。跨好几个系统，步骤动辄几百步。

SaaS-Bench 的思路很暴力：直接把真系统搬进 Docker，让 Agent 在真实的前后端逻辑、数据库状态和业务约束中干活。

SaaS-Bench 任务 —— 真实工作场景任务

SaaS-Bench 精心挑选了 23 个开源 SaaS (Software-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，否则为 0
• Checkpoint Score（检查点分数，宽松）：按权重计算部分检查点完成比例

Agent → Browser-Use → 执行 → 验证 → 打分总览图

后面的结果会表明 —— 这两个数字之间的巨大落差，恰好暴露了 Agent 最核心的问题。

榜单出炉：全军覆没

来看这组数字 —— 

主要结果 (DeepSeek V4 、M2.7 和 GLM5.1 为单模态模型，仅测评 Text-Only Domain)

最强的 Claude Opus 4.7，检查点分数 43.9%，端到端完全通过分数只有 3.8%——106 个任务，只完整通过了 4 个。Kimi K2.5 和 Gemini 3.1 Pro？完全通过分数为零。一个任务都没走完。

这组数字的含义极其残酷：Agent 可以推进工作的部分中间环节，但几乎没有能力将一个完整的长程工作流走完。

多跑几次能救吗？

四个模型的 Pass@k 结果

把每个模型在同一任务上独立跑 3 次，对一次就算通过。pass@3 相比 pass@1 整体提升约 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 重做一遍。

UniPat AI

UniPat AI 致力于构建面向真实场景的 AI 训练、评测与应用新范式，推动 Agent 能力在千行百业中规模化落地，创造切实的经济与社会价值。

• 官网链接：https://unipat.ai

文章来自于"机器之心"，作者 "机器之心"。