怎么知道 Agent 真干完活了？

SaaS-Bench, 一份新的研究

判断 Agent 靠谱与否，核心指标只有一个：是不是真干完活了

行业的做法大抵是：给 Agent 配台虚拟机，里面里装点程序或者仿真网页，给他的操作打分。在这种逻辑下，诞生了如评估电脑技能的OSWorld，评估客服工作流的 Tau2 等 bench

在 GPT-5.5 发布的时候，也是引用了这些个榜单

每当模型发布的时候，这些曲线就会被拿出来展示，但这里却有一个心照不宣的漏洞：用模拟器评测，测的是【动作】，而不是【结果】

Benchmark 最主要的功能，是扫描现有模型的问题。而在 Computer Using 这个场景下，最大的挑战就是面试形选手太多：很多 Agent 非常善于表演，能完成如复制文件之类的简单动作，再给出非常漂亮的结案报告

但如果放在真实的办公场景，我们更在乎的是那些跨软件、动辄上百步的长任务，最终是不是完成了

为了解决这个问题，我那些个在 UniPat 实验室整活的朋友，整了个新玩意儿：SaaS-Bench，来给 Agent 操作电脑这事儿，治治嘴硬

他们把一堆非常知名的、开源的 SaaS 工具，比如 Mattermost、OnlyOffice、ownCloud 打包进了一个 Docker，用真实的的办公环境，看看这些 Agent 怎么操作，以及操作完成后数据库有没有变化

作为测试结果，Opus 和 GPT 确实断档领先。但在这种真实的校验下，强如榜首也只拿了不到一半的分数

（另：这里 DeepSeek/GLM/MiniMax 不支持多模态，所以评分受影响）

所谓「真实」，必须能检测

之前测 GUI 能力的时候，通常是搭建一个静态网页的环境，看 Agent 能不能正确的点击按钮。测 bench，大抵就像是考驾照：看你会不会侧方位停车、会不会压线等等

但实际上路是另一回事儿。咱正常办公是业务导向的，环境也是较为复杂的，比如有的时候 Agent 的点击虽然成功了，甚至网页也跳转了，但后台可能没收到响应...因为你可能点了假链接，比如...下面这种

真实的电脑环境，总是有很诡异的问题

作为第一性原理，我们不妨换个思路：Agent 的嘴会骗人，但数据库不会，只需要检测数据库里的变化就行了，按着这个思路，就有了 SaaS-Bench

Task Input → Agent → SaaS Apps（Docker）→ Browser-Use → Verify（State-Check）→ Score，走完这条链才算数

然后呢，UniPat 的朋友把 23 个开源 SaaS，都丢进了 Docker 来跑，测试项目覆盖软件研发、业务财务、医疗管理、团队协作、农业供应链、独立媒体六个领域。然后每个业务场景里都是用了真实的业务数据，大概就像下图所示：

六个领域二十三个 App，环状图里大概率有你们公司在用的那几个

值得一提的事，在全部的 106 个任务里，93.4% 跨两个以上 App，三 App 协作的占一半（53 个）。纯文本任务 74 个，涉及多模态理解的 32 个。

这就很符合我们常见的工作习惯了，总是跨着软件来反复复制粘贴....哈哈哈哈，然后之前的各种 GUI bench 中，基本测试的都是 50 步以内的单 App 任务

就以医疗管理为例，医生先要在 OpenEMR 里写 SOAP 病历，再到 OpnForm 填上报字段，最后到 OnlyOffice 出正式文档，三个系统之间切来切去，就像下图所示

OpenEMR 写 SOAP 病历 → OpnForm 填上报字段 → OnlyOffice 出正式文档

之前的 bench 里测的基本上是 50步以内的单 App 任务，而 SaaS-Bench 则基本都是 100 步以上的长程任务，但凡中间出现糊弄，最终数据库校验就过不去

至于这些任务是怎么来的？也是有 Human 在 Loop 的，是先由大模型结合职业角色和 task seed 生成初步的数据，再由专家人工筛选、实际执行、对齐验证器，以保证所有的任务具有代表性和可验证性

大概就是这么四个阶段

还得说一下，在这个 Bench 里「操作对不对」这件事儿是通过「查数据库」来检测的，背后有一个验证器：每个任务都有一个 verify.py 文件，在跑任务的时候会自己调 SQL 查数据库、调 API 拉状态。每当任务有结果了，verifier 就会直接去查数据库里的字段对不对，避免出现下面这种情况

hhhhh

SaaS-Bench 榜单

【注意】DeepSeek/GLM/MiniMax 是单模态

说一下榜单的测试成绩吧，模型测试其实分为大类：文本任务和多模态任务，两者都通过 Browser-Use 在浏览器里操作 SaaS 界面，区别在于：多模态模型喂的是截图+无障碍树；不支持多模态的模型喂的就只有无障碍树，页面所有可交互元素被提取成结构化文本，模型读文字、输出「点第几号元素」

对于多模态的模型，没啥悬念的 Opus 4.7 拿了第一，checkpoint 分 43.9%，resolved 分 3.8%。GPT-5.5 High 几乎打平，checkpoint 43.8% 但 resolved 只有 1.9%

这里说一下，resolved 指的是完美完成了任务，checkpoint 则是给过程分；很显然，即便是强如 Opus，在真实操作办公软件这事儿上，其实跟弱智也差不多，很符合体感

在支持多模态的国产模型里，K2.6 是显著最强的，很符合认知：K2.5，是 Kimi 的一个分水岭/Kimi K2.6 开源：一个人，和他的 300 Agents

对于不支持多模态的 DeepSeek/GLM/MiniMax 这三款模型，只看 text-only  任务的话，最新发布的 DeepSeek V4 是强于 GLM 和 MiniMax 的，符合「越新越强」的刻板印象

然后...我发现了两个有趣的现象：其一、几乎所有多模态模型，在理论上更难的多模态领域里，分都会更高；其二、支持多模态模型，即便是在 text-only 的 Computer-Use 任务里，也更强

对于第二个点，考虑到在 text-only 下，单模态模型靠的是无障碍树，而多模态模型多了个截图，这意味着...即便是 Agent，图文并茂也是更利于模型/Agent 进行信息理解

任务越长，成功率越低

越长的任务，就越容易出问题，这个还是很容易理解的。作为数据，可以查看上面的图：

• 单 App 的任务平均分 53%，而跨 4 个 App 任务的成功率就掉到 20% 左右
• 操作部署在 50 步以内的任务，平均成功率有 50%+，但到了 400 步就在 20% 左右
• 验证点 6 个以内能拿 65% 的分数，18 个以上则掉到 27%

总而言之：任务越复杂，分越低。当然，从数学上来看也合理，即便每个 checkpoint 通过率高达 95%，12 连抽也就只剩 54%

97.3% 的任务超 100 步，最长 300+。真实办公流程就是这么长

步数越长，任何一步出错的概率越高，后面恢复的机会越少，把任务切成 early / mid / late 三段看，所有模型都是同一个走势：前段拿分，后段掉分

所有模型一路向下，没有例外

同时的，单步骤错误率并非一成不变，当前序步骤发生错误了，可能后续好多步的成功率都会受到影响，并且难以自检，比如下面这个：

第七步小石头一磕，后面九分跟着倒

在这个任务里，是要创建一个公司客户 Arcturus Digital，Agent 填了联系人姓名加公司名，却触发了个人客户的逻辑路径，实际创建出一个叫 Elena Vasquez 的人。作为影响，后续的开发票、记付款、对账等流程，都因为全部挂在错误实体下而产生错误

可见，前面只是一个小的错误，在后续环境下都能产生不小的损失

数据库，专治嘴硬

大模型总是带着点「先忽悠，大不了道歉」的恶习，而通过数据库去校验实乃创举。之前如果让 Agent 去自检，他总是说「放心吧，餐厅 100% 定好了」但如果拿数据库去校验，就很容易发现大模型在此处出现的问题：很多 Agent 自评是纯幻觉的

如果你只看 Agent 给你的汇报结果，很多时候你会被骗的心服口服，这时候你需要真的让赛博勇哥过来，让你的 Agent 360 度转一圈，看看数据

比如 Opus 4.6 在一个任务里发现日期填错了，它会说「我现在就去修改，一定搞好」，并汇报「账单日期 2026-03-20，已修复」。此刻如果通过 API 看一下，可能后台里还是：账单日期 03-19

意图说成了，状态说没成，两边各觉得自己没错

Agent 在意图层面认为成功了，反思机制是「我会改」，但不一定会改成功，这点相信大家一定深有体会，而 verifier 这玩意儿也正好拿来看看 Agent 到底能怎么糊弄

从榜单，到训练数据

对于 Computer-Use Agent 整块，在过去两年都在面临一个事情：CUA 训练数据严重不足，WebSTAR、GUI-360、Video2GUI 这些近期论文，开篇都点同一个判断：scarcity of high-quality trajectory data

CUA 训练数据大头来自人工标注，贵且不可扩展，而另一部份则来自简化环境下的合成数据，便宜但不真

SaaS-Bench 更有价值的地方在于它的环境，能够稳定的产出长程、跨 App、带真实后段校验的运行轨迹

对于想要攻克办公环境的 Agent 来说，这套环境是非常有价值的

总结

如果我们真的希望 Agent 能够进入千行百业，那么就应该更好的评估 Agent 的行为，确保无论它在做任何事情的时候，不是在糊弄

对于 Agent 的评估来说，我们不能只看他的结案报告写的多漂亮，排版多精美，更需要的是看看 Agent 是不是真的干完活了

SaaS-Bench 的意义，恰就在于给出了一套「测谎」的方法，以及一套「生成数据」的环境，或者说...给未来 Agent 打绩效的凭证...

趋势已经是这样了，拥抱吧

Blog：unipat.ai/blog/SaaS-Bench

GitHub：github.com/UniPat-AI/SaaS-Bench

论文：arxiv.org/abs/2605.15777

文章来自于"赛博禅心"，作者 "金色传说大聪明"。