米哈游崩坏IP实战分享：为探索AI，曾一晚烧掉200万？

在昨天（5月20日）的2026阿里云峰会现场，《崩坏》系列AI NPC & Gameplay技术团队负责人郑银河，就如何运用AI升级游戏工业化管线，进行了分享。

据郑银河介绍，米哈游对于「AI融入生产管线」的布局尝试，起步得相当早，在AI Agent的概念尚未大火时，内部已经开发了多个自研Agent平台，来匹配不同的应用场景，这次主要分享的是崩坏项目组内应用较多的Agent平台。

此外，他还以《崩坏：星穹铁道》中的帕姆帮帮为例，介绍了崩坏项目组在AI NPC方面的经验积累，并表示未来米哈游会继续尝试用AI来提升Gameplay体验。

以下是经过整理的演讲具体内容（如想了解其他阿里云峰会相关，以及会上更多「AI x 游戏」的探讨内容，欢迎查阅关于阿里云AI游戏分论坛的文章）：

大家好，我是郑银河。这次给大家分享的内容是「AI驱动下的游戏工业化管线升级」。

这次分享的内容主要分三部分。我会先介绍一下语言模型和Agent，以及我们内部的一些实践经验；第二部分会给大家介绍一下我们在AI NPC和AI Gameplay方向的一些实践经验；最后是AIGC部分。

首先来聊聊我们在AI Agent方面的实践经验。我们根据自己的实践，将Agent的发展阶段分成 L1、L2、L3。

L1指代的是最初的聊天室产品，如网页版ChatGPT、Copliot等。它们只能给用户提供一些简单的代码补全，或者简单的聊天内容，并不能产生明显的生产提效。

L2这个层级，以Qoder、Cursor为代表的辅助开发工具，为用户提供了新的工具范式。这个范式下，AI开始真正理解我们工程的全局上下文。用户不需要再像最开始那样手工写代码，只需要去点Accept（接受）就可以了。用户的身份，从一个程序员，变成了一个真正的架构师。

所谓L3，则是我们展望未来的一个方向。L3代表Agent协同的「全自动驾驶」模式。你只需要写明需求，Agent就能像数字员工一样，把这个需求做出来。目前我们在朝着这个方向去做，这可能也需要全行业的共同努力。

为了在开发中更好利用Agent技术，早在Agent火起来之前，米哈游内部就有做一些相关实践，目前已开发了多个Agent平台，来匹配不同的应用场景。

大概去年3-4月，崩坏系列项目组开始在内部开发一个自研的Agent平台：Echo Agent。它不是一个简单的聊天工具，而是一个托管Agent的生态平台。它能做很多复杂的任务，像OpenClaw之类的功能，都可以用Echo Agent来实现。我们不同业务，也有创建各自不同的Agent模板，比如包体冒烟的测试，配置助手，PPT助手等。

基于这套Agent平台的游戏开发，存在几个问题。

首先，游戏开发本身是重度依赖Windows底层API的，比如游戏打包的管线，很多只能在Windows环境下执行。但现在的Coding普遍没有对环境，比如PowerShell或Windows，做很好的支持。

针对这个场景，我们对Windows下的命令行工具，以及我们经常用到的版本控制工具P4，做了很多原生集成的工作。这可以让我们的Coding Agents在Windows环境下更顺滑地运行。

当然，这里面不乏经验教训。曾经有同事为了实现项目，建了几十个agent共同协作，一晚上烧了价值200万人民币的Token。但我们接受在探索AI时有成本、有学费，这也帮助更完善我们的Agent平台。

其次，大家知道，游戏研发是一个多模态行为。但现在的Coding Agent，主要集中在Coding、文本交互这样的场景，大家对于多模态能力没有那么重视，现在的模型在多模态能力上还有一些欠缺。所以我们很早就给Echo Agent加入了多模态相关工具和读取工具。

同时，我们意识到，游戏开发的工具生态也很重要。我们通过MCP，或者命令行的格式，引入了各种各样的游戏开发工具，每个人都可以像搭积木一样去搭自己的Agent。

我们还做了一个内部Skill社区。比如某个同学发现Agent不了解游戏里的一些机制，阻碍了他工作，他就可以让Agent自己写一个Skill，并一键分享给同组，这样其他人也能理解他对于游戏设计的小巧思了，大家协作更能节省工作量，避免重复踩坑。

此外，我们让Agent和很多内部工具做了融合。比如让Agent接入我们的引擎，打通我们的内部聊天工具，接入公司的安全基建。

下面这个例子，就是我们试图用AI Agent去做游戏引擎崩溃的分析。

大家知道，崩溃分析非常依赖个人经验，或者说依赖于分析者对整个项目的理解情况。Crash Dump只是崩溃的第一现场，真正的原因一般非常复杂，所以去查崩溃原因是件非常繁琐的事情。

但我们发现，随着模型能力提升，模型在分析代码bug方面有了很强的能力。本质上你只需要给它提供一个足够健壮的执行循环，并且把足够多的工具给它，它就能分析出来结果。

经过我们实践发现，只要执行循环和工具做得足够健壮，Agent就能极大释放大家的生产力。Agent能帮一些资深引擎同学找到具体错误，还能帮策划同学做一些白盒测试——这些测试不需要占开发人力，只需要把相应工具给Agent搭建好，策划同学就可以push Agent去做相关的工作。

我们内部已经通过Agent做了不少白盒测试，有赛车游戏、2D搜打撤等。由策划自己去验证自己的想法，他们的验证链路就缩短了很多。

接下来，我介绍一下我们在AI NPC方向的实践经验。

在《崩坏：星穹铁道》4.2版本里，我们上线了帕姆帮帮，内部将其称作AI帕姆。它重点探索了三个核心场景：

第一是角色养成。它能为玩家推荐配队、遗器方案；能结合社区的PUGC内容，对玩家角色养成过程中的一些问题进行答疑；能追踪玩家的刷取进度，并在合适的时候主动提醒玩家。

第二是剧情答疑。《崩坏：星穹铁道》运营到现在，背后已经形成了一个非常庞大的世界观，可能有一些弃坑玩家想要回来，却发现看不懂剧情了。这种情况下，玩家可以直接问AI帕姆关于剧情概述、人物关系、世界观背景等问题，AI帕姆都能回答。

第三是情绪互动。AI帕姆是允许自由输入的，而一旦你把自由输入框扔给用户，你就没有办法约束用户到底能输入哪些东西。我们发现，大部分用户其实会把自己的情绪倾泄出来，会像和老朋友聊天一样，去和AI帕姆聊天。

接下来聊聊，我们做AI帕姆背后的几个核心思考。

第一个思考在于，我们会尝试通过AI帕姆，让系统更主动地去理解玩家，而不是让玩家去费力地理解系统。因为本质上讲，应该是玩家在玩这个游戏，而不是被这个游戏玩。

《崩坏：星穹铁道》立项时，原本的目标也是轻度游戏体验，但随着游戏内容更新和游戏复杂度提升，玩家的认知负担会越来越重，这和轻度游戏体验的目标是存在冲突的。

AI帕姆一定程度上可以缓解这个问题。它可以主动推荐，所以用户不需要深入理解所有系统的每个细节；它可以降低新玩家、回流玩家的上手门槛；它可以按需为用户提供精准内容，玩家不需要自己去翻攻略，或者去啃设定。

一句话总结：不是让用户适应越来越复杂的系统，而是让系统反过来去服务每个用户。

我们的第二个思考在于，让游戏里的角色真正「活」起来。

传统对话、游戏剧情，本质上是游戏单方面、一次性的内容输出，我们很难围绕剧情做更多演绎，也很难让玩家和相关角色做更多互动。但《崩坏：星穹铁道》本质上是想展现一个个鲜活的角色。AI NPC相关技术，可以很好地帮我们解决这个问题，还可以给角色注入灵魂。

而做AI NPC，最重要的一点是，不能让用户觉得这个角色人机感重。所以我们首先要解决的一个问题，是让AI帕姆活起来。

我们尝试做的第一个事情，是在表现层加更多动作。在聊天框左边，玩家可以真正看到帕姆，并且帕姆在这个聊天框里能动起来，它会根据玩家聊天内容做相应的动作，这样用户看到的就不是一个干巴巴的聊天窗口了。

第二件事，是在逻辑层面让AI帕姆有活人感。前面有提到，《崩坏：星穹铁道》背后有一套庞杂的世界观设定，我们需要让AI帕姆适应对应设定，实现一套RAG系统。

传统的RAG系统是非常人机，或者说性能很差的，因为大部分模型做RAG，本质上就是复述检索出的文档内容，你很难让NPC看起来像你的伙伴。

我们的解决策略是，额外交叉比对帕姆与该事件/人物的「关系网络」、「过往印象」与「主观态度」，将上述因素转化为特定情绪，对客观信息进行“情绪染色”与二次重构。这也是IP老师写帕姆对话的方式。

第三件事，是给AI帕姆加上更多记忆，这可能是所有AI NPC相关应用里最重要的方向了。人与人之间交流，我们肯定不会期望说和一个根本没有记忆的人去做深入交流。

我们设计了三重记忆机制，即短期记忆、中期记忆、长期记忆。

短期记忆指的是玩家对话上下文的对话历史；中期记忆是在玩家与AI帕姆聊得比较多了后，帕姆会尝试总结压缩之前的对话历史；长期记忆，则是我们尝试给每位用户设计建议独立的专属档案，持续记录玩家的行为偏好、感兴趣的话题、过往的互动经历，这样帕姆下次聊天就可以把玩家之前提到的内容给echo（回响）出来。

AI帕姆的中期、长期记忆，用的是千问Plus模型，这个模型是比较好用的，但实现起来也存在一些难度——《崩坏：星穹铁道》本身玩家活跃量级达千万级，在这么大的一个基数上，AI模型要面对千万级高并发的挑战。

为应对这个挑战，我们做了三方面的优化工作。

第一，我们构建了一个异构推理集群。本质上讲，我们找到了市面上能找到的所有GPU机器，去推理我们所训的模型。这里提到的GPU机器，包括我们阿里云上的GPU机器，也包括我们自建机房里的GPU机器。

第二，我们试图在模型层面压低AI帕姆的推理成本。我们最终的主模型，用了一个稀疏的MoE架构模型，并且在做模型训练的时候，我们还做了思维蒸馏——帕姆如果每次都先写长篇草稿再回答，玩家等它打字都要睡着了，所以我们让大模型当「老教授」，把思考能力直接教给帕姆，帕姆开口就是答案。

第三，在推理过程中，一些常规的推理操作肯定要上，比如说FP8推理、NVFP4推理。

接下来再聊一个关键问题：怎么让AI帕姆适应《崩坏：星穹铁道》后续内容更新？

《崩坏：星穹铁道》是一款长线运营游戏，每个版本都有大量新内容。如果每次更新，我们都要去重新训练模型的话，那背后的时间和成本都是不可接受的。

所以我们的核心架构原则，是让模型和知识库分离——模型是模型，知识库是知识库。这样我们只需要更新知识库就可以。

不过在更新知识库时，也有一些难度。毕竟《崩坏：星穹铁道》的世界观非常庞杂，在更新知识库时，我们会有一些提前的预处理，来尽量减少人工工作量。

和UGC内容不同，AI帕姆背后的知识库，本质装的是PUGC内容。我们需要为AI帕姆的知识库负责：它错了，是官方的错，不是玩家的错。所以我们做了一些技术优化，用AI Agent离线地把知识库内容，自动拆解成一个个细碎的、容易理解的问答，存进知识库里。同时我们还做了Doc2Query——反过来，从知识文档自动生成可能查询的问题，用来提升检索的召回率。

未来，基于我们在AI帕姆方面的经验积累，我们还会研究如何把这套能力更好适用到其他AI相关的Gameplay中。

其中一个想法——不一定真能做出来——是把AI放在类似《Among Us》这样的狼人杀游戏场景中。说白了就是融合聊天模型所带来的自由度、更多Gameplay相关规则。而且你可以尝试用语言模型去影响Gameplay里的数值、机制，从而给用户带来更多的游戏体验。

最后介绍一下我们在AIGC方面的实践。

自2023年初，我们就开始探索AIGC在相关项目中的生产应用，也借此积累出了一套相对完善的方法论。最终的产物，就是这个开箱即用的AIGC工作台，叫作AJI，有点恶搞AGI的意思，我们内部把它称为阿基。它有各种各样的版本，下图示例是网页版本。

我们做这套平台，背后的核心动机有两点。

一是可用性。现在市面上AI相关产品已经做得很强了，但你真让产品美术、场景美术、动作设计师自己去搭环境，去把模型用起来，还是很难的，所以我们做了这套平台，这样非技术侧同学也能很快上手，去产出相关资产。

二是业务需求。外部模型有时并不能完全满足我们对游戏制作的需求，包括对精度、风格一致性的要求。所以在AJI平台里，我们不只是接入外部模型，也会针对业务场景去训练自有模型。

比如我们会让模型去适应《崩坏：星穹铁道》特定的风格纹理，这样模型训好后，团队同学就可以用AI尝试自动生成相关物体纹理，或者一键切换纹理。

AI还有很多可以解放生产力的用途。

我们用AI可以直接从场景原画中提取物体的三视图。

玩过RPG游戏的同学应该有体会，游戏里的NPC跟你说话时，基本就是站桩，加上几个固定的动作来回切换。而在AI帮助下，我们可以做更多voice to motion的模型，这样NPC就能根据对话内容自动做出相关动作。

限于时间，今天的分享其实只涵盖了我们已经完成的、正在进行中的部分案例。我们期待与更多人才一同，拓展创意边界、解放生产力，为玩家提供原本限于技术、时间所不能提供的更好体验。