Unity 向 Google Antigravity 的智能体开放引擎

Google 推出了 Antigravity 的插件市场——一个面向 Antigravity 应用及其控制台版本的第三方与自有扩展的集中式目录。首批合作伙伴中出现了官方 Unity 插件：它一键将引擎接入智能体，之后构建、模拟以及 realtime-3D 管线的管理都可以不离开 Antigravity 完成。

此前，把智能体与外部系统打通意味着手动配置：MCP 端点、环境变量、领域技能和自定义子智能体要写在单独的仓库或本地配置里。插件把多达五种可扩展性原语打包进一个带 plugin.json

清单的版本化捆绑包：技能（SKILL.md）、MCP 服务器（mcp.json）、规则、生命周期钩子（hooks.json）和自定义智能体——它们作为一个整体被安装、更新和启用。开发者要做的只是在 Customizations → Plugins 面板中找到 Unity，或者执行 agy plugin install。

智能体获得了什么

Unity 插件为 0.1.8-beta 版本，采用 Unity Companion License，适用于 Unity 6 及更高版本；它发布在 Unity Technologies 的仓库中，agy plugin list

命令可用于检查安装情况。许多技能通过 Unity 的命令行工具 Unity CLI 来操作已打开的编辑器：智能体会自行检查该工具是否已安装，必要时自行安装，并添加一个小型 Unity 包，CLI 通过它与运行中的编辑器通信。Unity Hub 的用户通常已经有这个工具——Hub 会自动安装它。

随后，智能体可以创建 GameObject、更改资源导入设置、直接在运行中的编辑器里执行 C# 代码并检查结果——而不必手动修改场景和资源文件。CLI 本身还能安装编辑器、创建和打开项目、启动构建与测试。

技能会根据任务自动调取，但也可以从斜杠菜单手动调用。其中包括内购、激励视频、设置界面、像素风渲染、六边形瓦片调色板、排查 TextMeshPro 中汉字显示问题，以及审查 ScriptableRendererFeature 中的 Render Graph 错误。

也存在 Unity 直言提醒的风险：技能会直接改动脚本、场景和资源，而并非每一处改动都会被编辑器记录或可通过编辑器回滚。建议很简单——把项目纳入版本控制系统，并在大改之前提交。

Antigravity 并非唯一环境

同一个 Unity 插件也可用于 Claude Code、Codex 和 Grok——在每个环境中都以各自的命令安装，而在 Claude Code、Grok 和 Antigravity 中，技能还会额外出现在斜杠菜单里。Unity 希望用户把缺陷和建议发到自家论坛 Unity Discussions。

为什么会发生这件事

Unity 的这些举动汇聚成一个押注：为编辑器提供一个中立的接口——对外输出控制台层，并为每个流行的智能体环境发布一层薄封装。支持的此类环境越多，工作室越没有理由根据自己使用哪个助手来挑选引擎。Unity 出现在 Google 的目录中，看起来是这条路线的延续，而不是一桩单独的交易。

从 Google 一侧看，逻辑是对称的：一个陈列着现成合作伙伴插件的橱窗，消除了智能体环境的主要障碍之一——必须为团队的每件工具手工拼装集成。游戏开发对这样的目录来说是个合适的场景：这里的管线很长、可复现，且不适合手工的重复劳动。

如果这一趋势延续，对游戏团队而言，开发环境与智能体编排器之间的界线将逐渐模糊，而某个具体引擎的价值将越来越取决于它把自身的操作——构建、测试、资源导入、运行场景——对外暴露得有多细致。对建模师和程序员来说，这意味着一部分工作将从编辑器里的手动操作，转向提出任务并检查智能体提交到仓库的改动。

你准备好把构建交给 Antigravity 里的智能体，还是继续用自己的脚本？说说这个插件还缺什么才能让你信任它。