为 Agent 重造一台游戏引擎：南大联合南洋理工提出 VibeGame

来源：市场资讯

（来源：机器之心）

大模型的编码能力让 Vibe Coding 成了软件开发的新常态，“一句话生成 xx 游戏” 也在社交媒体上反复刷屏。但这些刷屏的 demo 有一个共同点：第一个能跑起来的版本，就是终点。

而在真实的游戏开发里，第一个可玩版本恰恰是起点。针对这个问题，近日来自南京大学模式识别实验室（PRLab）的胡文博、李垦、魏佳哲，在司晨阳教授的指导下，联合新加坡南洋理工大学 S-Lab 提出游戏开发智能体框架 VibeGame。研究团队把这一任务定义为 Prompt-to-Game Development：从一句自然语言和一张可选的概念图出发，交付一个完整可玩的游戏工程，并支持用户此后持续修改它。

为此，VibeGame 组建了一支由 8 个专业 Agent 组成的开发团队，并为这支团队从头重造了它脚下的游戏引擎。每个版本都要经过团队自己试玩把关，而每一次成功交付，都会沉淀成让下一款游戏起点更高的经验。

• 论文标题：VibeGame: Prompt-to-Game Development with AI-Native Engine and Self-Evolving Adversarial Agent Team

• 论文地址：https://vibegame.tettet.org/technical_report.pdf

• 项目主页：https://vibegame.tettet.org

• GitHub 地址：https://github.com/tettethu/VibeGame

一、从 VibeCoding 到 VibeGame，挑战重重

游戏开发本就是软件工程中一个格外困难的领域，一款游戏往往需要美术、策划、程序等多个工种协作数月甚至数年，要实现的一般都不是简单的输入输出关系的叠加，而是一个实时运转的交互世界。现有的 Coding Agent 在开发游戏时暴露出四个核心能力缺口：

• 画不出美术。没有图像生成与后处理工具，Agent 只能拿色块和几何形状搭占位图，仅能验证玩法，但远远达不到游戏素材的美术要求。

• 跟不上帧率。游戏每秒 60 帧，但是 Agent 的思考还是以秒来计量的，它既不能像人一样靠手感试玩，也不能拖着鼠标所见即所得地改场景。

• 进不去引擎。传统游戏行业的引擎和美术工具都是为人类工程师设计的，工程状态散落在层层 GUI 面板与二进制文件中，哪怕接上 MCP 也只能露出有限接口，Agent 调试起来困难重重。

• 读不懂需求。「做一个空洞骑士风格的 Boss 战」—— Boss 有几个技能？攻击节奏多快？玩家挨几下会死？空白只能让 Agent 靠设计经验填，而且很容易踩雷：每个决定单看都合理，拼在一起得到的却不是用户想要的游戏效果。

二、一支会试玩、会互相挑错、

还会自我进化的游戏 AI 开发团队

面对这四个缺口，VibeGame 给出了一台让 Agent 能亲自玩游戏的引擎、一支会互相挑错的 Agent 团队和一座不断积累的可复用经验库。

1. AI-Native 游戏引擎：让 Agent 真正玩得到游戏

今天的游戏引擎都是为人设计的。工程状态散落在编辑器面板、配置系统和二进制素材里，人点几下就能看到的东西，Agent 完全够不着。

VibeGame 的选择是，在 2D 游戏框架 Phaser 之上重新搭一台专门给 Agent 用的引擎。它满足三个条件：

• 一切都是文本。 场景、动画、碰撞、数值这些传统引擎藏在面板和二进制文件里的东西，在这里全是带类型检查的 JSON 格式文件。Agent 改游戏和改代码是同一件事，而且引用了一张不存在的图这类低级错误，游戏还没跑起来就会被拦下。

• 游戏可以被按下暂停键。Agent 能暂停游戏、一帧帧往前推、注入「跳跃」「攻击」这样的操作，再读取状态、截图比对。那个跑得飞快、Agent 根本追不上的实时系统，就此变成了它能按自己节奏检查的对象。

• 源码摆在明面上。 引擎的完整源码随工程一起分发。文档没写清楚、或者版本对不上的地方，Agent 直接去读源代码。

这台 AI-Native 的游戏引擎，第一次让一个游戏工程对 Agent 来说，是完全可读、可写、可验证的。

2. 八个 Agent 的开发团队：自己干的活，交给别人验收

一个 Agent 从头做到尾，等于让它自己判自己的卷子 —— 尤其是画面好不好看、手感跟不跟手这类主观的事，最容易被自己放过去。

于是 VibeGame 组建了一支八人团队：制作人、策划、美术、架构、程序、审计、试玩、验收。团队按一条硬性原则运转：任何 Agent 的产出，都由没有参与生成它的角色来检验，这支团队也被称作对抗式 Agent 团队（Adversarial Agent Team）。

一款游戏从一句话到交付，要走三步：

• 第一步，意图对齐。 制作人先追问用户到底想要什么，策划据此写出正式的游戏设计文档，美术画出概念图定下视觉调子。这两份材料经用户点头，就成了后续所有开发与审查共同对齐的标准。

• 第二步，并行开发。项目拆成代码、美术、策划三条线同时推进。代码要先规划再实现，而且要过两道检查：审计对着设计文档查，试玩进游戏真玩，行为和画面都对上才算完。

• 第三步，对抗修正。 三条线收工后，验收对整个游戏终审：功能、画面、手感，任何一项不合格就附上理由打回，转成修复任务重新进入开发，直到过关。全程默认自动，用户也随时可以插话，反馈会带进后续开发。

第一次交付不是终点。用户随时可以回来提新要求，团队先读懂已有工程，判断哪些保留、哪些重写，再按改动大小决定：小改直接动手，大改重走完整流程。

3. 免训练自我进化：越用越强，越用越默契的游戏开发团队

每交付一款游戏，团队都会把验收过的经验沉淀成三类资产：

• 骨架（Skeleton）：某类游戏的可运行模板，保留工程结构和调好的参数。

• 组件（Module）：状态条、小地图这类跨项目通用的功能，自带检查逻辑。

• 契约（Contract）：记录做某类功能时各角色怎么配合，比如做一张地图，策划、程序、美术、试玩各交付什么。

下一个项目开工时，相关资产会被检索出来当起点，但不是照搬 —— 它们必须在新项目里重新适配、重新验证过才能用。整个过程不更新任何模型参数，团队靠积累项目历史、代码库和合作经验变强。于是每交付一款游戏，下一款的起点就高一点。

三、从一句话造游戏，到给成品动手术：

VibeGame 的多场景实战

VibeGame 可以在各种情况下处理用户的请求，涵盖从零创作、参照概念图开发，以及对已有游戏的任意扩充与创意修改。

游戏创建（Game Creation）

只需几句话描述玩法，系统便自行补全设计、代码与美术，交付完整可玩的游戏工程；附上一张概念图，角色、场景和配色还会对齐它的风格。

游戏编辑（Game Edit）

用自然语言对同一个项目提出任意修改：小到整体换皮，大到把回合制改成实时动作、让玩家和 Boss 互换身份，系统都在已有工程上改，不从头再来。

结语

回头看，VibeGame 做对的是三件事。

它没有把 Agent 接到现成的引擎上，而是从地基重造了一台。 工程全是文本，游戏能被按帧暂停和推进，源码全部摊开给 Agent 看…… 这些设计让 “改游戏” 第一次和 “改代码” 一样完全可控。

它没有让一个 Agent 从头干到尾，而是让八个角色互相制衡。 试玩 Agent 是真的进游戏里玩了一遍，验收 Agent 是真的盯着画面挑毛病，不合格就附上理由打回重做。

它也没有让经验随项目一起蒸发。 骨架、组件、契约被留了下来，不更新任何模型参数，团队却能一款比一款做得顺。

当开发、测试、迭代、进化被连成一个闭环，“一句话生成游戏” 的终点，就成了游戏开发真正的起点。而这个起点，属于每一个想做游戏的人。