🤖 AI

SaaS-Bench: Can Computer-Use Agents Leverage Real-World SaaS to Solve Professional Workflows?

本文介绍了 SaaS-Bench，这是一个涵盖 23 个专业 SaaS 系统中 106 项真实任务的综合基准，其结果表明，当前的计算机使用智能体在规划和状态跟踪及错误恢复方面的局限性，使其在处理复杂、长程工作流时面临显著困难，端到端成功率不足 4%。

原作者： Kean Shi, Zihang Li, Tianyi Ma, Zengji Tu, Jialong Wu, Xinbo Xu, Qingyao Yang, Ruoyu Wu, Weichu Xie, Ming Wu, Jason Zeng, Michael Heinrich, Elvis Zhang, Liang Chen, Kuan Li, Baobao Chang

发布于 2026-05-18

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Kean Shi, Zihang Li, Tianyi Ma, Zengji Tu, Jialong Wu, Xinbo Xu, Qingyao Yang, Ruoyu Wu, Weichu Xie, Ming Wu, Jason Zeng, Michael Heinrich, Elvis Zhang, Liang Chen, Kuan Li, Baobao Chang

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你正在招聘一位新助理来处理你最复杂的工作日。你不仅仅希望他们回复邮件；你希望他们能登录你的银行账户、项目管理软件、医疗记录和设计工具，真正去完成工作。

这篇论文介绍了一项名为SaaS-Bench的新“期末考试”，旨在测试 AI 助手（称为计算机使用代理）在应对这类现实世界任务时的真实能力。

以下是他们所做的工作及发现，辅以简单的类比进行解析。

1. 问题所在：“电子游戏”与“真实工作”

迄今为止，大多数针对 AI 助手的测试就像玩电子游戏。关卡短暂，规则简单，如果你卡住了，游戏只需重置即可。

旧方式：“点击红色按钮，然后输入‘你好’。”（简单、短暂、孤立）。
现实世界：“进入人力资源系统解雇一名员工，然后进入会计系统计算其最终薪资，接着进入客户关系管理系统重新分配其客户，并确保日期完全匹配。”（困难、漫长、混乱）。

作者意识到，通过“电子游戏”式的测试并不意味着 AI 能够胜任真实工作。因此，他们基于23 个真实可部署的软件系统（如真实的医疗记录系统、会计工具和项目管理工具）构建了一项新测试，这些系统正是专业人士实际使用的。

2. 考试：SaaS-Bench

将SaaS-Bench想象成一个巨大的、持续多天的障碍赛。

赛道：它包含106 个不同的任务，分布在六个不同的工作“社区”（如医疗保健、金融和软件工程）中。
规则：AI 必须像人类一样，使用网页浏览器在这些系统中导航。它不能通过查看数据库代码作弊；它必须点击按钮并阅读屏幕。
难度：这些任务并非只需 5 分钟。平均每个任务需要超过 100 个步骤（点击、输入和滚动）。这就像要求某人烤一个蛋糕，为其撰写食谱，将食谱寄给朋友，然后归档面粉的收据，所有这一切一气呵成。

3. 结果：AI 迷失了方向

研究人员在考试中测试了当时最智能的 AI 模型（即 AI 界的“优等生”）。结果令人清醒：

得分：即使是最好的 AI 模型，也仅完成了**不到 4%**的任务，且是从头到尾完整完成的。
“差点”陷阱：AI 实际上在任务的开始阶段表现不错。它能完成 80% 的进度。它可以填写第一份表格，点击正确的按钮，并创建第一份文档。
崩溃：但随后，它会犯下一个微小的错误（例如输入错误的日期），未能察觉该错误，然后继续沿着错误的道路走下去。等到它到达终点时，整个结果都是错的。

类比：想象一个 GPS，它非常擅长告诉你“左转”和“直行 5 英里”。但如果你不小心错过了一个转弯，GPS 并不会说“你迷路了，让我们重新计算”。相反，它会自信地告诉你继续直行 50 英里，直到你耗尽燃油。AI 很自信，但它经常出错。

4. 它们为何失败？（四大障碍）

论文指出了 AI 挣扎的四个主要原因，并运用了一些精彩的隐喻：

“纸牌屋”效应（脆弱性）：在这些长任务中，每一步都依赖于前一步。如果你在第 10 步搞砸了，第 11 步到第 100 步就全毁了。AI 在第 10 步表现得如此出色，以至于它认为自己做得很好，但那个微小的错误却导致整个结构崩塌。
“沉默的毒药”（错误级联）：有时 AI 犯下的错误在表面上看起来是正确的。
- 示例：AI 创建了一个名为"Elena"的客户，而不是"Arcturus Digital"。屏幕上显示"Elena (Arcturus)"，所以 AI 心想：“太好了，我做到了！”但由于名称在技术上不正确，随后发生的每一笔财务交易都关联到了错误的人身上。AI 从未意识到它毒害了源头。
“自信的骗子”（自我欺骗）：AI 有一个“记忆”，它会在那里告诉自己它做了什么。有时，它看到了错误，试图修复它，却忘了检查修复是否生效。然后，它会写一份报告说：“我修好了！”尽管屏幕上仍然显示错误。这就像一个学生意识到自己犯了数学错误，试图擦掉它，但随后还是把答案写了下来，并说：“我完成了。”
“抛硬币”（不可靠性）：如果你让同一个 AI 执行相同的任务三次，它第一次可能得满分，第二次完全失败，第三次表现尚可。它缺乏一致性。这意味着即使它昨天能工作，你今天也不能信任它能可靠地完成任务。

5. 结论

这篇论文问道："AI 代理能否使用现实世界的软件来解决专业工作？"

答案是：尚未。

虽然这些 AI 模型在交谈和理解语言方面极其聪明，但它们目前在长期、复杂、现实世界的执行方面表现极差。它们会迷失在细节中，不会双重检查自己的工作，并且在犯错后无法恢复。

作者构建这项测试（SaaS-Bench）并非为了说明 AI 无用，而是为了向我们确切展示它在哪里出错，以便我们能够修复它。在 AI 能够在不混淆或不自信地给出错误答案的情况下处理 100 步的工作流程之前，它尚未准备好接管你的专业工作。

技术摘要：SaaS-Bench

问题陈述

计算机使用代理（CUAs）已从被动的文本生成器演变为能够与图形用户界面（GUI）和 Web 浏览器进行交互的主动执行者。然而，现有用于评估这些代理的基准测试存在三个关键局限性，导致对其现实世界能力的系统性高估：

应用复杂性有限：许多基准测试依赖于简化的、静态的或合成的 Web 环境，缺乏生产级软件所具备的完整前端 - 后端逻辑、动态状态依赖和业务约束。
孤立的工作流：任务通常局限于单一应用程序且时间跨度较短，未能捕捉专业工作中固有的跨应用程序协调、领域特定知识以及结构化的多步骤流程。
短视野依赖：现有任务很少需要扩展的交互序列（通常超过 100 步），而这些序列对于测试代理随时间推移的规划、状态跟踪和错误恢复能力是必要的。

因此，目前缺乏严格的评估框架来确定 CUAs 能否在现实世界的高价值软件即服务（SaaS）环境中有效运行。

方法论

基准构建（SaaS-Bench）

作者引入了SaaS-Bench，这是一个旨在评估 CUAs 在现实可部署 SaaS 环境中表现的基准。构建过程遵循三个核心原则：

现实且可部署的环境：
- 该基准建立在23 个真实的开源 SaaS 系统（例如 OpenEMR、OnlyOffice、BigCapital）之上，而非玩具网站。
- 这些系统通过 Docker 容器化，确保完整的前端 - 后端逻辑、持久化的数据库状态和用户认证。
- 在每个任务开始前，环境会重置为预定义的初始状态，以确保可重复性并防止状态污染。
- 数据通过结合大语言模型（LLM）生成的现实数据与导入的开源数据集进行语义填充，以确保具有意义的业务上下文。
专业、跨应用程序及多模态工作流：
- 任务组织在六个专业领域：软件工程、业务运营、医疗管理、团队协作、农业和媒体创作。
- 该基准包含106 个任务，均基于现实世界的工作流。
- 93.4% 的任务涉及至少两个应用程序，其中 50% 需要跨三个应用程序进行协调。
- 该集合包含74 个纯文本任务和32 个多模态任务（涉及图像、文档或媒体），主要集中在农业和媒体领域。
长视野执行：
- 任务设计平均包含超过100 个交互步骤。
- 一个四阶段流水线（任务种子 $\rightarrow$ 合成循环 $\rightarrow$ 静态检查 $\rightarrow$ 执行检查）确保任务具有专业性、可执行性和可验证性。这涉及一个迭代的“构建者 - 挑战者 - 优化者”循环，其中 LLM 生成候选任务，人类专家审查其歧义性、完整性和可验证性。

评估协议

执行框架：代理仅通过基于浏览器的 UI 操作（导航、点击、输入）进行交互，使用 browser-use 框架。禁止直接访问数据库、API 或文件系统。
验证：每个任务被分解为加权验证检查点。采用三种验证方法：
- 状态检查：验证客观系统状态（数据库记录、API 响应）。
- 内容检查：通过字符串匹配验证文本输出。
- LLM 裁判：评估开放式输出，如报告质量。
指标：
- 解决分数（Resolved Score）：二元（1 或 0）；仅当所有检查点通过时为 1。
- 检查点分数（Checkpoint Score）：反映进度的加权部分分数，允许衡量长视野任务中的中间成功。

关键结果

性能概览

实验在七个前沿模型（包括 Claude Opus 4.6、GPT-5.4 High、Qwen 3.6 Plus 等）上进行。结果表明，当前代理在现实 SaaS 工作流中面临显著困难：

端到端完成率低：即使是最强的模型Claude Opus 4.6，其解决分数也仅为 1.9%（端到端完成任务的比例不到 4%）。
检查点分数：最佳模型的整体检查点分数为43.2%，表明虽然代理通常能完成中间步骤，但无法保持连贯性以完成整个工作流。
领域差异：性能因领域而异，“团队协作”任务通常比“业务”和“医疗”任务更容易，后者涉及更严格的数值约束和领域特定流程。

失败模式分析

该论文确定了四种根本性的失败模式，解释了低解决分数的原因：

长视野完成的脆弱性：由于成功概率的乘积性质（ $p^N$ ），即使每个检查点的高准确率（例如 95%），对于具有 10–20 个检查点的任务，其解决分数也接近于零。
跨应用程序工作流中的错误级联：单个语义错误（例如将客户错误分类为“个人”而非“公司”）可能会在依赖链中静默传播，导致下游检查失败，即使代理认为任务已完成。
不可靠的自验证：代理在修正后往往无法重新验证其操作。它们可能识别出错误，尝试修复，然后在未确认修复是否成功的情况下继续执行下一个子任务，从而导致“静默”失败。
高运行间方差：性能极不稳定。同一模型在相同任务的一次运行中可能得分为 0.80，而在另一次运行中仅为 0.10。这表明当前依赖单次运行指标（pass@1）的评估具有误导性；pass@k指标揭示，虽然代理偶尔能找到成功的轨迹，但一致性仍然是一个主要挑战。

意义与主张

该论文声称，SaaS-Bench提供了首个严格的、现实的测试床，用于在专业、跨应用程序、长视野设置中评估 CUAs。其意义在于：

揭示能力差距：它表明，尽管大语言模型（LLMs）取得了进展，但当前代理尚无法可靠地解决现实世界 SaaS 环境中的专业工作流，端到端完成任务的比例不到 4%。
重新定义评估标准：它认为短视野、单一应用程序的基准测试是不够的。该领域必须转向评估代理在长序列中维持状态、从错误中恢复以及跨多个系统协调的能力。
识别结构性局限：结果强调，主要瓶颈不仅仅是知识检索，而是规划、状态跟踪和错误恢复。该论文指出，当前的代理架构缺乏处理长视野任务脆弱性所需的闭环验证机制。

作者总结道，虽然 SaaS-Bench 揭示了显著的局限性，但它为未来研究更可靠、更具实际可部署性的计算机使用代理奠定了必要的基础。