解放生产力。

整理 / 王丹

在昨天（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 就能根据对话内容自动做出相关动作。

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

游戏葡萄招聘内容编辑，

点击「阅读原文」可了解详情

推荐阅读

点击下方名片，关注公众号

（星标可第一时间收到推送和完整封面）