Antigravity+Blender MCP：AI代理驱动的智慧仓储数字孪生搭建方案

从第一次接触数字孪生这个概念，到现在亲手拿AI代理去生成仓储场景，这几年最直观的感受是：数字孪生不缺理论，缺的是能把物理世界快速“翻译”成3D资产的执行路径。

我最近做的一个项目，标题就叫《Antigravity + Blender MCP（上）：打造3D 智慧仓储数字孪生》。简单说，就是用 Antigravity 这类 AI 代理平台，把仓库建模这件事变成“对话式”的：你告诉代理货架尺寸、通道宽度、AGV路线，它通过 Blender MCP 连接 Blender 实时建模，我只需要做规划、检查和修正。整套流程跑下来，比我以前用纯 Blender 手工搭建快了不止一个量级，而且场景的复用性、可迭代性非常好。

这篇文章我会把这套方案的底层逻辑、选型过程、最小可跑架构、实操步骤完整拆出来，并记录过程中遇到的坑。如果你正在做智慧仓储、物流仿真、数字孪生园区相关工作，或者是研究 AI Agent + 3D 工具链的人，这篇内容应该能帮你省掉一大段摸索时间。

1. 先把这个方案的底层逻辑讲透

1.1 数字孪生到底在“孪生”什么

很多人一说数字孪生，第一反应是“在电脑里建一个长得像仓库的模型”。这个理解太表面了。数字孪生真正要复刻的，是空间、物体、数据、状态和事件之间的关系。仓库里的货架不是孤立的一堆铁皮，它有自己的位置、层数、载重、占用率；AGV不是一条会动的线，它有路径规划、避障逻辑、调度优先级。这些东西必须在3D空间里“能算”，而不只是“能看”。

所以智慧仓储数字孪生项目，通常要拆成三块来看：

• 3D场景底座：货架、通道、分拣台、月台、消防设备、库位编号；这一层的核心是空间关系准确。
• 业务数据层：库存数量、入库出库记录、订单波次、设备实时状态；这一层负责为3D场景赋予语义。
• 仿真决策层：AGV路径规划、货位分配策略、瓶颈分析；这一层用来回答“如果这样调整，会发生什么”。

我在设计这个项目时，第一优先级不是渲染得多漂亮，而是先把3D场景底座做扎实。没有准确的空间骨架，后面所有数据绑定、仿真算法都是空中楼阁。而 Antigravity + Blender MCP 这套组合，恰好把最耗时、最容易出错的三维资产生成环节，从人肉操作变成了可持续对话和批量执行的自动化过程。

1.2 Antigravity 和 Blender MCP 在工程里各是什么角色

Antigravity 是一个以 Agent 为核心的 AI 开发平台，你可以把它理解成一个“代理工厂”。你不需要从零去写一堆编排代码，而是用自然语言描述目标、约束、工具和交付标准，让它在内部生成并迭代一个可运行的 Agent。对我这种更关注业务方案、不想陷进 prompt 工程和工具链胶水代码里的人来说，这个抽象层非常友好。

Blender MCP 则是把 Blender 暴露给 AI 客户端的一座桥。MCP 是模型上下文协议，简单理解就是 AI 访问外部工具的标准化接口。Blender MCP 在 Blender 端启动一个服务，AI 客户端就能通过定义好的工具去查询场景、新增对象、修改属性、切换材质，甚至渲染出图。整个过程不需要像传统 Blender 开发那样，为每个操作手写 Python 脚本再在胶水层里调用。

两者组合起来，工程上的分工是：

• Antigravity 负责“懂业务”：理解仓储布局规则、通道间距、消防要求、货架承重等业务语义；
• Blender MCP 负责“懂3D”：把你描述的语义转化为网格、节点、材质、坐标和场景层级。

我在这个项目里最喜欢的一个点是：Antigravity 生成的代理并不直接把坐标写死，而是先把仓库平面规划成数据，再决定是否交给 Blender 执行。这样如果甲方改了一个尺寸，我只需要在对话里调整参数，场景可以整体重新生成，而不是在 Blender 里手工拖拽几十个零件。

1.3 这套组合真正解决什么问题

传统数字孪生建设有几个被反复吐槽的痛点。第一是建模周期长，一个中等规模的仓库，用 Blender 手工建，快则一周，慢则半个月；第二是业务语义和3D资产脱节，模型建好了，但库位编号、货物属性、AGV航线没跟模型绑定，后面做数据接入还得二次加工；第三是改一处重来一遍，布局调整往往带动整组模型联动。

用 Antigravity + Blender MCP 的方式，这三个问题都有解：

• 建模周期从“周”压缩到“小时”，而且首批搭建精度已经能到项目汇报与仿真预演级别；
• 业务语义直接写进生成流程，比如建货架时就把库位分层信息作为命名和父子结构绑定好；
• 修改布局只需改对话中的参数，代理会通过 MCP 对场景做增删改，而不是人肉重做。

这套组合不是替代资深建模师，而是把重复性、规则性、参数性的建模工作从人身上拿掉，让人的精力集中在业务验证和场景设计上。这也是我后续所有落地思路的基石。

2. 选型逻辑与架构设计

2.1 为什么底层资产用 Blender 而不是 Unity、Three.js

在这个项目立项前，团队内部其实是讨论过 Unity 和 Three.js 的。先说我个人结论：它们不是同一个层级的东西，不存在非此即彼。Blender 负责的是资产生产，Unity 和 Three.js 负责的是运行时表现。

Unity 更适合做交互式大场景，但它有以下问题：第一，Unity 的编辑器操作对 AI 工具链的开放性不如 Blender，Blender 有 Python API、几何节点、快捷键命令行，MCP 服务可以用更薄的一层去控制；第二，Unity 工程结构更重，不如 Blender 的 .blend 文件灵活；第三，数字孪生项目经常要交付给不同平台，Blender 导出 glTF、FBX、OBJ 都方便，Unity 场景却很难一键搬到别的引擎。

Three.js 则主要面向 Web 端实时渲染。它更适合做最终展示层，而不是资产生产层。我见过不少团队硬把 Three.js 当成建模工具，结果定了半天展 UV 和补面，效率很低。数字孪生项目最合理的路径是：Blender 出高质量资产 → 导出到 Three.js/Unity/UE 做运行时可视化。这一步分工清晰，后续好处会越来越明显。

2.2 为什么不用现成的数字孪生平台

市面上确实有很多可视化数字孪生平台，界面很漂亮，拖拽就能用，但我的判断是：如果项目要做深，平台类产品的天花板会很早出现。

首先是价格问题。成熟的数字孪生平台通常按数据点数、用户数、场景并发数收费，一套中型仓储项目跑一年，成本可能已经够你自己开一条工具链了。其次是定制问题。仓储物流项目几乎没有两个完全一样的，甲方经常会提“这个巷道门要能联动传感器”“这个货架颜色要随温度变化”，平台产品改起来非常痛苦，而且改完升级阶段又可能被覆盖。

用开源工具链自己搭的好处是，每一个节点你都能控制，出了问题知道去哪里改。Antigravity 负责智能调度，Blender MCP 负责建模交互，后面的数据接入和可视化层也能各自选型。对原型验证和中小规模交付来说，这种自由度比平台带来的“省心”更有价值。

2.3 MCP 这个“AI 的 USB 接口”怎么连通 Blender

很多人第一次听说 MCP，会觉得是个复杂的新东西。我打个比方：如果 AI 是一台电脑，MCP 就是 USB 接口，工具是鼠标、键盘、显示器。没有接口之前，AI 每次要操作工具，都得专门写驱动；有了统一的 MCP 规范，AI 只需要知道接口长什么样，就能接上各种能力。

具体到 Blender MCP，它在 Blender 里以插件方式运行，启动后会在本机端口监听来自 MCP 客户端的请求。客户端发来的每条指令对应一个工具，比如“获取当前场景信息”“创建一个立方体”“修改物体位置”“切换渲染模式”“导出 glTF”等。AI 代理通过这些工具感知当前 3D 场景，并做出下一次操作。

这里有一个容易踩坑的点：MCP 工具返回的是文本或文件路径，不是直接能看的大图。所以代理执行完一堆动作后，最好让它调用一次渲染或截图工具，把当前 Blender 视图反馈到对话里，否则代理会“盲操作”，容易越改越乱。我项目里所有关键节点都设置了这个反馈闭环，效果极其明显。

2.4 最小可跑架构长什么样

这个项目的最小可跑架构，简单说就是四层，不需要上服务器，一台性能还行的工作站就能跑通：

如果只是做概念验证，可以不用 Antigravity 自带的复杂工作流，直接在平台里创建一个能调用 MCP 工具的 Agent，指向本机 Blender 的 MCP 服务地址，第一轮跑通“创建地面 + 创建货架 + 渲染截图”就算成功。

有一点要提醒：MCP 服务默认是本地进程，如果你要部署到远程服务器，得考虑网络穿透和安全认证，否则 AI 代理没法连接 Blender 端。但开发调试阶段，老老实实把 Blender 和 Antigravity 客户端放在同一台机器上，是最稳妥的做法。这个建议也帮我躲过不少网络权限的坑。

3. 实操：用 Antigravity 驱动 Blender 搭建仓库场景

3.1 环境准备：三件套安装与验证

我在做这个项目前，以为难点在 Agent 设计，结果真正拦住多数人的反而是环境安装。这里直接列出我验证过的组合：

• Blender 版本：建议 3.6 及以上，最好用 LTS 版本；Blender 不同版本的 Python API 有差异，Blender MCP 对旧版本兼容不够好。
• Blender MCP 插件：从官方开源仓库获取最新版，将插件文件夹放入 Blender 的 addons 目录，在偏好设置里勾选并启用；然后找到服务启动入口，点击运行，看到“MCP server started”的提示才行。
• Antigravity 账号与工作台：注册账号并完成登录验证，进入代理创建界面，确认能配置外部 MCP 服务。首次使用可能需要验证邮箱或账号状态，这些验证信息填不对，会出现一连串访问异常，我后面第4章会讲。

安装完不要急着建场景，先做两个最小验证。第一个验证，在 Blender 里手动建个默认立方体，用 MCP 接口读取到场景中有立方体对象信息；第二个验证，在 Antigravity 的 Agent 工作台里写一句最简单的话：“调用 Blender 的获取场景工具，告诉我当前场景有什么。”如果它回答出了正确答案，说明整条链路已经打通，可以做正式的业务建模了。

3.2 创建一个“仓储建模代理”

Antigravity 的创建流程整体很自然，关键是在创建之初就把代理的“人设”定清楚。我会在角色描述里这样写：

这是一个仓储三维场景生成代理。你负责把一个仓库的业务规格转成对应的Blender三维模型。你需要严格遵守仓库设计规范，理解货架、通道、月台、分拣区、AGV路径等概念。每次动手前，先输出你的规划，再调用Blender MCP工具执行。执行完成后，渲染场景图片并反馈给用户。

这样的角色定义有特别实际的作用。第一，它强制代理先规划后动手，而不是随机生成几个东西堆在场景里；第二，它把专业术语植入了代理的上下文，让后面的对话不容易跑偏；第三，它要求反馈图片，让整个流程变得可检验。

创建完角色后，我会在 Antigravity 里给它绑定工具集。这里要注意，不同工作台对 MCP 工具的命名和权限控制不一样，需要确认 Blender MCP 相关工具是否已经出现在可用列表里，如果没有，多半是 MCP 服务地址配置错了。

3.3 先向代理描述业务语义，再让它动手

很多人在这一步会犯一个错误：上来就说“建一个仓库”，然后期待 AI 像魔法一样把仓库变出来。我现在想明确告诉你，这个期待会稳定地落空。AI 代理不是不想干活，而是它需要一个信息密度足够高的任务描述。

我会用一段仓库规划文本作为输入，有点类似给设计院提资：

仓库内部尺寸：东西长50米，南北宽30米，层高9米。
货架类型：双深度托盘货架，货架长度每排30米，总6排，排间距3米，通道宽度3.5米。
库位规则：每个托盘位宽1.2米，深1.1米，高1.5米，每层放2个托盘。
出入口：南侧设2个月台，月台宽度4米，深度6米。
AGV路线：沿中央主通道规划双向行驶主路，主通道宽度4米，次通道宽度2.5米。

这段文字里我把硬性约束都给了，且互相之间没有冲突。这时代理的“业务理解”能力才能真正体现：它能计算出排数、层数、库位数，并把这些数字落到 Blender 坐标里。

这里再分享一个关键技巧：不要让代理直接“蒙”坐标，而是先让它输出一个布局表，把每个物体的原点坐标、尺寸、数量列在表格里，你确认后，再由它批量生成。这就像先出施工图，再施工，底层的错误率降低非常多。

3.4 从一张空场景到仓库骨架的完整对话

下面我以其中一轮典型对话过程为例，展示 Antigravity 是如何通过 Blender MCP 完成建库的。

第一步，让代理清理场景。我会说：“请用Blender MCP的删除工具，清空当前场景中所有默认对象，然后创建一个名为Warehouse_Floor的平面，尺寸50x30米，位置居中。”

代理会先调用工具查看场景，发现有默认立方体，于是执行删除，然后新增一个平面物体，设置尺寸。由于 Blender 默认单位是米，且我用的是真实比例建模，这一步比较顺。

第二步，创建货架区块。我给出规划表：“沿北侧开始第1排货架，长度30米，宽1.2米，高7.8米，共8层，分3段。第1排原点放在(-15, -12, 0)。”代理会陆续执行新增盒子、修改尺寸、设置位置、复制排列等一系列操作。如果它想用坐标计算，我会提示它批量生成而不是逐个复制，这样场景结构树更干净。

第三步，生成月台和通道。月台要挂在南侧墙面外，所以我会建议代理把月台作为单独对象，叠加一个半透明的长方体表示装卸区。通道则是作为尺寸参考，我一般不生成实体，而是在场景中用一个空对象或平面轮廓表示，避免遮挡货架。

第四步，建 AGV 行驶路径。我会让代理用曲线工具创建一条从南侧月台延伸到北侧库区的折线，并设置曲线颜色为绿色。这一步非常有用，后期如果跟仿真引擎对接，这条曲线可以直接转成路网数据。

第五步，生成最终反馈。让代理调用渲染工具，把当前场景以俯视角度渲染成图片，再在对话里分析布局是否满足通道间距、货架排布是否对齐。检查完如果有偏差，我可以只提出一条修正指令，代理会精准调整目标对象，不必推翻重来。

整个流程大概需要几百次工具调用，但人的介入点只有五到六个。对比手工建模，省下的主要是重复创建和调整的时间。

3.5 交付检查：模型规范与导出

场景搭出来后，最容易被忽略的是“规范化”。你可能会想，场景能看就行，但数字孪生项目后续还要接入数据、做仿真、发布 Web，模型一旦不规范，后面全是泪。

我项目里用了三条检查标准：

• 命名规范：所有对象名带前缀，比如货架用“Rack_A01_01”，月台用“Dock_S01”，AGV路径用“Route_AGV_01”。这不只是为了好看，而是让后续业务数据能通过名称准确绑定到模型节点。
• 父子层级：一组货架的立柱、横梁、托盘位都放在一个总对象下，形成清晰的树状结构。后续要做库位高亮、状态变色，直接操作父级或者通过名称索引子级都很方便。
• 导出格式：需要给 Web 展示时，导出 glTF 2.0 格式，并勾选嵌入纹理；需要给仿真软件用时，导出 FBX，并注意旋转轴设置。Blender 里 Y 轴和 Unity/Three.js 的习惯不同，导出前要统一轴向，否则进到其他引擎经常是躺着的。

如果你未来打算用点云数据做逆向建模，或者用 3D 结构光相机采集仓库实景，这套流程还能更进一步：把生成的合成场景作为训练数据，配合点云拉框标注，能显著降低数据成本。不过那是项目后段的内容，这篇文章先不展开。

4. 出错记录、避坑建议与后续主线

4.1 我踩过的几个坑

坑一：Antigravity 访问异常和验证问题。我在刚开始折腾时遇到过平台登录后提示验证账户、403 拒绝访问、更新出错之类的情况。多数时候不是配置问题，而是账号状态没通过校验，或者某些实验功能还没对当前账号开放。我的处理方式很笨但有效：先检查账号的验证状态是否正常，关掉代理里多余的高风险工具，再等一段时间重试。这里要强调一句，尽量用稳定合规的网络环境和正式账号，别为了省事去套用乱七八糟的中转方案，安全问题不值得冒。

坑二：Agent 执行到一半直接终止。我遇到过一次“Agent execution terminated due to error”，排查后发现问题出在 Blender MCP 返回的数据结构异常，代理收到非预期格式后中断了任务。后来我在对话里强制要求“每一步执行后输出结构化结果，包括新增对象的名称和ID”，问题基本就不再出现了。

坑三：Blender 场景对象爆炸式增长。代理创建几十个货架柱子时，如果它循环执行不合并，Blender 场景树会非常混乱。解决方法是提前在角色定义里加一条“批量创建同类型对象时，尽量用关联复制或几何节点，并把生成对象归组”。实测这样操作后，对象数量减少了一大半，文件体积和渲染速度都改善很多。

4.2 给新手的两条关键建议

第一，先想清楚代理的“决策边界”。Antigravity 里的代理确实可以做决策，但你要明确哪些事它必须问，哪些事它可以直接做。比如粗定位和批量建模不需要问人，但涉及货架尺寸、通道宽度这种业务边界，我会要求它千万不能擅自改参数。有了这个边界，生成的东西才不容易出现“看起来合理，用起来翻车”。

第二，把场景检查也做成工作流的一部分。不要等到建模结束再去检查，让代理养成“每完成一个批次就渲染一次正交视图”的习惯。我通常让它在做完地面、货架、月台、路线四个批次的节点后各反馈一张图，我快速扫一眼就能发现对齐、间距、数量是否有问题。这个习惯帮我保住了很多带病上线的调度。

4.3 后续内容预告与扩展方向

这篇文章是《Antigravity + Blender MCP》（上），后面的主线我已经排好了：一是把仓库模型和业务数据打通，实现库存变化在场景里的动态反映；二是把 AGV 路径曲线接入路径规划算法，做成可交互的调度预演；三是将场景导出到 Web 端，用前端技术做轻量化展示。这几部分每块都能单独展开一篇文章，到时候我会把实操数据和踩坑记录一起放出来。

除了主线，我个人还看好两条扩展路线。一条是点云标注：合成场景能批量生成带真实坐标的“假”点云，配合人工拉框，用来训练仓储场景的目标检测模型，比纯手工标真实点云效率高得多。另一条是几何特征学习：用 3D 卷积自编码器对货架、托盘、通道做特征编码，以后做场景自动优化、库位推荐会有比规则算法更灵活的表达空间。这些都是值得持续试的方向，希望这篇内容能给你一些底层的抓手。

最后说点个人体会。AI 驱动 3D 建模这件事，现阶段仍然需要人去定义清晰的问题、可执行的步骤和验收标准，但它把从前“建模师干到半夜”的体力活，变成了“在对话里把规则聊清楚”的智力活。真实落地时，我建议你从极小切口开始，比如只做一个仓库区域、三条货架、一条路线，跑通后再慢慢放大。一步到位做大场景，只会更快把一整套问题全冒出来。

我现在的习惯是，任何新项目都先用这套组合做出一版粗糙但可迭代的底座，再往“真实感”和“业务深度”两边走。毕竟数字孪生到最后，要比拼的还是你对业务的理解和跟 AI 协作的方式。