从开发工具到Agent底座，Unity中国重构游戏生产链。

作者｜王博

AI大模型公司越来越喜欢用游戏展示模型能力。

近期发布的Kimi K3，直接将“生成可玩的多人游戏和3D游戏”作为核心能力之一，展示模型如何把概念、图片甚至视频转化为可交互体验；Anthropic发布Claude Fable 5时，也重点展示了模型长时间自主编程、根据一份提示词生成完整可玩游戏的能力。

从生成一个可交互的网页小游戏，到根据自然语言修改角色、场景和规则，游戏几乎成了检验AI编程能力的标准项目。理由并不复杂：它同时包含代码、图像、动画、交互和逻辑，足以把模型的多模态能力直观地呈现出来。

但在游戏行业看来，“生成一个游戏Demo”与“开发一款真正可以上线、运营和持续迭代的游戏”，中间仍然隔着漫长的工程链路。

7月28日，游戏引擎公司Unity中国在上海发布团结引擎2.0，并推出游戏开发AI Agent团结Codely。相比为编辑器增加一个AI对话框，这次更新更值得关注的地方是Unity中国开始从底层改造引擎，让AI能够理解游戏工程、操作编辑器、运行测试并修复问题。

在Unity中国CEO张俊波看来，AI不会让游戏引擎失去价值，反而可能让引擎在游戏生产中介入得更深。

这也构成了团结引擎2.0的核心命题：当AI能够写代码，游戏引擎还需要提供什么？

1. 游戏引擎正在为AI重新设计

传统游戏引擎首先是为人服务的。

开发者通过编辑器搭建场景，用脚本控制角色和交互，再由引擎处理渲染、物理、动画以及不同终端的适配。在这个过程中，项目文件、API、文档和编辑器界面，也都按照人类开发者的使用习惯设计。

AI进入之后，这套体系暴露出一个问题：大模型可以读代码，却很难理解一款游戏的完整状态。

以Unity工程为例，其核心内容通常分散在C#脚本、场景文件、资源文件和YAML配置中。YAML文件更多是在记录某一时刻的状态，无法完整呈现开发者在编辑器中的操作逻辑。模型即使能够修改其中一部分文件，也未必知道这些变化会给整个项目带来什么影响。

因此，团结引擎2.0做了一项更基础的改造：重新设计资产和工程的表达方式，为AI提供更容易理解和调用的数据结构。

团结引擎2.0打通了自然语言、可视化节点和代码三种创作方式，并加入修改对比、版本追溯和权限控制等机制。AI生成的内容可以被检查、审核和回滚，从个人使用的辅助工具，逐渐进入企业的正式开发流程。

建立在这套底层架构上，团结Codely可以完成需求理解、代码编写、场景搭建、测试运行、错误分析和问题修复。Unity中国将这种工作方式称为“Loop Engineering”：AI的任务不止于输出一段代码，还要持续运行、验证和修正，最终交付可检查的结果。

这一区别很关键。

当前很多AI Coding工具已经能够读取代码库、修改文件和执行命令，但游戏开发是一个高度多模态、强状态依赖的过程。移动一盏灯、替换一个角色或者调整一次碰撞参数，可能涉及场景、脚本、资源和渲染管线的联动。AI需要理解“游戏现在是什么样”，也要理解“这次修改具体改变了什么”。

但是当通用Agent已经能够读取代码库、运行命令并生成游戏场景，团结Codely作为垂类Agent核心优势是什么？

张俊波告诉「甲子光年」，差异主要来自两个方面：一是行业Know-how，二是数据的准确性和简洁性。

在他看来，通用大模型吸收了跨越不同版本的大量公开数据，其中包含重复、过时甚至相互冲突的内容。垂直模型能够把知识范围限制在Unity和团结引擎的具体场景中，提高Agent行为的可控性，同时减少上下文和Token消耗。

“我们的目标是，能不能拿一个300B的模型，针对游戏场景，达到人家2.8T模型的水平。”张俊波告诉「甲子光年」，垂类模型、自有Know-how以及Agent与工具之间更紧密的耦合，将成为团结Codely的主要差异。

这次发布会上，Unity中国还宣布与清华大学合作打造游戏行业专属的私有化垂类大模型，联合训练适配Unity及团结引擎的Coding大模型，提升引擎API理解与复杂工程任务执行能力，同时支持模型私有化部署，回应大型企业的数据安全关切。

与单纯接入更强的大模型相比，引擎公司掌握了更准确的API、项目结构、版本变化和真实工作流，更有机会把模型能力转化为稳定的工程结果。

1. AI降低门槛，也会放大工程复杂度

AI进入游戏行业，最直接的变化是开发门槛下降。

过去，一支游戏团队通常需要同时具备策划、程序和美术能力。独立开发者即使拥有创意，也可能因为不会编程、缺乏美术资源而停留在想法阶段。随着代码、图像、动画和3D资产生成能力不断成熟，一个人或者几个人完成游戏原型，已经变得越来越现实。

现实的场景也会带来现实的问题：当越来越多没有编程和游戏开发经验的人开始尝试制作游戏，游戏引擎公司的核心价值会发生哪些变化？

张俊波告诉「甲子光年」，未来游戏团队的人员结构可能发生倒转。

过去，一个制作人背后可能需要十名工程师和美术人员；随着AI能力提高，团队中负责创意和制作的人会增加，重复性的执行工作则更多交给Agent。“如果一个Agent不够，就雇十个Agent，只要有足够的Token，都能做出来。”张俊波说。

不过，张俊波随后也谈到了AI开发的另一面：代码生成得越快，维护成本未必越低。

他对「甲子光年」透露，Unity中国内部已经有大量代码由AI生成，一些工程师甚至主要通过命令行和自然语言工作。但当代码出现Corner Case，团队可能很难判断这段代码的设计逻辑，更难迅速定位责任人。对一个需要服务数百万开发者的商业引擎来说，这类问题会被进一步放大。

“AI修复Bug比Coding还贵。”张俊波说。

这句话揭示了AI编程现阶段容易被忽略的成本。生成代码只占软件生命周期的一部分，后续还有测试、调试、审查、迭代和维护。游戏项目尤其如此：一款长期运营的游戏可能拥有数百万甚至数千万玩家，任何底层问题都可能演化成大规模事故。

因此，团结Codely强调运行、验证和可追溯性，本质上是在尝试解决AI Coding从“能写”走向“能用”的问题。

对于个人开发者，一个不可维护的小游戏或许可以被迅速放弃；对于游戏公司，AI生成的内容必须进入版本管理、权限控制和测试流程。谁能把AI约束在成熟的软件工程体系中，谁才有机会真正进入企业核心生产环节。

1. 引擎竞争从技术参数走向经营效率

团结引擎2.0仍然是一款游戏引擎，因此，AI之外的更新同样占据很大比重。

在图形能力上，新版本升级了虚拟几何体、实时动态全局光照、阴影、动画、粒子系统和并行渲染能力。跨平台方面，团结引擎新增对PlayStation®5、Xbox Series X|S、Nintendo Switch™ 2和Nintendo Switch的支持。

至此，团结引擎覆盖PC、移动端、主机、微信及抖音小游戏、开源鸿蒙和智能汽车座舱等终端。Unity中国希望用一套代码和资产，覆盖中国本土生态与全球主流平台。

这背后对应着游戏行业一个现实变化：项目越来越贵，失败也越来越难以承受。

高品质游戏的研发周期不断拉长，单个平台提供的收入空间却未必能够覆盖持续上涨的开发成本。跨平台发行可以扩大潜在用户规模，AI则可以让团队更快完成原型、测试玩法和验证市场。

引擎的价值因此开始从“帮助开发者实现功能”，延伸到“帮助公司管理项目风险”。

一方面，跨平台能力让同一份研发投入覆盖更多市场；另一方面，AI把测试和验证环节提前，让团队在投入大量资源之前，尽早发现玩法、性能和工程问题。

张俊波将这种变化概括为“经营效率”：游戏公司的竞争将逐渐从团队规模，转向研发效率、验证速度和决策质量。

1. AI不会消灭游戏引擎，可能让引擎变得更重要

AI软件浪潮中，一个反复出现的判断是，Agent将绕过传统软件界面，直接完成用户任务。

游戏引擎看起来也面临相似挑战：既然模型可以生成代码、资产甚至游戏画面，开发者是否还需要一个复杂的引擎？

张俊波并不认同这一终局。

原因在于，商业引擎的价值从来不止代码本身。它将渲染、物理、动画、跨平台适配和测试能力封装成稳定模块，使开发者无需重复制造底层工具。进入AI时代后，这些成熟模块还可以进一步降低Token消耗。

一个Agent可以重新写一套抗锯齿算法，也可以直接调用经过验证的引擎API。前一种方式需要生成、测试和维护大量代码，后一种方式可能只需要一次Function Call。

从这个角度看，AI越强，成熟软件的封装价值反而越突出。Agent负责理解意图，引擎负责提供可靠的执行单元。

当然，团结Codely目前仍处在早期阶段。张俊波透露，产品上线约十周，新用户第二周留存约为30%至40%；大约三分之一的用户每天会在其中使用两小时到十几个小时。能否用好AI，仍然高度依赖开发者经验。

垂类模型能否稳定处理复杂工程、AI生成代码的维护成本如何控制、企业数据如何在模型训练中得到保护，这些问题仍需继续验证。

但团结引擎2.0给出了一条清晰路线：未来的游戏引擎不会只负责运行游戏，也会负责组织Agent、管理上下文、约束模型行为，并检查AI交付的结果。

过去，商业引擎通过封装底层技术，让游戏公司不必先造一个引擎。

接下来，它要进一步封装AI的复杂性，让有创意的人不必先成为一名熟练的程序员，也能把游戏真正做出来。

（封面图及文中配图来源：Unity中国）