Meet the Unity CLI
TL;DR
Available now: the Unity CLI is a standalone unity binary for managing and interacting with editors, modules, projects, and auth from the terminal. No UI needed; install via command line.
现已可用：Unity CLI 是一个独立的 unity 二进制程序，用于从终端管理和操作编辑器、模块、项目与身份认证。无需图形界面，通过命令行安装。
Built for automation: structured JSON/TSV output, clear exit codes, non-interactive installs, and service-account auth for CI.
为自动化而建：结构化的 JSON/TSV 输出、清晰的退出码、非交互式安装，以及面向 CI 的服务账号认证。
Also available today: the experimental com.unity.pipeline package lets the CLI drive a running Editor, or a dev Player build, over a local API. You can expose your own commands with a [CliCommand] attribute.
今天同时推出：实验性的 com.unity.pipeline 包，让 CLI 能通过本地 API 驱动一个正在运行的编辑器、或一个开发版 Player 构建。你可以用 [CliCommand] 特性暴露自己的命令。
unity command eval runs C# code live inside a running Editor or Player and returns the result, with no project-level recompile or domain reload required.
unity command eval 在运行中的编辑器或 Player 里实时执行 C# 代码并返回结果，无需项目级重新编译或域重载。
Together, they allow AI agents to operate Unity: observe a live project, act on it, and verify the result.
三者合力，使 AI 智能体得以操作 Unity：观察一个活着的项目、对它动手、并自行验证结果。
More and more of development happens in the terminal: in scripts, in CI, and increasingly in the hands of AI agents. Today Unity meets you there.
越来越多的开发发生在终端里：在脚本中、在 CI 中，以及越来越多地在 AI 智能体手中。今天，Unity 到这里来见你。
It's one single, fast unity command, and each layer goes further than the last: the CLI manages Unity, the Pipeline package drives it, and eval reaches inside it.
它是一条统一而快速的 unity 命令，而每一层都比上一层走得更深：CLI 管理 Unity，Pipeline 包驱动它，eval 探入它内部。
curl -X POST http://localhost:7800/api/exec 调 pipeline（端口 7800，与本机实测一致）。右：Unity 编辑器 Test Runner 显示 11/11 passed。摘要写着「Compile errors fixed (2)」「Test logic bugs fixed (3)」「Unity recompiled cleanly (domain reload, no error CS)」。点击放大。
unity command eval <code> 检查活着的场景，发现某个碰撞体在运行时被禁用了，重新启用它，再进入 Play 模式确认修复——观察运行中的游戏、对它动手、并自行验证结果，全程没有复制粘贴任何控制台输出。
What is the Unity CLI / 什么是 Unity CLI
The CLI ships as a single self-contained binary. There are no dependencies to install, and installation adds itself to your PATH.
CLI 以单个自包含的二进制文件发布。没有依赖需要安装，安装过程会自动把自己加进 PATH。
Because it's a native binary, it starts quickly, whereas the old Unity Hub headless path (-- --headless) took noticeably longer. This gap adds up across the dozens of calls a script or agent makes per job.
因为是原生二进制，它启动很快；而旧的 Unity Hub 无头路径（-- --headless）明显更慢。这个差距会在一个脚本或智能体每项作业发出的几十次调用中累积起来。
Get started / 上手
# macOS or Linux
curl -fsSL https://public-cdn.cloud.unity3d.com/hub/prod/cli/install.sh | UNITY_CLI_CHANNEL=beta bash
# Windows
$env:UNITY_CLI_CHANNEL='beta'; irm https://public-cdn.cloud.unity3d.com/hub/prod/cli/install.ps1 | iexInstalling an editor with the modules you need is a one-liner: unity install 6000.2.10f1 -m android ios webgl
装一个带所需模块的编辑器只要一行：unity install 6000.2.10f1 -m android ios webgl
From there, commands read the way you'd expect: unity editors to see what's installed, unity open to launch a project with the right editor resolved, and unity auth login to sign in.
往下的命令读起来都如你所料：unity editors 看装了什么，unity open 用正确的编辑器版本打开项目，unity auth login 登录。
Built for automation / 为自动化而建
The CLI was built to live inside automation, not just an interactive shell. Every command can emit structured output you can pipe straight into your tooling.
CLI 是为「活在自动化里」而造的，不只是一个交互式外壳。每条命令都能吐出结构化输出，可直接管道接入你的工具链。
Errors go to stderr, results to stdout, and exit codes follow a simple contract (0 success, 1 error, 130 cancelled), so failures are easy to catch in a pipeline.
错误走 stderr，结果走 stdout，退出码遵循一个简单契约（0 成功、1 错误、130 取消），因此失败在流水线里很容易被捕捉。
On a headless build agent, it authenticates with a service account via environment variables. No browser, no manual step. And unity doctor diagnoses environment, credential, and configuration problems.
在无头构建代理上，它通过环境变量用服务账号认证。无需浏览器，无需手动步骤。而 unity doctor 会诊断环境、凭据和配置问题。
Talking to the Editor / 对话编辑器
Managing installs is only half the story. The Unity CLI can also drive a running Editor.
管理安装只是故事的一半。Unity CLI 还能驱动一个正在运行的编辑器。
Once added to a project, com.unity.pipeline lets a running Editor receive commands from the CLI entirely on your machine. It works with Unity 6.0 LTS and newer, and turns the Editor into a programmable automation target for scripts, CI jobs, and agentic tools.
一旦加进项目，com.unity.pipeline 让运行中的编辑器完全在你本机接收来自 CLI 的命令。它支持 Unity 6.0 LTS 及更新版本，把编辑器变成一个可编程的自动化目标，服务于脚本、CI 作业和智能体工具。
Those commands aren't a fixed set. Any static method in your project becomes one by adding a [CliCommand] attribute, with [CliArg] on its parameters.
这些命令不是固定的一套。你项目里任何静态方法，加个 [CliCommand] 特性就变成一条命令，参数上加 [CliArg]。
The package discovers it automatically, with no registration step.
包会自动发现它，无需注册步骤。
using Unity.Pipeline.Commands;
using UnityEngine;
public static class MyPipelineCommands
{
[CliCommand("greet", "Log a greeting and return its length")]
public static int Greet(
[CliArg("name", "Who to greet", Required = true)] string name)
{
Debug.Log($"Hello, {name}!");
return name.Length;
}
}It doesn't stop at the Editor. Drop its runtime component into a development build and your running game exposes the same kind of API.
它不止于编辑器。把它的运行时组件放进一个开发版构建，你正在跑的游戏就暴露出同样的一套 API。
It's localhost-only and off by default (for dev and QA builds, never production), but it turns a running Player into something a script, test rig, or AI agent can drive in a live runtime instance.
它仅限 localhost 且默认关闭（用于开发和 QA 构建，绝不用于生产），但它把一个运行中的 Player 变成脚本、测试台或 AI 智能体能在实时运行实例里驱动的东西。
命令：
unity command --runtime "…\Build\URPTempalte.exe" set_camera_speed --speed 10输出：
Connecting to Unity Editor at localhost:7900（编辑器是 7800，运行时另开端口）→ Result: Set playback speed to 10x on 1 active director(s): [CinematicTimeline]参数里带着
"token":"fLRHU/Yzp…"——就是上文说的安全令牌。右侧画面里游戏正在跑。Execute C# scripts with eval / 用 eval 执行 C#
Registered commands cover the operations you've anticipated. unity command eval covers the ones you haven't.
注册的命令覆盖你预料到的操作；unity command eval 覆盖你没预料到的。
It evaluates an arbitrary C# expression inside a running Editor and hands you back the result: a live Read-Eval-Print Loop (REPL) into your project, from the terminal.
它在运行中的编辑器里求值任意 C# 表达式并把结果交回给你：一个从终端通往你项目的、活的 REPL（读取-求值-打印循环）。
It's compiled with Roslyn and run on the Editor's main thread, so it reaches any engine or editor API your project can.
它用 Roslyn 编译，在编辑器主线程上运行，因此能触达你项目所能触达的任何引擎或编辑器 API。
Because that power cuts both ways, eval is gated behind a security token. No predefined command, no plugin, no recompile: if you can express a question in C#, you can ask a running Unity instance.
因为这份能力是双刃的，eval 被一道安全令牌卡住。没有预定义命令，没有插件，没有重新编译：只要你能用 C# 表达一个问题，你就能问一个正在运行的 Unity。
The usual change-and-check cycle (edit, recompile, relaunch) costs seconds at best; eval answers in milliseconds against an instance that's already up.
通常的「改一改看一看」循环（编辑、重编译、重启）最好情况也要数秒；eval 对着一个已经起来的实例，以毫秒作答。
Across the many calls a script or an agent makes in a session, that difference adds up, and it's exactly what gives an AI agent a tight feedback loop instead of a slow one.
在一次会话中脚本或智能体发出的众多调用上，这个差异会累积——而这正是让 AI 智能体获得紧密反馈循环、而非缓慢反馈循环的东西。
A foundation for AI-assisted development / AI 辅助开发的基座
AI coding assistants are good at writing code and content. They've historically struggled with everything around that: running the project, seeing what broke, trying again.
AI 编程助手擅长写代码和内容。它们历来吃力的是围绕这件事的一切：运行项目、看清哪里坏了、再试一次。
An assistant can generate a gameplay script but can't run the tests to see if it works. The Unity CLI and Pipeline layer close that gap.
助手能生成一段玩法脚本，却无法运行测试看它是否work。Unity CLI 与 Pipeline 层合上了这道缺口。
First, the CLI speaks a language agents understand: structured JSON and a predictable exit-code contract mean a model gets clean, parseable results instead of scraped console text.
其一，CLI 讲的是智能体听得懂的语言：结构化 JSON 加可预测的退出码契约，意味着模型拿到的是干净、可解析的结果，而不是刮来的控制台文本。
The same qualities that make it reliable in CI make it reliable as a tool an agent calls.
让它在 CI 中可靠的那些品质，也让它作为智能体调用的工具同样可靠。
Second, the Pipeline package makes the Editor self-describing: run unity command with no arguments and a connected Editor reports the operations it exposes. An agent discovers what it can do at runtime instead of relying on a hardcoded list.
其二，Pipeline 包让编辑器自我描述：不带参数跑 unity command，连接的编辑器会报出它暴露了哪些操作。智能体在运行时发现自己能做什么，而不是依赖一份硬编码清单。
Put those together and you get a real feedback loop: an assistant can open the project, apply a change, run the tests, enter Play mode to check behavior, read the result, and decide what to do next, with no human relaying output back and forth.
把这些放在一起，你得到一个真正的反馈循环：助手能打开项目、施加改动、跑测试、进 Play 模式检查行为、读取结果、决定下一步——不需要人在中间来回传递输出。
That's the shift from an assistant that suggests to one that can verify.
这就是从「会建议的助手」到「能验证的助手」的转变。
And there's no fixed list of what an agent can do. Because eval reaches whatever API your project can call, an agent's capability surface is the same as Unity's: rendering, physics, animation, the asset database, the Editor itself, plus everything your own code adds.
而且智能体能做什么并没有一份固定清单。因为 eval 能触达你项目可调用的任何 API，智能体的能力面就等同于 Unity 的能力面：渲染、物理、动画、资产数据库、编辑器本身，加上你自己代码添加的一切。
That reach is the result of more than a decade of API work, and an agent gets it without any extra integration.
这份触达范围是十余年 API 工作的成果，而智能体无需任何额外集成就能获得它。
We're at the beginning of this, and the primitives are already here today. If you're building AI-assisted tooling for Unity, the Pipeline package is where to start.
我们才刚开始，但这些基础件今天已经在这里了。如果你在为 Unity 构建 AI 辅助工具，Pipeline 包就是起点。
How it relates to Unity's AI offerings / 与 Unity 自家 AI 产品的关系
If you use Unity's AI offerings, such as the in-Editor assistant suite, this is the layer underneath it.
如果你在用 Unity 的 AI 产品（比如编辑器内置的助手套件），这就是它底下的那一层。
Unity's AI is the part that reasons about your project and decides what to do. The CLI and the Pipeline package are the execution surface that carries those decisions out: fast, local, and token-gated.
Unity 的 AI 是「对你的项目进行推理、决定做什么」的那部分；CLI 与 Pipeline 包是执行面（execution surface），负责把那些决策落实——快速、本地、受令牌管控。
The same surface is open to any agent, whether that's Unity's own tooling routing through its MCP server, a third-party assistant, or a script you write yourself.
同一个面向任何智能体开放：Unity 自家工具经其 MCP server 路由、第三方助手、或你自己写的脚本，都行。
Unity's AI is one consumer of it, not a replacement for it.
Unity 的 AI 是它的消费者之一，不是它的替代品。
Available now / 现已可用
The Unity CLI is here. Install it, run unity --help, and fold it into your next build script or CI job, or automate it with an agent.
Unity CLI 已经来了。装上它，跑一下 unity --help，把它折进你下一个构建脚本或 CI 作业里，或者交给一个智能体去自动化。
The documentation has the full command reference. Tell us what you build; your feedback shapes where it goes next.
文档里有完整的命令参考。告诉我们你造了什么——你的反馈决定它下一步走向哪里。
Official Q&A / 官方答疑精选
We created the Unity CLI MCP as a superior implementation. It's built on the new Pipeline package that allows for robust CLI to Editor communication. With that comes better performance, better handling of focus and domain reloads, and the ability to communicate with multiple Editors seamlessly.
我们做 Unity CLI MCP 是作为一个更优的实现。它建立在新的 Pipeline 包之上，能提供健壮的 CLI 到编辑器通信。随之而来的是更好的性能、更好地处理窗口焦点与域重载，以及无缝与多个编辑器通信的能力。
Pipeline is much more flexible than MCP. You can do almost anything! MCP is limited to the commands we provide and any custom ones you add.
Pipeline 比 MCP 灵活得多，你几乎什么都能做。而 MCP 只限于我们提供的命令，加上你自己添加的自定义命令。
If you want a temporary fix for the blocking dialogs, please set -automated into your Editor launch parameters.
如果你想临时解决阻塞式对话框的问题，请在编辑器启动参数里加上 -automated。
We have further work on the horizon to allow the package to control the blocking dialogs, but it requires an Editor change (and associated backports).
我们后续还会做工作让这个包能控制阻塞式对话框，但那需要修改编辑器本身（以及相应的向后移植）。
It uses the default action for all dialogs while the Editor is open. So you should only be using this for Pipeline-connected sessions.
编辑器开着时，它会对所有对话框采取默认动作。所以你只应在 Pipeline 连接的会话中使用它。
We have a unity-cli skill in our repo that teaches your agent how to use Unity CLI and the Pipeline package. npx skills add Unity-Technologies/skills
我们仓库里有一个 unity-cli skill，教你的智能体如何使用 Unity CLI 和 Pipeline 包。npx skills add Unity-Technologies/skills
We're working on creating skills here: Unity-Technologies/skills — a collection of reusable skills for AI coding agents: prompts, slash commands, and tools built for Unity workflows. We're also planning on adding integrations with the profiler and frame debugger before the CLI goes GA!
我们正在这里创建 skills：Unity-Technologies/skills——一批可复用的、给 AI 编程智能体用的 skill：为 Unity 工作流打造的提示词、斜杠命令和工具。我们还计划在 CLI 正式发布（GA）前加入与 profiler 和 frame debugger 的集成！
We're actively working on smarter exposing of commands/tools to the MCP mode and unity command and for humans too. Turns out dumping ~140 commands isn't readable to anyone!
我们正在积极改进向 MCP 模式和 unity command（以及对人）更聪明地暴露命令/工具。事实证明一口气倒出约 140 条命令，对谁都不可读！
unity eval works for the usecase you're suggesting. Just be very careful with it. In future versions we're going to adjust the command to dissuade agents/humans from using it as a crutch. It's not token efficient and it's really dangerous for humans/agents (arbitrary code execution).
unity eval 能满足你说的场景，但务必小心使用。未来版本我们会调整这条命令，劝阻智能体/人把它当拐杖用。它不省 token，而且对人和智能体都真的很危险（任意代码执行）。
I've assigned an engineer to solely work on optimizations for tokens/agent usage (and compute). We know it's really important to reduce costs and environmental impacts of our tooling.
我已经派了一名工程师专职做 token / 智能体用量（以及算力）的优化。我们知道降低工具的成本与环境影响非常重要。
Just please always keep in mind us, who aren't interested in AI-based workflows but we love to build our automations ourselves. So I really hope the CLI will be kept AI-independent.
请务必也始终记得我们这些人——对 AI 工作流不感兴趣，但热爱自己搭建自动化。所以我真心希望 CLI 能保持不依赖 AI。
BTW, since I'm usually super-critical to Unity in the last 4 years or so… Unity CLI is awesome! I really love it, thank you for making this!
顺带一提，我过去四年左右一向对 Unity 极为苛刻……Unity CLI 太棒了！我真的很喜欢，谢谢你们做了这个！
The CLI is designed to be agnostic and there are zero plans to change that.
CLI 的设计就是中立无关的（agnostic），我们零计划改变这一点。
Why CLI is superseding MCP / 为什么 CLI 正在取代 MCP
When you run an Agentic AI 'harness' — like claude, codex, cursor, pi, opencode — the way they all work is built around a simple loop, kinda like a REPL:
当你运行一个智能体 AI「harness」——比如 claude、codex、cursor、pi、opencode——它们的工作方式都围绕一个简单循环，有点像 REPL：
Send input (the 'context') to the model. Get a response back. If the response includes a tool call, automatically perform that command, add the results to the context, and go back to step 1. Otherwise, stop and wait for the user's next prompt.
把输入（「上下文」）发给模型 → 拿回一段响应 → 如果响应里含有工具调用，就自动执行那条命令、把结果加进上下文、回到第一步；否则就停下，等用户的下一句提示。
Everything that the agent does which is not 'just talking' is done through tool calls.
智能体做的一切「不只是说话」的事，都是通过工具调用完成的。
Each run around this loop takes time and costs tokens.
每绕这个循环一圈都要花时间、耗 token。
MCP is effectively a standard for registering custom 'tool calls' with a harness: a model can return a response that includes a tool call like Unity_ReadConsole(), and the harness can then carry that out and add the results to the context.
MCP 实质上是一套「向 harness 注册自定义工具调用」的标准：模型可以返回一个含 Unity_ReadConsole() 这类工具调用的响应，harness 随后执行它并把结果加进上下文。
It works, but it means that you can only do one MCP invocation each time you run around the loop, and the full response becomes part of the model input, which consumes tokens but also means the context gets filled up with responses that may not even be relevant.
它能用，但这意味着你每绕一圈循环只能做一次 MCP 调用，而且完整响应会成为模型输入的一部分——既耗 token，又意味着上下文被一些可能根本不相关的响应塞满。
Enter CLI: instead of registering each bit of custom functionality as a separate tool call, we just use one tool call, Bash(...), which runs a bash command line.
CLI 登场：不再把每一小块自定义功能注册成一个独立的工具调用，我们只用一个工具调用 Bash(...)，它运行一条 bash 命令行。
Now, Bash(unity command get_console_logs) is pretty much doing the exact same thing as Unity_ReadConsole() in the MCP… but where it gets powerful is that the model can construct a more interesting command-line than that, using basic shell features like piping.
此时 Bash(unity command get_console_logs) 干的事和 MCP 里的 Unity_ReadConsole() 基本一样……但真正强大之处在于，模型可以用管道等基本 shell 特性，构造出更有意思的命令行。
Bash(unity command get_console_logs --format json \
| jq ".data.result.logs | map(.message)" \
| grep "NullReferenceException" \
| wc -l)…to directly count the number of log messages in the console that include NullReferenceException, with a single tool call (so only one run around the loop = faster), and without any parts of the raw console output being added to the context (so fewer tokens used, and less distracting the agent with irrelevant things).
……直接数出控制台里含 NullReferenceException 的日志条数，只用一次工具调用（因此只绕一圈循环 = 更快），而且原始控制台输出的任何部分都不会进入上下文（因此更省 token，也更少用无关内容干扰智能体）。
The main downside to this stuff is that letting the agent construct and run arbitrary Bash(...) calls is risky — it can run any command that you yourself could run, including stuff like rm -rf / or curl to access the Internet.
这套东西的主要缺点是：让智能体构造并运行任意 Bash(...) 调用是有风险的——它能跑任何你自己能跑的命令，包括 rm -rf / 这类，或者用 curl 访问互联网。
Most harnesses have features to try and help mitigate this (like asking for your permission before running each command, or asking a model to assess how dangerous the command is), but some folks simply prefer to disable Bash(...) entirely, meaning that MCP is their only real option, despite the worse performance.
大多数 harness 都有缓解手段（比如每条命令执行前征求你的许可，或让一个模型评估命令有多危险），但有些人干脆偏好完全禁用 Bash(...)，这意味着 MCP 成了他们唯一的真实选项——尽管性能更差。
Bash(...) 类工具调用抓取；那些 | Select-String、--format json 的过滤，做的就是他说的「让原始输出不要进入上下文」。而「每条命令执行前征求许可」，也正是这套 harness 在做的事。