在做智慧仓储项目的时候我最头疼的不是算法也不是前端页面而是3D场景本身。业务方要的是“打开网页就能看到仓库全貌”的数字孪生场景建模师排期却排到下个月自己上手建又扛不住那套繁琐的操作流程。后来我换了个思路把Antigravity当作Agent执行平台给Blender接上MCP服务让AI直接按照自然语言描述把仓储场景建出来。这套链路跑通之后建一个几千库位的仓库模型从“按周算”变成了“按小时算”。这篇是系列的上篇先把整体链路、环境搭建和仓储建模的关键细节讲清楚下篇再聊数据对接和动态效果。1. 方案先导Antigravity和Blender MCP在干什么1.1 为什么是这两样东西的组合先说Antigravity。它本质上是一个能承载Agent任务执行的平台你可以把复杂的任务指令丢给它它会自己拆解步骤、调用工具、生成结果然后把执行过程反馈给你。它解决的是一件事把“人想干什么”翻译成“机器能执行的指令”。再说Blender MCP。MCP的全称是Model Context Protocol即模型上下文协议它把AI和外部工具之间的调用方式标准化了。Blender MCP就是社区里做的开源桥接服务它让Agent能够通过MCP协议向Blender发送指令指令最终会变成Blender的Python API调用也就是bpy调用。这两个东西组合到一起价值就出来了。过去我建仓库模型要么自己手动拖拽建模要么写一整套bpy脚本。手动建模的问题是机械重复几百个货架要一个一个摆写脚本的问题是需求一变脚本就要跟着改而且改脚本本身就很费时间。用Antigravity和Blender MCP这套链路我只需要把业务需求用大白话描述给Agent它负责写bpy代码通过MCP送进Blender执行场景就一层层搭起来了。1.2 MCP在这条链路里的作用MCP的原理想象成“万能插座”就好理解了。AI是电器各种软件工具是电器插头MCP就是统一规格的插座。只要工具方实现一个MCP服务端AI就能用标准的协议去调用它不需要针对每个软件单独写一套对接逻辑。放在这个项目里Blender MCP服务端跑在本地监听一个端口。Antigravity把Agent生成的Python代码或者操作意图发到这个端口Blender里的插件收到消息后调用bpy模块执行再把执行结果返回给Agent。整个过程对用户来说就是在Antigravity对话框里打一句话过几分钟Blender里就出现了一个仓库模型。这个方案有个隐藏优势就是“人可以在环里”。MCP是双向的Agent在执行过程中遇到模糊诉求可以直接在对话里问我我也能在Blender里手动调整不满意的地方再让Agent接着建。对比纯脚本方式这种半自动半人工的协作模式更贴近真实项目节奏。1.3 信息流和角色分工我把这套系统的角色分了三个决策者、执行者、工具。决策者是Antigravity它负责理解需求、拆解任务、编写代码、判断执行结果是否正确。执行者是Blender MCP服务端它负责接收指令、调用Blender、返回执行状态。工具是Blender本体它负责真正生成几何体、材质、灯光、相机。举个例子。我说“仓库地面是72米乘24米浅灰色”这句话进入Antigravity后Agent会解读为“创建平面尺寸72x24米指定材质为浅灰色”然后通过MCP发送给Blender执行。等执行结果返回后Agent还会再确认一句“地面创建成功材质已设置”我确认无误再下一条指令。这个分工模式的核心价值是分层清晰。模型六层货架、每排20列这样的重复性操作完全交给Agent做布局合理性、视觉效果、业务合理性这些需要经验判断的部分留给我来决策。人和AI各干各擅长的事效率自然就上来了。2. 环境准备与链路打通2.1 软件清单与版本建议先把需要准备的东西列清楚。这套方案依赖三个核心软件Antigravity、Blender、Blender MCP服务端。组件版本建议说明Antigravity最新稳定版Agent执行平台负责任务拆解与代码生成Blender3.6 LTS以上推荐4.x版本越新bpy兼容性越好但4.x需确认MCP插件兼容Blender MCP插件项目最新release插件是核心桥接层负责监听MCP指令并调用bpyPython环境3.10-3.12如果MCP服务以独立Python进程运行需要注意版本匹配我实际使用时遇到一个坑Blender 4.2刚发布时某些MCP插件的老版本对bpy API变动没适配导致连接后执行报错。后来我锁定在Blender 4.1搭配最新版MCP插件稳定跑了一个多月没出问题。如果你是第一次搭这套环境建议先用稳定组合不要追新。2.2 Blender侧的MCP服务端配置Blender这侧的配置逻辑不复杂装插件、启动服务、记下端口号。具体操作是这样的先在Blender的偏好设置里选择“安装插件”选中Blender MCP插件的压缩包或py文件。安装完成后在插件列表里勾选启用。启动插件后界面里会出现一个启动按钮点击它会开启本地服务默认监听端口是9876界面上会显示完整的WebSocket地址。我要特别提醒一句这个服务只绑定在本机回环地址也就是只允许本机访问外部设备访问不了。这是安全底线千万别为了图方便把它改成对外网开放因为MCP服务能直接调用bpy执行任意Python代码权限等于Blender管理员。改绑外部IP就等于让整个电脑处于裸奔状态。启动服务后可以用一个简单的本地Python脚本验证端口是否在监听。如果这一步通了Blender这侧就准备好接收指令了。2.3 Antigravity侧的MCP配置Antigravity侧要做的是把Blender MCP服务配置为它的工具来源。在Agent项目配置里找到MCP服务器设置新增一条连接记录填上服务名称、类型和地址。Blender MCP走的是WebSocket协议所以地址填ws://127.0.0.1:9876。填完之后Antigravity会自动探测这个地址确认能连上后会列出MCP服务端暴露的工具清单。Blender MCP服务端通常会暴露几个核心工具包括执行Python代码、获取场景状态、渲染视图等。看到工具列表出现说明两边握手成功。这里有个细节容易被忽略Antigravity的Agent会话是隔离的。如果你在不同的Agent会话里都要用Blender MCP需要把MCP服务器配置加到对应的会话或项目里而不是加一次全局生效。一开始我就是在A项目配好了切到B项目发现工具列表是空的折腾了一会儿才反应过来。2.4 第一步实测让AI在Blender里捏个测试立方体链路接没接通最直接的办法就是做一次最小化测试。我在Antigravity里发了一条极简指令“在Blender中创建一个默认立方体尺寸2x2x2米颜色设置为红色。”这句话发出去后Antigravity开始拆解任务生成的bpy代码大概是这个逻辑import bpy # 清空默认场景中的立方体 bpy.ops.object.select_all(actionSELECT) bpy.ops.object.delete(use_globalFalse) # 新建红色立方体 bpy.ops.mesh.primitive_cube_add(size2, location(0, 0, 1)) obj bpy.context.active_object # 创建并指定材质 mat bpy.data.materials.new(nameRedMat) mat.diffuse_color (0.8, 0.1, 0.1, 1.0) obj.data.materials.append(mat)这段代码通过MCP发送到Blender里执行。执行成功后Blender视图中出现一个红色立方体Antigravity那边会返回“执行成功耗时xx秒”之类的反馈。这一步跑通说明整条链路是通的后面就可以放心做正式场景了。我第一次实测的时候因为Blender没启动MCP服务也没启动Antigravity反馈的是“无法连接到目标服务执行终止”。这个坑我放在后面问题排查部分细说新手第一次测试时建议先把Blender打开、把MCP插件服务启动再在Antigravity侧做连接测试。3. 仓储需求拆解建模前先算清楚账3.1 用一个72x24米的自动化仓库当案例技术链路打通后先别急着生成模型。做数字孪生的第一步永远不是建模而是梳理业务参数。我拿一个典型的中型自动化仓库当案例把参数理清楚。这个仓库长72米、宽24米、净高9米。仓库内部划分为三个功能区靠近收货月台的一侧是入库暂存区中间是高位货架区靠近发货月台的一侧是出库暂存区。货架区一共放了6排双深货架每排20列、5层。每一列对应一个库位位置双深意味着正反两面都能放托盘所以这一侧的库位量直接乘2。数字化拆解之后这个货架区的总库位数是6排 × 20列 × 5层 × 2深 1200个库位。这1200个库位不是1200个独立模型而是通过程序化方式批量生成的。参数算清楚后面建模清单就出来了生成逻辑也清晰了。3.2 坐标系、单位、朝向的约定3D场景里最容易出问题的就是坐标系和单位。Blender默认以米为单位这对仓储场景非常友好因为仓库图纸全部按米标注前后一致不需要额外换算。坐标约定上我把仓库长边沿X轴方向铺开短边沿Y轴方向铺开Z轴向上。这个约定在后续给前端数字孪生网站提供模型时尤其重要因为Three.js等前端渲染引擎也是这套坐标约定导出后不需要做额外的旋转修正。还有一个容易被忽略的约定是建筑朝向。我习惯把收货月台放在X轴负方向末端发货月台放在X轴正方向末端。这样在孪生场景里AGV的运动轨迹就很自然地沿着X轴方向流动视觉上符合人的阅读习惯。等到了下篇做动态数据对接时这个约定可以省掉很多坐标换算的麻烦。3.3 从业务参数到建模清单理顺参数后我列一张建模清单明确这一版场景需要生成哪些对象、各占多少数量规模。建模对象数量规模说明仓库地面1个72x24米浅灰材质高位货架6排每排双深含立柱、层板、横梁货架库位1200个程序化生成按排、列、层编号巷道路面若干条沿货架区纵向铺设颜色区分月台/出入口2处收货与发货月台空间参照物若干人员、托盘、叉车等比例参照物每一类对象的建模难度不同。马台和地面这类简单形状手工建模也不费事但货架和库位这类重复对象手工建就纯粹是浪费时间。我的思路是简单对象手工建批量对象让Agent生成最后把所有对象放进统一的命名空间和集合结构。4. 核心实操用自然语言驱动仓储场景生成4.1 一句完整的Agent指令长什么样建模清单理清楚之后就到了最有意思的部分用自然语言让Agent干活。这里的关键不是“会不会说话”而是“怎么把话说到点子上”。我在实践中总结出一个公式对象定义 尺寸参数 位置关系 材质要求 命名规则。缺一个要素Agent生成的代码就会出现偏差。以货架为例我的一条指令是这个风格“在Blender中创建双深高位货架单排尺寸为宽3.2米、深2.6米、高7.5米。每排20列、每列5层库位净高1.5米。第1排中心点放在X5米、Y8米处朝向沿X轴。货架立柱材质用深灰色金属横梁和层板用浅灰色。每一个库位生成一个带标识的空对象命名规则为Rack_排号_列号_层号。”这句话里有坐标、有尺寸、有数量、有材质、有命名Agent拿到之后几乎不需要二次追问就能直接生成代码。我承认第一次这么跟Agent对话的时候心里没底担心它理解不了但实际跑下来发现只要参数给全效果比跟建模师沟通还稳定。4.2 Agent是怎么把话拆成Blender Python的从自然语言到bpy代码这中间的逻辑链值得展开说一下。Agent收到指令后先做语义理解识别出“双深货架”“20列”“5层”这些数量参数再从经验库里匹配对应的建模方案也就是“怎么用代码创建一个像货架的几何体”最后把这些参数套进代码模板生成可执行脚本。这段逻辑拆解出来的核心代码框架长这样import bpy import bmesh # 参数区可以根据对话里的数值调整 rack_count 6 # 排数 col_count 20 # 每排列数 layer_count 5 # 每列层数 rack_width 3.2 # 排宽米 rack_depth 2.6 # 排深米 layer_height 1.5 # 层高米 grid_x 72 # 仓库长度 grid_y 24 # 仓库宽度Agent先把对话参数转化成变量然后用循环语句生成重复结构最后赋材质、命名。我验证过它生成的代码框架比人工手写的还要规范变量命名默认用snake_case循环结构清晰方便后续二次调试。4.3 关键代码解读地面、货架阵列、库位标识一个完整场景的核心代码分三块。第一块是创建地面这个最简单一个平面加一个材质就搞定。bpy.ops.mesh.primitive_plane_add(size1, location(0, 0, 0)) floor bpy.context.active_object floor.name Floor_Main floor.scale (grid_x, grid_y, 1) # 调整平面原点贴齐网格角落 floor.data.vertices[0].co (0, 0, 0)第二块是货架阵列。这一步的逻辑是创建一排货架的基本单元然后用嵌套循环复制并平移。很多人会直接把单排货架复制20次这样场景对象数量暴增卡得要命。Agent生成代码时会自动用collection实例化也就是让所有货架共享同一个网格数据只记录位置差异。这个细节对性能影响很大几千个库位能不能跑得动就看这一步怎么处理。第三块是库位标识。这里的思路是创建一个空对象只保留坐标信息用命名规则承载库位编号比如Rack_01_05_03代表第1排第5列第3层。当前端数字孪生网站需要展示库存状态时就可以通过这个命名来对接数据哪一格有货、哪一格空置一目了然。5. 从静态模型到数字孪生规范、导出与复用5.1 命名和层级场景不是“看起来像”就行做数字孪生场景光“看起来像仓库”是不够的。模型还要能被程序识别、被数据驱动、被前端拉取。这就要求模型的组织方式有规矩。我给自己定了几条硬规范。第一所有对象必须有命名前缀比如仓库地面叫Floor_前缀货架用Rack_前缀AGV轨道用Path_前缀。第二同类对象必须放进同一个Collection集合方便整体显隐和导出控制。第三每个库位必须有独立的空对象锚点锚点命名格式固定为库位编号_行_列_层。这条规矩在实践中救过我一次。当时要在前端数字孪生网站里做库存可视化业务方要求点击某个库位弹窗显示库存信息。因为我在建模时把库位命名规范做成了固定的四点格式前端直接解析对象名就拿到了坐标和编号连二次映射表都不用建。如果我当时随手起了名字后面对接数据时要手工维护一张成千上万的映射表那个工作量想想就头大。5.2 材质管理与配色规范材质的规范同样重要。数字孪生场景不是艺术创作配色要服务于信息传达而不是审美。我的配色方案是固定的仓库地面用浅灰色货架结构用深灰色货架横梁用中灰色AGV可行走区域用半透明浅蓝色安全通道用黄色警示条月台区域用深绿色。这套配色在Three.js渲染下效果也稳定不会出现明暗差异过大导致信息看不清的问题。操作层面我让Agent在生成每个对象时同步创建材质材质命名也和对象命名对应。这样后续改颜色直接全局替换材质就行。我还习惯把材质统一放进一个Materials集合导出时单独控制避免前端加载时材质丢失。5.3 导出GLB给前端数字孪生网站用模型建好、规范和材质都到位了下一个关键动作是导出。前端数字孪生网站基本都是用WebGL渲染Three.js是主流选择它支持直接加载GLB格式也就是二进制glTF。导出前有几个设置要确认。第一场景单位必须确认是米。第二所有对象有没有多余的空集合建议清一遍场景再导出。第三灯光和相机要不要导出通常前端会用自身的光照系统导出时可以不包含灯光相机只保留几何体和材质。第四动画和驱动要不要烘焙如果模型里有通过driver控制的参数化结构导出前要确认前端需要哪种形态。我用的是glTF 2.0格式导出方式可以是Blender自带导出器也可以让Agent通过MCP调用导出命令。导出后我会再用模型查看器过一遍确认尺寸比例、材质颜色正常再交给前端同事。这一步别偷懒模型在Blender里看着正常但导出过程丢材质、错比例的问题我遇到过不止一次。5.4 把常用仓储件沉淀成资产库项目做多了之后我总结出一个提高效率的方法把常用仓储件沉淀成可复用的资产库。所谓资产库就是把货架、托盘、叉车、人员、AGV小车这些高频对象做成一到两个标准版本存成独立的.blend文件或者GLB文件放到统一的资产目录。后续新项目直接让Agent调用资产库里的现有文件而不是每次从零开始生成。举个例子一套标准的仓储托盘高度150毫米、尺寸1.2x1.0米是这个行业里最常见的规格。我把它存成Pallet_Standard资产文件。下次Agent生成货架时我直接在指令里写“库位放置标准托盘”它就知道去资产库里调用了不用每次重新描述一遍托盘细节。表面上这只是省了几分钟生成时间但实际价值远不止于此。资产统一意味着整个公司的数字孪生项目里所有托盘、货架规格一致跨项目对比数据时不会出现“这个项目用的托盘和那个项目不一样”的尴尬情况。6. 踩坑记录与问题排查6.1 Agent执行中断后的恢复技巧用Antigravity跑建模任务最让人抓狂的就是一个长任务跑到一半Agent提示执行终止。最开始我以为是自己指令写得不清楚后来反复测试才搞清楚大部分原因是Blender MCP服务在执行过程中遇到了异常脚本插件报错后Agent就主动停了。这里的处理思路分三步。第一步看Blender的控制台输出它会显示具体是哪一行Python代码报错。第二步把报错信息复制回给Antigravity让它定位问题并修复。第三步让Agent把修复后的脚本从失败位置继续跑而不是从头开始。这个“断点续跑”的能力是我觉得整套方案最值的地方。传统建模方式下建模师做一个大型场景中途错了要回退很久而在Agent协作模式下错误是局部的、可以被诊断和修复的。6.2 货架一多就卡性能优化思路1200个库位的场景如果每次都生成独立的网格对象Blender会卡得怀疑人生。我在第4章里提过collection实例化这里再展开说一下优化思路。Blender里的对象分为“网格数据”和“对象实例”两层概念。如果每个库位都复制一份独立网格等于在内存里存1200份一模一样的几何数据。如果让1200个对象共享同一个网格数据只存坐标和旋转差异内存占用会断崖式下降性能立刻提升好几个档次。在bpy里的实现方式就是用collection的实例化功能或者直接用bpy.context.collection.objects.link把同一个网格数据关联给多个对象。我实测下来用实例化方案1200个库位的场景在普通笔记本上也能流畅旋转查看而不用实例化方案同样场景几乎卡成PPT。这个技巧在做大尺度园区级数字孪生时尤其重要那个场景下动辄上万个重复对象不优化根本跑不起来。6.3 MCP连接不上、指令没反应MCP连接问题是我踩得最多的坑翻来覆去就那几个原因。第一个原因是Blender没启动MCP服务自然没监听端口。第二个原因是Blender启动了但MCP插件没点启动按钮服务没运行。第三个原因是端口被占用另一个程序把9876抢走了。第四个原因是Antigravity配置里的地址填错了比如多写了一个斜杠或者端口写错。排查顺序我建议是先确认Blender开着再确认MCP插件界面显示“服务运行中”再检查Antigravity的工具列表里有没有Blender相关工具最后一眼看端口是否能通过本机访问。按照这个顺序挨个排查90%的连接问题都能快速定位。还有一个隐蔽的问题就是MCP服务启动后Blender如果被强制退出服务不会自动清理残留进程会继续占用端口。这时候重启Blender新服务起不来一直报端口被占用。解决办法是先把残留的Python进程结束掉再重新启动Blender里的MCP服务。6.4 单位错乱和坐标偏移统一基准最后一个常见问题是单位错乱。表现为Agent生成了数字看上去对但模型实际尺寸完全不对或者位置偏移到场景之外。根因往往是Agent生成的代码里用了不同的单位假设。比如仓库长度72Agent可能会理解成72厘米而不是72米直接导致比例崩溃。解决思路是在对话里从一开始就固定单位声明每次生成关键对象时都带一句“单位用米”。或者在代码模板里写死单位转换逻辑不管是厘米还是英寸进去先转成米。坐标偏移的问题也有一个常见原因Blender的场景原点没有放在预期位置或者模型没有对齐网格。我的习惯是每次生成场景前把Blender的3D光标位置重置到世界原点保证所有新建对象都在预期坐标体系下。这个细节看着不起眼但在后期对接前端时一个坐标系偏差可能导致整个布局旋转90度或者平移几米出现那种“货架跑到墙外”的诡异效果。现象可能原因处理办法Agent执行终止Blender MCP执行脚本报错查看Blender控制台输出反馈给Agent修复场景卡顿严重未使用实例化独立网格过多重构为collection共享网格数据MCP连接失败服务未启动或端口被占用按连接排查顺序逐项确认模型尺寸比例异常单位假设不一致固定统一单位模板内做换算对象位置偏移场景原点或3D光标偏移重置到世界原点检查坐标系对齐我个人在实际操作中的体会是这套Antigravity加Blender MCP的组合最大的价值不是“自动建模”这四个字而是让建模过程从“手工体力活”变成了“参数驱动的对话式协作”。我现在接手一个新的仓储项目最优先做的事情从“打开Blender开始建”变成了“先梳理参数表再跟Agent对话”。业务一旦有调整比如货架排数从6排改成8排我只需要告诉Agent改一个参数场景几十秒后就更新完了这在以前是不可想象的效率。系列下篇我准备写这几块内容的实战延伸一是把仓库的静态模型数据接到业务系统让库位的空置和占用状态实时反映在孪生场景里二是AGV路径的可视化和动态轨迹模拟三是如何把Blender里做好的场景稳定地交付给前端数字孪生网站包括性能优化和模型面数控制。先把“上篇”这套链路跑通下篇的内容才有地基。
在做智慧仓储项目的时候我最头疼的不是算法也不是前端页面而是3D场景本身。业务方要的是“打开网页就能看到仓库全貌”的数字孪生场景建模师排期却排到下个月自己上手建又扛不住那套繁琐的操作流程。后来我换了个思路把Antigravity当作Agent执行平台给Blender接上MCP服务让AI直接按照自然语言描述把仓储场景建出来。这套链路跑通之后建一个几千库位的仓库模型从“按周算”变成了“按小时算”。这篇是系列的上篇先把整体链路、环境搭建和仓储建模的关键细节讲清楚下篇再聊数据对接和动态效果。1. 方案先导Antigravity和Blender MCP在干什么1.1 为什么是这两样东西的组合先说Antigravity。它本质上是一个能承载Agent任务执行的平台你可以把复杂的任务指令丢给它它会自己拆解步骤、调用工具、生成结果然后把执行过程反馈给你。它解决的是一件事把“人想干什么”翻译成“机器能执行的指令”。再说Blender MCP。MCP的全称是Model Context Protocol即模型上下文协议它把AI和外部工具之间的调用方式标准化了。Blender MCP就是社区里做的开源桥接服务它让Agent能够通过MCP协议向Blender发送指令指令最终会变成Blender的Python API调用也就是bpy调用。这两个东西组合到一起价值就出来了。过去我建仓库模型要么自己手动拖拽建模要么写一整套bpy脚本。手动建模的问题是机械重复几百个货架要一个一个摆写脚本的问题是需求一变脚本就要跟着改而且改脚本本身就很费时间。用Antigravity和Blender MCP这套链路我只需要把业务需求用大白话描述给Agent它负责写bpy代码通过MCP送进Blender执行场景就一层层搭起来了。1.2 MCP在这条链路里的作用MCP的原理想象成“万能插座”就好理解了。AI是电器各种软件工具是电器插头MCP就是统一规格的插座。只要工具方实现一个MCP服务端AI就能用标准的协议去调用它不需要针对每个软件单独写一套对接逻辑。放在这个项目里Blender MCP服务端跑在本地监听一个端口。Antigravity把Agent生成的Python代码或者操作意图发到这个端口Blender里的插件收到消息后调用bpy模块执行再把执行结果返回给Agent。整个过程对用户来说就是在Antigravity对话框里打一句话过几分钟Blender里就出现了一个仓库模型。这个方案有个隐藏优势就是“人可以在环里”。MCP是双向的Agent在执行过程中遇到模糊诉求可以直接在对话里问我我也能在Blender里手动调整不满意的地方再让Agent接着建。对比纯脚本方式这种半自动半人工的协作模式更贴近真实项目节奏。1.3 信息流和角色分工我把这套系统的角色分了三个决策者、执行者、工具。决策者是Antigravity它负责理解需求、拆解任务、编写代码、判断执行结果是否正确。执行者是Blender MCP服务端它负责接收指令、调用Blender、返回执行状态。工具是Blender本体它负责真正生成几何体、材质、灯光、相机。举个例子。我说“仓库地面是72米乘24米浅灰色”这句话进入Antigravity后Agent会解读为“创建平面尺寸72x24米指定材质为浅灰色”然后通过MCP发送给Blender执行。等执行结果返回后Agent还会再确认一句“地面创建成功材质已设置”我确认无误再下一条指令。这个分工模式的核心价值是分层清晰。模型六层货架、每排20列这样的重复性操作完全交给Agent做布局合理性、视觉效果、业务合理性这些需要经验判断的部分留给我来决策。人和AI各干各擅长的事效率自然就上来了。2. 环境准备与链路打通2.1 软件清单与版本建议先把需要准备的东西列清楚。这套方案依赖三个核心软件Antigravity、Blender、Blender MCP服务端。组件版本建议说明Antigravity最新稳定版Agent执行平台负责任务拆解与代码生成Blender3.6 LTS以上推荐4.x版本越新bpy兼容性越好但4.x需确认MCP插件兼容Blender MCP插件项目最新release插件是核心桥接层负责监听MCP指令并调用bpyPython环境3.10-3.12如果MCP服务以独立Python进程运行需要注意版本匹配我实际使用时遇到一个坑Blender 4.2刚发布时某些MCP插件的老版本对bpy API变动没适配导致连接后执行报错。后来我锁定在Blender 4.1搭配最新版MCP插件稳定跑了一个多月没出问题。如果你是第一次搭这套环境建议先用稳定组合不要追新。2.2 Blender侧的MCP服务端配置Blender这侧的配置逻辑不复杂装插件、启动服务、记下端口号。具体操作是这样的先在Blender的偏好设置里选择“安装插件”选中Blender MCP插件的压缩包或py文件。安装完成后在插件列表里勾选启用。启动插件后界面里会出现一个启动按钮点击它会开启本地服务默认监听端口是9876界面上会显示完整的WebSocket地址。我要特别提醒一句这个服务只绑定在本机回环地址也就是只允许本机访问外部设备访问不了。这是安全底线千万别为了图方便把它改成对外网开放因为MCP服务能直接调用bpy执行任意Python代码权限等于Blender管理员。改绑外部IP就等于让整个电脑处于裸奔状态。启动服务后可以用一个简单的本地Python脚本验证端口是否在监听。如果这一步通了Blender这侧就准备好接收指令了。2.3 Antigravity侧的MCP配置Antigravity侧要做的是把Blender MCP服务配置为它的工具来源。在Agent项目配置里找到MCP服务器设置新增一条连接记录填上服务名称、类型和地址。Blender MCP走的是WebSocket协议所以地址填ws://127.0.0.1:9876。填完之后Antigravity会自动探测这个地址确认能连上后会列出MCP服务端暴露的工具清单。Blender MCP服务端通常会暴露几个核心工具包括执行Python代码、获取场景状态、渲染视图等。看到工具列表出现说明两边握手成功。这里有个细节容易被忽略Antigravity的Agent会话是隔离的。如果你在不同的Agent会话里都要用Blender MCP需要把MCP服务器配置加到对应的会话或项目里而不是加一次全局生效。一开始我就是在A项目配好了切到B项目发现工具列表是空的折腾了一会儿才反应过来。2.4 第一步实测让AI在Blender里捏个测试立方体链路接没接通最直接的办法就是做一次最小化测试。我在Antigravity里发了一条极简指令“在Blender中创建一个默认立方体尺寸2x2x2米颜色设置为红色。”这句话发出去后Antigravity开始拆解任务生成的bpy代码大概是这个逻辑import bpy # 清空默认场景中的立方体 bpy.ops.object.select_all(actionSELECT) bpy.ops.object.delete(use_globalFalse) # 新建红色立方体 bpy.ops.mesh.primitive_cube_add(size2, location(0, 0, 1)) obj bpy.context.active_object # 创建并指定材质 mat bpy.data.materials.new(nameRedMat) mat.diffuse_color (0.8, 0.1, 0.1, 1.0) obj.data.materials.append(mat)这段代码通过MCP发送到Blender里执行。执行成功后Blender视图中出现一个红色立方体Antigravity那边会返回“执行成功耗时xx秒”之类的反馈。这一步跑通说明整条链路是通的后面就可以放心做正式场景了。我第一次实测的时候因为Blender没启动MCP服务也没启动Antigravity反馈的是“无法连接到目标服务执行终止”。这个坑我放在后面问题排查部分细说新手第一次测试时建议先把Blender打开、把MCP插件服务启动再在Antigravity侧做连接测试。3. 仓储需求拆解建模前先算清楚账3.1 用一个72x24米的自动化仓库当案例技术链路打通后先别急着生成模型。做数字孪生的第一步永远不是建模而是梳理业务参数。我拿一个典型的中型自动化仓库当案例把参数理清楚。这个仓库长72米、宽24米、净高9米。仓库内部划分为三个功能区靠近收货月台的一侧是入库暂存区中间是高位货架区靠近发货月台的一侧是出库暂存区。货架区一共放了6排双深货架每排20列、5层。每一列对应一个库位位置双深意味着正反两面都能放托盘所以这一侧的库位量直接乘2。数字化拆解之后这个货架区的总库位数是6排 × 20列 × 5层 × 2深 1200个库位。这1200个库位不是1200个独立模型而是通过程序化方式批量生成的。参数算清楚后面建模清单就出来了生成逻辑也清晰了。3.2 坐标系、单位、朝向的约定3D场景里最容易出问题的就是坐标系和单位。Blender默认以米为单位这对仓储场景非常友好因为仓库图纸全部按米标注前后一致不需要额外换算。坐标约定上我把仓库长边沿X轴方向铺开短边沿Y轴方向铺开Z轴向上。这个约定在后续给前端数字孪生网站提供模型时尤其重要因为Three.js等前端渲染引擎也是这套坐标约定导出后不需要做额外的旋转修正。还有一个容易被忽略的约定是建筑朝向。我习惯把收货月台放在X轴负方向末端发货月台放在X轴正方向末端。这样在孪生场景里AGV的运动轨迹就很自然地沿着X轴方向流动视觉上符合人的阅读习惯。等到了下篇做动态数据对接时这个约定可以省掉很多坐标换算的麻烦。3.3 从业务参数到建模清单理顺参数后我列一张建模清单明确这一版场景需要生成哪些对象、各占多少数量规模。建模对象数量规模说明仓库地面1个72x24米浅灰材质高位货架6排每排双深含立柱、层板、横梁货架库位1200个程序化生成按排、列、层编号巷道路面若干条沿货架区纵向铺设颜色区分月台/出入口2处收货与发货月台空间参照物若干人员、托盘、叉车等比例参照物每一类对象的建模难度不同。马台和地面这类简单形状手工建模也不费事但货架和库位这类重复对象手工建就纯粹是浪费时间。我的思路是简单对象手工建批量对象让Agent生成最后把所有对象放进统一的命名空间和集合结构。4. 核心实操用自然语言驱动仓储场景生成4.1 一句完整的Agent指令长什么样建模清单理清楚之后就到了最有意思的部分用自然语言让Agent干活。这里的关键不是“会不会说话”而是“怎么把话说到点子上”。我在实践中总结出一个公式对象定义 尺寸参数 位置关系 材质要求 命名规则。缺一个要素Agent生成的代码就会出现偏差。以货架为例我的一条指令是这个风格“在Blender中创建双深高位货架单排尺寸为宽3.2米、深2.6米、高7.5米。每排20列、每列5层库位净高1.5米。第1排中心点放在X5米、Y8米处朝向沿X轴。货架立柱材质用深灰色金属横梁和层板用浅灰色。每一个库位生成一个带标识的空对象命名规则为Rack_排号_列号_层号。”这句话里有坐标、有尺寸、有数量、有材质、有命名Agent拿到之后几乎不需要二次追问就能直接生成代码。我承认第一次这么跟Agent对话的时候心里没底担心它理解不了但实际跑下来发现只要参数给全效果比跟建模师沟通还稳定。4.2 Agent是怎么把话拆成Blender Python的从自然语言到bpy代码这中间的逻辑链值得展开说一下。Agent收到指令后先做语义理解识别出“双深货架”“20列”“5层”这些数量参数再从经验库里匹配对应的建模方案也就是“怎么用代码创建一个像货架的几何体”最后把这些参数套进代码模板生成可执行脚本。这段逻辑拆解出来的核心代码框架长这样import bpy import bmesh # 参数区可以根据对话里的数值调整 rack_count 6 # 排数 col_count 20 # 每排列数 layer_count 5 # 每列层数 rack_width 3.2 # 排宽米 rack_depth 2.6 # 排深米 layer_height 1.5 # 层高米 grid_x 72 # 仓库长度 grid_y 24 # 仓库宽度Agent先把对话参数转化成变量然后用循环语句生成重复结构最后赋材质、命名。我验证过它生成的代码框架比人工手写的还要规范变量命名默认用snake_case循环结构清晰方便后续二次调试。4.3 关键代码解读地面、货架阵列、库位标识一个完整场景的核心代码分三块。第一块是创建地面这个最简单一个平面加一个材质就搞定。bpy.ops.mesh.primitive_plane_add(size1, location(0, 0, 0)) floor bpy.context.active_object floor.name Floor_Main floor.scale (grid_x, grid_y, 1) # 调整平面原点贴齐网格角落 floor.data.vertices[0].co (0, 0, 0)第二块是货架阵列。这一步的逻辑是创建一排货架的基本单元然后用嵌套循环复制并平移。很多人会直接把单排货架复制20次这样场景对象数量暴增卡得要命。Agent生成代码时会自动用collection实例化也就是让所有货架共享同一个网格数据只记录位置差异。这个细节对性能影响很大几千个库位能不能跑得动就看这一步怎么处理。第三块是库位标识。这里的思路是创建一个空对象只保留坐标信息用命名规则承载库位编号比如Rack_01_05_03代表第1排第5列第3层。当前端数字孪生网站需要展示库存状态时就可以通过这个命名来对接数据哪一格有货、哪一格空置一目了然。5. 从静态模型到数字孪生规范、导出与复用5.1 命名和层级场景不是“看起来像”就行做数字孪生场景光“看起来像仓库”是不够的。模型还要能被程序识别、被数据驱动、被前端拉取。这就要求模型的组织方式有规矩。我给自己定了几条硬规范。第一所有对象必须有命名前缀比如仓库地面叫Floor_前缀货架用Rack_前缀AGV轨道用Path_前缀。第二同类对象必须放进同一个Collection集合方便整体显隐和导出控制。第三每个库位必须有独立的空对象锚点锚点命名格式固定为库位编号_行_列_层。这条规矩在实践中救过我一次。当时要在前端数字孪生网站里做库存可视化业务方要求点击某个库位弹窗显示库存信息。因为我在建模时把库位命名规范做成了固定的四点格式前端直接解析对象名就拿到了坐标和编号连二次映射表都不用建。如果我当时随手起了名字后面对接数据时要手工维护一张成千上万的映射表那个工作量想想就头大。5.2 材质管理与配色规范材质的规范同样重要。数字孪生场景不是艺术创作配色要服务于信息传达而不是审美。我的配色方案是固定的仓库地面用浅灰色货架结构用深灰色货架横梁用中灰色AGV可行走区域用半透明浅蓝色安全通道用黄色警示条月台区域用深绿色。这套配色在Three.js渲染下效果也稳定不会出现明暗差异过大导致信息看不清的问题。操作层面我让Agent在生成每个对象时同步创建材质材质命名也和对象命名对应。这样后续改颜色直接全局替换材质就行。我还习惯把材质统一放进一个Materials集合导出时单独控制避免前端加载时材质丢失。5.3 导出GLB给前端数字孪生网站用模型建好、规范和材质都到位了下一个关键动作是导出。前端数字孪生网站基本都是用WebGL渲染Three.js是主流选择它支持直接加载GLB格式也就是二进制glTF。导出前有几个设置要确认。第一场景单位必须确认是米。第二所有对象有没有多余的空集合建议清一遍场景再导出。第三灯光和相机要不要导出通常前端会用自身的光照系统导出时可以不包含灯光相机只保留几何体和材质。第四动画和驱动要不要烘焙如果模型里有通过driver控制的参数化结构导出前要确认前端需要哪种形态。我用的是glTF 2.0格式导出方式可以是Blender自带导出器也可以让Agent通过MCP调用导出命令。导出后我会再用模型查看器过一遍确认尺寸比例、材质颜色正常再交给前端同事。这一步别偷懒模型在Blender里看着正常但导出过程丢材质、错比例的问题我遇到过不止一次。5.4 把常用仓储件沉淀成资产库项目做多了之后我总结出一个提高效率的方法把常用仓储件沉淀成可复用的资产库。所谓资产库就是把货架、托盘、叉车、人员、AGV小车这些高频对象做成一到两个标准版本存成独立的.blend文件或者GLB文件放到统一的资产目录。后续新项目直接让Agent调用资产库里的现有文件而不是每次从零开始生成。举个例子一套标准的仓储托盘高度150毫米、尺寸1.2x1.0米是这个行业里最常见的规格。我把它存成Pallet_Standard资产文件。下次Agent生成货架时我直接在指令里写“库位放置标准托盘”它就知道去资产库里调用了不用每次重新描述一遍托盘细节。表面上这只是省了几分钟生成时间但实际价值远不止于此。资产统一意味着整个公司的数字孪生项目里所有托盘、货架规格一致跨项目对比数据时不会出现“这个项目用的托盘和那个项目不一样”的尴尬情况。6. 踩坑记录与问题排查6.1 Agent执行中断后的恢复技巧用Antigravity跑建模任务最让人抓狂的就是一个长任务跑到一半Agent提示执行终止。最开始我以为是自己指令写得不清楚后来反复测试才搞清楚大部分原因是Blender MCP服务在执行过程中遇到了异常脚本插件报错后Agent就主动停了。这里的处理思路分三步。第一步看Blender的控制台输出它会显示具体是哪一行Python代码报错。第二步把报错信息复制回给Antigravity让它定位问题并修复。第三步让Agent把修复后的脚本从失败位置继续跑而不是从头开始。这个“断点续跑”的能力是我觉得整套方案最值的地方。传统建模方式下建模师做一个大型场景中途错了要回退很久而在Agent协作模式下错误是局部的、可以被诊断和修复的。6.2 货架一多就卡性能优化思路1200个库位的场景如果每次都生成独立的网格对象Blender会卡得怀疑人生。我在第4章里提过collection实例化这里再展开说一下优化思路。Blender里的对象分为“网格数据”和“对象实例”两层概念。如果每个库位都复制一份独立网格等于在内存里存1200份一模一样的几何数据。如果让1200个对象共享同一个网格数据只存坐标和旋转差异内存占用会断崖式下降性能立刻提升好几个档次。在bpy里的实现方式就是用collection的实例化功能或者直接用bpy.context.collection.objects.link把同一个网格数据关联给多个对象。我实测下来用实例化方案1200个库位的场景在普通笔记本上也能流畅旋转查看而不用实例化方案同样场景几乎卡成PPT。这个技巧在做大尺度园区级数字孪生时尤其重要那个场景下动辄上万个重复对象不优化根本跑不起来。6.3 MCP连接不上、指令没反应MCP连接问题是我踩得最多的坑翻来覆去就那几个原因。第一个原因是Blender没启动MCP服务自然没监听端口。第二个原因是Blender启动了但MCP插件没点启动按钮服务没运行。第三个原因是端口被占用另一个程序把9876抢走了。第四个原因是Antigravity配置里的地址填错了比如多写了一个斜杠或者端口写错。排查顺序我建议是先确认Blender开着再确认MCP插件界面显示“服务运行中”再检查Antigravity的工具列表里有没有Blender相关工具最后一眼看端口是否能通过本机访问。按照这个顺序挨个排查90%的连接问题都能快速定位。还有一个隐蔽的问题就是MCP服务启动后Blender如果被强制退出服务不会自动清理残留进程会继续占用端口。这时候重启Blender新服务起不来一直报端口被占用。解决办法是先把残留的Python进程结束掉再重新启动Blender里的MCP服务。6.4 单位错乱和坐标偏移统一基准最后一个常见问题是单位错乱。表现为Agent生成了数字看上去对但模型实际尺寸完全不对或者位置偏移到场景之外。根因往往是Agent生成的代码里用了不同的单位假设。比如仓库长度72Agent可能会理解成72厘米而不是72米直接导致比例崩溃。解决思路是在对话里从一开始就固定单位声明每次生成关键对象时都带一句“单位用米”。或者在代码模板里写死单位转换逻辑不管是厘米还是英寸进去先转成米。坐标偏移的问题也有一个常见原因Blender的场景原点没有放在预期位置或者模型没有对齐网格。我的习惯是每次生成场景前把Blender的3D光标位置重置到世界原点保证所有新建对象都在预期坐标体系下。这个细节看着不起眼但在后期对接前端时一个坐标系偏差可能导致整个布局旋转90度或者平移几米出现那种“货架跑到墙外”的诡异效果。现象可能原因处理办法Agent执行终止Blender MCP执行脚本报错查看Blender控制台输出反馈给Agent修复场景卡顿严重未使用实例化独立网格过多重构为collection共享网格数据MCP连接失败服务未启动或端口被占用按连接排查顺序逐项确认模型尺寸比例异常单位假设不一致固定统一单位模板内做换算对象位置偏移场景原点或3D光标偏移重置到世界原点检查坐标系对齐我个人在实际操作中的体会是这套Antigravity加Blender MCP的组合最大的价值不是“自动建模”这四个字而是让建模过程从“手工体力活”变成了“参数驱动的对话式协作”。我现在接手一个新的仓储项目最优先做的事情从“打开Blender开始建”变成了“先梳理参数表再跟Agent对话”。业务一旦有调整比如货架排数从6排改成8排我只需要告诉Agent改一个参数场景几十秒后就更新完了这在以前是不可想象的效率。系列下篇我准备写这几块内容的实战延伸一是把仓库的静态模型数据接到业务系统让库位的空置和占用状态实时反映在孪生场景里二是AGV路径的可视化和动态轨迹模拟三是如何把Blender里做好的场景稳定地交付给前端数字孪生网站包括性能优化和模型面数控制。先把“上篇”这套链路跑通下篇的内容才有地基。
