1. 项目缘起：为什么我要用 Blender MCP 搭一个智慧仓储数字孪生

第一次听到“数字孪生”这个词，是在一个做仓储物流的朋友那里。他当时跟我吐槽，说他们仓库里几千个货位，每天靠人工盘点，效率低不说，还经常出现“系统显示有货、实际找不到”的尴尬情况。后来他们上了一套可视化系统，屏幕上能看到整个仓库的三维模型，每个货架、每个托盘的状态都实时更新，哪个区域拥堵、哪个货位空了，一目了然。我当时就觉得，这东西有点意思。

那个可视化系统，本质上就是一个数字孪生的雏形。数字孪生说白了，就是在电脑里建一个和现实世界一模一样的“双胞胎”，现实中的设备动一下，电脑里的模型也跟着动；电脑里模拟出来的方案，也能反过来指导现实中的操作。智慧仓储是数字孪生落地最成熟的场景之一，因为仓库本身就是一个高度结构化的空间，货架、通道、堆垛机、AGV 小车，这些东西的位置和状态都是可以被精确描述的。

但问题来了：传统做数字孪生，要么用 Unity、Unreal 这类游戏引擎，要么用 Three.js 自己撸一个 Web 端的三维场景。前者学习曲线陡峭，后者对建模和渲染的要求又很高。我一直在找一个更轻、更快的路径，直到我接触到了Blender MCP这套组合拳。

Blender 不用多介绍，开源三维建模的标杆，建模、材质、动画、渲染一条龙。MCP 是 Model Context Protocol 的缩写，简单理解就是一套让 AI 助手能够直接操控外部工具的协议。把 Blender 和 MCP 接在一起，意味着我可以用自然语言描述需求，让 AI 帮我在 Blender 里自动完成建模、摆放、材质赋予这些重复性劳动。而Antigravity在这个流程里扮演的是“调度中枢”的角色，负责把 AI 的指令翻译成 Blender 能听懂的操作。

这套组合最吸引我的地方在于：它把“建模”这件事的门槛从“你得会 Blender”降到了“你得会说人话”。对于做数字孪生来说，仓库里的货架、托盘、通道，都是高度重复的标准化物体，用 AI 批量生成再合适不过。这篇博文，我就把整个搭建过程拆开揉碎讲清楚，从环境准备到第一个货架落地，每一步都附上我实际踩过的坑和验证过的参数。

2. 整体设计思路：为什么是 Antigravity + Blender MCP 这套组合

2.1 数字孪生的三层架构在仓储场景里怎么落地

数字孪生这个概念听起来很玄，但拆开来看就是三层：数据层、模型层、交互层。数据层负责采集现实世界的信息，比如货架上的 RFID 标签、AGV 的位置坐标、温湿度传感器的读数；模型层就是那个三维的“双胞胎”，把数据映射成看得见的物体和状态；交互层则是用户能操作的部分，比如点击某个货架查看库存、拖动时间轴回放昨天的作业流程。

在智慧仓储场景里，这三层的具体落地是这样的：

• 数据层：WMS（仓储管理系统）提供库存数据，IoT 网关提供设备状态，UWB 定位提供 AGV 实时坐标。这些数据通常以 JSON 或 MQTT 消息的形式流出。
• 模型层：用 Blender 建立仓库的静态结构（货架、地面、墙体、通道），再用脚本驱动动态物体（AGV、堆垛机、托盘）的位置和状态。
• 交互层：可以是 Blender 内部的实时预览，也可以导出到 Web 端用 Three.js 渲染，甚至可以用 Blender 的 Eevee 引擎直接做实时渲染输出。

我选择 Blender MCP 作为模型层的核心工具，原因很简单：Blender 的 Python API 极其强大，几乎任何操作都能用脚本完成，而 MCP 让 AI 能够直接调用这些脚本。换句话说，我不需要手写每一行 Python 代码，只需要用自然语言描述“在坐标 (10, 5, 0) 放一个 2 米高的货架”，Antigravity 就能通过 MCP 把这个指令转成 Blender 的bpy操作。

2.2 为什么不用 Unity 或 Three.js 直接做

这个问题我被问过很多次。Unity 做数字孪生确实成熟，Asset Store 里有大量现成的仓库模型和脚本，实时渲染效果也好。但 Unity 的问题在于：建模和场景搭建是分离的。你通常需要在 Blender 或 3ds Max 里建好模型，导出 FBX，再导入 Unity 摆放。这个流程对于需要频繁调整布局的仓储场景来说，太笨重了。

Three.js 更轻，但它的强项是渲染，不是建模。你要在 Three.js 里从零建一个货架，得用 BoxGeometry 一个个拼，材质、光照、阴影都得自己调。对于复杂的仓库场景，代码量会爆炸。

Blender MCP 的优势在于建模和脚本在同一个环境里。我可以在 Blender 里用 AI 生成货架模型，立刻用脚本把它复制 200 份摆到指定位置，再实时预览效果。如果布局不对，改一句描述重新生成就行。这种“描述即建模”的体验，是传统流程给不了的。

2.3 Antigravity 在流程里到底干什么

Antigravity 这个名字听起来很科幻，但它的角色其实很务实：它是一个 AI 助手的运行环境，负责理解我的自然语言指令，然后通过 MCP 协议调用 Blender 的工具接口。你可以把它想象成一个“翻译官”，一边听我说“把货架往左移半米”，一边把它翻译成 Blender 能执行的bpy.ops.transform.translate(value=(-0.5, 0, 0))。

这里有个关键点：Antigravity 本身不建模，它只是调度。真正的建模逻辑还是跑在 Blender 里的。所以整个流程的稳定性，取决于 MCP 协议能不能准确地把指令传达到位。我实测下来，对于“创建物体”“移动物体”“修改材质”这类基础操作，准确率很高；但对于“把这个货架设计得好看一点”这种模糊指令，AI 就无能为力了。所以我的经验是：指令要具体，参数要明确，别让 AI 猜你的审美。

3. 环境准备：Blender MCP 服务端与 Antigravity 的对接细节

3.1 Blender 侧的 MCP 插件安装与配置

Blender 本身没有内置 MCP 支持，需要装一个插件。我用的版本是 Blender 4.2 LTS，插件从 GitHub 上的blender-mcp仓库获取。安装步骤不复杂，但有几个细节容易翻车。

第一步，确认 Blender 的 Python 环境。Blender 自带了一个 Python 解释器，路径通常在安装目录/4.2/python/bin/python.exe（Windows）或/Applications/Blender.app/Contents/Resources/4.2/python/bin/python3.11（macOS）。MCP 插件需要依赖mcp这个 Python 包，所以得先在这个 Python 环境里装好。

我一开始图省事，直接用系统的 pip 装了mcp，结果 Blender 里死活导入不了。后来才发现，Blender 的 Python 是独立的，必须用它的解释器来装。命令是这样的：

# Windows "C:\Program Files\Blender Foundation\Blender 4.2\4.2\python\bin\python.exe" -m pip install mcp # macOS /Applications/Blender.app/Contents/Resources/4.2/python/bin/python3.11 -m pip install mcp

装完之后，在 Blender 的偏好设置里找到“插件”选项卡，点击“从磁盘安装”，选择下载好的blender_mcp.py文件。启用插件后，Blender 的侧边栏会出现一个 MCP 面板，里面有一个“启动服务”的按钮。点击之后，Blender 会在本地开一个 WebSocket 服务，默认端口是 9876。

注意：如果你的电脑上装了防火墙或者安全软件，可能会拦截这个端口。我第一次启动时，Windows Defender 弹了三次警告，必须手动放行才能让 Antigravity 连上。

3.2 Antigravity 侧的连接配置

Antigravity 这边需要配置一个 MCP 服务器的地址。在它的设置文件里，找到mcp_servers这个字段，添加一条记录：

{ "mcp_servers": { "blender": { "url": "ws://localhost:9876", "type": "websocket", "timeout": 30000 } } }

这里的timeout我设了 30 秒，因为 Blender 在执行复杂建模操作时可能会卡住几秒，如果超时太短，Antigravity 会误判为连接失败。实测下来，30 秒对于大多数操作都够用，除非你要一次性生成上千个物体。

配置完成后，重启 Antigravity，在对话窗口里输入一句“列出 Blender 场景中的所有物体”，如果能看到返回结果，说明连接成功了。如果报错，先检查 Blender 的 MCP 服务是否在运行，再检查端口是否被占用。

3.3 版本兼容性：我踩过的三个坑

第一个坑是 Blender 版本。我一开始用的是 Blender 3.6，结果 MCP 插件里的某些 API 调用不兼容，报了一堆AttributeError。后来换成 4.2 LTS 就正常了。所以建议至少用 4.0 以上的版本。

第二个坑是 Python 版本。Blender 4.2 自带的是 Python 3.11，而mcp包要求 Python 3.10 以上，这个没问题。但如果你用的是更老的 Blender，自带的 Python 可能是 3.9，那就装不了最新版的mcp，得降级到旧版本。

第三个坑是网络环境。Antigravity 和 Blender 必须在同一台机器上，因为 MCP 走的是本地 WebSocket。如果你想跨机器连接，得把localhost换成局域网 IP，但这样会有延迟，对于实时性要求高的操作不太合适。

4. 仓库静态结构建模：从地面到货架的完整流程

4.1 用自然语言描述仓库布局

环境搭好之后，第一件事是建仓库的“壳”。一个典型的智慧仓储场景，静态结构包括：地面、四面墙、货架阵列、通道、充电桩、分拣台。这些东西的位置和尺寸，通常可以从仓库的 CAD 图纸或者 WMS 的库位数据里拿到。

我手头的仓库数据是这样的：长 60 米，宽 40 米，高 8 米。货架是双排背靠背布局，每排货架长 20 米，深 1.2 米，高 6 米，分 4 层。通道宽度 3 米。这些数据我先整理成一个 JSON 文件，方便后续脚本读取：

{ "warehouse": { "length": 60, "width": 40, "height": 8 }, "rack": { "length": 20, "depth": 1.2, "height": 6, "levels": 4, "rows": 6, "columns": 2 }, "aisle_width": 3 }

然后在 Antigravity 的对话框里输入：“根据 JSON 文件里的参数，在 Blender 里创建仓库地面和四面墙，地面用灰色材质，墙用半透明蓝色。” Antigravity 会通过 MCP 调用 Blender 的bpy.ops.mesh.primitive_plane_add和bpy.ops.mesh.primitive_cube_add来生成这些基础几何体。

这里有个细节：Blender 默认的单位是米，所以直接输入 60、40 这些数值就行，不需要换算。但如果你从 CAD 图纸拿到的数据是毫米，记得先除以 1000。

4.2 货架模型的参数化生成

货架是仓库里数量最多的物体，也是最需要参数化生成的。一个标准的横梁式货架，结构包括：立柱、横梁、层板、斜撑。如果手动建模，一个货架至少得花十几分钟，200 个货架就是几十个小时。用 Blender MCP，我只需要描述清楚参数，AI 就能批量生成。

我的做法是：先让 Antigravity 生成一个“母版”货架，确认尺寸和比例没问题后，再用脚本复制。生成母版的指令是这样的：

“创建一个货架模型，长 20 米，深 1.2 米，高 6 米，分 4 层。立柱用 0.1 米见方的方管，横梁用 0.08 米高的矩形管，层板厚度 0.02 米。材质用橙色金属漆。”

Antigravity 收到指令后，会调用 Blender 的bpy.ops.mesh.primitive_cube_add创建各个部件，然后用bpy.ops.object.join合并成一个物体。这里有个技巧：立柱和横梁的尺寸要精确到厘米级，因为数字孪生对尺寸的准确性要求很高，如果货架尺寸和现实不符，后续的数据映射会出问题。

母版生成后，我用一段 Python 脚本把它复制到指定位置。脚本的核心逻辑是：

import bpy import json # 读取仓库参数 with open('warehouse_params.json', 'r') as f: params = json.load(f) rack = params['rack'] aisle = params['aisle_width'] # 获取母版货架 master_rack = bpy.data.objects['Rack_Master'] # 双排背靠背布局 for row in range(rack['rows']): for col in range(rack['columns']): # 计算位置 x = row * (rack['length'] + aisle) y = col * rack['depth'] z = 0 # 复制货架 new_rack = master_rack.copy() new_rack.data = master_rack.data.copy() new_rack.location = (x, y, z) bpy.context.collection.objects.link(new_rack)

这段脚本跑下来，200 个货架几秒钟就摆好了。如果手动摆，至少得半天。

4.3 通道与功能区的划分

货架摆好之后，通道和功能区的位置就自然确定了。通道是货架之间的空隙，宽度由aisle_width决定。功能区包括：入库暂存区、出库暂存区、分拣区、充电区。这些区域通常用不同颜色的地面标记来区分。

我在 Blender 里用bpy.ops.mesh.primitive_plane_add创建了几个薄片，贴在地面上，分别赋予不同的材质颜色。入库区用绿色，出库区用红色，分拣区用黄色，充电区用蓝色。这样在三维视图里一眼就能看出各个区域的功能。

实操心得：功能区的颜色不要太鲜艳，否则在实时渲染时会抢视觉焦点。我一开始用了纯红纯绿，结果整个场景看起来像儿童乐园。后来改成低饱和度的莫兰迪色系，观感好很多。

4.4 材质与光照的快速配置

数字孪生场景的材质不需要像影视渲染那么精细，但也不能太粗糙。我的原则是：金属物体用 Principled BSDF 的 Metallic 通道，塑料物体用 Roughness 通道，地面用带纹理的漫反射材质。

Blender MCP 支持通过自然语言修改材质。比如我说“把货架材质改成橙色金属漆，粗糙度 0.3，金属度 0.8”，Antigravity 就会调用bpy.data.materials相关的 API 来调整参数。实测下来，对于标准材质，AI 的调整准确率很高；但如果涉及复杂的节点连接，比如混合纹理、法线贴图，AI 就力不从心了，还是得手动调。

光照方面，我用的是三点布光法：一个主光源（Sun）从斜上方打下来，两个辅助光源（Area）从两侧补光。主光源的强度设 3.0，辅助光源设 1.5。这样出来的效果比较自然，阴影不会太硬也不会太软。

5. 动态元素与数据映射：让数字孪生“活”起来

5.1 AGV 小车的路径动画

静态的仓库模型只是一个“壳”，真正让数字孪生有价值的是动态元素。AGV 小车是仓储场景里最常见的动态物体，它的运动轨迹通常由 WMS 系统调度生成，表现为一系列坐标点。

我在 Blender 里用bpy.ops.curve.primitive_bezier_curve_add创建了一条贝塞尔曲线，作为 AGV 的行驶路径。然后把 AGV 模型绑定到曲线上，用Follow Path约束让它沿着曲线运动。曲线的控制点坐标从 WMS 的调度数据里读取，这样 AGV 的运动就和现实中的调度逻辑一致了。

这里有个坑：Blender 的Follow Path约束默认是匀速运动，但现实中的 AGV 在转弯时会减速。如果要模拟得更真实，需要手动调整曲线的Evaluation Time或者用脚本控制速度曲线。我一开始没注意这个，结果 AGV 在转弯时“飞”了出去，看起来特别假。

5.2 货位状态的实时更新

货位的状态（有货/空货）是数字孪生最核心的数据映射。在 Blender 里，每个货位对应一个小的立方体，有货时显示为实心，空货时显示为线框。这个切换可以通过修改物体的display_type属性来实现。

我用了一个 Python 脚本，每隔 5 秒从 WMS 的 API 拉取一次库存数据，然后遍历所有货位物体，根据库存状态更新显示。脚本的核心逻辑是：

import bpy import requests # 从 WMS 获取库存数据 response = requests.get('http://wms-api/inventory') inventory = response.json() # 遍历所有货位 for slot in bpy.data.objects: if slot.name.startswith('Slot_'): slot_id = slot.name.replace('Slot_', '') if slot_id in inventory and inventory[slot_id]['quantity'] > 0: slot.display_type = 'SOLID' slot.color = (0.2, 0.8, 0.2, 1.0) # 绿色表示有货 else: slot.display_type = 'WIRE' slot.color = (0.8, 0.2, 0.2, 1.0) # 红色表示空货

这个脚本跑起来之后，Blender 里的货位颜色会随着 WMS 数据实时变化。实测下来，5 秒的刷新间隔对于大多数仓储场景够用了，如果要求更高，可以降到 1 秒，但会增加 WMS 的负载。

5.3 用 Antigravity 做数据映射的“翻译官”

上面的脚本虽然能跑，但每次调整逻辑都得改代码，很麻烦。后来我发现，可以用 Antigravity 来做“翻译”：我把 WMS 的数据格式和 Blender 的物体命名规则告诉它，然后直接用自然语言描述映射关系，比如“把 WMS 里 quantity 大于 0 的货位显示为绿色实心，否则显示为红色线框”。Antigravity 会自动生成对应的 Python 脚本并执行。

这种方式的好处是迭代快。如果老板说“有货的显示绿色，空货的显示灰色”，我只需要改一句描述，不用动代码。但缺点是调试难，如果 AI 生成的脚本有 bug，排查起来比手写代码更费劲。所以我的建议是：核心逻辑手写，边缘逻辑用 AI 生成。

5.4 实时渲染输出的性能调优

Blender 的 Eevee 引擎支持实时渲染，但默认设置下帧率可能只有十几帧。对于数字孪生来说，至少得稳定在 30 帧以上才够流畅。我做了几个优化：

第一，关闭不必要的阴影。Eevee 的软阴影很吃性能，改成硬阴影或者直接关掉，帧率能提升 30% 左右。

第二，降低采样数。Eevee 的 TAA 采样默认是 64，降到 16 对画质影响不大，但性能提升明显。

第三，用 LOD（Level of Detail）。远处的货架用低模，近处的用高模。Blender 的Decimate修改器可以自动生成低模，我写了个脚本根据相机距离动态切换。

第四，限制视口刷新率。如果只是做数据监控，不需要 60 帧，锁 30 帧就够了，还能省电。

6. 常见问题与排查技巧实录

6.1 MCP 连接失败的排查思路

MCP 连接失败是最常见的问题，表现是 Antigravity 里输入指令后没有任何反应，或者报“Connection refused”。排查步骤是这样的：

1. 检查 Blender 的 MCP 服务是否启动。在 Blender 的侧边栏 MCP 面板里，看状态指示灯是不是绿色。
2. 检查端口是否被占用。在命令行里跑netstat -ano | findstr 9876（Windows）或lsof -i :9876（macOS），看有没有其他程序占用了这个端口。
3. 检查防火墙设置。Windows Defender 和 macOS 的防火墙都可能拦截本地 WebSocket 连接，需要手动放行。
4. 检查 Antigravity 的配置文件。mcp_servers字段的 URL 必须是ws://localhost:9876，不能写成http://。

我遇到过一次特别诡异的情况：Blender 的 MCP 服务显示在运行，端口也没被占用，但 Antigravity 就是连不上。后来发现是 Blender 的 Python 环境里mcp包的版本和 Antigravity 期望的不一致。卸载重装后就好了。

6.2 批量生成物体时的性能瓶颈

一次性生成几百个货架时，Blender 可能会卡死。这是因为每个物体都会触发一次场景更新，几百次更新叠加起来就很慢。解决办法是批量操作：先用bpy.data.meshes.new创建网格数据，再用bpy.data.objects.new创建物体，最后统一链接到场景里。这样只触发一次场景更新，速度快很多。

另外，生成过程中可以临时关闭视口刷新。用bpy.context.window.screen.areas找到 3D 视图，把shading.type改成WIREFRAME，生成完再改回来。

6.3 材质显示异常的修复方法

有时候 AI 生成的材质在视口里显示正常，但渲染出来是黑色的。这通常是法线方向反了。在 Blender 里选中物体，进入编辑模式，按Shift+N重新计算法线就行。

还有一种情况是材质丢失。如果 AI 在生成材质时引用了不存在的纹理文件，材质会显示为默认的灰色。解决办法是在bpy.data.materials里找到对应的材质，检查node_tree里的纹理节点路径是否正确。

6.4 常见问题速查表

避坑技巧：每次修改完场景后，记得按Ctrl+S保存。Blender 的撤销栈有限，如果操作步骤太多，撤销不回去就只能重来。我吃过这个亏，一次误操作删了半个仓库的货架，只能从头生成。

7. 从 Blender 到 Web 端：数字孪生的下一步扩展

Blender 里的数字孪生虽然直观，但只能在本地看。如果要让更多人访问，比如仓库管理员在手机上查看，就得导出到 Web 端。Blender 支持导出 glTF 格式，这是一种专门为 Web 优化的三维格式，Three.js 和 Babylon.js 都能直接加载。

导出的步骤不复杂：在 Blender 里选中所有物体，点击“文件 > 导出 > glTF 2.0”，选择.glb格式（二进制格式，体积更小）。导出时注意勾选“应用修改器”和“导出材质”，否则模型会丢失细节。

Web 端的加载代码大概长这样：

import * as THREE from 'three'; import { GLTFLoader } from 'three/addons/loaders/GLTFLoader.js'; const loader = new GLTFLoader(); loader.load('warehouse.glb', (gltf) => { scene.add(gltf.scene); // 遍历模型，找到货位物体 gltf.scene.traverse((child) => { if (child.name.startsWith('Slot_')) { // 绑定点击事件 child.userData.clickable = true; } }); });

Web 端的优势是跨平台，手机、平板、电脑都能看。但缺点是性能受限，浏览器里的三维渲染能力远不如 Blender。所以我的策略是：Blender 做建模和数据处理，Web 端做展示和交互。两边通过 WebSocket 同步数据，Blender 里更新了货位状态，Web 端也能实时看到。

这个扩展方向我还在摸索中，目前遇到的最大问题是模型体积。一个完整的仓库模型导出 glb 后大概有 50MB，加载起来很慢。后续打算用 Draco 压缩或者分块加载来优化。如果你也在做类似的事情，欢迎交流经验。