搞前端数字孪生的人应该都有同感最折磨人的往往不是写代码而是3D资产怎么来。拿到一个智慧仓储项目CAD图纸是有的货架尺寸也有但要把几百组货架、几千个SKU托盘一个个手工摆进 Blender 或者 Three.js光是体力活就能耗掉一两个星期。最近我把 Antigravity 和 Blender MCP 串起来试了一条新路子让 AI Agent 直接操作 Blender 建模把仓库场景从零开始长出来。这篇文章就是这次实践的上半部分重点讲如何把这条建模工作流跑通以及用自然语言批量生成仓储三维资产的完整方法。适合正在做 3D 数字孪生、Web3D 可视化或者想尝试 MCP 驱动建模工具链的朋友参考。1. 为什么是这套组合先想清楚再动手1.1 数字孪生项目里的3D资产困局做数字孪生和普通3D可视化项目有一个很大的区别它不是做一个好看的模型就完事而是要保证场景里的每个物体都对应真实世界的业务数据。比如仓库里的货架前端页面上点击它要能查询库存AGV 在场景里移动时位置要能跟调度系统的实时数据对上。这意味着模型不能只是好看还得有稳定的命名、坐标、尺寸和层级结构。但实际项目里三维资产的来源往往很尴尬。让建模师手搓周期长、沟通成本高让开发自己用 Three.js 写几何体简单的小仓库还行一旦到几千个物件的量级写代码也得写很久用现成的仓库模型库又跟实际布局、尺寸对不上。最麻烦的是改版——甲方一句货架间距调一下或者SKU 数量变了手工模式下基本等于推倒重来。我试过让大模型直接生成 Three.js 代码来搭场景效果一般。AI 确实能写出合理的代码但生成复杂几何体、处理坐标变换、做材质细分这些高精度操作表达在代码里非常啰嗦而且运行起来跟预期差距很大。一个大模型对画出整个仓库的货架这种需求的建模能力远不如它对写一段 JSON那么可靠。后来我意识到问题不在于 AI 的能力而在于执行链路AI 擅长的是理解和拆分任务真正能精确建模的应该是 Blender 这类专业工具缺的只是中间那座桥。1.2 Antigravity 和 Blender MCP 各自解决什么问题Antigravity 是个云端的 AI 集成开发环境跟普通在线编辑器不一样的地方在于它把 Agent 当成了核心工作流。你可以在项目里直接跟 Agent 对话让它读文件、写代码、跑命令而且它原生支持 MCP 协议可以在配置面板里接入各种 MCP Server。对我这种常年跟多个数据源打交道的人来说这个特性刚好踩在点上。Blender MCP 是社区里的一个开源插件原理不复杂它让 Blender 开启一个本地服务监听 MCP 请求AI 客户端通过 MCP 协议调用暴露出来的工具比如创建物体、修改属性、删除对象、执行 Python 代码Blender 这边收到指令后就在场景里实时操作。代码层面的实质是把自然语言翻译成 Blender 的 Python API 调用。这两个东西拧在一起就形成了一条很有意思的流水线Antigravity 当大脑负责理解需求、拆解任务、读取数据、生成参数Blender MCP 当手负责执行建模命令。以前是我写好需求让建模师去做现在是我把需求告诉 AgentAgent 调用 Blender 里的工具直接建模。对于仓储这类参数化很强、重复度很高的场景这种组合的提速效果非常明显尤其是批量生成和后期统一改尺寸效率差一个数量级。1.3 工作流全貌我先说清楚整个工作流的全貌方便你判断哪些环节值得照搬。我目前在用的流程是这样的仓库的布局参数长宽、货架排数、巷道宽度、货位格数先整理成一张表SKU 库存数据导成 CSV把这些资料丢给 Antigravity让它作为 Agent 的上下文Agent 根据任务拆分通过 MCP 调用 Blender 里的建模工具一栋货架、一排货架、整个仓库一层层生成出来模型建好后在 Blender 里整理命名和层级导出 glTF前端用 Three.js 加载渲染。这篇先讲场景建模这一段环境怎么搭、MCP 怎么接通、用什么 prompt 让 Agent 按仓储逻辑生成模型、导出前怎么优化。下篇再写数据驱动的实时联动比如 IoT 数据进来后货架颜色怎么变、AGV 路径怎么跟着调度走。关于版本这里要预先提醒一句Blender 4.x 之后部分 Python API 调整过老一些的 Blender MCP 插件在 4.0 以上偶尔会报兼容性错误。我验证下来稳定性最好的是 Blender 3.6 LTS如果你是照着这篇文章做最好先在这个版本上跑通再去折腾新版。2. 环境准备与插件安装2.1 Blender 版本选择和插件安装先说两个最基础的选择。Blender 不是越新越好尤其在接 MCP 这种社区插件的时候稳定压倒一切。我本地用的是 3.6 LTS原因很实际Blender MCP 插件的主要测试环境就是它遇到问题好查3.6 的 API 对 Python 脚本执行也更宽容。后面如果要切换到 4.2 LTS也不是不行但请做好小概率兼容问题自己动手改的心理准备。插件我用的主要是ahujasid/blender-mcp这个开源项目直接在 GitHub 下载 zip 包。安装路径是Edit → Preferences → Add-ons → Install选择 zip 后勾选启用。这里有个小经验不需要手动解压Blender 会自动把 zip 复制到插件目录。装完之后左侧边栏或者 3D 视图的 N 面板里会出现 Blender MCP 的标签页。2.2 启动 Blender MCP Server在 Blender MCP 标签页里先确认 MCP Instructions 区域的内容。这个输入框里的文字会被发送给 AI 客户端起到给 Agent 交代工作规范的作用。我一开始留空结果 AI 生成的模型总是命名混乱、比例奇怪后来在 Instructions 里写清楚单位使用米、对象命名使用小写加下划线、优先使用 bpy 原生 API、不要在场景里留默认立方体之后输出质量稳定了很多。配置好之后点Start MCP Server正常的话界面会提示服务已在某个端口启动默认一般是 9876。我建议这时候顺手做个验证在 Antigravity 的终端里执行一下端口探测或者在本地浏览器里访问对应的地址确认服务确实在监听。我之前遇到过插件面板显示已启动但实际端口没开的情况多半是端口被占用或者防火墙弹窗没允许。另一个容易忽略的选项是Auto-apply code。打开了它AI 返回的 Python 代码会自动在 Blender 里执行不用人工确认速度快很多适合批量建模。但如果你是第一次跑或者 Agent 生成的代码明显不可控建议先关掉改成手动审阅。否则一条错误的建模指令可能让场景里多出几千个垃圾对象清起来很痛苦。2.3 在 Antigravity 中接上 MCPAntigravity 里的操作分几步。先打开项目的设置面板找到 MCP Servers 配置入口这里可以添加自定义 Server。填法上Name 随意关键是 Transport 和 URL 要跟 Blender MCP 对齐如果你的 Antigravity 版本走 WebSocket就填ws://你的主机地址:9876如果只支持 HTTP 模式就填对应的http://你的主机地址:9876。这里的主机地址按Blender 跑在哪台机器上来理解就行Blender 和 Antigravity 在同一台机器填 localhost 或 127.0.0.1不在同一台填 Blender 所在机器的局域网地址。填完之后先别急着建模发一条最简单的指令测试让 Agent 调用 MCP 里暴露的工具比如列出当前 Blender 场景里有哪些物体或者创建一个默认立方体。如果 Agent 能正常返回执行结果、Blender 视口里能看到变化说明链路通了。这一步我踩过的坑是Antigravity 不同版本对 MCP transport 的支持有差异有时候 UI 上只给了 HTTP 选项但 Blender MCP 默认是 WebSocket两边语言不通连接就一直失败。遇到这种情况别在配置界面死磕去查一下当前版本支持的协议格式按它要求的来。提示MCP 服务只要 Blender 开着才有效。我习惯先把 Blender 开着、MCP 服务启动好再去 Antigravity 里对话。如果哪天 Agent 突然听不懂建模指令了先回 Blender 看一眼 MCP 服务是不是还在跑。3. 用自然语言把仓库“画”出来3.1 最小闭环验证先让 Agent 建一个立方体我第一次验证通道指令给得很保守删除场景里的默认立方体在原点创建一个边长为 1 米的立方体命名为 test_box。等 Blender 视口里出现那个新立方体的时候我基本确认这条路走得通。这条指令的链路是Antigravity Agent 理解人类语言 → 从 MCP 工具列表里选出合适的建模工具 → 填好参数发给 Blender MCP → Blender 执行 Python 代码 → 视口更新。这个最小闭环为什么值得先跑一遍因为它能一次性验证三个关键环节MCP 服务是否在线、Antigravity 能否正确调用工具、Blender 侧能否按参数生成物体。任何一步出问题都能在这个极简场景里暴露出来不用拿整个仓库来试错。另外这也是给 Agent 立规矩的机会——我从第一条指令就带上命名要规范的要求后面它生成一堆物体时命名基本都在可控范围。3.2 参数化生成货架阵列最小闭环跑通后就可以进入正题了。我以自己做的仓库为例把参数先说清楚仓库 60 米长、40 米宽6 排货架每排 20 列、5 层单组货架单元宽 1.2 米、深 0.8 米、高 2.4 米排与排之间的巷道留 2.5 米。这些数据来自 CAD 图纸我原样发给 Agent没有让它自由发挥。Agent 第一次尝试的时候我给的指令是生成 6 排货架。结果它确实生成了但朝向乱来、间距不均、坐标乱七八糟整个场景像被打散过的乐高。后来我把指令改成带坐标和循环逻辑的形式货架单元尺寸 x1.2y0.8z2.4单排 20 列列间距 0.1 米从左侧起点沿 X 方向排列共 6 排排间距 3 米沿 Y 方向偏移所有货架对象放入名为 Shelves 的集合命名前缀为 shelf_。这么一改出来的场景就规矩多了。核心就一个原则给 AI 的参数越具体结果越可控。不要指望 AI 能理解仓储排布是横排还是竖排你必须把坐标系、方向、间距全交代清楚。这一步还有个隐藏好处参数化之后后续调整成本极低。甲方说货架间距要改成 3.5 米我不需要把每个货架手动拖一遍直接在对话里告诉 Agent 刚才的参数里排间距改为 3.5重新生成整个 Shelves 集合就行几秒钟完成一次整体变更。这在手工建模流程里简直不敢想。3.3 结合CSV数据批量生成货物光有货架还不够仓库里得有货。这块我用 SKU 库存表来驱动把 CSV 数据交给 Antigravity让它读入后直接映射到建模指令上。下面是一个简化的 CSV 示例sku_id,货位,quantity,box_size SKU001,A-01-03,12,0.4 SKU002,A-01-04,6,0.5 SKU003,B-02-01,24,0.3Antigravity 可以读取项目里的文件我把这个 CSV 放进项目目录然后给 Agent 指令读取 stock.csv按货位列把每个 SKU 对应的箱子放到正确货位上箱子尺寸用 box_size 字段命名用 sku_id 加前缀 box_。实际效果确实能跑。Agent 会先解析 CSV然后把每个箱子建模到指定货位。这里我踩了一个坑CSV 里货位是 A-01-03 这种业务编码Agent 一开始没法把它转成世界坐标。解决办法是让我先给它一张货位编码 → 坐标映射表或者干脆在 CSV 里加上 x、y、z 三个坐标列。有了坐标列Agent 就纯按坐标摆箱子准确率高很多。这次批量生成的箱子数量大概在七八百个。Blender MCP 执行时是按脚本循环创建速度很快但场景对象多了之后会有点卡。我建议大数量批次拆成几次执行比如每次生成一个货架的货而不是一次性生成全场。这样既方便检查也避免一次性指令过长把 Agent 搞蒙。材质颜色我用了库存量阈值来区分库存充足是绿色中等是黄色偏低是红色。这个不是纯视觉美化后续做数字孪生前端的时候它就是库存健康度的前置表达能力导出后前端可以直接读材质颜色映射业务状态。3.4 路径、区域与视觉标记货、架都有了还得让场景看起来像一张规划图。我先让 Agent 画 AGV 行驶路径给出一串路径点坐标用贝塞尔曲线连起来再给曲线设置一个细的挤出宽度变成地面上的路径线。路径线的作用在后期特别大因为调度数据进来之后AGV 位置可以用一个替身物体沿着这条曲线移动前端看到的效果就很接近真实调度了。然后是区域划分。存储区、分拣区、出货口、暂存区我让 Agent 在地面上生成不同颜色的半透明平面每个平面用 collection 区分。这一步的作用是让场景有可读性不管是给客户汇报还是自己调试数据绑定一眼就能定位区域。最后我放了两个固定视角的摄像机一个是俯视全景用来总览一个是出货口附近的三分之一视角用来看细节。加上一盏区域光导出预览图后整个场景终于从一堆灰模变成了像回事的仓储示意图。4. 给前端用的模型导出与优化4.1 导出格式怎么选场景建完不等于可以直接给前端用得先决定导出格式。我的原则非常简单目标前端是 Three.js那就用 glTF/GLB。glTF 是 Web3D 生态的事实标准PBR 材质、场景层级、动画、骨骼都能保留Three.js 加载器开箱即用GLB 是它的二进制封装单文件便于分发。FBX 和 OBJ 不推荐在这条链路里用。OBJ 太裸材质和层级信息都不全FBX 是 Autodesk 生态的东西导出到 Three.js 后材质经常要返工。3D Tiles 这个格式也经常出现在数字孪生的讨论里但它更多是给大规模倾斜摄影或者 GIS 场景用的仓库这种室内精细场景用不上别被绕进去。4.2 导出前必须处理的命名、原点和比例导出这一步我吃过大亏先说最容易出问题的命名。AI 生成的物体一开始命名是随缘的比如Cube.023这种前端脚本根本没法通过名字判断它是货架还是货物。后来我在建模阶段就让 Agent 严格执行命名前缀货架用shelf_货物用box_路径用path_区域平面用zone_。前端加载 GLB 后GlTFLoader 返回的 scene 里每个节点都有名字前端可以直接通过前缀过滤出需要的对象不用一个个手工映射。原点问题也值得注意。Blender 里如果某个货架的几何中心不在原点导出到前端后它绕自身旋转或者定位会非常别扭。我的做法是建模时就让 Agent 把每个物体的原点设置到几何中心。配合1 Blender 单位 1 米的约定前端拿到模型就不用再做换算物体尺寸、位移全是真实世界的米省掉很多麻烦。材质方面有个容易踩的坑Blender 里如果用了 Cycles 特有的材质节点导出 GLB 时会丢。我的建议是统一用 Principled BSDF这是 glTF 导出器能映射的 PBR 材质。仓储场景不需要花哨的次表面散射Principled BSDF 完全够用。4.3 性能优化三板斧仓储场景的对象数量很容易失控。我第一次导出整个仓库的 GLB差不多三千多个独立对象前端加载后帧率惨不忍睹。后来我总结了三板斧第一合并静态对象。货架这类完全不会动的物体在 Blender 里直接把整排货架合并成一个对象减少前端 draw call。合并之后场景树会简洁很多代价是失去单个货架单元的独立性。权衡办法是需要跟数据绑定的对象不合并比如每个 SKU 箱子要保持独立因为它要响应点击和状态变化纯装饰性的那就合并掉。第二利用集合和实例化。Blender 里做关联复制或者集合实例导出 GLB 后 Three.js 可以配合 InstancedMesh 或者骨架来处理重复物体。货架和标准托盘是高频重复物体用实例化之后前端性能会好看非常多。第三开启压缩导出。glTF 导出面板里可以勾选 Draco 压缩对几何体顶点数据进行压缩文件体积能显著下降。室内仓储模型的几何精度要求不高默认压缩参数即可。第一次导出的 GLB 如果前端加载后显示有破面或闪面多半是压缩比例过高或者几何体重叠调低参数再导一次就行。导出的操作本身可以让 Agent 在 Blender MCP 里执行它会用bpy.ops.export_scene.gltf自动完成比手动选菜单位置要快。但导出前我会手动检查一遍命名前缀和原点这两样错了导出后前端绑定数据的返工成本比建模还高。5. 常见问题与排查技巧实录5.1 MCP 服务连不上这是最常见的问题没有之一。我把遇到过的现象和排查思路整理成了一张表现象可能原因处理方法Agent 提示无法连接 MCP ServerBlender MCP 服务没启动回到 Blender 点 Start MCP Server确认提示成功连接超时端口被占用或防火墙拦截检查 9876 端口占用情况必要时换端口放行防火墙Agent 能连上但工具列表为空transport 协议不匹配确认 Antigravity 当前支持的是 HTTP 还是 WebSocket按格式调整指令执行了但 Blender 无反应主播机 Antigravity 与 Blender 不在同一环境地址填错检查 MCP 配置中的地址是否为 Blender 所在机器可访问的地址排查的时候有个好用的小工具在 Antigravity 的终端里手动访问一下 Blender MCP 的地址如果能得到响应说明服务在线如果连接被拒问题就在地址或端口上。这个办法能快速缩小排查范围比反复跟 Agent 对话高效得多。5.2 Agent 建模指令“翻车”了怎么办AI 生成代码不是每次都能跑对。我遇到的典型翻车场景有三种。第一种是调用了不存在的 bpy API。Blender 的 Python API 更新频繁Agent 有时会按自己的理解写出已经被移除的函数或参数。解决办法是把 Auto-apply code 关掉改成让 Agent 先生成代码你审一眼再执行或者直接在 Instructions 里注明使用 Blender 3.6 的稳定 API。第二种是坐标和单位乱套。一个很常见的问题是 Agent 把米和厘米搞混生成的货架比仓库还高。这在最初几次建模时频繁出现。我的办法是每一次建模指令里都重申一遍单位并且用具体数值来约束货架高度 2.4 米列间距 0.1 米不要自行缩放。明确得越早返工越少。第三种是生成到一半自己乱了。比如生成货架时Agent 写到第 20 列突然跳跃到最后或者把所有货架叠在了一起。这种基本没法局部修我的建议是直接让它删除集合 Shelves 中所有对象重新生成并且把生成脚本固化下来——同一套参数重新生成的结果是一样的可控性反而更强。5.3 工程化方面的坑再多说几句工程化上的体会。Blender 的 .blend 文件是二进制格式git 没法对它做 diff多人协作或者版本回溯都很别扭。我的做法是不依赖 .blend 文件来保存工作成果而是把每次让 AI 执行的生成脚本单独存成.py文件放进项目仓库里。这样改参数、重跑、对比效果都清清楚楚AI 生成的随机性风险也降下来了。命名规范这块前面提过多次但值得单独强调。数字孪生场景只要过了几十个对象命名一乱基本没法维护。我在 Instructions 里写死了一套规则所有对象用英文小写加下划线前缀表示类型后面跟序号。这套规则不只约束 Blender 场景里看得见的对象也约束集合和材质命名。到后面上 Three.js 的时候你会发现这套命名规范省下来的时间远超当时花的那一点。还有版本快照。每次大改之前我会用File Save As另存一个带日期的 .blend避免 AI 一通操作把场景改到没法回头。虽然重跑脚本能重建但有时现场微调的手工操作是脚本没有覆盖的快照还是得上。最后的几点大实话这套流程我用下来的体会是MCP 建模链路的真正价值不是省掉了建模工时而是把建模这件事从手工操作变成了可复现的数据管道。只要输入参数不动重建出来的场景就是一致的前端的数据绑定逻辑永远不用跟着模型随机变化重写。这也是数字孪生项目里我认为最值得先投入的部分——场景这层不稳后面接 IoT 数据、做实时联动全是空中楼阁。如果照这篇文章搭建环境我给你的唯一建议就是从最小闭环开始先让 Agent 把一个立方体建出来再逐步扩展到货架、货物、路径和区域。别想着让 AI 一口气生成整个仓库任务越大出错的概率呈指数上升而且你很难定位问题出在哪个环节。一步步来每一步都验证过后面就会很顺。下篇我会接着写 IoT 数据接入和实时联动比如让货架颜色跟着库存走、让 AGV 按调度路径动起来先把静态场景这层做稳后面才接得住真数据。
