Unity Technologies 在 2026 年的 Unity AI Assistant（v2.7.0-pre.2）是 Unity 官方对 AI 编程一体化的回应------把对话、资产生成、Editor 自动化、Agent 平台全部收进一个包。Funplay Unity MCP 则是社区开源的 MCP HTTP server，把 Unity Editor 暴露成 91 个 MCP 工具，用户自己接 Claude Code / Cursor / Codex 等客户端。
两者解决"在 Unity 里用 AI"这件事，但走的是完全不同的两条路。本文按 10+ 个维度详细对比，目的是让 Unity 开发者在选型时能基于事实而非品牌做决定。
1. 整体定位对比
Unity AI Assistant
对话 + 资产生成 + 自动化 + Agent 平台
全栈 / 一站式
Funplay Unity MCP
MCP HTTP server + 工具集
轻量 / BYO 客户端
| 维度 | Unity AI Assistant | Funplay Unity MCP |
|---|---|---|
| 定位 | Editor 内 AI 能力统一入口 | MCP HTTP server 暴露 Editor 能力 |
| 典型用法 | 在 Assistant 窗口里聊天驱动 | 在 Claude Code / Cursor 等外部客户端里指令驱动 |
| 目标用户 | 想要"开箱即用"的 Unity 开发者 | 已经有 AI 客户端工作流的开发者 |
| AI 客户端关系 | 自带 Provider + 通过 ACP 接 Claude/Gemini | BYO 任意 MCP 客户端 |
Unity AI Assistant 的设计取向是"Unity 内部自成一体"------AI 对话窗口、生成器、Skills、Agent 注册表全部在 Editor 内部。Funplay Unity MCP 的取向相反------Unity 只负责暴露能力，AI 决策与对话由外部客户端承担。
2. 平台与版本要求
这是两者最直接的差异：
| 项 | Unity AI Assistant | Funplay Unity MCP |
|---|---|---|
| 最低 Unity 版本 | 6000.3 (Unity 6) | 2022.3 |
| 支持的 Unity 范围 | 仅 Unity 6 | Unity 2022.3 → 6 全覆盖 |
| 后端依赖 | 必须连 Unity Cloud（api-beta-v2.prd.azure.muse.unity.com） |
完全本地（127.0.0.1:8765） |
| 账号要求 | Unity Hub 登录 + Access Token | 无 |
| 离线可用性 | ❌ AI 推理必须联网 | ✅ 工具调用本身全本地，AI 推理走外部客户端（Claude Code 等可走本地模型） |
对当前还停留在 Unity 2022 LTS 或 2023 的项目而言，Unity AI Assistant 完全不可用------这是相当一部分商业项目的现实。Funplay Unity MCP 在这一带向下覆盖 4 年的存量项目。
3. 协议与架构
Unity AI Assistant 的三进程模型
Unity Editor 主进程
UI + Tool 执行 + MCP Server
Relay App
原生子进程
Unity Cloud Backend
Muse / AI Gateway
AI Agent 进程
Claude Code / Gemini CLI / Codex
ACP over Gateway
三个进程串起来：
- Unity Editor 主进程：UI、工具执行、MCP Server 内嵌
- Relay App：原生编译子进程（macOS ARM64 / x64、Linux、Windows 各一份），WebSocket 桥接 Editor 与 Unity Cloud
- AI Agent 进程：第三方客户端（Claude Code、Cursor 等），可通过 MCP IPC 或 ACP over Gateway 接入
Funplay Unity MCP 的单进程模型
Unity Editor 主进程
HTTP MCP Server :8765
外部 AI 客户端
Claude Code / Cursor / Codex
本地 HTTP / JSON-RPC
无外网依赖
只有 Unity Editor 一个进程，HTTP MCP server 直接跑在 Editor 内部，AI 客户端通过标准 MCP 协议 over HTTP 直连。无 Relay、无 Cloud、无 Gateway。
| 维度 | Unity AI Assistant | Funplay Unity MCP |
|---|---|---|
| 进程数 | 3（Editor + Relay + Agent） | 2（Editor + Agent） |
| 协议 | ACP + MCP + Unity 私有协议 | 标准 MCP over HTTP/JSON-RPC 2.0 |
| 传输 | WebSocket (Relay ↔ Cloud) + IPC (Editor ↔ Agent) | HTTP (Editor ↔ Agent) |
| 网络出口 | 必须出公网 | 仅 127.0.0.1 |
4. MCP 工具暴露：15 vs 91
Unity AI Assistant 的 MCP Server 主要服务于"让外部 Agent 控制 Unity"，对外暴露约 15 个工具：
ManageAsset、ManageGameObject、ManageScene、ManageEditor、ManageMenuItem、ManageScript / CreateScript / DeleteScript、ManageShader、ApplyTextEdits / ScriptApplyEdits、RunCommand、ReadConsole、FindInFile / ListResources / ReadResource、ImportExternalModel、GetSHA、ValidateScript
设计取向是"Manage*"------一个工具覆盖一类对象的 CRUD（如 ManageGameObject 同时承担创建、修改、删除）。优势是工具数量少，劣势是单个工具参数复杂、LLM 选对 sub-action 的概率被一压再压。
Funplay Unity MCP 在 v0.3.0 暴露 91 个工具，分 20 个 [ToolProvider] 模块，并提供 core (29) / full (91) 两套 profile：
| 暴露策略 | Unity AI Assistant | Funplay Unity MCP |
|---|---|---|
| 总工具数 | ~15 | 91 |
| 暴露形式 | 固定，按 "Manage*" 大粒度 | core 29 / full 91，按操作粒度细分 |
| 默认 profile | 全部 15 | core 29（含 execute_code 兜底） |
| 新工具扩展 | 不开放，Unity 内置注册 | [ToolProvider] + [ToolParam] 三步即可 |
关于工具数量与选择率的反直觉关系，Funplay 的设计选择是"细粒度工具 + 精简 default profile + execute_code 兜底"，与 Unity 的"大粒度 Manage*"是两种取舍。
5. 通用工具逃生口：RunCommand vs execute_code
两者都意识到"工具集不可能覆盖所有需求"，都提供了通用 C# 执行入口，但实现风格差别明显：
| 维度 | RunCommand (Unity AI Assistant) | execute_code (Funplay Unity MCP) |
|---|---|---|
| 执行模型 | IRunCommand 接口实现 |
IFunplayCommand 接口实现 |
| 编译方式 | 内部脚本系统 | CodeDom 内存编译 |
| 文件落盘 | 不写 .cs 文件 | 不写 .cs 文件 |
| Domain Reload | 不触发 | 不触发 |
| 沙箱 | ✅ 命名空间黑名单（System.Reflection, System.Net 等） |
❌ 无沙箱，依赖客户端层审批 |
| 权限审批 | IToolPermissions + AllowOnce/Always/DenyOnce |
客户端侧（如 Claude Code 的 tool approval） |
| Undo 集成 | 间接 | ctx.RegisterObjectCreation/Modification（直接） |
| 结构化返回 | 字符串 | ctx.ReturnValue 任意类型 + 结构化 messages |
Unity 的 RunCommand 走"沙箱限制"路线------禁用反射、网络等危险命名空间。优势是默认安全，劣势是有些合理的脚本场景被一刀切（例如反射调用项目内自定义 API）。
Funplay 的 execute_code 不沙箱------把"是否允许这段代码执行"的决定交给客户端层。Claude Code 在 invoke tool 之前会展示代码让用户审批，这种 client-side approval 在 AI 客户端层面是当下的标准模式。两种策略各有适用，企业敏感场景下 Unity 的服务端沙箱更稳。
execute_code 的 IFunplayCommand 与 Undo 集成详见。
6. PlayMode 自动化能力
Unity AI Assistant 在 PlayMode 上提供的工具：
Unity.EnterPlayMode、Unity.ExitPlayMode
仅有进入与退出，不提供 PlayMode 期间的截图、输入模拟、Game View 状态读取。这意味着外部 Agent 无法在 PlayMode 里"看到游戏在跑"------它能命令 Unity 进 PlayMode，但接下来发生什么对它而言是黑箱。
Funplay Unity MCP 提供完整的 PlayMode 视觉闭环：
| 工具 | Unity AI Assistant | Funplay Unity MCP |
|---|---|---|
| 进入 PlayMode | ✅ | ✅ |
| 退出 PlayMode | ✅ | ✅ |
| 模拟鼠标点击 | ❌ | ✅ simulate_mouse_click |
| 模拟键盘 | ❌ | ✅ simulate_key_press / simulate_key_combo |
| 截图 Game View | ✅（CameraTools，截图工具但非 PlayMode 专属） | ✅ capture_game_view |
| 读 Console 日志 | ✅ ReadConsole | ✅ get_console_logs |
| PlayMode 视觉闭环 | ❌ 不完整 | ✅ 完整 |
对希望让 AI 自动完成"修改 → 进 PlayMode → 测试 → 看结果 → 退出 → 再调"循环的场景，Funplay 是当下唯一能完整闭环的方案。Unity 自身可能在未来版本补齐这部分，但 v2.7 暂未到位。
7. 资产生成：Unity 独家 vs 借助外部生态
这是 Unity AI Assistant 最难复制的优势------5 类内置生成器，配套 Unity Cloud 后端：
| 生成器 | 输入 | 输出 |
|---|---|---|
| Texture/Image | 文本 / 参考图 / 涂鸦板 | Texture2D / Sprite / Cubemap |
| 3D Mesh | 文本 | .glb / .fbx |
| Material/PBR | 文本 / 参考图 | Material / TerrainLayer |
| Sound | 文本 / 参考音频 / 录音 | AudioClip |
| Animation | 文本 / 角色模型 | AnimationClip |
模型在 Unity 后端托管，按 Credits 计费。生成器与 Editor 的集成深度高（精灵表生成、骨骼映射、地形图层等都做了 Unity 特化）。
Funplay Unity MCP 不内建生成器。资产生成走"外部生态 + execute_code 落地"路径：
- AI 客户端调用 Replicate / Stable Diffusion / Stability / Meshy 等公开 API 生成图片/模型
- 通过 execute_code 把生成的资源导入项目（AssetDatabase.ImportAsset）+ 处理设置（贴图压缩、模型导入设置等）
这种路径的优势是 BYO 模型（用户自己选最强或最便宜的），劣势是 Unity 特化的体验（骨骼映射、地形图层等）需要自己拼。对个人开发者这两种取舍各有合理，对生产项目则取决于团队成本与定制需求。
8. Skills 系统对比
两者都有 Skills 概念但实现差别明显：
Unity AI Assistant Skills：
- SKILL.md + YAML frontmatter（name、description、required_packages、required_editor_version、tools、enabled）
- SkillsScanner 扫描项目内 SKILL.md 文件
- 技能正文作为 System Prompt 注入 AI Agent
- 技能可绑定特定工具（如 Cinemachine skill 仅启用 CreateGameObject、CodeEdit）
Funplay Unity MCP Skills：
unity-mcp-workflowskill 通过Funplay → Project Skills菜单安装到目标 AI 客户端（Claude Code / Cursor 等）- skill 本身是给客户端读取的 prompt 与规则集合，不在 Unity 端执行
- 由客户端 SDK（Claude Code 的 .claude/skills/）维护
两者面向的"Skills"层不同------Unity 的 Skills 是 Agent System Prompt 的 Unity 端补丁，Funplay 的 Skills 是 AI 客户端侧的工作流指引。前者紧耦合 Unity Cloud 推理，后者依靠客户端自己的 skill 加载机制。
9. 商业模式与成本
| 项 | Unity AI Assistant | Funplay Unity MCP |
|---|---|---|
| License | Unity Terms of Service（私有） | MIT 开源 |
| 计费 | Credits 点数制（预授权 25 点/请求） | 免费（用户自付外部 AI 客户端费用） |
| 企业管控 | Unity Dashboard 管理团队点数、成员访问 | 完全本地，企业管控通过 AI 客户端策略（如 Claude Code policy） |
| 模型分层 | unity-fast / unity-max | 不限制，客户端自行选 |
| 第三方 BYOK | AI Gateway 支持自带 Claude/Gemini API Key | 天然 BYO，无需任何 Gateway |
对个人开发者：
- 单次使用强度低 → Unity AI Assistant 的 Credits 制可能更省（无固定订阅）
- 重度使用 / 大量代码生成 → 自带 Claude API / Cursor 订阅可能更可控
对企业：
- 需要统一管控 / 审计 / 报销 → Unity Dashboard 是即用的方案
- 已有 AI 工具基础设施（如 Anthropic 企业账户）→ Funplay 不增加新的供应商关系
10. 数据本地化
| 项 | Unity AI Assistant | Funplay Unity MCP |
|---|---|---|
| 对话历史存储 | Unity Cloud（可恢复跨设备） | 客户端本地（Claude Code / Cursor 自己的会话存储） |
| 项目代码上传 | 工具调用结果发往 Cloud 推理 | 工具调用本身本地，AI 客户端可能上传至其供应商 |
| 截图 / 资产 | 经 Relay 上传 Unity Cloud | 本地 base64 / 文件路径 |
| 企业合规 | Unity ToS + Unity 隐私政策 | 取决于用户选的 AI 客户端供应商 |
对涉及代码或资产敏感性的场景，"经过哪些第三方"是关键决策点。Unity AI Assistant 是"经过 Unity Cloud + 可选 Anthropic/Google"，Funplay 是"经过用户选定的 AI 客户端供应商"。
11. 演进速度
| 项 | Unity AI Assistant | Funplay Unity MCP |
|---|---|---|
| 首发时间 | 2025-04（v1.0.0-pre.1） | 2026-01 |
| 当前版本 | v2.7.0-pre.2（13 个月 30+ 版本） | v0.3.0（4 个月 4+ 版本） |
| 发版节奏 | 周级 | 双周到月级 |
| 覆盖面 | 单一对话 → 全栈 AI 产品 | 19 工具 → 91 工具 |
Unity 的演进速度反映了其作为引擎厂商的资源投入。Funplay 作为社区项目演进速度有限，但优势是改动方向由用户需求驱动，没有内部产品路线图约束。
12. 何时选哪个
2022.3 - 2023.x
6000.3+
想要一站式 + 生成器 + Credits 计费
已有 Claude/Cursor 工作流 + 想要本地化
两套并用
你的项目
Unity 版本
Funplay Unity MCP
唯一选择
使用偏好
Unity AI Assistant
Funplay Unity MCP
都装
详细判断标准：
| 场景 | 推荐 |
|---|---|
| Unity 2022.3 / 2023 LTS 项目 | Funplay Unity MCP（Unity AI Assistant 不支持） |
| 需要 AI 生成 Texture / Mesh / Sound / Animation | Unity AI Assistant（生成器独家） |
| 已经在 Claude Code / Cursor 里有完整 AI 工作流 | Funplay Unity MCP（无缝接入） |
| 需要 PlayMode 视觉闭环（截图 + 输入模拟） | Funplay Unity MCP（Unity 暂缺） |
| 企业需要 Dashboard 统一管控 | Unity AI Assistant（开箱即用） |
| 需要 100% 本地推理 / 离线场景 | Funplay Unity MCP（外接 Ollama 等本地模型） |
| 想用 Unity Pro Credits 计费体系 | Unity AI Assistant |
| 想要 MIT 开源 / 二次开发 | Funplay Unity MCP |
| 想要 91 个细粒度工具 / core+full profile | Funplay Unity MCP |
实际中两者并不互斥------Unity AI Assistant 主要在 Editor 内部使用，Funplay Unity MCP 主要在外部 AI 客户端使用。开发者可以两套并用：日常对话与生成走 Unity AI Assistant，复杂的多工具编排走 Claude Code + Funplay Unity MCP。
13. 写在最后
Unity AI Assistant 与 Funplay Unity MCP 是两种完全不同的产品哲学的具体落地：
- Unity 的策略：全栈 + 收敛 + 平台化------把所有 AI 能力收进 Editor，用 Credits 体系与 Unity Cloud 绑定，用 ACP 协议纳入第三方 Agent 但保留 Gateway 控制
- Funplay 的策略：轻量 + 开放 + BYO------把 Editor 暴露成标准 MCP server，AI 决策交给用户选定的客户端，全本地 MIT 开源
两条路径都合理，没有谁取代谁的问题。对个人开发者与中小团队，选择往往基于"已经有什么"------已经付 Claude / Cursor 订阅的会自然走 Funplay，已经在 Unity Pro 体系内的会自然走 Unity AI Assistant。
Funplay Unity MCP 仓库地址：FunplayAI/funplay-unity-mcp，MIT 协议。Unity 6 用户希望两套并用、或对 PlayMode 闭环、91 工具细粒度感兴趣的开发者，可以试试。
本文基于 Unity AI Assistant v2.7.0-pre.2（2026-05）与 Funplay Unity MCP v0.3.0 的实现对比。版本演进可能改变两侧的能力清单------以最新发布为准。