Antigravity + Blender MCP：AI驱动数字孪生场景构建实战

做数字孪生这件事过去最常见的姿势是建模师在Blender里手工搭场景前端开发在Three.js里写交互中间再接一套后端服务把实时数据喂过来。链路长、沟通成本高改一个货架位置都要两边同步。今年MCP把AI的能力接进这些工具以后事情开始变得不一样了。我最近用Antigravity配合Blender MCP把一套仓储数字孪生场景从静态模型做成了可动态驱动的半成品这套组合让我重新理解了“数字孪生”四个字。这篇是下篇重点不讲怎么装环境而是讲怎么把场景真正做出来、跑起来以及过程中踩过的坑。适合正在做前端数字孪生、搞物流仿真、或者单纯想了解AI3D工作流的朋友。1. 为什么用 Antigravity Blender MCP 做数字孪生1.1 数字孪生从“看”到“改”的变化传统数字孪生平台一般绕不开那套三层架构数据采集层、模型层、应用层。数据采集层负责对接传感器、WMS、ERP这些系统模型层负责把物理世界抽象成可计算的3D对象应用层就是给人看的可视化界面。这三层如果只是做一个静态展示页面那Three.js随便搭搭也能交差。但真正让“孪生”变得有意义的是它要跟物理实体保持同步——AGV小车的实时位置、货架库存余量、拣货任务的执行状态。一旦涉及到这种动态同步你就会被同一个问题卡住谁来改3D场景货架从A区挪到B区库存从饱满变成缺货AGV从停靠点移动到下料点这些变化都要落到Blender场景里的具体对象上。传统做法是写一堆Python脚本或者干脆让建模师手动挪效率极低。MCP出现以后这个问题的答案变成了“让AI直接操作Blender”。这不是把手工操作换成命令行操作那么浅层而是把整个场景的“可编程性”交到了一个能理解自然语言的智能体手里。1.2 组合的职责划分AI大脑、3D引擎、通信协议先说分工。Antigravity是一款AI原生的IDE它能理解自然语言指令、调用MCP Server、写代码、跑代码整个Agent的执行链路都在这个环境里完成。Blender负责提供高质量的3D场景、建模、材质、渲染能力它是所有可视化内容的最终载体。Blender MCP则是两者之间的桥把Blender的场景操作能力包装成一个个可供AI调用的工具。这个架构里的每个角色边界很清晰你可以这样类比Antigravity是大脑负责接收你的需求、拆解任务、决定下一步做什么Blender是手负责真正把物件摆进场景里MCP是神经网络负责让大脑的指令传达到手上。任何一个环节缺失这套工作流都转不起来。比方说如果只靠Antigravity写Python脚本控制Blender你得先懂bpy的API再处理IDE和Blender之间的进程通信还要自己维护错误重试逻辑而MCP把这一切标准化了AI对工具的理解成本大幅降低。角色在方案中的职责生活化类比Antigravity指令理解、任务拆解、工具调用编排项目经理兼总设计师Blender MCP暴露Blender的操作能力封装为MCP工具接口转接头Blender场景构建、材质渲染、空间计算施工现场和施工队1.3 这个方案适合谁这套组合不是用来替代专业建模流程的。Blender MCP擅长的是快速原型、数据可视化、仿真场景编排这些偏“逻辑驱动”的活儿真要做一个精雕细琢的角色模型、带复杂UV贴图的机械结构你还是得回到传统建模管线里慢慢磨。它的目标用户很明确正在做前端数字孪生项目的开发者需要快速把业务数据映射到3D场景物流仓储行业的信息化工程师想做个能实时反映库位和AGV状态的仿真看板还有一类是AI应用开发者想研究MCP这类协议在实际业务里到底能带来多大效率提升。我自己属于第一类和第三类的混合体做完这个项目最大的感受是数字孪生难的不在渲染而在“场景和你业务数据之间的那层胶水”而这层胶水恰恰是AI最擅长帮你写的东西。2. MCP 机制与 Blender 端准备2.1 MCP 三角色与一条命令的完整路径在动手之前我建议先把MCP的运行机制过一遍不然出了问题你连日志都看不懂。MCP协议里有三个角色Host是宿主应用也就是AntigravityClient是宿主内部负责发起请求的客户端组件Server是独立运行的MCP服务端比如Blender MCP。三者关系不复杂但很重要的一点是MCP Server可以跟宿主不在同一个进程里它自己监听一个端口通过JSON-RPC方式跟Client通信。一条指令的完整路径是这样的你在Antigravity的对话面板里输入“在场景里加一个2米高的货架”Agent理解“加货架”这个意图之后发现需要调用Blender相关的工具于是它查看已注册的MCP Server工具列表找到尺寸参数对应的方法组装JSON-RPC请求发给Blender MCP Server。Blender MCP收到请求后执行对应的bpy操作把执行结果比如对象名称、坐标、尺寸再打包成JSON返回给Agent。Agent拿到结果判断是否还需要下一轮操作比如“货架太高了改矮一点”。这套链路里信息的每一跳都是结构化数据AI不需要靠屏幕截图来猜它拿到的都是严格定义好的场景对象信息。这带来一个很实际的好处——可复现。同一句指令在同一个状态下执行结果是一致的。这对于仿真场景的搭建至关重要因为你的目标是让AI变成可编程的构建器而不是碰运气的盲人摸象。2.2 安装并启动 Blender MCP 插件Blender MCP的安装有几个关键步骤我直接给出来照着走就行。第一步下载blender-mcp的插件包拿到一个zip压缩包。打开Blender进入Edit菜单选择Preferences在左侧找到Get Extensions点右上角的下拉箭头选择Install from Disk找到那个zip包确认安装。装完以后在已安装的扩展列表里能找到BlenderMCP把它启用。这里要注意Blender版本我实测4.x版本问题不大太老的3.6以下版本可能兼容性不好建议直接用新版。第二步安装MCP Server本体。Blender MCP需要一个独立运行的Python服务推荐用uvx启动依赖管理干净。环境里没有uv的话先装一下或者直接用pip安装blender-mcp包。我个人的习惯是统一用uvx因为它能自动拉取依赖不会污染本地Python环境。第三步在Blender里启动服务。插件启用后会在扩展菜单里出现一个BlenderMCP的入口点击Start Server。此时切到Blender的控制台窗口如果看到类似“MCP server started on ws://127.0.0.1:9876”的输出说明服务已经起来了。9876这个端口是默认的WebSocket端口后面所有通信都走这里。注意启动服务之前确保Blender没有被多个实例占用。我在一次调试中同时开了两个Blender窗口结果MCP请求被随机分发对象创建得乱七八糟排查了半小时才发现是这个原因。2.3 在 Antigravity 中注册 MCP ServerAntigravity这一侧要做的是把Blender MCP注册成它的MCP Server资源。你可以在Antigravity的设置入口里找到MCP相关的配置新建一个Server类型选command启动命令填uvx参数填blender-mcp。如果你更习惯用配置文件维护可以在项目根目录维护一个mcp.json内容大致如下{ mcpServers: { blender: { command: uvx, args: [blender-mcp] } } }配置完成后重启Antigravity的会话或者重新加载MCP配置让它重新连接Blender MCP Server。连接成功的标志是MCP工具列表里出现了get_scene_info、add_cube、set_object_transform这一类的工具。如果列表是空的多半是Server没启动或者Antigravity还没探测到。这里我想强调一点MCP工具的命名和语义决定了Agent能不能用好它。Blender MCP默认暴露的工具非常多覆盖了对象创建、变换、材质、场景查询、物体选择、删除等常见操作这些都是“常见操作”里最有用的那一层。第一次使用建议先让Agent调用get_scene_info看看场景里有什么再决定下一步这能有效减少“幻觉式操作”。工具类别常见工具示例典型用途场景查询get_scene_info、get_object_info确认对象存在性、坐标、尺寸对象创建add_cube、add_cylinder、add_plane生成货架、货物、地面对象变换set_object_transform设置位置、旋转、缩放材质相关add_material、assign_material区分库存状态、区域标识场景管理clear_scene、delete_object、duplicate_object重置、批量复制3. 进阶实战构建动态仓储数字孪生场景3.1 场景数据模型设计做数字孪生的第一件事不是打开Blender而是先定义数据模型。没有数据模型AI生成的场景就是一堆没有意义的方块。我定义了一个非常精简的JSON结构用来描述仓储场景里的几类核心实体地面是固定背景货架是存储单元货物是货架上的状态载体AGV是要移动的目标路径点是AGV的导航轨迹。{ warehouse: {width: 20, depth: 12}, shelves: [ {id: 1, x: 2.0, y: 0, width: 3, height: 2.4, layerCount: 4, status: normal} ], goods: [ {id: G-001, shelfId: 1, sku: SKU-8821, stock: 120, capacity: 200} ], agvs: [ {id: AGV-01, x: 0, y: -3, angle: 0, loadStatus: empty} ], waypoints: [ {id: WP-1, x: 0, y: -3}, {id: WP-2, x: 4, y: -3}, {id: WP-3, x: 4, y: 6} ] }这个结构看起来简单但它是整个场景的“业务坐标系”。我特意在对象命名上做了约束BLender里的物体名和数据里的ID一一对应比如货架shelf_01对应数据shelf_id1AGV-01对应数据agv_idAGV-01。这一步是整套方案的灵魂因为后面所有AI操作都依赖对象名来定位如果命名规则混乱Agent很快就会卡在“找不到对象”的泥潭里。3.2 从空白场景到基础仓储布局数据模型有了以后我就开始指挥Agent搭场景。我并没有把所有指令一次性抛给它而是分步走每一轮都让它先查询场景信息再执行这样我能通过返回值判断它是否理解正确。第一轮我输入请先清空场景然后创建一个长20米、宽12米的仓库地面。Agent先调用clear_scene清掉默认的立方体然后add_plane创建平面再用set_object_transform把平面缩放到20×12的比例位置归零。它返回给我一个对象清单地面坐标和缩放都对上了。第二轮我根据shelves数据要求生成货架请按数据在x2.0, y0位置生成一个4层货架每层高度0.6米。Agent的做法是用add_cube创建货架的主体框架再通过循环创建多个立方体作为层板然后用set_object_transform逐层摆位。前后大概十几秒场景里出现了一个结构清晰的货架。第三轮把goods数据映射成货物对象。我要求在shelf_01的第1、2、3层各放两个货物立方体尺寸是0.4×0.4×0.4。Agent先查询了shelf_01的尺寸和坐标算出每层能放的位置再批量创建小立方体。这一步它处理得比我预期好因为它不是盲目摆放而是先get_object_info拿到了货架子对象的实际坐标再计算说明“先查询后操作”这个习惯已经内化到它的执行逻辑里了。第四轮创建AGV和路径点。我用add_cylinder生成一个圆柱体代表AGV再沿着waypoints创建几个小圆环作为路径点标识。到这里一个静态的仓储场景已经成型地面、货架、货物、AGV、路径点全部都由AI基于JSON数据驱动生成。3.3 动态驱动AGV 移动与库存状态联动静态场景只是开始真正让数字孪生“活”起来的是动态驱动。我写了一个模拟运行周期的循环逻辑让Agent每隔几秒处理一批业务事件。第一类事件是AGV移动。AGV从WP-1出发沿路径点移动到WP-2再转向WP-3。每一步移动Agent都调用set_object_transform更新AGV-01的location和rotation参数。具体来说location从(0, -3, 0)移动到(4, -3, 0)rotation的Yaw角跟着路径方向变化。这一步的返回结果很重要——如果某个路径点在场景里不存在Agent能立刻发现并报告异常而不是硬着头皮往下算。第二类事件是库存状态可视化。货物G-001的库存从120降到60我让Agent把对应的货物对象材质颜色从绿色变成黄色库存继续降到30就变红色。Blender MCP提供材质工具Agent用add_material创建三种备选材质再根据库存阈值assign_material给对应货物对象切换。这样从视觉上一眼就能看出哪些库位缺货不需要去看表格数据。第三类事件是连续动画。单纯改位置是跳变的看起来不够真实。我在一轮指令里要求Agent在每次位置更新时插入关键帧这样在Blender的时间轴上就能形成AGV的平滑运动轨迹。关键帧插入不属于Blender MCP的默认工具但Antigravity作为IDE它能直接生成Python脚本调用bpy来补充这部分能力。这正好体现了Antigravity MCP组合的弹性MCP解决工具接口IDE解决代码逻辑两者互补。3.4 视觉验证和一轮指令纠偏动态驱动做完以后我遇到一个很典型的问题Agent告诉我它已经把AGV移动到了正确位置但我从Blender视口看过去AGV压根没动。问题出在它只更新了位置参数没有更新rotation参数导致AGV的朝向还是默认方向看起来像横着滑过去的这种“形变而神不变”的问题从数据上检查不出来必须看实际渲染结果。所以我把“视觉验证”设计成一个独立环节。做法是让Agent在执行完一系列变换后强制调用渲染或截图能力把当前视图状态反馈回来。默认的Blender MCP没有直接的截图工具但Antigravity有代码执行能力可以让它用bpy自带的viewport渲染接口把当前透视视图渲染成PNG图片然后由我检查这张图再决定是否进入下一轮操作。这个“人机校验”的环节非常关键。AI在没有视觉反馈的情况下很容易在前几轮操作正确后面累积误差越偏越多。每次大改之后亲眼确认一次比最后统一排查省力得多。实测下来最稳的做法是一轮不少于三次构建前看数据构建中看对象信息构建后看渲染图。4. 与前端/Web 数字孪生衔接4.1 导出 GLB 与 JSON 场景清单Blender里的场景做得再花哨最终要落到前端页面给人用这就需要解决数据出口问题。Blender可以直接导出glTF格式的GLB文件这是Web 3D的通用格式Three.js原生支持。导出的方式是选中场景里的所有对象File菜单里选择Export选glTF 2.0格式。这里有一个坐标系的坑必须提醒你Blender默认是Z轴向上而Three.js默认是Y轴向上。直接导出不处理的话场景到前端会整个躺倒货架变成“趴”在地上的。解决办法有两个导出时勾选“Y Up”选项或者在Three.js加载后把根节点旋转-90度。我习惯用前者因为这样GLB文件本身就符合Web坐标系习惯后面所有对象的position值不用做额外换算。除了GLB我还需要一份场景清单JSON用来在前端做对象查询和状态绑定。Blender没有一键导出JSON的功能但可以在文本编辑器里跑一段Python脚本把对象的名称、类型、位置、旋转、缩放全部输出到一个JSON文件里。import bpy import json items [] for obj in bpy.context.scene.objects: items.append({ name: obj.name, type: obj.type, location: list(obj.location), rotation: list(obj.rotation_euler), scale: list(obj.scale) }) with open(/tmp/scene.json, w, encodingutf-8) as f: json.dump(items, f, indent2, ensure_asciiFalse) print(exported, len(items), objects)这份JSON和GLB是一一对应的前端拿到GLB渲染场景拿到JSON建立对象索引两边一关联就完成了Blender到Web的空间映射。4.2 Three.js 加载与运行时控制前端这块我用的是Three.js标准加载流程GLTFLoader加载GLB文件加载完成之后通过object.name从scene里取出具体对象。因为我们前期就定了命名规则这一步非常丝滑AGV-01、shelf_01、G-001这些名字在GLB里原样保留前端不需要维护额外的映射表。import * as THREE from three; import { GLTFLoader } from three/addons/loaders/GLTFLoader.js; const loader new GLTFLoader(); const scene new THREE.Scene(); loader.load(/models/warehouse.glb, (gltf) { const root gltf.scene; scene.add(root); // 实时更新AGV位置 setInterval(() { const agv root.getObjectByName(AGV-01); if (agv) { agv.position.x 4.0; agv.position.z 6.0; } }, 2000); });这个端点进去以后前后端的数据流就串起来了后端业务系统产生物流事件前端收到事件后更新Three.js对象的position和颜色Blender那边的场景只负责离线构建和导出。实际项目中Blender不必常驻真正对外服务的是GLB加JSON这套静态资产加上一个能接收实时数据的Web端运行时。有一件事我想特别提醒GLB文件里对象的坐标是导出那一刻的快照运行时更新只发生在浏览器内存里不会反向影响Blender源文件。所以要改场景结构回Blender改完重新导出即可运行时只需要关心状态更新两者解耦非常清爽。5. 常见问题排查与避坑记录5.1 MCP 连不上、断连与版本不匹配这个是最常见的故障区我把现象和解决方案整理成一张表遇到可以照着查。现象可能原因处理方式Antigravity工具列表为空Blender端Server未启动确认Blender控制台出现ws://127.0.0.1:9876连接后立刻断开MCP Server进程异常退出查看Antigravity日志里最后抛出的异常信息操作偶尔超时场景对象过多执行时间太长拆分成多轮小指令执行创建对象返回失败Blender版本和插件不兼容升级Blender到4.x插件源码优先拉最新版uvx依赖安装失败本机Python版本过旧用uv自带的Python或pip单独安装我自己最常踩的是“配置了MCP但忘了重启会话”。Antigravity对MCP Server的探测往往在会话初始化阶段完成新增Server之后不重启工具列表就一直不刷新看起来像连接失败其实只是个缓存问题。5.2 agent 执行中途终止我遇到过几次“agent execution terminated due to error”之类的报错一开始以为是MCP协议问题后来定位下来多半是工具返回的内容太大导致Agent的单轮上下文被塞满后续指令执行不下去。比如get_scene_info在对象特别多的时候会返回一长串数组直接塞进对话上下文里既占token又容易触发截断。处理方法有两个一是给Agent下指令时明确要求它只返回必要信息比如“只返回货架对象的名称和坐标不要返回材质参数”二是分小步执行一次别让Agent处理十几个对象改成一类对象一个批次。这不仅仅是规避报错也是让Agent少犯错的有效策略。5.3 坐标轴与材质表现异常坐标轴的问题在4.1提过Blender的Z轴向上和Three.js的Y轴向上是历史遗留差异导出GLB时勾选Y Up是最省事的解法。材质方面一个容易踩的坑是Blender的Eevee渲染引擎和Cycles渲染引擎对材质的支持不同。MCP创建的材质在Eevee实时预览里可能看起来发灰切到Cycles渲染才显示完整光照效果。如果你只是做数字孪生看板建议直接用Eevee同时把材质的金属度和粗糙度参数调低一点避免出现“塑料反光”的廉价观感。5.4 数据量大了怎么办真实仓储场景里货架数量轻轻松松上百个每个货架又有几十个库位如果让Agent逐个add_cube创建速度完全不可接受。我发现最优的做法是用duplicate_object批量复制已有对象再微调位置。先创建一个模板货架然后用循环复制一百次每次通过set_object_transform设置新坐标整体效率能提升一个数量级。另外对象命名的规范在数量上来以后显得越发重要。没命名规范的时候Agent在几十个同名Cube里找目标对象会非常痛苦有了规范它可以按前缀过滤对象列表比如“列出所有shelf_开头的对象”整个查询成本大幅下降。性能问题的本质往往不是计算量而是数据组织方式。做完这个项目我个人体会最深的一点是数字孪生项目的瓶颈从来不是渲染引擎的渲染能力而是“业务数据”和“3D对象”之间那层转换逻辑。以前这层逻辑靠人肉编写工作量大且难以维护现在有了Antigravity加Blender MCP转换逻辑可以由AI半自动生成而人能专注于数据建模和结果校验。视野再放宽一点MCP生态里类似的Server还有很多比如把设计稿信息直接喂给AI的蓝湖MCP、让AI操作浏览器的Playwright MCP本质都是同一件事把某个领域的操作能力标准化交给大模型调度。工具会迭代但“通过协议把AI接入具体生产工具”这个思路会是接下来很长一段时间的确定性方向。