企业官网建设流程全解析

2026年，在游戏开发群里聊得最多的一个词，已经从“大模型能不能写代码”变成了“MCP准备好了没”。写代码环节里AI早就能干不少活了，但真正让人上头的，是让AI直接把手伸进Unity、虚幻引擎这些编辑器里干活：我今天只是想验证一个玩法想法，一句话下去，编辑器里已经帮你把临时关卡搭好、道具摆好、摄像机路径配好了。

MCP（Model Context Protocol）说白了就是给大模型配的一整套“操作手柄”。以前AI跟你聊得头头是道，但聊完它动不了手；现在通过MCP，AI可以调用编辑器里的各种接口和工具，你说的每句自然语言都能翻译成针对引擎的具体操作。对我这种既写代码又要盯玩法逻辑的人来说，这一步跨过去之后，整个开发节奏都变了。

这篇文章想分享的，就是从Unity MCP到UnrealClaude这一条完整工具链的落地经验。不管你是独立开发者、工作室技术负责人，还是刚转工具链方向的新人，只要你在用Unity或Unreal做内容，这套流程应该都有参考价值。以下内容都是我实际搭建和跑过的流程，包含踩坑记录和改进思路。

1. MCP工具链在游戏引擎里到底解决什么问题

1.1 MCP的三件套

MCP架构不复杂，和我之前写的设备桥接工具思路类似：一个服务端常驻，把能力暴露成工具列表；一个客户端拿着模型，按需调用。拆开看是这三块：

• MCP Server：跑在引擎编辑器进程里，负责接收请求，最终把请求转成引擎API。在Unity里，它通常是一个Editor插件加一个后台HTTP/WebSocket服务；在Unreal里，基本走Python Editor Script那一套。
• MCP Client：运行在大模型所在的程序里，比如Claude Desktop、Cursor，或者你自己用SDK封装的一个Agent。它负责理解用户指令，决定调哪个工具、传什么参数。
• 工具注册表：MCP Server启动后广播一份工具列表，每个工具包含名字、描述、输入参数的JSON Schema。模型不会看到引擎源码，它只看到这份清单。

这个设计起码有三个好处：第一，引擎侧不用知道大模型怎么工作，只做个标准接口；第二，模型侧不用关心引擎内部实现，只要拿工具名单做事；第三，安全边界天然存在——你可以只暴露某几个工具给模型，其他API全部锁死。

1.2 为什么2026年这件事才真正可用

MCP协议2024年底出现，当时大量MCP Server其实是“玩具级”的，开了服务但干不了实事。到了2026年，局面完全不一样，主要三个原因：

大模型上下文窗口变大。之前处理复杂场景图信息，聊个几十轮就撑不住了；现在能一次塞进几十个对象信息，并且能维持多轮工具调用的状态。引擎的可访问性也变强了，Unity 6把很多编辑器API整理得更便于外部进程调用，Unreal这边Python Editor Script也成熟不少，做插件的人不用再去踩一堆坑。再加上Agent执行稳定性明显提高，早期经常一个错误操作导致整个任务中断，现在可以重试、回滚、在编辑器里做诊断，工具调用失败的恢复成本低了很多。

所以现在才说“工具链”，而不是单一某个MCP插件。单独接一个Unity MCP，只是体验；把Unity、Unreal、Blender、Cocos那个生态全部串起来，那才是工具链。设计工具那边也一样，MasterGo、蓝湖这些平台都开始出MCP接口，本质都是同一个思路：让AI能直接操作你们已经在用的工具。

1.3 自然语言驱动相比传统自动化脚本的优势

特意对比一下，大家应该都写过Editor扩展脚本，传统方式是“写死流程、手动改参数、跑完看结果”。MCP + LLM的方式则完全不同：

我只说一个直观体验：以前做关卡布局验证，我写个脚本至少半小时；现在我跟AI说“中间放个圆形高台，周围错落摆六个掩体，给主摄像机绕场动画”，一分钟内就进Unity看效果了。这不只是快，关键是它把人从“反复改参数”里解放出来了。

2. 从零搭一套Unity MCP工具链

2.1 环境准备

先明确最低版本建议：

• Unity 2022.3 LTS或Unity 6，推荐Unity 6，因为编辑器API更稳定
• Python 3.10+，部分方案中的MCP Server宿主需要
• Node.js 18+，用于启动MCP Client的调试
• Claude Desktop或者Cursor这类支持MCP的客户端

如果你平时用Trae这类IDE，2026年基本也都支持自定义MCP Server了，操作逻辑类似。另外提醒一句，Unity安装时尽量选上“Windows Build Support”和“Developer Mode”相关模块，后面调试一些外部进程工具能少很多麻烦。

2.2 选型：Unity MCP Server两条路线

当前社区里主流的Unity MCP方案基本分两类。

第一类，纯C#编辑器扩展型。它直接跑在Unity进程内，把MCP服务嵌入编辑器，通过WebSocket监听。优点是部署简单，不依赖外部环境，能直接访问Unity的各种运行时API；缺点是你需要把端口暴露出去，且要小心编辑器主线程问题。

第二类，外部Python桥接型。Unity端只放一个转发插件，真正的MCP Server逻辑放在Python进程里。优点是方便扩展和维护，能复用Python生态的自然语言处理库；缺点是链路长了，排查问题多一个节点。

我的建议是：个人用、做原型验证，果断选第一类；如果是要做成多人协作的工具链，可以考虑第二类，方便做权限控制和请求日志。团队协作场景里，日志和审计比单人场景重要得多。

2.3 安装与启动

拿我用的一个C#方案举例，大体步骤是：

1. 在Unity Package Manager里选择“Add package from git URL”，填入项目仓库地址。
2. 等待编译完成，菜单栏会出现MCP相关入口。
3. 点开设置面板，确认端口号（比如8080），选择启动时是否自动开启服务。
4. 点Start Server，控制台会打印类似MCP server listening on ws://127.0.0.1:8080的日志。
5. 防火墙如果弹窗，选择允许访问；有些环境还需要在网络设置里允许回环访问。

接着在Claude Desktop里添加MCP Server配置：

{ "mcpServers": { "unity-mcp": { "command": "npx", "args": [ "-y", "@modelcontextprotocol/server-stdio" ] } } }

如果用的不是stdio方式而是Streamable HTTP，配置会变成：

{ "mcpServers": { "unity-mcp": { "type": "http", "url": "http://127.0.0.1:8080/mcp" } } }

以你实际安装的方案说明为准，不要照抄。配置完后重启一下客户端，让配置生效。

2.4 连通性自检

启动后，不要急着让它干活，先用低风险操作验证连通性。我会在客户端里直接问：

你能列出Unity MCP Server现在提供的所有工具吗？

模型如果正确返回工具列表，说明MCP Client和Unity MCP Server已经通了。一般你会看到类似这些工具：

• scene_get_active_scene
• object_create
• component_set_property
• material_assign
• asset_import
• scene_screenshot

这些工具其实就是后面自然语言和引擎之间的“抓手”。如果这一步都失败，后面所有操作都白搭，所以建议把它当成一个固定检查项。

3. 自然语言驱动Unity跑通一个小关卡

3.1 先搞懂自然语言怎么变成引擎操作

很多朋友第一次听“自然语言驱动游戏引擎”会以为有个黑魔法，其实背后逻辑并不玄乎。在MCP链路里，LLM承担了“意图识别 + 槽位提取 + 规划工具调用”的角色；如果你的Agent是自研的，没有强模型参加，那就需要用Python做一个意图识别模块，做槽位提取。

什么是槽位提取？就是一句话里抽结构化参数。比如：

在场景原点放一个长10米、高3米、厚0.5米的红色立方体，并在上方2米处加一个暖色点光源，再创建一个X轴来回移动的蓝色平台。

这句话里的“槽位”有：

• 意图：scene_builder
• object_type：Cube、Point Light、Cube
• position：(0,0,0)、(0,4,1)、(0,0.25,0)
• scale：(10,3,0.5)、(2,0.5,2)
• color：red、warm、blue
• animation_info：move_axis="X", amplitude="3", period="4"

在MCP Server层，通常不需要自己做NLP，因为模型已经把参数填进工具调用里；但如果你把MCP嫁接给一个轻量级内部Agent，那自己实现意图识别和槽位提取就很有必要了。Python里最简单的做法是维护一个槽位模板正则加一个槽位填充器，先用规则抽取数字、颜色词和动作词，再交给后续模块执行。这样做的好处是即使模型不擅长处理中文长句，你的自建Agent也能稳定拿到结构化参数。

3.2 实操：让AI搭一个带墙、带灯、带移动平台的小关卡

我实际在Unity里跑通过一个类似案例，直接复制下面这段需求给客户端就行：

帮我清空当前场景，在原点创建一面10米长、3米高、0.5米厚的红色立方体作为墙体，并在它上方2米处添加一个暖色Point Light，再创建一个在X轴来回移动的蓝色平台，平台大小2米见方，厚度0.5米。

Claude接到后，会先生成工具调用序列。它通常不会一次全做，而是分批执行。以我遇到过的一个典型执行日志为例：

第1步调用scene_clear，参数空。这一步清空场景，避免旧物体干扰。

第2步调用object_create，参数是类型Cube、位置原点、缩放[10,3,0.5]。Unity场景里立刻出现一个扁长的大方块。

第3步调用material_set_color，参数对象Wall，颜色[0.8,0.1,0.1]。墙体变为红色。

第4步调用light_create，类型Point Light，位置[0,4,1]，颜色[255,190,120]，强度800。暖色光源挂上去，场景气氛就起来了。

第5步调用object_create，创建移动平台Cube，位置[0,0.25,0]，缩放[2,0.5,2]，然后赋蓝色材质。

第6步调用animation_add_move_loop，参数平台名、X轴、幅度3米、周期4秒。平台开始来回移动。

整个过程大概十几秒，编辑器里就像有个人在帮你操作一样，逐帧出现结果。这就是自然语言驱动引擎的直观感受。

3.3 MCP Server端做了什么

关键细节在于：MCP Server收到这些请求后，并不会直接在监听线程里操作Unity对象。因为Unity的GameObject相关API几乎都有主线程要求，在WebSocket回调里直接访问会报错或者行为诡异。正确做法是把命令丢进一个队列，在EditorApplication.update里消费队列，回到主线程再创建对象。

有些方案为了绕开这个问题，会使用[UnityEditor.InitializeOnLoadMethod]注册生命周期回调，或者用EditorApplication.delayCall。无论哪种方式，原则就一条：引擎API调用必须回到主线程。

另外，每次工具调用返回，最好带上下文信息，比如新对象的世界坐标、ID、场景名称。模型要靠这些信息继续判断，如果返回太贫瘠，它就只能瞎猜。这一点在写MCP工具时很容易被忽略，但恰恰是决定交互稳定性的关键。

3.4 面向AI的自然语言操作技巧

我把这段时间用到的高频经验整理成几条：

• 数字、单位、颜色词不要省。说“来一堵墙”模型可能给个默认值，不如说清楚“长10米、高3米、红色”。
• 过于复杂的操作，拆成多个句子分步做。比如先布置场景再调灯光，最后加动画。让模型按步骤执行，成功率明显更高。
• 如果你发现模型重复打开同一个工具，可能是上次调用返回状态不够明确。检查MCP工具返回值里是否包含操作目标ID和当前场景状态。
• 在编辑模式下操作序列化资源（Prefab、ScriptableObject）时，记得先让模型确认资源路径，避免操作到错误副本。

对着屏幕看过几十次AI乱来的现场后，我越来越理解一个道理：不是所有东西都能丢给模型自由发挥。能提前用规则约束的，就提前约束住。

4. UnrealClaude：Unreal侧的自然语言工作流

4.1 UnrealClaude是什么

“UnrealClaude”并不是某个官方产品名，而是社区里对“把Claude这类大模型接入Unreal Editor”方案的通俗叫法。Unity侧大家习惯叫Unity MCP，Unreal侧就慢慢叫成了UnrealClaude。

原理上和Unity MCP一致：在Unreal Editor里跑一个服务端，暴露工具给MCP Client，让Claude能调用编辑器能力。具体到Unreal，最顺手的宿主是Python Editor Script Plugin加一个Socket监听。它能做的事情包括：

• 在关卡里SpawnActor并设置Transform
• 批量修改资产属性（材质、StaticMesh、贴图路径等）
• 读取关卡状态、执行Play-In-Editor测试
• 生成蓝图节点或修改简单蓝图属性
• 触发C++编译并获取结果

4.2 搭建Unreal侧的MCP服务

前提条件：Unreal版本建议5.3以上，Python Editor Script Plugin开启，项目里已经能跑Python脚本和命令行。

基础步骤：

1. 在Plugins菜单里启用Python Editor Script Plugin。
2. 用一个现成的Unreal MCP插件，或者自己写一个简单的Socket服务脚本。
3. 设置监听端口，比如9091，和Unity的8080区分开。
4. 在Claude Desktop里新增一条MCP Server记录，type选http或stdio，URL指向127.0.0.1:9091。

自己写一个最简服务思路是这样的（示意，不能直接用于生产）：

import unreal import socket import json sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.bind(("127.0.0.1", 9091)) sock.listen(5) def dispatch(line): cmd = json.loads(line) if cmd.get("tool") == "spawn_actor": world = unreal.EditorLevelLibrary.get_editor_world() actor = unreal.EditorLevelLibrary.spawn_actor_from_class( unreal.StaticMeshActor, cmd["location"] ) return {"ok": True, "actor": actor.get_name(), "location": cmd["location"]} return {"ok": False, "error": "unknown tool: " + str(cmd.get("tool"))}

真正放到项目里，这个脚本还要处理粘包、命令队列、主线程调用、权限校验等。这里主要是让大家看明白核心机制。我见过不少新手写完这个脚本直接运行，然后整个编辑器卡死，原因就是socket监听阻塞了主线程。

4.3 自然语言驱动蓝图的边界

关于Unreal，大家最关心的其实是蓝图。实测下来，直接让LLM逐个拖蓝图节点生成复杂逻辑，依然比较脆弱，很多时候生成的节点图连线是错的。我更推荐更稳的三条路线：

• 对简单蓝图，用Python API直接改蓝图属性，比如设置变量值、设置Actor位置、替换Mesh资源。
• 对中等复杂度操作，让LLM生成一个Python Editor Script，然后在MCP工具里执行这个脚本。
• 对重型逻辑，让LLM生成C++代码文件，通过MCP触发编译。编译完成后，再通过工具把新Class挂到Actor上。

这三条路线各有适用场景。我现在实际工作流里，前两条覆盖了90%的日常操作，第三条用于新增正式玩法模块。毕竟C++编译耗时摆在那，不适合用来做即时交互。

4.4 Unreal侧的关键注意事项

• Python脚本不要写在Socket阻塞循环里，编辑器UI会卡死。要用异步socket非阻塞模式，或把命令放到unreal.register_slate_post_tick里处理。
• SpawnActor前先确认当前是Editor世界还是PIE世界，别把测试Actor生成到错误世界。
• Unreal资产批量修改一定要做版本控制检查，一次修改太多资产，回滚很痛苦。
• LLM调compile_blueprint或者触发C++编译时，要让它等编译结束再继续，否则后续工具可能拿到旧信息。

Unreal的坑往往比Unity更隐蔽，因为编辑器封装层次多，报错信息不容易一眼定位。多花点时间在服务端日志上，其实比反复试prompt更管用。

5. 常见问题与排查

5.1 高频问题速查表

5.2 几条容易被忽略的排查经验

第一，MCP Server不要一上来就暴露全部工具。权限最小化原则，先暴露只读工具，比如scene_get、asset_list，等跑稳了再开放写操作。不然模型误操作一次，整个场景就乱了。我见过有人让Claude清理场景，结果它把整个场景文件里的序列化数据一并处理了，回滚花了两小时。

第二，日志非常重要。2026年的MCP Server工具基本都会带日志面板，但很多人不看。一旦出问题，先看服务端日志，确认请求有没有到引擎，这是排查的第一道分水岭。很多连接问题到最后发现就是端口配错，日志里写得很明白。

第三，LLM在工具状态连续交互时，偶尔会出现幻觉对象名称，比如它把“Wall”记成“Wal1”。解决办法是每个工具调用都返回最新对象列表摘要，或者让它先list再操作。别嫌这一步多余，它能帮你避免大量错改对象的问题。

最后说点个人体会

这套工具链最大的价值，不是让AI替我们写代码，而是把“在引擎里做实验”的门槛从“必须会写代码”降到了“会说话、会描述需求”。我在实际项目里，策划丢一个模糊想法过来，我先用自然语言快速搭个可跑的小关卡，跑Timeline感受节奏，有了感觉再让AI进一步细化或生成正式代码。这个流程放在两年前，还得靠我自己写一堆临时脚本，现在轻松太多了。

如果你正准备开始折腾，我建议先小范围试。别一上来就想着接管资产管线或者核心编译流程，先用Unity MCP做一个低风险的临时关卡搭建，验证稳定了，再逐步扩展到Unreal、Blender这些相邻工具链。把验证过的交互模板沉淀成团队内的标准prompt，效率还会再提一档。

最后再分享一个小技巧：平时用的最高频操作，比如“build_test_level”“generate_lighting_setup”这类，建议封装成独立MCP工具，比完全靠LLM自由发挥稳定得多。工具链这东西，用顺了会让人觉得引擎像是自己长了手。