Antigravity + Blender MCP 这个组合，最近在3D数字孪生圈子里的讨论热度确实高。简单说，这套玩法就是让AI直接在你的Blender里动手建模，你只需要像聊天一样把需求描述清楚——比如“我要一个长30米、宽20米、高8米的智慧仓库，里面配上双排货架和几台AGV小车”，AI就会借助MCP协议调用Blender的工具，把模型一层层建出来。这篇文章是实操向的，会从方案选型、环境配置、MCP连接、真实建模指令到问题排查完整拆解一遍。适合正在做3D智慧仓储数字孪生、想引入AI辅助建模的开发者，也适合听过Blender MCP但一直不知道怎么落地的朋友。我会把整个过程中实际踩过的坑一并说出来，尽量让没接触过MCP和AI建模的人也能照着复现。

1. 方案拆解：Antigravity和Blender MCP各自扮演什么角色

这节先把两个核心工具的角色讲透。很多人一听“AI建模”就以为AI能自己从零生成一个完整场景，实际上目前最靠谱的方式是分工协作：Antigravity负责理解需求、规划步骤、生成指令，Blender负责执行建模，而Blender MCP就是两者之间的“翻译官+机械手”。

1.1 Antigravity：一个能听你指挥的AI开发环境

Antigravity是Google推出的AI原生开发环境，本质上是围绕AI Agent构建的云端开发空间。你可以把它理解成一个懂代码的项目经理：它能读取项目文件、执行命令、管理版本，还能通过MCP协议去调用外部工具。跟传统IDE最大的区别是，你不需要手动写完整流程，只要把目标描述清楚，Agent会自动拆解任务并一步步完成。

在这个项目里，Antigravity承担的是“大脑”和“调度中枢”的角色。它不直接渲染3D模型，而是负责生成正确的操作指令，比如“在坐标(3, 2, 1)处创建一个边长2米的立方体并命名Rack_01”，然后把指令发给Blender MCP去执行。你也可以把它当作一个会写Blender Python脚本的同事，只不过这个同事不用睡觉、不怕繁琐，只要你把约束说清楚，它就能不停地产出成果。

1.2 Blender MCP：给AI装上操作Blender的“手”

MCP全称是Model Context Protocol，是目前AI工具接入领域的一套开放协议标准。过去每个工具要接入AI都得自己造一套接口，重复且混乱。MCP出现之后，统一成一套协议：服务端暴露一批“工具”（tools），AI端按统一格式调用即可。

Blender MCP是社区开源项目，分为两个部分：一是Blender插件，二是一个MCP Server程序。插件在Blender里启动一个WebSocket服务，默认监听本地端口9876；MCP Server则负责接收Antigravity发来的工具调用请求，翻译成Blender的Python API（也就是bpy）操作。举个例子，AI想创建立方体，流程是：Antigravity发起工具调用 → MCP Server收到指令 → 转换为bpy.ops.mesh.primitive_cube_add()并在Blender里执行 → 返回执行结果给AI。整个过程就是“AI动脑、MCP传话、Blender动手”。

1.3 为什么这套组合适合做智慧仓储数字孪生

智慧仓储数字孪生有一个典型特点：场景元素高度重复、布局规整但数量庞大。一个中等规模的仓库，光货架就有几十上百组，每个货架又有立柱、层板、货物，如果靠手动建模，一个场景少说要折腾好几天。而用传统脚本方式写bpy代码，每次调试也要反复试错。

Antigravity + Blender MCP的组合，最大的优势是“交互式迭代”。你不需要一次性写对完整脚本，而是像指挥一个实习生那样一步步调整：先建地面，再立柱子，再摆放货架，发现问题就说“把第三排货架往X轴方向挪0.3米”，AI会实时修改。这种工作方式非常贴合数字孪生前期做原型、出方案的节奏——快速搭建、快速调整、快速交付。

1.4 智慧仓储场景需要哪些基础元素

做数字孪生不是随便堆几个立方体，而是要有清晰的场景结构。我在这个项目里总结了下面这张元素清单：

这些元素不需要一开始全部做精细，重点是先把空间尺度和布局逻辑确定下来。数字孪生项目里，模型精度是逐级上升的，第一版只需要做到“示意级可交互”，后期再替换精细模型即可。

2. 环境准备：从安装到MCP连接成功要过的四道关

这一步是整个项目最容易劝退人的地方。我自己第一次配置时花了将近半天，不是插件装不上，就是端口连不通，或者AI调工具超时。所以这里把每一步都写细一点，你照着做基本一次就能通。

2.1 Antigravity项目环境准备

先登录Antigravity并新建一个项目，建议项目名直接用英文，比如warehouse-digital-twin。项目会自动分配一个云端工作目录，后面生成的模型文件、导出文件都会放在这里。

这里要区分两种情况。如果你用的是Antigravity Desktop（本地安装版），那环境跑在你自己的电脑上，和本地Blender之间的连接非常简单，直接走localhost即可。如果你用的是Antigravity的Cloud环境，而Blender安装在你自己电脑上，那就得用远程MCP的方式把Blender暴露出去，或者干脆把Linux版Blender装到云端环境里，让Agent在云端内直接访问。我实际测试下来，最省心的方案是：本地装Antigravity Desktop + 本地Blender，全程localhost通信，排查问题最方便。

进入项目后，在设置界面找到MCP Connections相关入口，准备添加MCP Server。别急着填参数，先把Blender那一侧准备好。

2.2 Blender插件安装与启用

Blender MCP的GitHub仓库一般会提供两个关键文件：一个是Blender插件（通常是addon.py），另一个是MCP Server程序（通常是server.py）。下载后解压到本地某个固定目录，路径里尽量不要有中文和空格，否则后面命令行容易出幺蛾子。

打开Blender，依次进入 Edit -> Preferences -> Add-ons，点击 Install，选择插件文件并启用。启用后在3D视图按一下键盘 N 键，右侧抽屉面板里会出现Blender MCP相关的标签页。点击 Start MCP Server 按钮，看到状态变为类似Running on ws://localhost:9876就说明插件端已经就绪。

注意：Blender版本太旧可能导致插件报错，建议用Blender 4.x。另外，Blender自身带了一套内置Python，和系统里安装的Python是两回事，很多新手在系统终端里装了一堆依赖，结果Blender插件依然报错，就是因为根本没走Blender的Python环境。好在Blender MCP插件本身就是个Socket服务端，主要依赖都在MCP Server那一侧，Blender插件本身并不需要额外装库，这点卡住的概率不高。

2.3 MCP Server配置文件的正确写法

回到Antigravity的MCP Connections设置，添加一个MCP Server，选本地进程模式。配置文件通常长这样：

{ "mcpServers": { "blender": { "command": "python", "args": ["server.py"], "cwd": "/path/to/blender-mcp", "env": { "PYTHONPATH": "/path/to/blender-mcp" } } } }

几个字段的要点分别是：

• command和args：启动MCP Server的命令。有些项目要求用uv run启动，那就把command换成uv，args换成["run", "server.py"]，以你下载项目的README为准。
• cwd：server.py所在目录，必须填绝对路径。
• env：如果MCP Server依赖某些第三方库，且这些库装在非默认路径，需要在这里指定PYTHONPATH。

如果要走远程WSS模式，则改成像这样：

{ "mcpServers": { "blender": { "url": "wss://your-mcp-server.example.com/mcp/?token=your_token_here" } } }

这种模式的典型场景是：MCP Server跑在一台云主机上，或者想要多人共用同一个Blender工作台。但日常本地开发，我强烈建议用第一种进程模式，因为日志直接输出在Antigravity的Agent终端里，报错信息一目了然。

2.4 验证连接：先跑通一个最简单的Cube

配置完成后，回到Antigravity的Agent对话框，输入一句最简单的指令：

“查看当前Blender场景里有哪些物体。”

如果AI回答“场景里有Cube、Camera、Light”，说明整条链路已经打通。接着再让它“在原点位置创建一个半径为0.5米的球体，命名为TestSphere”，然后切到Blender的Outliner面板，看到多了一个Sphere，就说明双向控制都没问题。

我遇到不少朋友在这一步没耐心，直接让AI建整个仓库，结果一会儿连接断开一会儿超时，根本分不清问题出在哪一环。先跑通最小链路，后面所有复杂的操作都建立在这条链路上，排查起来会轻松得多。

3. 实操记录：用AI一步步搭出仓储数字孪生场景

链路通了你就会知道，真正的乐趣在于“说需求”而不用“写代码”。但AI不是神仙，如果你不提前约好坐标、单位、命名规则，它会给你一堆乱七八糟的模型。这节把我实际的过程完整放出来，重点是那些让AI“听话”的技巧。

3.1 建模前先定义坐标、单位与场景尺度

Blender默认单位是米，这对仓储场景非常友好，直接按真实尺寸建模即可，后期导出到其他引擎也不用重新缩放。关键是坐标轴约定：我建议把Z轴固定为高度方向，地平面放在Z=0，X轴作为仓库长度方向，Y轴作为宽度方向。

为什么要这么较真？因为数字孪生模型后期要接业务数据，比如某个货位坐标对应数据库里的库位编码。如果AI建模时坐标随机发挥，后面做数据对接就要逐个人工修正，那是灾难。

我在项目一开始就会给Agent设置一段“场景约定”，你也可以直接复制：

场景坐标约定：Z轴为高度方向，地平面在Z=0。所有尺寸单位为米。仓库长轴沿X方向，宽轴沿Y方向。货架高度不允许超过Z=6。所有物体必须有清晰的命名前缀。

这段约定要作为固定的上下文放在会话开头，每次Agent开始干活前都会读到。别嫌啰嗦，实测下来，有约定和没约定，AI产出的可用度差距在50%以上。

3.2 从库架基础开始：自然语言驱动建模

我的第一个操作是建地面。在Agent对话框里输入：

“在Z=0处创建一个长30米、宽20米、高0.1米的立方体，作为仓库地面，命名为Floor。”

AI会通过MCP创建物体，并把尺寸、位置、名称一并设置好。之后让它建四面墙、加上屋顶，基本都是一句话的事。

这里有个细节：AI往往会先把需求翻译成工具调用，如果你观察Agent的执行日志，会看到它正在调用类似add_cube或create_object的工具，传入的其实就是blender操作参数。与其说你在“跟AI聊天”，不如说你是在发布任务，AI自己决定怎么拆解。

搭完地面和墙体后，不要急着往下走。先让AI“总结当前场景中的物体列表和坐标”，确认结构符合预期。这个回顾动作能帮你提前发现不少问题，比如墙体的位置是否对齐、屋顶是否飘在半空。

3.3 批量生成货架阵列：两种方式对比

仓储场景里最核心的就是货架。如果你一个一个下指令，比如“在这里建一个货架、在那里建一个货架”，AI确实会干，但效率很低。更好的方式是让AI用循环生成。

我最初的指令是：

“按3行×5列生成双排货架，行距2.5米，列距3米，每个货架宽1.2米、深0.6米、高2米，共5层，每层层板用薄立方体表示。货架命名规则为Rack_行号_列号。”

AI有两种执行思路。第一种是循环调用MCP工具，创建几十个物体。这种方式简单，但如果数量太大容易超时，而且Blender里会产生大量独立网格，后期不好管理。第二种是让AI直接调用MCP提供的“执行Blender代码”类工具，一次性提交一段bpy脚本。大部分开源的Blender MCP插件都支持这种模式。

我给一段实际跑过的脚本示例，你自己看结构：

import bpy for row in range(3): for col in range(5): x = col * 3.0 y = row * 2.5 z = 0.0 # 默认cube边长是2米，所以scale = 实际尺寸 / 2 bpy.ops.mesh.primitive_cube_add(size=2, location=(x, y, z)) rack = bpy.context.active_object rack.scale = (1.2 / 2, 0.6 / 2, 2.0 / 2) rack.name = f"Rack_{row}_{col}"

这里有个非常容易踩的坑：Blender默认创建的Cube边长是2米，不是1米，所以换算成scale时要除以2。我第一次没注意，AI生成的货架全部大了一圈，后期又一个个改。你也可以不纠结scale，直接在脚本里用obj.dimensions = (1.2, 0.6, 2.0)这种写法，Blender会自动帮你换算缩放值，更省心。

所以我的建议是：优先让AI用“执行代码”的方式批量建库架，因为脚本可维护、可调整，而且能让AI一次性完成几十个物体的创建，效率提升非常明显。

3.4 材质、灯光与渲染出图：让场景可交付

建模只是第一步，要交付给人看，还得有材质、灯光和渲染。这个环节同样可以直接指挥AI。

给地面和货架分配材质很简单：“新建材质FloorMat，颜色RGB(0.16, 0.16, 0.18)，赋给所有名字以Floor开头的物体。”AI会创建材质并自动赋值。

货架的货物，我建议用颜色区分不同SKU。比如A类货物用暖色，B类用冷色，这样数字孪生界面上一眼就能看出库位分布。可以让AI为每个货物随机取一个颜色，但最好限制在某个调色板范围内，不然会变成五颜六色的大花脸。

灯光方面，最简单的仓库照明方案是：在仓库顶部中央放一个Area Light，模拟顶灯；再补一个Sun光，模拟环境光，让模型有立体感。镜头可以先用正上方的俯视图检查整体布局，觉得合理后再换成人视角度出图。

渲染出图时注意，Cycles引擎质量高但慢，EEVEE引擎快但灯光质感弱一些。前期布局检查完全可以用EEVEE，确认姿态之后再切到Cycles出最终效果图。我在实际操作中都是让AI渲染到项目目录下的output文件夹，然后直接在Antigravity里点开图片检查，整个流程非常顺畅。

3.5 导出为glTF：为后续数字孪生平台做准备

这节内容其实下篇会展开讲，但先把导出环节提出来，因为很多人问。Blender建模完成后，要接入数字孪生平台（比如Three.js、Unity），我一般导出glTF/GLB格式。这类自包含格式体积小、支持贴图打包，Web端加载最友好。

导出前检查两件事：一是单位必须是米，二是命名规范清晰。glTF导出时如果选了“Z-up”配置，导入Three.js时默认是Y-up，需要统一处理旋转偏移，否则模型会整体躺倒。这些细节，建议在项目一开始就固定下来，别等导出了几十个物体才回头改。

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

这部分都是真金白银踩坑换来的。我会把最常见的问题按“症状—原因—排查—解决”的方式整理成一个速查表，也分享一些文档里不会写的经验。

4.1 MCP连接不上或工具调用超时

这里最值得说的是“工具调用超时”问题。仓储货架动辄几十上百个，如果让AI一个个去创建Cube，每个工具调用都要走一遍“AI生成参数→网络传输→Blender执行→返回结果”的流程，不超时才怪。我在这个项目里把超过10个重复物体的创建都改成让AI写脚本执行，超时率几乎降为零。

4.2 AI生成的模型位置不对、尺寸离谱

这个问题的根源往往是AI对Blender默认参数的理解偏差。常见的有两种：一是前面提到的Cube边长默认为2米，二是AI忽略了Z轴约定，把货架建到了地下。

解决方式分两步。第一步是在会话里反复强调场景约定，每次Agent动手前都会自己检查坐标。第二步是出错后不要让它“重建整个场景”，而是精确下发修正指令，比如“把Rack_1_2的Z坐标改为1.0米”，改动最小化，风险也最小。

还有一个野路子经验：AI改完坐标后，让它“输出当前所有Rack物体的坐标列表”，用列表来核对，比直接看模型快得多。这个技巧对排查“某排货架歪了”特别管用。

4.3 操作到一半Blender卡死或未响应

创建大量实体物体时，Blender很容易因为顶点数膨胀而卡顿。数字孪生场景里的高柜货架，每个层板拆成16个网格面，几十个货架下来就是上百万面，普通电脑直接吃不消。

我实测下来的对策有三条：

• 尽量用Array修改器来代替重复复制实体，同一批货架只保留一个基础单元，减少文件体积和视口压力。
• 在需要精确坐标布局时再让AI生成独立实体，但每个独立物体的分段数要尽量低。
• 定期保存Blender文件。这个听起来太基础，但实际操作中AI连续操作几十步后，一步卡死导致全部重来的痛，经历过的人都懂。

如果你发现Blender出现明显的延迟，先让AI停止当前操作，保存文件，再让它把场景中的高面数物体用简化模型替换。

4.4 生成结果不适合数字孪生后续使用

这个问题往往不是模型本身的建模错误，而是“数据语义”不对。数字孪生系统需要知道每个货架对应哪个库位、每个库位放了多少货物、状态是否占用。纯建模工具生成的Mesh，如果不带命名规范和数据约定，在业务侧是没法用的。

所以我在建模阶段就让AI把所有物体按规则命名：库架用Rack_区_排_列，货物用Goods_SKU编号_货架编号。这些命名看似不起眼，但决定了之后能不能用脚本批量读取模型数据、能不能对接数据库里的库存字段。这也是为什么我前面反复强调命名前缀的重要性。

另外，如果你们用的是真实仓库的点云数据做数字孪生，那会涉及到点云拉框标注、语义分割等另一套流程，也是很多团队问我的内容。这个方向更适合单独开一篇来讲，这里先不展开。

最后说点体会

Antigravity + Blender MCP这套工作流，用了一段时间后，我最大的感受是：它真正把“改模型”变成了“说需求”。以前客户说“货架间距再大一点”，我得进Blender选中物体、手动拉坐标、反复对齐；现在直接一句话，AI十几秒就改完，我只需要检查结果对不对。效率提升是一方面，更重要的是沟通成本降下来了。

这个方向后续还能继续扩展下去。我目前正在做的下一步，是把建好的场景接上真实的仓储业务数据：比如库位占用率通过颜色实时更新、AGV路径在三维场景里动起来、设备状态异常时自动高亮报警。如果有朋友也在做类似的东西，建议先从简单的数据驱动颜色变化开始，试通之后再做复杂的路径动画。下篇我会具体写场景如何接入业务数据并变成真正的“活”孪生体，到时再见。