自然语言驱动Blender建模，Antigravity+MCP快速构建智慧仓储数字孪生场景

先说个可能有点反直觉的结论一套看起来很唬人的智慧仓储数字孪生场景最耗时间的往往不是渲染不是动画而是最基础的那批3D资产建模和场景装配。传统做法里建模师照着平面图一点点拉墙、摆货架、布库位一套中型仓库的草图最快也要三四天改一版布局又要一两天。这个效率在项目早期试错阶段是很痛苦的——客户可能今天说要横排货架明天看完效果又说改成双深巷道每一轮都重来。我最近在做一个智慧仓储可视化项目试了一条新路子把 Antigravity 这类智能体编排平台和 Blender MCP 串起来用自然语言直接驱动 Blender 完成仓储数字孪生的场景搭建。跑通之后的效果是一句给我生成一个 20 米乘 40 米的仓库三排双深货架主通道 4.5 米AI 能自己拆解任务、调 Blender 建模、摆好库位网格一版可用的草模十分钟内出来。这篇文章是上篇重点讲这条链路的基本原理、环境搭建和第一批资产的生产过程不涉及太深的数据接入和渲染优化那些留给下篇。1. 为什么数字孪生偏偏要走上AI 直接建模这条路1.1 传统手工建模流程到底卡在哪先复盘一下传统的数字孪生场景制作流程。接到一个仓储可视化需求第一步是拿 CAD 平面图第二步是建模师照着图纸在 Blender 或 3ds Max 里搭墙体、地面、货架、穿梭车、机械臂第三步是导出 FBX/GLTF 给前端第四步才是数据对接。前三步如果顺利一周起步如果中途客户改需求比如把横排货架改成 U 形动线那墙体、地面、货架、库位编号全要跟着动改动量非常大。更麻烦的是3D 场景里的尺寸和逻辑是两回事。建模师能建出好看的货架但货架的库位编码、巷道宽度、消防通道位置、货物尺寸约束这些信息往往只存在于设计文档里不会体现在模型上。传统流程里建模师和开发人员要反复对齐这类信息沟通成本极高。我见过不少项目3D 模型和业务数据完全是两张皮货架位置只是摆设前端显示的数据是单独写死的。1.2 MCP 协议让 AI 从聊天变成上手干活MCPModel Context Protocol模型上下文协议这个事儿本质上就是给 AI 应用做了一套标准化的外设接口。你可以把它理解成 AI 世界的 USB-C——鼠标、键盘、显示器都能用同一套协议接进来不用每个设备单独做驱动。MCP 也一样AI 客户端通过统一的协议调用外部工具工具方只需要实现 MCP Server 就行了。放到 Blender 场景里Blender MCP 做的事情很直接它会启动一个 MCP Server把 Blender 的 Python API 包装成一系列可供 AI 调用的工具比如创建立方体移动物体设置材质添加修改器导入模型。AI 在对话中理解了你的需求就会按照这个工具列表去调用 Blender 完成操作。这和你手动在 Blender 里操作、或者自己在编辑区执行一段 Python 脚本本质上是一样的区别只是操作者是 AI。我第一次意识到这个路子的价值是在一个测试里让 AI创建一排货架每排 12 个库位库位之间间隔 0.2 米。原先我会花十几分钟写一段 Python 循环脚本跑完还要检查尺寸对不对。换成 MCP 之后AI 自己完成了循环创建、偏移计算和命名我只需要告诉它参数。那种感觉不是省了敲代码时间而是整个交互范式从人写命令变成了人描述意图。1.3 Antigravity 在这里面担任什么角色Blender MCP 解决了AI 怎么操作 Blender但还有一个问题谁来理解你的自然语言需求并把它拆成一系列可执行的 Blender 指令这就要靠 Antigravity 这类智能体编排平台。Antigravity 可以理解成一个 Agent 执行环境它接收你的任务描述维护任务的上下文调用各种 MCP 工具观察执行结果并根据结果调整下一步动作。它跟普通聊天机器人的差别在于聊天机器人只回答问题而 Antigravity 会以完成任务为目标去反复调用工具、检查中间状态。比如你说建一个仓库场景它会先拆解成创建地面 → 创建墙体 → 规划货架位置 → 放置货架 → 标注库位 → 设置摄像机然后逐个调用 Blender MCP 工具执行。在仓储数字孪生这个项目里Antigravity 相当于一个项目经理执行者它负责把模糊需求拆成清晰的子任务并且实际动手把每个子任务做完。我只需要在每个阶段验收效果不满意就让它改不用再手动打开 Blender 去调整每一个物体。2. Blender MCP 部署实录让 AI 真正握住 Blender 的鼠标2.1 环境准备Blender、Python 与 MCP 插件的搭配先说结论Blender MCP 本质是一个运行在 Blender 内部的插件所以环境准备的核心是Blender 能跑起来插件 AI 客户端能连上插件暴露的 MCP 服务。这里我用的是 Blender 4.x 版本安装路径不能有中文或空格否则后续 Python 环境容易出现各种玄学报错。第一步把社区常见的 blender-mcp 插件下载下来。下载得到的是一个压缩包里面带有 Python 脚本和插件定义文件。打开 Blender进入编辑Edit→ 偏好设置Preferences→ 插件Add-ons点击右上角的安装Install按钮选中下载好的压缩包即可。安装完成后在插件列表里搜索mcp启用它会看到插件面板里多出一项MCP Server相关设置。这里有个细节要提醒Blender MCP 启用后需要点击启动按钮它才会在本地开启一个 WebSocket 服务默认端口一般是 9876。这个端口就是 AI 客户端用来连接 Blender 的通道。如果没有点击启动后面 AI 客户端报连不上 Blender是必然的。另外Blender 在运行 MCP 服务期间不要关闭AI 的每一步操作都是实时发到当前场景里的你甚至能在 Blender 视口里看到物体被一个一个创建出来。2.2 Antigravity 侧配置 MCP 客户端连接Blender 这边服务起来了接下来要在 Antigravity 平台上配置 MCP 客户端让它能调用这个服务。不同平台的配置入口不一样但核心参数差不多服务地址、协议类型、超时时间。我当时的配置方法是在 Antigravity 的项目设置里找到 MCP/工具配置入口手动添加一个 MCP Client填入协议为 WebSocket地址为ws://127.0.0.1:9876连接后选择自动发现可用工具。工具列表刷新出来后能看到一堆create_cube、move_object、apply_modifier这类命名很直观的工具说明连接成功。如果看不到工具列表先别急着怀疑配置大概率是这几个问题Blender 那边的 MCP Server 没启动或者在连接前崩溃了。回 Blender 的插件面板看一眼状态。端口被占用或者被系统防火墙拦截。本地开发时127.0.0.1 一般不会有拦截但如果你调整过系统防火墙规则要确认对 Blender 放行。Antigravity 的 MCP 客户端连接超时设置太短。Blender 首次响应会比较慢因为首次调用要加载 Python 脚本建议把超时设置放宽到 30 秒以上。2.3 用一次旋转立方体测试完整链路配置完成后我建议先做一次最小化验证不要上来就生成整个仓库。最稳妥的测试是让 AI创建一个立方体并将它绕 Z 轴旋转 45 度。如果这一步能成功说明从自然语言到 Blender 的完整链路已经通了后面再慢慢加复杂度。实际操作中我在 Antigravity 里输入这句话后它先调用 MCP 工具创建了一个立方体然后调用旋转工具把立方体转了 45 度。Blender 视口里几乎同步出现了变化场景集合Outliner里多了一个名为 Cube 的物体。看到这个结果的瞬间我确定了这条路是可行的。有一个小细节AI 调用的工具名称和参数顺序跟 Blender MCP 暴露的定义不完全一致时可能会导致它第一次尝试失败。比如工具定义里旋转参数是rotation_eulerAI 可能需要先查询工具 schema 才能正确传参。所以测试时可以允许 AI 先调用一个list_tools或者查询工具定义的动作。我遇到的一种情况是AI 第一步会先问我可用的工具是什么这是正常的给它一点上下文空间。2.4 部署过程中踩过的坑这段经验比较碎但每一条都是实际花时间填过的坑值得记下来。第一个坑是 Blender 非管理员权限导致的写入失败。MCP 插件在给物体设置材质或贴图时需要写入 Blender 的用户配置目录如果权限不够会静默失败。我用的是以管理员身份运行 Blender来解决虽然不优雅但在 Windows 上是最省事的办法。第二个坑是版本兼容。Blender 4.0 之后 API 有一些变化部分 MCP 插件版本可能用的是旧 API导致工具调用报错。我后来固定在一个插件版本上Blender 版本也不随意升级保证链路稳定。这也是为什么我建议在项目文档里记录 Blender 版本和 MCP 插件版本方便环境重建。第三个坑跟 Blender 的命名冲突有关。如果场景里已经有同名物体AI 调用 MCP 新建物体时会覆盖或报错。我在让 AI 批量建货架前都会先让它执行清空场景或删除所有物体。别嫌麻烦这一步能避免大量混乱。3. Antigravity 智能体编排把一句帮我搭个仓储拆成可执行任务3.1 给 Agent 设定角色和工作边界Blender MCP 部署好之后真正影响产出质量的其实是 Antigravity 里的 Agent 设定。这一步很多人会忽略以为AI 那么聪明随便说说就能干实际并不然。Agent 没有清晰的角色和工作边界时它要么过于天马行空要么不知道该做到什么程度。我现在的做法是在 Antigravity 的项目说明里写一段系统提示词把 Agent 定位成仓储数字孪生场景搭建助手。内容大致包括工作目标根据用户描述的仓库需求在 Blender 中创建符合实际尺寸和布局规范的仓储 3D 场景。执行流程先规划空间尺寸再创建基础结构地面、墙体、门窗然后创建货架、通道、安全设施最后标注库位编码。编码规范所有创建的物体必须要有可读性强的命名比如Shelf_A1_R1表示 A1 排 1 号货架Bin_A1_01表示 A1 排 01 库位。禁止操作不要擅自删除用户已有资产不要在没有确认前做大规模破坏性操作。为什么要这么详细因为 Antigravity 的执行链路很长一旦中间某个环节的理解偏差没有被及时发现后面会沿着错误方向一路做下去。角色设定就像施工规范先立规矩再动工整体效率反而更高。3.2 任务拆解从一句话到十几步操作当我把生成一个 20 米乘 40 米的仓库三排双深货架主通道 4.5 米这个需求发给 Antigravity 之后它内部会如何拆解我可以通过它逐步调用的 Blender MCP 工具日志看得很清楚。大体步骤是这样计算场地面积和布局比例20×40 米的仓库三排货架需要留出主通道和消防通道所以货架不能占满全部面积。创建地面一个 20×40 米的平面厚度设为 0.1 米作为地基。创建墙体四面墙高度默认 5.5 米在南北向各留一个大门开口。创建货架三排货架每排分为两段因为双深每段 12 组货架每组货架 5 层、每层 2 个库位。这一步涉及大量重复建模AI 会用循环批量创建而不是一个个手动建。创建通道主通道宽度 4.5 米设置在货架中间消防通道宽 2 米沿墙布置。标注库位每个库位用一个空物体Empty标记命名规则按Bin_X_Y_Z为后续数据绑定做准备。这说明 Antigravity 的拆解能力和执行能力是能显式观察到的。如果拆解得不对你在日志里能立刻看出来比如它把 20×40 误读成长宽弄反了或者把三排理解成三列。发现问题后直接打断让它重来比最后整体返工代价小得多。3.3 执行报错的常见处理terminated due to error 与 eligibility check failed实际跑链路时Antigravity 会出现两类让我印象深刻的报错一个执行中断一个权限校验。agent execution terminated due to error 这类报错通常是某个 MCP 工具调用失败后 Agent 无法自动恢复导致的。我遇到过的场景是Blender MCP 执行一个操作时抛异常比如创建物体时传入了一个非法参数工具返回错误信息Agent 尝试重新组织语句但连续几次都失败最终整个 Agent 执行被终止。排查办法是先看日志里具体是哪个工具、哪个参数出错回到 Blender 插件面板看有没有对应的 Python 报错堆栈。大多数情况是参数格式问题比如把location传成了字符串而不是数组。把正确的参数格式在提示词里写清楚能有效降低这类报错概率。eligibility check failed 则更偏平台权限层面。它通常跟当前账号或环境是否有资格执行某项操作有关。我遇到的一个实际场景是某个 Blender MCP 工具需要写文件到外部路径但 Antigravity 的执行环境认为这个操作超出了权限范围直接拒绝了。这类问题不要试图绕过权限限制而是调整方案。我当时改成让 Blender MCP 只创建场景内资产、不做文件系统写入问题就解决了。做数字孪生项目时凡是涉及导出文件的功能建议单独拆分到特定工具里避免混在建模流程中触发权限拦截。另外还有个值得提的 403 问题。如果你在 Antigravity 里配置的 MCP 服务带访问令牌token而令牌过期或缺失请求时会返回 403。配置 MCP Client 时最好先确认平台是否支持设置 Header 或认证参数。我用的一次性令牌过期后重新生成并更新到配置里就好了。3.4 对话式迭代让 Agent 按阶段汇报别让它一口气全做完我早期犯过一个错误让 Antigravity 一次性把整个仓库场景做完然后等着验收。结果是它闷头做了一大堆有些参数和需求完全偏了返工工程量很大。后来我改成阶段化执行 每阶段汇报的方式。具体做法是在提示词里要求 Agent 每完成一个阶段就输出当前状态说明比如地面和墙体已创建尺寸为 20×40×5.5 米、货架已创建 3 排共 72 组并等待我的确认再进入下一阶段。这样虽然对话轮次变多了但每一轮的单次执行时间都更短出错也更容易定位。我可以在它做完地面和墙体之后先在 Blender 视口里目测一下比例对不对再让它继续做货架。这种方式更适合仓储这类有严格尺寸和布局规则的场景。它不是把 AI 当自动执行机而是当团队里的协作成员——拆解、执行、汇报人对关键节点把关。实际用下来项目整体返工率至少降低了一半。4. 第一版仓储孪生资产从库位、货架到巷道的建模实践4.1 用数据思维定义场景参数真正开始搭建资产之前我建议先用表格把仓储场景的核心参数定义清楚。这不是多余的额外工作而是让 AI 后续建模有据可依。没有参数约束的 AI 建模生成出来的货架可能比例失调、库位数量随意根本没法用于后续数据对接。我当时定义的基础参数是这些可直接参考元素参数说明仓库尺寸20m × 40m面积 800 ㎡单层檐高5.5m满足常规货架高度货架排数3 排纵向布置货架形式双深双列每排背靠背两列每组货架5 层 × 2 库位每组 10 个库位主通道宽 4.5m叉车双向通行消防通道宽 2m沿墙布置装卸口南侧 2 个各宽 3m、高 4m把这些参数写进给 Antigravity 的需求描述里它生成的模型就不会无边界发挥。我最开始只写了三排双深货架AI 自己根据 Blender 默认单位生成了 2.4 米一组的标准货架跟我想要的 2.8 米一组差了很远。有了参数表之后每个组件的尺寸都能对齐。4.2 货架建模一句话让 AI 批量生成并严格对齐货架是仓储数字孪生里最核心也最重复的资产。手动建模时最常见做法是建一组标准货架然后加阵列修改器Array Modifier批量复制。在 Blender MCP 链路里我看到了另一种实现方式——AI 直接用循环调用创建函数。我在 Antigravity 里输入的需求是创建三排双深货架每排 20 组每组货架宽度 2.8 米、深度 1.1 米双深就是两组背靠背、高度 4.8 米5 层横梁每层两个库位。 AI 收到后分三步执行第一步先创建一个标准货架组两根立柱、五层横梁、每层两个支撑隔板。第二步用循环将标准货架横向复制 20 组每组间隔 0.05 米。第三步复制出背后一组形成双深结构然后整排复制成三排按主通道间距摆好。值得称赞的是 AI 自动处理了命名规则。它把每个货架主体命名为Shelf_1_Group_01、Shelf_1_Group_02这样的格式每个库位隔板命名为Bin_1_1_01。这个细节对后续数据对接意义很大——如果没有规则化命名将来做前端点选库位时根本不知道选中的是哪个库位。这里有个小坑要提一下AI 循环创建的物体数量很大时如果没合理设置use_relative_offset或间距物体会互相重叠。我第一次生成的货架组之间就有细微重叠视觉上看不太出来但如果以后要做碰撞检测或者仓储路径规划会影响数据精度。建议在提示词里显式要求每组货架间距不小于 0.05 米确保无重叠。4.3 库位编码与标注从 3D 物体到孪生标识的桥梁仓储数字孪生和普通 3D 模型的本质区别在于孪生场景里的每一个物体都要能和业务数据挂上钩。货架不能只是好看的模型库位也不只是一个盒子它们要和 WMS仓储管理系统里的库位编码一一对应才能实现数字孪生而不是数字雕塑。这一步我在上篇里做的是基础版——用空物体Empty作为库位锚点。具体操作是让 AI 在每个库位的中心位置创建一个空物体命名为Anker_Bin_1_1_01空物体位置精确对齐库位中心。这些空物体在渲染时不可见但后续做前端交互时可以通过这些空物体的世界坐标在 Three.js 里映射到对应库位区块点击选中的是哪个库位一目了然。如果项目后期要对接真实 WMS 数据库位编码的规则很重要。我用的规则是Bin_{排}_{层}_{位}比如Bin_1_3_02表示第 1 排货架、第 3 层、第 2 个库位。这个规则在下篇接入真实库存数据时可以直接作为关联主键非常自然。Blender MCP 让 AI 批量创建这些空物体并命名几乎不费什么力气。4.4 从 Blender 导出模型和 JSON给前端留好后路数字孪生项目最终一定会走向前端展示所以 Blender 里的资产要能顺利导出。上篇我先做的是两种导出准备。第一种是 3D 模型导出。仓储场景里大量重复物体直接导出 FBX 或 OBJ 会让文件体积爆炸。我的建议是灯具、墙体、地面这类基础结构导出为低面数 GLTF/GLB货架这类重复资产可以用单个标准货架模型 实例化引用的方式在前端摆放或者导出前先把重复的阵列物体合并Join成几个大物体减少 Draw Call。我让 AI 执行了合并操作每排货架合并为一个整体三排就是 3 个物体文件体积大幅下降Three.js 加载也更快。第二种是数据导出。场景里创建的所有库位锚点空物体可以导出为一个 JSON 文件包含每个库位的名称和世界坐标。我在 Blender 里用 Python 脚本遍历所有空物体提取名称和位置输出成数组结构。后续前端拿到这个 JSON 就能直接渲染出所有库位的可点击区块和 3D 模型对齐。这里有个经验导出 JSON 时坐标系要统一。Blender 默认是 Z 轴向上而 Three.js 也是 Z 轴向上这刚好一致。但如果你用的是其他建模软件要特别注意坐标系转换。我习惯在导出前做一次坐标校验拿一个已知位置的空物体导出的 JSON 坐标是否和 Blender 视口显示的一致。4.5 第一版场景的验收视角经过以上步骤第一版仓储场景基本是这样的一个 20×40×5.5 米的仓库空间三排双深货架整齐排列主通道 4.5 米消防通道 2 米南侧两个装卸口每个库位都有编码锚点。在 Blender 视口里切换到渲染模式已经能看到一个结构清晰、比例合理的仓储雏形。验收时我会做四个检查尺寸检查用 Blender 的标注工具在场景里量一下货架间距、通道宽度是否与参数一致。命名检查大概浏览场景集合Outliner里的物体命名是否都符合规则有没有出现你说的仓库版本2这种无效命名。重叠检查开启 Blender 的线框显示模式看货架之间有没有明显穿插。导出预检试着导出一版 GLTF 和一个 JSON确认没有报错文件大小可接受。这一套验收流程做完第一版资产才算真正可用。接下来就可以进入下篇的范围了比如接入真实 WMS 数据、让库存状态驱动库位颜色变化、增加穿梭车动画、优化前端加载策略。我在跑通这一版之后最大的体会是工具链不能替代人的判断但能把项目早期的建模试错成本压缩到极低。以前跟客户讨论主通道 4.5 米够不够宽只能靠口头描述和图纸现在可以直接拉出一版可交互的 3D 场景让对方自行审视沟通效率完全不是一个级别。如果你也在做类似的数字孪生前期探索建议按这个链路先跑通一个小版本。参数不用太复杂一个 5×5 米的小区域加一组货架就能验证工具链是否稳定。工具链稳定了后面不管项目规模多大都只是参数增加和编码规则完善的问题。