Unity 终于把终端和 Editor 接上了

做 Unity 的时候，agent 最尴尬的不是写不出脚本。

是写完以后，它看不到 Editor 里发生了什么。

改一行 Collider，要等编译，等 domain reload，再进 Play Mode。Console 里飘红，你把日志复制回去，它再猜一轮。这个回路又慢又脆，而且每多一步，人就又变回了中间人。

七月中旬，Unity 推了 Unity CLI。不是又一个 Hub 的隐藏参数，是一个独立的 unity 命令。文档里还标着 experimental。但对着现在这套「AI 写代码、人盯 Editor」的分工，它至少对准了真正卡住的那一层。

所以我想记一下：它到底是什么，以及对我这种在 Mac 上用 Unity 做小项目的人，哪些地方有用，哪些地方先别急着信。

它其实是三层，不是一个口号

很多人看到「CLI」会以为只是把 Hub 搬到终端。官方自己拆得比较清楚：

Unity CLI 是一个独立二进制，用来在终端里装 Editor、加模块、开项目、做认证；com.unity.pipeline 让它能驱动正在运行的 Editor（或开发版 Player）；unity command eval 则能在已经起来的实例里直接跑一段 C#，不必为了试一句表达式再走一整轮项目重编译。

第一层解决的是机器和环境：CI 不想装完整 Hub，脚本要 JSON / TSV，退出码要稳定。以前 Hub 的 -- --headless 又慢又拗口，现在变成：

curl -fsSL https://public-cdn.cloud.unity3d.com/hub/prod/cli/install.sh | UNITY_CLI_CHANNEL=beta bash
unity --help
unity install 6000.2.10f1 -m android ios webgl

第二层才是Editor。项目里装上 Pipeline 包之后：

unity pipeline install
unity command
unity command <command-name>

任何静态方法加上 [CliCommand]，就可以变成终端可调的命令。项目自己的「导入、跑测试、进 Play、切场景」不必再绑死在菜单点击上。

第三层是 eval。官方演示里，agent 拿到一句「玩家有时会掉出地板」，用 unity command eval 去查现场，发现 collider 在运行时被关了，打开它，再进 Play 验证。关键不在于 demo 炫不炫，而在于回路终于闭环了：观察、动手、确认，都发生在同一个还活着的 Editor 里。

这才是 agent 缺的那截

我写过不少 Claude Code、Codex 相关的东西。它们在仓库里已经很强了：改文件、跑测试、看 diff。

Unity 项目却多了一层「引擎状态」。场景树、Play Mode、Importer、AssetDatabase，这些不在 git 里，也不在普通终端输出里。以前社区靠各种 MCP、截图、复制 Console。能用，但不稳，也难复现。

Unity 这次的态度其实挺直白：能跑 shell 时，优先用 unity command / eval；CLI 里也带了 unity mcp，给那些不方便直接跑终端的 agent 用。旧的 in-Editor assistant MCP 在往这条路上迁。两边都免费，也不再拿订阅卡你。

对我来说，更重要的不是品牌站队，而是接口形状对了。

结构化输出、固定退出码、命令可发现（unity command 不带参数就列出当前 Editor 暴露了什么）——这些才是 agent 能可靠调用的东西。宣传文案里的「AI 助手」可以换，这层执行面最好别再换一次。

官方也写得很清楚：Unity 自家的 in-Editor AI 只是这层执行面的一个消费者，不是替代品。Claude、Codex、本地模型，理论上都能走同一条路。这点对个人开发者很重要。我不想为了用 agent，先把自己绑进某一家的编辑器插件生态。

我对它真正在意的几件事

1. 它解决的是「看见和验证」，不是「替你做游戏」。

agent 还是会胡写 API、乱改 prefab。CLI 只是让它少靠你当肉眼中继。期待它自动做出完整玩法，现在还早。

2. eval 很快，也更危险。

它用 Roslyn，在 Editor 主线程跑，能摸到你项目摸得到的几乎所有 API。官方用 security token 卡住，文档里的说法也直白：把它当成远程执行代码来对待。本机 localhost、开发构建、明确授权——这些边界必须守住。开发版 Player 也能挂 runtime 组件，但默认关，而且不该进生产包。

3. Pipeline 要 Unity 6.0+，CLI 本身仍是 experimental。

文档首页就写着 experimental。Hub 现在会顺手装 CLI，也可以单独装、单独 unity upgrade。Mac 上现在也能 brew install --cask unity-cli。也就是说：可以开始用在个人脚本和原型里，但别把整条发版流水线一夜之间押死在上面。

4. 和旧 Hub headless 脚本要迁移。

如果你仓库里还躺着 "Unity Hub" -- --headless ...，得对照官方 migration 改命令。这不是小改名，是换了一套更像正经 CLI 的语义。

对独游开发者味着什么

一个人做 Unity 的时候，日常最大的摩擦往往不是「装不装得上 Editor」，而是改完逻辑要不要再手动点一遍 Play、再把报错贴回聊天窗口。

如果 CLI + Pipeline 稳定下来，我更想先用在这些地方：

• 打开指定工程，确认 Editor 版本对不对

• 跑一批自己暴露的 [CliCommand]：进 Play、跑一小段自动化检查、把结果打成 JSON

• 让 agent 用 eval 问现场问题，而不是问我「Console 里有什么」

CI 装 Editor、加模块，对公司流水线价值更大。对一个人的小项目，真正值钱的是第二条和第三条：把「人在 Editor 里点来点去」变成可脚本化、可复查的步骤。

它不会替你做出一款游戏。它只会让我少花时间当 agent 的眼睛和手。

最后

Unity CLI 不是又一次「全面拥抱 AI」的口号发布。它更像补了一块早就该有的地基：终端能管环境，脚本能驱动 Editor，agent 终于有一条不那么歪的路去验证自己改没改对。

现在它还写着 experimental。我会装，会试，会把能稳定复现的命令收进自己的小脚本。不会一上来就把构建、发包、自动化测试全押上去。

工具好不好，看它能不能把反馈环收紧。这一次，Unity 至少对准了那个环。

https://unity.com/blog/meet-the-unity-cli

https://docs.unity.com/en-us/unity-cli/unity-cli