游戏研发中的 AI 转型：网易多 Agent 系统与知识工程实践

演讲嘉宾｜林香鑫，网易游戏高级技术经理

近一两年大量 AI 编码工具如雨后春笋般诞生，但在游戏项目工程级别的代码编写参与度仍不高，主要受限于 LLM 上下文长度、游戏业务的复杂度与灵活性。

本文整理自网易游戏高级技术经理林香鑫 6 月份在 AICon 2025 北京站的分享《大模型在游戏研发中的落地实践》。团队通过代码知识谱图构建、多 agent RAG 召回、MCP 等技术方式，打造了一个可完成复杂游戏编码任务的超级助手，在代码搜索、知识问答、功能迭代、新功能编写等业务场景均有不错的落地效果，已在公司内部广泛应用，同时推动了内部 AI 生成代码覆盖率大幅提升。

12 月 19～20 日的 AICon 北京站 将以 “探索 AI 应用边界” 为主题，聚焦企业级 Agent 落地、上下文工程、AI 产品创新等多个热门方向，围绕企业如何通过大模型提升研发与业务运营效率的实际应用案例，邀请来自头部企业、大厂以及明星创业公司的专家，带来一线的大模型实践经验和前沿洞察。一起探索 AI 应用的更多可能，发掘 AI 驱动业务增长的新路径！

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。

在游戏研发管线中，我们正在开展一系列与人工智能赋能相关的中台化工作，其中也包括与 AI 编程工具相关的内容。今天，我主要想和大家分享一下大模型在游戏研发中的落地实践，重点在于我们在这一过程中的思考与感受。

理想与现实的差距

从早期的 ChatGPT 3.5 到 GitHub Copilot，再到 Devin、Claude Code 等，我们可以看到随着大模型技术的不断发展，技术落地工作逐渐成熟，并催生了多种不同的产品形态。这引发了一个令人焦虑的问题：随着这些看似无所不能的工具的出现，程序员是否真的处于失业的边缘？对于从事 AI 编程的从业者来说，这种焦虑感尤为强烈，我们不禁思考，这些工具是否真的有如此强大的影响力？

在这样的浪潮下，我们开始思考在游戏研发过程中，这些工具是否真的适用。为此，我们开展了一次内部的大规模调研。调研结果显示，与大家的普遍认知不同，游戏研发人员花费最多时间的环节并非代码编写，而是代码理解。这一现象与游戏研发体系和模式有着天然的契合点。无论是策划、美术还是开发人员，虽然他们提交到代码仓库的内容不同，但整个游戏系统的运作需要多方协同。以一款知名游戏为例，其代码仓库行数达到了千万级别，这无疑带来了巨大的理解成本。此外，当出现问题需要调试时，这一环节也占据了相当多的时间，而代码编写反而排在后面。这正是游戏领域在研发效能方面面临的困境。

进一步分析，我们发现导致这一困境的原因主要有三个方面。首先，约 30% 的人认为游戏研发过程中缺乏清晰、及时的技术文档，这与游戏的发布周期密切相关。例如，一个资料片可能需要在两个月内上线，根本没有时间进行详细的技术设计，通常是基于上一次资料片的经验快速复用并上线，这种心态导致了技术债务的不断积累，占比约 28%。其次，游戏研发管线比传统的 Web 开发复杂得多，测试、编译、调试的速度缓慢，一次性审查大量代码耗时过长，这也是一个突出问题。

针对这些问题，我们借助大模型和 Copilot 的初期优势，在 2024 年初构建了一套以 IDE 加 Web 双端形式存在的系统。除了常见的代码聊天、代码补全等基础功能外，这套系统更多地围绕团队如何开展研发工作而设计。团队可以定义自己的规则、知识库，并在系统上运行代码审查流程，甚至可以随时针对一段代码发起讨论。

但这些并非重点，重点在于我们利用 AI 赋能的机会，将所有面向程序的工作逐步集中到一个入口，即大家常用的 IDE。我们不希望研发人员每天在不同的地方切换工作，而是希望他们能够在 IDE 中完成所有工作。同时，我们通过 Web 后端形成与 IDE 相互支撑的形态，IDE 的使用情况和数据会回流到后端，而后端配置管理的团队数据也可以在 IDE 中使用，从而将整个游戏研发过程集中到一个入口。

在过去的一年中，我们重点解决了三个方面的工作。首先是缩短代码理解周期。代码理解不仅涉及代码逻辑，还可能包括游戏玩法、角色技能等开发人员需要理解的内容。其次是代码补全与生成，我将重点分享我们内部是如何落地代码生成的。最后是经典的代码质量问题，即 AI 代码审查。虽然这一领域备受关注，但实际操作起来并不容易，今天我也会分享一些相关经验和心得。

游戏研发知识工程

在游戏研发过程中，如何更好地理解代码及其背景知识，是我们一直在探索的问题。在这个过程中，我们逐步构建了一套游戏研发知识工程体系。一个游戏团队通常涉及策划、研发、美术等多个角色，大家每天需要协同交互的问题非常多。例如，一个游戏角色的技能是什么？像最近大火的某款热门竞技类游戏，已经有数十个角色，每个角色可能有好几个技能，普通人很难全部记住，只能通过询问来获取信息。再比如，去年的中秋活动是如何实现的？如果我要设计今年的中秋活动，自然希望借鉴去年的经验。还有如何让 UI 界面背景实现毛玻璃效果，这可能涉及组件配置属性等问题。此外，开发人员和 QA 经常会因为“我改了这个东西会不会影响其他东西”而产生分歧，而这些问题的答案都藏在代码仓库里。

在这种背景下，我们遇到的首要问题是大家都不喜欢写文档。程序员最讨厌的事情之一就是写文档和注释，这导致知识很难沉淀下来。即使有了文档，很多时候也用不上，因为直接询问同事往往能更快得到回应。

然而，在大模型技术爆发的当下，这一问题有了新的解决方案。大家应该都听说过智能问答系统，那么如何利用 RAG 或 Agent 技术来解决这个问题呢？我们推进了这一项目，因为如果能让人们快速获取知识，又不希望在这个过程中互相损耗效率，那么引入一个持续工作的第三方系统就显得尤为重要。

在大模型时代，知识工程指的是对企业内部数据进行系统化的治理、挖掘、应用管理与迭代，构建一个能够支撑 AI Agent 运行的知识体系。这听起来概念简单，但涉及的内容却非常广泛。比如结构化知识，包括游戏中的技能、角色、系统、玩法等，这些都可以定义为一系列结构化数据。同时，也涉及大量非结构化文本，比如角色背后的设计与解释，这些可能以文档形式存在，而在游戏行业，很多策划喜欢用 Excel 管理内容，这些都是非结构化数据。此外，还有领域知识、团队积累的案例，以及潜移默化运行的内部业务模式等，这些对企业来说都是知识，因为它们是你每天可能接触或需要应用的内容，如果你要完成某个实现，就需要了解这些知识。

基于前面提到的统一入口，我们将大家理解的通用知识，比如从 GPT 或 Claude 等模型获取的知识，升级为具有内部知识的聊天模式。对于游戏来说，除了业务逻辑和知识，还有一个非常重要的点，那就是游戏引擎。我们内部基本都使用自建的游戏引擎，因此我们将这些知识关联在一起，一旦需要使用，就能通过这种方式快速获取。比如用到了引擎的哪些 API、哪些 SDK，如果在实现过程中能够快速获取这些信息，那将是一种更高效的方式。

基于前面的讨论，我们可以将知识分为两类。一类是显性知识，即那些即使不问 AI，也可以在文档中找到的知识。在这个过程中，我们主要做的是已有知识的治理。对于内部的知识管理系统、工单系统、代码仓库（如 SVN、GitLab 等），我们都实现了数据的归集，并将其处理进一个统一的知识库，或者说是团队的知识大脑。然后通过 agentic RAG 等方式，实现了对知识的切割、解读和检索。我们最深入的工作是定义 AI Agent，希望通过 AI Agent 的路由，以最高效的方式找到相关数据，这是显性知识治理的过程。

另一部分非常重要的是隐性知识。如果一个开发人员要实现某个功能，他可能每天都在与代码仓库打交道。在这个过程中，我们进行了隐性知识的挖掘。其实一切都在代码里，我们的目标是构建一套代码知识图谱。这里用到的技术其实很传统，只是结合大模型的发展，能够进一步在业务价值上激活。首先，我们对代码目录结构进行了解析，因为代码目录结构对于理解一个工程来说非常重要。其次，我们基于抽象语法树（AST）和调用流，完成了对整个仓库中所有函数甚至所有类的语义化解读，将原本枯燥难懂的代码变成语义上更容易理解的文本。接着，我们挖掘了代码中的调用关系和调用链，形成了一张地图，最终构建了一张完整的代码地图。虽然可视化可以做得非常炫酷，但重点是我们对代码仓库进行了非常精细的解构，让你可以通过聊天的方式获取其中的信息，这是非常重要的一个点。

在整个过程中，我们还会剔除一些特殊的文件，因为这些文件可能会对原本的知识产生干扰。此外，除了完成目录树本身的抽取，我们还做了一件事，就是基于以往的所有工单，工单里会有与提交记录的关联，我们将这一层信息打通，这意味着一个业务模块与代码文件，或者某段解读完的代码逻辑是有关系的，从而形成了一个具有业务背景知识的代码知识解读结果。剩下的工作是基于传统的 AST 技术或线上的动态调用链关系组织出的一张图谱。

Codemaker 最新推出的全量仓库代码可视化功能模块，对逻辑完整的代码仓库进行局部代码解析后生成的内容，我们称为一份代码地图。它包含代码文件、函数之间的调用关系，以及文件、类、函数的语义化解读，对函数复杂度、代码规模的洞察。数据支持简洁模式和代码模式，支持与地图交互展开查看更多上下游信息，支持人工标注对应模块。

经过这个过程，代码仓库对我们的意义已经从单纯的代码存储，变成了一个可以贡献知识的资源。这意味着在一个 100 人的团队中，一个人能够了解所有人写的代码，只要愿意与它交流。

我们也将这一模式应用到了很多大型游戏中。例如之前在海外非常火的一款知名超英题材多人在线游戏，整个游戏涉及几百人的共同研发。在这个过程中，我们直接基于他们的场景解决了这些问题。痛点非常明确：资产非常多，但很多都没有被充分利用，而大家每天都在互相询问各种问题，比如“这是怎么回事”“那个是怎么实现的”“数值是多少”等。我们统计发现，大家每天可能需要花费 20% 的时间去获取这些信息，这对效率的阻碍是非常大的。最后，我们通过前面的各种方式实现了一个入口，能够连接到所有必要的支持，形成了这样的模式。

我们还对一些日常问题进行了分类，这些问题远不止开发层面上的，还包括开发技术、公共引擎、游戏设计工具、环境配置，甚至涉及一些项目管理的流程。这是我们建立的模式。最后我想强调一点，如果仅仅完成了第一轮治理，只是把现有数据激活，这是不够的。在实践中我们发现，当大家开始使用这套系统时，会产生使用过程中的数据，这些数据可以进一步回流进来，补充整个团队的知识库。这一点非常重要，我们称之为迭代知识。补充这一环节后，整个知识体系就形成了一个正向循环，知识才能真正“活”起来。以前最大的问题是知识是“死”的，除非你去用它。现在大家已经养成了习惯，要找相关信息就来这里，这样就会产生过程数据，我们可以进一步利用这些数据。

Multi-agent 赋能代码编写

在构建了坚实的知识底座之后，很多事情变得容易了许多。因为有了这样一个良好的知识基础，人们能够接触到这些知识，自然而然地，我们就会想到：AI 是否能够接触到这些知识？如果它能够接触并理解，那么它是否能够帮助我们编写代码？这一阶段，我们正是在解决这个问题。

结合了知识工程之后，我们的系统能够理解整个游戏仓库的整体架构、具体的技术栈，以及如何运行，还能快速查找代码。这与大家熟悉的 Cursor 或 Codebase 有些类似，但正如之前提到的，游戏代码仓库的规模非常庞大，如果仅依赖本地模式，是无法满足需求的。因此，我们在前面的基础上构建了一套云端模式，只有这样，才能面向整个团队开展工作。

我们从传统的聊天模式升级到了一个由 AI 驱动的模式，我们称之为“仓库智聊”。这个名字的寓意很简单：我们的所有工作都可以面向仓库展开，或者说，我们的所有工作都可以基于仓库进行。大概就是这样的意思。

然而，我们很快发现这还不够。因为如果整个团队要基于仓库的代码实现展开工作，还需要很多其他的东西。为了让 Agent 能够基于对整个团队的业务背景或技术栈的理解，生成符合我们需求的代码，我们做了一件事：从团队的角度构建一个研发空间。如果你作为一个新人加入一个团队，你首先需要了解什么？如果你什么都不了解就开始写代码，那么写出来的东西一定会被人嫌弃。你可能需要经过 1 到 3 个月的培训，才能逐渐掌握团队那些隐藏在水面下的知识。我们的研发空间就是想把团队那些隐藏的知识显性化，定义出来。

在这个过程中，我们发现，除了要让仓库能够被挖掘出来，以及梳理原有的项目过程文档之外，还需要关注很多细节。比如，我的游戏正在使用哪个版本的 SDK？我正在使用哪个版本的引擎代码？里面是否还用到了其他通用的技术库？这些内容其实都隐藏在我们日常的运作过程中，但从未被真正梳理出来。我们正在做的，就是把这些内容梳理清楚。

还有，这个团队的编码风格是怎样的？曾经有一个团队领导使用我们的功能时，一开始抱怨说，虽然生成的代码看起来都没错，但不符合我们团队的风格。这确实是一个问题。一旦这种风格被定义出来，比如我们规定 Python 应该使用哪个版本，或者遵循哪些代码规则，慢慢地，你就会发现，它越来越像这个团队的一个成员在工作。我们就是基于这样的前提构建了研发空间。

这里有一个案例。在梳理完前面提到的这些内容之后，整套架构其实非常清晰。这与大家在网上看到的通用 Agent 架构没有太大区别。真正核心的区别在于，我们给 Agent 提供了什么样的上下文。现在有人说，未来工程师可能是面向上下文编程，我对此深有感触。Agent 架构最后的差异不会太大，真正重要的是你给 Agent 提供了什么样的信息。这正是我们在构建团队空间研发空间时所关注的内容。

在这种模式下，我们定义了一个核心 Agent（Core Agent）。这个 Agent 与其他架构中的 Agent 类似，能够进行规划和拆解，但最重要的是，我们基于内部工具或内部数据，为它提供了什么样的人员去协调。这一点非常重要。如果你协调的是一个不了解这个项目的人，他可能会给出错误的信息，自然也就很难生成正确的结果。经过我们的治理，很多倾向于项目风格和项目偏好的 Agent 逐渐被定义出来并产生。经过核心 Agent 的协调，并且通过系统提示（system prompt）等方式让核心 Agent 表现得更好，整套体系就会逐渐成熟起来。这就是我们对结合研发空间的多 Agent 系统的思考方式。

目前，虽然大家看到的形态是一样的，但背后的逻辑是不同的。我们提出一个需求，比如增加一个功能或修改一个逻辑，最后它会帮你完成生成。我想强调的是，真正困难的是背后的这部分内容。如果你直接把一个开源的 Agent 应用到你的团队，它真的能正常工作吗？我对此表示怀疑。因为最终我们发现，核心价值在于背后的这些细节。

在完成这些工作之后，我们在内部落地的情况也值得分享。首先，我们将整套系统应用到新人学习阶段，形成了一个非常明确的指引。在这种工作模式下，新人应该如何循序渐进地利用这个工具来完成理解？我们有一个实践案例：我给了一个新人 4 万行代码，原本估计他需要两周时间来熟悉，但我告诉他使用这个工具，最后他告诉我只需要一到两天。因为 4 万行代码，说实话，如果你一行一行地去读，或者在没有任何引导的情况下熟悉它，那是一个非常枯燥的过程。但在前期加入团队学习时，你其实不需要这么细致地去了解所有内容，更多的是有人帮你梳理这些内容，让你能够理解整体框架，以及未来你要修改的内容和位置，这些都会有一个清晰的指导。这也间接释放了导师的负担。以前，大家都要一对一地指导新人，现在可以让 AI 来指导新人。

从项目协同的角度来看，虽然我们的系统最初是围绕代码生成设计的，但经过大家的探索，它现在可以用在很多方面。除了常规的生成变量名、业务代码逻辑、现有代码重构以及生成测试用例之外，它还可以用在很多创造性场景中。之前，一个内部用户偷偷告诉我，他用这个工具来写专利。这其实是一个挖掘已有内容并加以利用的过程。在实际应用中，这个工具在游戏团队中的使用率已经达到 30%。当然，这是三个月前的数据。我最近看到的数据显示，这个工具一个月能够贡献大约 500 万行代码，分布在几十个游戏项目中。500 万行代码是一个非常庞大的数量。

Al Review 助力研发质量

在刚才提到的 30% 的代码由 AI 生成的情况下，剩下的 70% 仍然需要人工编写。如果手工编写代码，大家自然会非常关注研发质量。在我看来，游戏开发是一个比较特殊的领域，很多时候工期非常紧张，很多时候我们只能完成核心逻辑的代码审查。然而，一些运营事故往往是由一些非常低级的错误引起的。比如，我今天要设计一个活动，每人赠送十个仙玉，但如果手抖敲成了 20 个，甚至 100 个，从代码逻辑层面是很难发现这种错误的。因为你写了一个 100，系统怎么知道这是错误呢？在没有上下文的情况下，这种问题很难被发现。因此，基于这样的特殊背景，我们内部形成了一套基于传统静态代码分析技术与 AI 代码审查相结合的方法，对整个从研发到测试再到发布的流程进行必要的代码质量把控。

代码审查确实是一个非常耗精力的过程，而且可能会打断你的工作。它的模式其实很简单，无非是提交合并请求，然后大家去查看。但正是因为这种简单且频繁的事情，大家很难坚持下去。所以，我们的目标是将代码审查过程智能化，争取在研发早期就发现潜在的错误。

我们之所以觉得 AI 适合用于代码审查，尤其是在游戏场景下，是因为我们发现很多错误其实是由一些比较低级的问题引起的，而 AI 恰好比较擅长处理这些问题。如果让高级专家专门去审查这些低级错误，他们可能会觉得没有成就感。此外，AI 可以持续工作，我们内部已经构建了一套方式，白天由人编写代码，晚上由 AI 审查代码。这样基本不会占用你的时间，第二天你只需查看结果即可。

当然，我们也要有一个基本的心理预期，即 AI 能发现一个错误就是赚到了，而不是期望它能找出所有错误。基于这样的前提，我们开展了这项工作。

整个过程中，我们其实也遇到了不少困难。因为实际操作下来会发现有很多问题。如果作为一个通用的大模型，它存在一些典型问题，比如幻觉问题，这里就不多说了。另外，它会非常纠结细节，尤其是那些非常细的所谓规范性问题，其实大家通常并不在意。还有就是它的幂等性很难保持，今天说这里是问题，明天可能又说这里是另一个问题。当你重复提交同一行代码时，可能会得到不同的反馈。最重要的是它不懂业务。就像刚才说的，如果我要实现赠送 10 个仙玉，但你写成了 100 个，它在没有业务背景的情况下也发现不了。所以，我们的整体目标是从原来误报多、不准确的状态，逐步演进到少而精的状态。

整个技术升级过程其实也经历了几个阶段。最初，大家做 AI 审查时，明确要做的是搞 prompt 工程，让它去发现问题。但结果并不理想，业务团队会抱怨说“搞了 1000 个问题给我，我该怎么去修复和确认呢？”因为可能里面只有 10 个是有效的。第二轮，我们基于双引擎，把静态分析和大模型结合起来，先由静态代码分析过一轮，再由大模型做补充。结果发现，这样发现的问题更多了。

后来，我们引入了 Multi-Agent 协同架构，因为业务团队可能会说“我不在意这个问题，帮我抑制掉”。于是，我们做了像 filter、AI 这样的东西，也尝试对问题进行分类分级，因为每个业务关注的点不一样。我们不断引入更多单项能力的 AI 来对问题进行进一步筛选和定义。最后，我们进一步解决它不懂业务的问题，引入了前面提到的知识工程，逐步将其应用到 AI 审查过程中。

在产品形态上，从早期依赖人工自主发起审查的过程，逐步演进到与我们的流水线集成，甚至与工单系统进行质量门禁。最终，所有信息都集中在一个入口，即 IDE 上。

在代码审查方面，我们支持本地代码审查和团队协作审查。本地代码审查无需接入支持，可以直接对待提交代码或划选文件代码范围一键发起审查，支持查看审查结果并处理问题。团队协作审查则需要接入如 GitLab 等代码仓库，在 Web 端或插件端创建审查请求。用户可以选中需要审查的 Commit 或 MR，配置团队审查成员，勾选 AI 审查和 AI 解读，也可以添加工单信息辅助 AI 审查。

填写完成后提交创建，创建完成后，在审查详情页可以查看审查详情，查看 AI 反馈的问题并标记其有效性及标签，还可以对问题进行回复，触发与 AI 模型的进一步交互。点击代码 DIFF 右侧的加号，可以添加一条新的问题。上述操作也可以在平台侧进行。平台还提供面向管理员的仓库维度的审查数据统计。

这是我们目前演进的形态。在这个过程中，我们还发现了一个好处。以前，一些错误解决了就解决了，但经过这样一套中央管理后，我们会发现一个很大的保障：错误数据在哪里发生，以及如何修复的，我们逐步将其沉淀下来。这对于我们后续进一步提升能力，甚至如果真的要去训练一些模型，这些数据的价值非常大。另一方面，这些错误的经验可以作为整个团队编码的进一步输入，帮助抑制一些问题，这也是我们目前正在尝试的一个方向。

未来展望

未来还有许多工作要做，但我认为这一切都离不开一个核心要素——前面提到的研发空间。对于我们这些专注于内部落地工作的人来说，经过多年的摸爬滚打，我们逐渐意识到最关键的问题是：研发数据究竟在哪里？这个问题至关重要。因此，我们优先要做的，不仅仅是面向研发人员的知识治理，而是将整个体系演进为一个团队的大脑。

目前，像 Cursor 或其他工具更多地帮助个人维持记忆，但我们希望构建的是一个能够维持团队记忆的系统。无论谁加入团队，都能获取过去多年积累的相关经验。这正是我们想要实现的目标。策划文档、研发规范、工单处理经验，甚至我们在即时通讯（IM）中沟通得出的结论，这些内容构成了整个团队的记忆。虽然它们在日常工作中看似零散，但当我们把它们整合在一起时，却能发现不少惊喜。

由于我的工作涉及整个全流程环节，我一直在思考如何在游戏研发管线中让一套真正体系化的团队 AI Agent 运转起来。我们发现，策划与研发、策划与美术、研发与 QA 之间的交流，最终都会汇聚到一些共同的点上。那么，这些知识和 Agent 是否能够体系化地协同工作，就显得尤为重要。到目前为止，我们更多地是在单点上解决职能相关的问题，但未来，我们希望这套团队 AI Agent 能够像真正的团队协作模式一样运作起来，基于前面提到的支持 Agent 进行操作。目前，我们已经在进行一些尝试，并且积累了一些相关案例，期待在下次有机会与大家分享更多这方面的内容。

会议预告

12 月 19～20 日，AICon 2025 年度收官站 · 北京见。两天时间，聊最热的 Agent、上下文工程、AI 产品创新等等话题，与头部企业与创新团队的专家深度交流落地经验与思考。2025 年最后一场，不容错过。