Unite Shanghai 2025 | AI 在超大游戏工程中的应用瓶颈与解决方案

Unite Shanghai 2025 于 10 月 23-24 日圆满举办。在团结引擎专场中，腾讯天美 J1 工作室客户端主程余煜与 igins 首席技术专家牟骞带来分享《AI 在超大游戏工程中的应用瓶颈与解决方案》，本文为演讲全文实录。请持续关注，一起学习 Unite 分享的最新干货。

余煜：大家好，我是来自腾讯天美 J1 的余煜，很高兴今天能有机会参与到 Unite 峰会。2025年被称为 AI Agent 元年，短短半年，AI 应用已经陆续开始进入我们的工作生活。今天就和大家介绍我们在大型游戏工程中使用 AI 的一些思考和实践。我和我的同事牟骞会从现状和挑战出发，讲一下我们方案的原理和实现，最后介绍该方案在团结引擎 crash 治理中取得的一些落地进展和实际价值。

Vibe Coding 的现状与挑战

AI 辅助编程前两年就出现了，2025 年呈爆发态势，百家争鸣，甚至出现 vibe coding 的概念。Claude code 作为其中的佼佼者，给开发者带来了前所未有的智能编程体验。

从 Microsoft、GitHub、Stripe、Amazon 等官方报告当中可以看出，AI 编程占比持续提升，而且有非常不错的价值。但大家有体验 AI 编程的话，还是会发现AI 会出现记忆断裂、编造信息、擅自调整需求，或者是长时间执行但是没办法完成任务的情况。

分享一些我们团队中使用 AI 的问题，我们会发现 AI 擅自缩小任务、不听指挥、越改越差，一个问题修出两个问题。并且因为这些产品都是 toC 的商业化产品，面临大量的 token 限制和模型限制问题。

谷歌 Osman 也曾在访谈中表示，AI 辅助开发存在“70% 陷阱”，AI确实在 70% 的时间内就可以完成工作，但是在深层次问题，比如性能、边界、兼容性，扩展性方面，存在比较大的视野盲区。比如AI修复了血条不显示的 Bug，强行显示，但这样导致了游戏崩溃的问题，就是所谓的“后退两步”循环陷阱。特别是在一些大型项目中，更容易出现我们之前提到的记忆断裂、信息编造的问题。为什么会出现上述问题呢？我们总结了 4 个方面。

用一个比喻来描述：我们招聘了一个逻辑能力很强、具备丰富的知识储备，但工作记忆有限，一次性只能聚焦小部分内容，看多了还容易忘，有时候会出现一些思维幻觉的外包新员工。外包公司的老板为了推销他的员工，告诉我们员工非常好，具有博士级别的智能。听说是博士，我们让他做大型任务。实际上在超大型游戏工程当中往往出现非常大量的游戏信息，比如百万级别的代码，数十万级别的游戏资产，即使是游戏行业的老专家都需要花大量时间才能把游戏的上下文理解清楚。我们这位新员工确实可以把大型任务拆分成更小的任务，但还是缺乏游戏工程上下文的耦合性理解。并且也不是很了解我们对于交付的要求，虽然知识渊博但是不了解具体项目。同时做的过程当中很容易丢三忘四，有时候会编造一些信息。最为关键的是这家外包公司的老板为了考虑公司的收益和利润，会控制员工不能加班，所以员工一看该下班了，就交付了自己觉得还凑合，但是实际上并不太 OK 的交付物。

这个时候如果我们给他安排一个成熟的导师，导师能完整理解游戏的上下文工程，将任务和上下文耦合，并清晰地传递交付标准，并且在员工交付以后可以 check 员工交付结果，这个新人就能有比较好的发挥。这就是为什么我们会有这样的说法：如果能够带得好新人，大概率也能用得好 AI。我们聚焦关键洞察上，发现 AI的生产过程是不连续的，只能片段性产生一些过程交付物，但是我们这些专家的专业知识和宝贵经验把 AI 离散的产出串联成为了一个整体。最近有一个比较有意思的说法，因为 AI 的兴起需要很多专家来赋能，让我们这些 35+ 的大龄工程师又迎来了职业第二春。

这也是今天我们讨论的核心点：如何让 AI 更长时间地、更全面地、更独立地工作？以及刚才提到 AI 需要配合专家的经验，如何降低 AI 的使用门槛和能力要求？在英伟达的 GTC 峰会上提出了 Agentic AI 的概念，这种类型的 AI 希望在尽可能少的人工干预之下，让 AI 面向目标自主规划和自主完成任务。接下来我们介绍一下如何实现 Agentic AI 的思考和方法论, 我们称为可微智能。

可微智能的认知原理

先看一下模型召回的本质：同一个物件，不同角度下产生不同投影。事物本身没有变化，取决于你从什么角度看待它。我们知道，大语言模型通过大量的数据集进行预训练，给到的提示词就是投影的方向。

举个例子，比如说天美的《王者荣耀》，假设有一个英雄既可以打上单，也可以打野，如果提示词只是问打野的攻略，大概率只会告诉你打野的信息，上单的信息不会告诉你。也就是说提示词会决定大语言模型怎么回答你，提示词越详细，大语言模型越听话。背后的本质是从高维数据集到低维数据集的投影，带来数据丢失。

从流程上来分析这个问题。当前大语言模型的数据集是有时效性的，希望大语言模型通过联网搜索用最新的信息来作答，但是这种作答方式是 Vibe 模式，也就是召回、重组、生成三个步骤。有几个重点:信息获取过程依赖数学形式的表达，即 embedding+rerank， 也就是语义级的关键字搜索、相关性重排。这个过程和在搜索引擎中检索信息非常相似，过程是有信息丢失的。关键字就是投影方向，搜索不同关键字出来的信息是有一些遗漏的，我们称之为信息熵增。

因为上一步召回的时候有信息错误，重组的时候就有很大的概率产生错误结论。因为大语言模型的上下文是有限的，我们又需要迭代进行 RAG，迭代过程当中会不断放大信息熵增。举个例子，有一个任务是 99% 的成功率，迭代了 300 次之后失败率达到了 95%，迭代一千次以后失败率达到了 100%，迭代次数越多失败概率越高，这是为什么 AI 处理大型任务有比较大问题的关键原因。

最后看生成，AI 的生成是黑盒，并不知道生成过程，出错以后没办法回溯，只能修改提示词。我们使用 AI 的时候有一个概念是抽奖，我们总在抽奖。从流程中，我们可以明确发现如果希望 AI 稳定工作，关键就是控制信息熵增。

受到数学可微概念启发，曲线是由无数小直线拼出的近似图形。是否可以将大型任务通过专家的经验拆分到足够小，以至于单步 AI 有足够的能力完成，从而构成 AI 连续长时间稳定工作的基石？我们由此提出了可微 AI 的概念，分成三个关键点：可微分、可预测、可逆性。可微分，即 AI 执行过程中，不会出现超出 AI 能力范围的任务；可预测，即通过当前流行的上下文工程，让 AI 对于工程环境能顺藤摸瓜，从而对修改产生的影响有更全面的判断；可逆性，很容易理解，指 AI 的执行过程需要可以被回溯和调试。

我们用导航来比喻，在一条都是坑的马路上，有些车比较长，如履平地；有些车比较短，就会掉坑。有两种思路解决：一种是把车造的越来越长，做更新更牛的大模型，另外一种方式是修路。两种方式本质上没有对与错，现在我们选择更经济更现实的方案是修路，让 AI 去更好地执行。

预测性就比较好理解了，我们一开始知道哪里会堵，哪里限号， AI 做决策的时候就比较好做可预测的决策，寻找最优路径。正是基于可微的思想，我们也在游戏的 crash 治理这个问题上实现了可以长时间无监管地完成长距离推理的 Agent，并且适配了国产的开源模型，不仅大幅降低了使用成本，提升了安全性，也一定程度打破了目前地缘政治下，海外模型对国内的封锁。具体是如何实现可微 AI 的方案，接下来有请工作室的专家工程师牟骞和大家分享。

牟骞：感谢各位来宾，我是天美工作室的牟骞，我给大家介绍在可微 AI 的基础上，我们如何进行后续的工程实施。

可微智能的技术实现

在这一领域，我们主要是启用了范式的开发。范式是今年上半年流行的，特别是在 OpenAI 出来以后，大家把这类问题归纳到范式解决方案。这块我们主要完成可控性、连续性、可回溯性、可导性方面的约束。

我们在这个范式中做了几大部分。首先是对预置的 AI 领域专家见解做了大规模的拆解，我们做了一些预置埋点，让 AI 在工程当中进行预先的点分布，在正确的路上做正确的事情。

第二部分范式我们有任务的数据结构，可以是任意的结构，树结构、图结构、列表架构，加以状态机的运行，主要提供非常强的可控性。我们对所有要完成的任务进行了统一结构和状态机处理。

第三部分是上下文工程。来自于最早 2022 年 AutoGPT，有足够强的大脑，助手提供无限的上下文，只要大脑有足够强的推理性和上下文足够完整，就可以解决任何问题，这是我们做上下文工程的核心关键。

因为详细的拆分，我们对模型能力的要求进一步下降。好比在同一个模型上，一次性做十个事情可能注意力有限，但是如果分解成一次性做一个事情，就会做的非常棒，因此我们对于模型能力要求会大幅度下降。

AI 范式第一部分是数据结构，可以根据明确的目标范式。比如针对 Crash 的治理，拿到 Crash 的内容是已经崩溃之后的线索，并不是内存的实时反馈，所以我们对它的链路只作为模拟和猜测，然后进行探索的过程，这种探索的过程更适合用树的结构来承载。

第二部分是状态机的执行，我们对于执行的遍历顺序、执行入口、失败回滚、长效的任务都有比较好的控制。这样每次 Prompt 放进去以后，第一步成功了，我们把状态直接引到第二步调试，这样哪怕工程发生任何问题，后续都可以对它进行持续的任务规划和再检索。

这里我们整个工程范式的使用流程如上图所示，从明确的范式目标——探索型范式使用树结构比较适合，到选取数据结构，定义状态机，然后选取大语言模型。因为每一步工程可能都会有任务偏向，对于大模型能力是有要求的，所以我们选择不同的模型组合搭配使用，既可以得到更好的任务效果，也降低了任务成本。最低的模型只要可以正常使用，成本甚至低于每千 token 4B 或 8B。然后会构建范式，把复杂任务范式进行初步的信息填入，构建范式进行运行，最后进行范式级的优化，得到最终的结果。

以树结构为例，任务树的构建从 root 节点、第一层到第二层，数据节点包含了任务描述、上下文，子父节点、父节点之间有引用关系。树结构先天就有上下前后的关系，自然表达了要先做什么后做什么，在深度维可以表达顺序。执行策略可以是广度优先、深度优先、或优先度遍历，这样在迭代整个树的时候，迭代顺序在一开始范式运行的时候就确定了。

第二个部分是节点维，表示当前处理的节点正在进行什么操作。我们可以在节点和节点之间有一些额外的策略，比如在深度相同的情况下，两个不同的节点如果是离散的，则此时是可以并发运行的。

还有步骤维。步骤维是指处理单节点任务的时候可能分成多维，例如召回某一个程序代码符号信息，查询引用，可以一步查询多维。传统的 agent 流程更多是模拟角色的身份介入，而步骤维是以事来介入。我们在这里的目的是增加复用性，并且适配更多的模型，例如第一步用更好的模型，推理性能很强，第二步对安全性要求很高，选开源模型，混合使用，可以在步骤维达到最好的效果、最低的成本和推理时间。

在工程优势上，我们在性能方面、颗粒度方面和故障容错方面都有非常好的实际应用。在三维上进行遍历迭代，用状态机的方式运行，可以做到精确导航。这里最大的区别是实际任务当中会不会控任务流程，Cloud code 运行过程当中是自主决定 to do list，虽然也有类似状况机，但是并不是强控的状态，是大语言模型自身决定的状态，导致可能在复杂工作情况下，和预期会有不对齐的情况。

这里面可微执行的核心是状态机每步执行状态都是可微、可控的，明确表达了我们在整个图上遍历的连续性和可导性，也是对可微思想的延续。

这是非常重要的上下文工程部分。我们在中间需要给 AI 提供足够多的丰富信息，这些信息在整个工程里面都是以摘要+图结构的方式来表达。我们会对代码库进行摘要和图结构关联，对创意设计库也采取同样的方式，包括从策划案、UX、原画，或者 TDD 技术拆解文档、代码库、代码符号都做完整的摘要。比如来了一个新的技术同事，他永远会问几个问题：代码应该写在哪，这个功能是不是之前开发过了、当前状态是什么，应该遵守哪些规则。这一系列的问题上下文工程都会提供，提到的每个问题在每个库里面都能得到上下文关联，并且根据扩展关联在周边进行搜索，得到非常完整的上下文，这样决定了在整个上下文工程里面的信息可微度和不丢失。

这里重点讲解代码库关联关系如何构建。首先是代码库部分，需要它以图结构来完整表达在代码符号中的关联关系。程序员是如何在整个代码中导航的呢？大家都用过 IDE，我们最常做的事情是在代码中用鼠标选取某一个符号，然后 control+ 左键转到符号本身的定义，或 F12，或在符号上右键 find all reference 查找引用，这层关系为我们提供了完整的代码导航，我们希望代码导航的能力同样提供给 AI。在 IDE 使用这项技术是微软在 2016 年和 Red Hat 提出的 Language Server Protocol 协议，通过 JSON-RPC 查询到代码之间的语义关联。在这一架构下可以完整得到代码导航，就可以让 AI 像人一样搜索引用、获取定义、获取所有关于代码符号的上下文信息，都可以存入 LSP 图数据库，在最终的检索效率上非常高。

与 Embedding 对比，问题在于我们产生的符号从文本的角度上是符号，通用的命名在很多地方都会出现，embedding 搜索取了向量阈值相似度，如果搜出了一百甚至一万份，如何区分这个符号是不是目标符号？只有符号表才能确定在规定的作用域和生命周期之下才是我们所需要的符号，这是我们引入 LSP 的技术关键。

可微智能在 Crash 中的落地实践

可微智能在 Crash 中落地，我们主要通过全局视野分析，深度因果处理，自动化处理、知识传承，同时把项目里面特殊的一些用途进行植入，让它在全局中既可以在上下文中搜索，也可以结合专家经验进行落地，看一下具体实施。

发生了 Crash，有可能来自于不同的语言，比如是 C++ 的底层 +C# 中间层 +Lua 脚本，报错的时候可能会涉及到三种语言，这个时候会先把三个类型的堆栈按照时序进行混合。第二步分析和整理堆栈的一些数据，然后插入到超级范式。这里因为调度有顺序，我们会把每行的堆栈当成深度维的节点进行插入、探索。这里主要解决的问题，就是在中间会自由 add task、executer、set clue、set conclusion，这部分起到的作用是解决复杂域的问题。例如 A 给 B 赋值，B 给 C 赋值，C crash 了，A 和 B 并不在堆栈上，我们要找出来 A 在哪。作为常规的 cloud code，最多分析出 A 报错了，但绝对找不到 C 是罪魁祸首。这样的情况下我们采用了超级范式，add task 会找到因为 A 报错了，所以去 find all reference 查找什么地方引用它，根据堆栈的推理得到了 B 的线索，然后验证线索是否是可被梳理的，这块如果 OK 又找到了 C，对 C 的情况进行分析，产生一种可能性。所有的超级范式进行完整流程的时候会进行回溯，会模拟在这种分析下这样的路径是否可达成。如果可达成，最后出错的部分一定是报错的部分。

上面的例子是多线程竞争下产生的问题，典型符合刚才 A 到 B 到 C 的情况，并且 C 的赋值不在同一个线程当中。首先会找到直接问题原因的总结，其次在调用路径上进行复述，然后会找到根因也就是就是 C，C 是由哪块导致的，要有完整的证据链，还有问题的引入上下文，找到最近会有可能引发问题的提交人，最后还给出了如何修复，并判断影响的下载面，这部分是对整个模块修复以后会产生的额外风险的评估，修复的紧急情况也会做完整阐述。

同样，案例 2 也是多线程引发的栈溢出，对比传统需要引入更多的线程框架、更复杂的时序、在静态情况下重现，其实是非常难分析的问题。

看一下最终的演示。这个演示是在早期的版本里面用 LangGraph 建立的，通过引擎合入新版本 USYM ，实现了 il2cpp，进行了 C# 和行号和符号之间的映射。可微范式下找线索-分析循环以后，得到了最终产生的结果。

总结一下，在实际应用过程当中，六个月时间就产生了 1000+ 用例的验证，Doctor 系统在运行效率、成本、准确性方面都做到极致的提升。在商业价值量化上，我们统计了 89 个问题，平均每个问题处理时间 20 分钟，效率提升 80% 以上。单个问题堆栈消耗 1M 左右，成本大概是一块钱人民币。我们最早的开发是基于 cloud 3.7 sonnet 模型，每个单子成本是 15 到 18 美元，到现在一块人民币，有数百倍的提升。并且是国内的开源模型，最终适配千问 3，235B，128K，是我们所有使用模型当中推理性能最高的，当然也有一些小模型跟随。间接的商业价值是，我们可以快速得到用户反馈、专家经验固化以及团队效率提升。也完美解决了目前国外模型对国内的封锁问题，对自身产品安全性的也有保证，并且节约了成本。

以上就是今天要分享的 Doctor 系统利用可微思想治理 crash 得到的阶段性目标，今天的演讲到此结束，谢谢大家！

Unity 官方微信

第一时间了解Unity引擎动向，学习进阶开发技能

每一个“点赞”、“在看”，都是我们前进的动力