畅游技术总监黎志刚：游戏AI Agent的落地实践与踩坑总结 | 游戏观点

【游戏新闻专稿，禁止转载！】

游戏新闻报道/AI圈子今年最热门的话题，一定绕不开AI Agent，年初甚至出现全民讨论的“小龙虾”热。在游戏圈，基于自主感知、自主决策、自主执行的特性，Agent也成为AI落地游戏开发的核心发力点之一。AI Agent如何落地游戏场景，一直是行业人士最关心的话题。

6月5日的腾讯云AI产业应用大会·游戏专场上，畅游高级技术总监黎志刚以《游戏行业AI Agent的实践之路》为题发表演讲，披露过去一年畅游如何构建AI Agent在游戏场景的实践落地，分享了内部踩过的坑和宝贵经验。

以下是游戏新闻整理的演讲内容：

大家好，我是来自搜狐畅游的黎志刚，今天很高兴来向大家分享过去一年我们公司在Agent方面的经验，但是今天篇幅有限，我更多讲的是构建过程中的思考和遇到的一些坑。

接下来这段时间，我会从这六个板块来同大家分享。

趋势这块，相信大家都知道，去年开始整个Agent落地速度非常快，我们也是从去年开始一直做各种Agent、包括管线构建、Skills等设计。这里有一个大家都会去思考的核心问题：做了那么多AI后，落地的效果怎么样？

可能很多公司和团队都会去复盘，发现做了很多东西，但最终应用上线后，比如成本有没有降低，团队效能有没有提升？可能反映出来的效果没有那么明显。我们也会做大量的复盘，过去一年基于每个板块在做复盘，发现了很多坑点，

游戏场景落地时，我们在开发的过程中发现，要打通整个上下游是很困难的。

如果我们只是做单个场景很容易，比如只做运维更新、回档等，不管是做Skills或是简单的Agent，都是OK的。因为畅游用十几年的时间做了大量的自动化系统，已经实现了很高的智能化，节省的人效和效能已经很OK了。

那为什么还要做智能体？我们复盘效能数据和流程的过程中发现，决策计划生成的过程中，还有大量环节是由人去做的。这里有大量的经验，还有大量需要继续判定的规则，很多东西其实是灰色的，或者说是没有进行量化、信息化的，这部分非常重要。

而且随着像Harness Agent这样的新框架出来以后，我们发现，如果希望让经验变得更加有思维，或者说让他能够自学习成长，这部分也是很重要的。

在畅游构建智能体的过程中，团队最开始会考虑：大模型能力适配性很高，所以我们把所有东西都对着他，那大模型就可以帮我干很多事情。但我们自己跑完以后发现，不是这样的。

大模型有它的强项，能帮我们收集相关工具的信息，以及当我们提供相关信息以后，它去调度很多程序，包括我们已有的自动化系统。或者举例子，腾讯云提供的WorkBuddy，它会帮我们去进行硬编码，构建一个直连我们的终端系统以及自动化教务系统，然后根据需求帮助我们做自动化，这都是OK的。

大模型的强项能做什么、我们要给大模型提供什么，以及在真实生产环境里应该干什么？这里是有区分的，不是说所有东西全都由大模型来做。

整个过程我们内部会分成三层来做，最下面这层，我们会把内部系统和要调度的服务全部MCP化，不是让大模型直接硬编码或者通过Key的方式，直接连我们内部的系统，这样是很不安全的。

特别是对运维场景来说，它是生产场景，线上几百万、上千万用户都在使用这样的服务。如果让大模型直接去操作，不管是幻觉问题，还是理解问题，都会导致一些非常严重的事故。所以我们是不会让大模型或者智能体直接上生产环境的。

但又要让他去干这件事情怎么办？我们反思了一下，现在做的大量自动化工具、平台，或者所谓的链路，已经可以提供给智能体，让它作为工具来进行调度。智能体要做的事情就是上面这层，我们要去构建Skills。

这些Skills在构建过程中又要区分，比如我们在应用场景中已经做了自动化部分，也就是所谓Workflow已经进行静态化这部分，要不要去进行智能体化？这是有区分的。比如有些项目非常老，已经运行了十几年，它的规则是不会变的。唯一会变化的就是活动，这些都是固化的。那不建议对它进行很深度的智能化，但可以做一件事情，需求的意图识别和自动执行。

比如当产品或者运营给你发邮件，或者要求你下周四更新什么。最早是怎么做的？是由运维或者说有产品提取相应的需求，发需求邮件、接到需求邮件，运维做工单，再去调自动化系统执行自动化工作流。

整个过程中需求的意图识别，不需要再用人分析，现在大模型的意图识别，可以写很多的规则和关键词，直接让它生成工单，工单也不需要人填了，整个自动化系统可以和智能体进行有效的关联。

最上面这层，比如做Skills或者构建智能体，有什么很好的工具吗？Skills有很多的设计方式，我们去年用了很多的工具。但在WorkBuddy出来以后，内部做过一项统计，用各种智能体生成的数量，WorkBuddy会非常多。

当然这不是给腾讯打广告，但真实数据确实是这样的。因为它相对友好。其他工具有一定理解成本，因为有一种开发思维在里面，你也可以一股脑全丢给他，但要进行对话修复的轮数会比较多。我们最长可能通过280多次对话，才能让它帮我修出一个相对可用的智能体。还不能直接发布使用，因为在本地的沙盒运行完后还要进行工程化部署。

WorkBuddy比较好的方式就是，可以在本地PC直接跑一个最小的MVP，哪怕通过硬编码的方式跑通一个专题，但可以把这个工程直接放到我的工程目录里，让它再进行二次强化和实践，这是没有问题的。

所以我们过去半年一直在用WorkBuddy做最小化的MVP再移植线上，至少跑通了三个大的项目落地。

这是三层框架去实现的方面。后面是Skills蒸馏这部分，我主要想跟大家聊得是，是不是我们所有存储的技能文档、所谓的历史文档，都要向量化后进行Skill生成。

这其实不是特别理想，我们第一次做的时候，把上万的文档全部丢到了一个向量数据库，然后对向量数据库进行蒸馏，针对岗位、操作、行为、工作流去抽离相应的Skills。但效果非常不好的。原因很简单，每个人写出来的文档，以及落地的工作流是参差不齐的。第一是标签信息不统一，第二就是业务场景信息缺失。

举个例子，我们需要把《天龙八部》整个运维工作全部放进去。但《天龙八部》项目的架构、特性，更新过程中要注意的点……发布文档里很多是没有的。我们需要一张完整的业务图谱，也就是所谓的知识图谱。

过去很长一段时间里，我们在做一件很重要的事情，把所有业务的知识图谱做了一次相当深度的梳理。这不需要很多时间，一线的同学在开发过程中每天都是这么干的。梳理完后我们进行标准化和向量化的处理后，再把它形成一个规则引擎。

所以除了Skills本身以外，不要把知识库全丢到向量库再去生成Skill，里面可能会产生比较大的偏差。

另一点是知识库非常需要，它可以提高后续经验乃至于Skills的优化和晋升，但不能每次都让Skills或者智能体去向量数据库里面去捞一遍。举个例子，向量数据库好比有2万人，我们不能为了找一个人每次运行Agent跑到2万人里面去搜一遍，其实可以做一些相应的抽离。

最近GitHub上也出了一些相应的框架，对知识库的优化，还有知识库、向量数据库蒸馏的操作。所以我们对向量数据库也做了相应的切割，把智能体、Skill调用比较频繁的东西全部抽离到上层，不让它沉到庞大的向量数据库里面。

而这些所谓的规则和技能也会慢慢通过Harness Agent进行自我学习，发现比如哪些东西不再是一个接口、Skill要调用的服务和参数，而是应该固化的 Agent服务，它也是可以去做的。

过去一年最难的，是思维意识的转化。先不说非技术团队，技术团队里有大量的同学，对AI或者大模型的使用可能还停留在“应用”阶段。

我们内部把所有同学对AI智能体的使用能力分为两个阶段：一是应用阶段，不管是通用大模型还是WorkBuddy，能够用它完成自己工作的提效，我们认为达到了大模型和智能体的应用能力，但还达不到所谓的“智能体化”。

什么叫把自己的工作流智能体化？举个例子，比如天龙项目组的同学认为，他能把自己的工作场景和工作流全部梳理完后，将整个管线做成一个大的多智能体工作流。这时我们才认为，他达到了智能体化。

这里有一个很核心的点，很多同学会把自己做的手动做的所有事情，一股脑丢到大模型，或者所谓的智能体里让它去生成。以前是比较难的，但随着大模型现在的智能化程度，60%的情况会帮你区分出来。

当然我们内部做的话，会有一个产品化思维的Skill，可以把你的工作场景和业务场景通过自然语言的方式丢给它，帮你进行AI产品化切分。比如告诉你什么样的东西要放到智能体构建，哪一块要做MCP，哪一部分要做Skill……

如果要做智能体处理，还有一个关键点是，方式能不能完全智能体化？可以，但效率是有限的。相当于我们把人是怎么干的全部给了智能体。智能体如果照着再干一遍，做的就是一个自动化，效能提升有限。

我们需要打破现原有工作流重新来看，要从执行者变成指挥官。

举个例子，原来我们是一个项目的测试或运维，但转变完后可能是这个项目的负责人。预计版本周四发布时，他要考虑版本什么时候能出包，包过来后什么时候能快速进行预测，什么时候能快速上传CDN……整个管线都可以自己跑，不再依赖于上下游各个部门。当然，这里也依赖于各个部门的打通。

另一点就是流程。以前我们总讲必须遵照流程。在智能体时代，流程非常重要，但还需要升级。流程不是一成不变的，日常工作过程中人思考的那部分叫“弹性部分”。比如说有时候我们说的“刷脸”，按原来的流程是不能用跑的，但我想办法给你去跑，这就是弹性的部分。但其实智能体已经可以做到。

另外一点就是说，非技术同学、特别是平台部门的同学，用智能体的时候会产生天然的恐惧。

他们会有一个先入为主的观念：我不懂开发、不懂编码，所以没有办法构建自己的智能体——这是过去常有同学给我们反馈的。但当我们教大家用WorkBuddy这样的平台以后，他会发现，不需要自己写代码，告知需求智能体就会帮我们去生成一套自己的生产流。

举个例子，HR可能每周都要给某些固定的团队发各种各样的周报。以前的做法是手工算，每周都要花好几个小时。当我们教会他用WorkBuddy以后，他可能直接把原始数据文档丢给WorkBuddy。再编辑了一个Skill工作流帮他处理，定时每周几点发送给谁，大幅降低时间。他做完了这个案例以后，发现没那么恐惧了。

这里有一个很大的点，如果我们一直在想怎么做，不如先把帮他迈出第一步。先做一个最小的场景，他自然而然就不会那么恐惧。

为什么要讲Agent定位？最开始内部讨论很激烈的一点是，我们已经做了那么多的自动化系统，为什么还要做智能体？如果要做智能化，是在原来的自动化系统上改造更合适、还是说从头做更好？以及整个投产比是什么样的？

我们内部团队也做了大量测算，包括成本以及投入的时间周期。各方测算下来，我们发现如果在原来的自动化系统上做升级，效能会有微提升，但是带来不了较大提升。举个例子，原来有几十个人去维护十几个产品，但我们做完后只能降低1-2人的工时提效。

但如果通过智能体化重构，则是把工作场景和工作流、业务场景全部打散重新组装。比如运维场景是接需求，然后自己解释需求，自己再用自动化脚本去配置自动化工作流执行。我们现在做的方式很简单，智能体自己理解需求、自动生成工单，或者用TAPD也挺好。

生成进去后因为已经标准化，下一步不管是写脚本、自动化系统，还是你自己构建的工具都没有问题，执行什么都可以。相当于原来由人去理解、规划的部分，以及看着它防止出错和审核这部分，都可以交给智能体去做。而且这些智能体不是一个技能，每一个智能体节点都由多个技能构建。

另外是场景落地，什么样的场景需要Agent，什么样的场景不需要？

如果我们的场景固定，且已经跑得非常稳定，没有较大变化，不需要做规划和决策，Workflow跑得特别好的，可以先让他跑，因为这部分做了以后提升有限。反而是对那些需要大量人工操作的，比如刚刚提到的HR，或是人工收集的部分，包括资产治理里的成本测算，我们可以通过Agent解决这个问题。

还有一点，智能体一定就是安全稳定的吗？不是，它存在幻觉问题。Skill也不是越多越好，Skill越多幻觉可能会更严重。

最后一个问题是，有那么多智能体和工具，工程师难道都去送外卖吗？肯定不是。我们内部讨论的时候，发现运维工程师有一个天然优势：工程化。大模型、智能体都必须进行工程化，不能纯在测试环境或者开放环境跑，一定要进行工程化。因此，AI智能体工程化的工程师是很需要的。

第二点就是架构师，我们不会再去做具体的执行，而是架构。当一个项目进来以后，他就可以搞定跟运营相关的所有技术线链路，版本出来相关的执行也是OK的。其他的岗位就不说了。

说一下落地场景，运维场景落地的数据非常好，因为这里有70%的数据是自动化系统已经实现的。剩下的20%，主要是智能体帮我们做的智能决策和智能方案，这部分速度比较快。

下一个是测试场景，这是最近半年我们啃得最难的一件事。游戏测试是很复杂的，每个项目不一样、功能也不一样，怎么样才能让测试快一点？

我们最开始的做法是通过人工写测试用例，但浪费时间比较多，所以我们写了一个测试用例自动生成的智能体。它可以通过历史测试用例的知识库，快速提取这个类型游戏测试用例对应的功能模块。直接出相关测试用例的准确性，我们内验了一下，大概70%可以直接用，还有一部分需要手动改。

第二部分，我们思考的是人工测能不能变成不需要人工测，比如测试跑一遍直接生成视频后，视觉识别大模型通过识别它的坐标、识别它的元素，捕捉形成自动化脚本让它直接进行回放，解决大量回归和复测的问题。这部分我们内部也做了工程化的落地。

目前来看，捕捉是可以的，但时间特别长的时候幻觉问题就出现了，捕捉的很多东西会丢，这是我们还在攻坚的问题。有些东西我们正在做，但回放是可以的。

游戏开发里面最核心的，是客户端和整个工程化开发，畅游内部研发中台做了一个很有意思的事情，他们做了自己的cycode的平台，实现了服务端的智能化开发。它所有的逻辑、消息处理，业务逻辑的处理大部分都不需要人工生成，而是平台直接生产。这部分依赖前期功能产品文档的详细程度、规范程度，如果做的好可以一键生成，如果不规范的话，一个后端开发同学就可以去做这件事情。

这其实已经有很多项目在跑，这部分依赖于游戏项目的沉淀。我们公司有些项目有大量服务端的老代码，也就是所谓的基座。我们以前的做法是自己去做基座分析，但现在有一个比较好的Understand Anything的框架，可以对老代码进行知识图谱化，快速提取出老代码里面的参数接口。你们可以尝试，我们内部尝试效果很好。