【GameLook专稿，禁止转载！】

GameLook报道/随着AI从风口到实用技术的落地，越来越多的同行开始将AI融入到自己的研发工作流当中。不过，如今的AI大模型和工具，绝大多数都只能在特定研发环节帮助同行提升效率，真正能够一句话生成可玩游戏的模型，仍在探索中。

最近，在5月23日举行的”出海文娱增长闭门会“上，来自港中大MMLab的姜一雷作了题为“OpenGame：从自然语言到端到端可玩的Web游戏”的演讲。他分享了LLM如今做游戏的难点，并介绍了他参与的codeagent项目OpenGame的“解题思路”。

通过OpenGame，你只需要自然语言，就能指挥agent写代码帮你研发游戏。据姜一雷介绍，如果是做2D网页游戏，在该模型的模板基础上，大概一周时间就能做出可玩的产品。

开源地址：https://github.com/leigest519/OpenGame

那么，如今的code agent能做成什么样的游戏？还面临哪些挑战，以及未来会走向何方？

以下是Gamelook整理的完整演讲内容：

姜一雷：

今天很荣幸能向前面的各位学习，然后能去分享我们最近做的一个开源项目，叫做OpenGame，它相当于是面向game coding开发的Agentic框架。

在此之前先介绍一下我自己，我叫姜一雷，目前是港中文MMLab博一的学生，同时是在某大厂的基座团队做LLM的强化学习预训练的工作。我个人的研究领域也是Agent，以及怎么针对Agent能力的提升去设计一些框架和底层算法，相当于是通过强化学习去提升基模的能力。

今天的内容目录大概是这样的：

为什么我们要做这个工作，这个工作里面大概包含什么，以及怎么评估的。然后我也想讨论一下，从技术方面来讲，想要做成现在这样Web Game Coding的Agent有哪些技术上的难点，以及未来可能去怎么发展。

首先，为什么游戏code agent是比较难做的？我们这个东西相当于做了一个类似于首个开源的整体框架，能够把输入的一句话，就是自然语言，一句你对游戏的想法或者游戏设计，能够把它变成一个完整口，在这样一个2D的网页游戏。是一个端到端以及全自动这样的一个框架。

我们做了三个主体：一个是我们搭了整个agent，相当于现在用的词叫harness，相当于是为了针对这个任务去创造出一个比较好的harness；另外我们也去训练一个中等模型的基模，是27B的一个基模；然后相对应提出一个怎么样做评估的方法。

为什么游戏对LLM特别难？

为什么说游戏创作对大模型来说，尤其是对现阶段的LLM来说是比较难的东西，因为一个真正可玩的游戏其实是一个实时系统，它包含了一些主循环物理事件的处理，也包含了很多像美术、音频这样一些资源的管线，它是一个非常非常庞大的、相对来说非常复杂的系统，product system。

然后它中间跨文件的一些，无论是导入或者调用，其实耦合都是非常紧密的。现在LLM，比如说它在解一些coding题目，或者去底下的单个文件代码上面其实表现得会非常不错。但是，如果让它去写一些非常复杂的工程，尤其是从零开始写，比如说我想搭一个可能是二三十个文件的项目，你让它从头开始写，其实现在的通用Agent做的非常Bug。

从我们最开始的实验中，我们发现有3类失败模式，第一个是逻辑不自洽，比如说整个全局状态在主循环里一直漂移。另一个是对于你想用的这个游戏引擎，它对这方面的知识感知不是很好，比如说引擎里面已经实现了一些功能，但它不知道有这个功能，然后它自己想要从头写一遍代码，而不是去调用引擎里的某一个功能。第三个就是跨文件不一致。相当于它在创建project level项目的时候，跨文件调用非常差。

目前想到了一个方法，我们想把这个coding agent，在它的基础上把它专业化成为Gamedev的专家。

然后我们做出来大概是这样一个效果：

比如无论是个人的创作者或者甚至是教育领域，比如说老师现在想要把课堂变得更有趣，还是一些自媒体的创作者都可以根据他们想要的话题或者知识去构建出来一些更有意思的内容。

我们整个游戏的涵盖类型也非常多，无论是像马里奥这种平台游戏，还是保卫萝卜、植物大战僵尸这种类似塔防的游戏，亦或是UI heavy类似影游那种的，其实也都是可以做的。

因为时间限制，我这边就大概过一下我们这个东西是怎么做的。

首先是代码模型训练，我们在Phaser上面的宇宙上做三阶段的训练，首先是CPT，然后是SFT，然后再加上RL，这是一个比较常规的过程。

主要还是搭了一个agent harness，这里有6个阶段，首先分类就是针对每个游戏的类型去维持一个最小化和功能化的一个code agent，便于它在写游戏代码的时候能直接调用它，而不是从头开始写。所以第一步要有一个分类，比如说物理引擎，他可能是一个平台游戏，也可能是一个上帝视角游戏，这种类型就不需要考虑重力因素。

之后就是GDD生成，文档生成，资源生成，到最后相当于提取中间这个模板，然后直接把里面的hook给填上，最后是一个验证。中间的话就是训练的过程，以及我们管线的过程。

最后就是相当于Agent在过程中会不断演化自己，比如说我们首先会维护一个meta campaign，它是一个非常原始的母模板，针对任何游戏都可以调用这个模板。随着给他一些真实认知的任务过程中，比如说建一个马里奥式的游戏，那它建完之后，我会让他把这种游戏所需要的模板提取出来，放到我们的模板库。

这样，在下次遇到比较类似的游戏的时候，就可以按图索骥，直接提取出来比较类似的模板去用，往里面填充hook就可以了，就不用从头开始写。

device skill也是针对容易出现的bug，相当于每天的一个MD file，无论是在验证过程中还是下一次从头开始生成过程中，能让它把这个东西debug好。

接下来也比较困难，也就是这个游戏怎么玩？它和普通的代码其实还不一样，普通代码你可能有compile（编译）成功、test通过就OK了。

但是游戏不一样，游戏也有三个阶段，第一个阶段是这个东西能不能编译成功，如果都不能编译成功那肯定不行。第二个阶段就是里面有没有bug，比如有些游戏做出来它可能有bug，比如我们用SOTA模型去做马里奥游戏的时候，它完全不知道这个游戏角色的身高和它能跳跃的阶梯高度之间的关系，导致这个游戏永远无法通关。

第三步，游戏最重要的是好玩，那这个趣味性又怎么衡量？这不是更难了？所以说这个东西本身衡量起来是非常非常困难的。我觉得在我们这个工作里面，现在这个阶段只能尽力做的好一些，但是我们承认肯定不是完美。我们衡量三个阶段，也就是三项，第一个是build，能不能渲染，能不能编译；第二是游戏画面怎么样，就是我们从中间截图然后给他打分。

第三是和用户意图是否一致，就是比如说我在游戏里想做几个功能，我想要这个游戏有3个关卡，某个人物有什么功能，或者我想要交互技能是WASD还是上下左右，也就是你做出来的游戏是否和用户需求一致。

从结果上看，我们这个模型和harness都取得了非常好的效果。

Web Gamedev的痛点

最后想讨论的是web gamedev目前的几个痛点以及未来的几个方向。

第一个就是LLM和Code Agent的3D空间理解问题。当然，我们的OpenGame主要聚焦的还是2D游戏，下一个我们已经在做的相当于是OpenGame 3D吧，我们已经在做了。

从我们最开始做的时候就发现有几个比较重要的问题。第一个是3D的问题，比如说，LLM通过Unity或者Unreal的MCP去用或者调用API生成一些3D资产，但生成之后，比如说我想搭一个赛车的跑道，然后我跟它说要搭一个赛车道，旁边要有一堆树。然后这个agent会调用一些API来生成3D的资产，但是它不知道怎么摆，它心里面没有这个东西。比如常规我们应该是中间一条路，树是在两边，这是比较正常思维的一个场景。

但很有可能，他会把一棵树垒到另一棵树的上面，或者说它把树就种到路的中央。就是说，它不知道怎么去管理3D布局，这是非常重要的一个问题。然后像其他的一些比如说穿模，比如说你生成了一些NPC，一生成直接就卡墙里了。

从我们看，这是相当重要的一个问题，我们觉得模型本身是缺乏3D空间先验的，它在text token序列里面推理没有空间的理解能力。一些可能的方向，比如说符号化的空间表示，或者动态闭环，或者物理碰撞信号，这i可能是一些解决的思路。

至于我们是怎么解决，如果大家感兴趣的话，我们会在七八月份的时候会发布出来OpenGame 3D，我们也给出了一些解决方案实现了一些比较好的效果，到时候大家可以关注一下。

第二个点，我认为是非常重要的一个点，就是这个Game Agent怎么去eval，也就是怎么去“玩”到“体验”。这个也不是我说的，之前我跟Unity交流，他们在Gemini 3之后就大力发展AI业务，大家交流认为eval是最痛点的一个阶段，无论是你的agent group里怎么给验证反馈，还是说用RL训练的时候怎么给reward，其实都是非常非常中国要的。

我们大概分两条思路，大概是这么想的：第一个是黑盒的，相当于Game-VLA，就是我们input实时有一句话，就是完全模仿人，因为我不知道游戏的源码怎么搞，只知道这个游戏相当于是一个SDK，直接就用。那就是看这个游戏的画面然后输出动作，相当于像玩家一样把整个游戏玩一遍。

但是我们目前尝试有几个问题，首先这个路线，也就是Game-VLA路线，用现在的仿真模型，在zero-shot情况下走不通，也就是如果是他没见过的游戏让它直接玩，基本上它就是不会玩，效果很差。一个可能的解决方案是用few-shot去做，就是你把比较像的给他做一个in-context-learning（情景学习），或者把这个游戏一些比较重要的交互生成一些技能给他塞到这个context里面让它知道。

这个还有个问题是，比如你真的用Game-VLA去做的话，你想要检验这个游戏中的功能，比如说这个游戏有3关，我想测试第2关，那就必须把第一关玩完之后才能玩第二关。但有一个很大的问题，就是它能不能玩到第二关都不一定。

而且如果一个游戏有50关，我想要测试第49或者第50关，那非要把前面所有关都玩完吗？这个就太慢了，这就完全不可行，无论是agent loop还是rollout都太长了，完全没法做，可能训一个step就要好几天，完全没办法训练。

所以权宜侧可能就是白盒这样的东西，因为LLM、code agent生成的游戏，它的源码是完全accessable的，知道它代码是怎么写的，那么我们可以做一些白盒runtime state injection。核心洞见就是，把玩到某个状态，直接pass到某个状态。

因为游戏它其实就是一个state machine，原先的Game-VLA黑盒玩法是通过一个agent去玩到某个状态。这个state injection就是直接不玩，把参数改到对应state就行。

大概说一下白盒方案的一些思路，比如说直接抽调keypoint，这当然也需要LLM去帮我们，然后往里面注入，再去执行。这个比较快比较稳，但局限就是仅限于白盒自生成游戏，我觉得如果将来技术发展到更好的话，我觉得还是有一个流式的黑盒Game-VLA，也就是它能像人那样实时去玩这个游戏。但是这个需要大模型那块把仿真人模型训练好才可以。

未来方向

未来的方向，当然是从2D到3D。OpenGame是一个偏学术性的，我看到不少创业公司也在做类似的东西了。我感觉2D的技术门槛已经没有那么高了。如果想做的人，直接在OpenGame上改一改，一周就做出来了。技术门槛可能在3D，但是对于产品我可能不是太懂，我只是从技术上来说，所以只是提供技术参考。

今天的分享就这些，谢谢大家。

【GameLook专稿，禁止转载！】

GameLook报道/今天的国内科技股也算是过上了好日子。

此前的中国科技股板块，都是搞硬件的企业各种发大财。反观那些做应用、生态、大模型的公司，却因为高昂的资本支出，以及投资者对其产出不达预期的担忧，导致一个个迎来股价闪崩。

但在6月2日，科技股终于迎来了一个好消息：港股上市的美团、阿里、腾讯三家中国公司连番大涨，上演一出夺回股价失地的大场面。

GameLook作为游戏媒体，最关心的自然还是腾讯。截至6月2日收盘，腾讯公司股价报480港元/股，涨幅达10.09%，总市值超4.38万亿港元，创下自2021年1月25日以来单日最高涨幅纪录。

为何是这三家上市公司引领今日科技股大涨？美团刚刚发布2026年第一季度业绩，由上季度的161亿元减少至65亿元。美团的大幅减亏也说明了一件事：外卖大战即将迎来尾声。同样卷入其中的阿里，可以预见也会降低投入。至少在一季度，外卖行业的内卷整治已经出现较好的迹象。

但阿里还有另外一重身份，腾讯的主力业务也不涉及外卖、电商，这一轮股价大涨更多绕不开AI。字节、阿里跟腾讯都是国内押注AI最猛的巨头，一些AI相关的利好消息，就是能够直接影响腾讯股价。

6月2日，据外媒《金融时报》报道，两位知情人士透露，腾讯目前已完成微信内嵌AI智能体的原型测试，最快将于6月启动公开上线前所需的合规审批流程。完成合规程序后，腾讯计划先向小范围外部用户开放测试，再逐步扩大推广，目前日期尚未确定。

微信AI智能体开放测试和上线时间，最终需要腾讯公司官宣。对腾讯而言，无疑是一件开天辟地的重要事件，据报道，腾讯已将此次推出AI智能体列为最高战略优先级。

可以预见，未来微信不仅仅可以同人聊天、与小程序互动，还可以跟AI智能体进行直接对话、自动调用微信数百万个小程序、乃至小游戏进行互动，将构成10亿+中国网民使用微信的又一个重要理由。微信基于AI智能体展开的商业模式，想象力巨大。

此前，因为没有上市、始终游离在资本市场的字节跳动，每每因为豆包、Seedance等AI能力传出利好消息，会反向制造港股上市科技公司的业务焦虑。大家也都很担心，港股上市的腾讯、阿里能否扛得住。

如今也到了腾讯绝地反击的时刻，即将在微信内嵌未来AI最重要的形态“智能体”，用自己最强大的护城河重新瓜分AI这块蛋糕——这个动作的象征意义，远大于短期内产生的回报，也让我们看到了中国新一轮AI长期竞争的开始，

微信内置AI助手，能有多“恐怖”？

2025年爆火的Manus，较早兑现了“AI替你打工”的可能性，给国内用户和从业者带去了第一轮震撼，甚至惊呆了老外。Meta一度官宣将以超20亿美元的价格收购Manus母公司蝴蝶效应，当然最后成为首个被公开叫停的AI领域外资收购案。

Agent带来的第二轮震撼，则是今年3月的“龙虾热”。这一次，不再只是开发者的狂欢，消费端的大众也积极参与进来。当时，腾讯拿出了空前的决心，宣布所有业务条线全部支持一键“养虾”，单日股价随即暴涨7.27%。

如果说，之前的“龙虾”热腾讯还能参考别人的成功路径，这次用微信以身入局的腾讯，需要开始学着自己思考：微信内嵌智能体会是什么形态？Agent该如何同微信生态、商业模型结合？

可以想象，一旦腾讯量身定制的智能体方案上线，且能够充分发挥微信自身优势，这将是腾讯在智能体领域最狠的大招，没有微信的友商根本学不来。因此，腾讯接近推出微信AI助手的消息一经流出，随即引发港股投资者狂欢，股价立刻暴涨。

这种狂欢的氛围甚至会逐步传染，想象空间不断蔓延开来，一旦腾讯拿出了自己的智能体，阿里可能也会跟进……此前股价阴跌不止的中国科技股，随即展现出一副绝地反击的态势。卷不动的外卖大战，以及腾讯测试微信的AI智能体原型的消息，共同造成了今天港股科技股的大涨。

目前，微信已经嵌入具备搜索功能的AI智能助手“元宝”，但并非完整的智能体。更让外界好奇，微信即将内置的AI智能体助手，会带来什么样的新体验？

根据《金融时报》报道：据曾观看早期演示的知情人士介绍，用户可通过在微信主界面向右滑动，进入AI智能体的对话框。用户可以通过对话输入指令，智能体可以自动调用小程序执行该指令，比如查找咖啡馆并根据口味下单等任务。

GameLook认为，微信AI助手的最大价值，除了整合信息流、视频流、工作流之外，就是挖掘微信数百万小程序的互通。小程序本就是腾讯主导的一个可怕生态，智能体让整个小程序生态互通后，有望将微信的商业化潜力发扬到新高度。

作为超级APP的微信，是马斯克一直以来的“意难平”。不只是小程序，当智能体进一步将微信的整个信息流、视频号、电商、资金流……全部串联起来，AI时代一个最庞大的生态图景就此展开。

当然微信AI助手是否能有想象中的威力，需要一步步实现。用户第一时间使用的，永远都是个beta版。最终版本还需要随着用户使用不断调整、优化。一旦整个格局打开，下一个紧张的就该是阿里、字节了。

用户的时间和注意力都是有限的，全面布局的微信，必然会影响到阿里、字节旗下AI产品的用户时长和活跃度。一涨一跌，腾讯有望靠Agent再赢下属于自己的一城。

韩国人先给微信智能体打了个样？

微信内嵌AI智能体，让中国投资者表现得“一惊一乍”。但隔壁韩国，为了干好AI、出售游戏业务的Kakao已经花了一年多时间聚焦AI agent，目标是让所有5000万KakaoTalk用户都拥有个人AI智能体。

目前，Kakao AI Agent可以在单一聊天窗口内完成跨平台任务，具备美妆、时尚、零售、税务、旅行、就业、餐饮、高尔夫预订等能力；自动识别对话中的日程、约会和计划并发送提醒；基于对话上下文推荐商品并引导完成支付。

很多人没意识到，腾讯本就是Kakao股东，Kakao AI Agent相当于微信AI助手的“测试版”。腾讯内部AI智能体开发团队自然会了解海外产品的部署、具体表现形式、各功能使用率等情况。

当然，Kakao Talk并不等同于微信，Kakao自身虽然一直在研发Kanana大模型、还其性能显然并不属行业顶级之列，也没有强大的小程序生态，甚至很多功能都是照搬微信，但小程序生态与腾讯存在巨大落差。双方用户体量也有巨大差异，前者只有5000万用户，微信月活高达14亿。

Kakao相当于给腾讯内部团队打了样，测试用户对于AI智能体的接纳度。至少说明腾讯不是完全从0到1的冒险，外部投资公司的尝试一定会被腾讯消化吸收，再结合微信自身的特点转化。

目前大家最担心的是，微信内置智能体上线后，AI算力供应能否支持所有微信用户的正常体验。高频使用AI和Token消耗带来的巨额账单，已经让越来越多海内外大厂都直呼压力山大。

Uber的CTO Praveen Neppalli Naga透露，约5000名工程师四个月内就烧完了公司2026年的AI预算；海外一家科技巨头，短短一个月内烧掉了5亿美元的Claude账单；2026阿里云峰会上，《崩坏》系列AI NPC & Gameplay技术团队负责人郑银河透露，内部员工建了几十个Agent共同协作，一晚上烧了价值200万元人民币的Token。

14亿MAU的微信用户同时段使用，是否会让腾讯AI算力供应直接爆炸，或是导致出现排队等待、分时使用等影响体验的情况，是所有用户目前最担心的地方。

在GameLook看来，Kakao至少做对了一件事，值得其他厂商学习。其Kanana in KakaoTalk以及设备端的Kakao Nano模型，使用个人智能助理使用设备端处理，即所有聊天分析在本地完成，不发送数据到服务器。微信有一定条件向这种方案靠拢。对算力的吞吐量、资金压力都有一定程度的缓解，值得借鉴。

做微信AI智能体，腾讯“不急”

海外公司可参考之外，微信加速推进内嵌AI智能体计划的最大底气，是前OpenAI研究员姚顺雨的加入。

如果说，张小龙掌舵微信这艘大船，将整个超级APP生态做得相当扎实，真正兑现了Metaverse这件事。姚顺雨的加入则为微信带来了一个最强大的能力，用智能体将微信生态和能力全部串联起来，让用户真正步入智能化的AI时代。

去年的一档播客节目里，在被问及“如果是微信的一号位，你怎么在微信里做Agent”的问题时，姚顺雨的回答是：“不急”。

姚顺雨表示：“为什么要急着进攻？比较危险的是一个颠覆性的创新。真正的危险，不是说一个类似于微信的东西打败了微信，而是一个很不一样的东西打败了微信。需要对颠覆性创新有所警惕，但如果是这些incremental（渐进式的）创新，这种小的创新，早做晚做可能区别没有那么大，也不用太担心。”

这一想法似乎也代表了腾讯管理层的态度。早在2025年第三季度财报电话会上，腾讯总裁刘炽平就首次系统披露微信AI化战略蓝图，明确表示“微信最终会推出一个AI智能体”。但直到2026年才传出完成原型测试、即将启动合规审批流程的消息。

中国科技巨头的AI大战里，腾讯从不是最激进的那个，也不打没准备的仗。即使是在Agent最火热的那段日子里，腾讯依旧选择等大家都烧钱试错弄明白了，才加速推进微信的AI智能体计划，稳扎稳打地兑现预期。

微信推出AI智能体，决定了未来腾讯公司价值能否再攀高峰。即从一家市值几千亿美元的公司，在未来真正步入步入万亿美元市值的公司，成败在此一举。

就像GameLook曾经说的那样，如今腾讯的一切问题，都是AI的问题。微信把AI智能体这条路走通，将是所有投资者最希望看到的一幕。

【GameLook专稿，禁止转载！】

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

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

以下是GameLook整理的演讲内容：

大家好，我是来自搜狐畅游的黎志刚，今天很高兴来向大家分享过去一年我们公司在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的框架，可以对老代码进行知识图谱化，快速提取出老代码里面的参数接口。你们可以尝试，我们内部尝试效果很好。

研发场景的话，管线场景是我们正在搭和跑的场景，和腾讯同学说的有很大部分相似，我就不重复了。

这个就不说了，大家都在用，只要用WorkBuddy就会发现很好用。我们以前抓竞品数据还要写一些程序，现在WorkBuddy自带，每天都能看到最新的资讯，看到智能体发布的框架。

我们内部做降本增效是比较狠的，但不是为了省钱，而是要把钱花在该花的地方。我们以前能做的事情是这样的：通过在线人数、服务器的带宽、性能各方面，研究项目费用要怎么降，这是一种方式。

但我们最后发现，回归本质就是资源的弹性伸缩。这要怎么实现呢？云上的弹性伸缩是很好做的，但业务是不会让你做的。

我们可以去做长线的监测和数据分析，比如服务器跑一年过程中最高峰的消耗怎么样？程序在空跑的情况下，CPU和内存消耗是多少、中间差值是多少？在什么区域可以做性能降低……我们内部做了一个降本分析的智能体，当然这还只有部分场景在跑。

以前所有的数据分析都要人工来看，但现在智能体可以帮我们。直接把日志给它，或者可以把各种内容丢给它，智能体有大量商用或定制的Skill。比如发行项目买量的前一周，每天都需要相应的技术日报，以前都是人工整理。但现在写了一个Skill，所有数据能从相应平台拉出来，自动生成报告、自动发。

素材场景这里不详细说。素材制作和美术相关，我们内部用腾讯蒙皮的工具比较多。

过去半年，我们做了一套非常好的客服处理系统，替代了原来的人工录入、人工识取、人工解决客服的问题。当然我们也参照国外的AIHelp平台做了相应的改造。现在我们构建了大量的游戏知识库，所有的客服工单都可以自动识别、自动拾取，在游戏内快速回复给用户。

安全很重要，不能把所有东西都丢给大模型。当我们有一些机密数据或者项目的标准数据进来后，要提交给大模型，尤其那些还不是私有化部署的大模型，这时候怎么办呢？我们会做一些脱敏处理，比如把游戏名、相关东西替换成其他标签，处理完拿回来后智能体会自动替换完。

另外，腾讯云会给一些企业固定的沙盒和容器，保障我们的企业数据不外流。

讲讲第三点吧，可以相信AI，但不能过度信任。因为现在AI会“抽风”，有的时候会骗你。

举个例子，如果对某个游戏游戏业务很熟悉，他一看到AI生成的plan计划会发现，前面看着好，后面可能也好，中间没毛病，但某一块肉有问题。怎么办？一方面是要优化现在生成的Skill，另一方面要构建现在业务知识图谱。

业务知识图谱的丰富度和规则引擎足够完善的话，准确度是比较高的。我们内部项目实现的时候发现，有些相对简单、固定的项目是不会出错，但复杂度较高，以及要影响度很高的项目，当前阶段需要考虑人工审核，未来随着大模型能力提升，或者能够提供一些Skill和智能体后，可能就不需要考虑这件事情了。

这是内部效果的提升，就不重复说了。

未来展望刚刚也讲过了，不要被动地让AI驱动去做，可以更主动把我们的场景进行智能体化。

行，今天就讲这么多。

【GameLook专稿，禁止转载！】

GameLook报道/AI工具在过去两年里井喷式增长，但游戏研发的工业化管线并未同步升级，AI生成游戏资产的实践仍然受限于“单点生成”：概念图生成得很漂亮，3D模型也能出，但中间的生产链路仍然断裂，游戏开发者需要在多个平台之间手动拼接。

6月5日，2026腾讯云AI产业应用大会游戏专场上，腾讯光子LAP游戏资产智能体（下文简称Light AI）技术负责人与产品负责人以《跨越“单点生成”的玩具时代：AI驱动的游戏资产工业化管线重构》为题，首次对外披露了Light AI这一光子工作室群内部打磨4年的一站式AI游戏资产生成平台，回应了游戏行业资产生产受流程阻碍这一痛点。

以下为GameLook整理的演讲实录：

大家下午好，我是来自腾讯光子工作室的薛小黎。我在光子工作室主要跟我的小伙伴凡开俊老师一起负责我们内部的一款AIGC应用平台的产品建设工作。说回到AIGC的话，相信这些年大家也很有感悟。就是我们一夜之间就可以通过一句话，一段Prompt，就可以成为自己想法的主美。但实际我们在这场AI的狂欢里，跟游戏项目去做真实落地的时候，也发现了一个真实的痛点。那就是当前的AI它更多还是以单点玩具的形态存在。那么我们要如何用AI驱动游戏资产的工业化管线重构呢？这个也是我们内部一直在不断探索的一个问题。当然现在我们其实已经沉淀了一份解决方案了，在不久的将来我们也会把它作为一款产品推向大众市场。所以今天在这里就做一下小小的预热，并且希望能跟大家一起探讨我们在未来各行各业里面AI具体的呈现方式。

说回到游戏项目组。其实目前我们在使用AI的过程中有两个非常大的瓶颈。首先第一个就是单点的玩具化，相信大家也很有感触，就是我们现在的AI本质它还是一种抽卡，虽然我们已经有很明确的需求，比如说我们需要特定的角色、特定的材质、特定的角度以及特定的游戏场景。AI可以快速给我们生成大概几百张或者上千张的图片，但它更多还只是定位在精美的，漂亮的图片。我们如何让这个图进入到下游的生产？这种结果的不可控就会导致它不是真正的数字资产。

第二个瓶颈就是我们协作的作坊化。因为像我们好不容易生成了一张满意的2D图，接下来他要进入3D的环节。整个3D的环节又涉及到不同的职能，以及需要在不同的工具里面去进行资产的流转。这里就会涉及到一些沟通方面，或者因为格式不统一而产生的摩擦问题。所以这也是阻碍我们当下去进行一个规模化生产的一个非常大的一个问题。好，就像我屏幕下方写的，所以目前整个AI应用的单点生成以及整个我们流程的这种作坊化，它就是两座大山。对于我们现代游戏项目来说，资产量往往是一个成千上万的一个级别。如果不能去承载这种规模化的生产，我们就很难说AI在里面究竟做了多少提效。

我们实际在跟游戏制作人聊的时候，还发现了一个隐藏的痛点。那就是“TA技术美术离职了，我们的AI生产线也就停了。”这不是危言耸听，这其实是一个非常真实的行业故事。因为我们在实际团队里可能也会有这种感触，就是不同使用AI能力的同学在面对同一个需求以及同一段prompt的时候，它生成的结果质量可能是有非常大的区别的。所以这就导致我们的整整个经验是存在于人的脑子里，他很多都是靠手感，这就会像一种黑盒化的炼金术。所以当这种核心AI人员的离失，可能就会让我们整条管线的AI能力归零。新人可能在面对留下来的这些prompt，没有办法快速的进入到我们曾经的那种AI生产质量里来。所以这也是我们非常大的一个痛点。

这样的生产力它建设在我们这种人的经验里的话，它其实就像是在薄冰上走路。其实它的可控性以及风险是非常大的。那回到我们这种单点式的玩具使用，以及这种协作的一个作坊化，包括我们这种管理的一个黑盒的经验化。在这三个大的问题下面我们要怎么去解决？这里的话我们通过内部的一些探索，也得出了一个非常笃定的结论。那就是游戏工业它不需要孤立的玩具，我们需要的是一条能跑通的标准化的流水线。我们要做的不是单点的能力的生成，而是去进行一个统一的游戏生产的底座的搭建。这个也是我们像这个材料上的这个图标一样。如果说我们还是以单点AI能力去使用的话，它可能就是让这个扳手他只能在我们既定的这个流程里面去做局部的修修补补。

但一旦我们能让这样的能力形成一张齿轮的话，他就可以无缝的嵌入到我们的生产环节里来，能够进行整个大的流程环节上面的完整提效。所以借着这样的一个核心逻辑，我们的突破思路其实也就顺理成章了。我们要做的就绝对不是一个生图工具，因为市面上已经有非常多高质量的大模型。我们要做的也不是去做大模型接入的平台，我们要做的就是借助腾讯光子工作室的游戏制作经验，搭配我们的这些优秀的大模型能力，去打造一个超级工厂式的流水线pass平台。所以我们各个工具，各个环节不会是用AI工具拼凑起来的这种单点式的孤岛。而未来要构建这样的超级工厂，让AI真正融入到我们的研发环境里来，实现生产力真正的解放。

所以作为产品负责人，我在定义这条管线的时候有三个非常核心的指标。首先就是格式统一，game ready以及我们的经验沉淀。大家可以看一下这样的一条流水线，我们要打通的绝对不是简单的文生图，图生3D我们要做的是真正的像游戏引擎的资产流转。第一步从我们生图开始，我们就会摒弃这种随意的单图的生成。我们要确保我们的生成的结果一定是为下游的环节而去做预设和准备的。他一定是为了我们去进行下一步的3D生成经验，而去对应统一的标准。

那来到第二步，我们的3D生成模型的话，也是会继续的以一种统一的格式底座来做搭建。为了方便我们第三步的像骨骼绑定以及做动画验证等等这样的效果。这样我们就可以确保我们是在同一套底层的数据标准下来去进行资产的流转。一定程度上就可以消灭我们整个环节的这个格式税。当然因为这套流程，如果我们把它固定下来的话，上游的一些修正也会自动化的流转到下游。我们就不存在一些可能反复沟通或者反复验证的问题。

最重要的就是我们的这套资产是可以沉淀下来的。它是可以以这种企业级的定制的方式，然后落地到我们实际的项目里，就不会存在前面人走了，经验也没有了这样的一个情况存在。无论是新人还是老人，都可以直接在这样的一条流水线跑通所有游戏资产的制作需求。当然刚刚讲了非常多的这种概念或者是想法层面的东西，我们具体是怎么去进行落地的呢？接下来就给大家展示一个短片，可以看一下我们在内部是如何完成这条game ready的资产生产管线的。

好Light AI就是我们在光子内部在应用的这个平台的名字。其实就像刚刚视频里看到的，我们呈现了非常多单点的能力。但我们具体这些能力的串联，其实就是在这样的一个无限画布里面，通过这种节点可视的方式来去进行串联的这样的一个画布。它就可以起到团队协作，然后让所有的职能的人员都在同一条画布去进行编辑的能力。

在光子内部的话，其实我们已经探索了有差不多四年的时间，然后整个的生产也已经支持了大概2000万次的生产。刚刚也有看到，其实我们还涉及到非常多像管理端的一些能力。其实像现在我们对于很多企业，目前对于AI的管理，如何能够合理的接入，流转，并且进行风控复盘，这个也是我们现在要去做的一个事情。因为如果我们不去做一个精细化的管理的话，那我们的AI提效也就无从谈起。所以在这样的一张可以无限编辑的画布上去串联所有的能力到底意味着什么？这里也给大家算了三笔账。

首先第一笔是时间账。在我们过去的整个资产制作的时间来看，从前期的概念设定到后期在3D里面跑通经验验证，整个周期其实都是按照周或者月的时间来去推进的那现在通过我们这样的一条固定化流水线，时间就可以被压缩到以天为级别。这个其实对于我们整个资产的验证以及快速试错就会有非常大的帮助。

第二个就是我们算损耗，大家平时用很多的单点工具，可能在不同的平台，以及可能不同的职能需要用不同的一些工具资产等等。这里工具格式不对，来回倒腾，然后沟通成本高，可能还涉及到一些返工。现在我们通过这条整个管线的打通，这种跨端的内耗基本就也可以被消除为零，实现真正的无感流转。

第三笔账也是今天相信很多老板非常关心的一个问题。就是我们如果真的把这样的一套经验沉淀为资产，可以去不断的复用的话。那我们前面所讲的那个人走经验没的痛点，其实也一定程度上就可以被解决了。有了我们自己专属的这样一个经验资产的话，其实也是未来各个游戏项目它非常核心的一个制作的壁垒。好，核心思路有了，然后我们的底层能力也打通了，这样也算明白了。

接下来其实我们还面临这一个新的挑战。底层的工业足够强大。但大家刚刚也看到了，那个无限画布上的整个工作流，其实串联的还是非常复杂的。如果我们有一个预设好了的工作流的话，那大家确实可以快速去接入使用。但如果我有一个新的想法，我要从0到1开始搭建，我要怎么做？这个可能就会有一些难度。为了解决这个问题，我们 也在整个底层的管线上专门加装了一个大脑，也就是我们研发的智能中枢。所以这也就是我们的一种全新的交互范式，通过agent的能力，结合可视化的这种节点无线团队协作画布，把这个功能推向给大家。

我们可以通过自然语言来去识别大家的意图。这里的话必须要懂复杂的节点参数，或者是一些具体的一些节点设置的能力。只需要通过一句自然语言，像帮我生成一个火族风格的角色场景，或者是特效导出Unity预制体，只需要这样的自然语言就可以得到结果。

但是直接得到结果也是不行的。因为其实我们直接得到结果一定程度上它还是一种拆盲盒。所以我们的agent它是在精准识别了我们的意图之后，把它会按照具体的步骤去拆分成一个一个的节点在画布上。这样的话就意味着节点里的每一个过程对我们来说都是透明的，每一个参数都可以去做二次编辑，整个流程是可以去进行不断的复用以及更新换代、迭代流转。所以在智能画布上，我们就可以既享受一键下达指令的这种极简的操作，又可以把控对我们整个工业管线上每一个节点以及节点质量的绝对控制权。这样的话就可以高效实现大家对于新出现的这个想法的一个具体的落地了。

agent它本身很强大，大家日常也会有用到小龙虾之类这样的一些能力。其实也会发现我们有一个非常聪明的大脑。但是如果他不懂业务的话，那他可能就像一个非常优秀的学生能听懂，但可能具体实施起来没有那么专业。所以在这样的一个背景下，在我们产品正式上线的时候，我们也会搭载这个专属的skill市场，也就是我们为它配备的一个顶级的专业工具箱。大家可以看到就是我们我这里列的不是我们全部的skill能力，但它不是通用的功能插件。它更多是基于我们光子工作室在实际的游戏制作过程中积累下来的经验。

SOP像比如说在前期我们有IP孵化，然后和竟品分析skill。这样就可以帮助我们的主策去快速的建立世界观，去完成整个故事内容的搭建。中期分镜视频资产量产可以让像美术同学、音频同学等等快速的去重复，把所有这些可复用的美术资产的能力去进行进一步的释放，告别重复的劳动。后期的话我们还有像资产评审这样的skill，用这种3A级的评审能力对我们的所有内容输出去进行复盘。所以它其实是覆盖我们真实的一个游戏的生命周期的一个skill能力包。所以在这样的一个基础上，我们的agent就结合了我们的光子工作室实际的游戏经验，化身为懂风格懂管线的高级技术美术以及资深策划。所以这样的话大家就可以进一步把我们的游戏生产结合AI的能力去进行传播了。

好，有了这一套agent智能中枢和光子的经验底座，其实我们一路在内部探索到今天也一直在思考一个问题，就是AI时代我们对于我们来说，到底什么才是真正的技术普惠？现在我们也可以回答这个问题了，就是我们坚信真正的技术普惠其实是去打破创作的特权。过去像光子工作室这样的一些生产管线经验，其实是内部的护城河。大家可能也有感触，就是有一些技术的能力我们想要去握在手里。但是今天我们面对整个游戏行业的生产力变革，也做出了这样的一个决定。就是要打破这面墙，把属于我们的护城河变成灌溉我们全行业的生态活水。所以从重工业走向大众化，我们的终极使命就是把这条冰冷的流水线变成人人手里都可以握着的画笔。

无论你是一个独立的游戏开发者，还是十几个人几十个人的中小型团队，都能拥有这样的一个专业级别的能力。好，那几个月之后我们的这款产品就会向大家面世了。就是结合了整套agent以及我们整个光子底层的工业级能力的平台。它将会以一种很清亮很有趣的方式面向大家。我们要让每一个普通人游戏梦都能在这条智能化管线上跨越技术的鸿沟，变成触手可及的现实。所以接下来我们比拼的不会是谁能堆更多的人力，一定是谁掌握了更先进的生产力管线。所以在这里也非常期待和大家一起去重构我们游戏工业的未来。

非常欢迎感兴趣的老师持续关注我们，可以扫我们屏幕上的二维码加入我们的内测群。相信大家桌上也都有那个小册子，那个也是我们Light AI的宣传册，上面有我们的二维码以及邮件。非常欢迎各位老师能够跟我们去交流大家的想法以及需求。我们内测群见谢谢大家。

Light AI Early Access内测已开放申请，诚邀您一起重构游戏工业的未来，申请邮箱：[email protected]。