前阵子接手一个智慧仓储的前期原型，客户要得其实很朴素：把仓库里的货架、托盘、AGV通道做成一个3D场景，让业务方在浏览器里能直观看到整体布局，后期还要叠加上库存数据和传感器状态。按老路子走，要么上UE5、Unity从零搭数字孪生底座，要么用Three.js手写一大堆几何体代码，周期都不短。这次我换了一条新路径：Antigravity + Blender MCP，从空白文件到有模有样的仓储3D场景，基本是“把模型聊出来的”。

先解释这几个关键词。Antigravity是一个AI代理开发平台，你把任务用自然语言写清楚，它能自动拆解、编排并执行多步骤的Agent任务；Blender MCP则是给Blender安装的一个MCP服务端，让AI可以通过标准协议直接调用Blender的建模能力。两者一接，等于给AI装上了“三维画笔”。这篇内容适合正在做数字孪生园区、智慧仓储或物流仿真的工程师、前端开发者，也适合想快速出三维可视原型的产品经理。我会把环境配置、建模实操、踩坑经验全部拆开讲，你照着做，半天之内就能跑通第一个仓储场景原型。

1. 场景定调：智慧仓储数字孪生项目怎么搭第一张“底图”

1.1 数字孪生建模的核心不是“像”，而是“结构化”

很多人一听数字孪生，第一反应是要做高精度模型，恨不得把货架每颗螺丝都建模出来。这个思路在数字孪生项目里恰恰是最大的坑。数字孪生的价值在于物理世界与数字空间的映射和联动，重点在“孪生关系”，不在“像不像”。

仓储场景里最需要表达的东西，归纳下来就四层。第一层是空间结构，库房多大、层高多少、收货区和发货区在哪，这决定了整个场景的骨架。第二层是资产位置，货架在哪排、托盘放在哪个货位、AGV从哪条路走，这决定了业务逻辑能否在三维空间里讲清楚。第三层是运动状态，AGV当前在哪、是否在搬运、路径是否拥堵，这是后期做仿真的基础。第四层才是外观表现，材质、光照、渲染效果，这部分恰恰是最不值得初期投入精力的。

所以我给团队定的原则是：原型阶段只做“结构化粗模”。货架用Box组合，AGV用带圆角的长方体，托盘用标准几何体堆叠。每一个对象在Blender里有一个干净的命名、一个明确的层级归属，比它长得好看重要一百倍。后面到了演示或投标阶段，再针对关键设备单独替换高精度模型，完全来得及。这就像画建筑草图，先用线条把空间关系定住，再谈装饰细节。

1.2 为什么选择Antigravity + Blender MCP而不是传统建模方式

选型这件事，我对比了几条常见路径。传统纯手工Blender建模，一个熟练建模师搭出像样的仓储场景也要一到两天，而且后期需求一改，返工成本非常高。用Three.js直接写前端三维，对团队前端能力要求高，每次调整布局都要改代码，迭代速度慢。直接上UE5或者Unity的数字孪生模板，功能确实全，但对小团队来说偏重，起步成本和运行时开销都不小。

Antigravity + Blender MCP这套组合，核心优势是把“人操作三维软件”变成了“人指挥AI操作三维软件”。Blender MCP把Blender的Python API封装成AI容易调用的工具，Antigravity负责把自然语言需求拆解成一个一个具体的Blender操作并执行。相当于AI是设计师，Blender是画板，你只需要跟设计师说清楚需求和约束。

补充一点，这并非要取代重型数字孪生平台。它的定位是“原型验证器”和“项目加速器”。标书演示、方案验证、教学演示、早期产品规划，这类场景里需要快速得到一个能看、能讲、能迭代的三维场景，这套组合的性价比极高。等场景复杂度上来了，再把整个项目迁移到Unity或UE继续深化，那时候你的Blender源文件就是最好的蓝图。

2. 环境搭桥：Antigravity、Blender与Blender MCP插件的连线步骤

2.1 Antigravity项目创建与MCP服务器配置

先登录Antigravity控制台，新建一个项目，我给这个项目起名Warehouse-DT，类型选择Agent构建。创建完成之后第一件事不是急着写提示词，而是把项目背景和建模规范写进项目根目录下的AGENTS.md文件。

这个习惯是从实际踩坑里养成的。Agent的记忆和上下文有限，你每次对话都重复“单位用米、对象按前缀命名”，既啰嗦又容易遗漏。把这些规则固化在配置文件里之后，每次运行Agent它都会自动加载这些上下文，效果稳定很多。我用的模板大致长这样：

# Warehouse-DT 数字孪生项目 ## 项目目标 在Blender中搭建一个40m x 20m智慧仓储三维场景，用于仓储布局演示和数据联动验证。 ## 建模规范 - 单位统一使用米（Meters），场景尺寸必须符合现实物理尺度。 - 所有对象按前缀命名：Shelf_, Pallet_, AGV_, Path_, Marker_, AOI_。 - 货架标准规格：双排货架，宽2.4m，高2.4m，5层。 - 托盘采用1200mm x 1000mm标准规格。 - 模型优先用基础几何体组合，保持低多边形，限制单个对象面数。 - 每个货架、托盘、AGV必须挂载唯一的ID属性，命名规则见项目说明。

配置文件准备好之后，在Antigravity项目设置里找到MCP Server配置项。这里需要添加一个HTTP类型的MCP服务端点，指向运行Blender MCP插件的那台机器。如果Agent是跑在本机上的，填localhost地址和对应端口就能连通；如果Agent运行在云端，则需要填局域网IP或通过安全隧道暴露的公网地址。

2.2 Blender端安装Blender MCP插件并建立通道

Blender端准备工作分两步。第一步是安装Blender MCP服务端依赖，在Blender内置Python终端里执行：

pip install blender-mcp

如果你的Blender环境比较干净，这一步通常不会出问题。装好之后，打开Blender的偏好设置，在插件管理里面找到blender-mcp相关插件并启用。启用后插件会提供一个“启动MCP Server”的按钮，点击它会拉起一个本地服务，同时终端会打印出监听端口和连接地址。

默认端口常见是9876，但也可能因为环境不同而有变化，一定要以插件启动日志里打印的地址为准。为了验证服务确实起来了，可以直接在浏览器里访问对应的HTTP地址，能看到一个响应页面或者收到连接回调说明服务正常。

接着回到Antigravity项目的MCP配置里，把服务类型选为streamable-http，URL填上刚才看到的地址。保存配置后，Antigravity会自动测试连通性。这一步满不满分不重要，后续真正执行Agent任务时才能验证完整链路。配置参数我整理了一张表，方便直接对照：

这里有个容易忽略的问题：如果Blender跑在你本地，而Antigravity的Agent跑在云端，Agent是无法直接访问你电脑上的localhost的。解决办法要么把Blender MCP服务部署到一台内网或公网可访问的机器上，要么把Antigravity的Agent运行环境拉到本地网段。这一步别偷懒，链路不通后面全白搭。

2.3 第一次握手：验证Agent能操作Blender

环境配好后，先在Antigravity里发一条最简单的指令验证链路：“检查Blender连接，删除默认场景中的所有物体，然后新建一个名为Ground的平面，尺寸为50米乘30米。”

正常情况下，Agent会调用一系列Blender MCP工具，Blender视图里能看到默认的Cube被删除，一个大型平面被创建出来。如果这一步通了，整个管线就证明已经打通了。我实测的时候，这个验证过程一般不超过两分钟。

这里有一个必须提前说的常见坑：Agent返回“连接失败”，但Blender里操作其实已经执行了。这种诡异情况通常是因为协议握手成功但消息回传超时，或者生产端把错误信息吞掉了。遇到这种情况，先别急着怀疑环境，直接看Blender场景里有没有变化，再检查本地MCP插件的终端日志。日志比Agent的报错信息诚实得多。

3. 动手实操：从空白场景到完整智慧仓储模型的四步流程

3.1 建库前先定规划：尺寸、单位、命名规范

建模前不规划，后面一定乱成一锅粥。我这次以40米长、20米宽、6米高的仓库为例。整个场景划分为四个功能区：收货区、货架存储区、发货区、AGV通道。收货区放在仓库左边，规划尺寸5米乘8米；货架存储区在中间偏右，分成两组双排货架；发货区在右侧，也是5米乘8米；AGV主通道宽度设计为2米，连接收货和发货区。

通道宽度这个参数是有讲究的。AGV在通道里要完成直线行驶和L型转弯，转弯半径通常按1米设计，所以主通道低于2米就会出现转弯死区。我们给Agent下指令时，要明确交代这些尺寸，而不是让它自由发挥。

这里顺便提一下3D点云拉框。如果仓库现场有激光雷达或结构光相机扫描出来的点云底图，第一步应该先把点云导入Blender作为参考底图，然后用Cube包围盒把每个货架区域“框”出来，这就是数字孪生里常说的AOI拉框。这些Cube统一用AOI_前缀命名，后续无论是做点云标注、数据对应还是算法训练，都能直接复用这个标准。

正式开始建模前，还有两个动作必须在指令里明确。第一是单位设置，在Blender的场景属性里强制Metric加Meters，防止后期导入导出时出现放大缩小100倍的混乱。第二是所有对象命名规范，我给Agent定的规则是：货架Shelf_01_01表示1号货架第1排，托盘Pallet_0101表示1号货架01层的第1个托盘位，AGV用AGV_01、AGV_02递增。这套命名在后面的数据绑定阶段会救你的命。

3.2 货架和托盘：让Agent批量生成标准件

规划完之后，我给Antigravity发了一条指令，大致内容是：“在地面区域创建5组双排货架，每组宽2.4米、高2.4米、5层，立柱和横梁用金属灰色材质，货架间距对齐AGV通道边缘。”

有意思的是，Agent在执行这种批量重复任务时表现得相当稳定。它会自动写一个循环脚本，在Blender里把5组货架按等间距创建出来。如果你让它一次性创建50组，它大概率也能跑完，但中间一旦某个参数写错，排查起来就头大。我的习惯是第一次先建5组，看整体比例和位置没有问题，再复制阵列扩展数量。宁可多花几次对话，也不要一次吃成胖子。

托盘建模的要点在于标准尺寸。我们用的是1200毫米乘1000毫米的标准木托盘，顶部放一个简化的周转箱，周转箱颜色可以做区分：蓝色表示在库、绿色表示待出库、红色表示异常。这一步看起来只是颜色选择，实际上为后期数据驱动模型留了伏笔，等真正接到WMS库存数据时，颜色可以直接映射库存状态。

这里给一个提示词模板，实测下来效果不错：

在Blender当前场景中批量创建托盘模型： - 托盘规格：长1.2米，宽1.0米，高度0.15米 - 托盘上增加周转箱：尺寸0.6m x 0.4m x 0.3m - 周转箱材质颜色：蓝色 - 所有物体按Pallet_前缀命名，并添加到Storage集合中 - 将托盘放置在货架每层的地板上，每个货位放置1个 - 完成后在输出中列出已创建的托盘数量和位置

做完这步，一个仓储场景的“骨架”和“血肉”基本到位了。地面、货架、托盘、区域划分都有了，接下来是在这个基础上做动态元素。

3.3 AGV小车与运行路径：从静态模型到可模拟动线

AGV建模没有什么神秘感，客户并不要求看到齿轮和电路板，他们要的是能体现“这个设备在这条路上跑”的逻辑。我用最简单的组合方式：一个底盘Cube加一个顶部箱体Cube，再在车体顶部加一个圆环作为识别标识，整体挂在一个名为AGV_01的空物体下面。这样后面要做动画或接入真实位置数据时，直接控制空物体的位移就够了。

AGV的初始位置放在收货区充电桩旁边，指令里要写清楚坐标。路径是本小节的重点，我让Agent用Bezier曲线绘制AGV从收货区到货架区、再到发货区的行驶线路。如果指令里只说“画一条路径”，Agent生成的曲线大概率是随机的，后期调整起来非常痛苦。正确做法是显式指定控制点坐标：起点在收货区出口，途经货架区主通道中点，终点在发货区入口，每个控制点都给出具体坐标值。

路径曲线生成之后，需要在曲线属性里设置粗细，让它在视图里一眼可见。再给路径指定一个Emission自发光材质，主色用绿色。这条路径线不只是好看，它还是后续仿真和调度的关键。实际的车辆调度系统如Nav2这类导航方案，用的也是类似“关键点路径”的思路，我们在数字孪生场景里把这些路径控制点坐标导出，就是现成的waypoint表，可以直接和调度算法做联动。

这一步还涉及一个细节：曲线生成要分步走。先让Agent生成曲线，再单独发指令设置曲线粗细，最后发指令设置材质。一次性让Agent完成三件事，中间出错的概率明显变大，毕竟曲线对象和端点的选择在MCP工具链里是需要精确匹配的。

3.4 预留孪生数据接口：命名、层级与Custom Properties

模型建完不接数据，就只是个空壳子，不算真正的数字孪生。所以在建模阶段就要预留数据接口，最基础的两个动作是层级整理和自定义属性挂载。

层级整理靠的是Blender的Collection体系。我给这个项目分好了四个集合：Structure放地面和墙体，Storage放货架和托盘，Equipment放AGV和路径，DataUI放文本信息面板。所有对象必须在对应集合下面，严禁孤儿对象堆在场景根目录。这个规则看似死板，但场景一复杂，没有Collection管理的文件根本没法看。

自定义属性是Blender里非常好用的机制，选中任何一个对象，在对象属性面板里可以添加自定义字段。比如选中AGV_01，添加一个名为status的字符串属性，初始值为idle；再选中某组货架，添加temperature和stock_qty两个属性。这些字段看起来不起眼，但它们是未来数据回灌的“插座”。Antigravity生成的Agent可以通过MCP工具直接读写这些属性，后续库存数据进来，脚本直接更新对应属性值，模型状态就会跟着变化。

信息展示层我用Text对象来做。在场景右上区域创建几个文本对象，显示“温度：24.5C / 湿度：45%RH / 在库数量：1280”，这些文字对象放进DataUI集合，后期Web端或仿真平台可以通过API实时刷新。说到后续扩展，如果要接点云场景理解、3D卷积自编码器特征提取这类算法，前期规范的命名和包围盒对齐也能帮你省掉大量拉框标注的人工成本。

4. 踩坑记录：Agent建模过程中最容易翻车的五个环节

4.1 Agent执行中断：报错信息怎么读

跑Agent建模时遇到最多的就是执行中断。Antigravity控制台经常会弹出一句“agent execution terminated due to error”，第一次看到这个报错我整个人是懵的，因为错误信息太泛了。后来总结出规律：这种中断多数发生在Blender侧出现异常，比如Python解释器内存占用过高，或者执行了超长时间的批量循环导致会话超时。

解决办法很朴素。把大任务拆小，每条指令只让Agent做一类事情。一次创建5组货架没问题，一次创建50组就容易被干掉；一次生成一条路径没问题，一次生成10条交叉路径就非常容易让Blender卡死。另外，Agent运行期间Blender里别开着材质预览和实时渲染，那些功能极其消耗资源。

还有一类报错是“eligibility check failed”，这个一般跟项目权限或账号资格有关。处理办法是先检查登录状态是否过期、当前账号是否有运行Agent的权限，实在不行换个节点网络再试。这类问题不是代码层面的，排错重心放在账号和网络环境上。

4.2 MCP连接失败：五类典型场景排查

MCP连接失败是第二个高频问题，我遇到过的情况可以分成五类。

第一类，插件没启动。Blender里没点“启动MCP Server”，端口自然没有监听。排查方法是在命令行执行netstat -ano命令，看目标端口是否有进程在监听。

第二类，监听正常但连接超时。这种情况通常是防火墙拦了入站连接，尤其是Windows系统第一次启动MCP服务时会弹出防火墙授权窗口，一旦点了取消，后面就再也连不上。到系统防火墙设置里把对应端口放行即可。

第三类，最坑的一种：Agent在云端，根本访问不了本地localhost。你本地服务起来再多也没用。解决思路是要么在配置MCP时填写局域网内可达的地址，要么用安全的方式把服务暴露到Agent可以访问的地址。生产级别的调试最好把Blender装到有公网IP的专用机器上。

第四类，Blender界面卡死但进程还在。这种情况多发生在插件主线程被Agent的长任务阻塞时，视图半天不刷新，你以为挂了其实它还活着。先等几分钟恢复，如果始终没反应就强制重启Blender再重新启动MCP Server。实测下来，频繁切换视图着色模式最容易触发这个问题。

第五类，服务恢复正常但Agent还是报连接失败。这种时候把MCP Server在一端重新启动一次，相当于重启服务清空缓存，比反复检查配置有效得多。

4.3 模型“看着不对”：单位、着色模式与父子关系检查

模型生成出来但是视觉上不对，先别急着怪Agent，我先说三个最重要的检查项。

第一是单位错乱。Blender里如果单位设置成了厘米，但是指令里按米描述尺寸，生成的模型就会巨大无比或者缩成一点。检查场景属性里的Unit System，确认是Metric且Scale为0.01。这个细节导致的经典症状是：导入模型后整个场景放大100倍。

第二是着色模式问题。很多“没材质”的现象其实是视图着色模式停在Solid线框模式，模型看起来灰扑扑的甚至只剩线框。在Blender右上角把视图切换为Material Preview，真实材质效果立刻就出来了。这个不是建模错误，是显示设置问题。

第三是父子关系跑偏。父级物体带着旋转角度，子级物体创建时坐标就跟着偏移。遇到这种情况直接选中所有父级物体，执行Apply All Transforms，把变换归零，再让Agent基于世界坐标重新生成。模型看起来“歪”的时候，多半是这个原因。

我把这套检查顺序总结成了口诀“单位、着色、父子”，让团队的实习生先按这三项自查再找我确认，效率一下子高了很多。

最后说一句实际体会：Antigravity + Blender MCP这套组合最适合解决的问题，是把一个模糊的需求快速变成一个能看、能讲、能迭代的三维场景。它不会让建模师失业，反而把数字孪生项目起步阶段的时间成本压缩到半天以内。这个项目做下来我最大的感悟是：在让AI动手之前，把命名规范、单位制式、场景分层这三件地基打牢，后面所有数据联动都会顺滑很多。下篇我准备继续写数据回灌的部分——真实库存数据和传感器状态怎么驱动这些模型动起来，以及如何导出GLTF到前端完成最终展示。如果读者朋友正在推进类似项目，建议从小场景开始，20米见方的库房、5组货架、2台AGV，先完整跑通一次，再大规模铺开。