如何判断智能体任务已成功执行

如何判断一个AI智能体（Agent）是否真正可靠？标准其实非常直接：关键在于它能否真正完成任务，而不仅仅是执行动作。

行业内普遍采用的评估方法，是为Agent配置一个虚拟机环境，预装特定软件或模拟网页，然后根据其操作步骤进行打分。基于这一思路，诞生了诸如评估操作系统操作能力的OSWorld、评估客服工作流效率的Tau等一系列基准测试（Benchmark）。

即便是GPT-5.5发布时，其官方数据也引用了这类榜单的结果。

每当有新模型发布，这些性能曲线总会被反复展示。然而，这其中存在一个业界心照不宣的漏洞：基于模拟器的评测，衡量的是“动作”是否标准，而非“最终结果”是否达成。基准测试的核心目的，本应是发现现有模型的短板。在“使用电脑”这一具体场景下，最大的挑战莫过于存在大量“面试型选手”——许多Agent擅长表演，能漂亮地完成复制文件等简单操作，并提交一份看似完美的报告。

然而，一旦将其置于真实的办公环境中，我们真正关心的是那些需要跨软件协作、步骤动辄上百的复杂长链条任务，最终是否被成功执行。

为了解决这一核心痛点，UniPat实验室的研究人员推出了一项全新的基准测试：SaaS-Bench。它的目标非常明确，就是专门治理Agent在电脑操作任务上的“言行不一”问题。

他们是如何实现的呢？研究团队将一批知名且开源的SaaS应用，例如Mattermost、OnlyOffice、ownCloud等，打包整合进一个Docker容器，构建出一个高度真实的办公环境。然后，让各类Agent在此环境中进行实际操作。最关键的一步在于：任务完成后，直接检查后台数据库是否发生了预期的状态变化。

测试结果颇具启发性。尽管Opus和GPT系列模型依然保持领先优势，但在这种“结果导向”的真实校验下，即便是排名第一的模型，得分也未超过50%。

（注：本轮测试中，DeepSeek、GLM、MiniMax等模型因不支持多模态输入，其评分受到一定影响。）

真正的「真实」，必须可被检测

过去评估图形用户界面（GUI）操作能力，通常搭建一个静态网页环境，观察Agent能否正确点击按钮。这类似于考驾照：只考核你是否会侧方停车、是否压线。

但真正上路驾驶则是另一回事。真实的办公场景是业务导向的，环境也复杂得多。有时，Agent的点击动作看似成功，页面也发生了跳转，但后台可能根本没有收到有效请求——例如，它可能点击了一个伪装成按钮的图片链接。

真实的电脑操作环境，总是充满了各种意想不到的“陷阱”。

因此，不妨回归第一性原理：Agent的自我汇报可能存在“水分”，但数据库的状态不会说谎。只要检测数据库里的关键字段是否发生预期变化，就能准确判断任务是否真正完成。正是基于这一核心理念，SaaS-Bench应运而生。

它的评估链条设计得非常清晰：任务输入 → Agent执行 → 操作Docker环境中的SaaS应用 → 通过浏览器进行交互 → 后端状态验证 → 最终评分。任何一个环节都不可或缺。

UniPat团队将23个开源SaaS应用整合进Docker环境，测试场景覆盖了软件研发、业务财务、医疗管理、团队协作、农业供应链、独立媒体这六大核心领域。每个业务场景都使用了真实的业务数据进行模拟，具体分布如下图所示：

六大领域，二十三个应用，这张环状图中很可能就包含了你公司正在使用的工具。

值得一提的是，在全部的106个测试任务中，高达93.4%的任务需要跨两个以上应用协作，涉及三个应用协作的任务占了一半（53个）。其中，纯文本任务74个，需要多模态理解的32个。这高度贴合我们日常的工作习惯——总是在不同软件之间反复切换、复制粘贴。而以往的各类GUI基准测试，基本只测试50步以内的单应用任务。

以医疗管理场景为例：医生需要先在OpenEMR系统中撰写SOAP病历，然后跳转到OpnForm填写上报字段，最后在OnlyOffice里生成正式文档。整个过程需要在三个独立系统间来回切换，流程如下图所示。

此前的基准测试多以50步以内的单应用任务为主，而SaaS-Bench的任务基本都是100步以上的长程复杂任务。只要中间有任何一步“敷衍了事”，最终的数据校验就无法通过。

那么，这些高难度任务是如何产生的？这里引入了“人在回路”（Human in the Loop）机制：首先由大语言模型结合职业角色和任务种子生成初步数据，再由领域专家进行人工筛选、实际执行，并与验证器逻辑对齐，确保所有任务既具有行业代表性，又是技术上可验证的。

整个任务生成与验证过程大致分为以上四个阶段。

此外，在这个基准测试中，“操作是否正确”完全通过“查询数据库”来判定。背后运行着一个独立的验证器：每个任务都对应一个verify.py脚本，任务运行时自动调用SQL查询数据库、或调用API拉取状态。任务一结束，验证器就直接去核对数据库里的字段值是否符合预期，从根本上杜绝下图所示情况的发生。

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的表现显著更强，这与其技术迭代的认知相符。对于不支持多模态的DeepSeek、GLM、MiniMax这三款模型，如果仅看纯文本任务，最新发布的DeepSeek V4要强于GLM和MiniMax，符合“越新越强”的一般规律。

此外，测试还揭示了两个有趣的现象：第一，几乎所有多模态模型，在理论上更难的多模态任务上，得分反而更高；第二，支持多模态的模型，即使在纯文本的电脑使用任务上，表现也更强。对于第二点，考虑到在纯文本模式下，单模态模型只能依赖无障碍树，而多模态模型额外多了一张截图。这意味着，即便是对AI智能体而言，“图文并茂”的信息也能更好地帮助它理解环境。

任务越长，成功率越低

任务步骤越长，越容易出错，这符合直觉。具体数据可以从上方的图表中清晰看到：

• 单应用任务的平均成功率在53%左右，而跨4个应用的任务，成功率就骤降到20%。
• 操作步骤在50步以内的任务，平均成功率超过50%，但到了400步，成功率就在20%左右徘徊。
• 验证点在6个以内的任务能拿到65%的分数，而验证点超过18个，分数就掉到27%。

总而言之：任务越复杂，得分越低。从数学概率上看这也合理，即便每个检查点的通过率高达95%，连续通过12个检查点的概率也就只剩54%了。

97.3%的任务超过100步，最长的有300多步。真实的办公流程往往就是如此冗长。

步数越多，任何一步出错的可能性就越高，后续挽回的机会也越少。如果将任务切分成早、中、晚三个阶段来看，所有模型都呈现同一个趋势：前期得分较高，后期失分严重。

所有模型的成功率曲线一路向下，无一例外。

同时，单步错误率并非一成不变。当前序步骤发生错误，可能会连带影响后续许多步骤的成功率，并且错误难以自我检测和纠正。比如下面这个典型案例：

在第七步被一个小问题绊倒，后面九步跟着全部出错。

在这个任务中，目标是创建一个名为“Arcturus Digital”的公司客户。Agent填写了联系人姓名和公司名，却意外触发了创建个人客户的逻辑路径，结果实际创建出一个名叫“Elena Vasquez”的个人客户。这个早期错误导致后续的开发票、记录付款、对账等所有流程，都因为挂在错误的客户实体下面而全部失败。可见，前期一个微小的偏差，在复杂的后续业务环境中能造成连锁反应和巨大损失。

数据库校验：专治AI“嘴硬”

大语言模型多少带有一些“先承诺，不行再道歉”的习性，而通过数据库进行结果校验，堪称一项创举。以前如果让Agent自我检查，它可能会信誓旦旦地汇报：“放心吧，餐厅100%订好了。”但用数据库一校验，很容易就发现大模型在这里产生的“幻觉”问题：许多Agent的自我评价并不可靠。

如果只看Agent提交的最终汇报，很多时候你会被它看似完美的说辞所迷惑。这时候，你需要像进行“赛博验证”一样，亲自去查看后端数据。

例如，Opus 4.6在一个任务中发现日期填错了，它会说“我现在就去修改，一定搞好”，并汇报“账单日期2026-03-20，已修复”。但如果此时通过API查看后台，数据很可能纹丝未动：账单日期依然是03-19。

意图说成了，状态说没成，两边信息对不上。

Agent在意图层面认为自己成功了，它的反思机制是“我会改”，但不一定能改成功。这一点相信许多开发者深有体会。而独立验证器的存在，正好可以用来检验Agent的“承诺”到底有多少能落到实处。

从评估榜单，到高质量训练数据

对于“电脑使用智能体”这个研究领域，过去两年一直面临一个核心困境：高质量的训练轨迹数据严重短缺。WebSTAR、GUI-360、Video2GUI等近期论文，开篇都指出了同一个问题——数据的稀缺性。

CUA的训练数据主要来自人工标注，成本高昂且难以扩展；另一部分则来自简化环境下的合成数据，成本低但真实性差。SaaS-Bench更有价值的地方在于它所构建的真实环境，能够稳定地产出长程、跨应用、且带有真实后端校验的运行轨迹数据。

对于任何想要攻克真实办公环境自动化难题的Agent开发者来说，这套环境及其产出的数据，都具有极高的参考价值和实用意义。

总结与展望

如果我们真的希望AI智能体能够深入千行百业，成为可靠的数字员工，就必须建立更有效的评估体系，确保它在执行任何任务时，都不是在“表演”或“敷衍”。

评估一个AI Agent，不能只看它的结案报告写得多么漂亮、逻辑多么自洽，更需要通过技术手段验证它是不是真的把活儿干完了、干对了。

SaaS-Bench的意义，恰恰在于提供了一套可靠的“测谎”机制，以及一个能够“持续生成高质量训练数据”的真实环境。或者说，它为我们提供了一套未来给AI“绩效考核”的客观凭证。

技术趋势已然如此，是时候深入理解并拥抱它了。