别再卷截图感知了：StateAct 把长程桌面智能体的瓶颈挪到了「推理」上
论文：StateAct: Program State, before Pixels, for Long-Horizon Computer-Use Agents 链接：https://arxiv.org/abs/2607.22798 作者：Yan Yang, Xiangru Jian, Ziyang Luo, Zirui Zhao, Yutong Dai, Ziji Shi, Hanshu Yan, Jun Hao Liew, Silvio Savarese, Junnan Li（Salesforce AI Research） arXiv ID：2607.22798（cs.SE / cs.CV，2026 年 7 月 24 日 v1）
核心摘要
如果你最近在跑 OSWorld 这类长程桌面智能体基准,大概率会被一个数字卡住:同一颗 Claude Opus 4.8,换成"截图+点击"框架,二值成功率就 20.6%,花了大约 72 美元/任务,还经常在最后一步"自己骗自己"——写完了文件、内存里也告诉自己完成了,评测就是过不去。StateAct(Salesforce AI Research,arXiv:2607.22798)的解法很反直觉:把屏幕"降级"成 fallback,让主智能体直接读写程序状态(文件、DOM、应用后端),再配一个独立、叙述盲(narration-blind)的完成门做持久化验收。同一骨干上,二值成功从 20.6% 拉到 26.9%,部分成功从 54.8% 拉到 61.6%,成本压到约 7.8 美元/任务(约 1/9)。老实讲,这不算模型层面的突破,更多是工程架构层面的清醒——但这个清醒值 6 个点 + 一个数量级的成本下降。
一、从一个我之前的困惑说起
去年我们做类似的桌面 Agent 时,最常听到的吐槽是:"模型都到 Opus 4 了,怎么填个表格都填不对?"
后来排了一通,发现两类失败其实是混在一起的:
- 感知层失败:截图看不清,坐标点歪了,被弹窗挡了。
- 交付失败:操作其实跑完了,但保存路径错了、文件没刷盘、或者保存的是过程文件而不是任务命名文件。Agent 自己信誓旦旦说"done",评测就是 0 分。
这俩问题被包成一个指标,叫做"成功率"。然后大家拼命堆感知——更大的视觉骨干、更细的 Set-of-Mark 标注、更密的截图——但交付那一类失败根本不是感知能解的。
StateAct 这篇论文的作者做了一个有意思的区分:任务交付物是程序状态,不是屏幕。桌面任务的产物是一个持久化的东西(电子表格的某个单元格、邮箱里那封标记过的邮件、某个 .ics 日历文件),屏幕只是它的一帧渲染。同一帧像素可以来自无数个不同的程序状态,反过来同一个程序状态可以渲染出无数种像素。
图 1:OSWorld 2.0 上 8 个系统的二值成功率。StateAct 26.9% 是唯一突破 21% 公开前沿(红色虚线)的参赛,Opus 4.8 同一骨干的截图基线是 20.6%,次强的 Opus-4.7 是 18.2%。
顺着这个思路再往前一步,长程任务的"长"本身就是个放大器:单次有损读图也许无伤大雅,但 100 次有损操作叠加起来,状态漂移能把任务漂到哪去谁也不知道。真正决定长程智能体上限的,不是它看到的,而是它写入的。
二、StateAct 到底干了什么
一句话版:主智能体直接读写文件、DOM、应用后端,屏幕截图只在不可还原的视觉子目标上才被委派给子智能体;主智能体调 finish() 时,一个独立、叙述盲的完成门只检查持久化交付物,不看智能体的话术。
2.1 架构总览
图 2:StateAct 架构图。主智能体(Claude Opus 4.8,state-first)在 Program State(files · DOM · DB · shell · …)上 act/observe;左下是 Context Manager,负责压缩(compact)和持久化计划清单(plan checklist);右下是"一次性"的子智能体(GUI specialist、Web specialist、General agent),主智能体 delegate 后拿回简洁报告;底部 Finish Gate 独立 verify 持久化状态,narration-blind,被拒时让主智能体最多重试 3 轮。
四个关键模块各司其职:
- 主智能体:默认动作空间是 bash、文件编辑、只读 view_image(用于图片文件)、计划清单、finish、智能体委托。不直接暴露鼠标键盘——这听起来很激进,但实际意思是:你能用
openpyxl改 B7,就别click(x=734, y=512)。 - Context Manager:压缩(把最早的对话前缀摘要掉)+ 计划清单(每轮重新注入,跨压缩存活)。
- 一次性子智能体:每次委托在自己的新上下文里跑,返回简短结果。GUI 子智能体处理视觉子目标,Web 子智能体处理浏览器(导航+JS+DOM 序列化+CSS 选择器点击),General agent 兜底任意子任务。
- Finish Gate:每次主智能体调 finish()(且至少 3 个非 finish 步骤后),启动一个独立进程验证。它看不到主智能体的对话历史,只有原始任务指令、机器访问(bash、文件读、DOM 查询),而且编辑器修改被禁用。
2.2 状态优先,不是状态唯一
作者对"哪些任务适合状态优先"做了一个诚实的分类,这是我最喜欢这篇论文的地方:
| 任务类型 | 描述 | 状态锚定能帮上? |
|---|---|---|
| State-addressable | 到目标产物的代码路径存在 | 大幅帮 |
| Hybrid | 主要是状态,有一个不可约的视觉子目标 | 帮 + 委派 GUI |
| Render-only | 像素/外观判断(图像编辑、图表外观、WYSIWYG) | 不帮 |
最后一种是 StateAct 主动承认的盲区——别硬卷。
2.3 像素 vs 状态:一个具体的对比
图 3:左是像素通道——screenshot() 给"cell shows 1,240",但显示可能省略了公式、隐藏了行、或精度被四舍五入,只能 click(x=734, y=512) 然后 type("=SUM(B2:B6)"),完全依赖当前焦点;右是状态通道——openpyxl.load_workbook("r.xlsx")["Sheet1"]["B7"].value 直接读出 stored formula,wb.save("r.xlsx") 持久化。
这个对比说明的不是"代码更好",而是这两种通道根本不是同一类信号。像素通道是有损且非单射的(rendering \(f_{\text{render}}\) 不是 injective,\(f_{\text{render}}^{-1}\) 不存在),所以无论把视觉模型堆到多强,都不可能从一帧像素反推完整的程序状态。状态通道 \(g\) 在多数桌面任务上实际是单射且可逆的(读出公式、隐藏行、DOM 节点属性),agent 能直接编辑 task-defined 的交付物。
三、Finish Gate:把"自吹自擂"从产品里切掉
这一节值得单独说,因为我之前被同一个问题反复咬过——Agent 写完文件就 finish,内存里"觉得"对,评测就是 0 分。
图 4:Finish Gate 真实 transcript。Agent 提交 finish() 时声明 "Done: exported all 14 courses",门只给两个工具:read calendar.ics 和裸任务指令,执行后读到 "→ 8 events (≠14)",立即 FAIL 并把主智能体送回去 "import the rest, retry"。门的四属性:narration-blind(看不到 agent 话术)/ reads state(看持久化文件)/ history withheld(主智能体的编辑器被禁用)/ up to 3 rounds。
四个属性是配套的,拆开任何一个都会出问题:
- 叙述盲:这是和 Reflexion / Self-Refine 的关键区别。后两者让 agent 反思自己的轨迹,本质是用模型自己的话术说服自己,容易出现agreement bias——读到自己的"全部完成"就信了。StateAct 的门直接拒绝阅读 agent 的叙述。
- 状态锚定:验的是任务命名的真实交付物(那个具体的 .ics、那封具体邮件、那个具体 .xlsx 单元格公式),不是 UI。
- 防捕获:不接 agent 自己造的旁路证据(比如 Downloads 里有 14 个 .eml,但任务命名的是 mailbox 里),这是防 agent 在错误地方"自证清白"。
- 有界纠正:最多 3 轮,避免门把 agent 拖进死循环。
作者特别强调,这个门在值上弱但在通用性上强——一个 prompt 适用 108 个任务,零 per-task 验证器工程。代价是它的天花板:对结构失败(路径错、未保存、格式错)有效,对值失败(算错、抄错、漏行)它无从判断。
四、实验:在 OSWorld 2.0 上跑分
4.1 主结果:同一骨干,换架构
OSWorld 2.0(108 个长程桌面任务,平均每任务 100+ 步),骨干统一 Claude Opus 4.8:
| 系统 | 二值成功率(%) | 平均部分成功率(%) | 每任务成本(美元) |
|---|---|---|---|
| StateAct(状态锚定) | 26.9 | 61.6 | ~7.8 |
| Opus 4.8 截图参考基线 | 20.6 | 54.8 | ~72 |
| Opus-4.7(最佳批配置) | 18.2 | 48.9 | ~33.6 |
| GPT-5.5 | 13.0 | 49.5 | ~25.5 |
| Sonnet-4.6 | 8.3 | 41.5 | — |
| MiniMax M3 | 4.6 | 22.3 | <5 |
| Qwen3.7 | 2.8 | 21.5 | <5 |
| GLM-5V | 0.0 | 9.0 | — |
关键数据点:同一颗 Opus 4.8,只换框架不加训练,+6.3 个二值点、+6.8 个部分点,成本压到约 1/9,输出 token 从 224K 砍到 100K。前沿模型是必要的,但不是充分的——这论文最有冲击力的一句话是:你已经在用最强的模型,但你搭的脚手架把它的能力用出了 20%。
4.2 逐能力:StateAct 强在哪里、弱在哪里
图 7:六系统 × 十能力的 mean-partial(左)和 binary(右)。StateAct(红)在 streaming、multi-item state、cross-source reasoning、conflict disambiguation 这些"状态可机器检查"的能力上大幅领先;最弱的两项是 human-in-the-loop(0/43.9%)和 multimodal edit(20/54.2%),前者需要框架从不主动征求的交互轮次,后者是无瑕疵长视觉链。
读这个图有几个判断:
- 强项集中在"机器可读状态" — multi-item state、cross-source、conflict disambiguation、implicit state、streaming 都是"任务交付物能被代码直接打开并核对"的类别。
- 弱项集中在"渲染即交付" — human-in-the-loop(任务要求等真人输入)、multimodal edit(图片/PDF 嵌入)、visual-spatial(画布类操作)都需要像素通道。
- Tutorial 是个反直觉的弱项(13.6/55.3) — 因为 OSWorld 2.0 的 tutorial 任务经常需要按教程做"无意义但必须遵守"的步骤序列,模型会自作聪明跳过。
4.3 成本-精度前沿
图 6:横轴是 USD/任务(log scale),纵轴是二值成功率(左)和 mean partial(右)。StateAct(蓝色圈)位于左上,二值 ~26.9% @ ~\(7.8,mean partial ~61.6% @ ~\)7.8;Opus 4.8 同一骨干的参考实现落在右上(更贵、更差);唯一比它便宜的是 MiniMax M3 和 Qwen3.7,但它们远低于 5% 二值。
把"准确"和"便宜"同时做到位的,基本只有 StateAct。这个象限意义在于:前沿模型的边际成本正在被脚手架吃掉,而不是被模型本身吃掉。
4.4 消融:三个机制各值多少
| 配置 | 二值(%) | 部分(%) | 含义 |
|---|---|---|---|
| 完整 StateAct | 26.9 | 61.6 | — |
| −act(禁 GUI 子智能体) | 18.5 | 51.3 | 最大跌幅,且部分甚至低于参考基线 54.8% |
| −verify(去掉完成门) | 23.1 | 57.5 | −3.8 / −4.1 |
| −sustain(关闭上下文管理) | 21.3 | 58.7 | −5.6 / −2.9 |
一个比较反直觉的发现:禁掉 GUI 子智能体,部分成功率从 61.6% 跌到 51.3%,比"纯截图基线"的 54.8% 还低。意思是:没有 GUI 委派的纯代码动作空间,在长程任务上根本撑不起来。代码不是用来替代 GUI 的,代码是用来替代大部分 GUI 的;该用 GUI 的地方必须能用 GUI,否则反而拖累。
另一个发现:递归深度没意义。主智能体是"扁平委托"还是"工作者自递归"还是"嵌套自递归",平均部分得分分别是 61.6 / 57.6 / 57.9,扁平最好;递归分支仅在 7/108 任务上触发,且从未嵌套。作者把这个数据摆在台面上,我挺欣赏——很多论文会强行把"深度"包装成核心贡献,这里直接说"我们试了,没用"。
4.5 通用性:Sonnet 4.6 也能涨,但短视野不涨
| 骨干 | 参考基线 | StateAct | 备注 |
|---|---|---|---|
| Opus 4.8 | 20.6 / 54.8 | 26.9 / 61.6 | 主实验 |
| Sonnet 4.6 | 8.3 / 41.5 | 11.1 / 42.0 | 二值 +2.8,部分 +0.5 |
| Bash-only(Opus 4.8) | — | 15.7 / 45.9 | 纯 shell,无子智能体、无门,部分还低于参考基线 54.8% |
| OSWorld-Verified(短视野) | 77.3 / 80.9 | 78.4 / 81.9 | 几乎打平,符合"长视野优势"预期 |
"Bash-only 反而不如截图基线"这一行,作者专门拎出来讲:光有"代码动作空间"是不够的,代码 + 委派 + 完成门三件套才构成状态锚定。少任何一件都会让架构摔下去。
Sonnet 4.6 上 +2.8 / +0.5 的结果,说明 StateAct 对中等骨干也有正收益,但不如在 Opus 上那种"显著拉满"的效果——大概率是因为 Sonnet 在状态推理上本身就不如 Opus,门能帮它抓到结构错误但抓不到值错误。
4.6 五个基准的额外验证:子智能体不需要太强的 GUI 模型
作者做了一个非常工程化的实验:把主智能体保留为 Claude Opus 4.8,把 GUI 子智能体从 Claude 的 CUA 模型换成自家 31B 的 SFR-CUA,跑五个基准:
| 模型 | OSWorld-V(短) | OSWorld 2.0(长) | WindowsAgent Arena | Android World | MobileWorld |
|---|---|---|---|---|---|
| Claude Opus 4.8(无 StateAct) | 80.9 | 54.8 | 41.6 | 69.0 | 51.3 |
| SFR-CUA(无 StateAct) | 66.9 | 7.6 | 40.9 | 68.1 | 48.7 |
| StateAct + Claude Opus 4.8 | 81.9 | 61.6 | 50.6 | 81.9 | 70.1 |
| StateAct + SFR-CUA | 81.1 | 43.2 | 51.2 | 84.1 | 68.4 |
四个基准上,把 GUI 子智能体从 Claude 换成弱得多的 SFR-CUA,基本不影响端到端分数(81.1 vs 81.9、51.2 vs 50.6、84.1 vs 81.9、68.4 vs 70.1)。只有 OSWorld 2.0 这个最长的基准上,差距才暴露出来:43.2% / 18.5%,显著低于 StateAct+Claude 的 61.6% / 26.9%。
这一行数据是工程上最值钱的一条:前沿 GUI 模型在 80% 的场景下是 overkill,只在最长的桌面任务上才是必要的。这个结论直接对应"GUI 子智能体只跑 1.1% 的主智能体步骤"——大多数时候它根本不被调用,所以弱一点也没差。
五、失败分析:68/76 通过的"门"为什么不是 bug
作者对 79 个非完美任务做了逐任务审计,这是论文里我看得最仔细的一节:
图 8:79 个非完美任务的归因桑基图。Reasoning 38(wrong value 13、wrong choice 11、imprecise geom. 9、missed item 5)是主导失败模式;Verifier 14(wrong path 5、unchecked content 5、wrong format 4)是门本可捕获的"结构"错误;Capability 18 命中模态瓶颈(视频链 8、slide/pptx 6、3D/CAD/medical 4);Ambiguity 4 + Other 5。
完成门的操作特征表(Table 5)更刺眼:在 76 个"非完美任务到达门"里,门正确通过 68 个、错误拒绝 8 个——错的通过率约 90%。
作者把这个写成了一段非常老实的讨论(我自己读了两遍):
"This is not narration-conditioned agreement bias—the gate is independent of the agent's narration—but rather common-mode failure: shared interpretation of the source."
我的翻译:门不是在"附和"agent,它和 agent 共用了同一种"对源数据的理解"。当 agent 把数字 7 看成 7、门也把 7 看成 7,门就没法发现 agent 算错了。这是没有 ground truth 的自验证器的天花板——结构性错误能抓(路径错、未保存),值错误抓不到。
52 个任务理论上可解(reasoning 38 + verifier 14),22 个任务命中模态瓶颈或指令歧义(视频、PPT、3D/medical,这些是 backbone 跨不过的),5 个未充分分解。换句话说,StateAct 离"通用 OS 智能体"还有大约 50 个任务的差距,而这 50 个里大部分是"换更强的模型/更长的推理时间"才能跨的——架构已经做到头了。
六、轨迹案例:三段 score 1.0 的成功故事
图 5:三个 score 1.0 的轨迹。STATE-FIRST(任务 012):全程不碰 GUI,主智能体用 bash 列出试卷树 → python-docx 解析错题 → pdfplumber 匹配题与卷 → tesseract OCR 找隐藏/干扰题 → cp 复制并按字节核对 → 完成门重读 5 个 PDF → PASS。DELEGATE(任务 001):用 Python 把 FYP 时间表直接写进 calendar.ics 并消除 2 个冲突,然后只为了看一眼 GNOME Calendar 视觉效果才委派 GUI specialist。GATE RETRY(任务 038):主智能体用 curl/PATCH 设置 40 个 CloudCRM 线索状态 → 门从源重新推导 40 条 → REJECT 线索-6(陈旧 CRM 记录已被新邮件取代)→ 主智能体读新邮件重新推 → 门再次 verify → PASS。
任务 012 这条尤其让我服气——整个任务没有任何 GUI 操作。五道错题的匹配、干扰项的拒绝、最终 5 个 PDF 的字节核对,全在 bash + Python 里完成,门只读了一次。这种"全程静默"的轨迹,在过去任何截图优先的框架里都不可能跑出来。
任务 038 那条则展示了门+主智能体的真实协作:门不是简单"对/错",它真的能基于外部源(更新的邮件)推翻主智能体写在 CRM 里的旧状态。这才是 actor-critic 分离在产品里该有的样子。
七、我的判断
这是一篇工程架构非常成熟的论文,不是模型层面的突破,也不试图装成突破。我给它的定位是:长程桌面智能体从"演示能跑"走向"可量化、可审计、可降本"的一篇。
几个我比较认的地方:
- 诚实承认边界。把任务分 state-addressable / hybrid / render-only 三类,主动把 render-only 排除出去,说明作者真的想清楚了适用范围,而不是无脑"我们的方法全场景领先"。
- 递归深度没意义也写在论文里。很多论文会把"自递归"包装成创新点,这里直接说扁平最好、递归基本不触发、嵌套从未发生。这种透明度在工程论文里挺稀缺的。
- GUI 子智能体 1.1%。这数字本身就很有信息量——它告诉你这件事的杠杆不在 GUI 模型有多强,而在 98.9% 的步骤根本不该走 GUI。这对工程团队直接意味着"别再烧钱在 SOTA GUI 视觉骨干上了,先看一下你的 action space"。
- 完成门的诚实。68/76 错误通过率,作者没有包装成"门很严格",而是写明这是 common-mode failure。这种坦诚反而让方法更可信。
也有几个我皱眉的地方:
- StateAct 跑 155 轮/任务,参考基线 103 轮。它通过多花 50% 的轮次 + 子智能体委派拿到的部分提升,究竟有多少是"状态通道"本身的功劳,有多少是"更长轨迹 + 更多次尝试"的功劳?论文没有严格做"截断到相同步数"的对照。我自己怀疑,把 Opus 4.8 截断到 155 轮的纯截图基线跑一遍,可能也能涨 2-3 个点。
- 无 ground truth 验证器是天花板。这是作者自己说的,我同意。状态锚定把感知瓶颈挪到推理瓶颈,没有消除瓶颈。如果你做生产部署,准备好面对"门过不了的值错误"——这类错误需要另一个独立的 ground truth 源,而不是再加一个 LLM。
- Bash-only 45.9% 部分成功率低于截图基线 54.8%。这其实是个挺令人警醒的数据:很多团队会觉得"反正 LLM 能写 Python,直接上 CodeAct 不就行了?"——答案是不行,代码动作空间 + 子智能体 + 验证器必须三件套。
八、给做 Agent 的同行
如果你也在做类似的桌面 / 浏览器 / 移动 Agent 框架,有三个点可以立刻在自己项目里试一下:
- 不要让主智能体同时跑截图+点击和 shell+文件。拆成"主智能体只看状态、GUI 子智能体只看像素"两个角色,中间用结构化报告传话。哪怕不重写整个框架,先做这一层解耦,成本都能看到显著下降。
- 完成门要独立。哪怕你暂时没法做叙述盲,至少把门放在另一个进程、另一个 prompt、拿不到 agent 对话历史的位置。自我审查最大的坑就是"看到自己写过 done 就默认 done"。
- 先看动作空间,再看视觉模型。如果 80% 的步骤其实可以走代码,你堆再多视觉骨干也只在 20% 的步骤上加分。先把动作空间设计好,再去堆模型。
最终判断:StateAct 不是一篇"看完想立刻改模型"的论文,但它是一篇"看完想立刻改自己脚手架"的论文。在这个模型能力迭代速度越来越快、而产品部署仍然卡在 20-30% 成功率的时代,把模型用对地方比用更大的模型更值钱。
觉得有启发的话,欢迎点赞、在看、转发。跟进最新 AI 前沿,关注我。