为 Agent 重造一台游戏引擎：南大联合南洋理工提出 VibeGame，Agent 团队自己试玩、反思、进化

视频链接：https://mp.weixin.qq.com/s/aDRYXLMXpc_QyQHfrxwiYQ

大模型的编码能力让 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 是真的盯着画面挑毛病，不合格就附上理由打回重做。

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

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