← 返回文章归档
2026-07-29 22 分钟阅读 阅读 加载中... 次 访客 加载中... 人

StateAct：把 Computer-Use Agent 的主循环从『看屏幕』换成『读状态』之后

StateAct 让主 agent 默认通过代码读写程序状态（文件、DOM、数据库、shell），只在任务确实需要视觉交互时才委派一个独立 GUI 子代理去点屏幕。同一个 Claude Opus 4.8 后端，在 OSWorld 2.0 上二值成功率从 20.6% 提到 26.9%，成本从每任务约 72 美元降到约 7.8 美元。拆解它的状态锚定原理、无叙述验证门，以及对 APP 自动化测试 oracle 设计的启发。

#GUI Agent#Computer Use#Agent Architecture#Verification#OSWorld

Computer-use agent 这两年最常见的主循环是同一套东西：截一张屏幕，模型看图定位坐标，输出一次点击或输入，再截一张图确认效果，如此循环几十到几百次。这套模板在短任务上问题不大，但放到长程任务里会被放大——本站 7 月 23 日拆过的 OSWorld 2.0 把评测单元从平均 30 步左右的操作序列换成中位 1.6 小时、平均 318 次工具调用的真实工作流之后，即便是 Claude Opus 4.8 这样的顶尖后端，二值成功率也只有 20.6%。问题往往不是模型看不清按钮，而是几百步的截图-点击循环里状态在悄悄漂移：单元格里的公式被渲染成一个数字，隐藏行看不到，滚动到屏幕外的内容直接从上下文里消失。

StateAct（arXiv:2607.22798，Salesforce AI Research）反过来问了一个问题：如果任务真正要改变的是程序状态——一个文件、一条数据库记录、一次 DOM 操作——那为什么要让 agent 先把状态渲染成一张有损的图片，再费力气从图片里猜回状态？论文把这个问题变成一个可检验的原理，围绕它重新设计了主循环、验证机制和长程记忆管理，在同一个 Claude Opus 4.8 后端上把 OSWorld 2.0 的二值成功率从 20.6% 提到 26.9%（部分完成度从 54.8% 提到 61.6%），同时把每任务成本从约 72 美元降到约 7.8 美元，输出 token 从 224K 降到 100K。

目录

  1. 为什么这篇论文值得关注
  2. 背景与问题定义
  3. 核心思路：状态锚定原理
  4. 方法拆解：StateAct 的三个组件
  5. 实验设置与主要结果
  6. 消融实验与失败归因
  7. 对 APP 自动化测试 / Mobile QA 的工程启发
  8. 局限性与点评
  9. 总结
  10. 参考链接

1. 为什么这篇论文值得关注

放在 grounding → 评测真实化 → 混合执行空间这条演进线上看，StateAct 的位置很清楚。过去一年 GUI agent 领域投入最多的方向是让模型「看屏幕看得更准」——UI-TARS、GUI-Actor、UI-AGILE 这类工作在推更好的坐标定位和视觉 grounding；OSWorld 2.0、C-World 这类工作在把评测环境做得更真实。StateAct 站在另一个位置：它不追问「agent 能不能看清这个按钮」，而是追问「这个任务本来就不需要看屏幕吗」。这是目前 GUI+API+CLI+MCP 混合执行这条线里证据链最完整的一篇——它不只是给模型多加几个工具，而是给出一个可以证伪的原则（渲染是有损、不可逆的映射，状态查询在任务触达的子状态上基本可逆），再用一整套实验去检验这个原则的边界在哪里、什么时候会失效。

Figure 1：StateAct 在 Claude Opus 4.8 上取得 26.9% 的二值成功率，是唯一超过公开榜单 21% 前沿线的结果，橙色柱是同一后端在标准 computer-use-agent 框架下的参考基线 20.6%，成本约为其九分之一

它还回答了一个 grounding 阵营很少正面处理的问题：如果 agent 的主循环不依赖屏幕视觉，GUI 视觉模型的能力到底还有多重要？论文用一个替换实验直接给出数字：把最强的 GUI 子代理换成自研的 31B 小模型 SFR-CUA，五个基准里有四个的端到端表现几乎不掉。这个结果值得所有正在为 GUI grounding 模型的规模和成本发愁的团队认真看一眼——后面第 7 节会把这组数字摊开讲。

2. 背景与问题定义

论文里反复对比的「参考基线」，是标准的 computer-use-agent（CUA）框架：主 agent 只能看屏幕截图，通过坐标点击/输入操作，每一步动作后再截图确认。这套框架在 OSWorld 2.0 上跑 Claude Opus 4.8，二值成功率 20.6%，部分完成度 54.8%，输出 token 约 224K，成本约 72 美元一个任务。

问题不在于这套框架不能用，而在于它把「观察」这一步固定死在了渲染通道上。一个桌面任务的交付物通常不是一张截图，而是一份被正确保存的文件、一条被正确写入的数据库记录、一个被正确修改的 DOM 状态。当任务链条拉长到几百步，渲染通道的信息损失会持续累积：一个单元格显示的是渲染后的数字，看不出背后是字面值还是公式；一行数据被滚动到屏幕外，agent 的上下文里就不再有它的痕迹；一次跨页面的状态变化，如果没有截图正好捕捉到，agent 就可能完全错过。OSWorld 2.0 已经在数据上证明了这类长程状态追踪失败普遍存在，StateAct 要做的是回答：如果换一个观察通道，这类失败能不能系统性地减少。

3. 核心思路：状态锚定原理

论文把 agent 观察世界的方式形式化成两条通道。设 s 为程序状态（文件、后端、DOM、数据表）。像素通道是渲染映射 o_pix = f_render(s)，状态通道是查询映射 o_state = g(s)——一次 shell 命令、一次工作簿读取、一次 DOM 序列化。围绕这两条通道，论文给出两个结构性事实。

第一，渲染是有损且不可逆的映射。很多不同的状态会渲染成难以区分甚至完全相同的截图：一个显示的总数可能是字面值也可能是公式，可能被四舍五入，也可能滚动到了屏幕外。形式上 f_render 不是单射，f_render 的逆不存在，再好的感知模型原则上也无法从 o_pix 一般性地还原出 s。而在任务实际触达的子状态范围内，状态通道 g 基本是可逆的。

Figure 3：同一个子目标走两条通道的对比。左侧像素路径靠截图读一个总数、按坐标点击输入，注释里写明显示可能省略公式、隐藏行或精度，且坐标操作依赖当前焦点；右侧状态路径直接用 openpyxl 打开工作簿、读取单元格存储的公式、写回并保存，整个过程精确且可复现

Figure 3 是这条原理最直观的例子：像素路径里 screenshot() 读到的只是「单元格显示 1,240」，这个值可能省略了公式、隐藏行或精度，后续的 click/type 还要依赖坐标和当前焦点是否正确；状态路径里直接 load_workbook 打开文件、c = wb["Sheet1"]["B7"] 定位到目标单元格、读出真实存储的公式、写回、保存，整条链路精确、可查询、可复现。差距在单次操作里看起来不大，但论文强调这种损耗会随着任务长度累积，状态通道的优势随任务长度增长而扩大——这正是长程任务这个场景的核心矛盾。

第二个事实是：任务的交付物是状态本身，不是状态的一张截图。论文用 G(s) 表示状态上的成功谓词，对于交付物依赖非渲染内容（公式、隐藏行、屏幕外数据、后端状态）的任务，不存在一个 G̃ 能满足 G(s) = G̃(f_render(s))，因为渲染在结构上就丢掉了这部分内容——不是加了噪声，是直接不存在于渲染结果里。

论文也明确划了这个原理不适用的边界：当任务目标本身就是一个视觉结果——图片编辑、排版、图表外观、所见即所得输出——渲染出来的画面就是唯一相关的观察对象，状态通道在这类任务上没有任何优势。论文据此把任务分成三类：状态可寻址（存在通向目标产物的代码路径）、混合型（大部分靠状态、一个环节不可避免依赖视觉）、纯渲染型（像素/外观判断）。状态锚定原理预测：前两类会受益，第三类没有优势——这个预测后面在 Table 1 的分能力拆解里能看到印证。

4. 方法拆解：StateAct 的三个组件

Figure 2：StateAct 架构图。主 agent（Claude Opus 4.8，state-first）通过 act/observe 直接读写程序状态（文件、DOM、数据库、shell），verify 交给一个独立的 Finish Gate；Context Manager 负责压缩上下文和维护外部化的任务清单；主 agent 还可以把任务 delegate 给右侧一次性专精子代理（GUI 专家点击屏幕、Web 专家读写 DOM、通用代理处理任意委派子任务），子代理执行结果通过 result 返回，被拒绝的任务通过 retry 通道打回主 agent

StateAct 由三个组件构成：一个通过代码操作程序状态的主 agent、一个通过重新读取真实产物来验证完成度的独立完成门（finish gate）、以及支撑运行几百步不崩的上下文管理机制。

在状态上行动。主 agent 的动作空间是代码和结构化操作：持久化的 bash、一个文件编辑器、一个只读的 view_image（用于查看图片文件）、一个 plan 清单工具、一个 finish 动作和一个 agent 委派工具。主 agent 本身不暴露任何实时屏幕操作（鼠标、键盘）。仅靠代码是不够的——不是每个应用都暴露完整 API 或可访问状态，论文的消融实验显示，只给 bash 的同一个 agent 部分完成度只有 45.9%，低于纯视觉基线的 54.8%。

状态发现依赖两个信号：模型自身对常见桌面应用如何在磁盘上存储状态的先验知识（邮件存储、办公文档格式、浏览器 profile、应用数据库），以及先验不确定时的主动探测（find/ls/grep/sqlite3）。探测只负责定位状态存在的位置，不负责判断目标值是什么。

委派规则很明确：只有当子目标「不可避免地依赖视觉」时才会调用 GUI 子代理——要么通过探测找不到任何文件/后端/DOM 路径通向目标，要么这个效果本身只能表现为一次渲染交互（拖拽画布选区、关闭一个不可脚本化的弹窗、读取一个只存在于屏幕上的值）。实测 GUI 使用率只占主 agent 步骤的 1.1%（108 个任务里有 28 个至少触碰过一次 GUI 子代理），把子代理内部轮次算进去，占总模型轮次约 11%。浏览器工作交给一个专门的 web 子代理，通过导航、执行 JavaScript、把 DOM 序列化成 markdown、按 CSS 选择器点击，同样锚定在结构化状态上而不是截图。

在状态上验证。当主 agent 调用 finish（只有在至少三个非 finish 步骤之后才允许调用）时，一个独立的完成门会被拉起。它的上下文里只有逐字的任务指令和机器访问权限（bash、文件读取、DOM 查询），编辑器写操作被屏蔽。它看不到主 agent 的消息历史、计划或完成理由，也看不到预期值。这带来四个性质：无叙述（narration-blind，只看任务和机器，不看 agent 的自我陈述）、状态锚定（在真实持久化产物里核实结果，而不是依赖 UI）、反捕获（必须独立定位任务指名的真实交付物并在那里核实，仅存在于 agent 自建旁路文件里的证据会被拒绝）、有界纠错（拒绝后主 agent 最多被打回三轮）。

Figure 4：一次完成门验证的浓缩示例。Agent 声称『完成：导出全部 14 门课程』并调用 finish()，完成门实际读取 calendar.ics 发现只有 8 个事件（≠14），判定 FAIL 并把『只保存了 8/14，导入剩余部分后重试』的结果送回给 agent；下方四个图标概括完成门的工作方式：无叙述、读取真实状态、历史被隐藏、最多三轮

这个设计明确对标两类既有工作：一类是 Reflexion、Self-Refine 这样让 agent 反思自己叙述过的轨迹，本质上是自洽性检验；完成门刻意反过来做——一次新鲜、独立、只在终点检查的第三方核实，拒绝阅读 agent 的自我陈述，直接检查持久化的交付物，更接近 actor-critic 里的独立验收测试，而不是自我反思。另一类是 OpenComputer 这种为每个任务手写状态验证器的方案，能做到接近 oracle 级别的数值核对，但代价是每个任务都要单独写验证逻辑；StateAct 的完成门用一个可以套用到全部 108 个任务、零逐任务工程量的 prompt 级检查，换来通用性，代价是在数值正确性上明显更弱——这个代价在第 6 节的 Table 5 里有具体数字。

维持状态。单个 agent 最多跑 200 轮主循环，平均每任务还要发起 4.2 次子代理委派（每次最多 50 轮），朴素的上下文窗口撑不住。三个机制应对这个问题：新鲜上下文的专精子代理（每次委派独立开一个上下文窗口，只带着聚焦的子任务，返回一份精简报告，图片密集或探索性的子工作不会污染主 agent 的状态模型）；自动压缩（接近上下文上限时，在一个助手消息边界处对最旧的前缀做摘要，图片被剥离，同时保留状态事实）；外部化计划（一个持久化在消息历史之外的任务清单，每轮重新注入，能扛过压缩，用来锚定多步骤任务不跑偏）。

5. 实验设置与主要结果

评测在 OSWorld 2.0（108 个长程真实任务）上进行，遵循该基准的协议：报告二值成功率、部分完成度（分数制）、每任务成本（美元）。所有实验使用 Claude Opus 4.8 并开启自适应思考，每次 agent 调用限制 200 轮主 agent 预算。轮次统计上，主 agent 平均每回合约 57 个模型轮次，每次子代理委派再加约 23 个内部轮次（上限 50），一个任务合计约 155 个模型轮次（约 57 主 agent + 约 98 子代理）。

在完全相同的后端上，把标准 computer-use-agent 框架换成 StateAct，二值成功率提升 6.3 个百分点，部分完成度提升 6.8 个百分点，同时把输出 token 从 224K 降到 100K，成本从约 72 美元降到约 7.8 美元一个任务，约九分之一。StateAct（26.9% / 61.6%）是所有已发布系统里表现最好的一条。

Table 1：OSWorld 2.0 十种能力标签上的分能力表现（二值/部分完成度，%），按 StateAct 排序。多项目追踪、流式交互、跨源推理、冲突消歧这几类状态可寻址能力上 StateAct 领先幅度最大；教程跟随、多模态编辑、动态环境、人机协同这几类更依赖视觉交互的能力上领先幅度明显收窄，人机协同一项二值成功率甚至是 0.0

分能力拆解和第 3 节的原理预测方向一致：多项目状态、流式交互、跨源推理、冲突消歧这几类偏状态可寻址的能力上，StateAct 的领先幅度最大（比如流式交互二值成功率 66.7% vs 参考基线没有对应数字，跨源推理 26.1% vs GPT-5.5 的 13.0%）；教程跟随、多模态编辑、动态环境这几类更依赖持续视觉判断的能力上，领先幅度明显收窄。值得单独指出的是人机协同（human-in-the-loop）这一项，StateAct 的二值成功率是 0.0%——论文自己的解释是这类任务需要一个框架从未主动发起的交互轮次，或者一条容错率极低的长视觉链条，StateAct 目前两者都没有覆盖。

在成本-准确率前沿图上，StateAct 的位置更直观：

Figure 6：OSWorld 2.0 上的成本-准确率前沿图。横轴每任务美元成本（对数刻度），左图纵轴二值成功率，右图纵轴部分完成度，StateAct（红色圆圈标注）独自位于左上角，比最强的公开条目 Opus-4.7 高 8.7 个二值百分点、比 GPT-5.5 高 13.9 个百分点，同时成本远低于两者，只有更弱的 MiniMax M3 和 Qwen 系列成本更低

StateAct 在成本和准确率上同时占优，不是拿准确率换成本的权衡：它以约 7.8 美元一个任务的成本，比成本约 33.6 美元的 Opus-4.7 高 8.7 个二值百分点，比成本约 25.5 美元的 GPT-5.5 高 13.9 个百分点，部分完成度比两者都高出 12 个百分点以上。在图上展示的系统里，只有明显更弱的 MiniMax M3 和 Qwen3.7 成本比它更低。

论文还报告了几组补充实验（对应 Table 4，未单独配图）：一个只给 bash、屏蔽 GUI/子代理/完成门的配置，部分完成度只有 45.9%，低于纯视觉参考基线的 54.8%——只靠代码动作、没有完整脚手架是不够的；在 Claude Sonnet 4.6 上套用同一套框架，二值成功率从 8.3% 提到 11.1%，说明状态锚定对较弱的后端同样有帮助（绝对提升幅度更小）；在短程的 OSWorld-Verified 上，StateAct 和参考基线表现相近（78.4% vs 77.3% 二值成功率），和状态锚定的优势集中在长程任务上这一判断一致。

6. 消融实验与失败归因

组件消融（去掉 StateAct 里的一个机制）显示，去掉在状态上行动这一项（重新暴露 GUI、屏蔽 cua）掉分最多——部分完成度从 61.6% 掉到 51.3%，比参考基线的 54.8% 还低；去掉完成门（-verify）掉到 23.1%/57.5%；关掉计划工具（-sustain）掉到 21.3%/58.7%。

Table 3：(a) 组件消融，逐项去掉 StateAct 的一个机制，去掉在状态上行动这一项掉分最多；(b) 委派深度消融，对比扁平委派、worker 递归、嵌套自递归在十种能力上的部分完成度，扁平配置整体不落后于两种更深的调度方案

委派深度消融值得读得仔细一点：递归调度（worker 递归、嵌套自递归）在十个能力维度上的部分完成度普遍不如扁平委派（StateAct 默认方案），但论文自己交代了一个关键限制——递归在 108 个任务里只被触发了 7 次，且从未真正嵌套。这意味着这组数字之间的差异不能被归因于调度深度本身，论文把它定性为「一个设计选择（保持 StateAct 扁平），而不是一个关于层级结构的普适结论」。

Figure 8：79 个未完美完成任务的根因审计。推理错误（38 个，约占一半）进一步拆分为数值错误（13，主要是算术/公式和读取值错误）、选择错误（11，主要是选错选项和读错指令）、几何不精确（9）；验证器相关问题 14 个；歧义指令 4 个；能力/模态瓶颈 18 个（主要是幻灯片、3D/CAD、音频转写等视觉链条问题）

失败归因图是这篇论文最诚实的部分。论文把 79 个未完美完成的任务分成「两类可修复错误 + 一块硬残留」：推理错误（38 个，占比最大）和验证器误判（14 个，完成门错误放行）加起来 52 个，论文认为这些原则上是可修复的；剩下 22 个（约占全部 108 个任务的 20%）要么撞上后端模型跨不过去的模态瓶颈，要么指令本身有歧义；还有 5 个未做进一步归类。推理错误的 38 个又拆成数值算错（13，算术/公式错误 7 个、读取值提取错误 6 个）、选择错了选项（11，选错选项 6 个、误读指令 5 个）、几何处理不精确（9，裁剪/缩放偏差 6 个、CAD 坐标精度 3 个）、漏项（5）；模态瓶颈的 18 个里，视觉链条问题占 8 个（幻灯片/pptx 6 个、GUI/布局 2 个），另有 3D/CAD/医疗影像 4 个、音频转写 3 个、其他感知 3 个。在状态上行动基本消除了感知类失败——用代码「读 B7 单元格」或「列出日历存储」是精确的；完成门针对的是持久化失败——路径错误、没保存、格式不匹配。两者都没有触及占比最大的推理错误，这也是论文自己点出的、当前方法没有解决的部分。

Table 5：完成门运行特征。(a) 门的最终判定与 grader 真实结果的交叉表；(b) 运行速率——正确拒绝占全部拒绝的 88.9%，但正确拒绝占全部到达门的真实失败任务只有 10.5%（8/76），正确通过占真实成功任务的 96.6%

Table 5 把完成门的能力边界量化得很清楚：它做出拒绝判定时，88.9% 的拒绝是正确的（8/9）；但如果看它面对全部 76 个真正到达门、且确实存在缺陷的任务，只有 10.5% 被正确拦下——换句话说，76 个真实有问题的任务里，有 68 个被完成门放行了。它对真正成功的任务判断很准（正确通过率 96.6%，28/29），也确实能可靠抓住结构性缺陷（比如 Figure 4 里 14 个日历事件只存了 8 个这种可以直接核对数量的问题），但对无法独立复算出正确答案的数值错误，几乎没有拦截能力——这恰好对应 Figure 8 里占比最大的推理错误类别。论文自己的结论是：状态锚定把准确率的瓶颈从感知层挪到了推理层，而不是消除了这个瓶颈。

7. 对 APP 自动化测试 / Mobile QA 的工程启发

StateAct 是桌面场景的论文，但它的核心设计——状态优先的执行、动作空间的三分法、无叙述验证——可以直接迁移到 APP 自动化测试和移动端 QA 的框架设计上。

oracle 设计应该优先查状态，而不是查渲染结果。移动端测试长期依赖 UI 截图比对、控件文本读取、OCR 判断执行是否成功，这正是论文里的像素通道，天然有损：一个订单状态可能在页面上显示「处理中」，但后端状态早已变成「已完成」，中间的渲染延迟或缓存会制造假阳性和假阴性。凡是能找到代码路径的场景——订单状态、库存数值、埋点日志、网络请求体、本地数据库、SharedPreferences/UserDefaults——都应该优先通过 API、ADB shell、Instrumentation 或 mock 后端直接核对，只有真正不可绕开的视觉判断（图片渲染是否正确、布局是否错位、WebView 内嵌页面是否加载）才交给屏幕层面的比对。

在把 GUI 操作层换成更贵的模型之前，先做一次替换实验。这是这篇论文对移动端团队最直接的一条参考：

Table 6：五个基准上的表现对比（部分完成度，%）。把 StateAct 里的 GUI 子代理从 Claude Opus 4.8 换成自研的 31B 小模型 SFR-CUA 后，OSWorld-Verified、WindowsAgentArena、AndroidWorld、MobileWorld 四个基准的端到端表现几乎不受影响，唯独在长程程度最高的 OSWorld 2.0 上明显掉分（61.6 降到 43.2）

把 GUI 子代理从 Claude Opus 4.8 换成 SFR-CUA（一个规模小得多、单独跑分也明显更弱的 31B 模型，OSWorld-Verified 上单独跑只有 66.9% vs Claude Opus 4.8 的 80.9%），在 OSWorld-Verified（81.1 vs 81.9）、WindowsAgentArena（51.2 vs 50.6）、AndroidWorld（84.1 vs 81.9）、MobileWorld（68.4 vs 70.1）四个基准上端到端表现几乎没有差别，唯独在长程程度最高的 OSWorld 2.0 上明显掉分（43.2 vs 61.6 部分完成度，18.5% vs 26.9% 二值成功率）。论文的解释是：一旦主 agent 主要靠状态承载任务，视觉子代理只需要处理少量、相对简单的兜底子目标，一个更便宜的模型就够用；只有在最难的长程桌面任务里，视觉子目标本身变难了，才会暴露弱模型的短板。这提示移动端自动化框架在选择屏幕操作层的模型时，先看自己的编排层是不是真的状态优先——如果测试框架已经通过后端/数据库/日志核对大部分断言，屏幕操作层未必需要最贵的多模态模型来驱动每一次点击。

动作空间的三分法可以直接搬进 Appium/UIAutomator/XCUITest/Maestro 框架的设计清单。StateAct 的委派规则是：默认走代码/API，只有在探测不到任何文件/后端/DOM 路径、或者效果本身只能通过渲染交互表达时，才委派给 GUI 子代理。对应到移动端自动化：登录、灌数据、跳转到指定页面，优先用 deeplink、mock 接口、ADB shell 或应用内测试钩子完成，而不是走完整的 UI 点击流程；权限弹窗、WebView 过渡、原生手势这类真正只能通过界面完成的动作，才保留给 UI 层。StateAct 自己的实测比例——只有 1.1% 的主 agent 步骤触碰 GUI、108 个任务里只有 28 个至少用过一次——是一个具体的存在性证明：一条真实的长程工作流里，大多数子目标其实不需要屏幕操作，只是过去的框架默认让它们都走屏幕。

无叙述验证可以直接套用在测试判定环节。做一个独立的通过/失败判定器，只接收任务的原始验收标准和对后端状态/日志/网络抓包的直接访问权限，不读取自动化脚本自己的执行日志或自我报告的执行结果——这能防止判定逻辑被自动化脚本自己的叙述带偏，就像 Reflexion 式的自我反思容易被自己讲述的轨迹说服一样。同时要记住 Table 5 的数字：即便判定器直接查真实状态，对真正存在缺陷的用例，正确拦截率也只有 10.5%，说明断言本身的精细程度（具体的期望值、而不只是「流程有没有跑完」）依然承担了大部分工作，不能指望一个通用判定器替代具体的断言设计。

不要把纯 API/后端测试当成 UI 自动化的替代品。StateAct 的 bash-only 消融（部分完成度 45.9%，低于纯视觉基线 54.8%）说明有些子目标确实不可避免地依赖视觉——对应到移动端就是图片渲染、布局回归、WYSIWYG 这类问题，一套完全跳过界面交互的后端测试体系会系统性地漏掉这类真实存在的视觉缺陷。

8. 局限性与点评

真正贡献：把「渲染通道有损不可逆、状态通道基本可逆」这个原理讲清楚，并且给出了可证伪的预测（状态可寻址和混合型任务受益，纯渲染型任务没有优势），再用 Table 1 的分能力结果去检验这个预测——这比大多数只报总分的架构论文更接近科学方法。无叙述验证门是一个真正落地的架构机制，不只是一个建议，论文给出了它的运行特征数据（Table 5），也明确对比了它和 Reflexion/Self-Refine 式自我反思的区别。GUI 子代理可替代性实验（Table 6）是一个有价值的反直觉结果：一旦主 agent 状态优先，视觉 grounding 模型的质量和端到端任务成功率之间的耦合会明显减弱，这对整个高度依赖「更强 grounding 模型等于更强 agent」这一假设的研究方向是一次值得认真对待的挑战。准确率和成本同时改善、且是在本站已经核实过的 OSWorld 2.0 上取得的结果，量级也不小（+6.3/+6.8 个百分点，约九分之一成本）。

可能被高估的部分：委派深度消融只在 108 个任务里触发了 7 次递归，且从未真正嵌套，这个样本量支撑不起「扁平结构更好」这个结论，论文自己也承认了这一点，但读者容易把 Table 3(b) 的数字误读成对层级化架构的负面证据。完成门的真实拦截能力偏弱——面对到达门的 76 个真实缺陷任务，只正确拦下 10.5%——「-verify」消融只掉 3.8 个百分点二值成功率，容易让人低估这个组件在数值正确性上的实际短板。核心的 +6.3/+6.8 个百分点提升只在 Claude Opus 4.8 一个后端上验证，Sonnet 4.6 上确实有提升（8.3%→11.1%）但幅度小得多，论文没有报告在 GPT-5.5 或其他后端上套用 StateAct 框架的结果，跨后端的泛化性目前证据有限。108 个任务的样本规模决定了置信区间偏宽，这一点在 7 月 23 日 OSWorld 2.0 那篇里已经提过，这里同样适用——Figure 1 里「唯一超过 21% 公开前沿线」这个说法是真实的，但换算成任务数只是几个任务的差距。

可复现/可落地建议：如果要在自己的 agent 框架或测试体系里复用这套方法论，优先复用的是动作空间三分法（状态可寻址默认走代码/API、混合型按需委派、纯渲染型才走视觉）这个设计检查清单，以及无叙述验证门的架构模式（判定逻辑不读执行脚本的自我陈述，只读原始验收标准加真实状态）。在决定要不要为屏幕操作层采购更贵的多模态模型之前，先在自己的场景里跑一次类似 Table 6 的替换实验，量化端到端指标是否真的对视觉模型质量敏感。同时不要指望通用验证器替代具体断言——Table 5 的 10.5% 拦截率是一个提醒，断言设计本身依然是承担大部分正确性保证的地方。

9. 总结

StateAct 做的事情概括起来是一次通道切换：把 agent 默认观察和操作世界的方式从渲染换成状态，只在视觉确实不可替代时才回落到屏幕。这个切换在同一个后端上带来了准确率和成本的同时改善，也把失败原因清楚地挪到了推理层——完成门能可靠抓住结构性缺陷，但对需要独立复算的数值错误基本无能为力。论文最后一句话说得直接：长程 computer use 现在的瓶颈是 agent 怎么想，不是 agent 怎么看。对 GUIAgent 领域而言，这提示下一阶段的重点可能不再是继续堆更强的屏幕感知，而是投入到验证机制的数值正确性、以及推理错误本身的定位和修复上；对 APP 自动化测试而言，它给出的动作空间三分法和无叙述验证模式是可以直接搬进现有框架的工程资产。

10. 参考链接