游戏研发中的 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 进行操作。目前，我们已经在进行一些尝试，并且积累了一些相关案例，期待在下次有机会与大家分享更多这方面的内容。

加入我们

我们正在招聘资深研发工程师（代码基础设施方向）。该岗位将负责公司代码智能平台的设计与研发，包括构建大规模代码图谱（如调用关系、继承结构、数据依赖），并利用 LLM 等技术进行代码分析、摘要、问答和影响面评估等能力开发。同时需要构建平台的上层应用与 API，支持代码搜索、重构、测试与安全等场景；持续跟踪程序分析与代码大模型技术并推动在内部研发流程中的落地。希望你具备扎实的静态/动态程序分析和编程能力，熟悉至少一种代码分析框架；具备 LLM、图数据库或搜索引擎等相关经验更佳，并具备良好的问题解决能力与团队协作精神。

如有兴趣，欢迎将简历投递至 linxiangxin1010@163.com