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

机器之心
个人专栏
热度: 5541

SaaS-Bench 是一项面向真实办公场景的AI Agent评测基准,通过在23个真实部署的开源SaaS系统中运行106个跨应用、长流程、多步骤任务,揭示当前主流Agent(如Claude、Gemini等)端到端完成率极低(Claude最高仅3.8%),暴露其在状态保持、错误恢复、闭环验证和路径稳定性等方面的结构性缺陷,戳破‘全自动办公’幻象。

摘要由 Mars AI 生成
本摘要由 Mars AI 模型生成,其生成内容的准确性、完整性还处于迭代更新阶段。

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

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

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

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

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

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

SaaS-Bench

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 刚刚用一组数据证明:这一切,都建立在沙子上!

SaaS-Bench

Leaderboard

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

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

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

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

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

SaaS-Bench

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 进入的不是一个空白的测试页面,而是一个有历史数据、有干扰项、有跨系统关联的真实工作环境。

SaaS-Bench

任务模态、领域、app 三层分布

106 个任务中,93.4% 跨越至少两个应用,三应用任务占了一半(53 个)。纯文本任务 74 个,涉及多模态理解的 32 个。以 Claude Opus 4.6 的执行轨迹估算,97.3% 的文本任务操作步数超过 100 步,最长轨迹达 300+ 步。

SaaS-Bench

任务难度分析 —— 大多数任务是 Cross-App + Long-Horizon 的

这些任务是怎么来的?如何评估 Agent 的操作能力?

SaaS-Bench 采用“LLM 生成 + 专家把关”的方式完成任务构建:

先由 LLM 围绕六大专业领域和具体职业角色生成任务,明确任务目标、跨应用依赖和验证要求,并通过多轮修改减少歧义和漏洞。

随后,专家会对任务进行人工筛选和真实执行检查,重点判断任务是否专业、自然、可完成、可验证。对于堆砌步骤、逻辑混乱或验证不准的任务,会被修改或剔除,最终确保每个任务都能真实运行,并能被验证器准确评估。

SaaS-Bench

任务构建流程图 —— 四个阶段保证任务质量

SaaS-Bench 允许 Agent 使用 Browser-Use 在 SaaS 环境中操作计算机,并给出了两个指标:

Resolved Score(完全通过分数,严苛):全部检查点通过才算 1,否则为 0

Checkpoint Score(检查点分数,宽松):按权重计算部分检查点完成比例

SaaS-Bench

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

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

榜单出炉:全军覆没

来看这组数字 ——

SaaS-Bench

主要结果 (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 可以推进工作的部分中间环节,但几乎没有能力将一个完整的长程工作流走完。

多跑几次能救吗?

SaaS-Bench

四个模型的 Pass@k 结果

把每个模型在同一任务上独立跑 3 次,对一次就算通过。pass@3 相比 pass@1 整体提升约 8 个百分点。

Sonnet 4.6 在多模态任务上从 33.9% 跳到 52.1%(+18.2pp)—— 它并非完全不行,而是执行极不稳定

这不是环境随机性。每次运行的初始状态完全相同。这是路径依赖 —— 模型在某个决策点的微小差异,导致后续轨迹完全分叉。

多跑几次有帮助,但远不是解决方案。

越复杂,分越低

三个结构维度全部单调递减:

SaaS-Bench

分数 vs 应用数 / 分数 vs 步长 / 分数 vs 检查点个数

跨应用数1→4:平均分从 53% 降至 20%

操作步长增加:任务轨迹越长,得分显著越低

检查点个数≤6 vs ≥18:平均分从 65% 降至 27%

「跨应用 + 轨迹长 + 细粒度验证」的任务得分最低 ——这恰恰是真实工作流最常见的形态。

四种结构性失败:Agent 到底在哪翻车

SaaS-Bench 真正的价值不在于分数本身,而在于暴露了 Agent 在真实环境中的四种致命缺陷。

失败 1:任务越长,越做不对

即使每个检查点通过率高达 95%,12 个检查点的全部通过概率也只有 54%。而 SaaS-Bench 的平均检查点数远超 12。

所有模型都呈现同一个模式:通过率随任务推进呈下降趋势,没有一个模型能在后半段维持住前期表现。

SaaS-Bench

模型随着任务执行,做对的越来越少

这是一条不可逆的下降曲线。越往后走,越不可能走完。

失败 2:一步错,步步错

一个典型案例:任务要求创建一个公司客户「Arcturus Digital」。Agent 同时填了联系人姓名和公司名,触发了个人客户逻辑,实际创建的是个人客户 Elena Vasquez。

此后的 10 张发票、付款记录、账户对账,全部挂在错误实体下。核心检查点权重仅 3%,但导致了下游 30% 的权重损失。

SaaS-Bench

上游任务导致下游失败链示意图

一个 3% 的错误节点,造成 30% 的分数损失。

失败 3:做完不检查,自以为对了

Claude Opus 4.6 在 Step 124 识别出日期错误(2026-03-19 vs. 2026-03-20),执行了修改,但没有回到页面复查,直接推进后续子任务。Step 210 提交时,汇报写的是「账单日期 2026-03-20,已修复」—— 页面上实际日期仍是 03-19。

SaaS-Bench

Agent 在意图层面认为成功,Verifier 在状态层面发现失败

Agent 在意图层面认为成功,验证器在状态层面发现失败。两者之间的断层是系统性的。 当前 CUA 框架缺少「严谨的反思闭环」 —— Agent 是个不会检查自己作业的学生。

失败 4:同一张考卷,成绩忽高忽低

Claude Sonnet 4.6 在同一任务的三次独立运行中,分数范围从 0.00 到 0.68。这不是环境随机性造成的 —— 每次运行的初始状态完全相同 —— 而是路径依赖:模型在某个决策点的微小差异,会导致后续执行轨迹完全分叉,这让 Agent 在长程任务中的执行变成了赌博。

SaaS-Bench

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

本文来自微信公众号“机器之心”

声明:本文为入驻“火星财经 专栏”作者作品,不代表火星财经官方立场。
转载请联系网页底部:内容合作栏目,邮件进行授权。授权后转载时请注明出处、作者和本文链接。未经许可擅自转载本站文章,将追究相关法律责任,侵权必究。
提示:投资有风险,入市须谨慎,本资讯不作为投资理财建议。
本内容旨在传递行业动态,不构成投资建议或承诺。