Antigravity + MCP 驱动 Blender，AI 自动搭建智慧仓储数字孪生

1. 项目概述：当 AI 代理开始操作 Blender

1.1 这个项目到底在做什么

我先说结论：这个项目是用 Antigravity 作为 AI 编排层，通过 MCP 协议把 Blender 变成 AI 可以直接控制的 3D 建模工具，最终产出的是一个 3D 智慧仓储数字孪生场景。整套链路是“自然语言指令 → Antigravity Agent 理解意图 → 通过 MCP 调用 Blender Python API → 自动生成/修改仓储三维模型 → 导出场景数据 → 对接前端可视化”。

听起来有点绕，但拆开看其实很直白。传统做法是你打开 Blender 手动建模、摆货架、调材质，再写代码导出数据。这套方案里，你只需要告诉 AI“帮我建一个 8 排货架、3 条通道、每排 5 层，层高 1.8 米的仓库”，Antigravity 就会自动调用 Blender 生成对应场景。这就是 MCP（Model Context Protocol，模型上下文协议）在起作用——它把 AI 和三维引擎之间的“对话”标准化了。

我做这个项目的主要目的，是想验证一条更高效的 3D 数字孪生生产路径。传统数字孪生项目最大痛点就是建模周期太长：一个中等的仓储场景，手工建模加调格式，往少了说也要两个星期。而用 Agent + MCP 的方式，基础场景框架能在几小时内搭出来，后续需求变更（比如加一排货架、改通道宽度）只需要改一句描述，AI 会直接改模型。

1.2 为什么是 Antigravity、Blender 和 MCP 这个组合

先说 Antigravity。它本质上是一个带 Agent 能力的 AI 开发环境，内置了大模型和代码执行沙箱。和普通对话式 AI 最大的区别是，它能自主完成“理解需求 → 拆解任务 → 调用工具 → 验证结果”的完整闭环。我要它建仓库，它不会只给我一段 Python 代码让我自己跑，而是真的会去连接 Blender、执行脚本、截图给我看效果。这一点对非纯编程背景的同学特别重要，你可以不关心 Blender 的 API 细节，只要把意图说清楚。

再说 Blender。选它而不是 Unity 或 Three.js，核心原因是它具备完整的建模、修改、导出流程，而且有 Python API 和命令行模式。MCP 服务器要控制三维工具，必须有稳定的程序化接口。Blender 的bpy模块可以直接执行建模、材质、渲染、导出，这能力是很多游戏引擎不具备的——它们更适合展示成品，而不适合“无头”批量修改模型。

最后是 MCP。它解决的是 AI 和工具之间的协议统一问题。没有 MCP 之前，每个工具都要单独写一套适配；有了 MCP，Blender 只需要实现一个标准接口，Antigravity 就能通过统一的协议读写状态、调用操作。打个比方：MCP 像是 USB 接口，Blender 是 U 盘，Antigravity 是电脑。没有 USB 标准之前，每个设备都得专门设计接口，有了标准之后插上就能用。

1.3 适合谁看，能解决什么问题

如果你是做数字孪生、智慧园区、仓储物流可视化相关工作的，或者对 AI 辅助 3D 建模感兴趣，这篇文章值得看完。我会把环境搭建、MCP 配置、Blender 建模、数据导出、问题排查这些环节全部铺开讲，结合我实际踩过的坑。

需要提前说明的是，阅读这篇文章不需要你精通 Blender 或写过完整的 MCP 服务器，但最好对 Python 有一点基础，至少能看懂函数调用。我会尽量把每个步骤的操作理由讲清楚，你遇到类似场景时可以照着做，而不是死记命令。

2. 核心概念与方案选型拆解

2.1 数字孪生与 3D 智慧仓储：需求侧分析

数字孪生这个概念被滥用了很久，但落到仓储场景，它其实有非常具体的需求。我们做智慧仓储三维可视化，最终要回答三个问题：仓库里现在有什么东西、东西在哪、设备（AGV、传送带、机械臂）在干什么。

对应到三维场景，就是三个层次：第一层是静态结构建模，包括墙体、货架、通道、出入口，这一层基本不变，做完可以反复复用。第二层是动态设备建模，包括 AGV、堆垛机、机械臂这些会动的东西，它们需要带关节和动画逻辑。第三层是数据绑定，就是把货架上每个库位和业务数据库关联起来，模型上的任何一个格子都能查到对应的库存信息。

这三个层次的工作量是递增的。第一层用刚才说的“AI 从零生成”就能搞定，第二层需要手工定制或半自动生成，第三层则是纯粹的代码工作，要在前端或 Node 服务里做数据映射。我这次项目的主攻方向是第一层加第二层的框架部分，第三层用到了导出 JSON 的方案，后面细说。

2.2 MCP 协议：AI 与三维世界的握手协议

MCP 不是什么全新的概念，它的核心是一套 JSON-RPC 风格的通信协议，规定了 Client（比如 Antigravity）和 Server（比如 Blender MCP 服务）之间的消息格式。简单说，AI 想要 Blender 干活，不是直接把自然语言扔给 Blender，而是消息先经过 MCP Server 翻译成可执行的bpy命令。

我从实际运行的角度理清一下消息流：

1. 用户在 Antigravity 里输入指令：“新建仓库，宽 60 米，深 40 米，高 8 米，内部 5 排货架。”
2. Antigravity 的 Agent 把任务拆解，识别出需要调用 Blender 的“新建场景”能力。
3. Agent 通过 MCP Client 向 Blender MCP Server 发送create_warehouse(width=60, depth=40, height=8, rack_rows=5)。
4. Blender MCP Server 收到后执行bpy脚本，操作场景数据。
5. 结果（成功/失败/截图路径）通过同一通道返回给 Antigravity。

这套流程的关键在于 MCP 的 Schema 定义——也就是给 AI 看的“工具说明书”。在 MCP Server 里，每个工具都要声明参数、类型、返回值格式。AI 会根据这个 Schema 决定怎么调用，所以 Schema 写得越清楚，AI 的执行准确率越高。我后面有一节专门讲这个 Schema 怎么写。

2.3 Antigravity 的角色：AI 代理如何编排工作流

Antigravity 在整个项目里像一个“包工头”。它不直接建模，但负责拆解你的自然语言需求，调度 MCP 工具，检查每一步执行结果，必要时纠正错误。

我在项目中体验最深的一点是它的 Agent 循环能力。普通的 AI 辅助编程是“用户提问 → AI 回答 → 用户手动作”，但 Antigravity 的 Agent 模式是“任务下发 → 自动执行 → 自动检查 → 发现问题自动重试”，直到任务完成或失败退出。而且它可以记住之前执行过哪些操作，比如已经创建过货架，再让它加一层，它不会重新建一个场景，而是找到现有对象做修改。

不过这种自主性也带来一个风险：当 Blender MCP Server 返回错误信息时，Agent 可能会凭“想象力”自行修改方案，而不是真正读懂 Blender 报错。这时候如果你给的约束条件不清晰，它会反复尝试，造成整个任务执行时间拉长、甚至进入死循环。所以我建议在给 Antigravity 下达任务时，尽量在指令中带上明确的数值范围和可选方案，比如“如果货架放不下，自动减少排数，而不是改变通道宽度”。

2.4 Blender 在数字孪生中的不可替代性

有人会问，既然最后展示是在前端，为什么不在 Three.js 里直接建？我的答案是：建复杂场地模型这件事，Blender 仍然是效率之王。

Three.js 里建一个简单的盒子没问题，但你要建货架阵列、通道标识、AGV 模型，效率就很低了。而且 Three.js 没有针对“尺寸、材质、光照”的直观编辑界面，一切靠代码，改一个参数就要刷新浏览器看效果。Blender 则不同，它有一个完整的 3D 视图，你可以在里面旋转、缩放、看模型关系，AI 操作时也可以截图反馈。数字孪生项目前期大量精力花在“把场景打磨到比例合理、材质正确、层级清晰”上，Blender 的视窗系统提供了最好的调试体验。

此外，Blender 的.blend文件本身就是场景的数据库——它存储了物体的层级、变换矩阵、材质属性、动画曲线。MCP Server 可以在内存里对整个.blend文件做任何操作，然后导出 glTF/JSON 给前端用。这种“建模和导出分离”的工作模式特别适合数字孪生：建模在 Blender 里完成，运行时数据在前端驱动。

3. 环境准备与基础配置（实操）

3.1 部署 Antigravity 并解决 403 问题

Antigravity 的安装本身不复杂，下载对应平台安装包，注册账号登录。真正容易卡住的是 403 报错。我在第一次启动时就遇到antigravity 403，界面直接无法进入。这个问题的原因比较多，我从现象到解法逐个排查：

• 最常见的是账号验证未完成。Antigravity 会要求你验证邮箱或账号状态，如果没验证完，接口返回 403。页面会出现please verify your account to continue using antigravity提示。我当时的处理是把整个流程走完，包括邮件点击确认链接、重新登录。
• 另一种是时间不同步导致的 token 校验失败。如果你的系统时间和真实时间偏差太大，请求签名验证会失败，表现为 403。这种问题在虚拟机或长时间休眠的电脑上很常见，校准时间后就好了。
• 还有一种是访问网络不稳定，导致登录态校验中途失败。此时可以等一段时间再重试，不要反复刷新。

如果你遇到antigravity update error，也就是更新出错，多数是增量包下载异常。我建议直接卸载重装最新版，不要浪费时间修复增量包。

3.2 通过 MCP 配置 Blender 服务端

Antigravity 装好后，下一步是连接 MCP Server。Blender MCP 服务的地址格式一般是wss://api.xxx.com/mcp/?token=...，本质上是通过 WebSocket 访问远程 MCP 服务。但在本地开发场景，我更推荐用本地 MCP 服务，也就是直接在本机跑一个stdio或sse模式的 MCP Server，指向本机安装的 Blender。

这里有个容易混淆的点：MCP 协议有两种传输方式，一种是本标准输入输出（stdio），适合本地进程；另一种是 Streamable HTTP 或 WebSocket，适合远程访问。我这次选的是本地 stdio 模式，Antigravity 启动时会把它当作子进程唤起来。远程wss模式的好处是不用本地装 Blender，但延迟更高，而且你必须在远程环境里维护 Blender 的完整安装。除非是多人协作共享一个建模环境，否则本地 stdio 模式体验更稳。

在 Antigravity 的 MCP 配置里，我加了一个 JSON 配置项，类似这样：

{ "mcpServers": { "blender": { "command": "python", "args": ["-m", "blender_mcp_server", "--port", "9876"], "env": { "BLENDER_PATH": "/Applications/Blender.app/Contents/MacOS/Blender" } } } }

这里面有一个关键参数：BLENDER_PATH要指向实际的 Blender 可执行文件。MCP Server 收到 AI 的建模块指令后，会用--background模式启动 Blender 实例，执行bpy脚本，最后关闭。如果你没设置这个路径，或者指向错版本，后面调用会直接报找不到文件。

3.3 Blender 环境准备与插件安装

Blender 这边要做两件事：一是确认 Python 环境可用，二是安装必要的插件（如果有的话）。

Blender 4.x 自带完整的 Python 解释器，在脚本编辑里可以直接执行bpy。但你需要注意，MCP Server 是通过外部 Python 进程调用 Blender 的，不是在这个 Python 解释器里跑。也就是说，你本机的 Python 环境里要装了blender-mcp-server这个包，并且它能启动 Blender 的 Python API。

我当时的做法是用pip安装 MCP 依赖包，然后用命令行验证 Blender 能被外部进程调用：

blender --background --python-expr "import bpy; print(bpy.app.version_string)"

能正常输出版本号，说明 Blender 的命令行模式可用。这一步是整个链路通畅的基础，如果输不出内容，多半是BLENDER_PATH配错了，或者 Blender 安装盘符路径里有空格导致解析问题。

另外，我建议打开 Blender 的“开发者模式”。在偏好设置 → 界面 → 勾选“开发者选项”。这样脚本执行时的错误信息会完整输出，而不是被界面吞掉，排查问题能少花一半时间。

4. 核心实操：用 Blender 搭建仓储数字孪生场景

4.1 场景结构设计与坐标规范

数字孪生场景最忌讳“怎么方便怎么建”，后面数据对接时会乱成一锅粥。我开工之前先定了几个规范：以 Blender 的世界原点为仓库中心点（0,0,0），地面放在 Y=0 平面，X 轴为仓库长度方向，Y 轴为宽度方向，Z 轴为高度方向。单位统一用米，这是 Blender 的默认公制单位，也是对接物理引擎和前端三维引擎最稳妥的方案。

层级命名規范是我踩过坑之后才总结出来的。每个货架对象叫Rack_01、Rack_02，库位叫Bin_R01_C02_L03（排-列-层），AGV 叫AGV_A、AGV_B。不要小看命名这件事，后续通过 MCP 给 AI 下指令时，比如“把 Rack_03 的高度改成 2.4 米”，如果命名不清晰，AI 根本定位不到对象。更麻烦的是，MCP 返回的场景对象树也会因为命名混乱而变得不可读。我建议从第一个模型开始就强制自己按规范命名。

4.2 货架、通道、AGV 的建模策略

货架是仓储场景里数量最多、结构最重复的对象。手工一个个摆浪费时间，让 AI 用循环阵列做是最优解。核心思路是：先建一个“标准货架单元”，然后用 Python 循环复制，按间距排列。

下面是我给 AI 下达的一段典型建模指令，以及它触发的 Blender 脚本逻辑：

创建一个双深货架：长 2.4 米，宽 1.2 米，高 1.8 米，5 层横梁，底部离地 0.1 米。

AI 通过 MCP 调用了类似这样的函数：

def create_rack(location, length=2.4, width=1.2, height=1.8, shelf_count=5): # 建立柱 for i in range(2): x_offset = -length / 2 if i == 0 else length / 2 bpy.ops.mesh.primitive_cylinder_add( radius=0.04, depth=height, location=(location.x + x_offset, location.y, location.z + height / 2) ) # 建横梁和层板 for shelf in range(shelf_count + 1): z_pos = location.z + 0.1 + shelf * (height - 0.2) / shelf_count # 建横梁 cube 并拉伸 # 建背板/护栏等

这个函数其实不复杂，关键在两点：一是把底座高度、层高、尺寸全参数化，AI 可以根据你的需求生成任意规格货架；二是把物体用集合（Collection）管理，每个货架的所有部件都归入Rack_XX集合，方便后续整体移动和导出。

通道的建模更简单，本质上就是地面上的标记线。但要注意贴图和 UV 展开，如果你打算在浏览器里展示，通道标线最好用独立的材质 ID，这样前端可以通过材质属性控制透明度或变色。AGV 的建模就别走“AI 从零生成”路线了，这种有轮子、有举升机构的模型，AI 生成的几何结构通常比较粗糙。我的做法是从开源模型网站下载基础 AGV 模型，再在 Blender 里调整尺寸比例。这并不违背项目目标——AI 负责搭框架，模型资产靠人工精修，两者结合才是实战状态。

4.3 通过 MCP 让 AI 调用 Blender API

这一段是整个项目的核心机制，也是 MCP 体现价值的地方。MCP Server 里定义了若干工具，我这里列出最常用的四个：

Schema 的意思是告诉 AI“这个工具接受什么参数、返回什么结果”。仓库外框架的例子：

{ "name": "create_warehouse_shell", "description": "创建仓库的建筑外壳，包括地面、四周墙壁和屋顶开口。", "inputSchema": { "type": "object", "properties": { "width": {"type": "number", "description": "仓库宽度（米），沿 X 轴"}, "depth": {"type": "number", "description": "仓库深度（米），沿 Y 轴"}, "height": {"type": "number", "description": "仓库高度（米），沿 Z 轴"} }, "required": ["width", "depth", "height"] } }

我强烈建议你在描述字段里写清“米”这个单位，并且说明坐标轴方向。因为 AI 模型对空间概念的理解不完全稳定，万一它把 X 和 Y 搞反了，出来的仓库就是扁的。同样的，如果你希望 AI 优先响应某个工具，可以把它放在 Server 的工具列表前部，并增加一个高优先级的描述提示。

4.4 导出 JSON 数据与前端联动

Blender 模型最终要被前端网页使用，所以导出格式要“轻”。我不推荐直接导出.blend让浏览器加载——格式太重，兼容性也差。我这边走的是两条路：一条是导出 glTF/GLB 作为三维模型资产，另一条是导出 JSON 作为场景结构数据。

.blend文件本身是场景的数据库；glTF 是给前端渲染用的轻量格式；JSON 则是给业务逻辑用的数据源。这三者的关系是：

• glTF：包含几何、材质、动画，在 Three.js 里可以直接加载。
• JSON：包含物体名称、世界坐标、长宽高、层级关系、库位编号、容量上限等元数据。
• 业务系统：根据 JSON 里的库位编号查询库存数据，驱动前端改变对应模型的实时状态。

MCP 的export_scene_json工具在导出时，会把每个物体的 transform（位置、旋转、缩放）、bounding_box（包围盒）、custom_properties（自定义属性）全部扫出来。你只需要在 Blender 的物体属性面板里填好自定义属性，比如SKU_CODE、MAX_WEIGHT，导出时就会自动带上。这一步很关键，我见过太多人做数字孪生依赖手工绑定数据位置，模型一改，绑定就全崩了。用自定义属性驱动导出，可以保证“模型和数据永远同步”。

前端联动这部分，我用了一个简单的原则：前端不直接分析模型的几何细节，只读取 JSON 和 glTF。场景初始化时加载 glTF，同时把 JSON 里每个物体的坐标映射到 Three.js 对象上；后续要更新库位状态，只需要用 JSON 里的 ID 查找三维对象即可。

5. 常见问题与排查实录

5.1 Antigravity 403 与账号验证问题

这是整条链路第一道坎，我遇到过不止一次。403 出现的场景大概有三类：登录后立即出现、执行 Agent 任务中途出现、更新过后出现。

登录后立即出现的 403，基本可以判断是账号状态问题。按照提示完成verify your account to continue using antigravity验证流程，一般能解决。执行中途出现的 403，通常是会话过期，重新登一次就好。更新过后出现的 403，大概率是配置文件和当前版本不匹配——我建议把老版本的配置文件全部删掉，让程序重新生成。

这类问题有个通用排障思路：先看是否有验证提示，再看系统时间是否正确，最后考虑重装。按这个顺序能覆盖九成的情况。不要再进去乱改网络配置，那只会让问题更难排查。

5.2 Agent 执行被终止的排查思路

antigravity agent execution terminated due to error这个报错我在第一次自动生成货架阵列时遇到过。当时表现是：AI 已经创建了几排货架，突然报错终止。排查后发现原因是 MCP 工具返回的结果数据量太大——场景里有几百个物体，每个物体的信息都返回给了 Agent，超出了单次上下文窗口的限制。

解决方法是调整 MCP Server 的返回策略：不要在每次调用后全量返回场景信息，只返回“操作结果摘要 + 新增对象的少量元数据 + 场景对象数量统计”。让 MCP Server 提供一个专门的summarize_scene工具，AI 需要知道全局情况时再主动调用。这个改动把它从“一次性塞太多信息导致上下文爆炸”这个问题里拉出来了。

还有一个容易忽略的问题：Blender 某些操作需要 GUI 上下文，比如bpy.ops.mesh.primitive_cylinder_add在--background模式下虽然通常没问题，但如果你不小心切换了场景上下文（例如没有先select_all(action='DESELECT')），也会中断。这类问题要从两处入手：一是在脚本里做好对象选择状态管理，二是让 Agent 在处理复杂任务前，先调用一个“重置场景到已知状态”的工具。

5.3 MCP 连接失败的常见原因

MCP 连接失败，我的经验是把问题分成两端：客户端配置问题和服务端环境问题。

客户端最常见的问题是command指向的 Python 环境不对。Antigravity 自身可能带了一个 Python 解释器，如果你在系统 Python 里装了 MCP 包，但配置里用的是 Anaconda 的 Python，就会找不到模块。一定要在启动 Antigravity 的同一个环境里安装 MCP 相关依赖，或者用绝对路径指定 Python 可执行文件。

服务端最常见的问题有两个。第一个是端口被占用，尤其在做本地调试时，上次异常退出后端口没有释放。第二个是 Blender 进程残留，如果 MCP Server 创建 Blender 子进程失败，要先手动把所有 Blender 进程杀掉再重试。这两个问题很好排查：打开系统进程管理，看有没有僵尸 Blender；再看命令行netstat -ano | findstr 9876有没有端口占用。

5.4 Blender 建模中的性能与规范问题

仓储场景建模最大的性能杀手是物体数量。一个大型仓库可能有几百个货架、上千个库位，如果每个库位都是一整个独立 Mesh，Blender 会卡到怀疑人生，前端加载也大概率白屏闪退。

解决办法是实例化。Blender 用collection_instance或关联复制可以大幅降低内存开销——底层数据只有一份，上层只是“引用”。导出的 glTF 也支持实例化，前端加载会非常快。但这里有个坑：AI 通过 MCP 自动建网格时，如果不注意，它会把每个立方体都做成独立 Mesh。所以在给 AI 的指令里要明确“货架横梁和立柱用关联复制/实例化方式生成，不要独立生成 Mesh”。

另外，精确建模时要注意 Blender 的容差问题。MCP 执行命令时，如果你直接给浮点数坐标，可能出现微小偏移导致边缘漏缝。我的习惯是全部用毫米级整数运算（用round(x, 3)），在模型层面上消除误差。

6. 项目小结与我的几条经验

这个项目做到目前阶段，我最大的收获不是“AI 能建 3D 模型”，而是“AI 加标准协议能重构 3D 建模的工作流”。以前改一个货架高度、加一排通道，需要手动操作加代码修改，现在只需一句话描述变化，剩下的事交给 Agent。这种体验带来的效率提升，只有实际跑通一次才知道有多大差距。

要说最值得分享的经验，我总结成三句话。第一，MCP 工具的描述写得越具体，AI 的完成度越高，“米”和“轴”这种看似基础的单位说明一个都不能省。第二，建模规范永远是第一位的，命名、坐标、单位、自定义属性这些功夫花在前期，后期能省下十倍时间。第三，Agent 不是万能的，它会在一个错误上反复横跳，你要通过控制返回信息量和增加重置工具来约束它的自主性。

这个系列的主题是“（上）”，目前完成了场景框架和基础建模的流程。下一篇我会重点做动态部分：给 AGV 添加路径动画、把 JSON 数据对接到前端 Three.js、并实现基于实时数据的货架亮色联动效果。等我把动态数据串起来，再做一次完整的视频演示，到时候会把这个项目的所有配置文件和 MCP 工具代码开源出来，方便大家直接改造成自己的数字孪生底座。

最后再分享一个小技巧：调试 MCP 链路时，不要一上来就用 AI 全流程。先在 Blender 里手动执行一次目标脚本，确认效果；再手动模拟一次 MCP 调用；最后才让 Antigravity 自主跑。把问题分层隔离，整个调试过程会很有时。这套“先本地、再协议、后 Agent”的三段式排查法，我强烈建议每个做 AI 工具链的人都试一次。