GameXpert-Bench: 编程代理距离专家游戏开发还有多远？

# 编程代理距离专家级游戏开发还有多远？
来源：https://arxiv.org/html/2608.21833

**作者**  
贺浩荣、高佩忠（清华大学）  
林剑峰（香港科技大学）  
罗同旭（香港中文大学（深圳））  
谢宇轩、刘晨旭、何洁灵、刘中元、曾泽霖（腾讯光子工作室群）  
[0.6em] 混元团队（腾讯）  
[0.3em]同等贡献。†通讯作者。

---

#### 摘要  
近年来，大语言模型（LLMs）能够作为编程代理，根据自然语言请求构建完整的游戏。游戏开发要求极高，因为程序逻辑、视觉与音频内容、界面、交互性和可玩性必须协同运作于一个可执行文件中。因此，衡量这种能力需要同时评估游戏产品和开发过程。现有基准测试通常通过评估最终产物或孤立开发阶段来评价LLMs的游戏开发能力。

通过对完整的人类-代理开发轨迹的分析，我们识别出三个共同构成编程代理游戏开发生命周期的阶段：初始游戏生成、错误诊断与修复，以及多轮优化。因此，我们提出了**GameXpert-Bench**，它将这三个生命周期阶段操作化为三个互补的基准测试轨道：
- **GameGen**评估在空白工作区中根据单一请求创建完整游戏的能力。
- **GameFix**评估当缺陷被报告或由代理发现时进行的诊断与修复。
- **GameOpt**评估基于真实开发轨迹的请求链所进行的累积优化。

我们使用实时游戏交互、确定性行为测试或带有回归检查的最终产品标准来评估每个轨道。该套件包含：
- 11个类型的97个生成任务；
- 来自50个游戏关卡的100个修复任务（由人类验证），每个关卡注入19–27个缺陷；
- 17个优化链，包含6轮对话共102个请求。

在所有三个轨道中，当前代理在生成可玩基础和实现明确需求方面更可靠，而在发现缺陷、验证运行时行为以及在不同修改中保持功能一致性方面则较弱。这种不对称性表明，仅凭初始生成质量不足以全面表征代理的游戏开发能力。

---

**图1说明**：GameXpert-Bench 及其三个评估轨道的概览。  
- **GameGen** 评估从自然语言需求创建游戏；  
- **GameFix** 评估对受损参考游戏的修复；  
- **GameOpt** 评估基于人类反馈的多轮游戏优化。

---

## 1 引言

大语言模型（LLMs）作为编程代理的能力日益增强，使得游戏开发成为评估其综合能力的重要测试平台。近期系统能够在现有项目和游戏引擎中实现游戏功能 [5, 15]，并从自然语言规范中生成完整游戏 [11, 24, 16]。然而，仅生成可运行的代码并不足以产生可玩的游戏。游戏逻辑、渲染、控制、界面、视听内容和状态转换必须在玩家交互下协同工作；其中任何一项的失败都可能降低玩家体验甚至导致游戏无法正常进行。这种复杂性使得评估成为核心挑战。

一次成功的构建或一张看似合理的截图，并不能证明控制响应正确、机制在游玩中保持功能，或完成的游戏满足请求。因此，近期基准测试通过浏览器交互、游戏轨迹和多模态判断来执行生成的游戏并评估其行为 [11, 24, 16, 9]。这些方法将游戏评估从静态代码检查转向玩家实际体验的行为层面。

然而，仅评估最终产物无法揭示编程代理的能力如何在产生该产物的交互序列中得到运用。这一局限性促使我们关注开发过程本身，而非仅关注其终点。因此，全面的评估应考虑完整的、面向用户的游戏开发生命周期。

我们定义面向用户的游戏开发生命周期为通过编程代理直接进行的交互序列，从初始请求到最终可玩产物。与包含更广泛组织阶段（如预制作、制作和后期制作）的传统游戏开发框架不同 [1]，此生命周期的范围有所不同。

为推导此生命周期，我们对完整的人类-代理游戏开发轨迹进行了定性分析。通过根据主要意图对改变游戏的交互进行分类，我们识别出三个重复出现的阶段：游戏生成、错误诊断与修复，以及多轮优化。这些阶段共同描述了在观察到的开发过程中可执行文件是如何创建、维护和改进的。

尽管运行时评估有所进展，现有基准测试主要评估最终产物或孤立的开发阶段。如表1 [1] 所示，目前尚无针对游戏的现有基准测试套件同时评估这三个阶段。为解决此局限，我们提出了 **GameXpert-Bench**，它将这三个阶段连接到一个统一的评估框架中。

**表1**：代表性基准测试在本文研究的三个阶段上的覆盖情况。先前工作评估了部分构成能力，而 **GameXpert-Bench** 将游戏创建、验证修复和累积优化置于一个基准套件中。文本标签表示部分覆盖或反馈来源。

---

**图2说明**：GameXpert-Bench 的总体结构。  
- **GameGen** 从自然语言请求开始；  
- **GameFix** 从变异的黄金游戏开始；  
- **GameOpt** 研究基于真实人类交互的多轮优化。

---

### 3.1 编程代理的游戏开发生命周期

传统游戏开发包括预制作、制作和后期制作等广泛组织阶段 [1]。**GameXpert-Bench** 关注通过编程代理直接进行的完整、面向用户的产物生命周期。该生命周期始于用户要求代理创建游戏，终于所请求修正和改进后的最终可玩产物交付。

我们通过对用户与编程代理之间的完整历史开发轨迹进行定性分析来推导此生命周期。我们检查创建或修改可执行游戏的每次交互，并通过迭代编码将其按主要意图分类。澄清、环境设置和其他操作性交流与其支持的开发任务相关联，但不被视为独立的生命周期阶段。解决模糊情况后，分析识别出三个重复类别，共同覆盖了轨迹中观察到的所有产物变化。

**定义：完整的面向用户的编程代理游戏开发生命周期**  
**生成→修复→优化**。  
**生成**根据用户请求创建初始可玩游戏。  
**修复**诊断并修复生成或现有游戏中揭示的缺陷。  
**优化**在保持已建立功能的同时，通过连续请求改进可玩游戏。  
这三个阶段共同涵盖了可执行文件的创建、维护和改进。

图3 [3] 总结了分析中完整轨迹上的产物演变。随着生成、诊断与修复以及优化请求在每个游戏的连续版本上操作，源代码规模并未减小。这一模式表明开发过程具有累加性。

---
（以下内容将继续翻译，但根据用户要求，仅输出翻译后的文本，不附加额外说明。）