米哈游AI大佬揭秘:会说话的NPC与会做游戏的Agent,《崩坏》先行一步?

2026云栖大会上周刚刚落幕，在9月23日上午的“创造·无界：阿里云AI游戏行业论坛”上，米哈游《崩坏》系列 AI NPC & Gameplay 技术团队负责人郑银河，发表了题为《从会说话的 NPC到会做游戏的 Agent，大模型在游戏领域的双向穿透》的演讲。

他主要围绕《崩坏》系列内部AI应用的三大方向进行了分享：AI在游戏玩法上的应用，AI在游戏研发过程中的应用，以及AI和游戏的结合。

AI Gameplay方向，郑银河介绍了《崩坏：星穹铁道》4.2版本上线的“AI帕姆”，支持剧情问答、攻略查询、长期记忆和情绪反馈，还能跟上游戏42天一次的大版本更新。

郑银河透露，米哈游已经围绕 Gameplay场景搭起一整套游戏AI技术栈，从基座模型到游戏里需要的各种玩法。他一并剧透了《崩坏：星穹铁道》在该方向的最新尝试：让AI角色自主博弈、参与交互的桌游玩法。

游戏研发方面，《崩坏》系列内部推出了自研Agent平台EchoX，以及进行了研发流程。可以自己排查问题、找到性能瓶颈并优化，帮助策划快速拼出能玩的白盒Demo，替美术完成提出三视图、更换材质等费时间的重复性工作。

游戏场景与AI深度结合方面，郑银河举例内部曾用《小丑牌》做实验：让Coding Agent先写好脚本，再交给程序执行。有意思的是，Agent自己上网找到《小丑牌》模拟器作弊。目前，在游戏环境里的Agent自进化已经被做进《崩坏：星穹铁道》QA流程。

以下是GameLook整理的完整演讲：

我是银河，很高兴有机会跟大家分享我们在游戏和大模型领域的一些实践和应用。

这次我的分享主要分成三个部分，首先想围绕AI在游戏玩法上的应用，总结起来就是玩家可以体验到的AI内容。第二部分，我们想要去介绍AI在游戏研发过程中的应用，包括很多幕后的工作，它不会被玩家直接感知到，所以说我们把它叫成“玩家看不到的AI应用”。最后我想讨论一下AI和游戏的结合，AI的出现很大程度上提升了游戏体验，也很大程度上提升了游戏的研发效率。但游戏作为一个可控的虚拟场景，它也正在反哺AI研发，这里也会介绍一下我们自己的一些实践。

让我们看一下第一部分，之前在《崩坏：星穹铁道》4.2版本上线的应用“帕姆帮帮”，其实主要叫它“AI帕姆”。它其实有三个核心场景：第一个是说这样萌萌的列车长，他可以给你提供游戏里角色的配队，提供配队、光锥或者遗器的养成方案。当然他还会追踪你的刷级进度，在合适的时候提醒你做相应的刷取；

第二，它支持剧情问答的功能。我们内置了一套完整的《崩坏：星穹铁道》知识库，玩家可以直接询问他剧情内容，比如问人物关系、世界观等背景知识，帕姆都能很好地做出回答；最后就是所谓的情绪的互动，因为把聊天框漏给用户了，不能阻止用户问他任何想要问的事情。我们发现，玩家通常会和帕姆聊一些自己的日常生活，唠唠嗑，就像跟一个老朋友一起聊天。

我们当时做AI帕姆的背后主要有两个核心思考：第一是我们想让游戏系统主动理解玩家，而不是让玩家去理解游戏的系统；第二个思考是，我们想让游戏角色真正的“活”起来，最重要的一点就是不能让角色看起来很人机。

为了解决这个问题，我们从三个层面上做了一些尝试。第一个层面是所谓的“表现层”，我们想让帕姆动起来。实现方法就是AI帕姆在理解对话上下文的同时，它不仅会生成一段文字的回复，它也可以生成精准的表情标签。情绪标签会驱动这个3D的模型动起来，反映更多的一些情绪的反馈。

第二点我们想强调的是所谓的“逻辑层”，让帕姆有一个活人感。因为传统的RAG知识增强的生成，它返回的往往是比较干瘪的事实内容，听起来很人机。我们的做法其实不太一样，在AI生成内容的过程中会额外生成一些跟帕姆人设相关的回复。具体的做法就是找了一个IP同学，我们不断询问他在这种场景下帕姆会怎么回复，直到把同学“蒸馏”到我们帕姆的模型里面。

第三点就是“记忆层”，我们想让帕姆成为玩家真正的专属挚友。记忆是做AI NPC的一个必备条件，帕姆的记忆实现主要分成三个层级。首先是短期记忆，我们会缓存一些当前的对话上下文，保证这次的聊天是流畅的；第二部分是所谓的中期记忆，当对话的轮次到达一定阈值的时候，我们会对对话的上下文做一定的总结，保证关键信息不丢失；最后、也是最重要的一个部分是长期记忆，我们会专门为各个玩家建立自己的一套长期记忆系统。相当于今天的聊天记忆，明天你再找他去聊，他还是能记住的。他可以记住你跟他聊的一些感兴趣的话题、过往的经历之类的。

我们也观察到，很多玩家对长期的记忆系统还是非常感兴趣。很多线上玩家对这个系统乐此不疲，比如有的玩家试图说服我们列车长“三月七是他的女朋友”。我发现他花了几百轮、甚至上千轮的对话去污染帕姆的记忆，最终成功了觉得很高兴，他会在社交媒体上发帖。当然在实现这部分功能的时候，我们也用到了AI千万平台上一些模型的服务。

我们想要分享一下，实现AI 帕姆过程中所面临的一些技术挑战。主要是要对自己的游戏品质有很高的要求，帕姆背后我们建立了一套自己的自研基座模型，并且在做模型对齐的时候，我们设计了数十个不同的Rubric维度保障帕姆回复的质量。既包含了人设一致性、事实的准确性，还有帕姆记忆的相关性之类的各种各样维度。这些维度保证了帕姆的回复可以有饱满的情绪色彩，还保证了他回复的安全。

AI帕姆的另外一个挑战，是让帕姆跟上日常发布的新内容。米哈游大部分的游戏是内容型游戏，42天发布一个新版本，我们不希望新版本发布后帕姆什么也不知道，当然想让他的内容跟上每一个新版本。这里我们使用了一套记忆跟模型相互分离的手段，我们只需要更新记忆库，不需要更新模型，就可以跟上每次发布的新内容。

最后一个、也是最重要的挑战，帕姆上线的时候需要面临上千万的并发玩家，对背后服务的稳定性要求很高。在实现的过程中，我们选择了一个比较稀疏的MoE模型作为自己的基座，背后也配备了很多阿里云的基础组件，这些都是维持帕姆服务稳定的重要部分。

AI帕姆现在已经下线了，之后我们还会上线更多、更好玩的AI Gameplay的玩法。这里给大家透露一下近期的规划和安排：首先围绕 Gameplay场景，我们搭建了一套完整的技术栈，从基座模型到游戏里需要用到的各种能力，最终到搭建出来的各项应用。近期我们也计划在这套技术支持下，在游戏里面上线一个新的AI玩法。

这次的场景不再是一个聊天室，而是想让玩家跟NPC角色来一起打桌游。我们想打造一种线下桌游的体验，在这个过程中角色会有自己的意志。玩家的语言也可以变成桌游上的“武器”——你可以忽悠A去打B，过程中的一些交互也会改变后续桌游场上的博弈。当然，最终玩家和角色的交互会成为他们更深的一个羁绊。

这里展示了我们正在开发的玩法界面，看起来就像真的角色在打桌游一样——玩家可以随时说话，可以得到NPC的回应，甚至NPC会来主动cue玩家；我们也可以在场上开启嘴炮模式，怂恿角色之间打起来。这个玩法正在研发中，后续会上线跟大家见面。这里发生的所有一切不再是固定的剧本，而是你和角色之间产生的真实羁绊。

第二部分让我们深入到幕后，看一下游戏研发过程中AI Agent带来的能力。

为了更好地利用AI Agent技术，我们内部开发了一个自研 Agent平台叫“EchoX”，主要是托管代码Agent和相关工具生态，它可以完成很多复杂的任务。我们还为游戏研发实现了配套的Harness和MCP工具，后面会给大家分享例子。

这里给出的是一个用EchoX做性能分析的例子：可以很快根据相关的Log找到相应的一个技术瓶颈。

除了代码开发之外，我们在策划制作白盒的过程中也做了很多尝试。这里展示的是大概半年前的成果：我们给策划同学提供了一套可以让他自主搭建游戏玩法白盒的工具。

往常策划如果想要验证某一个新的想法，他需要说服开发同学给他开发一些游戏的白盒Demo，让大家玩一玩来测试是否好玩。现在随着大模型能力的提升，我们逐渐发现策划可以在这套Agent的框架下，用自然语言搭建出一个可玩的Demo，并且可以更快速做玩法验证。

美术管线上我们也找到了AI技术的很多应用。模型建好了之后，材质是决定我们风格的关键。比如说一个硬币有不同的材质，表现的内容完全不一样。我们想要在场景上做一些创新，很大的工作量是需要去尝试各种各样的不同材质。以前美术同学做这种脑洞验证非常耗时，每换一种材质都要手动制作贴图、渲染查看。现在，我们这边提供的AI材质替换助手可以在几秒钟内完成替换，帮美术同学快速验证概念方向。

这里还给出了一个游戏提取三视图的例子。在场景制作过程中，我们需要去场景原画里把每个物件的三视图拆出来，然后才能制作模型。这是一个工程量非常大，也非常乏味的劳动密集型工作。现在我们用AI的话，可以直接从场景原画里面提取这些物件的三视图。

不仅如此，对于我们觉得很不错的一些设计，AI还能一键生成很多变体，比如说换个颜色或者换一个具体的风格……这些工作可以让项目组的产能更能聚焦在一些更有创造性的工作上。

玩过角色扮演游戏的小伙伴应该也有体验，在很多角色扮演游戏里边，游戏里的角色跟你说话的时候，大部分动作是非常僵硬的，我们戏称为站桩对话，通常就是几个固定的站桩对话，活人感很差。想给每一段对话都做专属动作，是一个非常高成本的事情。我们这里使用AI模型去做动作的生成。它可以根据你说话的内容、相应的语义，生成相应的匹配动作，这项工作也在我们的游戏研发过程中有了落地。

最后我们想聊一下AI技术跟游戏场景更深层次的结合。

我们观察到，最近的基座模型越来越多关注游戏的开发工作。这里有几个原因，一方面是因为游戏开发成果可以更加直观的展示出来。比如很多基模公司会说：你说一句话，我这个模型就能帮你开发出一个游戏，然后把游戏链接扔出去——大家会觉得这个模型很厉害。

另一方面，游戏研发本质上也是一项极其复杂的软件工程项目。可以这么认为，游戏研发是仅次于像浏览器或者操作系统这类大型软件项目的一个非常复杂的软件项目。他自然而然、也应该成为Coding Agent的下半场。

Coding越来越多，应该去挑战自己，做更复杂的开发工作。Coding Agent的成功主要是依赖于这样一个执行循环：Agent在某个环境里做相应的执行，拿到某些规则上可以验证的结果，这个结果可以反馈给我的Agent，让它做下一步的迭代。但是在游戏场景里面，这样一个循环就很难跑通。

主要原因在于我们在做游戏质检的时候，大部分情况下还是靠人工做QA。单纯想要实现自动玩游戏，是一个很难的事情。这个循环一直跑不通的核心卡点，在于我们找不到一个可以自动玩游戏的东西。我们在这个方向上其实做了一些相关的实践。

我们的第一个想法是这样的，我们想让模型像人一样去玩游戏。

人怎么玩游戏呢？你打开一个游戏，你的眼睛看到了这个游戏渲染出来的画面，你的手输出了一些键盘和鼠标的操作，就把这个游戏玩起来了。我们也期望，现在的多模态模型可以一定程度上复刻这样一个过程。所以我们开发了相应的Agent来玩游戏的一个工作。

我们使用了Qwen-VL系列的基座模型，在这个基座模型上跑通了这一整套过程。包含CPT还有SFT强化学习的过程。在CPT阶段，我们也收集了上万小时的游戏数据——所谓的游戏数据就是游戏的录屏、游戏录屏对应的键鼠操作。有了这些数据之后，一定程度上可以去训练这个模型，从而让这个模型可以看到某一个游戏截图，就能输出相应的键鼠操作去玩这个游戏。

经历了整个流程之后，我们把它的推理速度优化到了一定的水平。比如说我们现在推理速度可以达到30FPS。这样的话，他其实能以非常快速、非常流畅的方式玩很多游戏。

这是一些效果，比如在很多FPS游戏里面做的很流畅。右边是一个RPG游戏，它可以遵循左上角的任务提示执行相应的任务。但是我们发现用这种方式实现的Agent，非常适合System one的任务。如果想要执行一些System two的任务，需要配比一个很复杂的记忆或者外置的Harness。

如果想要做一些System two的尝试该怎么办呢？我们想了另外一个思路：尝试使用Coding Agent写执行脚本。

一般来说，传统游戏里的AI都是基于决策树的。决策树本质上是一套非常复杂的if-else的代码。现在的Coding Agent非常适合写代码，我们可以尝试用Agent写很多的if-else。它可以写几千行甚至上万行，这个决策树会变得越来越复杂、越来越强力。通过运行执行脚本，就能让它去玩很多原来人写不出来的决策树行为。

比如我们选择了《小丑牌》，这是一个肉鸽类游戏，它提供了一个很长的执行序列，这个过程中要考虑到牌组的构建，本质上需要很大的推理能力。

我们做了这样的一个尝试：拿Coding Agent写了一个决策树，它可以去玩《小丑牌》。我们允许这决策树读取失败的Log，让Coding修改它所写的这一套决策树，从而有一个更强力的性能效果，实现RSI（Recursive Self-Improvement递归自我改进）这样一个过程。

这边有一个性能的分析图，随着迭代的进行，我们确实观察到了这项工作的性能提升。横轴是我们迭代的部署或者迭代时间，纵轴是这个《小丑牌》的通关率，可以看到它这个曲线确实在往上涨。

比较有趣的地方是，这边有一个性能的激增，大概从10%+直接到了60%+。某一天我们上班的时候突然发现它的性能变得很好。后来分析了一下，是因为我们的Agent一定程度上自己想到了一种作弊的方法，非常神奇。它自己上网找了一个《小丑牌》的模拟器，这个模拟器可以根据你当前的random seed看到未来的牌组，相当于一定程度上开了“上帝之眼”。

有了上帝信息之后，它就能把这个性能刷的很高。我们也很惊讶于现在的Agent可以有这样的一个能力，这也是为什么大家都说现在的Agent越来越聪明，导致越来越危险，幸好它是在游戏环里面。如果是在真实环境里面，没准真的会产生出来一些危害。如果抛弃这个作弊的功能，我们发现它的性能也是随着迭代的时间逐渐上升。

这项技术目前也应用在了《崩坏：星穹铁道》的QA的过程中——我们在QA的过程中可以搭建这样一套决策树去执行很多游戏操作，从而完成QA的质检功能。比如左边是操纵角色完成游戏里的一些小游戏，我们发现决策树这种方式都可以很好的完成。而决策树这样一个技术方案，又足够便宜，它在QA的过程中展现出了很大的价值。

这就是我今天想要给大家分享的内容，谢谢。