Alaya Lab的研究者如何让AI真正读懂游戏世界的规则

这项由Alaya Lab主导的研究发表于2026年7月，论文编号为arXiv:2607.14076v1，有兴趣深入了解的读者可以通过该编号查询完整论文。

你有没有想过，当你按下游戏里的攻击键，屏幕背后到底发生了什么？角色并不是直接就挥出拳头。游戏引擎得先偷偷查一遍：你的体力够不够？技能有没有在冷却？敌人此刻的姿势能不能被击中？全部确认通过之后，才把对应的画面渲染出来。这套“先查规则、再出画面”的流程，是传统游戏引擎几十年来运转的核心秘密。

然而，人工智能领域正在兴起一条截然不同的思路：能不能训练一个AI模型，让它直接从大量游戏视频中学会这套规律，然后自己充当一个游戏引擎，实时生成玩家操作后应该看到的画面？这种被称为“交互式世界模型”的技术，近年来引发了学术界和工业界的广泛关注，许多人认为它代表着下一代游戏引擎的雏形。

但问题也随之而来：这类AI模型到底做到了什么，又在哪些地方还差得远？Alaya Lab的研究团队决定系统性地审视这个问题。他们以传统游戏引擎的运转逻辑为参照系，把“一个合格的AI游戏引擎应该具备哪些能力”这件事拆解成四个维度，逐一检视现有的各类方法，分析每种方法的优势和局限。与此同时，他们还围绕知名动作游戏《黑神话：悟空》构建了一套数据采集系统，收录了超过90小时的实战游戏录像，每一帧都附带玩家的键鼠操作记录、游戏引擎导出的真实状态数据以及视觉画面，为未来研究提供了一份难得的资源。

一、游戏引擎的“运转秘籍”：一个被大多数AI忽视的循环

要理解这篇研究在说什么，得先搞清楚传统游戏引擎是怎么工作的。可以把它的运转方式比作一场没完没了的接力赛：玩家输入动作，动作传给裁判（游戏状态系统），裁判根据规则判断结果并更新比赛局面，最后画师（渲染系统）把更新后的局面画出来给玩家看。这三个环节——动作、状态、画面——构成一个反复循环的闭环，游戏世界就在这个循环里一刻不停地演进。

关键在中间那个“状态”环节。游戏引擎始终维护着一份精确的账本，记录着场景中每一个角色的血量、体力、所处位置、当前动画帧、装备属性等等。玩家按下攻击键，引擎不是直接生成攻击画面，而是先翻开账本核查——你的体力够发动这个技能吗？对方正处于可被打断的状态吗？攻击判定框和对方的碰撞体积有没有重叠？一切核查通过之后，账本上的数字发生变化，对方的血量减少，动画状态切换，然后渲染系统才把这一切画成画面呈现给你。

可现有的AI世界模型，大多数绕过了这个“账本”环节。它们直接用最近几帧的画面作为参考，预测下一帧应该长什么样。这种方式确实能生成看起来连贯的画面，但它把所有的“规则”都压缩进了像素之间的统计关联，而不是真正理解底层的逻辑。于是就出现了一些根本性的问题：同样是按攻击键，血量充足时和血量耗尽时理应有截然不同的结果，但基于像素预测的模型往往分不清这两种情况；敌人离开视野之后，它的状态在真实游戏中还在持续演变，但AI模型根本不知道屏幕外正在发生什么；某个技能击中之后，伤害结果应该在规定的动画帧数之后才显现，而不是立即跳出数字，但AI的生成时机往往和游戏规则对不上。

Alaya Lab的研究团队把这些问题归结为四个维度：玩家动作控制、游戏状态动态、状态与画面的持久一致性、实时交互生成。以下的内容，就是沿着这四个维度展开的。

二、玩家怎么“说话”，AI才能听懂——动作控制的三种语言

游戏里的玩家输入，其实远比看起来复杂。移动、转镜头，这些是空间几何上的操作；普通攻击、闪避，这些是设备上的按键信号；而“在boss即将发动大招时找准时机完成反击”，这种意图根本没有对应的按键，它需要结合当前的战场状态才能被理解。现有的研究方法，基本上沿着三条不同的路线来处理这个问题。

第一条路线：几何语言

这类方法把玩家的操作理解为摄像机在空间中的运动轨迹，用数学上的旋转矩阵、平移向量或者光线方向来表达“镜头往左转了多少度”。这种方式对于控制视角非常精确，生成出来的画面在镜头移动上表现得相当一致。但问题也很明显：它只解决了“看哪里”的问题，对于“做什么”完全无能为力。而且，要求普通玩家提供精确的摄像机轨迹数据，本身就是一件不切实际的事情。

第二条路线：信号语言

这类方法直接接收键盘和鼠标的原始输入状态——哪些键按下了、鼠标移动了多远——然后把这些信号编码成向量，作为生成下一帧画面的条件。Oasis、Matrix-Game等系统都采用了这个思路。这种方式更接近玩家的真实操作方式，而且对于简单、原子性的操作，比如“前进”或者“射击”，效果相当不错。然而，原始信号本身是语义模糊的。同样是按了某个攻击键，在不同的游戏状态下，它可能触发普通连击、也可能触发技能爆发、还可能因为体力不足而什么都不发生。这种“同一个输入，多种可能结果”的模糊性，让模型很难学到正确的映射关系，尤其是那些需要多键组合的连招技能。

第三条路线：语义语言

这类方法用自然语言描述玩家的意图，比如“向右闪避并发动反击技能”，让语言模型来理解这段文字并驱动画面生成。GameGen-X、Yume等系统走的就是这条路。这种方式最为灵活，甚至可以描述一些传统按键根本无法表达的复杂意图。但随着控制粒度越来越细，所需的语言描述也越来越长、越来越复杂，计算代价会急速上升，实时交互变得困难重重。

三种路线各有其擅长的场景，也各有无法回避的缺陷。几何语言精准但局限，信号语言自然但语义模糊，语义语言灵活但代价高昂。一个真正完备的交互式游戏世界，需要能同时处理这三种层次的控制——这目前还是一个未被解决的问题。

三、AI的“账本”在哪里——游戏状态的三种存在形式

如果说动作控制是游戏引擎的“输入端”，那么游戏状态就是其“核心处理器”。它决定了同样的动作在不同条件下会产生什么不同的结果。现有的AI世界模型，在处理这个问题时大体上走了三条不同的路。

状态藏进像素里

最主流的做法是把状态“藏进像素里”。这类模型完全不维护任何独立的状态表示，只是把最近若干帧的画面作为历史记录，然后根据这些画面加上当前的动作输入，预测下一帧画面应该长什么样。Sora、Wan这样的顶尖视频生成模型，以及游戏专用的GameNGen、DIAMOND等，都走的是这条路。这种做法的好处是简单粗暴、效果惊艳——因为继承了视频生成领域海量数据训练出来的视觉理解能力，生成的画面质量相当高。但坏处同样明显：游戏规则被压缩成了像素与像素之间的统计关系，而不是显式的逻辑判断。血量只剩一格和血量满格时，同一个攻击的结果理应截然不同，但对于一个只看像素的模型来说，这两种情况下的画面输入看起来可能非常相似，模型很难区分。

维护压缩的潜藏状态

第二种做法是维护一个“压缩的潜藏状态”。这类方法在模型内部保留一个紧凑的向量表示，专门用来跟踪游戏世界的整体状况，然后随着每一步操作不断更新这个向量。强化学习领域的世界模型研究，比如著名的Dreamer系列，就是沿着这条路发展起来的。这种方式不需要游戏内部的状态标注数据，可以纯粹从视频中学习，因此扩展性比较好。但问题在于，这个内部向量是什么含义，连训练它的研究者都说不清楚——它捕捉到的是视觉层面的规律，对于那些由非视觉原因（比如血量数值）驱动的视觉变化，它的表现往往不可靠。

用文字写出状态

第三种做法是用文字或符号把状态“写出来”。这类方法用结构化的文本直接记录游戏状态，比如“玩家当前血量720/1000，体力85/100，正在执行重攻击第二段动作”，然后把状态的演变转化为一个语言推理问题，让语言模型来预测下一时刻的状态文本。这种方式的优点是高度可读、可验证——任何人都能看懂这些数字代表什么，也能核查推理是否合理。然而，维护这样的显式状态需要大量带有精确状态标注的游戏数据，而这类数据目前极度稀缺。此外，用离散的文字记录连续动态的游戏画面，本身就存在信息损失，如何把文字状态和高质量的视觉生成真正打通，目前还基本上是一片空白。

四、“离开画面之后，世界还在转”——长时记忆的两种思路

在真实的游戏里，一旦某件事情发生了，它的影响就会永久留存。你把boss打掉了一半血，然后跑开躲避追击，等你回头，boss的血量绝对不会自己悄悄恢复。但对于大多数基于画面预测的AI世界模型来说，画面内能看到的信息才是它所知道的全部——一旦某个物体离开了视野，模型就对它发生的事情一无所知，等它再次出现在画面里时，很可能已经被“悄悄复原”了。

研究人员在这个问题上提出了两大类解决方案，区别在于记忆里存的是“过去发生了什么”还是“现在是什么状态”。

存“过去的照片”

第一类方法存的是“过去的照片”。它们把历史帧画面保存下来，当模型需要参考过去时，就从这个照片库里检索出相关的帧。有些方法按时间顺序索引，越久远的帧存得越压缩；有些方法按空间位置索引，回头看之前去过的地方时，就把当时拍下的照片调出来作为参考。WorldMem、Infinite-World等系统都采用了类似思路。这类方法在场景相对静态的情况下表现不错——你之前看到的那扇门，下次回来还是那扇门。但在动态交互丰富的游戏里，这种方法会遇到根本性的困境：你上次看到那栋建筑时它完好无损，但在你离开的这段时间里，一场技能爆炸把它炸掉了一半，照片库里存的还是完好状态，一旦你回头，模型就可能把那栋完好的建筑“还原”出来，而不是呈现它应有的残垣断壁。

存“当前的推测”

第二类方法存的是“当前的推测”。这类方法的出发点是：既然世界在你看不见的时候还在变化，那就不能只靠存照片，得主动推断那段时间里发生了什么，并更新记忆里的状态。ActWorld、Hybrid Memory等系统走的就是这条路——它们尝试跟踪那些暂时离开视野的动态物体，推算它们在不可见期间的状态演变。这种方式理论上更符合游戏世界的运转逻辑，但代价也更高：推断需要消耗计算资源，推断的准确性也难以保证，而且游戏里的高频交互会产生大量细小的状态变化，每一次都要做出正确的更新决策，这个要求目前还没有令人满意的解决方案。

五、“快”和“准”的两难困境——实时生成的速度与时机

一个游戏世界模型，不只要生成正确的内容，还要在正确的时刻生成出来。这里面其实藏着两个截然相反的要求，很少有研究把它们同时说清楚。

第一个要求是“快”：从玩家按键到屏幕上看到反应，这个延迟必须极短，否则游戏会有明显的迟滞感，影响操控手感。这部分的研究非常活跃，CausVid等工作通过把“需要正向反向同时计算才能生成结果”的双向扩散模型，蒸馏成“只需正向一步步预测”的快速版本，大幅降低了生成每一帧所需的时间。Matrix-Game 2.0等系统进一步把这套技术和游戏动作输入结合起来，在实时速率下完成了交互式画面生成。

第二个要求则更微妙，可以叫做“准时”：不同的游戏事件，有它们各自被设计好的发生时机。一次重攻击，要经历起手动作、判定激活、收招三个阶段，最终的伤害数字不应该在按键瞬间就弹出来，而应该在判定帧结束时才显现。如果AI模型的生成逻辑对这种“事件发生的规定时机”一无所知，它就可能把结果提前展示，或者延迟展示，都会让玩家觉得游戏感觉不对劲。

目前的研究几乎全部集中在缩短生成延迟上，而对“让效果在正确时机出现”这件事几乎没有涉及。Yume-1.5等系统展示了在滚动生成的视频流中动态切换文本指令的能力，但事件触发的具体时机仍然由模型自身的生成先验决定，没有任何机制把它和游戏规则定义的判定时机对齐。这是一个被大多数研究者忽略、却对实际游戏体验影响深远的问题。

六、一套专门为《黑神话：悟空》打造的数据采集系统

研究团队不只是提出了理论框架，他们还针对现有数据的不足，亲手构建了一套数据采集系统。选择《黑神话：悟空》作为目标并非偶然——这款基于虚幻引擎开发的3A动作角色扮演游戏，拥有极高的画面质量和丰富的战斗机制，boss战场景中频繁的攻防交互和持续的状态演变，正是研究游戏世界模型最理想的实验场。

数据采集的核心难题在于如何把游戏画面和游戏内部状态同步对齐。研究团队对游戏引擎进行了插桩改造，让引擎在每一个计算帧（tick）都导出一条结构化的数据记录，涵盖当前帧的玩家输入、摄像机位置和旋转参数、玩家角色与boss的位置、朝向、当前动画状态、技能激活情况，以及血量、体力、攻击力、防御力、装备信息等游戏属性。这些数据以JSON格式实时写入本地文件，每一帧都带有系统时间戳。

在画面记录方面，研究团队采用了一套基于ReShade和OBS Studio的分屏录制方案。ReShade着色器把显示区域分割成若干子窗口，分别呈现RGB彩色帧和深度图，同时通过禁用相关渲染通道把游戏UI界面剥离，保留干净的游戏世界画面。OBS Studio被改造为同步记录每一帧画面对应的系统时间戳，从而和引擎侧的数据记录建立共同的时间基准，实现帧级别的精确对齐。

数据来源是众包玩家群体，他们技术水平参差不齐、游戏风格各异，自然地产生了多样化的行为数据，避免了单一风格导致的数据偏差。最终收集到的数据集包含超过90小时的1280×720分辨率、30帧每秒的游戏录像，并经过时间戳对齐、异常帧过滤、卡顿检测和跨流一致性校验等处理流程，形成了可直接用于模型训练的样本。

在数据标注层面，研究团队还设计了两种形式的文本化描述。第一种叫“槽位标注”，把固定长度时间窗口内的动作和状态记录按照结构化模板转写成文字，保留了所有精确的数值信息，但用结构化文本替代了引擎内部的数字编号。第二种叫“语义标注”，由Qwen3系列的大型视觉语言模型结合采样帧画面和对应的动作状态记录自动生成，用流畅的自然语言描述玩家在这段时间里做了什么以及游戏状态发生了怎样的演变。这两种标注可以分别用作下一状态预测的监督信号和视觉生成的状态条件输入，为未来的状态感知游戏世界模型提供了现成的训练材料。

七、这一切意味着什么——现状的客观评估与未来的方向

说到底，这篇研究做的事情，是在一片热火朝天的领域里冷静地画出一张地图——告诉大家，哪些山头已经被占领了，哪些山头还根本没人去过。

在已经取得显著进展的方向上，玩家动作的接入方式越来越自然，从最早只能处理离散的Atari按键，到现在能够理解键鼠信号和自然语言指令，覆盖范围大幅扩展。可探索的场景质量也在快速提升，最新的视频生成骨干模型已经能够产出接近真实游戏截图水准的画面。生成速度方面，通过蒸馏和流式生成技术的组合，已经有系统实现了接近实时的帧率，这在几年前是不可想象的。

然而，最核心的那个问题——让AI真正理解并执行游戏规则——依然基本上悬而未决。绝大多数模型把游戏状态埋进像素里，把规则压缩成视觉统计，这意味着它们在处理“结果取决于当前状态”这类逻辑时，表现相当不可靠。如何把显式的游戏状态真正纳入生成循环，如何让记忆系统在状态发生变化时做出正确的更新，如何让事件结果在规则要求的时刻而不是模型认为合适的时刻出现，这三件事构成了当前这个领域最迫切需要解决的核心挑战。

研究团队构建的《黑神话：悟空》数据集，正是为攻克这些挑战预备的弹药。在此之前，带有精确状态标注的游戏数据极度稀缺，使得所有想要探索显式状态建模的研究都缺乏充足的训练素材。这个数据集的价值，在于它把游戏引擎内部的完整状态信息和画面录像进行了帧级别的对齐记录，使得研究者第一次可以在一个高质量的真实游戏环境中，直接训练和评估那些把状态作为显式变量的模型。

归根结底，这项研究想说明的是：让AI真正读懂游戏世界的规则，不是一个视频质量的问题，而是一个逻辑理解的问题。生成漂亮的画面已经不再困难，但让AI知道在什么条件下应该生成什么样的画面，仍然是一段相当漫长的路。如果有一天，AI世界模型能够真正复现出“按攻击键 → 查体力 → 判断结果 → 渲染画面”这套游戏引擎的核心逻辑，那才算是真正意义上的下一代游戏引擎。现在的技术，还停在学习游戏“长什么样”的阶段，距离真正理解游戏“为什么这样”，还有一段关键的距离需要跨越。

Q&A

Q1：交互式游戏世界模型和传统游戏引擎有什么本质区别？

A：传统游戏引擎依靠工程师手写的规则运转，每一种游戏逻辑都需要明确编程。交互式游戏世界模型则是通过大量游戏录像训练AI，让模型自己摸索出规律来预测玩家操作后应该出现的画面。前者的规则精确可控，后者免去了手工编程，但目前的AI模型大多只学到了“视觉上应该长什么样”，还没真正学会“在什么条件下应该发生什么”，比如血量不足时攻击应该失败这类逻辑判断仍然不可靠。

Q2：《黑神话：悟空》的数据集和普通游戏录像有什么不同？

A：普通游戏录像只有画面。这个数据集的特殊之处在于，每一帧画面都同步附带了游戏引擎内部导出的完整状态数据，包括角色血量、体力、位置、当前动画状态等精确数值，以及玩家当时的键鼠输入记录。这种“画面加状态加操作”的三元对齐，让研究者可以训练那些需要理解游戏状态才能做出正确预测的模型，而不只是学习画面之间的视觉规律。

Q3：游戏状态“藏进像素里”和“写出来”这两种方式各自有什么问题？

A：把状态藏进像素里的方式，优点是不需要任何额外标注，可以直接从大量视频里学习，视觉质量高，但模型无法真正区分“血量充足”和“血量耗尽”这类只有数值差异的情况，导致相同输入在不同状态下应有不同结果时表现混乱。用文字把状态写出来的方式，优点是逻辑清晰可验证，但需要大量精确的状态标注数据，而且离散的文字描述和连续动态的游戏画面之间如何打通，目前还基本上没有成熟的方案。