游戏里的AI，终于学会了"边看边想边动手"
你有没有想过，一个能打游戏的AI，到底应该先学会什么？
如果你去问市面上大多数游戏智能体，它们的答案基本一致：看画面，然后决定按什么键。这套逻辑听起来天经地义,毕竟人类玩游戏不也是这样吗？看到怪物冲过来,手指头就本能地按下攻击键。
但这里藏着一个容易被忽略的问题。这些AI只学会了"看到A就做B"，却从来没有真正理解过，做了B之后，这个世界会变成什么样。它们更像是训练有素的反射弧，而不是真正理解游戏世界运作规律的玩家。
与此同时，另一群研究者走了完全相反的路。他们造出了能预测游戏画面变化的"世界模型"
**世界模型**：一种能够根据当前状态和动作，预测未来画面或环境状态会如何变化的AI模型，简单说就是"知道按了这个键之后，世界会变成什么样"的模型
这些模型非常擅长回答"如果按了W键，下一帧画面会是什么样"，但它们有个致命缺陷：动作必须由外部提供。它们自己不会决定该按哪个键,只会老老实实地预测"如果你这样按，会发生什么"。
一边是知道怎么按键、但不知道按键会带来什么后果的行动派，一边是知道按键会带来什么后果、但不知道该按哪个键的预测派。复旦大学、LIGHTSPEED等机构的研究者们琢磨出了一个想法：为什么不把这两种能力合在一起？
于是GameWAM诞生了，这是第一个真正意义上把"预测世界怎么变"和"决定怎么操作"捏合成一个模型的游戏AI系统。它同时生成两样东西：接下来的游戏画面，和接下来该按的键盘鼠标动作。
想要"既懂又会"，到底难在哪
这个想法听起来简单，做起来却处处是坑。
先说动作这一头。你在玩Minecraft的时候，游戏操作其实分裂成两种完全不同的模式。一种是普通玩法，你按着W前进，鼠标划一下转视角，偶尔按下鼠标左键攻击一只僵尸，这里面既有需要一直摁住的连续按键，也有瞬间触发的点击，还有连续变化的摄像机转动幅度。另一种是打开物品栏，用鼠标精确地把一块木头拖到合成格子里，这时候鼠标动作的含义完全变了，它不再代表转视角，而是代表精确的坐标定位。
这就好比同一个方向盘，在赛车游戏里控制的是车头朝向，在停车场模拟游戏里控制的却是精确停车的角度。物理上是同一套输入设备，但背后的统计规律天差地别。如果把这两种情况混在一起用同一套概率分布去建模，就相当于让一个只学过赛道漂移的司机去停车，他的肌肉记忆会不断把细致的停车动作做成夸张的甩尾。
GameWAM给出的解法是让模型自己学会"判断当前是在打怪还是在开菜单"，然后针对两种情况分别用专门的预测头去生成动作，同时对连续的数值（比如摄像机转动幅度）做模式专属的归一化处理。这个判断是逐个动作时刻做的，不是一次性给整段轨迹贴标签，这样即使玩家在几秒钟内从战斗切换到开箱子，模型也能跟上节奏。
再说时间这一头，这个问题更隐蔽，但同样致命。
游戏画面变化极快，如果每一帧都拿去做预测和存储，计算量会爆炸。所以现有的一些做法会稀疏采样，比如每隔几帧才看一次画面。但游戏里的关键事件往往稍纵即逝：一次精准的连招、一个突然冒出来的敌人、一次快速的镜头转向，如果采样太稀疏，这些瞬间可能直接被漏掉，就像用慢动作相机拍高速球赛，你可能连球进没进都看不清。
那把采样调密一点不就行了？问题是，在固定的计算预算下，采样越密，能覆盖的时间跨度就越短。这就像你手里只有一卷胶卷，拍照拍得越勤，能记录的时间段就越短。这直接影响两件事：模型能往前看多远（预测未来的窗口），以及模型能记住多久之前发生的事（历史上下文的长度）。
GameWAM对这两个子问题分别给出了应对方案。
计划得远，执行得近：块循环控制机制
先说"往前看多远"这件事。
GameWAM采用了一种叫做**块循环控制**的机制
**块循环控制（Block-Cycle Control）**：模型在每次决策时预测未来一段较长的动作序列，但只真正执行其中开头一小段，执行完之后重新观察环境再继续规划的控制方式
具体来说，模型每次会规划P步动作，但只提交执行前E步，E比P小很多。执行完这E步之后，模型拿到最新的游戏画面，重新规划接下来的动作，如此循环。
这个设计其实是在权衡两种需求的冲突。如果每次只规划很短一段就立刻执行，模型的"眼光"会很短浅，缺乏对未来趋势的把握，容易做出局部最优但整体糟糕的决策。但如果规划一大段就把整段全部执行完才去看新画面，那模型在这一大段时间里就完全是"闭眼开车"，中间发生的任何变化都无法及时响应，比如敌人突然从侧面绕过来了，模型却因为还在执行之前的规划而毫无察觉。
如果不做这种预测和执行的解耦，会发生什么？想象一个司机在高速公路上开车，如果他把整条路线一次性规划好然后闭着眼睛按照规划开完全程，中途出现的任何突发状况，比如前车急刹车，他都无法反应。但如果他每开出去一米就得停下来重新看路重新想接下来该怎么开，那车速会慢得离谱，根本无法应对高速变化的路况。块循环控制找到了中间地带：看得远一点用来判断大方向，但只信任并执行最近的一小步，走完立刻重新观察再决定下一步。
这套机制还带来一个训练上的好处。因为完整的游戏轨迹数据是提前录制好的，训练时不需要真的一步步地模拟这个"规划-执行-重新观察"的循环过程，而是可以把多个重叠的规划窗口平行地铺开进行监督学习，效率高了不少。
记住重要的，压缩不重要的：分层视觉历史
再来说"能记住多久以前"的问题。
GameWAM设计了一套**分层历史记忆**结构
**分层历史记忆（Hierarchical Visual History）**：将最近发生的观察保留得比较详细，把更久以前的信息逐渐压缩概括，从而在有限的存储空间里兼顾细节和跨度的记忆机制
具体的做法是，最近执行过的几段观察会被完整编码保留下来，形成一个"最近记忆缓冲区"。一旦这个缓冲区满了，最旧的那一段就会被"挤出去"，但不是直接丢弃，而是通过注意力机制压缩进一组更长期的记忆槽位里，这些槽位有不同的时间尺度，有的负责记住几个周期以前的事，有的负责记住更久远的事。
这个设计的直觉其实很朴素。你回忆一下自己怎么记事情的：五分钟前发生的对话，你能几乎逐字复述；一周前的某次会议，你只记得大致主题和几个关键决定；一年前的某天，你可能只留下一个模糊的印象，比如"那段时间挺忙的"。人脑并不是对所有历史信息做等量的存储，而是让最近的信息保持高清晰度，越久远的信息压缩得越厉害，这样才不会被信息量压垮，同时又不至于完全遗忘。
如果不做这种分层压缩，只用一个固定大小的缓存来存所有历史，会怎样？要么缓存很快被塞满，模型彻底丧失对更早历史的访问能力，一旦某个任务需要几十秒前的信息才能做出正确判断，模型就抓瞎了；要么把缓存做得极大以容纳足够长的历史，但计算和存储成本会随着游戏进行不断膨胀，最终变得不可持续。分层记忆用一个巧妙的折中方案解决了这个矛盾：容量固定，但信息按照时间远近做梯度压缩。
论文里还专门设计了一个辅助训练目标，让这套压缩后的历史记忆去预测当前画面的视觉特征，目的是防止压缩过程把有用的信息全部丢光，逼着模型学会"该记住什么"，而不是随便压缩了事。
一套物理输入，两种解读方式：交互模式路由
前面提到过游戏玩法和GUI界面操作共享同一套键盘鼠标接口，但语义完全不同。GameWAM为此设计了一个**逐步路由器**
**逐步路由器（Per-step Action Router）**：在每一个动作时间点上，模型会先判断当前应该按照"打游戏"还是"操作界面"的规则来生成动作，然后调用对应的专门预测分支
这个路由器的工作方式，有点像一个双语翻译在两种语言间无缝切换。假设你在跟一个既会说中文又会说英文的朋友聊天，对方能根据你说话的语境自动判断该用哪种语言回应你，而不需要你先明确宣布"我们现在切换成英文对话"。GameWAM的路由机制也是这样，它逐个时间步地判断当前处于哪种交互模式，然后调用对应的动作生成分支，整个过程发生在同一条生成轨迹内部，不需要切换模型，也不需要外部指令强制介入。
训练阶段，真实标注的交互模式标签会告诉模型"这一步其实是在打怪"或者"这一步其实是在开菜单"，模型据此学习路由判断，同时用这个标签去挑选对应的监督分支进行训练。到了实际运行阶段，模型自己预测的路由结果就会决定用哪个分支来生成动作。
如果不做这种模式区分，把两种交互统一用一套概率分布去建模会怎样？论文里的消融实验给出了答案：统一动作分布的版本，在GUI任务上的成功率是35.0%，而分模式处理的完整版本达到了43.0%,整体平均分从38.3掉到了50.7，落差非常明显。这说明混在一起处理确实会让摄像机运动的统计规律和鼠标点击的统计规律互相干扰，谁都学不干净。
视觉预测和动作生成怎么协作又不互相拖累
模型架构上，GameWAM用了两套并行的**扩散变换器**
**扩散变换器（DiT，Diffusion Transformer）**：一种结合了扩散模型生成能力和Transformer架构表达能力的生成模型，常用于图像和视频生成任务
一套叫Video DiT，负责生成未来的视觉画面；另一套叫Action DiT，负责生成对应的键盘鼠标动作。两者都用了**流匹配**的训练方式
**流匹配（Flow Matching）**：一种通过学习从噪声到目标数据分布之间的连续变换路径来训练生成模型的方法，是扩散模型的一种替代或改良训练范式
这里有个很关键的设计决定：Video DiT和Action DiT在处理"已经发生的、确定的"历史信息时是共享的，都能看到同一份干净的视觉上下文；但在处理"正在生成中的、还不确定的"未来内容时，两者是解耦的，动作分支不会去看那个正在被同步去噪的未来视频，视频分支也不会去看正在被同步去噪的未来动作。
这个设计乍一看有点反直觉。既然要"联合建模"，为什么反而要把两个还没生成完的东西隔开不让它们互相看？论文里做了对照实验来回答这个问题，把两者的噪声表示也连在一起处理，让它们能互相"偷看"对方还没生成完的部分。结果显示，这种完全打通的版本在MCU全量任务集上的平均成功率是39.6%，而默认的模态解耦版本是46.6%，差了整整7个百分点，尤其是在战斗类任务上差距最大。
更有意思的发现是，打通版本训练时动作损失下降得更快，但视频预测质量反而变差了，尤其是在快速运动的战斗场景里，生成的画面明显更模糊。论文作者猜测这可能是一种优化过程中的"资源争夺"：让两个还没完全确定的信号互相纠缠在一起学习，动作分支占了便宜，学得更快，但视频分支的优化过程被拖累了，尤其是在视觉变化本来就很难预测的高速场景里，这种争夺会更严重。
这就像两个人合租一套房子，如果他们完全共享所有资源包括收入，看起来更"团结"，但实际执行起来，手快的那个人容易在关键时刻抢占共同资源，导致另一个人的长期计划总是被打断。而如果各自管理自己的开销，只在必要的公共账目上对齐，反而能让两人的长期规划都更稳健。GameWAM选择的正是后一种方案：动作和视频各自独立生成，但共享对"已经确定发生的历史"的理解。
这个设计带来的额外好处是推理速度。因为动作生成不需要依赖对未来视频的同步去噪，在只需要生成动作的在线推理场景中，可以直接跳过未来视频的迭代去噪过程。实测显示，模态解耦版本的在线执行频率达到12.51赫兹，而联合版本只有8.12赫兹，快了大约1.54倍。这对需要实时响应的游戏控制来说，是个不小的优势。
事件密集处的数据要多采，稀疏处的少采
支撑模型训练的数据构建同样花了不少心思。GameWAM综合使用了三类数据：常规的VPT游戏轨迹（提供广泛的自然交互覆盖）、基于事件锚定重新组织的VPT数据（围绕挖矿、合成、战斗等关键交互事件构建的片段）、以及脚本生成的GUI操作轨迹（补充界面交互的覆盖面）。
**VPT（Video Pretraining）**：一种从大量未标注的Minecraft游戏视频中学习行为的预训练方法，最早由OpenAI提出
在事件锚定数据的采样策略上，研究者们注意到一个现象：一段长长的游戏录像里，真正有信息量的片段往往集中在事件发生的前后，比如一次成功的挖矿或者一次战斗击杀，而录像中大量的时间可能只是角色在漫无目的地走路或者转视角，这些片段对训练来说帮助有限。
如果对整段录像做均匀采样，会把大量的训练资源浪费在这些"无聊"的片段上。这就好比你在剪辑一部两小时的纪录片，如果均匀地从头到尾每隔十分钟截一帧图当作代表画面，你很可能截出来的都是过场镜头，真正精彩的高潮部分反而因为持续时间短而被漏掉。GameWAM的做法是在事件锚点附近提高采样密度，离事件越远采样越稀疏，这样既能重点覆盖关键的行为转变时刻，又不会完全丢掉周围的背景信息。
结果说话：更少的操作，更高的成功率
理论说了不少，实际效果怎么样呢？
在Minecraft的MCU基准测试上，GameWAM在Mini任务子集上达到了50.7%的平均成功率，在包含超过800个任务的完整测试集上达到46.6%，这两个数字都是所有对比模型里最高的。
更值得关注的是效率对比。GameWAM完成一个具体任务平均需要的原生交互步数，在具身类任务上是138步，GUI类任务上是155步，战斗类任务上是203步，全面低于所有对比方法，很多方法完成同样任务需要三四百步。这意味着GameWAM不仅做得对，而且做得更"利落"，不会做很多无效或重复的操作。
|任务类别|指标|GameWAM|次优方法|
|---|---|---|---|
|具身任务|步数（越少越好）|**138**|287（OpenHA）|
|具身任务|全量成功率|47.5%|**50.4%**（Game-TARS）|
|GUI任务|全量成功率|**60.0%**|39.1%（Game-TARS）|
|战斗任务|步数（越少越好）|**203**|316（OpenHA）|
在ViZDoom这个第一人称射击游戏测试环境里，GameWAM在四张地图上的平均奖励都超过了对比的Game-TARS模型，也超过了一些通用多模态大模型如GPT-5、Gemini-2.5-Pro在这个任务上的表现，在Battle 1地图上甚至达到了43.12的平均奖励，远超第二名的18.87。
论文还做了一个有趣的跨游戏迁移实验：直接把Minecraft训练好的GameWAM模型，不做任何针对性训练，拿去玩另一款体素风格的游戏VoxeLibre。结果整体成功率达到59.2%，其中砍树任务成功率高达85.0%。这说明模型学到的一部分底层视觉-动作控制能力，确实具有一定的跨游戏泛化性，不完全是对特定游戏画面的死记硬背。
一个意外发现：随机噪声竟然会"暗中操控"摄像机方向
在做实验的过程中，研究者们碰上了一件挺诡异的事。
生成式模型在采样时，通常需要一个随机的噪声起点，你可以理解为一次"投骰子"，决定了最终生成结果的具体走向。按理说，只要给定的场景条件（游戏画面、任务指令等）不变，换一个随机噪声起点，顶多是生成的动作细节有些许差异，方向上不应该有系统性的偏差。
但研究者观察到，如果在连续多次重新规划时反复使用同一个噪声源，某些特定的噪声实现会导致模型持续朝着某个方向转动摄像机，甚至在原地反复打转，严重时几乎无法完成任何任务。而只要每次重新规划时都换一个新的随机噪声，这种诡异的持续偏转现象就基本消失了。
这个现象被命名为**低频动作源印记**
**低频动作源印记（LASI，Low-Frequency Action Source Imprinting）**：采样噪声中的低频时间成分，会在固定场景条件下系统性地引导生成的粗粒度摄像机运动方向，是一种此前未被充分认识的生成式控制模型的失效模式
为了搞清楚这到底是巧合还是真实的因果关系，研究者做了一系列对照实验。他们对生成的动作序列做**离散余弦变换**
**离散余弦变换（DCT，Discrete Cosine Transform）**：一种把时间序列信号分解成不同频率成分的数学工具，低频成分代表整体趋势，高频成分代表细节波动
把噪声源和输出动作都分解成不同频率的成分，然后专门研究低频部分（对应模式0到2）的行为。结果发现，在固定场景条件下，噪声的低频成分和输出动作的低频成分之间存在很强的相关性，偏航角的DCT零阶模式相关系数达到0.890。
更直接的证据来自"移植实验"：把一个噪声样本的低频部分替换成另一个"供体"噪声的低频部分，结果显示，替换之后的输出动作有94.8%的概率会跟着"供体"走，而不是跟着原来的噪声走。而如果直接把低频部分清零，能消除99.25%的原本由噪声引起的输出变化。这三重证据放在一起，基本坐实了这不是巧合，而是低频噪声成分确实在直接驱动生成的摄像机运动方向。
为什么偏偏是低频而不是高频受影响？论文给出的一个合理猜测是，训练数据里真实的摄像机运动本身就带有很强的低频结构，玩家转视角通常是平滑连续的过程，很少有高频抖动。这种数据本身的特性，可能使得模型更容易把噪声里的低频结构直接"投射"到输出的低频运动趋势上，就像一张已经有底纹的纸，你在上面轻轻一画，那些线条会不自觉地顺着底纹的走向延伸。
研究者也尝试了几种在训练阶段直接抑制这个现象的方法，比如加入专门惩罚低频耦合的训练目标，或者强化对场景条件的依赖程度。但这些方法要么会干扰正常的动作学习效果，要么虽然保留了任务表现却依然没能消除低频依赖。目前论文采用的做法是在每次重新规划时都独立重新采样噪声源，这能有效阻断偏差在单次游戏过程中不断累积放大的链条，但并没有从根本上解决这个敏感性问题本身。
写在后面
读到LASI这部分的时候，我最触动的地方不是发现了一个bug，而是这个发现本身的方式：研究者不是在设计阶段主动预见到这个问题的，而是在实际跑闭环评测时，看到某些回合表现异常诡异，才回头去挖出这个隐藏的因果链条。这提醒我一件事，生成式AI系统的很多失效模式，可能根本不会在离线的静态测试里暴露出来，只有真正跑起来、反复交互、让偏差有机会累积，问题才会现出原形。这对整个生成式控制领域可能都是个警示：静态基准测试再漂亮，也不能代替真实的闭环压力测试。
另一个让我意外的细节是，论文里坦诚地写出了他们尝试过的几种"修复方案"都没有真正成功，只是找到了一个能绕开问题的工程补丁，也就是每次重新采样噪声。很多论文在遇到无法彻底解决的问题时，往往会选择淡化处理或者干脆不提，但这篇论文把这个未竟的问题明明白白地列在了局限性部分，还给出了后续研究应该满足的标准："既要防止噪声结构变成持续偏差，又不能压制掉正常的平滑运动和条件相关的动作多样性"。这种把开放问题清晰界定出来的做法，比强行给出一个不完美的解决方案更有价值。
如果一个AI系统的行为，会被它内部随机数生成器的某次具体取值悄悄操纵，那我们该如何定义这个系统的"意图"到底是什么？
Q&A
Q1：GameWAM是什么？
A：GameWAM是复旦大学、LIGHTSPEED等机构提出的首个用于原生闭环游戏和GUI控制的世界-动作模型，能同时生成未来游戏画面和可执行的键盘鼠标动作，在Minecraft和ViZDoom上都取得了具有竞争力的表现。
Q2：低频动作源印记（LASI）是什么现象？
A：这是研究者在GameWAM闭环测试中发现的一种失效模式，指采样噪声中的低频成分会在固定场景下系统性地引导摄像机运动方向，反复使用同一噪声可能导致角色持续偏转甚至原地打转，重新采样噪声可以缓解但无法根治。
Q3：GameWAM相比其他游戏AI有什么优势？
A：GameWAM在Minecraft MCU基准测试上以更少的执行步数取得了更高的任务成功率，例如具身任务只需138步，全面低于对比方法的三四百步，同时在GUI和战斗类任务上的成功率也位居前列。