SWE-Game × CUA-SWE：软件工程基准的游戏化与视觉化扩展 精读

论文 1 链接：SWE-Game: Can Coding Agents Build the Games We Want? 论文 2 链接：CUA-SWE: When Computer-Use Agents Meet Visual Software Engineering 发表时间：2026年9月 机构：SWE-Game——上海交通大学（主导）、中关村学院、上海创新研究院、深圳大学、北京邮电大学、Elbetech Technology（企业参与）；CUA-SWE——CMU（项目负责/通讯）、USC、UW-Madison、Arizona State、AWS Agentic AI（企业参与，提供工业场景与资源）。两篇均为高校主导 + 企业合作的研发模式。 领域标签：cs.AI / cs.SE，Agent 基准方向

一、论文背景：当 SWE 基准遇上「交互维度」

先讲什么是 SWE 基准与确定性验证器。 SWE-bench 开创了「仓库级软件工程评估」范式：给 agent 一个真实 GitHub 仓库加 issue 描述，agent 产出补丁，评估方用隐藏测试验证。SWE-bench Verified（OpenAI 2024 人工审核的 500 实例子集）确立了这套范式的黄金标准——确定性验证器：一套在相同输入下永远给出相同判定的可执行检查程序，如 FAIL_TO_PASS（修复前失败、修复后必须通过的测试）与 PASS_TO_PASS（必须保持通过的存量测试）。它的价值在于可复现：任何人、任何时间、任何机器上跑同一补丁，得到同一个分数，没有运气成分。

再讲什么是输入重放与 computer-use agent。 输入重放指按预定序列注入玩家/用户输入（按键、点击），再断言程序状态变化——游戏测试中常用，因为「玩一把就知道 bug 在哪」比读代码猜行为可靠得多。Computer-use agent（CUA，计算机操作 agent）则是通过截图看屏幕、通过鼠标键盘操作界面来完成任务的 agent，代表工作有 OSWorld（369 个真实操作系统任务，人类基线 72.36%）与 WebArena。它们与传统 coding agent 的能力通道完全不同：一个走 GUI 感知与像素操作，一个走源码读写与命令执行。

问题来了。 这两条线各自都遇到了瓶颈：

• SWE 线的评估对象太窄。真实软件不只有「改 Python 仓库修 bug」——游戏这类交互软件要求构建、修复、跨引擎移植，且行为正确性依赖玩家输入，静态代码检查和隐藏单元测试都无法判断「这个游戏好玩、这个机制真的生效了吗」。已有游戏基准退而用 VLM 裁判看视频打分，但 VLM 打分不确定、可被表面现象欺骗。
• CUA 线的评估又太浅。OSWorld 们只测「agent 能否通过界面完成用户任务」（发邮件、改设置），不测「agent 能否通过界面完成开发任务」——而真实开发者常常要看着运行中的应用界面定位问题、改完代码再运行验证。GUI 与代码这两个通道从未在同一个软件工程任务里闭环。

两篇论文正是对这两个瓶颈的正面回应，而且给出了惊人一致的核心解法：无论评估对象怎么扩展（从修 bug 到建游戏、从源码到 GUI），都坚持用确定性运行时验证替代主观判断。

二、论文定位和关联工作

2.1 SWE-Game 所在的游戏开发基准谱系

VLM/agent 裁判路线：OpenGame（arXiv:2604.18394，开放游戏 agentic coding）、WebGameBench（浏览器游戏运行时交互评估）、V-GameGym、GameCraft-Bench（arXiv:2606.17861，140 个 Godot 任务、重放演示 + 多模态 rubric 打分，最强 agent 仅 41.46%）都用 VLM 或 agent judge 评估生成游戏——灵活但非确定，且对功能性错误敏感度未知。SWE-Game 的评估器效度实验（94.25% vs 75.40% 缺陷检出）正是对这条路线局限的定量回应。

确定性运行时路线（同期）：GameLogicBench（arXiv:2609.21562，南京大学等）在 72 个 Godot 任务上逐仿真 tick 断言游戏规则（403 场景种子扩为 1451 测试），并用突变体验证评估器必须「接受等价实现、拒绝缺能力突变体」——与 SWE-Game 的 no-input 对照异曲同工，且验证了「运行时证据抓功能性错误」这一判断。

单一任务类型路线：GameDevBench/JamBench（项目编辑/生成/补全）、GameEngineBench（Unreal 项目内编辑）各覆盖一环。SWE-Game 的差异化定位：唯一以 41 个可执行参考游戏为锚、用单一共享仪表接口同时覆盖构建（G）/修复（R）/移植（P）四类以上任务（加上变体共五类）并配确定性运行时检查的基准。

2.2 CUA-SWE 所在的 CUA 基准谱系

CUA 基准：Mind2Web/WebArena/VisualWebArena（网页交互）、OSWorld/Windows Agent Arena/AndroidWorld（桌面与移动工作流）。它们测「界面操作完成用户任务」，任务成功判定用执行式脚本或环境状态检查，但不涉及代码编辑。

SWE 基准：SWE-bench/SWE-bench Pro/SWE-Lancer 评估仓库修改与专业开发任务，但只有源码通道——issue 文本 + 仓库快照。

CUA-SWE 的差异化定位：首个把 computer-use 与软件工程在 Web/Game/DevOps/Mobile 四域统一、带确定性验证器、并可做 code-only vs Hybrid CUA 配对对照的基准。注意 SWE-Game 的 Game 域与 CUA-SWE 的 Game 域（29 任务）有精神上的呼应——游戏都是交互密集、必须运行验证的软件。

2.3 对比总表

三、问题定义

两篇论文在抽象层面回答同一个问题：

具体问题：SWE-Game——如何客观评估 agent 构建的游戏是否符合预期玩法？CUA-SWE——当规格和运行信息只能通过运行中应用的视觉界面获得时，agent 能否完成开发任务？

共同抽象：给定一个「行为定义在交互过程中」的软件任务（而非行为定义在静态代码中），如何设计一套评估协议，使得 (1) 判定与实现无关（agent 可以写出命名/结构完全不同的等价实现）；(2) 判定可复现（相同交付物必然同分）；(3) 判定抗作弊（不能靠不操作、抄参考或改测试通过）。

形式化地说：求评估函数 V(交付物) ∈ {通过, 不通过}，约束为确定性（重复调用输出不变）、语义等价不变性（等价实现同判）与行为依赖性（行为必须由交付物在受控输入下产生）。

精妙之处：两篇论文都意识到「确定性」不必以牺牲「生态效度」（真实开发场景）为代价——办法是把评估从「看产物」改为「在受控条件下运行产物并检查状态」。这与 SWE-bench 用 FAIL_TO_PASS 测试代替「代码 diff 相似度」是同一哲学在交互软件上的延伸。

四、问题解法

4.1 SWE-Game：仪表接口 + 三类运行时证据

任务构成：41 个可执行 Godot 参考游戏（13 玩法类别、2D/3D）为锚，派生 247 任务：Brief-to-Game/GDD-to-Game/骨架补全各 41、注入缺陷修复 83、Godot→Unity 跨引擎移植 41。

核心机制：共享游戏仪表接口。类比深度学习里的「标准数据接口」（DataLoader 规定输入格式，不管底层是什么文件）：SWE-Game 规定参考游戏与 agent 实现都必须把游戏对象挂到标准 scene-tree 分组（如 gb_player 存玩家、gb_* 前缀存敌人/收集物/门等），并绑定标准动作与数值状态槽。这样「不同命名/结构的等价游戏对象」被映射到统一可观测空间——评估方自有的 probe（探测程序）可以在任意 agent 实现上执行输入重放并读取引擎状态，而无需了解该实现的内部代码。

三类运行时证据：

1. 引擎状态检查（engine-state checks）：受控输入序列后断言引擎内状态（位置、血量、分数、开关）——确定性、实现无关；
2. 认证参考输入重放（certified reference-input replay）：用预先认证过的参考输入序列在 agent 游戏上重放，检查行为一致性；
3. agent 自证 feature demo：agent 提交演示自己实现的功能的脚本。

no-input 对照（防作弊关键）：同样的检查序列再做一遍「不注入输入」的对照运行——如果对照局里游戏「自己通关」了（如掉落物恰好堆满目标），说明行为不依赖玩家输入，判负。这切断了「写一个自动演示动画冒充可玩游戏」的奖励作弊路径。

评分公式：构建任务 S = 0.85·客观（运行时证据）+ 0.15·视觉（41 套游戏专属 VLM rubric，共 658 项，与人评 Spearman ρ=0.829）；修复任务为 restoration×retained×preservation×validity 连乘。

4.2 CUA-SWE：四域任务 + 三重验证器 + S/M 标注

任务构成：105 任务跨 Web(36)/Game(29)/DevOps(20)/Mobile(20)。每任务含可编辑项目、运行中的应用（可截图、可鼠标键盘操作）与确定性任务专属验证器。

关键对照设计：同一任务跑两种条件——code-only（可读写源码、可跑构建测试，无 GUI）vs Hybrid CUA（code-only 基础上加截图与 GUI 交互）。这是把「GUI 通道的价值」变成可测量量的实验设计。

S/M 规格来源标注（概念贡献的核心）：每个任务标注规格的来源——

• S（source-specified，源码可定）：指令 + 可读项目代码已完整定义目标行为；
• M（application-material-dependent，依赖应用材料）：规格只存在于应用附属材料中——导入的设计图纸、服务合约（OpenAPI/spec 文件在运行时才可见的校验规则）、应用内嵌的配置资源等。

这层标注把「GUI 有没有用」这个模糊问题拆成可证伪的假设：若 GUI 价值在「看界面本身」，S、M 任务都应增益；若 GUI 价值在「恢复源码中不存在的规格」，只有 M 任务应显著增益。

验证器三重结构：V_u = V_task ∧ V_reg ∧ V_perm——

• V_task（请求行为）：用受控交互序列 + 渲染界面/运行时状态断言验证请求的行为确实发生；
• V_reg（回归保护）：应用的其他功能未被破坏；
• V_perm（允许修改）：改动未越界（未动受保护文件/接口）。

关键工程点：验证器独立于轨迹、可使用特权状态——agent 只能看到渲染出的界面，评估器却可访问完整运行时状态与受保护材料，保证评分可复现且不可被轨迹中的表演欺骗。

质量保障与后训练信号：LLM 辅助出题 + 人工审查 + 可执行验证三重校验（坏项目必败、金补丁必过、负例补丁必拒）；另用 verified reference replay 的动作前缀微调 Qwen3.8-27B（27/9 train/test split），提供训练数据价值验证。

评分：TSR = 平均(P_i · U_i)，P_i 为补丁正确性（验证器判定），U_i 为轨迹合规性（是否使用所属条件允许的接口、满足观察证据要求），四域等权。

五、评估指标与实验证据

5.1 SWE-Game：模型天花板与评估器效度

主指标为 0-100 综合分。六个模型（Opus5、GPT-5.6 Luna、Grok4.6、GLM5.3 Flash、Minimax M3、Qwen3.8 Flash）中，Opus5 五类任务全部第一：

证据一：构建任务远未解决。三大构建任务最优分全部 <60/100——即使最强的模型，从规格构建完整可玩游戏的能力也只有一半多一点。

证据二：修复任务中 Restoration 是区分器。Restoration（故障行为是否修复）跨模型波动最大（35.27–90.18），而 Retained（96.00–99.51）与 Preservation 都接近满分——模型普遍能不破坏存量功能，差距全在「能不能修好」。

证据三（最关键）：评估器效度。对 100 个 agent 构建游戏、1200 条人工标注行为：

运行时检查以 14.18 个百分点的 balanced accuracy 优势胜出——且这是确定性的 14.18pp。

证据四：视觉 rubric 消融。视觉 rubric 与人评 Spearman ρ=0.829（200 clips，MAE 0.103），但加参考视频做「外观目标」反而使 VLM 总分 +5.60（GPT）/+2.23（Opus），视觉呈现 +6.48/+9.00，而 Content Composition 反降 6.01/9.93——视频只传递「长什么样」，不传递「怎么玩」，甚至诱导模型模仿外观而牺牲内容。

证据五：错误类型分模型分化。GPT 主因是需求遗漏（56.4%）、Opus 36.9%、GLM5.3 Flash 则以玩法逻辑错误为主（52.2%）——功能性错误只有运行时证据能抓到，这与证据三互为因果。

5.2 CUA-SWE：GUI 价值的 S/M 分层证据

主指标 TSR（四域等权）。GPT-6-Astra 四域均值 59.9% 居首，超 GPT-5.6-Sol 17.7pp；单域 Web 66.7 / Game 37.9 / DevOps 80.0 / Mobile 55.0。

证据一：所有模型 Hybrid 全部优于 code-only：

（共 9 个前沿模型，差值 +12.8 至 +48.6。）

证据二（机制定位）：S/M 分层：

S 任务（源码可定规格）增益 ≈0 且模型间大幅波动；M 任务增益 +23.6~+48.1。DevOps/Mobile 的 code-only 几乎为 0（0.6%）——信息只存在于界面/材料中，不看就永远不知道要做什么。GUI 的价值不在「看」这个动作本身，而在恢复只存在于应用材料中的规格。

证据三：稳定性与后训练信号。三次全解率 GPT-6-Astra 34.5% vs GPT-5.6-Sol 3.4%（Game 域三次尝试研究）——强弱模型差异不仅在会不会，还在稳不稳；Qwen3.8-27B 在 gold-replay 前缀上 SFT 后，held-out pass 率 11.1%→33.3%——该基准可以产出有效训练信号，不是纯评估消耗品。

证据四：失败模式标注。32 条轨迹双标注（观察类 κ 0.77-1.0），瓶颈定位在观察获取与实现完整性，而非解释/诊断能力——模型看得懂，但拿不到信息、做不完整。

证据五：交互经济性。GPT-6-Astra 在与 Grok-4.6 共同成功的 Web 任务上 83.3% 用更少回复——强模型不仅成功更多，交互成本也更低。

六、效果优势的根源解释

6.1 为什么运行时证据抓到 VLM 抓不到的功能性错误（SWE-Game）

因果链（每步标注证据来源）：

1. 视频是行为的高损耗投影：像素帧丢弃了引擎状态变量（血量数值、碰撞开关、内部计数器），只保留渲染结果【论文实验支持：VLM 对「缺陷存在」的检出率仅 75.40%】；
2. 仪表接口把等价实现映射到统一可观测空间，probe 可直接断言状态变量而非从像素反推【论文机制设计】；
3. no-input 对照排除「行为与输入无关」的伪通过【论文机制设计】；
4. 因此功能性错误（需求遗漏 56.4%、玩法逻辑错误 52.2%）在状态断言下无所遁形【论文实验支持：executable 检查 92.59% balanced accuracy】。

外部交叉验证——方法相似：GameLogicBench（arXiv:2609.21562）同样发现「游戏可能在违反规则的运行后以合法状态结束」，必须逐 tick 断言规则而非看终态/视频；且其突变体验证显示，没有「拒绝缺能力突变体」的评估器会放过错误提交——与 SWE-Game 的 no-input 对照互为印证。GameCraft-Bench（arXiv:2606.17861）用重放+多模态 rubric，最强 agent 仅 41.46%，说明纯 rubric 路线的天花板与主观性。VLM-as-judge 的不稳定与误判在视觉评估文献中亦有独立记录（如工业级游戏 QA 视频研究：单提示 VLM 精度 0.50/准确率 0.72，二次裁判与元数据增强仅带来边际改善，arXiv:2606.22918 相关综述讨论了 VLM 裁判对表面合理性的敏感与重跑不一致）。

外部交叉验证——结论相近：SWE-bench Verified 的演化史（从 diff 相似到隐藏测试、再人工清洗测试质量）本身就是「执行式判定优于表面判定」的同一结论在传统 SWE 域的验证；Emergent Mind 综述引用的多项实证（约 22.32% 的「成功」修复可疑、solution leakage 约 33%）进一步表明：验证器质量决定基准效度——SWE-Game 的 92.59% 效度量化正是对这个教训的自觉应用。

6.2 为什么 GUI 价值不在「看」而在信息恢复（CUA-SWE）

因果链：

1. 若 GUI 价值来自「视觉确认」（看结果对不对），则任何任务加 GUI 都应有增益【可证伪假设】；
2. S 任务增益实测 ≈0（Web S +0.0、Game S −0.6）——当规格可从源码完整恢复时，看界面不提供增量信息【论文实验支持】；
3. M 任务增益 +23.6~+48.1，且 DevOps/Mobile code-only 仅 0.6%——规格与运行信息物理上不在源码里【论文实验支持】；
4. 因此 GUI 通道的本质功能是信息恢复：把只存在于应用材料/运行界面的规格读进上下文，再走正常代码通道实现【论文实验支持 + 阅读者对机制的概括，后者属推测性总结】；
5. 失败模式分析（瓶颈在观察获取而非解释/诊断）与 SFT 有效性（学习「如何观察」即可 +22pp）进一步支持：缺的是信息，不是智力【论文实验支持】。

外部交叉验证：OSWorld 谱系工作（人类 72.36% vs 初期最佳 12.24%，到 2026 年多模型越过人类基线）证明 GUI 通道本身可学且进步迅速，但它们不分离「信息恢复」与「界面操作」两种价值——CUA-SWE 的 S/M 分层正是对这一混淆的解耦。GUI agent 综述与基准（WorldGUI 的非默认初始状态、FineState-Bench 的细粒度交互 32.8% 准确率）从另一侧证实：GUI agent 的瓶颈分布在感知/状态恢复环节，与 CUA-SWE「瓶颈在观察获取」一致。GameCraft-Bench 的分析（「视觉交互对调试与迭代至关重要，源码中不可见的玩家侧故障需感知引导的迭代发现」）则从游戏生成方向得出与 M 任务机制相近的结论：视觉通道的价值在获取源码外信息。

综合判断与未决问题：

• 多研究共同支持：(a) 交互软件的评估必须基于受控运行时证据而非表面观察（SWE-Game 效度数据 + GameLogicBench 突变体验证 + SWE-bench Verified 历史教训）；(b) GUI 通道对开发任务的价值集中于信息恢复（CUA-SWE S/M 分层 + GameCraft-Bench 分析 + GUI agent 瓶颈文献）。
• 仍属推测：Hybrid 增益随模型代际如何演化（若未来模型能从源码反推全部规格，M 任务增益或收窄）；41 游戏规模下效度结论向其他引擎/品类的外推。
• 适用边界：SWE-Game 的仪表接口要求实现方可控（能挂分组），对纯黑盒交付（如网页游戏构建产物不可注入接口时）需适配；CUA-SWE 的结论以「规格确实存在于某处材料」为前提，对规格只存在于人脑中的模糊需求（「好玩一点」）不适用。两篇均为单 agent 框架/单次运行设置，多 agent 与多次采样下的方差未覆盖（SWE-Game 每模型仅配单一 agent 框架是其自认局限）。

七、必要知识反推

假设一个没有背景的人要做这两篇工作，最少必须知道什么？

领域知识层：

• 游戏引擎运行模型（scene-tree、tick、信号）与 Godot/Unity 差异——不理解就无法设计「实现无关」的仪表接口，也不知道移植任务的难点在引擎概念不对齐；
• 软件测试理论基础（测试预言问题、变异测试、混淆因子）——SWE-Game 的 no-input 对照本质是对照实验设计中的控制组思想，CUA-SWE 的坏项目/金补丁/负例三重校验是测试预言的工程化；
• GUI 自动化栈（截图流、坐标操作、accessibility 树）与移动/DevOps 环境搭建——CUA-SWE 四域环境是工程重头。

方法论知识层：

• SWE-bench 范式及其已知缺陷（测试不足、泄漏、规格不全）——两篇的验证器设计都是对该教训的规避；
• CUA 基准的任务构造与执行式判定（OSWorld 的 setup-config-eval 模式）——CUA-SWE 直接继承并扩展为「代码+界面」双通道；
• 心理测量学式的标注设计（balanced accuracy、Cohen’s κ、Spearman ρ、双人独立标注）——没有这层知识，92.59% vs 78.41% 的效度主张就无法严谨成立。

工程知识层：

• 容器化/虚拟化隔离评估环境、LLM 辅助出题 + 人工审查流水线、参考输入的「认证」（先验证输入序列本身有效再用于评估）；
• 确定性重放的工程陷阱（帧率依赖、随机种子、浮点不确定性）——做交互重放必须懂这些，否则「确定性」是空谈。

知识融合的关键节点：

1. 接口即协议：把「游戏对象语义分组」当成网络协议一样设计，让评估方与被评方解耦——这是游戏领域知识与分布式系统思维的融合点；
2. 对照实验移植到基准设计：no-input 对照与 code-only/Hybrid 配对，都是把因果推断的对照思想变成基准构件——这是实验方法论与 benchmark 工程的融合点；
3. S/M 标注的洞察：意识到「GUI 有用」是混淆了两个变量的复合命题，用规格来源标注把它拆开——这是心理测量学（构念分解）与 agent 研究的融合点。

八、论文中可以提取的通用性灵感

灵感一：评估交互系统，运行它的受控行为，别看它的表面。视频/截图是行为的有损压缩，状态断言才是无损通道。论文证据：缺陷检出 94.25% vs 75.40%；GameLogicBench「终态合法但中途违规」同理。推广场景：机器人技能评估（断言关节/传感器状态而非看回放视频）、数据分析 pipeline 评估（检查中间数据而非最终图表）、UI 回归测试、多 agent 协作审计（检查消息契约状态而非聊天记录外观）。

灵感二：用「接口标准化」换「评估确定性」，而不要求实现标准化。只规定可观测语义分组，不规定内部实现——等价实现同判，确定性无损。论文证据：gb_* 分组使 probe 在任意实现上运行。推广场景：插件生态质量审计（规定遥测接口而非代码规范）、模型互操作评估（规定输入输出 schema）、API 兼容性回归、数据 pipeline 的 DataFrame 列契约。

灵感三：把「能力价值」的归因问题做成配对对照 + 分层标注。「加了 X 通道效果更好」是混淆命题；给任务标注「该通道信息是否唯一可得」，增益应集中在是的那层。论文证据：S 任务 +0.0 vs M 任务 +42~48pp。推广场景：RAG 系统中检索通道价值的归因（标注答案是否只在外部文档）、工具调用 agent 中工具价值分层（标注任务是否必需该工具）、多模态教学中视频/文字分层、A/B 测试中渠道增量测量。

灵感四：防作弊检查要针对「不依赖输入的伪成功」设计。对照组（去掉关键输入后系统应失败）是比「看起来对」强得多的通过标准。论文证据：no-input 对照防「自动演示动画」；GameLogicBench 突变体防「缺能力实现」。推广场景：RL 环境 reward hacking 防御（去动作对照看 reward 是否仍增长）、学生作业查重（零输入运行测试）、安全审计（空负载对照）、推荐系统离线指标校验。

灵感五：视觉/多模态信号的价值要区分「确认」与「恢复」。前者提高的是信心，后者提高的是信息量；只有后者值得付出通道成本。论文证据：视频只提升视觉呈现（+6.48/+9.00）而降内容（−6.01/−9.93）；GUI 增益集中于规格恢复任务。推广场景：自动驾驶遥操作（何时必须看画面 vs 传感器足矣）、代码审查中截图附件的价值分层、数据标注质检抽样策略、医疗影像 AI 的二次阅片制度设计。

灵感六：好的基准同时是训练信号源。确定性验证器天然给出可微调/可强化学习的监督源。论文证据：SFT 11.1%→33.3%（gold-replay 前缀）。推广场景：企业内私有任务基准沉淀训练数据、机器人技能课程的课程学习源、教育自适应练习生成、合成数据的验证式过滤。

一句话收束：SWE-Game 与 CUA-SWE 从「对象扩展」（游戏）与「通道扩展」（GUI）两端逼近同一个结论——软件工程评估的下一站不是更聪明的裁判，而是让确定性验证器跟着交互边界一起扩张；而 GUI 通道被证明的价值，恰恰是它能把「只存在于运行中之物」重新带回可验证的世界。