AI 点完“成功”不算成功：GUI Agent 为什么必须做原子性测试

一个 GUI Agent 在页面上完成了全部操作，返回 status: success，还生成了一份看起来正确的患者记录。测试通过了吗？未必。真正决定结果的，是它离开之后，数据库、文件和业务状态究竟变成了什么。

图解： 最上层是 Agent 能看到并操作的 GUI，蓝色轨迹表示它执行的一连串点击与输入，右侧绿色勾只说明界面流程已经走到“成功”。中间和底层代表业务状态与数据库，橙红节点表示某个字段或记录已经被错误写入。原子性测试要继续穿透界面反馈，比较运行前后的真实状态，确认目标变化正确、禁止变化没有发生。

最近一篇名为 LegacyWorld 的研究，把这个容易被忽视的问题摆到了台面上。研究团队为 28 个 Windows GUI 工作流建立了可执行任务契约，让 6 个托管 Computer Use Agent 分别执行专家编写的流程，以及从专家操作录像生成的流程，再独立检查执行后的持久化状态。

这项研究最值得测试工程师关注的，不是某个模型的分数，而是一条更基础的质量原则：

GUI Agent 的一次运行，要么正确完成并留下正确状态；要么安全失败，不留下意外的持久化副作用。

这就是本文要讨论的“原子性测试”。

---

一、为什么 Agent 说“成功”仍然可能是失败

论文记录了一个非常具体的案例。在 DSWin 的“新增患者”任务中，Agent 返回成功，并给出了一份结构完整、看起来合理的患者信息。但运行结束后的数据库验证发现，保险号码被写成了 4212505，而任务契约要求的是 1234567890。

从 Agent 的视角看，它完成了流程；从业务系统的视角看，它留下了一条错误的持久化记录。

这类问题比普通页面自动化失败更危险，因为它往往同时具备三种迷惑性：

• 页面没有报错，甚至出现了成功提示；
• Agent 能自然语言解释自己做了什么；
• 错误已经越过界面，进入数据库、文件、配置或外部系统。

传统 UI 自动化通常重点验证“按钮能不能点”“页面有没有跳转”“成功提示是否出现”。GUI Agent 则会根据截图和上下文动态选择动作，它可能走出设计者没有预先写下的路径，也可能在中途停止、重试、误点或错误确认。

因此，测试对象已经从一条固定脚本，变成了一个会做决策、会产生真实副作用的执行系统。

---

二、原子性不是只测“成功率”

这里的原子性借用了事务“要么全部完成，要么不留下部分结果”的思想，但它不是在宣称所有 GUI 工作流都能自动获得数据库事务能力。它更准确地说，是一种运行结果的评价方法：无论 Agent 最后报告成功还是失败，系统都要处在任务契约允许的状态里。

LegacyWorld 把每次运行分成四类：

Agent 的结论	最终状态有效	最终状态无效
报告成功	有效成功：目标完成，状态正确	无效成功：Agent 说完成了，但结果错误或出现意外副作用
报告失败、停止或超时	有效失败：任务没完成，但受监控状态保持可接受	无效失败：任务没完成，还留下了部分修改或脏状态

图解： 上排两种结果的数据库仍保持绿色有效状态，区别在于左侧完成了业务目标，右侧选择安全停止；下排则出现橙红色异常。左下最危险——界面已经显示成功，后台数据却被破坏；右下代表 Agent 没有完成任务，还留下了需要人工修复的部分状态。四象限必须分别统计，不能压缩成一个“成功/失败”二元结果。

由此可以得到三个不能互相替代的指标：

指标	计算方式	回答的问题
有效成功率	有效成功 ÷ 全部运行	Agent 产生了多少真正可用的自动化价值？
原子性	有效成功 + 有效失败	每次运行结束后，系统状态有多大概率仍然可接受？
不安全副作用率	无效成功 + 无效失败	有多少运行留下了错误或意外状态？

这个拆分非常关键。一个 Agent 可以因为极度保守、几乎什么都不做而获得很高的原子性；另一个 Agent 可能完成了更多任务，却偶尔写坏关键数据。前者没有足够自动化价值，后者又可能无法安全上线。

真正的部署判断，必须同时看有效成功和状态安全。

---

三、论文数据揭示了什么

研究覆盖 28 个工作流，包括患者创建与查询、患者电话更新、计费代码录入、工资设置、报表导出、文件保存、软件安装和扩展管理等。其中 18 个任务经过领域专家或运营人员核对，以确认它们具有现实工作代表性。

在专家编写提示的实验条件下，结果呈现出明显不同的运行画像：

• GPT-5.4 的原子性为 100%，但有效成功只有 3.6%，绝大多数是“没有完成任务，但状态未被破坏”的有效失败；
• Claude Opus 4.6、Sonnet 4.6 和 Haiku 4.5 的有效成功分别达到 78.6%、75.0% 和 71.4%，但都出现了一定比例的非原子结果；
• Kimi K2.5 的有效成功为 42.9%，不安全副作用率达到 35.7%。

这些数字不能被写成模型排行榜。论文对每个模型—任务—提示组合只纳入一条执行轨迹，所有实验也都发生在隔离虚拟机中。它们是特定基准配置下的描述性证据，不足以推断模型长期稳定能力或生产可用性。

但它们足以证明一件事：完成率、保守失败和状态破坏是三种不同的运行特征，压缩成一个“成功率”会掩盖真正的运营风险。

---

四、屏幕录像不是正确性 Oracle

LegacyWorld 还比较了两种流程说明：一种由专家直接编写，另一种由模型根据专家的黄金路径屏幕录像生成。

录像很适合捕捉“人是怎么操作的”，却天然遗漏很多业务信息：

• 为什么此时可以点击确认；
• 哪些字段允许变化，哪些字段必须保持不变；
• 快捷键、焦点变化和屏幕外输入发生了什么；
• 中途失败应该清理什么；
• 最终数据库记录怎样才算正确。

实验中，多数 Agent 在录像生成提示下的有效成功率下降。例如 Opus 4.6 从 78.6% 降到 50.0%，Sonnet 4.6 从 75.0% 降到 53.6%。一些 Agent 的状态安全并没有同比恶化，更多运行只是转成了“安全但没完成”的有效失败。

这说明录像可以帮助采集流程，却不能代替任务契约。录像回答“通常怎么做”，Oracle 回答“做完之后什么才算正确”。

---

五、第一步：把操作说明升级为任务契约

很多团队给 GUI Agent 的输入只有一句话：“登录系统，新增一位患者并返回患者编号。”这只能描述目标，无法定义安全边界。

一份可测试的任务契约，至少应该包含以下内容：

契约字段	新增患者示例
初始状态	测试患者不存在；测试环境版本固定；目标数据库快照已保存
目标状态	只新增一条满足字段规则的患者记录，并返回真实患者编号
运行参数	姓名、生日、联系方式、保险号码、测试数据标签
允许变化	指定患者表新增一行；审计表新增对应事件
禁止副作用	不修改其他患者；不创建重复记录；不改变权限和系统配置
返回值契约	患者编号必须存在，并能与数据库新增记录关联
超时与停止	超过步骤、时间或重试上限时安全停止，不继续猜测
验证器	数据库差异、字段精确值、唯一性、审计事件和界面状态
恢复策略	仅清理本次带唯一标签的数据；清理后再次验证

图解： 左侧卡片代表任务契约，它在执行前固定“什么可以改、什么绝对不能改”；中间的发光指针代表 GUI Agent，只负责在授权范围内操作；右侧五条检查路径分别对应返回值、界面结果、持久化状态、禁止副作用和恢复结果。只有这些独立证据共同通过，最右侧的绿色盾牌才代表一次可信的有效成功。

这份契约不是更长的提示词。它应该成为 Agent、执行环境、验证器和测试报告共同读取的结构化事实。

最重要的是把“允许变化”和“禁止副作用”写出来。否则测试只能确认目标结果是否出现，却无法知道 Agent 是否顺手改坏了其他东西。

---

六、第二步：建立独立于 Agent 的状态验证器

不要让执行者同时充当自己的裁判。Agent 可以报告成功或失败，但最终结论必须由独立证据决定。

一个实用的验证器可以分成五层：

1. 返回值验证

检查 Agent 返回的编号、URL、文件路径、计算结果或结构化字段是否符合 schema，并与真实系统数据对应。

2. 界面结果验证

检查成功提示、当前页面、窗口状态和关键字段显示。这一层有用，但不能单独作为最终 Oracle。

3. 持久化状态验证

比较执行前后的数据库、文件、配置、安装状态或导出产物。对于数据库任务，应核对新增、修改和删除的精确差异，而不是只查“目标记录存在”。

4. 禁止副作用验证

主动检查不应该变化的对象：其他用户记录、相邻业务行、权限、目录清单、系统配置、重复文件和外部通知。

5. 恢复结果验证

如果流程支持补偿或清理，不要以“执行了清理命令”作为完成。清理后必须重新比较状态，确认系统真正回到允许的基线。

LegacyWorld 的做法是每次在新的 Windows 虚拟机中运行，先记录状态快照，运行结束、超时或异常停止后再采集最终快照，并用任务专属验证器判断。临时覆盖层在验证后丢弃，以保证后续运行拥有可比较的初始状态。

团队不一定需要完整复刻这个基础设施，但原则应该保留：测试环境可重置、状态可比较、验证逻辑独立、每次运行可追溯。

---

七、第三步：专门测试“做到一半会怎样”

普通演示总是沿着黄金路径走完，原子性问题却常发生在中间状态。测试设计需要主动把失败注入危险检查点。

以“创建订单并发送确认”为例，可以选择这些故障点：

故障检查点	注入方式	应验证的最终状态
表单填写一半	让元素失焦或页面重载	不产生正式订单，草稿规则符合契约
点击保存后未返回	模拟网络超时	不重复创建；可通过幂等键确认真实状态
订单已创建、通知未发送	阻断通知服务	订单和通知状态一致，可安全补偿或重试
Agent 误判成功	返回错误编号或旧页面提示	独立验证器将其判为无效成功
Agent 超时退出	在确认前后分别终止	确认前无持久化；确认后状态可识别、可接管

图解： 上方蓝色流程代表 Agent 从填写、保存、确认一直走到外部通知。三道门不是普通步骤，而是风险发生性质变化的边界：第一道门之前还能无损撤销，第二道门开始写入持久化状态，第三道门之后可能发送邮件、消息或触发其他外部动作。每道门都要同时测试绿色的安全停止分支和橙红色的非原子分支，确认系统能发现并阻断脏数据、重复写入和误发通知。

特别要测试三个边界：最后一次可逆操作、第一次不可逆写入、外部副作用发生前。支付、邮件、权限变更、批量更新和删除操作都应该在这些边界设置明确审批门。

故障注入不是为了让 Agent “更难成功”，而是为了回答上线前最关键的问题：它失败时，系统会不会比自动化之前更难收拾？

---

八、第四步：把四象限结果变成运营面板

建议每次评估至少记录以下字段：

字段	用途
Run ID、模型与提示版本	让结果可追溯、可比较
任务契约版本	防止 Oracle 变化后混算结果
Agent 报告状态	区分自报成功、失败、停止和超时
独立状态判定	记录有效成功、无效成功、有效失败、无效失败
状态差异摘要	展示目标变化与意外变化
人工介入次数	计算真实监督成本
恢复时间	衡量非原子失败的运营代价
证据包	保存截图、动作轨迹、日志、数据库差异和审批记录

最终面板不要只放一个绿色成功率，而要同时展示：

• 有效成功率：自动化到底产生了多少价值；
• 原子性：运行结束后的系统状态是否可接受；
• 无效成功率：最容易制造错误信心的比例；
• 无效失败率：失败后需要人工修复的比例；
• 平均恢复时间：每次副作用真实消耗多少运营成本；
• 人工审批和接管率：为了安全运行需要多少监督。

如果一个方案有效成功率提高了 10%，但恢复时间和无效成功率同时翻倍，它未必更适合生产。

---

九、团队可以怎样从小范围开始

第一版不需要建立一个庞大的 Agent 平台。可以选择一个低风险、可重置、有明确持久化结果的内部流程，连续试运行两周。

试点范围

• 1 个隔离测试环境；
• 3—5 个真实高频工作流；
• 每个工作流一份任务契约；
• 至少一个持久化状态验证器；
• 3 个中途失败检查点；
• 禁止生产账号、真实患者或客户数据；
• 所有外部通信和不可逆操作默认关闭。

进入下一阶段的门槛

• 连续运行中没有未监控的持久化变化；
• 所有 Agent 自报成功都能被独立验证；
• 失败能够稳定归类为有效失败或无效失败；
• 清理与恢复过程经过验证，而不是只写在文档里；
• 团队能够量化有效成功率、原子性、人工接管和恢复成本；
• 任一严重副作用都能触发自动停用或降级。

如果连最终状态都无法可靠观察，就不应先讨论提高 Agent 自治等级。

---

十、证据边界：这项研究还不能证明什么

LegacyWorld 是一项有价值的部署前研究，但引用结果时必须保留边界：

• 所有运行发生在隔离虚拟机，不是生产环境验证；
• 原子性只覆盖基准实际监控到的状态，不代表所有外部副作用都被发现；
• 每个模型—任务—提示组合只有一条纳入统计的轨迹，不能推导稳定概率；
• 专家核对的是任务现实性和契约设计，不是独立认证模型输出；
• 录像实验只研究从一条黄金路径重建流程，不等于从演示自动学习完整业务规则；
• 论文中的六个 Agent 和具体版本会变化，方法比单次分数更值得复用。

因此，这篇文章给出的任务契约、故障注入和运营面板，是基于论文机制做出的质量工程落地方案，不是论文已经完成的生产认证。

---

写在最后

GUI Agent 最危险的结果，不一定是页面报错或任务超时，而是它留下了真实副作用，同时给出一段足够自信的成功说明。

测试工程师需要把验收标准从“它有没有把流程走完”升级为三个问题：

• 它是否完成了真正有用的业务目标？
• 无论成功还是失败，最终状态是否仍然有效？
• 如果留下副作用，我们能否发现、停止、恢复和追责？

成功必须由目标状态证明，失败必须由无副作用证明。Agent 的自我报告，只是证据之一，不是最终判决。

当任务契约、独立验证器、故障注入和四象限指标都建立起来，GUI Agent 才从一场会点击按钮的演示，进入可以被质量工程认真评估的自动化系统。

---

参考资料

• LegacyWorld：Atomicity-Aware Evaluation of GUI Agents for Legacy Workflows
• LegacyWorld 论文全文
• LegacyWorld 复现实验仓库
• legacy-use：面向旧系统 GUI 工作流的 Computer Use Agent 框架

说明：论文已被 ICSME 2026 Industry Track 接收。本文中的试点方法、故障注入设计和运营指标，是在论文证据基础上的质量工程推论，仍需在具体业务系统中验证。