一句话总结

Salesforce AI Research 提出 StateAct，一种代码优先的多 Agent 框架，为主 Agent 提供直接的程序状态访问，仅将必要的视觉任务委托给 GUI 子 Agent，并通过完成守门机制验证结果，将 Claude Opus 4.8 在 OSWorld 2.0 上的二元成功率从 $20.6\%$20.6% 提升至 $26.9\%$26.9%，部分成功率从 $54.8\%$54.8% 提升至 $61.6\%$61.6%，且成本约为基于屏幕截图的对应方案的 $9$9 分之一，而去掉 GUI 子 Agent 的纯代码变体仅达到 $45.9\%$45.9% 的部分成功率，从而将瓶颈从感知重新聚焦到推理上。

核心贡献

• 本文提出 StateAct，一种代码优先的多 Agent 框架，使主 Agent 立足于程序状态，并将视觉交互委托给专用的 GUI 子 Agent，仅用于少数需要视觉交互的子目标——在 108 个任务中仅有 28 个需要此类交互，且仅 1.1% 的主 Agent 步骤被委托。
• 本文引入独立的完成守门机制，直接检查已保存的交付物是否存在结构性错误（如缺失或指向错误的输出），提供了一种无需叙述的通用验证机制，无需针对单个任务进行工程化设计即可适用于所有任务。
• 在 OSWorld 2.0 上，StateAct 在 Claude Opus 4.8 上将二元成功率从 20.6% 提升至 26.9%，部分成功率从 54.8% 提升至 61.6%，且成本约为原来的 9 分之一；消融实验和诊断表明，改进源于对状态的观察而非 Agent 深度的增加，将主要限制从感知转移到了推理。

引言

当前的计算机使用 Agent 可操作真实的桌面软件，但主要依赖屏幕感知——基于像素进行读取和操作。虽然这对短交互有效，但在长时间跨度任务中，基于像素的观察会变得脆弱：细微的状态差异（如公式与字面单元格值）不可见，微小的误读会在数百步中累积。此外，屏幕截图无法提供可靠信号来确认任务的最终产物是否已正确完成。作者引入 StateAct，将 Agent 循环重新定位为以程序状态作为主要接口，仅在无法通过编程方式访问时使用专用的 GUI 子 Agent。这种基于状态的设计包含一个直接检查持久化产物的验证守门机制，以及一种在长时间跨度中维持任务聚焦的上下文管理策略。

方法

作者基于计算机程序状态 $s \in S$s∈S 的两个观察通道确立了一个基本原理。像素通道是一个渲染映射 $o_{\mathrm{pix}} = f_{\mathrm{render}}(s)$opix​=frender​(s)，而状态通道是一个查询映射 $o_{\mathrm{state}} = g(s)$ostate​=g(s)（例如 shell 命令、DOM 序列化）。渲染是有损且非单射的，意味着 $f_{\mathrm{render}}^{-1}$frender−1​ 不存在，不同的状态可能产生无法区分的屏幕截图。在长时间跨度中，这种每步有损的代理会累积状态漂移。反之，状态通道在任务所接触的子状态上本质上是可逆的。此外，桌面任务的交付物是对程序状态的更改，而非一张屏幕截图。对于依赖非渲染内容的任务，成功断言 $G(s)$G(s) 无法仅从 $f_{\mathrm{render}}(s)$frender​(s) 中恢复。

如下图所示，像素路径依赖渲染后的间接观察和基于坐标的交互，而状态路径则直接针对并查询确切的产物。

为将此原理付诸实践，作者设计了 StateAct，包含三个核心组件：一个通过代码对程序状态进行操作的主 Agent，一个通过重新读取真实产物来验证完成情况的独立完成守门，以及一种在数百步中维持运行的上下文管理机制。

系统整体设计参见框架图。

主 Agent 的动作空间由代码和结构化操作组成，例如持久化 bash、文件编辑器和计划清单。主 Agent 不暴露实时屏幕操控（如鼠标或键盘）。Agent 通过利用关于应用程序如何在磁盘上存储状态的先验知识以及主动探测（例如 find、grep、sqlite3）来定位状态的存储位置，从而完成状态发现。当某个子目标属于不可化约的视觉操作时（例如拖拽 Canvas 元素或关闭无法脚本化的模态框），主 Agent 会将其委托给专用的 GUI 子 Agent。浏览器相关操作由 Web 子 Agent 处理，该子 Agent 进行导航、执行 JavaScript 并将 DOM 序列化为 Markdown。这一委托规则确保主 Agent 保持以状态为基础，GUI 的使用仅占总步骤的极小部分。

当主 Agent 调用完成时，一个独立的完成守门将被启动。其上下文中仅包含逐字任务说明和机器访问权限，编辑器修改被阻断。它永远不会看到主 Agent 的消息历史或计划。这一设计提供了四个关键特性：叙述盲视、状态基础（检查确切的持久化产物）、反捕获（拒绝仅在辅助文件中找到的证据）以及允许有界修正（最多三轮重试）。

下图展示了一个经过压缩的守门记录，守门捕捉到一个结构性缺陷：持久化的存储与 Agent 声称的内容不符。

为处理长时间序列而不使上下文溢出，作者采用了三种机制。第一，全新上下文专家在各自的上下文窗口中运行委托任务，并返回简洁的报告。第二，自动压缩在接近上下文限制时将最旧的前缀进行摘要并剥离图像。第三，一个持久化在消息历史之外的外部计划清单在每一轮中被重新注入，以锚定多部分任务。

下图展示了三条成功轨迹，分别展示了状态优先的动作、GUI 委托以及守门重试。

实验

StateAct 在一个长时间跨度 GUI 基准上使用强大的语言模型主干进行评估。将典型的计算机使用 Agent 替换为基于状态的执行方式，在提高准确率的同时将 token 成本降低了一个数量级，这主要由基于状态而非屏幕进行操作所驱动，完成守门和上下文管理则提供了额外的增益。失败分析表明，基于状态的代码消除了感知错误，守门能捕捉到结构性缺陷，但主要的残留错误是推理失败，这是提示级验证器无法纠正的，揭示了价值验证的天花板。消融实验证实平面委托已足够，并且一个紧凑的专家模型可以处理较短任务中罕见的 GUI 交互，但最困难的长时间跨度桌面任务仍然受益于前沿的 GUI 子 Agent。

在 OSWorld 2.0 基准上，StateAct 状态基础框架将 Claude Opus 4.8 的二元成功率从 20.6% 提升至 26.9%，平均部分成功率从 54.8% 提升至 61.6%，超越了所有先前公开的系统。这一提升伴随着单任务成本约九倍的降低，使 StateAct 成为性能最高且成本效益最好的方案。与同一模型使用基于像素的 Agent 框架相比，StateAct 在二元成功率上带来了 6.3 个百分点的绝对提升，在部分成功率上带来了 6.8 个百分点的提升。凭借 61.6% 的平均部分成功率和 26.9% 的二元成功率，StateAct 以超过 12 个部分百分点的优势超越了之前最佳的公开系统，而每任务成本仅为约 $7.80$7.80。

StateAct 平均每个任务进行 155 轮模型调用，明显少于其他一些模型如 MiniMax M3（327），但多于基础 Opus 4.8（103）。轮数计数因任务能力的不同而显著变化，在高循环任务中达到峰值，在菜单编辑任务中下降，这反映了系统仅在需要视觉回退时才依赖子 Agent 的特性。StateAct（155 轮）比 Opus 4.8（103）和 GPT-5.5（95）使用更多的轮数，但远少于 Sonnet-4.6（253）、GLM-5V（314）和 MiniMax M3（327）。StateAct 的轮数在高循环任务中达到 282 的峰值，在菜单编辑任务中降至 136，显示出在结构化交互上的效率。主 Agent 贡献了 57 轮，而子 Agent 委托增加了 98 轮内部轮数，因此大部分轮数来自 GUI 交互而非主 Agent 推理。

组件消融显示，完整的 StateAct 系统达到 26.9% 二元成功率和 61.6% 部分成功率。GUI 子 Agent 是最关键的组件：移除它会导致两项指标的最大降幅，部分得分下降超过 10 个百分点。完成守门和计划组件也有贡献，但完成守门仅限于结构性检查，会遗漏大多数价值错误。移除 GUI 子 Agent（—act）将部分得分从 61.6 降至 51.3，二元得分从 26.9 降至 18.5，这是所有消融实验中降幅最大的。禁用完成守门（—verify）将二元得分从 26.9 降至 23.1；分析显示，守门仅在 76 个到达任务中正确拒绝了 8 个，错误放行了 68 个，因为它无法捕获价值错误。关闭计划组件（—sustain）产生的二元得分为 21.3，比无完成守门的设置更差，表明持续推理在结构性验证之外发挥了实质作用。

一个仅使用 bash 而不包含 GUI、子 Agent 或完成守门的裸 Agent 取得的部分成功率低于参考系统，表明仅有代码动作是不够的。基于状态的动作（StateAct）提升了二元和部分得分，其优势主要体现在长时间跨度任务上：在一个短时间跨度基准上性能与参考系统持平，而在更弱模型上，状态基础带来了小幅提升。纯 bash 配置达到 45.9% 的部分成功率，低于参考系统的 54.8%，表明框架在原始代码动作之外至关重要。在 Claude Sonnet 4.6 上，状态基础将二元成功率从 8.3% 提升至 11.1%，显示出即便对较弱的主干也有收益。在短时间跨度的 OSWorld-Verified 上，StateAct 和参考系统取得相似的二元得分（78.4% vs 77.3%），确认基础收益集中在长时间跨度任务上。

完成守门几乎正确通过了所有二元成功任务，但也通过了绝大多数非完美任务，因为它仅检查结构性属性。在到达它的非完美任务中，它仅正确拒绝了很小一部分，导致其因无法检测价值或推理错误而产生较高的错误率。在 79 个非完美任务中，守门错误放行了 68 个，正确拒绝了 8 个；有 3 个任务从未调用完成，因此未被守门评估。守门在到达它的非完美任务上的错误率约为 90%，反映出仅进行结构验证的天花板。在 29 个二元成功任务中，守门通过了 28 个，失败了 1 个，显示出对结构正确的成功完成具有较高的召回率。

在 OSWorld 2.0 基准上，状态基础框架 StateAct 大幅提升了 Claude Opus 4.8 的二元和部分成功率，同时将每任务成本降低至约九分之一，超越了所有先前公开的系统。消融实验表明，GUI 子 Agent 是最关键的组件，而完成守门仅能捕获结构性错误并遗漏价值错误，计划模块在验证之外发挥了有意义的贡献。状态基础的优势主要体现在长时间跨度任务上，系统通过将 GUI 交互委托给子 Agent 来保持高效，这些子 Agent 占据了模型轮数适度增加的大部分。