StateAct: 程序状态优先于像素，用于长周期计算机使用代理

TL;DR StateAct 提出以代码直接操作程序状态为核心，仅在必要时调用 GUI 子代理，将计算机使用智能体的瓶颈从感知转向推理，在 OSWorld 2.0 上以更低成本提升成功率。

问题

问题背景

计算机使用代理 (computer-use agents) 正逐渐成为自动化办公、RPA 与智能助手的关键技术。当前焦点在于让代理在真实的桌面环境中完成跨应用、多步骤的长周期任务，如处理表格、管理文件、发送邮件等。

现有方法及其局限

主流方案依赖屏幕感知 (screen perception)：通过截图+点击的方式操作软件，并不断优化视觉模型来提升像素级理解能力。但这一范式存在根本性瓶颈：

• 信息损失：截图只是底层程序状态（DOM、文件系统、应用后端）的有损渲染，相同像素可能对应不同状态，关键结构信息丢失。
• 交互低效：视觉代理必须通过反复截屏→识别→点击来逐步探索，长任务中步骤数爆炸，且感知错误会逐级放大。
• 验证困难：纯视觉很难精确判断任务是否真正完成（例如文件是否保存到正确路径、数据是否缺失）。

技术挑战与重要性

真实桌面环境的状态空间巨大且动态变化，代理需在数百步交互中维持任务上下文，同时应对不确定性。StateAct 论文指出，将动作、验证、记忆全部锚定在可精确访问的程序状态 (program state) 上，将瓶颈从感知转向推理，是突破长周期任务成功率的关键。该问题难度在于：如何让代理自动发现可用的状态接口、何时必须回退到 GUI 操作、以及如何通过状态实现可靠的最终验证。业界高度关注此类技术，因为一旦成熟，可极大提升企业级流程自动化的可靠性和经济性。

行业类比启示

这类似于自动驾驶从纯视觉方案进化到融合高精地图与车辆内部状态 (CAN 总线)，通过获取底层系统信号而非仅依赖外部感官，显著提升决策的确定性和长程规划能力。

核心洞察

• **状态接地 (state-grounding) 将 Agent 的设计重心从感知移向推理**：传统 Computer-Use Agent 严重依赖截图理解界面，但像素只是程序状态的降级呈现，不同状态可能产生相同像素，且感知噪声会累积。StateAct 提出让主 Agent 直接通过代码读写程序状态（如文件、DOM），仅在极少数需要 GUI 交互的子目标才调用截图子 Agent。这一区分使行动、验证和记忆都锚定在结构化状态上，将失败的主因从「看不清」转变为「想不清」，即瓶颈从感知转移到推理。与仅提升视觉模型的路线相比，状态接地更根本地改变了 Agent 的能力边界，且实验表明纯代码变体（无 GUI）表现甚至不如纯截图基线，说明两种通道的混合设计才是关键。
• **委派子 Agent 与独立状态验证构成长时程任务的稳健闭环**：StateAct 为防止上下文爆炸，主 Agent 将子目标委派给拥有全新上下文的新子 Agent 执行，自身保持全局规划焦点。同时，独立的「完成闸门」基于程序状态对保存结果进行结构验证（如文件缺失、路径错误等），而不依赖视觉检查。这种设计使得 Agent 能够处理数百步的长时程任务，并在 OSWorld 2.0 上将 Claude Opus 4.8 的二元成功率提升 6.3 个百分点，成本降至 ~1/9。其中验证环节尤为重要，失效分析显示它避免了大部分结构错误，但最终仍受限于验证规则覆盖——这指出了未来通过状态增强验证的方向。

方法

输入与总体架构

StateAct 接收任务指令及对操作系统环境的双通道访问：程序状态（文件系统、应用后端、DOM、内存变量等）与屏幕截图。架构以代码优先的主 agent 为核心，仅当不可避免时才委托给 GUI subagent。

关键模块：Act, Verify, Sustain

• Act on state: 主 agent 通过编写并执行代码（如 Python）直接探查、修改状态，利用state discovery自动梳理环境结构。依据预定义的delegation rule判断子目标是否需要 GUI 操作。在 OSWorld 2.0 的 108 个任务中，仅 28 个任务触发 GUI 介入，且只占主 agent 总步数的 1.1%，显著降低调用成本和延迟。
• Verify on state: 独立的 finish gate 在任务完成后发起程序化检查，核对预期输出路径、文件完整性及结构性失败（缺失、未保存、写错位置），以此替代不可靠的视觉验收。
• Sustain state: 面对数百步的长程任务，主 agent 将子目标委派给全新的子 agent，自身上下文仅保留高层计划，避免中间细节污染，从而维持长期规划的稳定性。

输出与闭环

完成验证后，系统交付可信的任务结果（如文件更改、软件配置），全程由状态驱动的验收标准闭环，而非依赖像素级别的成功判断。

差异点: 与纯粹像素驱动的 GUI agent 不同，StateAct 将动作、验证和记忆同步锚定在程序状态之上，将主瓶颈从感知转移到推理，使长程任务的成功率显著提升、成本大幅降低。

实验

实验设计

在 OSWorld 2.0 长程计算机操控基准上评测 StateAct 多智能体架构。主智能体以 代码直接操作程序状态，仅在必要时调用 GUI 子智能体 执行截图与点击。对比基线包括：

• Screenshot-only：同一 Claude Opus 4.8 模型仅通过视觉感知操作；
• Code-only：完全移除 GUI 子智能体，仅依赖代码。 评估指标为 Binary Success 与 Partial Success，并记录每任务平均成本。消融实验分析组件敏感性及委托深度的影响。

关键发现

• 性能与效率双提升：StateAct 将 Binary Success 从 20.6% 提高到 26.9%，Partial Success 从 54.8% 提升至 61.6%，同时每任务成本降低约 9 倍。
• 混合通道必要性：Code-only 变体 Partial Success 仅 45.9%，低于 screenshot-only 基线的 54.8%，证明完全放弃视觉通道会丢失关键交互能力。
• 瓶颈转移：通过状态感知将行动、验证与记忆锚定在程序状态上，主要瓶颈从感知转向推理——智能体的失败更多源于“它怎么想”而非“它看到什么”。
• 最小化 GUI 介入：108 个任务中仅 28 个触发 GUI 子智能体，主智能体步骤中 GUI 调用仅占 1.1%，代码路径承担了绝大部分操作。

基线对比解读

screenshot-only 方法受限于屏幕渲染的有损性：不同状态可能生成相同像素，而像素噪声和遮挡常导致误判。StateAct 直接读写文件、DOM 等程序状态，避免了视觉解析的歧义，并通过独立的 finish gate 验证器 检测输出缺失、路径错误等结构性故障，纠正了关键错误。然而纯代码模式无法处理必须通过 GUI 完成的步骤（如菜单点击、弹窗确认），导致成功率甚至不如纯视觉基线。StateAct 的动态委托机制在保持以代码为主的低成本路径的同时，精准激活视觉交互，实现了两种通道的优势互补。这一设计思路对构建长程、可靠且经济的计算机操控智能体有直接工程参考价值。

行业影响

落地场景

StateAct 的 状态优先 架构可直接赋能任何依赖 GUI 自动化 的行业场景，尤其适合长周期、多步骤的桌面操作任务。典型应用包括：

• 企业 RPA 与办公自动化：自动处理电子表格、邮件、日历、文件管理，直接操作程序状态（如 DOM、Excel 数据模型）代替像素识别，大幅提升精确度与速度。
• 软件测试自动化：通过代码直接检查应用后端状态，结合 GUI 子代理仅处理必要点击，实现更稳定、低维护的端到端测试。
• 跨应用数据集成：在无 API 的遗留系统间迁移数据，状态代理可直接读写文件、解析结构化后端，避免截图转文字的高错误率。

商业价值

• 显著降本：在 OSWorld 2.0 上，StateAct 将单任务成本降至纯截屏方法的 ∼1/9，因为主要动作通过代码完成，节省了大量视觉 API 调用及 token 消耗。
• 成功率与可靠性提升：二进制成功率从 20.6% 提升至 26.9%，部分成功率从 54.8% 提升至 61.6%，且通过状态验证降低了文件未保存、写入错误路径等结构性失败，减少人工核查与返工。
• 瓶颈转移：将任务瓶颈从感知转向推理，意味着模型能力提升时，收益将更直接地体现在复杂任务上，而非被图像理解的噪音稀释。

与现有产品的工作流接口

StateAct 可作为 多代理框架 中的核心组件，与现有自动化栈集成：

• RPA 平台增强：在 UiPath、Automation Anywhere 等工具中，将高重复性步骤配置为代码优先代理，GUI 代理仅用于异常处理。
• AI 代理编排：可嵌入 LangChain、AutoGen 等框架，主代理通过代码执行器与状态 API 交互，验证器作为最终检查节点。
• CI/CD 管道：独立验证器可直接插入发布流程，自动检查输出文件结构、内容完整性，作为质量关卡。

具体行业用例

1. 金融服务 — 银行对账自动化
   传统 RPA 需截图并 OCR 识别报表数值，易受渲染差异影响。StateAct 直接读取底层数据库或 CSV 文件，用代码比对、汇总，只在需要点击“导出”按钮时调用 GUI 子代理，准确率与速度远超像素方案。
2. 电商平台 — 多店铺库存同步
   当商家需在多个后台系统间同步库存时，StateAct 主代理用脚本操作 DOM 或 API 获取实时库存，验证器确保未遗漏或重复，仅遇图形验证码等场景才交由 GUI 子代理处理，显著降低因截图延迟导致的超卖风险。

局限

• **程序状态可访问性依赖**：StateAct 假设能够直接通过代码访问底层程序状态（文件、应用后端、DOM 等），但在大量真实软件（尤其闭源 SaaS、云服务、移动应用）中，这类接口可能不可用或受安全策略限制，导致方法难以直接迁移。论文未讨论在部分可访达状态下的降级策略。
• **GUI 子代理性能瓶颈**：纯代码变体（无 GUI 子代理）在 OSWorld 2.0 上的部分成功率仅 45.9%，甚至低于纯截图基线（54.8%），说明部分任务不可避免需要视觉交互；当前 GUI 子代理仍依赖截屏点击，若其能力不足（如对动态 UI 元素辨识差），会变成新的短板，而论文未给出优化方向。
• **推理错误难被验证器修正**：验证器只检测结构性失败（缺输出、错路径等），无法纠正语义或逻辑错误；在数百步长程任务中，状态接地虽将瓶颈从感知转向推理，但大模型推理本身的盲区（如误解指令、优先级错位）仍会导致任务失败，而框架未提供在线纠正或反思机制。