type
status
date
slug
summary
tags
category
icon
password
一句话判断：StateAct 最有价值的地方，不是“用代码代替点击”这么简单，而是让 Agent 的执行、验收和长程状态都对准同一个对象：文件、数据库、DOM 和应用后端。它明显减少了屏幕操作带来的误差和成本，但最终成功率仍只有 26.9%；看得更准以后，推理错误成了主要障碍。
原始材料
论文来自 Salesforce AI Research，2026 年 7 月 24 日提交。到 7 月 29 日，我在 arXiv 页面、论文正文和 Hugging Face 条目中没有看到官方代码入口，因此下面的实验结果均按作者报告理解，不写成独立复现结果。
为什么今天选它
7 月 28 日的 Agent 候选里，JarvisHub 把画布当作创作 Agent 的共享状态，Multi-Agent Protocol Distillation 研究搜索轨迹蒸馏，Interactive Reward Agent 则用环境状态评估 GUI 任务。StateAct 更值得今天拆，因为它同时碰到了 computer use、harness、状态管理、工具路由、独立验收和长上下文，而且同模型对照、拆解实验与失败审计都比较完整。
它也和最近几次沉淀错开了。前几天研究的是世界模型、上下文记忆和训练时 skill；StateAct 讨论的是运行中的 Agent 到底该观察什么、改什么、凭什么宣布完成。这个问题直接影响真实产品的可靠性与成本。
它在解决什么问题
多数 computer-use Agent 的基本循环是：看截图，判断下一步，移动鼠标或输入文字，再看一张新截图。这种方式把屏幕当成事实来源，可屏幕只是程序状态的一次渲染。
同一个表格总计显示为 1,240，单元格里可能是公式，也可能是手填数字；隐藏行、完整精度和未保存内容也可能不在画面中。对一步任务，这种损失未必致命。连续做上百步时，每次都从不完整画面猜测，误差会不断积累。更麻烦的是，任务最终交付的是保存后的文件或应用状态，不是最后一张截图。论文第 3 节把这一区别称为 state-grounding，也就是“对程序状态落地”。
图 1：论文 Figure 3。左侧通过截图与坐标操作表格，看到的是渲染结果；右侧直接读取工作簿中的公式并保存，拿到的是交付物本身的状态。来源：论文 HTML。
StateAct 的判断很明确：只要目标能通过文件、数据库、DOM 或应用后端表达，就优先走状态通道；确实只能靠视觉完成的步骤，再交给 GUI Agent。
系统如何运作
1. 主 Agent 先找状态，再动手
主 Agent 没有鼠标和键盘控制权。它能用持久 shell、文件编辑器、Python、只读图片查看、计划清单、结束动作和委派工具。面对一个应用，它先判断状态存在哪里；不确定时，就用
find、grep、sqlite3 一类手段探查文件和数据库。论文第 4.1 节特别说明，探查只能定位状态，不能凭空告诉 Agent 正确答案。这个约束改变了默认路线。普通 GUI Agent 往往先尝试点击，失败后才找别的接口；StateAct 先操作真实交付物，屏幕是补充手段。
2. GUI 和浏览器 Agent 是专门工种
遇到拖拽、不可脚本化的弹窗、只存在于画面上的信息，主 Agent 才委派 GUI 子 Agent。论文的 108 个 OSWorld 2.0 任务里，只有 28 个任务调用过它；按主 Agent 步数算，GUI 调用占 1.1%。把子 Agent 内部步骤也算进去，视觉操作约占全部模型轮次的 11%。
网页任务另有浏览器 Agent，直接读 DOM、运行 JavaScript、按 CSS 选择器操作。它仍然遵守“先用结构化状态”的原则，并不是换一个 Agent 继续看截图。
图 2：论文 Figure 2。主 Agent 负责程序状态，GUI、网页和通用子 Agent 只接收聚焦后的子任务；完成前还要经过独立验收。来源：论文架构图。
3. 完成不是一句“做完了”，而是重新检查交付物
主 Agent 调用 finish 后，会启动一个只读的 finish gate。它只看到原始任务和当前机器状态，看不到主 Agent 的聊天记录、计划和完成理由，也不能修改文件。它必须自己找到任务真正要求的交付物，再检查文件是否存在、路径是否正确、内容是否保存、格式是否符合要求。
这套验收有两个值得借鉴的限制。第一，不接受 Agent 自己额外写出的“证明文件”，因为那可能只是自证循环；证据必须来自任务指定的真实交付物。第二，验收失败后最多重做三轮，避免无限反思。论文第 4.2 节称它为 narration-blind，也就是不听执行者讲故事，只看结果。
图 3：论文 Figure 4。Agent 声称已导入 14 个日历事件，finish gate 读取实际存储后发现只有 8 个，于是退回重做。它擅长抓住漏存、错路径和格式错误。来源：论文 Figure 4。
4. 长程状态靠三件朴素的东西维持
每个任务最多允许主 Agent 运行 200 轮，平均还会委派 4.2 次子任务。StateAct 没有把所有轨迹一直留在主上下文里，而是让每个子 Agent 使用新的上下文，只返回简短结果；接近上下文上限时压缩较早内容并移除旧图片；计划清单单独保存，每轮重新注入。论文第 4.3 节给出的这三项机制并不新奇，却把“任务事实”和“过程噪声”分开了。
实验结果应该怎么看
论文在 OSWorld 2.0 的 108 个长程桌面任务上评测。使用同一个 Claude Opus 4.8 时，参考 GUI harness 的完全成功率是 20.6%，StateAct 是 26.9%；部分成功分从 54.8% 提升到 61.6%。平均输出 token 从 224K 降到 100K，作者按当时价格估算的单任务成本从约 72 美元降到 7.8 美元，约为原来的九分之一。论文实验部分给出了同模型对照。
图 4：论文 Figure 6。横轴是单任务成本，纵轴分别是完全成功率和部分得分。StateAct 的点位同时向“更便宜”和“更准确”移动。所有数字来自作者汇总的公开轨迹与自家运行结果。来源：论文 Figure 6。
最能说明问题的不是总分，而是拆解实验：
- 拿掉 state-first 执行，部分分从 61.6% 降到 51.3%，甚至低于原始 GUI harness 的 54.8%；
- 拿掉 finish gate，部分分降到 57.5%；
- 拿掉计划与压缩，部分分降到 58.7%；
- 只留 shell、不用 GUI 子 Agent、委派和验收，部分分只有 45.9%。
这些结果说明，直接操作状态是最大贡献，但“全用代码”并不成立。视觉兜底、独立验收和长程管理合在一起才有效。另一个有意思的结果是，扁平委派的部分分为 61.6%，两种递归版本只有 57.6% 和 57.9%；递归分支仅在 108 个任务中的 7 个被触发，而且没有真正嵌套。论文据此支持“这套任务先保持扁平”，没有把它夸成多层 Agent 永远无用。
短任务上的优势也很小。OSWorld-Verified 中，StateAct 与参考系统的完全成功率是 78.4% 对 77.3%。这和论文的主张相符：状态通道主要在长链任务中减少累积误差，不是任何 GUI 任务都能吃到同样收益。
真正的新意在哪里
用代码作为 Agent 动作、把 API 和 GUI 混合、增加独立检查器、压缩上下文、委派新子 Agent，这些零件以前都有。StateAct 没有发明它们。
它真正做对的是统一工作对象和默认路由。执行时改真实状态，完成时重读真实状态，长程管理时保留状态事实；视觉操作只处理状态通道确实碰不到的部分。常见混合 Agent 往往把 GUI 与 API 当成两个并列工具，让模型每一步自由选择。StateAct 把状态通道放在主循环里，把 GUI 隔离成少量、明确的例外。
finish gate 的价值也不在“多一个模型来反思”。它故意看不到执行历史，减少被主 Agent 叙述带偏的机会；同时要求重新定位真实交付物，避免 Agent 用自己制造的旁证骗过检查。这里的新意更像系统边界设计，而不是一种新推理算法。
对产品和研发的启发
做真实业务 Agent 时，可以先给每类操作定义“权威状态”是什么。表格任务看工作簿内容，日历任务看事件存储，网页任务看 DOM 与后端返回，只有版式和视觉效果才以渲染结果为准。Agent 不必在每一步都模拟人类操作界面。
完成条件也该写在交付物上。不要用“模型说完成”或“最后一张截图看起来对”作为验收；至少检查路径、保存状态、结构、数量和格式。能写确定性检查的地方就别交给同一个模型再猜一遍。
执行者与验收者应隔离上下文。验收者只拿任务和结果，读权限够用就不要给写权限。即使它查不出所有错误，也能以较低成本拦住一批漏存、错路径和格式问题。
长任务的计划要放在消息历史之外。子任务用短上下文执行，返回结论和证据；图片、试错记录和临时日志不必长期占据主 Agent 的注意力。这里的重点不是压缩得多聪明，而是别把计划和过程垃圾混在一起。
风险、局限和尚未验证的问题
StateAct 把准确性墙从感知推向了推理，却没有穿过去。108 个任务中只有 29 个完全成功，79 个仍不完美。finish gate 对 76 个已进入验收但最终不完美的任务，只正确拒绝了 8 个，却放过了 68 个，漏过率约 90%。原因不是它相信了主 Agent 的叙述，而是两者可能用同一种方式理解错了原始材料。没有标准答案时，通用检查器擅长结构，难以判断数值是否真的正确。
图 5：论文 Figure 8。79 个未完全成功任务中，38 个主要失败原因是推理错误；另有验收薄弱、视觉能力不足和指令歧义。分类来自作者人工审计，不是自动标注。来源：论文 Figure 8。
状态通道也有清楚的边界。图像编辑、版式、CAD、拖拽和只存在于画面的信息，本来就需要视觉判断。论文中 human-in-the-loop 类任务的完全成功率仍是 0%，多模态编辑也明显弱于状态可查询的任务。把 GUI 降为例外，不等于视觉能力可以不要。
直接读写文件、数据库和应用后端会扩大权限与安全风险。一个被诱导的 Agent 不只是点错按钮，还可能批量修改真实数据。论文主要评估完成率，没有系统研究权限隔离、审计、恶意输入、回滚和并发写入。
证据范围也要收紧。主结果依赖 OSWorld 2.0 的 108 个任务和 Claude Opus 4.8；较弱的 Sonnet 4.6 上，部分分只从 41.5% 变成 42.0%。成本数字还会随模型定价与缓存策略变化。加上官方代码尚未公开，目前能确认的是论文内部对照完整，不能确认第三方能否按同样成本复现。
今日沉淀
- 先找任务的权威状态，再决定是否需要看屏幕。
- GUI 应该是处理视觉例外的专门工具，不必占据主循环。
- 验收者只看任务和真实交付物，不看执行者的自述。
- 通用 finish gate 能查结构错误，查不了共同理解造成的数值错误。
- 长任务优先外置计划、隔离子任务上下文，再考虑更深的多 Agent 层级。