1. 为什么是 Antigravity Blender MCP先想清楚这套组合解决什么问题1.1 做智慧仓储数字孪生最耗时间的从来不是写代码如果你接手过仓储数字孪生项目大概率会碰到同一个问题业务逻辑不难数据接口也不难最难的是把仓库搬进电脑里。一个像样的智慧仓储孪生场景至少要有库房墙体、货架排布、托盘、周转箱、AGV路径、装卸货口、送风管道这些基础模型。传统做法是建模师在 Blender 里一格格地拉方块、对齐、复制、再对齐做一套中型仓库模型三五天算快的。更麻烦的是业务方今天说要改成双深位货架明天说要加两条 AGV 通道模型就得跟着反复改。我这次做的是智慧仓储数字孪生项目的前期实验验证AI Agent Blender MCP这条路能否把建模周期从天压到小时。整套组合的核心思路是——让 AI 直接操作 Blender用自然语言描述需求由模型自动完成建模和修改而不是人手动去挪点、拉面。标题里的三个关键词拆开看都不新鲜但组合起来价值完全不同Antigravity提供 AI Agent 运行环境的原生 IDE可以在里面配置 MCP Server让大模型带着工具干活。Blender开源免费的 3D 建模软件Python APIbpy非常完整几乎所有界面操作背后都有对应接口这是能被 MCP 接管的基础。MCPModel Context Protocol统一了AI 如何调用外部工具的协议相当于给 AI 接上了手。以前大模型只能给你生成一段 Blender Python 代码然后你自己粘贴到 Blender 里运行现在 AI 可以直接把命令发给正在运行的 Blender 实例执行完再读取结果形成闭环。这套方案适合谁适合那些懂业务、懂数据、但不想在建模上耗太多时间的技术人。如果你打算做数字孪生园区、智慧工厂、仓储可视化又不想专门配一名 Blender 建模师那这篇文章的实操链路就是为你趟路的。它不是要替代专业建模师而是把大量重复性、参数化、可描述的建模工作自动吃掉。1.2 我为什么选了这套链路而不是 Unity/Three.js 直接建模在定方案之前我对比过另外两条常见路线一条是直接用 Three.js 在 Web 端写代码生成模型。它的优点是无需中间环节做完直接上网页。但缺点是复杂模型的代码量大到惊人一个货架几十根横梁立柱每个都要写 BoxGeometry 和矩阵变换改一个列数等于重写一段逻辑。而且 Three.js 建模没有视图反馈尺寸错了要等到渲染出来才发现。另一条是用 Unity 的 ProBuilder 等插件在编辑器里搭。托引擎的福操作手感比裸写 Three.js 好很多但有两个让我劝退的问题一是资产导出和复用不如 Blender 灵活二是当前 Unity 的 AI 辅助MCP 类工具链成熟度明显不如 Blender 社区。Blender 的优势在于它是开源生态里 Python 自动化最彻底的 3D 软件。bpy 模块能访问场景中每一个对象、网格、材质、修改器配合 MCP 让 AI 调用这些 Python 接口等于把 Blender 变成了一个可被自然语言驱动的建模引擎。建模完成后再导出 glTF/GLB 给 Three.js 或者 Unity 做 Web 端展示链路非常顺。1.3 这套方案的适用边界不是所有建模都该交给 AI我也要泼一盆冷水AI 驱动 Blender 适合的是结构化、参数化、可描述的模型比如仓库里的货架、料箱、流程示意线这些对象的几何规则明确、重复度高。但如果你要建的是带曲面造型的设备外观、复杂的异形件或者是需要精细拓扑的工业产品那 AI 目前的状态还不合适你最好还是让建模师手动做。我在项目里给自己划的界限是能用语言说清楚的形状才交给 MCP 建模说不清楚的就老老实实手动建。这个判断标准往后整个项目都很受用。2. Antigravity 环境准备装好之后再谈建模2.1 安装与登录 Antigravity把 Agent 入口先跑通Antigravity 是我当前主力使用的 AI 原生 IDE 之一它的特点是内置 Agent可以直接跑多步任务而不是简简单单给你补全代码。第一步自然是安装和登录。我这边以桌面端为例下载对应平台的安装包安装完成后首次启动会引导登录。这里要提醒一点——登录态直接决定后续 MCP 配置能否生效因为 MCP 的鉴权 token 通常是和账号体系绑定的。如果登录有问题后面配置了 MCP 也会出现连接被拒、权限不足之类的怪毛病。登录进去之后先做两个动作确认 Agent 面板能正常唤起。一般快捷键或者侧边栏图标能打开 Agent 对话窗口能对话就说明基础链路通了。检查 IDE 的版本更新。MCP 功能迭代速度很快旧版本很可能没有最新的传输协议支持我遇到过一次更新出错提示最后是手动检查更新解决的。2.2 MCP 配置入口与端点填写别小看这几行 JSONAntigravity 支持通过 MCP Config 文件来注册外部工具这个配置文件和 Claude Desktop 的格式完全一致结构不复杂{ mcpServers: { blender-mcp: { url: wss://api.example.com/mcp/?tokenyour_long_token_string } } }这里有一个很关键的坑URL 地址必须是 wss 协议WebSocket Secure而不是 http/https。MCP 的传输层默认走 WebSocket如果填成 httpAntigravity 连接时会报协议错误而且这个报错藏得很深表面上只显示连接失败。配置文件的打开方式因 IDE 版本略有不同一般是在设置里找 MCP 或 Tools 入口或者在命令面板里搜 MCP Config。如果你用的是 Antigravity注意看界面上是否有启用「MCP 连接」之类的开关我一开始就是忽略了这一步导致配置文件检查了十分钟才发现开关根本没打开。2.3 验证环境的一个小技巧先跑一个回声测试不要急着上 Blender。配置完 MCP Server 之后先看 Agent 能否列出该 Server 提供的工具列表。一般会在对话中提到检测到已连接的工具或者工具面板里能看到该 server 下的工具名。如果看不到工具按顺序排查配置文件路径是否正确Antigravity 读取的 MCP Config 是不是当前项目目录下的那一份。URL 里的 token 是否有效换行符、空格都会导致 token 解析失败。网络可达性。MCP Server 如果部署在远程存在跨网络访问的问题需要确认地址能从你当前网络环境访问。这一节看起来琐碎但实际项目里大部分时间都是耗在这种看似没问题却连不上的环节上。搞定了连接才真正进入建模环节。3. Blender MCP Server把 Blender 变成 AI 的手3.1 MCP 链路拆解Blender 插件、MCP Server、AI 客户端三者怎么协作很多同学第一次接触 Blender MCP 时容易把Blender 插件和MCP Server当成同一个东西其实它们是两套代码协作关系是一条完整链路AI 客户端Antigravity负责理解你的自然语言规划建模步骤并通过 MCP 协议调用工具。MCP Server一个独立的服务进程/端点接收 AI 发来的工具调用请求再转换为 Blender 可执行的 Python 代码。Blender 插件Add-on运行在 Blender 内部提供 WebSocket 端口接收外部发来的 Python 代码并在当前 .blend 文件里执行。执行一次帮我建货架的完整过程大致是你输入自然语言 → Antigravity 拆解任务把模型拆成几步建立柱/加横梁/加层板 → 通过 MCP 协议调用对应工具携带参数 → MCP Server 转成 bpy.Python 指令 → 通过 WebSocket 发给 Blender 插件 → Blender 逐条执行生成模型 → 把执行结果成功/失败/输出返回给 AI → AI 根据结果决定下一步动作理解这条链路最大的好处是排查问题时你能准确定位故障在哪一段。比如模型没动可能是插件没开端口也可能是 MCP Server 没把参数传对还有可能是 AI 生成了错误的 bpy 代码导致 Blender 执行失败。分不清这三段遇到问题就只能瞎猜。3.2 安装 Blender MCP 插件版本匹配是第一道关社区里常用的 Blender MCP 插件以 ahujasid/blender-mcp 等开源实现为代表安装方式大同小异。建议直接在 Blender 的偏好设置里安装打开 Blender进入Edit → Preferences → Add-ons。点击Install from Disk选择插件安装包zip 或 py 文件。在插件列表里搜索 MCP Server 或刚安装的插件名勾选启用。启用后通常在侧边栏N 键呼出可以看到 MCP 控制面板里面有Start Server按钮点击后会自动启动一个本地/远程的 WebSocket 服务。这里特别强调版本匹配不同 Blender 大版本的 Python API 有差异有的插件只适配 4.x有的只适配 3.x。装错版本的表现通常是插件能勾选但启动报错或者面板不出现。我在实验时用的是 Blender LTS 版本插件兼容性最稳。还有个细节Blender 在启动 Server 时会监听一个端口这个端口要和 MCP Server 配置里的端口保持一致。如果改过端口两边都得同步改否则 AI 说连上了实际 Blender 这边什么都没收到。3.3 关于 wss 地址和 Token 的三条安全守则MCP 配置里需要填 Blender MCP Server 的端点地址形式通常是wss://api.example.com/mcp/?tokenxxxxx。从安全角度我要专门写这段不要把带 token 的完整地址直接写进博客、GitHub 公开仓库或截图。文本里带 token 的 URL 会被爬虫抓取用来冒用你的 Agent 身份。Blender MCP 提供的执行能力是完整 Python 权限一旦被恶意调用等同于在 Blender 环境里任意执行代码。所以远程部署时一定要做鉴权和 IP 白名单不要裸奔。实验结束后关闭 Blender 的 MCP Server或者至少把 token 轮换一次避免留下长期暴露的入口。这几点不夸张我见过不止一个项目把带 token 的 MCP 地址贴在团队文档里最后被外部扫描到好在只是被消耗了配额没有造成实际损失。你就当线程安全一样认真对待。4. 用自然语言长出仓储模型首个可跑 Demo 全记录4.1 第一个 Prompt让 AI 生成基础库房框架环境全通了之后别急着写复杂的仓库布局先来一个最简单的库房框架。我给 Agent 的原始指令大致是在 Blender 里新建一个长 40 米、宽 25 米、高 8 米的库房空间。移除默认的 Cube在原点附近生成一个 Floor 平面四个方向建墙体顶部加一排等距工字钢横梁材质都设成简单的灰白色。这个 Prompt 看似简单实际上把建模工作拆成了五六个子任务。AI 收到后会先生成一段类似这样的 bpy 代码import bpy # 清空默认场景 bpy.ops.object.select_all(actionSELECT) bpy.ops.object.delete() # 地面 bpy.ops.mesh.primitive_plane_add(size40) floor bpy.context.active_object # 墙体 for side in range(4): bpy.ops.mesh.primitive_cube_add(size1) # ... 设置尺寸、旋转、位置在实际执行时我发现第一版代码会犯一个典型错误Primitive 的 scale 没有 apply导致后续对齐计算全部错乱。比如它生成了 40 米长的墙但物体本身的尺寸dimensions不等于 scale 值后续 AI 再想在这面墙上打孔或者加门时就找不到基准点。解决方法是让 AI 在生成每个对象后立即应用变换bpy.ops.object.transform_apply(locationFalse, rotationFalse, scaleTrue)加上这一行之后所有对象的实际尺寸和本地坐标才跟世界坐标一致。这个小细节是整个建模过程中反复出现的问题——AI 模型天然对Transform 未应用这件事情感知很弱好在固定在 prompt 模板里就能解决。4.2 批量生成货架、托盘参数化让 AI 输出几何级翻倍库房框架跑通之后接下来是仓储数字孪生的主角——货架。仓储货架是高度规则的结构左右立柱、横梁、层板、背拉杆。这类模型手动建一个还行但要建几十排就是纯体力活。我让 AI 按参数批量生成def create_rack_row(row_index, x_pos, col_count10): for col in range(col_count): # 立柱每两列共享一根 # 横梁每层两根 # 层板每层一张 pass这里的价值一下子就体现出来了你只要用自然语言说生成 8 排双深位货架每排 12 列、5 层层高 1.5 米过道宽 3 米AI 就能循环生成几百个对象。一个普通建模师手动建 96 个货位可能要两个小时AI 在几十秒内完成而且每次尺寸都能对齐到毫米级。但批量生成也有副作用场景里对象数量暴涨Blender 的视口会变得很卡。我建议生成后用 collection集合把模型分组一个货架排一个集合方便后续隐藏、导出和管理。# 创建集合 collection bpy.data.collections.new(namefRack_Row_{row_index}) bpy.context.scene.collection.children.link(collection) # 在生成每个对象时取消链接默认集合改用指定集合 for obj in created_objects: bpy.context.scene.collection.objects.unlink(obj) collection.objects.link(obj)这个操作我在第一次批量生成时漏掉了结果 500 多个对象全部堆在根集合里后来想给某一排货架加遮挡、换材质根本选不中。4.3 AI 建模的典型翻车现场与修正话术我不打算把 AI 建模描述得完美无缺。实测过程中翻车场景不少这里列三个最有代表性的以及我验证过的修正方式翻车一尺寸单位错乱。Blender 默认单位是米但 AI 生成的代码里经常混入厘米、毫米的数值。有一次让它建 1200mm 高的托盘结果生成的是一个比库房还高的巨物。修正话术是明确告诉它Blender 场景单位是米所有与尺寸相关的数字必须转换后输入。翻车二对象用 mesh 而不是 collection 管理。AI 倾向于把所有模型对象平铺在场景里因为它最简单但这会让后期管理崩溃。修正方式是要求它按区域/类型组织 collection 层级并且把命名规范写进 prompt所有货架节点命名格式Rack_区域_排号_列号全部归纳到对应 collection。翻车三修改历史对象能力弱。你让它把所有货架第三层层高改成 2 米它可能重新生成一遍也可能改错对象。我试过比较有效的做法是前期就要求 AI 在生成对象时给对象的尺寸、位置、层高都加自定义属性Custom Properties后续 AI 能通过属性读取来定位要修改的对象而不是靠猜哪个 mesh 是哪个。# 在生成货架时附带元数据方便后续按条件筛选 obj[rack_row] row_index obj[rack_column] col obj[level] level obj[type] rack_beam加了自定义属性后AI 后续执行改第三排所有层板厚度这类指令的成功率明显提升因为它有了明确的查询条件。这个思路我认为比要求 AI 记住整个场景状态更靠谱——让场景本身携带语义信息AI 通过读取语义来操作而不是靠上下文猜。5. 建模完成之后的数字孪生链路从 Blender 到 Web 可视化5.1 导出 glTF/GLB给 Three.js 和 Unity 用的标准格式Blender 内部建模只是第一步。数字孪生项目最终要落在 Web 端或者平台端展示通常需要把模型导出为 glTF/GLB 格式这是目前 3D Web 渲染的事实标准Three.js、Babylon.js、Unity 都能原生支持。在 Blender 里导出有两种方式方式一手动导出。File → Export → glTF 2.0勾选 GLB 格式。这种方式适合一次性导出操作简单但不利于自动化。方式二通过 MCP 调用代码导出。让 AI 直接执行导出命令bpy.ops.export_scene.gltf( filepath//exports/warehouse.glb, export_formatGLB, use_selectionFalse, export_applyTrue )我强烈建议用方式二因为智能仓储模型往往需要反复迭代——货架布局一变就要重新导出。让 AI 把建模→导出串成一个完整流程才是真正的端到端自动化。导出时有几个参数特别值得留意export_applyTrue导出前自动应用所有变换。如果建模过程中有未 apply 的 scale导出模型在 Three.js 里会出现旋转/缩放错乱。use_selectionFalse导出整个场景而不是当前选中对象。如果只想导出某一部分改成 True 并按集合选中。纹理格式如果是 PBR 材质优先用 JPEG/PNG 内嵌大项目可以用 WebP 压缩容量。5.2 把模型锚定到真实坐标与库位数据从像到是有了模型还只是长得像仓库。数字孪生的核心不是静态几何而是把模型和实时数据绑定起来——货架上每个储位对应数据库里的库存记录、温湿度、出入库状态。我的做法是在 Blender 建模阶段就给每个储位对象添加自定义属性storage_id储位编码比如A-03-02-05A 区、排 03、列 02、层 05。导出时这些属性会保留在 glTF 的 node 附加数据里extras 字段。Web 端拿到 glTF 后遍历所有节点读取storage_id// Three.js 中读取节点扩展信息并绑定数据 loader.load(warehouse.glb, (gltf) { gltf.scene.traverse((node) { const storageId node.userData?.storage_id; if (storageId) { // 根据 storageId 拉取实时库存数据绑定颜色/状态 bindStorageData(node, storageId); } }); });这一步的意义是当数据库状态变化时前端直接修改对应模型节点的材质颜色、挂载标签或触发动画。仓位满载变红色、缺货变蓝色、AGV 路径在移动——所有这些都在 Three.js 里完成。Blender 只负责静态底座实时状态由数据驱动。5.3 我的实操体会上篇做到这里正好是数据与模型握手的边界这是系列的上篇我把完整的链路推进到了Blender 内模型生成 导出 glTF并验证了数据如何锚定到模型节点。按我的项目进度到这一步最大的收获其实是建立了一个认知AI 建模的瓶颈不在生成能力在于你对输出的控制能力。一开始我让 AI 自由发挥结果模型很像但我控制不了后来通过命名规范、Collection 管理、自定义属性这三板斧才让 AI 生成的东西变成可被程序消费的数据。这跟传统建模的思维方式完全不同——传统建模考虑的是好看AI 建模要考虑的是可寻址、可修改、可导出。至于接下来的内容——AGV 路径的动效、库存热力层、实时数据接入 Antigravity 控制面板以及怎么用自然语言让 AI 修改已导出的 Web 端表现我放在中篇更新。最后提醒一句如果你准备照这篇文章搭环境一定先把第 3 章的安全守则过了再动手别的都好说端口和 token 裸奔的教训我替你踩过了。