1. Antigravity + Blender + MCP：这套组合到底解决了数字孪生里的什么难题
在仓储物流这个行业摸爬滚打几年之后，我越来越觉得，数字孪生不该只是大厂PPT里的漂亮名词。一个真实的智慧仓储数字孪生，背后是成千上万的货架、托盘、AGV路径、库位编号、设备状态——这些玩意儿用传统方式手工建模，一个中型的仓配中心，光建模就要折腾几周。而如果只堆数据不上3D，又永远没办法让业务方直观地看懂问题。
直到我开始把Antigravity、Blender、MCP这三样东西串在一起，这条路才算真正走通了。
先说结论：Antigravity是一个具备Agent能力的AI IDE，它能理解自然语言指令、自主拆解任务、执行代码并调用外部工具；Blender是我们熟悉的开源3D创作套件，建模、材质、动画、渲染都在它身上完成；MCP（Model Context Protocol）则是连接AI与外部世界的标准化桥梁，它让Antigravity能够把指令变成对Blender的精确操作。三者合在一起，就形成了一个“用自然语言驱动3D场景生产”的流水线——你要一个货架，说一句话，AI会自动规划、生成、落位。
这篇文章的重点是上半场：如何把Antigravity、Blender MCP这套环境完整搭起来，并用自然语言生成一个可用的仓储数字孪生静态场景。适合谁看？如果你正在做仓储物流的数字化项目、准备用3D可视化去替代传统平面图汇报，或者只是好奇AI到底怎么干活，这篇文章都能帮你在几个小时内跑通从0到1的完整流程。
我踩过的坑会在后面专门开一节讲，因为这套链路的坑真的不少，什么连接超时、坐标漂移、Agent执行中断，我一个没落下。
2. 环境搭建与MCP通信链路：从Antigravity配置到Blender插件唤醒
2.1 先把三件套的版本与依赖理清楚
我不建议一上来就最新版全家桶，尤其是Blender MCP这种社区插件，版本匹配比功能本身更影响体验。这是我实测下来比较稳的组合：
| 组件 | 版本 | 说明 |
|---|---|---|
| Antigravity IDE | 最新稳定版 | 内置Agent能力，支持MCP Server配置 |
| Blender | 3.6 LTS 或 4.1 LTS | 推荐LTS版，内置Python 3.10/3.11，兼容性好 |
| Blender MCP插件 | ahujasid/blender-mcp 最新提交 | 以Add-on形式运行在Blender内部，负责监听Socket请求 |
| MCP Server配置 | 通过Antigravity的mcp-config.json声明 | 指定blender-mcp的启动命令和参数 |
特别注意，Blender MCP并不是一个独立进程，它的架构是：MCP Server（通常用Python和Node.js混写）由Antigravity拉起，然后MCP Server通过WebSocket或TCP Socket连接Blender内部运行的Add-on插件。也就是说，Blender必须保持打开状态，插件必须在Blender里手动启用，MCP Server才有转发对象。这个机制和很多人熟悉的“插件装上即可用”逻辑完全不同，我第一次跑的时候就在这儿卡了半小时。
2.2 在Antigravity里加一个MCP Server
Antigravity的MCP配置沿用了社区常见的JSON格式。你需要找到IDE的MCP设置入口（一般在设置面板里），把blender-mcp对应的server配置填进去。核心配置长这样：
{ "mcpServers": { "blender-mcp": { "command": "python", "args": [ "-m", "mcp_server_blender", "--port", "9876" ] } } }这里有两个细节容易被忽略。第一，command指向的python解释器，必须在命令行里直接能启动，不能是IDE内置的沙箱Python。我一开始用的是系统Python但环境变量没有配好，Antigravity报错说找不到模块。第二，端口号要跟Blender插件里设置的端口保持一致，默认是9876，如果你本机端口被占用，记得在两端同步修改。
配置完成之后，Antigravity的Agent会在需要时自动启动这个MCP Server。判断是否连接成功的方法很简单：打开Blender，在3D视口里手动执行一次插件提供的连接菜单，或者直接让Agent运行一个最简单的“在Blender里创建一个立方体”的指令，看场景里有没有反应。
2.3 Blender端的插件启用与Socket监听
进入Blender，打开偏好设置（Edit -> Preferences），切到Add-ons标签页，点右上角的Install按钮，选择blender-mcp仓库里blender_mcp/addon.py对应的zip包（不同版本的仓库结构略有差异）。安装完成后搜索“MCP”，把插件前的复选框勾上。
然后在3D视口的右侧边栏（N键呼出）找到MCP面板，点一下Start Server按钮，面板上会出现一行提示，告诉你Socket服务已经开始监听，默认监听127.0.0.1和9876端口。
这里我再强调一次：这个Socket服务是常驻Blender进程内的。意味着你最小化Blender、甚至新建一个窗口都没问题，但只要你关掉Blender，链路立刻断掉。很多人在生成场景时发现“Antigravity说已执行完成，但Blender里什么都没有”，90%是这个原因——Blender的MCP插件根本没在监听。
3. 一条指令出仓储3D场景：完整打通自然语言到货架模型的执行链路
3.1 一条典型的仓储建模指令拆解
环境通了之后，才是真正有意思的部分。我先给你看一条我实测过的指令，然后逐步拆解Antigravity是怎么把它变成Blender场景的。
我输入给Antigravity的原始需求是：
在Blender中创建一个标准的仓储货架模型：长10米、宽1.2米、高4米，共4层，每层2个托盘位，货架主体为深灰色金属材质，立柱为蓝色，在场景中放在坐标原点左侧5米处，并复制出3排，排间距为3米。
这条指令放在传统工作流里，一个有经验的建模师大约需要10到15分钟完成，包括绘制轮廓、挤出、阵列复制、上材质。而在Antigravity + Blender MCP的环境下，整个执行链路是这样的：
- Agent识别出这是一个“程序化建模”任务，判断应该走Blender的Python API（bpy）来实现，而不是手工雕刻。
- Agent调用MCP工具，向Blender发送执行Python代码的请求。
- Blender内插件收到代码，在当前场景中执行bpy操作，创建几何体。
- Agent读取执行结果，确认对象创建成功、位置正确，然后继续执行下一个子任务。
3.2 Antigravity的自主拆解逻辑
Antigravity不会傻乎乎地把一整段Python一次性丢给Blender——那样做执行失败很难排查。它的Agent会做任务拆解，我在日志里看到它把任务分成了这几步：
首先创建单组货架的基本几何体：先建立两根蓝色立柱（Cube缩放成长方体），再建立四层横梁，每层放一个托盘平面。然后应用材质：货架横梁赋予深灰色金属材质，立柱赋予蓝色材质，这一步它甚至自动调用了Blender的Principled BSDF节点。最后做布局复制：以第一组货架为基准，沿X轴间隔3米复制两排，生成三排阵列。
这种拆解方式非常接近一个有经验的建模师的工作路径。传统做法里，很多人会直接写一个循环来生成所有货架，一次性搞定。但Agent选择先做单组、验证、再复制，其实是为了降低出错率——如果一次性生成全部，任何一个尺寸参数错了，就要整体推翻。
3.3 你在Blender里实际能看到的执行结果
当Agent执行到“复制出3排”这一步时，Blender的Outliner面板里会依次出现多组新对象。我建议你在场景里用鼠标中键旋转视角，检查一下货架是否出现在预期位置。
值得留意的是，Agent在首次执行时未必一次成功。在我的测试中，第一次执行的结果是货架高度参数写对了，但托盘位没有变成独立对象，而是合并到了货架网格里。源因在于Antigravity生成代码时默认走了bpy.ops.mesh.primitive_cube_add()加上后续合并的路径，而不是为每个托盘单独创建对象。我纠正它的方式是继续对话：“托盘位需要独立成对象，方便后续绑定库位编码”，Agent会根据这个反馈重新生成代码并执行。
这条链路的价值就在这里：你可以像指挥一个初级建模师一样，不断提出修改意见，AI会自己修改代码、重新执行、验证结果。这是过去任何一套3D自动化工具都不具备的交互方式。
4. 仓储模型不能照搬通用3D流程：货架、托盘、AGV动线建模的实用细节
4.1 为什么通用建模教程在这条路上不够用
如果你在B站或YouTube上看过Blender仓储建模教程，你会发现大多教学都在教“如何把一个立方体拉伸成一个货架”。但数字孪生场景里，模型的信息属性比模型本身的外形重要得多。
数字孪生三层架构里经常讲三层：物理空间、数字空间、数据连接。落实到仓储场景，就是要让货架不只是一个好看的几何体，它要能关联库位编号、承载重量、绑定库存数据。所以我在生成货架模型时，给Antigravity额外提了几个要求：
- 每个库位（货架格口）必须是一个独立的、有名称的对象，命名规则为
RACK-01-03-A，代表1号货架第三层A位。 - 每根立柱都要有独立的坐标信息，方便后续接IoT传感器数据时，能按坐标点映射设备读数。
- 货架模型的尺寸必须和实际图纸一致，不能是视觉上好看但毫无工程参考价值的美术模型。
这三点要求，其实就是把存储数据建模的思路带进了3D场景里。Antigravity完全能听懂这些要求，关键是你要把需求像下需求单一样，一条条写清楚。
4.2 托盘、货架、地面网格的工程级建模参数
以下是我这套环境里，一个标准化仓储场景各元素的推荐参数，直接抄作业即可：
| 元素 | 参数 | 说明 |
|---|---|---|
| 标准托盘 | 长1.2m × 宽1.0m × 高0.15m | 与流通领域常用托盘规格一致 |
| 重型货架 | 单排长10m，深1.2m，高4m | 4层横梁，每层3个托盘位 |
| 货架颜色 | 横梁 #666666，立柱 #2D5A9E | 区分结构件，方便后期做视觉识别 |
| 地面网格 | 场景单位设为米，网格间隔1m | 对应仓储地坪的分区线 |
| AGV通道 | 主通道宽3m，次通道宽1.8m | 用平面几何体做半透明标识 |
这些参数都不是拍脑袋定的。托盘长宽对应的就是标准叉车作业的通道宽度；货架高度对应消防喷淋系统的最低安装高度限制；地面网格间隔1米，对接监控摄像头坐标时换算方便。
4.3 动线、AGV路径与区域划分的前期埋点
数字孪生场景最怕的就是“模型好不好看，业务没法用”。业务方真正关心的是动线是否顺畅、AGV会不会撞车、库位占用率是否合理。所以静态场景搭建时就要考虑后期的动态模拟需求。
我的做法是在场景里用三种不同颜色的半透明平面把区域标出来：蓝色为AGV行驶区、绿色为拣选区、黄色为临时暂存区。这些不是最终可视化素材，但它们在模型树里是有明确名称的空对象，后续接动画脚本时，程序可以直接移动AGV模型并检测是否越界。
这里要给Antigravity的指令加上“创建空对象用于区域划分”这一句，它会生成六个空对象并放在正确的坐标上。这一步对后期价值极大——你不会希望所有区域都合并到一个Mesh上，那后期想看“哪些AGV在当前区域”的时候，代码会写得你怀疑人生。
5. 实测中最容易翻车的三个环节：连接超时、坐标漂移与生成中断排查
5.1 现象一：Agent报“execution terminated due to error”，但Blender端没有给出任何反馈
这条报错我第一次遇到时毫无头绪，后来发现它其实是“假报错”。Antigravity的Agent在调用MCP工具后，会设定一个默认的超时时间，通常只有几十秒。而仓储模型的生成脚本本身要执行大量bpy操作，尤其是材质创建和阵列复制这种重活，执行时间很容易超过Agent的超时阈值。Agent在超时后杀掉任务，于是报出“执行终止”，但Blender那边代码还在继续跑，或者已经因为Socket连接断开而中断。
排查思路很简单：打开Blender的System Console窗口（Window -> Toggle System Console），如果在Agent报错之后，Console里还在滚动输出Python执行日志，说明是超时被误杀了。解决办法是在MCP Server配置里调大超时时间，或者在给Agent的指令里明确加上“执行过程较长，请等待Blender端完成后再验证”。
5.2 现象二：生成出来的货架东倒西歪，完全不在设定的坐标上
坐标漂移的根源几乎都在单位换算。Blender内部长度单位是米，但很多仓储项目的图纸尺寸来自CAD，以毫米为单位。Antigravity在理解需求时，如果指令里没有明确单位，它会默认“10就代表10米”。但一旦你告诉它“长宽高来自某份毫米图纸”，它生成的脚本可能会出现除以1000不一致的情况。
我的建议是：在第一次对话的开头就锁定单位约定，比如“全场景使用米作为单位，所有坐标值以Blender世界坐标系为准”。另外，Antigravity在处理相对坐标时（比如“放在原点左侧5米处”），会读取场景中已有对象的边界框来计算偏移，如果你的场景中有一个巨大的默认立方体没有删除，它的边界框会把所有坐标计算都带偏。所以每次新建场景后，先清空默认对象，再开始建模任务。
5.3 现象三：Blender插件显示已连接，但MCP Server就是转发不到
这个问题更隐蔽。Blender插件面板上的连接状态，只代表Blender端Socket服务正常；但Antigravity的MCP Server在启动时，会用健康检查请求去试探Blender的响应。如果本地防火墙拦截了9876端口的TCP入站连接，就会出现“插件显示正常，Agent端无响应”的怪现象。
macOS上最容易碰到，因为系统自带的应用防火墙对命令行Python没有默认放行。Windows上一般不会拦本地回环地址，但如果你装了第三方安全软件，还是要在防火墙规则里放行python.exe。这个坑我帮同事排查时，发现他用的是一套内网代理环境，MCP Server的请求走了代理，结果永远找不到本地的9876端口。
排查链路总结如下：先看Blender System Console有没有收到请求日志；没有，再看Antigravity侧MCP Server的启动日志；还没有，检查防火墙和端口监听。三步走完，基本没有解决不了的问题。
6. 场景精细度、命名规范与后续扩展：为下半篇的实时数据接入做铺垫
静态场景建完之后，不要在Blender里继续纠缠渲染效果，那会浪费大量时间。我个人的做法是，先把Blend文件里各个模型对象的命名和层级整理干净。你可以让Antigravity帮你做一次“对象规范审计”，它会遍历场景，把所有没有明确命名的对象统一修改，并把货架、托盘、区域标识分别归类到Collection里。
这一步做完后，你的Blender文件才真正具备数字孪生数据层的雏形。以后你每天在Antigravity里给Blender发指令，执行的逻辑都是“按名称定位对象、修改变量、更新位置”。只要命名规范一致，AI的处理准确率会高很多。
在这篇文章里我主要讲了“上”的部分——也就是把静态场景做出来、让AI能指挥Blender干活。但数字孪生的核心在于“动”：库存数据变化、AGV实时位置、设备状态报警，这些数据驱动下的动态更新才是真正高价值的部分。下半篇我会围绕怎么把这套静态场景接上实时数据流来展开，包括用Python脚本在Blender里订阅MQTT消息、把货架库存状态映射成托盘颜色变化、以及如何将动态场景导出给Web前端展示。
如果你按这篇文章把环境跑通了，下半篇的入口其实已经准备好了——你现在手里有一个完全由代码控制、对象命名清晰、坐标系统明确的Blender场景，这比手动操作出来的模型不知道强多少倍。
