企业官网建设流程全解析

仓储数字孪生这个话题，我在上篇把静态场景搭建和基础数据映射聊完了，这篇是下篇，重点从“像”升级到“活”。我这次把 Antigravity、Blender MCP 真正组合起来，做了一个能接收真实仓储业务数据、能响应自然语言指令、能自动调整货位规划的进阶方案。如果你手里已经有一套大致能看的仓库 3D 模型，但一直卡在数据联动和 AI 调度上，这篇的每个环节我都按实际踩过的坑来写，建议对着操作。

先说清楚这套组合解决什么问题：Antigravity 负责云端的 AI 编排和业务逻辑，Blender 负责 3D 场景的可视化和空间计算，Blender MCP 则是中间那根“神经”，把自然语言指令翻译成 Blender 能执行的动作。三者串在一起，数字孪生才真正具备“收到消息就动、听懂人话就改”的能力，而不是一张静态大屏。

1. 进阶版要解决的 3 个核心问题

1.1 从“能看”到“能用”：数字孪生的三层演变

区分一个数字孪生项目是“演示级”还是“生产可用”，我一般看三层能力是否贯通。

第一层是静态还原。这一层在上篇基本完成，仓库的建筑结构、货架摆位、消防通道、月台布局能按图纸或现场测量还原，灯光一打、材质一贴，视觉效果已经不错。但这一层的本质还是“模型”，它不会因为库存变化而变化，也不会响应任何业务指令。

第二层是数据联动。库存、订单、AGV 位置、温湿度传感器这些真实数据能流进场景，模型里的货物数量会跟着库存快照增减，AGV 小车会沿着巷道移动，异常事件会触发报警闪烁。走到这一层，数字孪生才从“看个样子”变成“看状态”，领导排产、仓储经理调度都愿意参考这个系统。

第三层是 AI 驾驶。也就是这篇真正想讲的进阶点：用户不再需要通过下拉菜单、按钮去操作孪生体，而是直接用自然语言下达指令。比如“把 B-02 货位剩余空间小于 20% 的区域标红”，Antigravity 会对这句话做意图解析，拆解出业务条件，再通过 Blender MCP 调用对应的场景操作接口，最终在 Blender 视口中高亮那些货位。整个过程不需要人工写任何 Python 脚本，也不需要在 Blender 里做复杂选择。

第三层一旦跑通，数字孪生的角色就从“可视化工具”变成了“智能助手”，这也是为什么选 Antigravity 而不是只写一套老式管理后台的主要原因。

1.2 为什么偏偏是 Antigravity + Blender MCP

这个问题我在上篇埋了个伏笔，这里展开讲。当时我也对比过几条技术路线，各有各的问题。

第一条路线是直接在 Blender 里跑 AI 模型推理，让模型输出 Python 脚本操作场景。听起来很直接，但实际做起来相当难受：大模型权重动辄几个 GB，普通工作站推理速度慢，而且 Blender 的 Python 环境受插件机制限制，装深度学习依赖容易把场景搞崩。再加上每次都要在 GPU 上跑推理，成本和稳定性都不理想。

第二条路线是自己写一套规则引擎，把自然语言指令转换成固定操作。这个方案在 demo 阶段能应付，但它本质上还是“关键词匹配 + 模板填充”，稍微换一种说法就失灵，维护一套不断膨胀的规则表比写代码还痛苦。

第三条路线就是 Antigravity + Blender MCP 这种组合。Antigravity 这类支持 MCP 协议的 AI 编排平台，天然适合把大模型能力和外部工具解耦。大模型只负责理解意图、维护上下文、拆解任务，Blender 只负责具体的 3D 操作，两者之间用标准化的 MCP 工具协议通信。这样做的好处有三个：模型和场景互不污染、可以分别换版本升级、单点故障也好排查。

另外，Blender MCP 的好处是它已经封装好了读场景、创建物体、修改变换、材质编辑这一整套工具，不需要每做一个新功能就去改 Blender 插件源码。大部分仓储场景操作都能通过现成的 MCP 工具完成，少部分特殊操作再挂一个自定义 tool，开发效率比从头写插件高很多。

1.3 整体架构与数据流

这个项目跑起来以后，整个数据链路可以用一句话描述：仓库现场的数据往上送，AI 的决策指令往下发，Blender 在中间把空间变化呈现出来。

数据上行链路是：仓库现场部署的传感器、AGV 调度系统、WMS 业务库，通过 MQTT、WebSocket 或 REST API 把状态数据推送到数据总线；Antigravity 编排层订阅这些数据，结合业务规则和大模型分析，生成场景更新指令；指令通过 Blender MCP Server 进入 Blender 内部，最终修改模型状态。

控制下行链路是：用户在 Antigravity 对话界面输入自然语言指令，AI 解析意图后，决定调用哪一个 MCP 工具，传入什么参数；Blender MCP Server 执行成功后，把场景新的状态返回给 AI 平台；同时，Blender 视口实时的变化也会让操作者直观看到结果。

这里有一个我在架构设计时才想明白的点：Antigravity 不要直接连数据库去做高频查询，也不要直接把 Blender 的本地文件路径暴露给用户。数据更新和场景操作都应该通过标准化事件解耦，也就是先定义 JSON 事件结构，再让 Antigravity 和 Blender 各自处理事件。这样哪怕以后把 Blender 换成其他渲染引擎，或者换掉数据源，整套编排逻辑还能继续复用。

2. 环境搭建与链路打通

2.1 Blender MCP 插件安装与启动

MCP 玩法的核心是把 AI 模型接到外部工具上，这要装好 Blender 侧的 MCP 插件。我用的是 Blender 4.x 加配套的 blender-mcp 扩展，安装流程不算复杂，但有几个细节不注意就会翻车。

第一步，打开 Blender 后进入“偏好设置-插件”，点击“安装”按钮，选择下载好的 blender_mcp 插件包。安装完成后在插件列表里勾选启用，检查左下角是否出现 MCP 相关面板。

第二步，在 3D 视口按 N 键拉出侧边栏，找到 MCP 标签页，里面一般会显示 server 状态和端口号。默认端口通常是 9876，点击“Start MCP Server”按钮启动服务。插件本质是在 Blender 内部跑了一个 WebSocket 服务，监听来自 AI 客户端的指令。

第三步，验证服务是否真正起来了。可以在终端执行curl http://localhost:9876看返回握手信息，也可以在 MCP 标签页看状态是否为 running。我实际遇到过一种情况：插件显示启动了，但外部连不上，最后发现是 Blender 的 Python 脚本目录权限不对，导致 server 线程根本没起来。所以验证这一步不能偷懒。

第四步，非常重要的一点，不要把插件安装到只读的安装包目录。Blender 的插件目录优先级可以配置，建议把 blender_mcp 放到用户目录下的用户脚本目录，这样后续修改代码或者升级版本都方便，不会被系统权限卡住。

配套环境上，建议本地安装一个 Python 3.10+，用于跑 MCP Client 侧的命令行测试工具，方便调试 Antigravity 接入前的链路。如果只想快速验证 MCP 协议本身是否正常，可以先不接 Antigravity，用 MCP 官方调试客户端或者简单的 WebSocket 客户端连上去发几条指令试试。

2.2 在 Antigravity 项目中配置 MCP Server

Antigravity 在这里的角色是 AI 编排平台，所以需要在项目里把 Blender MCP 声明为一个可调用的 MCP Server。不同平台的配置界面可能不一样，但逻辑上都是在“项目设置-模型上下文协议”或“External Tools”里添加一条 MCP 记录。

配置时通常需要填几个关键字段：Server 名称，建议起得有意义一点，比如blender-warehouse，方便后续在对话中识别；Transport 类型，支持 HTTP 或 WebSocket；Endpoint 地址。由于 Blender 是跑在本地图形工作站上的，如果 Antigravity 平台部署在云端，就需要让 Endpoint 能被平台访问到。我实际部署时是把 Blender MCP Server 放在带 GPU 的工作站上，工作站和 Antigravity 项目处于同一个虚拟私有网络内，这样配置内网地址就能直接联通。

写到这里必须提醒一下认证问题。Blender MCP 刚启动时通常没有任何鉴权，局域网内谁都能连，这在正式环境是绝对不能接受的。我在工作站前端加了一个轻量级的转发层，对请求做 API Key 校验，只有携带项目密钥的请求才能进到 Blender MCP。这个动作能在后续排查时省很多事，因为所有请求都带着明确的来源标识。

配置完成后，在 Antigravity 的控制台里测试连接。测试通过后，平台侧会列出这个 MCP 暴露出来的工具清单，包括创建物体、修改变换、查询场景信息、执行自定义 Python 代码等。看到清单就说明链路已经通了，下面进入真正的功能验证。

2.3 验证链路：让 AI 在 Blender 里建一个货架

链路通没通，最直观的验证方法是向 Antigravity 发一条自然语言指令，让它操作 Blender 创建物体。

我当时的测试指令是这样写的：“请在坐标 (2, 3, 0) 处创建一个长 2 米、宽 1 米、高 1.5 米的立方体，命名为 Aisle_Shelf_01，并把它的颜色设置为灰色。”

这条指令执行过程大致是：Antigravity 识别出这是一个几何体创建任务，调用 Blender MCP 的create_cube工具，传入 location、scale、name 等参数；Blender MCP Server 在 Blender 场景中执行操作；执行完成后返回一个结果对象，包括新物体的名称、位置、尺寸和场景当前物体数量。

我实际遇到的问题很有代表性：第一次执行时，AI 生成的尺寸参数经过单位换算后偏大，创建出来的货架占了半条巷道。原因是 Blender 默认长度单位是米，但 AI 训练数据里大量包含以厘米为单位的建模教程，模型会在没有明确约束的情况下自行猜测单位。解决办法是在 MCP 工具的参数描述里明确注明“所有尺寸参数均以米为单位”，并在系统提示词里反复强调仓储场景使用国际单位制。加了这个约束之后，同类问题出现的频率明显降低。

链路验证通过后，我强烈建议把整个执行过程录屏存档。一方面方便向业务方展示“AI 能直接操纵数字孪生体”的效果，另一方面也是后续做问题排查的 baseline，一旦某个版本升级后行为异常，翻出旧录像做行为对比非常管用。

3. 用 AI 驱动批量场景生成

3.1 场景层级设计：为数据联动打好基础

很多数字孪生项目后面数据接不上，不是因为接口不会写，而是因为建模阶段根本没有给物体挂业务主键。这一步我吃了亏，最初建的模型里所有物体都叫 Cube、Cube.001、Cube.002，数据来了根本不知道往哪个模型上写。

进阶做法是场景根节点下按功能分区建立层级：Warehouse 根节点下挂 Shelving_Zone、Shipping_Dock、AGV_Paths、Buffer_Area 等子节点；每个货架物体必须通过 custom properties 挂上 shelf_id、rack_code、zone_name 等属性。这样 MCP 工具查询的时候才能通过属性索引精确找到对应物体。

在 Blender 中，custom properties 本质上就是物体对象上的字典属性，可以用 Python 直接写入：

import bpy obj = bpy.data.objects["Shelf_H1-03"] obj["shelf_id"] = "H1-03" obj["rack_code"] = "H-RACK-03" obj["zone_name"] = "HighFrequency"

这套命名和属性规范看起来琐碎，但它直接决定了后续第 4 章的数据联动能不能按预期跑通。我后来总结出一条经验：任何进入数字孪生场景的动态物体，至少要挂三个属性——业务 ID、所属区域、物体类型。三者缺任何一个，后面都要返工。

3.2 用 Antigravity 生成场景 JSON 再批量写入

如果让 AI 逐个创建几百个货架，效率太低，而且对话上下文很快就会超长。第二次迭代时我换了一种思路：让 Antigravity 负责生成结构化 JSON 数据，Blender 负责批量执行。

具体流程是，先在对话里描述仓储布局需求，例如有多少排、每排几列、通道宽度多少、货架尺寸多少。Antigravity 会把需求拆解成一个 JSON 数组，每项包含货架 ID、坐标、尺寸、朝向、分区等字段。然后通过 MCP 工具把这个 JSON 作为输入传给 Blender 的批量导入函数。Blender MCP Server 内部执行一段 Python 脚本，遍历 JSON 创建所有货架。

JSON 结构可以设计成这样的形式：

[ { "shelf_id": "H1-01", "x": 2.5, "y": 3.0, "z": 0.0, "width": 2.0, "depth": 1.0, "height": 1.8, "rotation_z": 90, "zone": "A" }, { "shelf_id": "H1-02", "x": 5.5, "y": 3.0, "z": 0.0, "width": 2.0, "depth": 1.0, "height": 1.8, "rotation_z": 90, "zone": "A" } ]

这里有一个关键逻辑：AI 只生成数据和参数，真正的几何创建交给本地 Python 函数完成。好处是每个物体的命名、属性挂载、材质分配都由同一段代码保证一致性，不会因为是 AI 生成的而出现命名错乱或属性缺失。这比我最初直接让 AI “写出完整 Python 脚本”要稳定得多，因为大模型生成的脚本重复逻辑一旦膨胀，出错率会快速上升。

批量生成完之后，在 Blender 中筛选场景内物体数量，确认创建总数和 JSON 条目一致。如果有遗漏，优先检查 JSON 里是否出现了重复的 shelf_id。重复 ID 会导致后面的货架把前面的覆盖掉，但场景里物体数量却不会报错，这种问题初看非常隐蔽。

3.3 坐标系对齐：让孪生坐标和物理世界严格对应

数字孪生的坐标对齐，本质上是一个“刚体变换”问题。物理世界的坐标是米制地理坐标或局部坐标，Blender 场景坐标也是米制。两者之间要做的是一个旋转 + 平移的映射，有时候还要加一个镜像翻转。

我在仓储项目里拿到的现场资料分两种：一种是有 CAD 图纸的，坐标原点和轴线方向都很明确；另一种只有现场照片和粗略测量数据，就需要自己在仓库地面找参考点。

推荐的方法是“三点标定”。在仓库地面找三个明显的物理参考点，例如消防柱中心、月台边缘、某个固定货架的柱脚。用测量工具拿到这三个点的真实坐标，在 Blender 中也对应放置三个空物体作为参考点，然后根据这两组点计算旋转平移矩阵。这个矩阵可以应用到整个场景的父级节点上，实现一次到位。

实操中我踩过一个镜像坑：Blender 默认 Z 轴向上，但很多建筑图纸是 X 向右、Y 向上的平面坐标，如果直接照搬坐标，模型在俯视图上会左右颠倒。后来我在 Antigravity 的系统提示词里加入了一句“本项目坐标采用右手系，X 向东，Y 向北，Z 向上”，这种情况才真正杜绝。

坐标对齐之后务必做一次可视化校验。在 Blender 视口中打开“Grid Floor”，把现场三个参考点之间的距离与 Blender 里对应空物体之间的距离做对比，误差控制在 10 厘米以内才算合格。误差来源一般来自物理测量误差和多点旋转矩阵的计算误差，为了一个仓储演示场景追求毫米级精度意义不大，厘米级足够。

3.4 模型精度与性能的取舍

场景里一旦有几百组货架、上千个货物模型，面数和物体数量都会失控。Blender 在视口中的交互帧率会变得很低，MCP 指令执行也会出现明显延迟，严重时整个界面卡死。

立体货架的正确做法是让 AI 生成的数据驱动 Array Modifier 和 Instance，而不是真的创建几百个独立网格物体。Array Modifier 在渲染时不增加实际内存占用，能提升场景管理效率。每个货架可以由：两根主立柱、若干横梁隔板、一个父级 Empty 构成，父级 Empty 负责承载 shelf_id 属性，子网格负责外观。

材质方面，不要给每个货物赋予独立材质。我按 SKU 分类共享材质槽，并给每个货物物体挂上 sku_type 属性，这样外观上能区分品类，又不至于出现上千个材质实例。

LOD（多细节层次）在后期同样重要。视图缩放较远时，可以切换到简化版替身模型，近景再显示高精度细节。Blender 的集合实例和视图显示层级可以做到这一点，在集合属性里设置视口最大缩放级别即可。

我这里有一份性能基准供参考：一台 RTX 3060 的图形工作站，Blender 场景中 500 个货架 + 3000 个货物 cube，使用 Eevee 渲染，视口帧率保持在 60 FPS，MCP 工具响应时间在 200 毫秒以内，这是比较健康的状态。如果明显低于这个水平，优先检查模型实例化程度和材质数量。

4. 让孪生体“活”起来：数据接入与联动

4.1 仓储场景里究竟要接哪些数据

数字孪生不是把数据库表搬进 Blender，而是让最有决策价值的数据驱动场景变化。我梳理过仓储现场的数据源，最终落地时只保留了四类：

第一类是 WMS 库存储备数据。包括每个货位的 SKU、批次、数量、库存状态。这一类的更新频率不需要很高，30 秒到一个分钟级同步一次足够，因为库存变化本来就是事务性的。第二类是 AGV 小车调度数据。AGV 的位置坐标、当前任务、速度、状态变化，更新频率要求较高，建议 500 毫秒到 1 秒一次，否则小车的运动轨迹在孪生体里看起来很生硬。第三类是环境传感器数据，包括温湿度、门禁状态、烟雾报警等。这类数据量不大，但一旦触发异常，必须立刻以高亮警告的形式反馈到场景中。第四类是空间感知数据，这在第 5 章单独展开，主要依赖 3D 结构光相机生成的点云。

踩过一个常见的坑：一上来就拉全量数据，把整个 WMS 的明细表全部导入，结果 Blender 里的货物模型数量爆炸，内存直接不足。正确的做法是聚合。货位级别的 SKU 数量做聚合展示，不需要逐箱子渲染。一个货位一个货物 cube，数量字段用属性记录，需要查看明细时再点击查询，而不是把所有明细都建成实体。

4.2 把业务事件标准化：统一 JSON 结构

数据接入的稳定性，完全取决于事件结构定义得好不好。架构上要避免 Antigravity 直接去解析各种异构接口，而是让数据接入层先统一转换成标准 JSON 事件。

我定义的事件结构长这样：

{ "type": "inventory_change", "shelf_id": "H1-03", "action": "add", "sku": "PN-8842", "qty": 120, "ts": "2025-01-18T10:30:00Z" }

type字段决定 Blender 用哪套处理逻辑，shelf_id决定操作哪个物体，action决定是新增、移除还是修改，sku决定货物外观，qty用于更新属性面板显示，ts是时间戳。

做事件总线时，我踩过的坑是所有事件都用一个主题推送，导致 Blender 侧每收到一条都要判断类型，频繁的字符串比对拖慢了处理速度。后来按业务域拆成了多个主题，iqty、inventory、agv_status、sensor_alert分开订阅，每个主题对应一个 MCP handler，逻辑清晰很多，性能也好了。

这个标准化事件结构是整个联动方案的地基。只要字段定义稳定，数据源换掉、数据库换掉、渲染引擎换掉，影响都不会扩散到业务逻辑层。我甚至把这份 JSON 结构打印出来贴在工位上，后面几轮迭代基本没有改动过。

4.3 Blender 内部如何响应数据事件

Blender MCP Server 接收到事件后，需要根据事件类型调用对应的处理器。以库存变更事件为例，处理逻辑分三步：

第一步，根据shelf_id找到场景中对应的货架物体。由于建模阶段挂了 custom property，这一步可以用遍历方式查找，也可以用 Blender 的 collection 层级直接定位。几百个物体的场景里，循环遍历的耗时完全可以接受。

第二步，根据action决定操作。add动作在货架父级下实例化一个 SKU 货物 cube；remove动作查找货架下对应的 SKU 物体并删除；update动作则调整数量和属性。

第三步，执行完成后更新物体属性面板，并把结果返回给 Antigravity。

处理代码我封装成了一个函数，方便在 MCP 工具中调用：

def handle_inventory_change(evt): shelf = find_by_prop("shelf_id", evt["shelf_id"]) if not shelf: return {"status": "shelf_not_found"} if evt["action"] == "add": sku_obj = create_sku_cube(evt["sku"], parent=shelf) sku_obj["sku"] = evt["sku"] sku_obj["qty"] = evt["qty"] sku_obj.location.z = get_next_stack_height(shelf) return {"status": "ok", "sku_object": sku_obj.name} if evt["action"] == "remove": sku_obj = find_child_by_sku(shelf, evt["sku"]) if sku_obj: delete_object(sku_obj) return {"status": "ok"} return {"status": "unsupported_action"}

这里有个细节：货物 cube 叠加在货位上，get_next_stack_height函数需要计算当前货位上放了几层货物，决定新货物落点的 Z 坐标。如果只有一层货位，这个函数就是固定高度；如果是多层货架，就需要先查出原有货物的层数再加一。

动画方面，如果希望货物放入货架时有一个平滑下落效果，MCP 执行完位置赋值后，可以再用 Blender 的时间轴节点做一个简单插值。但仓储场景的核心是数据准确，不是动画好看，所以动画我建议只对 AGV 做平滑移动，货物增删直接瞬变即可，省下来的性能用在高密度场景维护上。

4.4 用 Antigravity 编排一个“有脑子的”联动流程

数据接入解决的是“场景跟着业务走”，而 Antigravity 的编排能力让场景具备“决策和对话”能力。我在项目里实现了三类比较有价值的自动流程。

第一类是定时库存同步。Antigravity 里配置一个定时任务，每 30 秒从 WMS 拉取库存快照，生成标准inventory_change事件，推送到 Blender。这个过程几乎是全自动的，不需要人工干预。第二类是条件触发任务。我在 Antigravity 中设置规则：当某个分区空余率低于阈值时，自动调用 MCP 工具把对应区域高亮，并生成一条补货建议推送给运营人员。高亮的实现方式是给货架物体赋予一个半透明发光材质，同时把场景视角自动切换到该区域。

第三类才是最有价值的：自然语言复盘。业务方经常会问“现在哪个区域的库存压力最大”。以前只能让数据分析师写 SQL 查库，现在直接在 Antigravity 的对话界面输入这句话，AI 解析意图，调用 Blender MCP 的查询工具，把各分区的库存占用情况读回来，再用自然语言总结出 TOP3 并且直接在场景中标出来。

这套流程跑通之后，数字孪生才算真正嵌入了业务流程。我在演示时给业务方看的效果是这样的：真实 WMS 里一张出库单被审核，几秒后 Blender 对应货位的货物数量就变了，同时 Antigravity 对话框自动弹出一条“H1-03 货位库存已低于安全水位，建议补货”的消息。这套闭环链路相比单纯的大屏展示，说服力完全不是一个量级。

5. 进阶扩展：3D 点云感知与自动“拉框”

5.1 为什么还要引入点云数据

前面几章的数据联动有一个前提：业务系统能提供准确的状态数据。但仓储现场大量存在“系统状态和物理状态不一致”的场景，货箱被歪放、托盘被挪位、AGV 作业路径被临时堆物阻挡，这些信息 WMS 里根本没有，传统数字孪生也就感知不到。

解决这个问题最直接的办法是部署深度传感器。结构光相机或 RGB-D 相机能够输出 3D 点云，点云中的每一个点都代表现实表面的一个三维采样点。数字孪生拿到点云之后，经过算法处理，就能实时得到物体在空间中的位置和尺寸变化。这就是热词里常说的“3D 点云拉框”在仓储场景里的真实用途：在点云中给每个物体画出一个 3D 包围盒，用这个包围盒去同步驱动孪生模型。

5.2 点云预处理：从原始点云到干净物体

直接拿原始点云去做标注和拉框，效果会很差。因为仓储现场的点云数据量巨大，一个场景几百万个点都非常正常，而且包含墙面、地面、各种噪点。直接处理既慢又不准。

我实际的预处理流程分四步。

第一步，降采样。用体素滤波把点云分辨率降到 0.05 米级别。这样做能把百万级点云压缩到几十万点，显著降低后续计算压力，而且不影响拉框位置精度。0.05 米对应 5 厘米，对仓储仓储级物体识别来说足够。

第二步，去除地面点。仓储场景地面通常是大面积平面，点云里地面点占了很大比例却没有任何识别价值。用 RANSAC 平面拟合可以找到地面平面，把属于平面的点剔除。值得注意的是，货架脚、货物底部贴地的点不要被误删，所以平面拟合的 RANSAC 阈值要设置合理，比如 0.02 米。

第三步，聚类分割。地面滤除后，剩余点云就是各个独立物体。用欧式聚类算法按点与点之间的欧式距离把物体分离开。离得近的物体如果不满足预设的最小距离阈值，会被聚类成同一个物体，所以参数调整要结合货架的间距。

第四步，拉框标注。对每个聚类的点云，计算它在三个轴向上的最小值和最大值，得到一个轴对齐包围盒 AABB。如果物体存在倾斜，比如货物歪放了，就要用带方向的主成分分析拟合出一个 OBB 方向包围盒，由中心点、三条棱长、偏转角构成。

拉框结果最终输出成结构化 JSON：

{ "object_id": "item_039", "aabb": { "center": [12.4, 3.8, 1.2], "size": [1.2, 0.8, 0.6], "rotation_z": 15.0 } }

这一步处理对算力有一定要求，典型的仓储通道相机点位大约 30 万点降采样后处理耗时在 200 毫秒上下，可以满足秒级更新需求。如果现场没有 GPU 加速条件，纯 CPU 处理也能跑，但帧率会降不少。

5.3 拉框结果如何同步回 Blender 孪生体

得到点云的 3D 拉框结果后，要把它写回 Blender。写回的方式取决于拉框结果对应的物体是否已经存在。

在 Blender MCP 里我实现了一个sync_obb工具，输入是 JSON 拉框数据。处理逻辑分为两路：对于 WMS 已知的固定货架，用坐标距离匹配到现有模型，然后调整现有模型的位置和尺寸；对于新出现的障碍物或临时货物，就在对应坐标创建一个新的半透明包围盒，用颜色表示障碍物类型。

这里有一个精度匹配的问题。点云计算出来的中心坐标和 Blender 场景坐标存在一个刚体变换关系，必须先把点云的坐标转换到 Blender 坐标系下。否则会出现孪生体里“障碍盒悬浮在货架上方半米”的尴尬情况。

每次同步完之后，把这一轮sync_obb生成的所有临时包围盒打上一个统一前缀，比如OBB_TEMP_。下一次更新时先删除所有带此前缀的物体，再重新生成一批新的，避免场景中堆积大量过期的拉框结果。删除前缀物体的操作可以放在 MCP 工具内部完成，不需要每次都用自然语言让 AI 去猜哪个该删哪个该留。

5.4 点云感知 + AI 编排的闭环业务

点云拉框本身只是感知，真正产生价值的是感知数据用于决策。我把点云感知和 Antigravity 编排结合成了两条业务闭环。

第一条是障碍物告警。点云拉框发现 AGV 巷道上有未登记物体，Antigravity 工作流收到事件后，会自动检查该物体的坐标是否位于 AGV 规划路线上。如果是，系统立刻在 Blender 场景中高亮障碍物，并通知调度员，同时建议 AGV 改走备用巷道。

第二条是库存空间复核。剧本上记录着某个货位是空的，但点云拉框结果显示里面有物体占位，说明实体库存与系统库存产生了差异。Antigravity 收到差异事件后，会把对应的货位在孪生体里标记为“待盘点”，并且生成一条盘点工单给现场的仓储作业人员。

这两条闭环做到了以后，数字孪生系统就从“看着像现场”变成了“知道现场发生了什么”。我特别强调可靠性：AI 在点云标注上误检率不可能为零，所以这套感知数据更适合做辅助决策，不建议直接自动控制机械设备。实际的流程中，我让系统先发告警，由人工确认以后才执行后续调度动作。这个“人机协同”的兜底策略，在真实业务环境里远比全自动更稳妥。

6. 常见问题与避坑清单

6.1 Antigravity 接口返回 403 的排查

我在联调阶段被 403 折磨了两天，后台日志里反复出现“Please verify your account to continue using Antigravity”之类的提示，第一反应以为是平台不稳定，后来逐层排查才发现是三个不同层次的问题。

最常见的是 API Key 过期或写错。开发环境和生产环境的密钥不要混用，这是最基础但最容易犯的错。排查方法是在自己电脑上用 curl 直接请求接口，看能否复现 403，同时检查请求头里的 Authorization 字段是否正确。

第二个常见问题是项目角色权限不足。Antigravity 项目的成员可能分配了只读权限，调用写操作接口时就会返回 403。这种情况不会出现在接口文档请求参数排查里，要去项目的成员管理模块查看当前账号的角色权限。

第三个是账号级验证没完成。部分平台要求新账号绑定开发身份并完成验证后，才能持续使用 API 服务。后台的报错内容里通常已经明确提示了这一点。按照引导步骤完成验证即可，这属于正常的平台合规流程，不需要绕路处理。

排查 403 时我习惯一次性把请求方式、URL、请求头、请求体全部打印出来。大多数 403 都是因为请求头上少了项目 ID 或密钥字段，而不是平台真的拒绝了请求。

6.2 Blender MCP 连接时好时坏

MCP 连接不稳定是最影响开发体验的问题，我遇到的典型情况有三种。

第一种是端口被占用。Blender MCP 启动后默认监听 9876 端口，如果之前调试时没有正常关闭插件，残留进程会占住端口，导致新的 server 起不来。解决办法是先查询端口占用，再彻底关掉 Blender 重启插件。

lsof -i:9876

第二种是插件版本和 MCP 协议版本不匹配。Blender 插件更新频率很快，如果 Antigravity 平台的 MCP Client 版本较老，两边协议握手会异常。我的做法是把双方版本固定下来，升级时一次只动一边，出问题容易定位。

第三种是长连接被服务端断开。Antigravity 平台的 MCP 请求如果长时间没有返回，默认超时时间可能很短，Blender 这边一旦执行重操作，比如批量创建几百个物体，请求就被判定超时了。后来我把平台侧的超时设置调到 30 秒以上，又把 Blender MCP 这边的主循环改成异步处理，问题才算彻底缓解。

6.3 坐标漂移和数据不同步

坐标漂移这个现象在运行一段时间后容易出现，尤其是项目经过多次修改和重启之后。我用“三点标定”的参考空物体来校验，如果三个参考点在 Blender 中形成的三角形和现场测量结果对不上，就说明场景整体发生了位移或旋转。

数据不同步的问题基本集中在事件时序上。仓储现场数据推送频率如果很高，可能出现后到达的事件覆盖先到达事件的错误。我的处理策略是为每个货位加一个单调递增的 sequence 序号，旧事件的序号小于新事件的才被接受，否则直接丢弃。这个方法虽然原始，但在仓储场景里足够稳定。

6.4 渲染性能和场景稳定性优化清单

场景卡顿往往是管理问题，不是显卡问题。我给自己定了一张优化清单，每次项目进行到中期都拿出来过一遍。

Blender 渲染模式切换成 Eevee，关闭环境光遮蔽、泛光和屏幕空间反射，这三项是视口性能大头。场景结构上，冻结不需要交互的图层和集合，减少 MCP 工具作用域，也就是让 AI 的操作只限定在指定集合内，避免误触整个场景。批量更新时，把 1000 个货位的更新逻辑合并成一次场景树脏标记，而不是反复刷新。MCP 执行 Python 代码时，全部加上 try/except，避免某一次异常让 Blender 主线程卡死。

我在这里吃过的最大亏是：有一次没有限制 MCP 执行代码的作用域，AI 的一条误操作指令选中了整个场景并执行了删除操作，整个货架场景在 1 秒内被清空，而且没有保存备份。从那以后，我养成了两个习惯：一是在 Blender 里定期保存数字孪生场景的备份文件；二是给 Antigravity 系统提示词加硬约束——“执行任何删除操作之前，必须询问用户确认”。这两条每一条都能在关键时刻救命。

6.5 从单仓演示到生产系统的自然扩展

如果项目想从演示环境走向生产环境，有几个明显的扩展方向。

场景运行时不一定非得一直开着 Blender。Blender 更适合做建模和烘焙，线上展示和交互可以导出 glTF 或 USD 格式，用 Web 渲染引擎加载。Blender MCP 在流程中负责生成和更新这个导出产物。面向 VR/AR 应用时也是一样，把 Blender 作为资产生产管线，运行时输出到 WebXR 场景，视觉沉浸感会更强。多仓联动则引入消息队列作为事件总线，Antigravity 统一编排各地仓库，每个仓一个 Blender MCP Worker，这种架构下扩展新仓只是加一个 worker 节点的问题。

写到最后说一点我的个人体会：这个项目里我最大的教训是“先通数据，再谈画质”。最初两三周我把场景建得特别精致，货架材质、光照、环境都调到满意为止，结果反过来接 WMS 数据时，才发现模型中连货位 ID 属性都没挂，几乎全部返工。后来我彻底换了个顺序，先用灰模加实时库存数据跑通整个数据链路，确认事件结构、坐标体系、更新频率都合理之后，再慢慢替换材质和细节。如果你正在做类似项目，我强烈建议你采用这个顺序。

另外分享一个实用技巧：用 Blender MCP 批量调节 100 个以上货架时，AI 生成的指令很可能跑到一半就出 bug，比如在第 37 个同名物体上操作失败。所以要提前准备好场景快照恢复方案。我通常会在批量操作前，用 Blender 的“整体场景保存”功能存一个版本文件，一旦操作异常，立即恢复重来。这套组合拳打下来，项目推进速度比盲目雕细节要快得多。