SWE-Game: 编码智能体能构建我们想要的游戏吗？

TL;DR SWE-Game 用 247 个 Godot 游戏开发任务（含修复、移植）评测编码智能体，结果表明即使最强模型 Opus5 总分也不到 60/100，系统暴露了需求遗漏与逻辑错误等关键短板。

问题

问题背景

软件工程智能体评估正从函数级代码生成扩展到复杂交互式软件开发，游戏开发因其需求多样性、运行时交互和视觉呈现成为衡量通用编码能力的新场景。

现有方法局限

传统代码基准如 HumanEval、SWE-bench 主要验证函数级正确性或仓库级补丁，缺少对持续运行行为的观察：

• 无法判断 agent 是否根据设计文档实现了可玩机制，还是只生成了静态代码片段。
• 游戏特有的视觉表现、物理交互、跨引擎移植等维度未被覆盖，自动评估常退化为人工审查或弱启发式，难以规模化。

为什么这个问题难/重要

游戏是连续交互系统，状态空间远大于单步代码任务。从 brief 到可玩游戏，agent 需完成需求解读、引擎 API 使用（如 Godot、Unity）、动态 bug 调试和体验验证，涉及全链路软件工程能力。
自动评估需同时结合运行时状态检查、参考输入回放、agent 自演示和视觉评价，技术挑战显著；业界对游戏辅助开发和生成式 agent 的关注持续上升，该基准可揭示当前模型在长程规划、跨引擎语义保持上的真实短板。

行业类比

类似自动驾驶评估从单帧感知转向仿真轨迹闭环验证，游戏开发基准也需要从静态代码检查升级为运行时证据与视觉评估的融合，才能可信度量 agent 的实际交付质量。

核心洞察

• 评估范式从代码正确性转向运行时行为验证。SWE-Game 引入可执行检查、参考输入回放和 agent 自创演示，在 100 个 agent 构建游戏的人类标注行为上，可执行检查的平衡准确率达 92.59%，显著高于视频 VLM 判断的 78.41%。与 HumanEval 或 SWE-bench 依赖单元测试或补丁对比不同，该基准强调游戏机制的可玩性与交互正确性，对工程化评估交互式软件有直接借鉴意义。
• 任务设计通过五种开发模式暴露模型在需求理解与长程实现上的系统性短板。尽管 Opus5 在所有任务类型领先，但三个构建任务最佳总分低于 60/100，Brief-to-Game 仅 50.38；失败分析指出需求遗漏和玩法逻辑错误是主因。这表明当前编码 agent 在从模糊需求（brief）或设计文档生成可玩游戏时，缺乏需求抽取与游戏状态管理能力，与短片段代码生成基准的乐观结果形成反差。

方法

输入与任务构造

SWE-Game 基于 41 个可执行的 Godot 参考游戏，覆盖 13 种玩法类别（2D/3D），生成 247 个任务。任务分五种类型：Brief-to-Game（从简短开发简报实现）、GDD-to-Game（从游戏设计文档实现）、Skeleton Completion（完成代码骨架）、Bug Repair（修复 83 个注入故障）、Godot-to-Unity Porting（移植到 Unity）。输入包括上述材料及参考游戏的代码、资产和可执行文件。

关键模块：游戏 instrumentation 接口

提供共享的 instrumentation 接口，允许评估器拥有的 drivers 和 probes 在运行时执行动作并观察游戏状态，与被评估游戏实现解耦。该接口支持 engine-state checks、certified reference-input replay（使用认证参考输入回放）和 agent-authored feature demonstrations（代理编写的特征演示），用于客观评估机制正确性和可玩性。

输出与评估协议

输出为代理编写的游戏代码、修复后的代码或移植代码。评估结合多种证据：引擎状态检查验证内部状态是否满足预期；参考输入回放验证行为是否与原版一致；特征演示验证代理能否展示所要求的功能。此外，每个游戏配有 vision-language rubrics 单独评估视觉呈现。各任务类型有模式化评估标准，最终聚合为 0-100 分。

实验与有效性

六个模型测试中，Opus5 在所有任务类型中得分最高；构建类任务最高总分低于 60，Brief-to-Game 达到 50.38。失败分析显示需求遗漏和玩法逻辑错误是主要问题。在 100 个人工标注行为上，可执行检查的平衡准确率为 92.59%，视频 VLM 判官为 78.41%；视觉评分与人类评分的 Spearman 相关系数为 0.829，表明运行时证据结合视觉评估的可靠性。

与同类方法差异

不同于 SWE-bench 等聚焦代码修复的基准，SWE-Game 覆盖游戏开发全流程，强调运行时可交互证据与视觉评估的结合，更贴近实际游戏开发的多模态和交互性需求。

实验

实验设计

SWE-Game 构建了 247 个任务，基于 41 个可执行 Godot 参考游戏，覆盖 13 类玩法（2D/3D）。任务类型包括 Brief-to-Game、GDD-to-Game、Skeleton Completion、Bug Repair、Godot-to-Unity Porting。评估协议融合 engine-state checks、certified reference-input replay、agent-authored feature demonstrations，视觉表现用 game-specific vision-language rubrics 单独打分。评估了六种模型。

关键发现

Opus5 在五类任务上均取得最高综合分，但三项构建类任务（Brief-to-Game、GDD-to-Game、Skeleton Completion）最佳总分仍低于 60/100，其中 Brief-to-Game 为 50.38。对 100 个 agent 构建的游戏进行人工标注行为验证，可执行检查的平衡准确率 92.59%，显著高于视频 VLM judge 的 78.41%。基于 200 段游戏视频的 rubric 视觉评分与人类评分 Spearman 相关系数 0.829。分析发现需求遗漏与玩法逻辑错误是主要实现问题。

与基线对比及工程启示

可执行检查比视频 VLM 判断更可靠，说明 runtime evidence（引擎状态、输入回放）比纯视觉观察更能捕捉游戏机制正确性；视觉评估虽相关度高，但仍不如执行级验证。模型在构建任务中得分偏低，揭示从自然语言需求到可玩游戏存在显著差距，编码 agent 当前需要更强的需求理解和逻辑推理。这对实际工程意味着：评估游戏 agent 应结合运行时证据和视觉评估，避免单一视频评判；同时可优先提升需求解析与游戏逻辑生成环节。

行业影响

落地场景

SWE-Game 基准揭示了 coding agents 在游戏开发中的当前能力边界。工业界可直接用于：

• 游戏原型生成：AI 编码助手（如 GitHub Copilot 扩展）根据自然语言 brief 或 GDD 生成 Godot/Unity 可玩原型，帮助独立团队快速验证玩法。
• 自动化 QA：利用 agent 修复注入的 bug，并通过 instrumentation interface 执行回归测试，减少人工测试成本。
• 跨引擎移植：Godot 到 Unity 的自动移植任务可降低多平台发布的技术门槛。

商业价值

• 降本：缩短原型迭代周期，减少重复性编码和初级 QA 人力投入。
• 增效：快速产出可玩版本，让团队聚焦创意与关卡设计；automated feature demonstrations 辅助设计评审。
• 体验提升：通过 vision-language rubric 自动评估视觉表现，帮助筛选高质量原型。

与现有工作流集成

• CI/CD 门禁：将 SWE-Game 的 evaluation protocol（engine-state checks、certified reference-input replay、agent-authored demos）嵌入游戏项目流水线，作为代码合并前的质量检查。
• Agent 框架对接：基于 shared instrumentation interface，现有 coding agent（如 SWE-agent、OpenHands）可直接操作 Godot/Unity 环境，无需修改引擎源码。
• 视觉评估插件：将 game-specific VLM rubric 集成到美术或设计工具中，自动为游戏截图/视频打分。

具体 use case

• 互动营销小游戏：电商或内容平台运营人员用自然语言描述活动规则，AI agent 生成轻量级 Godot/HTML5 小游戏，快速上线促销活动，降低外包开发成本。
• 游戏开发教学：教育科技平台使用该 benchmark 作为自动化评分系统，学生提交游戏项目后，agent 运行可执行检查并给出玩法正确性与视觉质量反馈，减轻教师负担。

局限

• 评估框架依赖可执行环境与外部 instrumentation，限制了支持的游戏类型。所有 41 个参考游戏必须可执行、可被外部 drivers/probes 驱动，这意味着那些依赖非确定性事件、网络交互或复杂物理模拟的游戏难以纳入。此外，instrumentation 接口可能引入额外开发负担，且可执行状态检查只能验证可量化的机制，对于“趣味性”“手感”等定性维度依赖 VLM rubrics，其与人类评分相关性为 0.829 Spearman，仍有差距，可能导致视觉评估偏差。
• 任务规模与覆盖范围有限。247 任务来自 41 个游戏，平均每个游戏约 6 个任务，可能引入 reference game 特定偏差。13 个 gameplay 类别虽然多样，但主要围绕 2D/3D 核心玩法，未覆盖更广泛的游戏类型（如 MMO、策略回合制、复杂 UI 驱动游戏）。修复任务仅包含注入故障，可能不代表真实 bug 分布；porting 仅 Godot→Unity 单向，未验证反向或跨引擎泛化。
• 当前模型表现普遍较低，最高总分 <60/100，Brief-to-Game 仅 50.38，说明任务难度大，但也可能反映评估标准过于严格或参考实现质量过高，导致 ground truth 偏差。论文未深入分析低分是否源于模型能力不足、任务复杂度、还是评估协议过于苛刻。此外，资源消耗未在摘要中给出，可能对复现和实际部署构成障碍。与现有 SWE-bench 等代码基准相比，SWE-Game 更注重游戏可玩性，但在代码正确性之外增加了视觉和交互维度，可能扩大了指标冲突。