最近一直在折腾三维场景程序化生成，最头疼的环节就是把 AI 写出来的脚本真正跑进 Blender 里。以前要么手动复制粘贴 bpy 代码，要么反复在编辑器、命令行、Blender 之间来回切换，效率低还容易出错。后来我把Blender 5.2.2 + MCP Server + VS Code Copilot这套链路完整搭了起来，AI 终于能直接在聊天框里操作 Blender 场景——让它建个房子、改个材质、导个模型，它自己就能调用工具完成，全程不用手动开脚本执行。
这篇文章不做铺垫，直接讲怎么从零装好整套环境，MCP Server 怎么启，VS Code 里怎么配 Copilot，以及实际跑起来会遇到哪些坑，我会把踩过的都写清楚。适合三类人看：一是想用 AI 辅助建模的 CG 从业者，二是在做自动化 3D 流水线的开发者，三是打算把 MCP Server 接进自己工具链的折腾型玩家。下面进入正题。
1. 项目整体思路与方案选型
1.1 这套组合到底能干什么
先说结论：它把“AI 生成提示词”升级成了“AI 直接操作现场”。你可能已经用 Copilot 写过 Blender 脚本，但那只是停留在代码层面——你还要自己把代码拿到 Blender 里运行、调试。而接上 MCP Server 之后，Copilot 不再只是写代码，它变成了一个“有手”的助手，能直接调用 Blender 场景内的工具，实时创建物体、修改参数、渲染输出。
拿我实际做的事举例。以前我导入一批地形 OBJ，要按高度重新分组、赋材质、导成 FBX 给引擎用，这个流程写脚本不算难，但每次调参要跑好几轮。现在 Copilot 开着 Agent 模式，我直接说“把当前场景中所有高度低于 0.5 的物体合并成组，命名为 ground，并赋予一个泥土材质，然后导出 FBX 到项目目录”。它会通过 MCP Server 依次调用工具：读取场景、遍历对象、设置分组、创建材质、执行导出，整个过程我可以看着 Blender 视口实时变化，哪里不对立刻口头纠正。
这套组合的核心价值，是解决了两个长期痛点。第一是上下文割裂：以前 AI 不知道 Blender 场景里到底有什么，要我把数据导成 JSON 喂给它；现在 MCP 工具直接带场景状态，AI 对“现状”有感知。第二是操作闭环：以前 AI 生成脚本后，执行错误还要回到对话里描述报错；现在 AI 执行完立刻能看到结果，自己能接着调。
1.2 为什么选 MCP Server 而不是别的方式
市面上的方案不少：直接用 CLI 跑脚本、写 HTTP API 给大模型调用、用 ComfyUI 的 API 接 Blender，各有各的问题。CLI 方式灵活但不给大模型反馈，大模型看不到场景状态，只能盲猜；HTTP API 方案稳定，但要自己维护一套服务；ComfyUI 那套其实是为了一个特定方向设计的，泛化性不够。
MCP Server 的优势在于，它是一个统一协议。MCP 全称 Model Context Protocol，可以理解成“AI 世界的 USB-C 接口”——客户端（Copilot、Claude Desktop、Cursor 这类）只要支持这个协议，就能直接对接任何实现了同样协议的服务器（文件系统、浏览器、设计软件、3D 引擎都行）。也就是说，这套配置不是一次性的，今天你用 VS Code Copilot，明天换 Claude Desktop，配置文件几乎不用动。这个标准化价值，在自动化工作流里非常重要。
另外，Copilot 对 MCP 的支持是内置的，不需要额外装插件，而且它能以 Agent 模式自主决策调用什么工具、传什么参数、按什么顺序执行，对话窗口就是控制台，这比命令行人机交互直觉得多。整套流程里“AI 决策 + MCP 调度 + Blender 执行”三个角色分得很清楚，出了问题也容易定位。
1.3 版本选择与兼容性考量
先说 Blender 为什么用 5.2.2。5.2 是当前大版本里综合体验比较稳定的一个迭代，新增了烘焙渲染器相关能力，几何节点和材质系统也有明显加强，对于程序化生成场景来说，节点工具链的更新比界面动画更重要。5.2.2 是 5.2 系列的有效维护版本，Bug 修复比较全面，用起来心里踏实。
再说依赖兼容性。MCP 生态里比较关键的是Blender MCP 插件，插件在运行时会通过 WebSocket/HTTP 暴露端口，Blender 侧需要能访问到。这个插件一般以 .py 文件形式提供，安装方式是在 Blender 偏好设置里 Install from Disk，不需要进入命令行。要注意的是，插件的版本要尽量匹配 Blender 主版本，有些老插件在 5.x 里会因为 API 变化报错。
Python 环境也要留意。Blender 自己内置了一版 Python，但 MCP 插件是运行在 Blender 内部进程中的，它依赖的库已经在 Blender 的 Python 环境里打包好了。外部 VS Code 侧的 MCP 配置，是通过 HTTP/WebSocket 连到 Blender 内的服务，所以根本不要求外部 Python 版本和 Blender 内置的一样——这一点避开了很多传统 bpy 调用方案的坑。简单说，外部环境只需要有能发起 MCP 请求的客户端即可，而 Blender 内部的依赖由插件全权管理。
2. 环境准备与工具链安装
2.1 Blender 5.2.2 安装与初始设置
Blender 安装没什么特别，到官网下载对应系统的安装包，Windows 双击安装包，macOS 把 .dmg 拖进 Applications，Linux 用发行版对应的包管理工具或直接解压 .tar.xz。装完以后打开一次，确认能正常启动，然后做两件基础设置。
第一件事，在 Preferences 里把Developer Extras打开。路径是 Edit -> Preferences -> Interface，勾上 Developer Extras。这个选项默认是关闭的，不开的话，后面有些 MCP 工具能调用但界面看不明显。第二件事，确认 Python Scripting 工作区存在，不需要额外启用。Blender 本来就内置 Python Scripting 工作区，MCP 插件安装之后要在这里或者侧边栏打开。
这里有一个细节，很多人忽略：插件安装完不会自动启用，要去 Edit -> Preferences -> Add-ons 里搜索关键词找到插件，勾选 Enable。同时还要注意 Blender 是否允许插件访问网络端口。Windows 首次运行可能会弹出防火墙提示，一定要允许专用网络的访问，否则后面连接全部失败。macOS 的话要注意系统设置里的本地网络权限。
2.2 MCP Server 侧的 Python 环境准备
虽然刚才说外部 Python 版本不是硬性要求，但为了调试方便，还是建议建一个干净的虚拟环境，用来跑 MCP Inspector 或者自己写的测试客户端。我推荐用uv，比 pip + venv 快一个数量级，隔离也更干净。
# 安装 uv（macOS/Linux 或 Windows 都行） curl -LsSf https://astral.sh/uv/install.sh | sh # 创建项目目录并进入 mkdir blender-mcp-project cd blender-mcp-project # 创建虚拟环境 uv venv # 激活虚拟环境 # macOS/Linux: source .venv/bin/activate # Windows: .venv\Scripts\activate然后装两个包：mcp官方 SDK 和一个用于查看 MCP 端点的工具。blender-mcp插件运行在 Blender 里，不需要装到外部虚拟环境，但mcp客户端库可以装一份，方便以后快速写测试脚本。
uv pip install mcp uv pip install websockets这里别急着装bpy。很多人习惯 pip 装 bpy，但 Blender 5.2.2 的 PyPI 版本可能不会同步更新到最新，而且我们要用的是 Blender 内置扩展环境，外部装 bpy 意义不大，反而可能因为版本不一致引入混乱。
2.3 目录结构与配置文件规划
项目目录我习惯这样组织，清晰又好维护：
blender-mcp-project/ ├── .venv/ # 外部虚拟环境 ├── scripts/ │ └── test_client.py # 测试 MCP 连接的脚本 ├── .vscode/ │ └── mcp.json # VS Code 的 MCP 配置 └── README.md这个结构的关键在于，把“外部客户端”和“Blender 内置服务”明确分开。配置 VS Code 连接的时候，你填的都是http://127.0.0.1:9876/sse这种地址，而不是某个脚本路径，所以外部目录里不需要放插件代码，插件我就放在 Blender 的自动加载目录里。
Blender 插件目录的位置，在 Preferences -> File Paths 里能看到，一般是C:\Users\<用户名>\AppData\Roaming\Blender Foundation\Blender\5.2\scripts\addons这种。插件作者一般会在安装说明里告诉你放哪个版本目录，或者通过 Install from Disk 让它自动放到正确位置。
3. MCP Server 搭建与 Blender 初始化
3.1 理解 MCP Server 在 Blender 里的角色
画一条线帮你想清楚整体链路：
VS Code (Copilot) │ │ MCP 协议 (HTTP + JSON-RPC) ▼ Blender MCP Server（运行在 Blender 插件里） │ │ 调用 bpy API ▼ Blender 场景 / 渲染器 / 文件系统重点在这条链路的上半部分：MCP Server 不是独立进程，它是寄生在 Blender 内部的插件。插件启动后监听本地端口，等待外部客户端连上来。Copilot 通过 VS Code 的 MCP 配置知道有这个服务存在，然后就能调用它提供的 tools。
MCP 协议有几个核心概念：tools（工具，AI 能调用的操作）、resources（资源，AI 能读取的数据）、prompts（提示词模板）。Blender MCP 插件主要暴露的是 tools，比如create_object、select_object、modify_material、render_image这些。每次调用，客户端发一个 JSON-RPC 请求，服务器执行 bpy 操作，返回结构化结果。AI 看到结果后再决定下一步做什么，这就是 Agent 模式的基本运行方式。
这个设计有一个特别舒服的地方：返回结果是结构化的，不是终端日志。插件返回的是 Python 字典序列化后的 JSON，里面包含“操作是否成功”“生成了几个对象”“对象叫什么名字”这类信息。Copilot 读到这些信息，能直接影响后续推理，而不是像看命令行输出一样还要做文本解析。
3.2 启动 MCP Server 与验证连接
先下载 Blender MCP 插件。我用的是社区维护比较活跃的版本，直接在 GitHub 上搜关键字，通常能找到一个blender-mcp.py文件。下载后不要解压，打开 Blender 的 Preferences -> Add-ons，点击右上角的下拉箭头，选择Install from Disk，选中这个 .py 文件，然后启用插件。
启用后，在 Blender 侧边栏（按 N 键展开右侧面板）找到 MCP 相关的标签页，点击Start MCP Server。日志区会显示：
MCP Server started at ws://127.0.0.1:9876看到这个就说明服务起来了。不同插件的端口可能有差异，有的是 9876，有的是 8765，注意看日志，别死记端口。
接着在外部虚拟环境里跑一个测试脚本，确认网络层通不通：
# test_client.py import asyncio from mcp import ClientSession, StdioServerParameters async def main(): # 这里只是验证能不能连上本地端口 # 实际连 SSE 端点的代码如下 from mcp.client.sse import sse_client async with sse_client("http://127.0.0.1:9876/sse") as (read, write): async with ClientSession(read, write) as session: await session.initialize() tools = await session.list_tools() print("已连接 MCP Server，工具列表：") for tool in tools.tools: print(f"- {tool.name}: {tool.description[:50]}") asyncio.run(main())跑通之后会列出一大堆工具名，这就算服务器搭好了。我当时第一次跑通的时候，看着它列出十几个工具，有一种“这玩意真的活了”的感觉。
3.3 自定义 MCP 工具的边界
Blender MCP 插件默认提供的工具，覆盖了大部分基础操作：创建立方体/球体/平面/网格、修改位置旋转缩放、切换视图模式、导入导出主流格式、设置材质、调用渲染。但真实工作流里总有特殊需求，这时候有两个办法。
第一个办法是直接在插件源码里改，加自定义 tool 装饰器。很多插件是仿照 FastMCP 或者官方 MCP SDK 的写法写的，你在插件文件里能看到类似这样的模式：
# 插件内部源码结构示意（实际插件使用 Blender 内置 handler） @MCPTool("create_terrain_plane") def create_terrain_plane(size: float = 10.0, verts: int = 64): bpy.ops.mesh.primitive_plane_add(size=size) obj = bpy.context.active_object # 细分网格生成地形… return {"status": "ok", "object": obj.name}第二个办法是配置一个“允许执行的 Python 代码块”工具。有的 Blender MCP 插件带execute_code之类的功能，AI 可以直接发一段 bpy 代码让你执行。这个功能非常强大，但也非常危险，后面第五节我会说安全设置。
我这里强烈建议：默认把execute_code这类工具关掉，或者至少加上手动确认机制。原因很简单，AI 一旦拿到完整 bpy 执行权限，它既能让场景变成艺术品，也能一键清空你的所有对象。工作流里加一道确认，比事后备份划算得多。
4. VS Code Copilot 接入与联动配置
4.1 在 VS Code 中配置 MCP Server
VS Code 对 MCP 的支持已经非常成熟了，不需要装额外的扩展（如果你用的是新版自带 Copilot 的 VS Code，MCP 面板是内置的）。配置方法是打开命令面板（Ctrl+Shift+P 或 F1），输入MCP: Configure MCP Servers，选择这个命令后会打开一个mcp.json文件。
如果你是第一次配置，文件里可能只有基本结构。照着下面填：
{ "servers": { "blender-mcp": { "type": "sse", "url": "http://127.0.0.1:9876/sse", "enabled": true } } }写完保存。然后打开 Copilot Chat 面板，在左下角或设置区域检查 MCP Server 是否已连接。这里有个常见坑：万一保存后没有自动重载，打开命令面板运行MCP: Restart Server或者让 VS Code 重新加载窗口（Developer: Reload Window）。
4.2 在 Copilot Agent 模式下调用 Blender
配置好之后，正常使用 Copilot 的代码补全还是老样子，真正让 AI 操作 Blender，要切到Agent 模式（有的版本叫代理模式）。在 Copilot Chat 右上角选择 Agent，然后在对话里说出你的需求。
我实测过一个完整流程，对话大致是这样的：
我：当前 Blender 场景里新建一个立方体，把它命名为“box_test”，旋转 45 度，设置成红色材质。
Copilot 会调用 MCP 工具，先调用create_object，传入{"object_type": "CUBE", "name": "box_test"}；再调用set_object_transform，传入位置旋转参数；接着调用set_material，传颜色值。每一步都会在 Blender 里真实执行，视口能看到立方体出现、旋转、变色。
这个过程中，我全程没有碰 Blender 的快捷键，也没复制过代码。Copilot 的窗口里能看到它每一步调用了什么工具，参数是什么，对应执行结果是什么。出了问题，比如材质颜色报错，它会自己尝试修正参数再调用一次。
4.3 提示词设计与指令规范
和 AI 对话操作 Blender，和写自然语言聊天完全不一样，它需要的是可执行的、带约束条件的指令。经验之谈，有几点很重要：
第一，每次指令聚焦一件事。不要说“帮我建一个场景，要有山有水有树”，而要拆成“先创建地面平面”“再生成一组山体网格”“然后在坐标 (2, 2, 0) 处放置一棵树模型”。MCP 工具是单步操作，AI 需要清晰的子目标才能编排好顺序。
第二，给明确参数。指定尺寸、坐标、命名、材质类型，越具体越好。比如：
在坐标 (0, 0, 0) 创建一个半径为 2 的 UV 球体，细分级别设成 4，命名为 sphere_main，材质设为玻璃材质（折射率 1.45）。第三，重要操作前加“请确认”。虽然 Copilot 里可能没有内置确认环节，但你可以用语言要求它在执行删除、清空、覆盖文件之前先报告计划。这样至少能在对话层面形成一道心理防线。
第四，利用 MCP 的反馈循环。AI 执行完一个操作会返回结构化信息，你可以在对话里追问“现在场景里有多少个物体”“最新创建的物体叫什么”，它能准确回答，因为这些信息直接从 Blender 场景里读出来，不是猜的。
我实际用下来的体感是：最舒服的工作流是“AI 批量修改 + 人工眼神验收”，快速做重复性修改（改一百多个物体命名、统一贴图通道、批量导格式），AI 是神；但从一片空白去“创作”，它还需要你给足约束，不然会把场景搞得乱七八糟。
5. 常见问题与排查技巧实录
5.1 MCP Server 启动失败类问题
这个问题花样百出，我按频率排个序。
插件安装后找不到在哪里开启。大多是因为没有启用插件，回到 Add-ons 列表搜索插件名，确认已经勾选。注意 Blender 界面里启用了插件之后，侧边栏可能要新建一个窗口（鼠标移动到窗口边缘出现十字光标时拖出来），或者在现有窗口的 Viewport Overlays 旁边的侧边栏里找。
启动时提示端口被占用。Blender 的 MCP 插件默认监听 9876，如果你之前跑过另一个实例（或者其他程序占了端口），就会启动失败。解决办法是关闭其他占用进程，或者在插件设置里换一个端口（比如 9877），同时同步修改 VS Code 的 mcp.json 里的端口。前后要一致，这是个经常遗漏的细节。
启动后立刻崩溃或无响应。大概率是 Blender 版本和插件不兼容。有些插件是针对 4.x 写的，在 5.x 里因为 API 变化出问题。这时候检查插件作者的发布说明，看是否支持 5.2，不支持的话找替代插件或者手动改兼容代码。还有一个冷门原因：Blender 没有写入插件日志目录的权限，Windows 上跑在公司域环境容易出现，右键 Blender 用管理员权限试试。
5.2 连接与调用异常类问题
VS Code 显示连接不上。按顺序检查：第一，Blender 里的 MCP Server 是否还在运行，窗口最小化有可能让后台脚本暂停（尤其是 macOS），把 Blender 窗口恢复出来；第二，mcp.json 的 url 是不是和插件日志里的地址完全一致，包括协议（http 还是 ws）和端口；第三，防火墙有没有放行本地端口。这个问题解决率有九成。
连接成功但工具列表为空。这种情况，通常是 MCP 服务器连上了，但 Blender 侧的场景句柄还没初始化好。尝试在 Blender 里随便动一下场景（新建一个立方体再删除），回到 Copilot 面板执行 MCP: Restart Server。有遇到过一次插件触发异步 bug，重启才恢复。MCP 服务看着是好的，但工具注册不完整，这种“假成功”比较难查。
Copilot 说找不到需要的 Blender 工具。打开 VS Code 的 MCP 面板看工具栏数量，如果能看到工具名，但对话里 Copilot 调用时找不到，可能是工具名拼写差异（比如create_cube和add_cube就是两个不同的东西）。你可以在对话里直接问“你有哪些 Blender 工具”，它能根据 MCP 的 schema 告诉你准确名称。这个方式屡试不爽。
5.3 模型操作与安全类问题
AI 执行了危险操作（比如删除全部对象）。我建议在插件设置里找有没有类似的权限开关，把删除类操作设为手动确认。如果没有，就在对话约束里加一句“所有删除操作前必须征求我的同意”。这里还有个土办法：在 Blender 里定时保存恢复文件（File -> Recovery），或者跑脚本定期备份 .blend 文件，不然一次误操作可能损失几小时的工作。
AI 执行操作很慢。Blender MCP 的每一次工具调用，在场景复杂时会产生较大的上下文开销，传输和反序列化都很占时间。缓解办法是减少无关物体数量，或者给 AI 的工具调用设置超时时间，避免它反复尝试同一个失败操作。另外，尽量不要同时开着多个 MCP 连接（比如 VS Code 和 Claude Desktop 同时连同一个端口），会有抢占问题。
外部 Python 环境导包失败。如果你按网上很多老教程用 pip 装 bpy，会踩到版本坑。Blender 5.x 的 bpy 包在 PyPI 上滞后严重，装了可能会出现bpy.context损坏的报错。现在正确的姿势就是：不用外部 bpy，让插件在 Blender 内部执行。记住这条原则，能少掉很多头发。
5.4 变更管理
这个问题单独拿出来说，因为做自动化 3D 流程最怕“改了代码，结果发现是旧配置”。MCP Server 的配置、插件版本、Blender 版本、VS Code 版本，这四者只要有一个变更，整个链路就可能断。我自己的做法是：把 mcp.json 和插件版本写进项目 README，每次升版本都记录；升级 Blender 大版本前，先在测试项目里试跑一遍典型工具调用，确认无误了再切主项目。还有一个小技巧：Blender 插件旁边通常有日志输出面板，把日志级别调成 DEBUG，正常跑一次就能看到所有通信细节，排查问题事半功倍。
6. 实操心得与扩展方向
整套环境搭完到现在，我最大的感受是：它真正改变了人和 3D 软件的交互方式，但前提是你得把规则定清楚。MCP Server 和 Copilot 只是工具，真正决定工作流顺不顺的，是你能不能把需求拆解成 AI 能逐步执行的颗粒度。这有点像带实习生：你把任务说清楚，它能干得很好；你丢一句“随便弄弄”，它就还你一个随便的结果。
有一个小技巧值得分享：遇到重复性高的序列操作，与其让 AI 自己一步步调用基础工具，不如自己写一个组合工具。比如把“导入模型 -> 清除原始材质 -> 赋予标准材质 -> 改名 -> 导出子目录”封装成一个工具，给 Copilot 的提示里直接说“用 batch_import 处理这批文件”，效率能提升一个量级。MCP 的标准化接口让这种封装非常轻松，这也是下一步我会继续深挖的方向——把更多 Blender 工作流固化成可复用的工具集。
如果你也打算把 AI 接入 Blender，我建议你先从最简单的单物体操作开始，循序渐进地测试基础链路和权限边界，确保它在你手里成为生产力工具，而不是一台“能一键清空场景的失控机器”。等到环境稳定了，你会发现原本要一小时手工完成的流程，现在压缩到几分钟，而且不太容易出错——这就是这套组合最迷人的地方。
