← 返回 2026-10-01

CUA-SWE:当计算机使用智能体遇上可视化软件工程 CUA-SWE: When Computer-Use Agents Meet Visual Software Engineering

Prince Zizhuang Wang, Chenhao Liang, Zelong Xu, Aojie Yuan, Xiaolin Zhou, Haiyue Zhang, Yue Zhao, Xiyang Hu, Shuli Jiang 📅 2026-09-26 👍 15 2026-11-11 18:30
可验证奖励 基准评测 多模态智能体 计算机使用智能体 软件工程智能体

首个让智能体边操作运行软件边改代码、并用确定性测试验证修复的四域基准

前置知识

计算机使用智能体(Computer-Use Agent, CUA)

通过截图观察屏幕、用模拟鼠标键盘操作图形界面来完成任务的智能体。它不直接访问应用内部状态或结构化 DOM,只能从渲染后的像素中获取信息,代表系统有 UI-TARS、OpenCUA、Agent S2,相关评测基准包括 OSWorld、WebArena、AndroidWorld 等。其核心难点在于把视觉观察正确映射到界面元素与操作序列。

本文的 hybrid CUA 条件正是给编码智能体加上 CUA 的观察与操作通道,理解 CUA 的能力边界才能读懂“视觉反馈帮助诊断修复”这一核心实验设计的含义。

编码智能体与 SWE-bench

在代码仓库中读文件、编辑代码、执行命令与测试的智能体,代表系统如 Codex、Claude Code。SWE-bench 是其代表基准:给定 issue 与仓库,要求生成能通过仓库测试的补丁。这类智能体只看代码与命令输出,看不到运行中应用的界面和用户所见行为。

本文把这类智能体作为 code-only 基线条件,其与 hybrid CUA 条件的差距正是论文要度量的“视觉通道价值”,两条路线互补的背景是全文动机。

部分可观察马尔可夫决策过程(POMDP)

序贯决策的形式化框架 $\mathcal{M}=(\mathcal{S},\mathcal{A},\mathcal{O},P,\Omega,R)$:真实状态 $s_t$ 不可直接观测,智能体每步只收到观察模型 $\Omega$ 生成的部分观察 $o_t$,据此选动作 $a_t$,环境按转移 $P$ 演化,终止时依奖励 $R$ 结算。智能体需从交互历史 $h_t=(o_0,a_0,\dots,o_t)$ 中隐式推断状态。

论文第 2 节把每个任务形式化为有限视界 POMDP,策略 $\pi_\theta(a_t\mid I_u,h_t)$ 在指令与历史条件下选动作、最大化期望终端奖励,这是理解其问题定义与 RLVR 展望的数学基础。

确定性验证器与 RLVR

确定性验证器是独立于被评模型的程序,通过受控执行与断言给出可复现的判定,本文中为 $V_u(c)=V_u^{task}(c)\wedge V_u^{reg}(c)\wedge V_u^{perm}(c)$。RLVR(可验证奖励强化学习)用这类验证器给新采样轨迹打分作为奖励训练策略,避免 LLM 裁判的主观性与可被迎合性。

CUA-SWE 的评测可信度与后训练价值完全建立在“验证器可执行、可复现”之上,理解这一点才能明白论文为何强调确定性测试而非裁判模型。

监督微调(SFT)

在带标注的输入-输出对上继续训练预训练模型,使其模仿参考行为。本文用黄金参考修复的回放动作前缀微调 Qwen3.8-27B,训练后模型学会复现参考修复的开发流程,是在没有完整 RL 管线时验证环境学习信号的最简途径。

第 4.4 节的 SFT 实验(Web 域验证器通过率从 11.1% 升至 33.3%)是论文证明“基准可提供学习信号”的关键证据,也是通向 RLVR 的第一步。

研究动机

软件开发远不止编辑代码:开发者要反复运行程序、操作界面、用肉眼检查行为,再决定下一步改什么、改动是否生效。现有评测把这条完整链路割裂成两半——SWE-bench、SWE-bench Pro 一类编码基准只考察对仓库的改动,智能体看不到运行界面;OSWorld、WebArena 一类计算机使用基准只考察操作现成应用,智能体不写代码。即使 Programming with Pixels、WeaveBench 等可视化软件基准引入了运行时反馈,也集中在 JavaScript 网页、游戏等单一领域,或依赖主观的智能体裁判。论文给出一个典型场景:平台跳跃游戏中角色跳上平台后会直接穿过去,此时代码能构建、静态截图看起来完全正常,纯编码智能体无法从命令行输出定位这类缺陷,必须真正\u201c玩\u201d游戏、观察跳跃与落地,再把现象关联到移动或碰撞代码,修完还要重放操作确认修复且不破坏普通移动。

本文的目标是论文要构建一个把\u201c用软件\u201d和\u201c改代码\u201d统一起来的完整测试平台:CUA-SWE 基准、交互式开发环境与评测流水线,覆盖 Web、游戏、DevOps、移动应用四个软件工程领域,共 105 个任务。具体回答两个中心问题:其一,智能体如何利用 GUI 反馈来诊断、修复并验证软件?其二,当任务所需的规格说明或运行信息只能通过正在运行的应用的视觉界面获取时,智能体能否完成软件工程任务?为此每个任务都要求智能体在同一开发回合内修改代码与配置、执行命令、操作运行中的软件并检查视觉反馈,由确定性的任务专属测试验证修改后的软件是否满足需求且不破坏指定既有功能,为后续研究提供可复现、可验证的正确性判据。

与已有工作不同的是,论文的独特切入有三点。第一,同一任务在两种访问条件下做配对比较:code-only 条件只能读代码、跑命令、看输出,hybrid CUA 额外提供运行应用的截图和图形交互,从而干净地度量\u201c视觉通道\u201d本身的价值,而不混淆任务难度差异。第二,评测与轨迹解耦:正确性由独立于智能体行为的确定性验证器 $V_u$ 执行最终代码库来判定,而非用 LLM 当裁判,保证可复现且不可被讨好。第三,引入规格来源标注:source-specified(S)任务的规格写在指令与可读代码里,application-material-dependent(M)任务的规格只能从图纸、服务合同、图形参考卡等应用材料中恢复,使基准能区分\u201c从界面读需求\u201d与\u201c把需求写成代码\u201d两种能力,这是已有任何基准都不具备的维度。

核心方法

CUA-SWE 包含 105 个任务,覆盖 Web(36 个)、游戏(29 个)、DevOps(20 个)、移动(20 个)四个领域,任务改编自开源应用或专门构建的应用。形式化上,每个任务 $u$ 建模为有限视界部分可观察马尔可夫决策过程 $\mathcal{M}_u=(\mathcal{S},\mathcal{A},\mathcal{O},P_u,\Omega_u,R_u)$:状态 $s_t=(c_t,x_t,b_t)$ 包含当前代码库、开发环境与运行应用的完整状态及剩余动作预算 $b_t$,但智能体只能看到文件内容、命令输出或截图等部分观察 $o_t$。动作空间 $\mathcal{A}=\mathcal{A}^{coding}\cup\mathcal{A}^{computer}\cup\{finish\}$,前者覆盖代码检查、编辑与构建测试命令,后者覆盖截图观察、鼠标键盘输入与应用控制。终止奖励 $R_u(s_T)=V_u(c_T)\in\{0,1\}$ 由确定性验证器给出,策略 $\pi_\theta$ 的目标是最大化期望终端奖励,即最大化最终代码库通过验证的概率。

核心创新是把\u201c验证器与轨迹解耦\u201d与\u201c信息条件配对\u201d结合起来。验证器由三个二值检查合取而成:$V_u(c)=V_u^{task}(c)\wedge V_u^{reg}(c)\wedge V_u^{perm}(c)$,分别检查请求的功能是否实现、指定既有功能是否回归、修改是否越出允许范围。行为检查通过受控执行、交互序列以及对渲染界面或运行时状态的断言完成,评分只依赖提交代码 $c_T$ 的行为而不匹配参考补丁。评测时任务结果为 $S_i=P_iU_i$,其中补丁正确性 $P_i=V_u(c_T^i)$,轨迹有效性 $U_i$ 检查工具访问与观察证据是否符合所分配条件,成功率为 $T_{SR}=100|E|^{-1}\sum_{i\in E}P_iU_i$。与用 LLM 裁判的 WeaveBench、只看仓库补丁的 SWE-bench 相比,这套设计同时保证了确定性、防作弊(不许改受保护测试)和视觉信息的受控注入。

方法步骤详情

构建流程分五步。第一步,从可在运行应用中复现的具体软件行为出发生成任务:LLM 作者据此写出指令 $I_u$、初始有缺陷代码库 $c_u^0$、可复现运行时配置、黄金参考修复 $c_u^\star$、貌似合理的负例修复以及实现 $V_u$ 的受保护行为测试,并指定一段能通过可用观察暴露相关行为的交互序列。第二步,人工审查加可执行验证:至少要求 $V_u(c_u^0)=0$ 且 $V_u(c_u^\star)=1$,确保验证器能区分原始故障程序与已知正确实现;负例修复必须仍被 $V_u$ 拒绝,以检验验证器的判别力。第三步,验证交互开发路径:确认应用可被驱动到目标状态、相关视觉观察可通过基准接口获得、代码改动能生效、验证从干净状态可复现。第四步,构建期智能体试跑用于校准难度并识别失败模式,进而构造任务族受控变体(如提高几何复杂度、延长时序依赖),每个变体独立过审查与验证。第五步,评测中记录 $P_i$ 与 $U_i$,按四域等权聚合为平均成功率。

技术新颖性

技术新颖性体现在四点。其一,任务语义上把\u201c可观察的运行行为\u201d与\u201c代码修改需求\u201d显式连接,并要求保留指定既有功能,这是 SWE-bench 系列不具备的运行时维度。其二,规格来源标注(S/M)让基准第一次能单独测量\u201c从视觉材料恢复需求\u201d的能力——实验显示混合访问的收益几乎全部集中在 M 类任务,S 类任务域平均变化接近零,这本身就是方法论贡献。其三,任务族机制:不贴标量难度标签,而是通过改变特定开发需求(几何复杂度、时序依赖、额外交互条件)生成同源变体,可随混合智能体进步持续扩展基准。其四,可执行验证器天然给出二值奖励 $R_u(s_T)$,为 SFT 与 RLVR 后训练提供监督信号,论文已在 Web 域用 SFT 验证了这一学习信号(通过率 11.1% 升至 33.3%),而 Programming with Pixels 与 WeaveBench 均未提供可复现的后训练信号。

The CUA-SWE development and evaluation pipeline.
Figure 2: The CUA-SWE development and evaluation pipeline.
A concrete benchmark task: repairing inventory updates in Captain Callisto.
Figure 3: A concrete benchmark task: repairing inventory updates in Captain Callisto.
Mobile example: repairing imported routes in Campus Pocket.
Figure 4: Mobile example: repairing imported routes in Campus Pocket.
Web example: preserving distinct masked-date input behaviors.
Figure 5: Web example: preserving distinct masked-date input behaviors.

实验结果

GPT-6-Astra 以 59.9% 混合访问平均任务成功率领先,比 GPT-5.6-Sol(42.2%)高 17.7 个百分点,四域成绩 Web 66.7%、Game 37.9%、DevOps 80.0%、Mobile 55.0%(code-only 的 DevOps/Mobile 均为 0.0%)。所有前沿模型混合均胜纯编码:Astra +48.6、Grok-4.6 +31.7、Claude-Fable-5 +29.1 个百分点,收益集中在 M 类任务,S 类任务域平均变化接近零。行为上,Astra 在嵌套选择任务中能发现并修复连带缺陷,Sol 与 Claude-Opus-5 补丁则保留缺陷;齿轮任务完整重建 23 条传动关系,Sol 选错两处驱动轮。效率上 Astra 平均 4.3 分钟(Sol 3.7),对 Grok-4.6 83.3%、Opus-5 72.2% 的共同成功用更少响应;Game 三试中 Astra 34.5% 任务三次全对,Sol 仅 3.4%。SFT 在 Web 域 27/9 划分上微调 Qwen3.8-27B,验证器通过率从 11.1% 升至 33.3%。

Single-attempt task success (%) across four domains. Code denotes code-only access; hybrid CUA adds screenshots and graphical actions.
Table 1: Single-attempt task success (%) across four domains. Code denotes code-only access; hybrid CUA adds screenshots and graphical actions.
Success, time, and interaction effort.
Figure 6: Success, time, and interaction effort.
SFT performance on Web domain.
Figure 7: SFT performance on Web domain.
查看结构化数据
任务指标本文基线提升
四域平均任务成功率(单次尝试,GPT-6-Astra) 任务成功率 TSR (%) 混合 CUA 59.9 纯编码(code-only)11.3 +48.6 个百分点
四域平均任务成功率(单次尝试) 任务成功率 TSR (%) GPT-6-Astra 59.9 GPT-5.6-Sol 42.2 +17.7 个百分点
DevOps 域任务成功率(GPT-6-Astra) 任务成功率 (%) 混合 CUA 80.0 纯编码 0.0 +80.0 个百分点
Web 域任务成功率(GPT-6-Astra) 任务成功率 (%) 混合 CUA 66.7 纯编码 27.8 +38.9 个百分点
Web 域 SFT(Qwen3.8-27B,贪婪单次尝试) 原生验证器通过率 (%) SFT 后 33.3 基座模型 11.1 +22.2 个百分点
Game 域三次尝试一致性 三次尝试全部成功的任务占比 (%) GPT-6-Astra 34.5 GPT-5.6-Sol 3.4 +31.1 个百分点

局限与改进

作者承认的局限:SFT 只是来自黄金补丁回放的早期正向信号,环境能否提供可验证学习信号、可扩展的 RLVR 训练仍是未来工作,需要高效并行 rollout、长多模态轨迹上的稳定优化以及跨编辑、观察与交互的信用分配;基准目前只覆盖四个领域,任务与工作流长度有限,通过测试也不保证改动可安全部署。我的补充观察:其一,每域任务数只有 20–36 个,单次尝试下成功率的最小粒度约 2.8–5 个百分点,模型间几个点的差异(如 Web 上 66.7% 对 55.6%)很难说统计显著,重采样不确定性只放在附录;其二,验证器是严格二值的 $V_u\in\{0,1\}$,无法给部分修复记分,可能低估智能体实际进展;其三,Codex、Claude Code 等 harness 只在 CUA 条件下评测,跨 harness 的代码侧比较并不完全对齐;其四,$U_i$ 轨迹检查的假阳性率在正文着墨不多;其五,SFT 划分仅 27/9 个任务,规模太小,泛化结论有限。

独立分析的弱点

独立分析的弱点:第一,统计功效不足——DevOps 和 Mobile 各只有 20 个任务,一次尝试下每个任务值 5 个百分点,改进方向是扩充任务规模并报告置信区间与显著性检验。第二,M 类任务收益与混合条件深度耦合,评估没有解耦\u201c视觉理解\u201d与\u201c信息获取\u201d,可增加把应用材料文本化后提供的对照条件,量化纯感知的贡献。第三,截图通道成本被忽略:高分辨率截图的 token 开销与延迟未报告;DevOps 任务 code-only 全为 0.0% 也可能只是日志信息被界面掩盖而非视觉必需,应补充结构化运行时状态的文本基线。第四,二值验证器对部分修复无信号,可用加权测试分数构造密集奖励以利 RLVR 训练。第五,负例修复只覆盖作者预设的部分修复方式,智能体可能找到其他钻空子实现,需要对抗性红队持续扩展验证器判别集。第六,DevOps 域七个模型 code-only 全部为 0.0%,提示任务设计可能对非视觉通道系统性不友好,而非纯粹体现视觉价值。

未来方向

作者提出的方向:一是建立环境的可验证学习信号并发展可扩展 RLVR 训练——可执行验证器可为新采样的开发回合打分,并行应用工作区支持 rollout 收集,附录 E.3 给出目标函数与 rollout 接口,难点在长多模态轨迹的稳定优化与信用分配;二是扩展到更多领域、应用与任务,纳入更丰富的开发工作流和需要跨多工具、多应用协调编码与计算机使用的长任务;三是随混合智能体进步,用任务族机制持续生成更难的同源变体。基于成果可延伸的:用 105 个任务的验证器训练过程奖励模型;研究视觉观察在 S 类任务中诊断价值趋近于零的原因;把轨迹审计 $U_i$ 自动化并量化其误差率;在真实 IDE 中复刻混合访问条件做生态效度检验;比较 M 类任务上\u201c视觉读图\u201d与\u201cOCR 加结构化解析\u201d两条信息获取路线的成本收益。

复现评估

复现评估:论文在图 1 中给出 GitHub、网站与 Hugging Face 链接,任务指令、初始代码库、运行时条件与受保护验证器在报告评测前已固定;附录 B 文档化实现与示例测试,附录 D 列出全部 105 个任务,附录 G 给出完整模型结果,附录 A 描述评测协议与工作量核算,附录 E.2 给出 SFT 完整训练配置,可复现性设计相当完整。评测是确定性的(验证器执行加轨迹检查),不依赖裁判模型,复现排行榜结果主要是工程量问题:需要为每个任务搭建本地应用、配置受控执行环境,并按条件限制工具访问。SFT 部分需微调 Qwen3.8-27B(27/9 任务划分、每任务一次贪婪尝试),中等算力即可完成;RLVR 管线尚未实现。主要门槛是 105 个任务的环境编排与人工审查成本,以及 GPT-6-Astra 等前沿模型的 API 获取难度。

相似论文推荐