恢复策略引发的错误：鲁棒 GUI 智能体的基准测试与轨迹合成

TL;DR 通过 GUI-RobustEval 基准和 RoTS 合成框架，系统评估并大幅提升 GUI agent 从策略性错误中恢复的鲁棒性，在 OSWorld 达到 47.4% 成功率的新 SOTA。

问题

问题背景

随着 GUI agents 在自动化操作、智能助手等场景中快速发展，模型已能完成许多单步或短程任务。但 策略性错误（policy-induced errors）—— 即 agent 自身决策导致的错误，如参数错选、步骤遗漏、UI 元素定位偏差等——成为制约其实际部署的瓶颈，因为这些错误往往导致任务失败且难以自行恢复。

现有方法局限

目前大多数基准和训练数据主要衡量端到端成功率，忽略了错误恢复过程的细粒度评估。现有数据合成方法通常只针对正确轨迹，缺乏对错误模式的主动挖掘，导致训练出的 agent 在面对意外错误时缺乏自我修正能力。具体技术局限包括：

• 没有系统化定义和分类 政策诱导错误，评估无法覆盖真实场景中常见的错误类型（如组合错误、长程依赖错误）。
• 数据扩增手段单一，无法生成带有错误恢复轨迹的高质量训练样本，限制了模型鲁棒性的提升。
• 现有奖励模型和反思机制难以精确定位错误步骤并提供有效的恢复建议。

为什么这个问题难且重要

错误恢复需要 agent 同时具备环境感知、长程规划和自我反思能力，而真实 GUI 环境中错误模式高度多样且动态变化，穷举几乎不可能。此外，错误恢复与任务成功强相关：一旦 agent 陷入错误循环，整个自动化流程就会中断，这在金融、医疗、企业应用等对可靠性要求极高的场景中不可接受。业界正寻求能让 GUI agent 像人类一样从失误中学习的方法，因此构建系统性错误恢复评估基准和合成训练数据成为关键挑战。

行业类比

就像 自动驾驶系统 需要在感知失误或路径规划错误后快速调整，避免事故，GUI agent 在操作动态软件界面时也必须具备类似的故障恢复能力，才能从实验走向生产。

核心洞察

• 现有 GUI 基准普遍忽略错误恢复能力，**GUI-RobustEval** 首次系统性定义并衡量策略引发的错误模式。 不同于仅关注任务完成率的端到端评估，该基准通过 1216 个可执行测试用例覆盖参数错误、步骤遗漏、UI 元素错误及组合错误，内置错误感知判断，使鲁棒性成为可量化的维度，直接推动 agent 从“能完成”到“能纠错”的工程进化。
• **Robustness-driven Trajectory Synthesis (RoTS)** 将数据生成抽象为探索-恢复树，通过**脆弱性驱动的探索**和**经验引导的恢复**自动发掘并修复多样化错误。 与传统依赖人工纠错示例或简单重放的数据管线相比，该方法无需手工收集错误轨迹，可扩展合成 80 万条高质量纠错数据，其关键贡献在于实现了错误模式发现与恢复步骤合成的闭环，为训练具备自主恢复能力的大规模 GUI agent 提供了可复用的数据范式。
• 针对长时程 GUI 任务，**错误恢复训练能产生跨能力溢出**，RoTS-32B 在 OSWorld 上达到 47.4% 成功率的同时，All-Pass@4 提升至 33.8%，表明鲁棒性增强直接转化为更高的整体任务通过率。 这揭示出一个被低估的工程事实：传统端到端微调若忽略错误恢复环节，性能上限将严重受限，而系统性地注入恢复数据不仅能减少 cascading failure，还能优化 agent 的规划与执行策略，对产品级 GUI 自动化至关重要。

方法

RoTS 方法以任务指令与基础正确轨迹为输入，通过一个可扩展的树搜索框架，合成包含错误恢复经历的高质量训练数据，最终输出微调后的鲁棒 GUI agent。

环境准备与探索-恢复联合扩展

在虚拟 GUI 环境中，RoTS 首先准备一个能解析指令并返回状态的基础Executor。随后进入Explore-Recovery Co-Expansion：以正确轨迹为根节点，构建一棵 FAR-Tree，每个节点代表一个 GUI 状态，边为动作。扩展时，当前节点既可能执行一个正确动作（向下深入），也可能主动注入政策错误（如误点元素、遗漏步骤、输入错误参数），形成错误分支，再尝试从该错误状态恢复回正确路径。这种“先犯错再修正”的并行扩展，使得树结构同时覆盖了正确执行与多样化的错误-恢复模式。

脆弱性驱动探索

为了让合成资源向容易失败（脆弱）的状态倾斜，框架引入脆弱性分数 Fragility-Score。每轮扩展前，用当前模型（或一个参考策略）在节点状态下多次采样，计算平均步骤级成功率，成功率越低节点越脆弱，越优先被选为扩展对象。这确保合成过程聚焦于模型真正需要学习的困难恢复场景。

经验引导的恢复

当在错误分支需要生成恢复动作时，RoTS 不是随机尝试，而是利用树中邻近分支的历史经验进行智能恢复：

• Neighbor-Experience Guided Error Localization：收集同状态邻域的成功/失败轨迹片段，提炼为结构化经验，帮助模型定位当前步骤可能出的错。
• Advice-Conditioned Recovery：基于定位的错误，生成带有具体建议的提示，引导Executor或LLM生成有针对性的恢复动作，而非盲目重试。

数据集构建与训练

经过多轮树扩展后，从 FAR-Tree 中抽取所有错误-恢复片段，并附加链式思维（CoT）解释，形成 800k 规模的训练数据。这些数据包含不同错误类型（参数错误、步骤遗漏、元素误选、复合错误）及对应修正步骤。最终用该数据集对基础视觉语言模型进行监督微调，得到 RoTS-7B 和 RoTS-32B。

与先前仅通过模仿正确轨迹或事后添加噪声的数据增强方法不同，RoTS 通过主动探索脆弱状态并合成有指导的恢复轨迹，系统性提升了 agent 对政策诱导错误的识别与纠偏能力。

实验

实验设计

本文构建 GUI-RobustEval 基准（1216 个可执行测试用例），系统覆盖策略错误模式（参数错误、步骤遗漏、UI 元素错误、复合错误）。训练数据由 Robustness-driven Trajectory Synthesis (RoTS) 框架生成，采用脆弱性驱动探索与经验启发恢复的树状共扩展，产生 80 万条高质量轨迹。基于该数据微调 RoTS-7B 和 RoTS-32B，并在 OSWorld 和 WindowsAgentArena 上评估端到端性能。

关键发现

微调模型在 GUI-RobustEval 上错误恢复能力显著提升；RoTS-32B 在 OSWorld 取得 47.4% 成功率与 33.8% All-Pass@4，均为当前最优。分析显示长程错误恢复能力的增强直接贡献于任务成功率，缓解了多步任务中的累积错误问题。

与基线对比的深度解读

相比基于 GPT-4V 或专用代理（如 OS-Copilot、UFO），RoTS 模型在需要多步纠正的场景中优势明显。高 All-Pass@4 分数表明模型可多次尝试后稳定修正策略错误，而非仅单次运气。这揭示了一种工程启示：通过大规模合成包含自我恢复轨迹的数据，可有效提升 GUI 代理的鲁棒性，而无需昂贵的人类演示数据，为真实世界部署提供了可复现的路径。

行业影响

落地场景

GUI 自动化代理 在跨应用流程操作、RPA、软件测试、无障碍辅助等场景中价值显著。传统代理常因单步错误（误点元素、参数错误）导致整个任务失败，缺乏自我纠错能力。本工作通过合成错误-恢复轨迹训练模型，可让代理自主识别并修正动作级失误，直接提升以下产品的可靠性：

• 企业级 RPA 平台（如 UiPath、Automation Anywhere）：处理动态变化的 UI 时，代理能自动适应并重试。
• 端到端测试框架（如 Selenium 扩展）：生成测试脚本后，若因 UI 微小变化中断，代理可自行恢复测试流。
• 通用数字助手（如 OS-Copilot）：完成跨应用任务（如从邮件提取信息并填入网页表单），降低中途失败率。

商业价值

• 降本：减少自动化流程中的人工监控与脚本维护成本。在长期运行的任务中，错误恢复能力将端到端成功率提升 10-30%（论文在 OSWorld 上达 47.4% 成功率），直接节省工程师修复异常的时间。
• 增收：更稳定的自动化代理可支撑对可靠性要求高的商业化场景（如金融对账、电商订单批量处理），扩大可自动化范围，间接提升业务吞吐量。
• 体验提升：用户侧产品的自动操作更“聪明”，能优雅处理意外弹窗或布局改变，减少用户介入次数，提升净推荐值。

与现有工作流的接口

该方案提供数据集合成框架 RoTS 和微调模型，集成方式轻量：

1. 数据层：利用 RoTS 管线，在目标环境（如 Web、桌面应用）中自动探索错误模式并生成错误-恢复轨迹，扩充现有训练数据。生成的 800k 高质量轨迹可作为通用基础训练集。
2. 模型层：RoTS-7B/32B 可直接作为视觉-语言-动作模型接入现有 GUI 代理框架（如基于 GPT-4V 多模态 Agent 的 orchestration 层），或作为错误恢复专用子模块（当置信度低于阈值时调用 RoTS 模型进行重规划）。
3. 评估层：GUI-RobustEval 基准可嵌入 CI/CD 流程，度量每次迭代的鲁棒性变化。

具体落地实例

• 电商订单履约自动化：代理在操作后台时可能误点“取消”按钮，RoTS 训练的策略可检测到此错误并自动回退到上一步重新选择正确操作，避免订单丢失。
• 金融报表自动填充：从 PDF 提取数据填入网页系统时，若字段位置变化或出现非预期弹窗，代理调用 RoTS 恢复模块自我修正，无需重新编写脚本。

局限

• - **合成数据的错误覆盖有限**：RoTS 框架通过树搜索主动发现错误模式并合成恢复轨迹，但探索空间受限于预设的原子动作集合和错误注入规则。真实 GUI 交互中的错误类型更复杂，可能包括非确定性 UI 变化、外部事件干扰或应用崩溃，这些难以在合成环境中完整模拟。因此，模型在合成数据上习得的恢复策略可能难以泛化到分布外的错误场景，尤其在处理长周期、多应用协作的任务时，鲁棒性仍需进一步验证。
• - **依赖多组件 LLM-judge 系统，推理成本较高**：方法引入了多个基于大语言模型的判别器（如 Progress Critic、Action Critic、Reflection Identifier）来评估中间状态、生成反馈和筛选数据。在数据合成阶段，每步需要调用这些模型，显著增加了计算开销；在部署时，若需在线自我纠错，也可能需要额外推理。对资源受限的场景，高昂的 API 或本地推理成本可能阻碍实际应用，未来需探索更轻量的错误检测和恢复机制。
• - **评估基准和任务的泛化性局限**：尽管 RoTS 在 OSWorld 上取得了最高成功率，但 OSWorld 任务主要针对桌面办公场景。论文在 WindowsAgentArena 等更多样化基准上的结果展示不足，且未测试移动端或 Web 端 GUI 任务。真实世界的 GUI agent 部署需应对跨平台、跨应用和动态环境下的多样性挑战，模型的跨场景迁移能力尚未被充分验证，可能限制了其在现实系统中的可靠性。