说出来可能有点夸张去年有半年我每天最烦的事就是在 Unity 里来回调参数。光照强度不对改一个 float物体位置偏了拖一下 Transform材质颜色不对再点开色板选半天。这些操作本身不难但架不住量多改一版要重复点几十下。当时我就想如果我能直接跟编辑器说一句“把主光源调暖一点、亮度降到 800”剩下的它自己搞定那该多好。2026 年回头看这个想法已经不稀奇了——Unity MCP、UnrealClaude 这批工具链正在把“用自然语言驱动游戏引擎”从玩具 demo 变成正经的日常开发方式。这篇东西基于我过去大半年在 Unity 和 Unreal 两边反复折腾 MCP 工具链的真实记录。包含完整配置过程、意图识别与槽位提取的原理拆解、工具链选型对比以及大量踩坑后的修正方案。适合三种人看想了解 MCP 在游戏开发里到底怎么落地的技术管理者打算给团队搭 AI 辅助开发流程的 TA 或工具链工程师以及单纯想在 Unity/Unreal 里试试“动嘴改场景”的独立开发者。看完不说能直接上生产至少能少走我走过的那些弯路。1. 先搞清楚MCP 在 AI 游戏工作流里到底解决什么问题1.1 从“AI 写代码”到“AI 动手改场景”前两年我们聊 AI 辅助游戏开发基本说的是“让 AI 写 C# 脚本”或者“让 AI 生成 Shader 代码”。这当然有用但有个很明显的瓶颈代码生成出来后你还得自己复制进工程、自己挂载组件、自己调参。繁琐的编辑器操作一样没少AI 只是帮我们写了一个“还没生效的半成品”。MCPModel Context Protocol模型上下文协议的出现改变了这件事。它本质上是给大模型开了一扇直通外部工具的门让模型不只输出文本还能通过一组标准化的工具接口去读场景、改属性、执行操作。游戏引擎的 MCP 服务端相当于一个翻译层把 Unity 或 Unreal 的编辑器内部 API 封装成一个个工具模型只需要知道“有这些工具可用、各个参数是什么意思”就能以函数调用的方式直接操作引擎。我打个比方。以前的 AI 像是一个资深顾问坐在你旁边给你出主意但动手的永远是你。接了 MCP 之后这个顾问直接接管了你的键盘鼠标你说一句“帮我把镜头拉近到主角背后”它自己就推摇杆去了。1.2 游戏编辑器和普通软件不一样接入成本要看这一点做过工具链的人都会有感觉给 IDE 接 MCP 相对容易因为 VS Code、JetBrains 都有成熟的插件体系和稳定的进程间通信方式。但游戏引擎完全是另一回事。Unity Editor 和 Unreal Editor 本质上都是 GUI 密集型应用程序场景视图、层级面板、Inspector、蓝图编辑器大量操作依赖“选中某个对象”——这个交互在 GUI 里是天经地义的事但在文本/工具调用接口里就变得很别扭。比如你让 AI 把场景里的一盏灯调亮它首先得知道灯光对象叫Spotlight (1)还得知道属性路径是Light.intensity更要知道当前编辑器处于什么模式。所以成熟可用的游戏引擎 MCP 工具链核心不在于“协议本身”而在于引擎侧到底暴露了哪些工具、工具之间的编排是否合理。这也是 Unity MCP 和 UnrealClaude 这类项目真正值钱的地方。它们不是简单地把 C# 或者 Python API 翻成 MCP 工具而是把编辑器操作重新建模了一遍把高频的、可脚本化的操作提取成一组经过设计的工具集。理论上这套东西适合所有游戏开发者但坦白讲目前最受益的群体是三种做程序化关卡原型的策划、在引擎里布置大量临时场景的 TA、以及需要快速做 AI 沙盒实验的研究人员。1.3 2026 年的 MCP 工具链生态现状简要版到现在游戏引擎 MCP 已经不是某一个项目的独角戏。Unity 这边有几个开源社区项目在维护核心功能覆盖场景对象 CRUD、材质替换、Play 模式控制、Prefab 操作等Unreal 那边则以 UnrealClaude 为代表走的是 Unreal Editor Python API 桥接路线。另外像 Cocos、Godot 也开始有人做 MCP 适配H5 游戏引擎如 Phaser 也有实验性的方案。整体生态处在“能用但没那么稳”的早期成熟阶段。我接下来的内容主要围绕 Unity MCP 和 UnrealClaude 这两条主线展开。2. Unity MCP 从零接进来配置过程与工具清单2.1 环境准备和插件安装先说环境。以我实测的频率看Unity 2022.3 LTS 和 2021.3 LTS 都跑过 Unity MCP建议用 2022.3 或更新的 6000.x 系列。太老的 2019/2020 版本会出现 API 兼容问题社区维护者也基本只往前看。安装方式以 Unity MCP 官方推荐的步骤为准拿到 MCP 项目的 Git 地址一般是 GitHub 上的仓库需联网访问。在 Unity 中打开Window - Package Manager点左上角加号选择Add package from git URL...把仓库地址粘进去。等待编译完成工具栏会出现MCP菜单。这个过程走完你会在项目里看到MCP相关的 Editor 脚本被挂进来。它本质是一个运行在 Unity Editor 内部的轻量级 HTTP 服务监听本地端口用 JSON-RPC 2.0 格式跟外部 MCP 客户端通信。默认端口每个项目略有差异常见的是 8765但我遇到过端口冲突的情况后面踩坑部分细说。2.2 Claude Desktop 侧的 MCP 配置在 Unity 编辑器这一侧MCP Server 运行后需要让 Claude Desktop 或兼容客户端知道怎么连接它。Claude Desktop 的全局配置在 claude_desktop_config.json 里Windows 路径一般是{ mcpServers: { unity-mcp: { command: npx, args: [ -y, unity-mcp-server ], env: { UNITY_EDITOR_PATH: C:/Program Files/Unity/Hub/Editor/2022.3.10f1/Editor/Unity.exe } } } }注意这里有一个经验点npx -y unity-mcp-server这个命令的作用是拉起一个 Node.js 编写的客户端桥接进程它负责跟 Unity 编辑器内的 MCP Server 通信。所以实际上你只需要保证 Node.js 环境可用、网络能拉到 npm 包。配置完成后重启 Claude Desktop在工具列表里就应该能看到unity_get_scene_info、unity_create_object这类工具名。看到工具列表的那一刻就意味着通信链路已经打通了。提示如果你用的是国内网络环境拉 npm 包的时候偶尔会超时可以把 registry 临时切到镜像源但注意不要影响日常开发的其他依赖。2.3 Unity MCP 提供哪些核心工具不同项目的工具命名会有差异但整体能力边界是比较一致的。下面列出我实际使用频率最高的一组工具按功能分类分类工具名称示例作用常用程度场景状态get_scene_hierarchy获取当前场景层级结构包括所有对象名和父子关系极高对象操作create_primitive创建 Cube、Sphere、Capsule 等基础物体极高对象操作modify_transform修改对象的 position、rotation、scale极高组件操作add_component给对象挂载 Rigidbody、Light、Camera 等组件高资源操作set_material_property修改材质颜色、金属度等参数高组件操作set_component_property修改已挂载组件的属性比如 Light.intensity高运行控制enter_play_mode/exit_play_mode进入/退出 Play 模式中文件操作create_asset_folder创建文件夹低有了这组工具大模型就能做很多事了。我实测过一通最简单的连续对话先让它看一下场景里有哪些物体然后让它把名为Cube的物体移动到 (3, 0, 3)再把主光源调亮到 1200。整个过程不到 30 秒换作手动操作至少一分钟起步而且不需要打开任何脚本文件。2.4 第一次用自然语言驱动的完整流程拿一个具体的命令串来说你可以直接在 Claude Desktop 里输入帮我看看当前场景里有什么。模型会调用get_scene_hierarchy返回一份 JSON 格式的层级列表。然后输入在 (0, 1, 0) 位置创建一个半径 0.5 的球体默认材质命名叫 TestBall。模型会先调用create_primitive传递primitiveType: Sphere、position: {x: 0, y: 1, z: 0}、scale: {x: 0.5, y: 0.5, z: 0.5}等参数。Unity 侧收到后直接生成物体。上面这个链路中间最关键的是 Unity MCP 服务端把 MCP 工具调用翻译成 Unity 的GameObject操作。只要你在 Scene 视图里看到新球出现就说明全链路已经走通了。3. 自然语言到引擎操作意图识别、槽位提取与 JSON 落地的关键设计3.1 先理解“意图”和“槽位”这两个词很多人第一次接触自然语言驱动引擎时容易被“AI 好神奇”带偏觉得是模型直接理解了 Unity 的 C# API。实际上真正起作用的是一套结构化的中间表示意图识别和槽位提取。意图intent指的是用户这条指令想干什么。槽位slot指的是完成这个操作所需要的具体参数。比如“在 (5, 0, 3) 位置放一个红色材质的立方体”意图是CreatePrimitive槽位有对象类型、位置坐标、材质颜色、是否需要碰撞体等。用 Python 做意图识别和槽位提取并不是只有 Rasa 那样的传统 NLU 框架才能做。在 MCP 场景下更简单可靠的方式是利用大模型自身的函数调用function calling能力让它把自然语言输出成一段严格的 JSON。用户输入: 在(5,0,3)的位置放一个红色材质的立方体 模型输出: { intent: CreatePrimitive, slots: { primitiveType: cube, position: {x: 5, y: 0, z: 3}, material: red } }引擎侧收到这个 JSON 后再做参数映射和 API 调用。这比用正则匹配可靠得多也比传统的槽位填充更鲁棒——因为面对“放个矩形”、“搞一个方块”、“我要个立方体”这类同义表达大模型都能收敛到同一个 intent 上。3.2 槽位输出最容易翻车的地方JSON 结构不匹配这个环节最值得展开说。理论上大模型输出 JSON 很自然但实际工程里问题不少。第一引擎端解析 JSON 的工具通常很死板。Unity 的JsonUtility对字段名大小写敏感而且要求字段名跟 C# 类严格对应。你让模型输出position但 C# 类里写的是Position直接就解析失败了。社区里很多 Unity MCP 服务端会做一层字段名映射但做不到 100% 覆盖。如果你是自己搭 MCP Server建议直接上 Newtonsoft.Json 或者 System.Text.Json并配置大小写不敏感的属性名匹配省掉这一堆问题。第二坐标和单位的“想当然”错误。大模型训练语料里关于 Unity 的知识通常是笼统的可能把 Unreal 的厘米习惯带入 Unity 的世界。比如让模型放一个 5 米高的柱子Unity 里 feed 过去可能是 500导致场景里突然出现一个擎天柱级别的物体。我的做法是在工具描述里明确标注“distance unit: meters”并且在服务端做一次范围钳制超过合理范围的数值自动报警。第三槽位缺失时要明确要求模型追问而不是猜默认值。比如用户说“放一个立方体”没说位置如果模型直接默认 (0,0,0) 就没问题但万一用户其实想放在某个物体旁边呢我在工具定义里会把 position 设为 optional并附加说明“如果未提供默认使用 (0,0,0)若用户询问建议先追问”。3.3 轻量 Python 终端 Agent 怎么实现意图-槽位-执行闭环除了在 Claude Desktop 里用现成客户端你也可以在终端里用自然语言操控游戏引擎。核心逻辑就三步收集用户输入 - 用大模型做意图识别槽位提取 - 调用引擎 HTTP 接口执行。我写过的最小可运行版本用 FastAPI 起一个本地服务再在终端里循环读取输入from openai import OpenAI import requests import json client OpenAI(api_keyyour-key, base_urlhttps://your-llm-endpoint) def nlu(user_input): resp client.chat.completions.create( modelqwen-plus, messages[{ role: system, content: ( 你是游戏引擎操作助手。将用户输入转换为JSON指令。 必须包含intent和slots两个字段。 intent只能是: CreatePrimitive, ModifyTransform, SetMaterial, PlayMode 之一。 ) }, { role: user, content: user_input }], response_format{type: json_object} ) return json.loads(resp.choices[0].message.content) if __name__ __main__: while True: cmd input(输入命令: ) parsed nlu(cmd) # 根据 intent 转发到 Unity MCP Server 的 HTTP 端口 requests.post( http://127.0.0.1:8765/api, json{tool: parsed[intent], arguments: parsed[slots]} )这个是示意代码实际使用还需要考虑上下文管理、多轮对话修正和错误重试。但核心思路已经足够说明自然语言驱动引擎的落地路径其实就是把“意图识别 - 槽位提取 - 工具调用”这条链路串起来MCP 只是让最后一步变得更加标准。3.4 工具描述怎么写才能减少模型幻觉大模型能不能准确调用工具很大程度取决于 tool schema 里的描述是否清晰。这个点很多做 MCP 工具链的人会忽视。描述写得模糊模型就会猜一猜就会错。我的几个经验每个参数的描述必须包含单位、坐标系、合法范围。比如position.y要写清楚“世界坐标米通常范围为 -500 到 500”。工具描述里要带上典型案例尤其是不常见的值。比如set_material_property里metallic取 1.0 表示完全金属0.0 表示非金属。对互斥参数要做说明。比如create_primitive里primitiveType和meshPath二选一模型如果同时给了服务端要能丢弃一个并记录日志。尽量少用抽象的词。不要写“调整光照氛围”要写“修改 Light 组件的 intensity 属性float 类型默认 1范围 0-8”。一句话MCP 工具链设计里最花时间的不是写服务端代码而是打磨工具描述。工具描述打磨得好模型调用的准确率会有非常明显的提升。4. UnrealClaude 的接入姿态Claude Python API 直接改关卡4.1 Unreal Editor 的脚本化基础Unreal 这边和 Unity 有一个很大区别Unreal Editor 官方就支持完整的 Python 脚本框架也就是 编辑器 PythonEditor Scripting Python。通过 Python 可以访问unreal模块里面包含EditorLevelLibrary、EditorAssetLibrary、EditorFilterLibrary等一系列操作关卡和资产的接口。这意味着接入 Claude 或其他大模型时不必像 Unity 那样专门写 C# 桥接而是可以直接用 Python 充当胶水层。UnrealClaude 这个方案的思路就是在本地跑一个 Python 进程它既作为 MCP Server 接收来自 Claude Desktop 的工具调用请求又通过unrealPython API 操作 Unreal Editor。实际架构如下Unreal 编辑器启动时需要开启“Enable Python Editor Script Plugins”插件并确保编辑器在启动时允许外部 Python 脚本连接。UnrealClaude 的 Python Server 进程启动后会把所有可用的 Unreal 编辑操作注册成 MCP 工具。Claude Desktop 通过 MCP 协议调用这些工具Unreal 编辑器内的场景、资产、蓝图就会跟着改变。4.2 部署时最容易卡住的环节UnrealClaude 的部署有几个坑点比 Unity 那边多一点。第一个坑是 Python 环境。Unreal 编辑器内置的 Python 解释器和你系统里的 Python 不一定是同一个。如果你用系统 Python 去跑 anaconda 环境而 Unreal 用的是自己的内置解释器两者之间没有直接关联。很多教程没提这一步导致你明明装了unreal模块运行却报 ModuleNotFoundError。正确做法是先找到 Unreal 安装目录下的 Python 解释器路径用那个解释器去安装依赖或者干脆在 UnrealEditor 的 Python 控制台里执行命令来验证import unreal是否成功。第二个坑是编辑器状态锁定。Unreal 编辑器在编译、加载资产、运行 PIEPlay In Editor时Python 脚本调用有可能被阻塞甚至会直接崩溃。从我的实际体验看UnrealClaude 每次执行完工具调用后最好强制延迟 0.2 到 0.5 秒让编辑器有足够时间刷新界面。不要连续快速调多个工具否则容易出现“命令发出去了但场景没变”的假象。第三个坑是资产路径大小写。Unreal 的资产路径/Game/Map/MyMap有严格的大小写规则而大模型生成的路径经常把首字母小写。我在 FModel 等工具里见过太多这种问题了。服务端要做一次路径规范化否则 Claude 会反复报 “Asset not found”而文件明明就在那里。4.3 用自然语言修改 Unreal 关卡的实际用例我拿一个真实用例来演示。有一次我要快速做一个夜景测试关卡需要的操作是在场景里放一盏点光源、把光源颜色改成偏暖、再把亮度调到 3000 勒克斯左右。在 UnrealClaude 的对话窗口里输入在关卡中放置一个 PointLight位置在 (500, 200, 300)光源颜色为暖橙色强度为 3000。UnrealClaude 这边的工具链路是这样的先调用get_actor_list获取当前关卡中已有 Actor 列表确认没有重名冲突。调用spawn_actor参数填actor_class: PointLight、location: (500, 200, 300)。调用set_actor_property参数填property_name: LightColor、value: (255, 180, 120)。再调用set_actor_property参数填property_name: Intensity、value: 3000.0。整个过程在对话界面看到的结果是模型连续调用了多个工具Unreal 编辑器里依次出现灯光、变色、变亮。这背后和 Unity MCP 的链路本质上一样只是 Unreal 的 Python API 面更广工具数量更庞大。4.4 UnrealClaude 能做什么不建议做什么UnrealClaude 的能力边界我用一张表说清楚能力现状建议创建/删除 Actor稳定适合搭建临时测试关卡修改 Actor Transform稳定高频使用修改材质参数较稳定注意资产路径问题蓝图节点创建有限支持复杂逻辑还是手动做蓝图连线不稳定不建议纯靠 AI 完成运行 PIE 并验证中等可以做基础冒烟测试坦白讲蓝图是 Unreal 的灵魂之一但蓝图图形化的本质决定了它不太适合被 MCP 工具化。Creating a blueprint node 是一回事把节点之间的连线、执行流、事件绑定全部文本化表示又是一回事。当前 UnrealClaude 对蓝图的处理比较有限复杂的游戏逻辑建议还是在编辑器里手写别为难 AI。5. Unity MCP 与 UnrealClaude 对比不是二选一是按需取用5.1 两条路线的本质差异把 Unity MCP 和 UnrealClaude 放一起看会发现它们不是简单的“同一个功能的双版本”而是两种不同的架构思路。Unity MCP 的代表性实现走的是 C# 扩展 本地 HTTP Server 的路线。它把 Unity 编辑器当成一个独立的服务端外部 MCP 客户端直接与之通信。优势是链路短、延迟低、和 Unity 的各类 API 结合紧密劣势是往往是社区项目维护引擎版本升级后容易出现兼容问题。UnrealClaude 走的是 Python 桥接路线。因为 Unreal 官方提供了 Python 脚本架构外部 Python 进程可以直接通过unrealAPI 操纵编辑器。优势是工具面广几乎覆盖面对象、资产、关卡的所有操作而且借助 Python 生态定制能力很强劣势是需要额外维护一个 Python 服务进程多了一层调用链稳定性稍差。下面这个表是我根据自己的使用体验做的综合对比不一定完全客观但很有参考价值维度Unity MCPUnrealClaude架构本质C# Editor 扩展 HTTP ServerPython 桥接 unreal 模块安装复杂度中Package Manager 安装偏高需要配 Python 环境工具覆盖面中等聚焦场景操作广覆盖资产、关卡、蓝图稳定性较稳但依赖 Unity 版本中等偶发编辑器锁死蓝图支持不适用有限多用户场景单机 Editor单机 Editor适合人群Unity 团队、TA、独立开发者Unreal 团队、关卡设计师扩展成本需要写 C#需要写 Python较灵活5.2 怎么选一个简单的判断标准要是看完对比还不知道选哪个我的建议是以你主力引擎为准。Unity 项目就用 Unity MCPUnreal 项目就用 UnrealClaude。道理很简单MCP 工具链目前还没有成熟到跨引擎通用的程度与其强行统一不如在单一引擎内先把流程跑顺。如果你是做 H5 2D 游戏开发的比如 Cocos、Phaser目前也有实验性的 MCP 方案但生态远不如 Unity/Unreal 成熟。如果你对这块感兴趣可以关注那些支持 HTTP 接口的 2D 引擎——比如基于 HTML5 的 Phaser 项目通过 Node.js 桥接 MCP 是可行的。5.3 混用场景Unity 和 Unreal 项目并行时的统一入口有的团队两个引擎都在用你可能想问能不能用一个统一的 MCP 客户端同时连 Unity 和 Unreal从协议层面讲完全可以。MCP 客户端支持配置多个 serverclaude_desktop_config.json里可以同时配unity-mcp和unreal-claude两个条目。模型会根据上下文自动选择调用哪个工具。我在自己的环境里就是这么配的打开 Claude Desktop 后它能看到两套工具列表在对话里说“Unity 场景”或“Unreal”即可明确指向。但实际使用要注意一点同一时间最好只开一个引擎的 MCP server。因为两个引擎的 MCP server 都需要监听本地端口如果端口冲突后启动的那个会默默失败。建议 Unity 用 8765Unreal 用 9876固定端口不要自动变化。6. 实战串联用自然语言二十分钟搭一个小场景含排查经验6.1 任务设定搭一个简单迷宫理论讲完看一个完整的实战。任务是用自然语言在 Unity 里搭建一个迷宫场景要求包括地面、墙体、若干锥体障碍物、一个主光源并让摄像机从高处俯瞰。我把对话命令按顺序列在这里按这位博主当时的实际执行顺序“创建一个平面命名 Ground位置 (0,0,0)大小 20x20。”“创建几个立方体作为墙体组成一个 10x10 的迷宫墙体高度 2厚度 0.5用白色材质。”“在迷宫中央放置两个红色的圆锥体。”“创建一个 Directional Light旋转角度让场景有立体阴影。”“把 Main Camera 移到 (0, 15, 15)让它俯视整个迷宫。”如果每一步都让 AI 自己去做它会调用create_primitive、modify_transform、set_material_property、set_component_property这些工具。大概 2 分钟左右就能在场景里看到雏形。剩下 18 分钟干什么呢打磨细节给墙体加碰撞体、调整灯光的颜色温度、给物体加一点随机旋转。6.2 实测中出现的三个典型问题这个流程看着顺畅实际执行时我至少踩了三个坑都有代表性。第一个坑批量创建物体时对象命名冲突。如果直接让 AI “创建 30 个立方体”它通常会生成Cube、Cube (1)、Cube (2)这样的名字层级面板一片混乱。解决方法是让 AI 按区块命名比如Wall_01、Wall_02并且在工具调用里显式传入名字参数。如果模型没有命名习惯也可以在 system prompt 里加一句“创建对象时始终使用有意义的前缀”。第二个坑坐标覆盖问题。AI 连续修改同一个对象时可能出现上一次调用的值把下一次覆盖掉的情况。比如它先设置了 Cube 的 position随后又设置 Cube 的 rotation但 pos 莫名变成了 (0,0,0)。我遇到的原因是模型在调用modify_transform时会把未提及的参数写成默认值。解决办法在工具定义里把 position、rotation、scale 拆成三个工具分别修改而不是一个工具带全部参数这样模型就不会乱填了。第三个坑Play 模式导致 MCP 连接中断。Unity 进入 Play 模式后Editor 资源重载MCP Server 的端口监听偶尔会断。如果你在 Play 模式下让 AI 改物体属性很可能工具调用成功但场景没变化。我的做法是凡是 MCP 控制的操作尽量在 Edit 模式完成进入 Play 模式只做验证不再发修改指令。6.3 一个值得参考的 AI 工作流组织方式经过这么多轮折腾我现在的工作流已经稳定成下面这个样子准备阶段手动规划好场景结构把需要 AI 做的任务拆成一条条可验证的命令。执行阶段让 AI 批量创建对象、设置位置、调材质。验证阶段切换 Play 模式观察游戏视图找出问题再切回 Edit 模式让 AI 修改。这条流程的关键在于AI 负责执行人类负责验收。不要让 AI 在一个没有明确验收标准的任务上长时间自主运行否则它容易陷入“以为做完了但到处是问题”的状态。我自己吃过亏所以特别强调这一点。7. 给后来者的几个工具链细节优化建议7.1 上下文窗口不够用怎么办MCP 工具调用会占用大量上下文。get_scene_hierarchy返回的层级结构在大型关卡里动辄几千行 JSON一次就把上下文吃掉了大半。我遇到过 Claude 聊了几轮之后开始“忘事”甚至工具调用参数错乱的情况。解决思路有两个方向。第一是轻量化给get_scene_hierarchy加一个depth参数只返回顶层对象或者加search参数按名字筛选。很多 Unity MCP 实现已经支持这类过滤了但默认还是全量返回需要你在调用时主动传过滤条件。第二是定期清理对话历史每完成一个阶段性任务就新开一个对话窗口不要在一个超长对话里连续干所有事。7.2 权限控制别忽视MCP 工具默认拥有引擎的大部分 Editor 权限这相当于给 AI 开了一个“上帝账号”。在个人项目里无所谓但在团队环境里要小心。建议至少做到两层控制第一层网络访问控制。MCP Server 默认监听127.0.0.1不要让它在外部网络暴露。如果办公环境有严格防火墙要确认端口策略不会导致内网其他机器也能连到你的编辑器。第二层操作白名单。在 Unity MCP 服务端做一层过滤比如只允许在指定文件夹下创建资产只允许修改场景内已有对象不允许删除 Scenes 目录等。代价是每次新增工具调用类型时都要同步权限规则但换来的是安全。7.3 性能调优批量调用永远好过逐个调用MCP 工具调用毕竟有网络和序列化的损耗逐个调用在大规模场景下会很慢。比如你让 AI 创建 50 个路灯如果它一个 one-by-one 地创建几十秒过去了。好的做法是在服务端提供一个batch工具接收一个命令数组一次性执行。我改造过 Unity MCP Server加了一个execute_batch工具参数是一个 JSON 数组每个元素对应一个工具调用。这样从 50 次网络请求压缩到 1 次耗时从 40 秒降到 5 秒左右。7.4 中文自然语言输入的小细节最后说一个中文环境下特有的问题全角标点。用户输入中文时经常带着全角括号“”和“”模型在解析时有时会把全角字符留在 JSON 的 key 里导致解析失败。我的方案是在服务端和提示词里都加一条规则所有输入先做统一的全角转半角处理再进入意图识别环节。同样的数字也可能被写成中文“一百八十”模型在槽位提取时要能正确转成 180。这个能力大模型本身是有的但需要在提示词里明确提示比如“数字请一律使用阿拉伯数字”。从去年年初第一次在终端里用自然语言调用 Unity 创建了一个方块到现在能比较稳定地通过 MCP 工具链让 AI 搭场景、调灯光、改材质、跑冒烟测试这个变化在时间线上不到两年。但上手时踩过的坑尤其是坐标系错乱、工具描述模糊、Play 模式断连这些估计每个走这条路的人都会经历一遍。我写这篇的时候刻意没有回避那些翻车细节因为工具链的价值从来不在教程截图里而在真实的报错信息和修复方案里。如果小白照着配置一遍就过一次成功那我反而会怀疑是不是漏了哪个关键步骤没写。MCP 工具链目前还有明显的粗糙感但方向已经很清楚游戏引擎的输入方式正在从 GUI 点击进入“自然语言 工具调用”混合驱动的时期。作为先走了一段的从业者我只能说值得折腾。 用自然语言驱动游戏引擎：Unity MCP与UnrealClaude实战指南
说出来可能有点夸张去年有半年我每天最烦的事就是在 Unity 里来回调参数。光照强度不对改一个 float物体位置偏了拖一下 Transform材质颜色不对再点开色板选半天。这些操作本身不难但架不住量多改一版要重复点几十下。当时我就想如果我能直接跟编辑器说一句“把主光源调暖一点、亮度降到 800”剩下的它自己搞定那该多好。2026 年回头看这个想法已经不稀奇了——Unity MCP、UnrealClaude 这批工具链正在把“用自然语言驱动游戏引擎”从玩具 demo 变成正经的日常开发方式。这篇东西基于我过去大半年在 Unity 和 Unreal 两边反复折腾 MCP 工具链的真实记录。包含完整配置过程、意图识别与槽位提取的原理拆解、工具链选型对比以及大量踩坑后的修正方案。适合三种人看想了解 MCP 在游戏开发里到底怎么落地的技术管理者打算给团队搭 AI 辅助开发流程的 TA 或工具链工程师以及单纯想在 Unity/Unreal 里试试“动嘴改场景”的独立开发者。看完不说能直接上生产至少能少走我走过的那些弯路。1. 先搞清楚MCP 在 AI 游戏工作流里到底解决什么问题1.1 从“AI 写代码”到“AI 动手改场景”前两年我们聊 AI 辅助游戏开发基本说的是“让 AI 写 C# 脚本”或者“让 AI 生成 Shader 代码”。这当然有用但有个很明显的瓶颈代码生成出来后你还得自己复制进工程、自己挂载组件、自己调参。繁琐的编辑器操作一样没少AI 只是帮我们写了一个“还没生效的半成品”。MCPModel Context Protocol模型上下文协议的出现改变了这件事。它本质上是给大模型开了一扇直通外部工具的门让模型不只输出文本还能通过一组标准化的工具接口去读场景、改属性、执行操作。游戏引擎的 MCP 服务端相当于一个翻译层把 Unity 或 Unreal 的编辑器内部 API 封装成一个个工具模型只需要知道“有这些工具可用、各个参数是什么意思”就能以函数调用的方式直接操作引擎。我打个比方。以前的 AI 像是一个资深顾问坐在你旁边给你出主意但动手的永远是你。接了 MCP 之后这个顾问直接接管了你的键盘鼠标你说一句“帮我把镜头拉近到主角背后”它自己就推摇杆去了。1.2 游戏编辑器和普通软件不一样接入成本要看这一点做过工具链的人都会有感觉给 IDE 接 MCP 相对容易因为 VS Code、JetBrains 都有成熟的插件体系和稳定的进程间通信方式。但游戏引擎完全是另一回事。Unity Editor 和 Unreal Editor 本质上都是 GUI 密集型应用程序场景视图、层级面板、Inspector、蓝图编辑器大量操作依赖“选中某个对象”——这个交互在 GUI 里是天经地义的事但在文本/工具调用接口里就变得很别扭。比如你让 AI 把场景里的一盏灯调亮它首先得知道灯光对象叫Spotlight (1)还得知道属性路径是Light.intensity更要知道当前编辑器处于什么模式。所以成熟可用的游戏引擎 MCP 工具链核心不在于“协议本身”而在于引擎侧到底暴露了哪些工具、工具之间的编排是否合理。这也是 Unity MCP 和 UnrealClaude 这类项目真正值钱的地方。它们不是简单地把 C# 或者 Python API 翻成 MCP 工具而是把编辑器操作重新建模了一遍把高频的、可脚本化的操作提取成一组经过设计的工具集。理论上这套东西适合所有游戏开发者但坦白讲目前最受益的群体是三种做程序化关卡原型的策划、在引擎里布置大量临时场景的 TA、以及需要快速做 AI 沙盒实验的研究人员。1.3 2026 年的 MCP 工具链生态现状简要版到现在游戏引擎 MCP 已经不是某一个项目的独角戏。Unity 这边有几个开源社区项目在维护核心功能覆盖场景对象 CRUD、材质替换、Play 模式控制、Prefab 操作等Unreal 那边则以 UnrealClaude 为代表走的是 Unreal Editor Python API 桥接路线。另外像 Cocos、Godot 也开始有人做 MCP 适配H5 游戏引擎如 Phaser 也有实验性的方案。整体生态处在“能用但没那么稳”的早期成熟阶段。我接下来的内容主要围绕 Unity MCP 和 UnrealClaude 这两条主线展开。2. Unity MCP 从零接进来配置过程与工具清单2.1 环境准备和插件安装先说环境。以我实测的频率看Unity 2022.3 LTS 和 2021.3 LTS 都跑过 Unity MCP建议用 2022.3 或更新的 6000.x 系列。太老的 2019/2020 版本会出现 API 兼容问题社区维护者也基本只往前看。安装方式以 Unity MCP 官方推荐的步骤为准拿到 MCP 项目的 Git 地址一般是 GitHub 上的仓库需联网访问。在 Unity 中打开Window - Package Manager点左上角加号选择Add package from git URL...把仓库地址粘进去。等待编译完成工具栏会出现MCP菜单。这个过程走完你会在项目里看到MCP相关的 Editor 脚本被挂进来。它本质是一个运行在 Unity Editor 内部的轻量级 HTTP 服务监听本地端口用 JSON-RPC 2.0 格式跟外部 MCP 客户端通信。默认端口每个项目略有差异常见的是 8765但我遇到过端口冲突的情况后面踩坑部分细说。2.2 Claude Desktop 侧的 MCP 配置在 Unity 编辑器这一侧MCP Server 运行后需要让 Claude Desktop 或兼容客户端知道怎么连接它。Claude Desktop 的全局配置在 claude_desktop_config.json 里Windows 路径一般是{ mcpServers: { unity-mcp: { command: npx, args: [ -y, unity-mcp-server ], env: { UNITY_EDITOR_PATH: C:/Program Files/Unity/Hub/Editor/2022.3.10f1/Editor/Unity.exe } } } }注意这里有一个经验点npx -y unity-mcp-server这个命令的作用是拉起一个 Node.js 编写的客户端桥接进程它负责跟 Unity 编辑器内的 MCP Server 通信。所以实际上你只需要保证 Node.js 环境可用、网络能拉到 npm 包。配置完成后重启 Claude Desktop在工具列表里就应该能看到unity_get_scene_info、unity_create_object这类工具名。看到工具列表的那一刻就意味着通信链路已经打通了。提示如果你用的是国内网络环境拉 npm 包的时候偶尔会超时可以把 registry 临时切到镜像源但注意不要影响日常开发的其他依赖。2.3 Unity MCP 提供哪些核心工具不同项目的工具命名会有差异但整体能力边界是比较一致的。下面列出我实际使用频率最高的一组工具按功能分类分类工具名称示例作用常用程度场景状态get_scene_hierarchy获取当前场景层级结构包括所有对象名和父子关系极高对象操作create_primitive创建 Cube、Sphere、Capsule 等基础物体极高对象操作modify_transform修改对象的 position、rotation、scale极高组件操作add_component给对象挂载 Rigidbody、Light、Camera 等组件高资源操作set_material_property修改材质颜色、金属度等参数高组件操作set_component_property修改已挂载组件的属性比如 Light.intensity高运行控制enter_play_mode/exit_play_mode进入/退出 Play 模式中文件操作create_asset_folder创建文件夹低有了这组工具大模型就能做很多事了。我实测过一通最简单的连续对话先让它看一下场景里有哪些物体然后让它把名为Cube的物体移动到 (3, 0, 3)再把主光源调亮到 1200。整个过程不到 30 秒换作手动操作至少一分钟起步而且不需要打开任何脚本文件。2.4 第一次用自然语言驱动的完整流程拿一个具体的命令串来说你可以直接在 Claude Desktop 里输入帮我看看当前场景里有什么。模型会调用get_scene_hierarchy返回一份 JSON 格式的层级列表。然后输入在 (0, 1, 0) 位置创建一个半径 0.5 的球体默认材质命名叫 TestBall。模型会先调用create_primitive传递primitiveType: Sphere、position: {x: 0, y: 1, z: 0}、scale: {x: 0.5, y: 0.5, z: 0.5}等参数。Unity 侧收到后直接生成物体。上面这个链路中间最关键的是 Unity MCP 服务端把 MCP 工具调用翻译成 Unity 的GameObject操作。只要你在 Scene 视图里看到新球出现就说明全链路已经走通了。3. 自然语言到引擎操作意图识别、槽位提取与 JSON 落地的关键设计3.1 先理解“意图”和“槽位”这两个词很多人第一次接触自然语言驱动引擎时容易被“AI 好神奇”带偏觉得是模型直接理解了 Unity 的 C# API。实际上真正起作用的是一套结构化的中间表示意图识别和槽位提取。意图intent指的是用户这条指令想干什么。槽位slot指的是完成这个操作所需要的具体参数。比如“在 (5, 0, 3) 位置放一个红色材质的立方体”意图是CreatePrimitive槽位有对象类型、位置坐标、材质颜色、是否需要碰撞体等。用 Python 做意图识别和槽位提取并不是只有 Rasa 那样的传统 NLU 框架才能做。在 MCP 场景下更简单可靠的方式是利用大模型自身的函数调用function calling能力让它把自然语言输出成一段严格的 JSON。用户输入: 在(5,0,3)的位置放一个红色材质的立方体 模型输出: { intent: CreatePrimitive, slots: { primitiveType: cube, position: {x: 5, y: 0, z: 3}, material: red } }引擎侧收到这个 JSON 后再做参数映射和 API 调用。这比用正则匹配可靠得多也比传统的槽位填充更鲁棒——因为面对“放个矩形”、“搞一个方块”、“我要个立方体”这类同义表达大模型都能收敛到同一个 intent 上。3.2 槽位输出最容易翻车的地方JSON 结构不匹配这个环节最值得展开说。理论上大模型输出 JSON 很自然但实际工程里问题不少。第一引擎端解析 JSON 的工具通常很死板。Unity 的JsonUtility对字段名大小写敏感而且要求字段名跟 C# 类严格对应。你让模型输出position但 C# 类里写的是Position直接就解析失败了。社区里很多 Unity MCP 服务端会做一层字段名映射但做不到 100% 覆盖。如果你是自己搭 MCP Server建议直接上 Newtonsoft.Json 或者 System.Text.Json并配置大小写不敏感的属性名匹配省掉这一堆问题。第二坐标和单位的“想当然”错误。大模型训练语料里关于 Unity 的知识通常是笼统的可能把 Unreal 的厘米习惯带入 Unity 的世界。比如让模型放一个 5 米高的柱子Unity 里 feed 过去可能是 500导致场景里突然出现一个擎天柱级别的物体。我的做法是在工具描述里明确标注“distance unit: meters”并且在服务端做一次范围钳制超过合理范围的数值自动报警。第三槽位缺失时要明确要求模型追问而不是猜默认值。比如用户说“放一个立方体”没说位置如果模型直接默认 (0,0,0) 就没问题但万一用户其实想放在某个物体旁边呢我在工具定义里会把 position 设为 optional并附加说明“如果未提供默认使用 (0,0,0)若用户询问建议先追问”。3.3 轻量 Python 终端 Agent 怎么实现意图-槽位-执行闭环除了在 Claude Desktop 里用现成客户端你也可以在终端里用自然语言操控游戏引擎。核心逻辑就三步收集用户输入 - 用大模型做意图识别槽位提取 - 调用引擎 HTTP 接口执行。我写过的最小可运行版本用 FastAPI 起一个本地服务再在终端里循环读取输入from openai import OpenAI import requests import json client OpenAI(api_keyyour-key, base_urlhttps://your-llm-endpoint) def nlu(user_input): resp client.chat.completions.create( modelqwen-plus, messages[{ role: system, content: ( 你是游戏引擎操作助手。将用户输入转换为JSON指令。 必须包含intent和slots两个字段。 intent只能是: CreatePrimitive, ModifyTransform, SetMaterial, PlayMode 之一。 ) }, { role: user, content: user_input }], response_format{type: json_object} ) return json.loads(resp.choices[0].message.content) if __name__ __main__: while True: cmd input(输入命令: ) parsed nlu(cmd) # 根据 intent 转发到 Unity MCP Server 的 HTTP 端口 requests.post( http://127.0.0.1:8765/api, json{tool: parsed[intent], arguments: parsed[slots]} )这个是示意代码实际使用还需要考虑上下文管理、多轮对话修正和错误重试。但核心思路已经足够说明自然语言驱动引擎的落地路径其实就是把“意图识别 - 槽位提取 - 工具调用”这条链路串起来MCP 只是让最后一步变得更加标准。3.4 工具描述怎么写才能减少模型幻觉大模型能不能准确调用工具很大程度取决于 tool schema 里的描述是否清晰。这个点很多做 MCP 工具链的人会忽视。描述写得模糊模型就会猜一猜就会错。我的几个经验每个参数的描述必须包含单位、坐标系、合法范围。比如position.y要写清楚“世界坐标米通常范围为 -500 到 500”。工具描述里要带上典型案例尤其是不常见的值。比如set_material_property里metallic取 1.0 表示完全金属0.0 表示非金属。对互斥参数要做说明。比如create_primitive里primitiveType和meshPath二选一模型如果同时给了服务端要能丢弃一个并记录日志。尽量少用抽象的词。不要写“调整光照氛围”要写“修改 Light 组件的 intensity 属性float 类型默认 1范围 0-8”。一句话MCP 工具链设计里最花时间的不是写服务端代码而是打磨工具描述。工具描述打磨得好模型调用的准确率会有非常明显的提升。4. UnrealClaude 的接入姿态Claude Python API 直接改关卡4.1 Unreal Editor 的脚本化基础Unreal 这边和 Unity 有一个很大区别Unreal Editor 官方就支持完整的 Python 脚本框架也就是 编辑器 PythonEditor Scripting Python。通过 Python 可以访问unreal模块里面包含EditorLevelLibrary、EditorAssetLibrary、EditorFilterLibrary等一系列操作关卡和资产的接口。这意味着接入 Claude 或其他大模型时不必像 Unity 那样专门写 C# 桥接而是可以直接用 Python 充当胶水层。UnrealClaude 这个方案的思路就是在本地跑一个 Python 进程它既作为 MCP Server 接收来自 Claude Desktop 的工具调用请求又通过unrealPython API 操作 Unreal Editor。实际架构如下Unreal 编辑器启动时需要开启“Enable Python Editor Script Plugins”插件并确保编辑器在启动时允许外部 Python 脚本连接。UnrealClaude 的 Python Server 进程启动后会把所有可用的 Unreal 编辑操作注册成 MCP 工具。Claude Desktop 通过 MCP 协议调用这些工具Unreal 编辑器内的场景、资产、蓝图就会跟着改变。4.2 部署时最容易卡住的环节UnrealClaude 的部署有几个坑点比 Unity 那边多一点。第一个坑是 Python 环境。Unreal 编辑器内置的 Python 解释器和你系统里的 Python 不一定是同一个。如果你用系统 Python 去跑 anaconda 环境而 Unreal 用的是自己的内置解释器两者之间没有直接关联。很多教程没提这一步导致你明明装了unreal模块运行却报 ModuleNotFoundError。正确做法是先找到 Unreal 安装目录下的 Python 解释器路径用那个解释器去安装依赖或者干脆在 UnrealEditor 的 Python 控制台里执行命令来验证import unreal是否成功。第二个坑是编辑器状态锁定。Unreal 编辑器在编译、加载资产、运行 PIEPlay In Editor时Python 脚本调用有可能被阻塞甚至会直接崩溃。从我的实际体验看UnrealClaude 每次执行完工具调用后最好强制延迟 0.2 到 0.5 秒让编辑器有足够时间刷新界面。不要连续快速调多个工具否则容易出现“命令发出去了但场景没变”的假象。第三个坑是资产路径大小写。Unreal 的资产路径/Game/Map/MyMap有严格的大小写规则而大模型生成的路径经常把首字母小写。我在 FModel 等工具里见过太多这种问题了。服务端要做一次路径规范化否则 Claude 会反复报 “Asset not found”而文件明明就在那里。4.3 用自然语言修改 Unreal 关卡的实际用例我拿一个真实用例来演示。有一次我要快速做一个夜景测试关卡需要的操作是在场景里放一盏点光源、把光源颜色改成偏暖、再把亮度调到 3000 勒克斯左右。在 UnrealClaude 的对话窗口里输入在关卡中放置一个 PointLight位置在 (500, 200, 300)光源颜色为暖橙色强度为 3000。UnrealClaude 这边的工具链路是这样的先调用get_actor_list获取当前关卡中已有 Actor 列表确认没有重名冲突。调用spawn_actor参数填actor_class: PointLight、location: (500, 200, 300)。调用set_actor_property参数填property_name: LightColor、value: (255, 180, 120)。再调用set_actor_property参数填property_name: Intensity、value: 3000.0。整个过程在对话界面看到的结果是模型连续调用了多个工具Unreal 编辑器里依次出现灯光、变色、变亮。这背后和 Unity MCP 的链路本质上一样只是 Unreal 的 Python API 面更广工具数量更庞大。4.4 UnrealClaude 能做什么不建议做什么UnrealClaude 的能力边界我用一张表说清楚能力现状建议创建/删除 Actor稳定适合搭建临时测试关卡修改 Actor Transform稳定高频使用修改材质参数较稳定注意资产路径问题蓝图节点创建有限支持复杂逻辑还是手动做蓝图连线不稳定不建议纯靠 AI 完成运行 PIE 并验证中等可以做基础冒烟测试坦白讲蓝图是 Unreal 的灵魂之一但蓝图图形化的本质决定了它不太适合被 MCP 工具化。Creating a blueprint node 是一回事把节点之间的连线、执行流、事件绑定全部文本化表示又是一回事。当前 UnrealClaude 对蓝图的处理比较有限复杂的游戏逻辑建议还是在编辑器里手写别为难 AI。5. Unity MCP 与 UnrealClaude 对比不是二选一是按需取用5.1 两条路线的本质差异把 Unity MCP 和 UnrealClaude 放一起看会发现它们不是简单的“同一个功能的双版本”而是两种不同的架构思路。Unity MCP 的代表性实现走的是 C# 扩展 本地 HTTP Server 的路线。它把 Unity 编辑器当成一个独立的服务端外部 MCP 客户端直接与之通信。优势是链路短、延迟低、和 Unity 的各类 API 结合紧密劣势是往往是社区项目维护引擎版本升级后容易出现兼容问题。UnrealClaude 走的是 Python 桥接路线。因为 Unreal 官方提供了 Python 脚本架构外部 Python 进程可以直接通过unrealAPI 操纵编辑器。优势是工具面广几乎覆盖面对象、资产、关卡的所有操作而且借助 Python 生态定制能力很强劣势是需要额外维护一个 Python 服务进程多了一层调用链稳定性稍差。下面这个表是我根据自己的使用体验做的综合对比不一定完全客观但很有参考价值维度Unity MCPUnrealClaude架构本质C# Editor 扩展 HTTP ServerPython 桥接 unreal 模块安装复杂度中Package Manager 安装偏高需要配 Python 环境工具覆盖面中等聚焦场景操作广覆盖资产、关卡、蓝图稳定性较稳但依赖 Unity 版本中等偶发编辑器锁死蓝图支持不适用有限多用户场景单机 Editor单机 Editor适合人群Unity 团队、TA、独立开发者Unreal 团队、关卡设计师扩展成本需要写 C#需要写 Python较灵活5.2 怎么选一个简单的判断标准要是看完对比还不知道选哪个我的建议是以你主力引擎为准。Unity 项目就用 Unity MCPUnreal 项目就用 UnrealClaude。道理很简单MCP 工具链目前还没有成熟到跨引擎通用的程度与其强行统一不如在单一引擎内先把流程跑顺。如果你是做 H5 2D 游戏开发的比如 Cocos、Phaser目前也有实验性的 MCP 方案但生态远不如 Unity/Unreal 成熟。如果你对这块感兴趣可以关注那些支持 HTTP 接口的 2D 引擎——比如基于 HTML5 的 Phaser 项目通过 Node.js 桥接 MCP 是可行的。5.3 混用场景Unity 和 Unreal 项目并行时的统一入口有的团队两个引擎都在用你可能想问能不能用一个统一的 MCP 客户端同时连 Unity 和 Unreal从协议层面讲完全可以。MCP 客户端支持配置多个 serverclaude_desktop_config.json里可以同时配unity-mcp和unreal-claude两个条目。模型会根据上下文自动选择调用哪个工具。我在自己的环境里就是这么配的打开 Claude Desktop 后它能看到两套工具列表在对话里说“Unity 场景”或“Unreal”即可明确指向。但实际使用要注意一点同一时间最好只开一个引擎的 MCP server。因为两个引擎的 MCP server 都需要监听本地端口如果端口冲突后启动的那个会默默失败。建议 Unity 用 8765Unreal 用 9876固定端口不要自动变化。6. 实战串联用自然语言二十分钟搭一个小场景含排查经验6.1 任务设定搭一个简单迷宫理论讲完看一个完整的实战。任务是用自然语言在 Unity 里搭建一个迷宫场景要求包括地面、墙体、若干锥体障碍物、一个主光源并让摄像机从高处俯瞰。我把对话命令按顺序列在这里按这位博主当时的实际执行顺序“创建一个平面命名 Ground位置 (0,0,0)大小 20x20。”“创建几个立方体作为墙体组成一个 10x10 的迷宫墙体高度 2厚度 0.5用白色材质。”“在迷宫中央放置两个红色的圆锥体。”“创建一个 Directional Light旋转角度让场景有立体阴影。”“把 Main Camera 移到 (0, 15, 15)让它俯视整个迷宫。”如果每一步都让 AI 自己去做它会调用create_primitive、modify_transform、set_material_property、set_component_property这些工具。大概 2 分钟左右就能在场景里看到雏形。剩下 18 分钟干什么呢打磨细节给墙体加碰撞体、调整灯光的颜色温度、给物体加一点随机旋转。6.2 实测中出现的三个典型问题这个流程看着顺畅实际执行时我至少踩了三个坑都有代表性。第一个坑批量创建物体时对象命名冲突。如果直接让 AI “创建 30 个立方体”它通常会生成Cube、Cube (1)、Cube (2)这样的名字层级面板一片混乱。解决方法是让 AI 按区块命名比如Wall_01、Wall_02并且在工具调用里显式传入名字参数。如果模型没有命名习惯也可以在 system prompt 里加一句“创建对象时始终使用有意义的前缀”。第二个坑坐标覆盖问题。AI 连续修改同一个对象时可能出现上一次调用的值把下一次覆盖掉的情况。比如它先设置了 Cube 的 position随后又设置 Cube 的 rotation但 pos 莫名变成了 (0,0,0)。我遇到的原因是模型在调用modify_transform时会把未提及的参数写成默认值。解决办法在工具定义里把 position、rotation、scale 拆成三个工具分别修改而不是一个工具带全部参数这样模型就不会乱填了。第三个坑Play 模式导致 MCP 连接中断。Unity 进入 Play 模式后Editor 资源重载MCP Server 的端口监听偶尔会断。如果你在 Play 模式下让 AI 改物体属性很可能工具调用成功但场景没变化。我的做法是凡是 MCP 控制的操作尽量在 Edit 模式完成进入 Play 模式只做验证不再发修改指令。6.3 一个值得参考的 AI 工作流组织方式经过这么多轮折腾我现在的工作流已经稳定成下面这个样子准备阶段手动规划好场景结构把需要 AI 做的任务拆成一条条可验证的命令。执行阶段让 AI 批量创建对象、设置位置、调材质。验证阶段切换 Play 模式观察游戏视图找出问题再切回 Edit 模式让 AI 修改。这条流程的关键在于AI 负责执行人类负责验收。不要让 AI 在一个没有明确验收标准的任务上长时间自主运行否则它容易陷入“以为做完了但到处是问题”的状态。我自己吃过亏所以特别强调这一点。7. 给后来者的几个工具链细节优化建议7.1 上下文窗口不够用怎么办MCP 工具调用会占用大量上下文。get_scene_hierarchy返回的层级结构在大型关卡里动辄几千行 JSON一次就把上下文吃掉了大半。我遇到过 Claude 聊了几轮之后开始“忘事”甚至工具调用参数错乱的情况。解决思路有两个方向。第一是轻量化给get_scene_hierarchy加一个depth参数只返回顶层对象或者加search参数按名字筛选。很多 Unity MCP 实现已经支持这类过滤了但默认还是全量返回需要你在调用时主动传过滤条件。第二是定期清理对话历史每完成一个阶段性任务就新开一个对话窗口不要在一个超长对话里连续干所有事。7.2 权限控制别忽视MCP 工具默认拥有引擎的大部分 Editor 权限这相当于给 AI 开了一个“上帝账号”。在个人项目里无所谓但在团队环境里要小心。建议至少做到两层控制第一层网络访问控制。MCP Server 默认监听127.0.0.1不要让它在外部网络暴露。如果办公环境有严格防火墙要确认端口策略不会导致内网其他机器也能连到你的编辑器。第二层操作白名单。在 Unity MCP 服务端做一层过滤比如只允许在指定文件夹下创建资产只允许修改场景内已有对象不允许删除 Scenes 目录等。代价是每次新增工具调用类型时都要同步权限规则但换来的是安全。7.3 性能调优批量调用永远好过逐个调用MCP 工具调用毕竟有网络和序列化的损耗逐个调用在大规模场景下会很慢。比如你让 AI 创建 50 个路灯如果它一个 one-by-one 地创建几十秒过去了。好的做法是在服务端提供一个batch工具接收一个命令数组一次性执行。我改造过 Unity MCP Server加了一个execute_batch工具参数是一个 JSON 数组每个元素对应一个工具调用。这样从 50 次网络请求压缩到 1 次耗时从 40 秒降到 5 秒左右。7.4 中文自然语言输入的小细节最后说一个中文环境下特有的问题全角标点。用户输入中文时经常带着全角括号“”和“”模型在解析时有时会把全角字符留在 JSON 的 key 里导致解析失败。我的方案是在服务端和提示词里都加一条规则所有输入先做统一的全角转半角处理再进入意图识别环节。同样的数字也可能被写成中文“一百八十”模型在槽位提取时要能正确转成 180。这个能力大模型本身是有的但需要在提示词里明确提示比如“数字请一律使用阿拉伯数字”。从去年年初第一次在终端里用自然语言调用 Unity 创建了一个方块到现在能比较稳定地通过 MCP 工具链让 AI 搭场景、调灯光、改材质、跑冒烟测试这个变化在时间线上不到两年。但上手时踩过的坑尤其是坐标系错乱、工具描述模糊、Play 模式断连这些估计每个走这条路的人都会经历一遍。我写这篇的时候刻意没有回避那些翻车细节因为工具链的价值从来不在教程截图里而在真实的报错信息和修复方案里。如果小白照着配置一遍就过一次成功那我反而会怀疑是不是漏了哪个关键步骤没写。MCP 工具链目前还有明显的粗糙感但方向已经很清楚游戏引擎的输入方式正在从 GUI 点击进入“自然语言 工具调用”混合驱动的时期。作为先走了一段的从业者我只能说值得折腾。