我最近一直在折腾一个很有意思的组合：Antigravity 加 Blender MCP，目标是用自然语言直接生成一个智慧仓储的 3D 数字孪生场景。先说清楚这个选题的背景：仓库类项目的数字孪生，很多时候并不需要精确还原一砖一瓦，而是要快速把空间布局、货架数量、货物摆放、动线关系可视化出来，给运营看、给汇报用、给系统集成做底座。传统做法要么找建模师手搓模型，要么自己啃 Unity 或 Three.js，周期一拖就是几周。这次我想完全换一条路，让 Agent 去操作 Blender，把“需求到 3D 场景”的中间环节尽量压缩。

这篇是系列的上篇，主要解决“从零打通环境，到能用一句话生成基础仓储场景”的闭环。适读人群我归纳为三类：想给业务系统快速做 3D 可视化的人，想尝试 Agent 编程和 MCP 工具链的人，以及已经在用 Blender 但想引入 AI 辅助建模的人。基础要求不高，能装软件、会跑命令行就行。文章里我会把选型理由、完整步骤、踩坑过程都摊开讲，尽量让没接触过 MCP 的读者也能照着复现。

1. 为什么仓库数字孪生要选“自然语言建模”这条路

1.1 先泼一盆冷水：传统数字孪生为什么这么慢

以前我做过一个仓库可视化项目，需求从“把库房平面图转成三维”开始，到最终上线，拆成了好几拨人：建模工作室出模型，前端工程师接 Three.js，后端同学写接口，UI 同学调风格，项目经理专门排期对接。光是“货架从 10 组改成 15 组”这种改动，就要回到建模环节重新导一次模型，前端再改一遍配置，两天时间就没了。再赶上客户在周会上说“这个箱子颜色不对”，那真的只能沉默。

问题不在于某个环节的人不专业，而在于链路太长。数字孪生在业务端听着很性感，在开发端几乎所有时间都耗在沟通和迁就工具上。这种模式做单次交付还行，一旦需求变成持续迭代，整个流程立刻僵硬。

1.2 这次项目的目标边界：要“够用场景”，不要“物理级仿真”

我给自己定的目标非常克制：不做高保真物理仿真，不做分子级贴图，就做一个能表达空间布局、货架数量、货物位置、大致动线关系的三维沙盘。静态层面有结构和物件，动态层面能接受数据驱动变化，比如库存数字变化时货物数量跟着变，AGV 小车坐标变化时路径跟着更新。

把目标定义到这个尺度之后，工作量一下就下来了。模型不需要五万面，用方盒子、圆柱、平面就能表达大部分仓储要素。真正麻烦的反而是“怎么把需求变成模型”这件事，而这一块恰好是自然语言建模的强项。

1.3 为什么敢让 AI 直接建模：闭环里的三个能力

让 AI 直接生成 3D 场景，很多人第一反应是不靠谱。我的理解是，这事能做成的关键在于闭环：Agent 通过 MCP 拿到 Blender 的实时操作能力之后，不再是一次性生成一堆代码碰运气，而是“理解需求、调用工具、执行操作、观察结果、发现问题、再修正”这样循环推进。自然语言只是入口，真正的王牌是大模型加工具执行加结果反馈的闭环。

当然，AI 也不是不犯错。它可能在第三组货架上漏了两层，也可能把颜色参数写错。应对办法很简单：一条指令给出去，先看结果，再发一条修正指令。这个循环的速度非常快，比改模型改代码快得多，这也是我敢把核心生产链路押在这套组合上的原因。

2. 技术栈拆解：Agent 负责思考，Blender 负责渲染，MCP 负责翻译

2.1 MCP 到底是什么，和普通 API 有什么区别

MCP 的全称是 Model Context Protocol，模型上下文协议。它的定位不是某个公司私有的 SDK，而是给 Agent 提供标准化的工具访问通道。你可以把它类比成 USB-C：USB-C 本身不生产电，但它统一了充电口、数据口、视频口的对接方式，什么设备插上都能用。MCP 做的事类似：Agent 这个“主机”不知道 Blender 内部长什么样，但只要 Blender 侧跑了一个 MCP Server，Agent 就能自动发现服务器上挂了哪些工具、每个工具接受什么参数、调用之后返回什么结构。

这跟传统 API 有本质区别。传统 API 是“你有个固定功能，我给你开个口子”，MCP 是“给 Agent 一套能力说明书加远程遥控器”。模型不需要提前把每个函数硬编码进训练数据，只要 MCP Server 在线，它就能现场“看懂”这些工具的用途，然后按需调用。

2.2 Antigravity 在链路中扮演的角色

Antigravity 在我这套链路里是大脑和调度中心。它负责承载 Agent 的运行环境，管理工具调用的上下文，也通过 MCP Client 连接外部各种工具服务。配合浏览器扩展，Agent 还能观察网页和应用界面，相当于多了双眼睛。

对 Blender 来说，Antigravity 是“指挥官”；对 MCP 来说，Antigravity 是“客户端”。它把自然语言转成可执行的工具调用序列，再把返回结果解析回人类能看懂的语言。整个流程里你不需要手写一行 Blender 脚本，只需要在控制台里把 MCP Server 地址配好。

2.3 三个组件各解决什么问题

数据流大概是这样：自然语言进入 Antigravity，Antigravity 通过 MCP 协议把指令发给 Blender MCP，Blender MCP 直接调用 bpy API 操作场景，执行结果再原路返回。这个链路最重要的特点是每一层都解耦，替换任何一层都不影响其他部分。

2.4 我为什么不用 Three.js 直接写

我也考虑过直接用 Three.js 写仓储场景。Three.js 灵活性确实高，但有个实际痛点：所有模型都要自己准备，要么通过代码生成几何体，要么导入 glTF，折腾一圈下来，建模的活还是没省掉。Blender 在这里更像一个 DCC 中转站：建模、布局、材质、相机都在里面做，通过 MCP 导出 JSON 之后，前端再用 Three.js 加载。

所以我的选择是“Blender 建模先行，Three.js 后面接手”。Blender 负责视觉和空间结构，Three.js 负责 Web 展示。中间用 JSON 作为交换格式，配合坐标轴转换，两边各干各擅长的事。

3. 打通 MCP 链路：从安装 Blender MCP 到 Antigravity 里跑第一个指令

3.1 装 Blender：版本选择有讲究

第一步是装 Blender。这里强烈建议选 LTS 长期支持版本，别用太新的 beta。原因很简单：Blender MCP 这类插件往往针对稳定版做适配，beta 版一改内部 API，插件可能直接报错。我最初用的是一个小版本号比较新的测试版，插件装上之后界面都打不开，换成 LTS 马上就好了。

装的时候注意 Blender 内置了自己的 Python 环境，这个后面会用到，千万不要去系统里单独装一个 bpy 再来连，版本很容易对不上。保持默认安装即可。

3.2 把 Blender MCP 插件装进去并启动监听服务

Blender MCP 是以插件形式运行的。操作路径是：打开 Blender，进入“偏好设置”里的“插件”面板，点击“安装”，选择下载好的插件压缩包，启用后在侧边栏找到对应面板，点击启动服务。启动成功之后，控制台会打印出监听地址，一般是http://127.0.0.1:8000或者类似的本地端口。

这里有几个容易踩的细节：第一，启动之后那个 Blender 窗口不能关，一关服务就没了；第二，端口不要被其他进程占用，我之前有一次本机有个调试服务占了同端口，插件一直起不来，最后换到 8001 才正常；第三，如果后续要从另一台机器发起连接，监听地址就不能只写 127.0.0.1，要改成 0.0.0.0，但要注意网络安全，别暴露到公网。

3.3 在 Antigravity 中配置 MCP 连接

打开 Antigravity 控制台，找到 MCP 连接管理，新增一个服务器。名称可以随意写，比如blender-local；服务类型根据实际协议选择，支持 HTTP 或 WebSocket 形式；地址填刚才 Blender MCP 打印出来的本地地址。如果服务要求鉴权，就把 token 填到对应的认证参数里，不要在对话里告诉 Agent。

配置完先点“测试连接”，看到通过再继续。第一次配置容易忽略的点是：浏览器扩展里的 MCP 连接开关没有打开。Antigravity 很多时候是通过浏览器扩展去发起 MCP 连接的，扩展设置里如果没启用，控制台显示配置正常但实际连接会失败。这个开关藏得比较深，建议配置完直接去扩展设置里检查一遍。

3.4 第一句指令：建一个 20×12×8 米的空间

环境通了之后，就该跑第一个实际指令了。我给的原文是：

创建一个长20米、宽12米、高8米的仓库空间，地面用浅灰色，四面墙用半透明材质，再放一个摄像机，视角从东北角看向西南方向。

跑完我有点惊讶，Blender 里真的出现了一个完整的房间，地面、墙面、相机位置都正确。虽然风格简陋，但作为场景底座完全够用。这一步的关键意义不是模型多好看，而是整条链路真正通了：自然语言被解析成工具调用，Blender 收到了指令并执行，结果返回到了对话里。

注意一个小技巧：指令里尽量写清尺寸、颜色、视角等具体参数，不要只写“建一个仓库”。模型对模糊指令的想象力会发散，给足参数，执行结果的可控性会高很多。

4. 用一句话搭出仓储场景：货架阵列、托盘堆叠与导出 JSON

4.1 从空仓库开始：结构化命名很重要

场景底座建好之后，下一步是往里面填仓储要素。我建议所有要素都带上结构化命名，比如货架叫Shelf_组号_层号_位号，小车叫AGV_序号。这样做的原因是，后续数据绑定和前端导出都必须依赖名字来定位对象，名字一乱，整个自动化就乱了。

给子对象命名有两种方式：一种是让 Agent 按规则自动命名，另一种是在 prompt 里明确写规则。我更推荐后者，因为 AI 自动命名偶尔会发挥出奇怪的花样，比如把中文混进去或者出现重复编号，这些在 JSON 导出阶段都会变成麻烦。

4.2 生成货架与货物：用批量逻辑而不是一个个摆

仓库场景最核心的要素是货架和货物。我可以直接给你一段实测可用的 prompt：

在坐标(0,0,0)到(3,20,0)的区域生成两排货架，每排5组，每组5层，每层4个仓位，共200个仓位。货架用深灰色金属框架，货物用橙色立方体，命名规则：Shelf_组号_层号_位号。请用循环批量生成，不要创建多余的独立对象。

这里有个关键点：一定要在 prompt 里强调“用循环或批量生成，减少对象数量”。如果不加，有些 Agent 会真的生成 200 个完全独立的立方体，每个都是独立网格对象，Blender 文件立刻膨胀，视图卡顿，后续导出 JSON 也会带出大量冗余数据。

4.3 加入动线辅助设施：动线、AGV、传送带

仓储数字孪生不能只有货架，还要有动线关系。我接着让 Agent 添加了几条传送带、两辆 AGV 小车和几个托盘区。这类设施用简单几何体加颜色标记就够了：传送带用扁长方体加几条滚轴圆柱，AGV 用一个小方块加一个方向箭头，托盘区用带边框的浅色平面。

这一步的体验很直观：改需求不用再回建模软件，直接说“把传送带从仓库北侧移到南侧”“AGV 再加一辆”，Agent 就会去执行。这种高频小改动的效率提升，比一次性生成大场景更有价值。

4.4 导出 JSON：打通 Web 端的数据格式

仓储场景在 Blender 里建好只是第一步，最终要能在 Web 端展示。Blender MCP 提供了场景导出能力，能把当前场景序列化成结构化数据。以一个简化后的字段为例，大致长这样：

{ "scene": "warehouse_v1", "objects": [ { "name": "Shelf_01_02_03", "type": "mesh", "geometry": "cube", "position": [2.5, 1.8, 0.4], "rotation": [0, 0, 0], "scale": [1.0, 0.5, 0.6], "material": { "color": "#ff8c00", "roughness": 0.7 } } ], "camera": { "position": [15.0, 8.0, 5.0], "target": [0, 0, 2] } }

拿到这个 JSON 之后，前端写一段很薄的加载逻辑就行：遍历 objects，按 geometry 创建几何体，按 position、rotation、scale 摆好位置，再按 material.color 上色，一个基础的可视化仓库就出来了。名字字段极其重要，前端要响应点击、显示详情，全靠它去对应业务数据。

4.5 让场景“活起来”的数据绑定思路

数字孪生只有 3D 模型还不能叫孪生，得有数据。我准备做一个最简单的数据绑定：库存表里某个货位数量从 0 变成 12，就通过接口告诉 Agent“把 Shelf_01_02_03 的箱子数量改成 12”，Agent 再通过 MCP 在 Blender 里替换或者新增网格。AGV 小车同理，只要传入实时坐标，Agent 就能更新它的位置属性。

这个方案的好处是业务系统不需要直接操作 Three.js 或 Blender，所有变更都走自然语言，业务侧只需要把变化发出来就行。做成全自动之前，可以先跑半自动：人看一眼变化，发一句指令，确认场景更新。跑顺了再尝试把数据接到 Agent 的上下文里自动触发。

5. 实际踩坑记录：端口、权限、版本与 JSON 导出的完整排查链路

5.1 MCP Server 显示连接成功但指令没进 Blender

现象：Antigravity 侧测试连接显示正常，但发指令后 Blender 场景毫无变化。这是我第一次跑通环境时遇到最诡异的情况。

我的排查链路是这样的：先打开 Blender 控制台，看启动服务的窗口有没有打印请求日志，结果发现什么都没有；再用命令行直接访问服务地址，敲了下面这条命令：

curl http://127.0.0.1:8000/

如果服务正常，返回里能看到服务信息和可用工具列表。我当时发现命令行能返回服务信息，说明 Blender MCP 本身没问题，问题出在 Antigravity 到 Blender 之间的连接配置上。最后检查到浏览器扩展的 MCP 连接开关没有打开，Agent 发起的请求在更上层就被拦截了。打开开关之后，指令顺利到达 Blender。

5.2 Antigravity 报 403 或资格检查失败

这两个报错会在不同阶段出现。403 一般发生在建立连接或鉴权阶段，最常见原因是 token 过期或者填写错误。看一眼配置里的认证信息，重新生成一个 token 再粘贴进去基本能解决。如果是浏览器扩展模式，还要确认扩展本身处于启用状态，有些环境默认未启用会导致 Agent 发起连接时被浏览器策略拦截。

“资格检查失败”这个报错，我遇到的情况多和账号状态、服务开通权限有关，少数时候是网络环境导致服务端校验不通过。处理顺序建议是：先刷新账号信息，再检查服务订阅状态，最后看控制台错误日志确认具体是哪一步校验失败。不要看到 403 就去折腾代理或者反代，先查日志，大多数时候都是配置层面问题。

5.3 Agent 执行到一半提示 terminated due to error

这个报错信息其实很泛，我第一次看到以为整个方案不可用。排查之后发现，常见触发点有三个：指令一次给得太复杂导致执行超时，Blender MCP 返回了非标准结果导致 Agent 解析失败，或者插件内部执行到某个操作时崩了。

处理方式也很朴素：把复杂指令拆成几条小指令，每条指令只做一件事；检查 Blender 控制台有没有具体报错；把插件重启一次再试。我后来养成的习惯是每发一个大指令前先保存 Blender 文件，执行出错就立刻“撤销”加“重来”，不用重新配环境。

5.4 JSON 导出后方位错乱、颜色丢失

前端加载 JSON 之后发现模型方向不对，这是 Blender 和 Three.js 坐标轴习惯不同导致的。Blender 是 Z 轴向上，Three.js 常见习惯是 Y 轴向上，所以导出阶段需要对坐标做轴交换。简单的做法是导出时把 Z 值放到 Y 位置，但旋转和欧拉角也得跟着换轴序，不能只换位移。

颜色丢失的问题也常见，原因是很多 MCP 导出只支持基础颜色和粗糙度，PBR 贴图路径不会自动带进 JSON。所以我现在的习惯是：前期场景里尽量用纯色材质，把视觉表现控制在一个合理的粗糙度范围，这样才能保证导出的 JSON 在前端复现时颜色基本一致。等需要高质量贴图时再用 glTF 等其他格式。

5.5 对象命名里的中文和特殊字符陷阱

我曾经让 Agent 生成“左侧货架”“右侧货架”这种中文名，Blender 里看着没问题，导出 JSON 之后前端解析就出了状况。部分工具链对非 ASCII 字符支持不完善，名字里的空格、中文、斜杠都可能变成潜在的解析错误来源。

现在的规矩是：所有对象名一律使用英文、下划线和数字，例如Shelf_01_02_03、AGV_001。这个习惯在前期就定好，后面数据对接会非常省事，不然等场景大了再统一改名，又是一轮体力活。

5.6 “求完美”陷阱：一次生成太多对象导致卡顿

刚开始玩自然语言建模，很容易在 prompt 里写“生成 500 个箱子”“铺满整个地面”。结果就是 Blender 卡成幻灯片，Blender MCP 执行超时，Agent 报错。原因在于每一个独立对象都是一个网格对象，对象数量上去之后，场景数据量和视图刷新压力都会成倍增加。

解决办法是：能用阵列修改器就用阵列修改器，能合并网格就把同一区域的箱子合并成一个整体，能实例化就绝不复制独立对象。生成的规模控制在一个体感流畅的范围，通常是几十个对象以内，不够再分批扩展。

6. 个人心得与下一步计划

6.1 这个组合的边界在哪里

这套方案并不是“AI 帮我做 3D”，本质是“AI 借 Blender 的工具能力执行了一套预设好的建模操作”。它能做的是基于几何体和基础材质快速搭出场景框架，但遇到复杂曲面建模、高级材质、骨骼动画这些还是力不从心。所以定位要摆正：它擅长的是空间布局设计和批量物件生成，不是取代资深建模师。

6.2 我的几条实测体会

第一，不要一上来就让 Agent 生成一个完美仓库，应该先生成局部，验证链路没问题，再扩大规模。第二，错误不可怕，可怕的是没有保存习惯。每次执行大指令前保存一下 Blender 文件，后续排错会轻松很多。第三，保持“Blender 窗口、Antigravity 控制台、日志终端”三屏同开，哪里出错一眼就能定位。整体跑下来，这套链路最大的收益不是省掉建模师，而是把“改需求”的成本压到最低，这对数字孪生类项目尤其友好。

6.3 下篇预告

上篇先把环境打通和基础场景生成写完了，下篇计划折腾三件事：第一，用自然语言生成多个相机机位和关键路径动画；第二，把实时库存表和 AGV 坐标接进 Agent，让场景里的货物数量和小车位置能跟着业务数据一起动；第三，把 Blender 导出的 JSON 接入 Three.js，搭一个浏览器里直接打开就可以看的 Web 仓储页面。等这三件事跑完，整套“需求到视觉再到数据驱动”的链路就算完整了，到时候再来更新下篇。