企业官网建设流程全解析

上一篇我们把 Antigravity 和 Blender MCP 之间的基础链路打通了，AI 已经能通过标准 MCP 协议直接操作 Blender 里的网格、材质、相机，甚至在视口里截图回传给自己看。说句实话，能跑通链路只算热身，真正有意思的是拿这套组合拳去解决一个完整的问题。这篇我拿“3D 智慧仓储数字孪生”当靶子，把建模、数据驱动、动态联动这一条龙弄完。适合已经跑通基础连接、想让项目真正落地的读者，看完可以在 Blender 里直接复现一套会“动”的仓库孪生场景。

这套流程不是我拍脑袋设计出来的，是我实际做了两个仓储数字孪生原型项目之后沉淀下来的方法。一开始也走过弯路，比如让 AI 一次性生成整个园区，结果 Blender 里出现几百个物体，数据乱成一锅粥；后来把任务拆成“建模层、行为层、数据层”逐步迭代，效率才上来。下面这些内容全部来自真实操作，坑也标出来了，照着做能少踩不少雷。

1. 进阶实战的整体思路：为什么用 Antigravity + Blender MCP 做仓储数字孪生

1.1 数字孪生场景的三层结构

数字孪生这个概念听起来高大上，落到仓储场景其实就三层东西。

第一层是几何模型。货架多高、间距多少、AGV 多大、通道留多宽，这是静态的“皮”。第二层是行为逻辑。AGV 怎么走、传送带怎么转、货物怎么上架下架，这是“筋”。第三层是数据驱动。实时库存、订单状态、设备异常，状态一变，模型就得跟着变，这是“血”。三层都齐了，这个孪生体才算真正“活”起来。

我见过很多项目只做了第一层，模型建得漂漂亮亮，但完全不会动，那顶多叫三维效果图，不叫数字孪生。用 Antigravity 编排 Agent，本质上就是在帮你把三层都补齐：几何层用自然语言生成和调整，行为层用坐标、曲线、约束来定义，数据层通过 MCP 工具或 Python 脚本把外部数据灌进场景。动手之前先把这三层拆清楚，后面实操才不会越改越乱。

1.2 MCP 协议在这里扮演什么角色

MCP 是 Model Context Protocol（模型上下文协议）的缩写，在整套架构里就是 Antigravity 和 Blender 之间的通用插头。打个比方，以前的 AI 工具链是每个软件自己搞一套接口，AI 想连五个工具就得写五份私有适配代码，维护成本高不说，换个版本就容易挂。MCP 把“工具怎么暴露”和“客户端怎么调用”统一了：服务端把自己能干的活声明成一个个 tools，客户端按同样的 JSON 格式去调用，参数和返回值都是结构化数据。

Blender MCP 就是跑在 Blender 里的一个 MCP 服务端，它把 Blender 的常用操作——创建物体、改材质、移动旋转缩放、导出模型、视口截图——封装成一个个工具函数。Antigravity 作为 MCP 客户端，拿到工具返回结果之后，再交给大模型判断下一步怎么走。

这套组合比传统“人写 Python 脚本改 Blender”强在哪？强在意图到操作的翻译成本大幅降低。传统方式下，你得先想清楚哪个函数创建货架、每个货架几个层板、层板厚度多少，代码量不小。现在你只要跟 Agent 说“给我排 6 排双深货架，每排 3 层 5 列”，它自己会拆解成循环创建动作，一轮轮调用工具完成。人的角色从“写代码”变成了“提需求和验收结果”。

1.3 这组方案和 Unity、Three.js 比起来强在哪

做数字孪生的人经常纠结选什么工具，我先把这个说透。

这里的关键认知是：Blender 这套组合不是用来替代 Unity 或 Three.js 的，而是上游产能工具。Antigravity 把需求变成模型，Blender 把模型变成资产，后续可以导出给 Three.js 在网页上做正式展示。所以正确的姿势不是纠结“到底选哪个”，而是想清楚“在哪个阶段用哪个工具”：“设计验证阶段”用 Blender + MCP 快速出结果，“正式交付阶段”再导到 Web 或者引擎里打磨。

2. 跑通仓储场景前的工具链准备

2.1 Blender 版本选择与运行环境

这次实战我强烈建议直接用 Blender 4.x，我用的是 4.1 LTS，稳定性没问题。为什么强调版本？因为 Blender MCP 依赖 WebSocket 连接和独立 Python 进程，旧版本的 API 命名和属性系统有不少差异，工具注册方式也变过。你要是还在 3.6 甚至 2.9 上，大概率会遇到一堆“AttributeError: ‘Mesh’ object has no attribute……”之类的报错，排查起来非常耗时间。

另外注意硬件底线。Antigravity 和 Blender 是两个独立进程，一个当大脑、一个当建模引擎，建议内存至少 16G。仓储场景即使只建基础货架、AGV、传送带这些东西，加上材质切换和动画计算，内存占用也会轻松到 2~4G。如果你同时开着浏览器、多个 Agent 任务，16G 是舒适线，8G 会明显卡顿。

2.2 搭建 Blender MCP 服务端

Blender MCP 的常见开源实现是以插件或者独立脚本形式提供的，整个搭建过程分三步。

先在 Blender 里把 MCP 插件的源码路径加到偏好设置里，或者在 Scripting 工作区直接打开服务端脚本。建议用插件模式，因为可以设置成启动时自动加载，省心很多。

然后安装依赖。Blender 自带的 Python 环境和系统 Python 是隔离的，直接 pip 经常装错地方。最稳妥的做法是在 Blender 的偏好设置里找到 Python 解释器路径，然后在系统终端里用这个解释器安装依赖：

pip install websockets requests

websockets负责 MCP 的通信通道，requests用于部分插件扩展功能。装完之后回到 Blender，点击运行服务端脚本，看到类似“MCP server started on ws://127.0.0.1:8000/mcp”的日志，就说明服务端起来了。

默认监听地址是本地回环 127.0.0.1，这个不要随便改成 0.0.0.0。把端口暴露到局域网或公网，等于把 Blender 的操作权限开放给所有人，一旦被扫到，别人可以直接增删你的场景物体，风险极高。如果服务端设置了 token，客户端调用时要在请求头里带 Authorization 字段。这个 token 就像门禁卡，只给信任的客户端，发现泄露要立刻更换。

2.3 Antigravity 侧接入 MCP Server

Antigravity 这边主要是新建代理流程，把 MCP Client 节点加进去。我在实际操作中看到服务端返回的工具集合通常是 create_object、set_material、transform_object、delete_object、viewport_screenshot、export_scene_json 这一组。不同版本的命名会略有差异，但“创建对象、改材质、变换、截图、导出”这五大类基本不变。

连接成功后先别急着干活，发一条最简单的测试指令：“创建一个边长为 1 米的立方体”。确认 Blender 视口里真的出现了一个立方体，链路才算真正通了。我踩过一个坑：直接让 Agent 建整个园区，结果执行到一半报错，排查了半天发现是 MCP 地址末尾少了个/mcp路径，服务根本没连上。这种低级错误在正式动手前用一条测试指令就能规避。

3. 用自然语言在 Blender 里构建仓储场景

3.1 先搭骨架：货架与托盘布局

建仓储场景最忌讳的就是一句“帮我建个仓库”然后撒手不管。AI 再聪明，也没有你脑子里的业务概念。正确的姿势是把空间尺寸和布局约束讲清楚，越具体越好。

我常用的一个指令模板是：“在 X 轴方向排 6 排货架，每排长 12 米、宽 1.2 米、高 3 米，货架之间留 2.5 米通道，每排货架做双深结构，每层高度 0.6 米。”Blender MCP 收到之后会把这些描述转换成循环创建参数。Agent 如果生成的布局太挤，直接说“通道再宽 0.5 米”，它也能听懂并执行修改。

这里有个底层逻辑值得一提。Blender MCP 工具调用本质上还是在调 Blender 的 Python API，只是把参数包装成了 JSON。比如创建一个货架长方体，工具调用结构类似下面这样：

{ "tool": "create_box", "args": { "name": "SHELF_ROW_01", "location": [0, 0, 0], "size": [12, 1.2, 3] } }

size数组在 Blender 里对应的是局部坐标系下的长宽高，单位是米。货架层板不需要建得非常精细，用薄矩形代替就行，毕竟数字孪生要的是实时性和状态联动，不是电影级别的渲染精度。托盘和货物用带颜色的立方体模拟，货物颜色本身就可以用来区分品类或状态。

3.2 补业务细节：AGV、传送带、分拣机械臂

骨架搭完之后，再补仓储场景里的核心设备。AGV 小车的建模指令我推荐这样写：“新建一个长 1.2 米、宽 0.8 米、高 0.5 米的扁长方体，底部加四个半径 0.15 米的圆柱体当轮子，整体命名为 AGV_01，放到坐标 (10, 5, 0)。”

这里有一个特别容易被初次接触 Blender 的人搞混的点：Blender 是 Z 轴向上的三维软件，地面是 X-Y 平面，高度是 Z 值。很多人习惯性把高度放在 Y 坐标上，结果模型横着躺在地面上，还得花时间重新旋转。用小车上路前，先确认一下它的轮子是不是都贴在地面。

传送带用“长条盒体 + 一排小圆柱滚轮”实现，分拣机械臂用“底座圆柱 + 两段臂长方体 + 末端夹爪”搞定。这些基础几何体用 MCP 工具批量创建非常快，但我想强调一个经验：MCP 适合批量生成标准化几何体，如果遇到带倒角、异形、曲面多的复杂结构件，AI 生成的效果会比较糙。这时候别硬扛，自己动手在 Edit Mode 里精修一下，或者从外部模型库导入，效率反而更高。AI 干脏活累活，人做关键判断，这才是这套工作流的最佳打开方式。

3.3 截图反馈与迭代打磨：让 AI 能“看见”自己建的东西

只创建不检查，很容易建出一个没法看的场景。Blender MCP 工具集里有一个杀手锏——视口截图（viewport_screenshot）。它能把当前视角的画面渲染成一帧图像，回传给 Antigravity。大模型看到图之后，就跟你看到视口一样，能判断货架是不是重叠了、通道是不是够宽、AGV 是不是跑到墙里去了。

我在实战中最常用的是这么一套循环：建完一批物体，让 Agent“从顶部视角截一张图”；看到图之后如果发现布局偏左，就让它“把第二排货架整体向右移动 0.8 米”；再截图，再调整。两三轮下来，场景基本能拿得出手。这种人在环（human-in-the-loop）的迭代方式，效率远高于自己手动逐个选中物体、按快捷键、改参数，尤其适合“改颜色、改位置、改重复模型”这种没有技术含量但非常消耗耐心的操作。

4. 从静态模型到动态数字孪生：数据驱动联动

4.1 货位状态实时可视化

模型建好只是开始，数字孪生的灵魂在于“状态驱动”。我做的第一个真实项目里，货位状态数据来自 WMS 系统，每秒钟会产生几十条变更记录。孪生场景里不需要把每条记录都翻译成动画，更合理的做法是周期性拉取状态快照，然后批量更新 3D 物体的外观。

最直接的可视化手段是颜色映射：空闲货位显示绿色、占用货位显示红色、锁定货位显示黄色。在 Blender 里批量更新颜色的核心代码很简单：

import bpy wms_states = [ {"slot": "SLOT_01", "state": "occupied"}, {"slot": "SLOT_02", "state": "empty"}, {"slot": "SLOT_03", "state": "locked"}, ] color_map = { "occupied": (0.85, 0.2, 0.2, 1), "empty": (0.2, 0.85, 0.2, 1), "locked": (0.85, 0.7, 0.1, 1), } for item in wms_states: obj = bpy.data.objects.get(item["slot"]) if obj and obj.active_material: obj.active_material.diffuse_color = color_map[item["state"]]

这段逻辑很简单，但背后有一个支撑整个项目的核心规范：3D 物体命名的唯一性。SLOT_01、AGV_01这种带前缀的命名，本质上就是数据库主键。没有这一条，数据字段和场景物体根本对不上，后面做任何数据驱动都是灾难。

在完整链路里，状态数据不一定来自本地文件，可能是 API 接口、消息队列或者数据库。Antigravity 可以配其他数据类 MCP 工具去读这些数据源，再把结果翻译成批量更新指令发给 Blender。注意时间同步问题：数据端的时间戳和 Blender 动画帧之间要建立对应关系，通常的做法是约定一个“每秒刷新次数”，而不是每一条数据都即时驱动一次模型。

4.2 AGV 路径动画与调度逻辑

AGV 在仓储孪生里是最常见的动态对象。让小车动起来，标准做法是“路径曲线 + Follow Path 约束”。

第一步在 Blender 里新建一条 Bezier 曲线，命名为PATH_AGV_01。第二步把路径上的控制点移动到 AGV 要走的关键坐标，比如从库区 A 到拣选台 B，中间绕开货架区域。第三步选中 AGV 模型，给它添加 Follow Path 约束，目标选PATH_AGV_01。第四步设定动画帧范围，AGV 就会沿着曲线跑起来。

如果想让 AGV 面朝前进方向而不是侧着走，还得额外加一个 Track To 约束，让它始终朝向路径切线方向。这个小细节容易漏掉，不加的话小车会出现“横着漂移”的诡异画面。

Antigravity 在这一步扮演的角色是“调度指令翻译器”。它读取任务计划（比如“从 A 点到 B 点，途经中转点 C”），把业务路径转换成三维坐标点序列，再调用 Blender MCP 创建曲线、绑定约束。路径规划算法本身通常在 WMS 或调度系统里已经实现了，你不会在孪生端重写调度算法，你要做的是把调度结果翻译成 3D 动画指令。

4.3 导出与发布：从 Blender 到前端

仓促孪生场景做完，迟早要给别人看。最常见的发布路径是把 Blender 资产导出，交给前端 Three.js 渲染。

Blender MCP 的导出工具通常能直接输出 JSON 格式的场景数据，包括每个物体的顶点坐标、法线、UV 和世界变换矩阵。有个常见坑是坐标轴方向：Blender 默认 Z 轴向上，glTF 标准规定 Y 轴向上，好在 Blender 导出 glTF 时会自动做轴变换，到了 Three.js 里方向和 Blender 视口里看到的一致。但如果你用自定义 JSON 导出，记得把世界变换矩阵也带出去，前端就不用手动重新算坐标了。

5. 常见问题排查与避坑实录

5.1 Antigravity 报错“agent execution terminated due to error”

这个报错信息特别笼统，属于“Agent 在某个环节执行被中断”的兜底错误。我在实际项目里遇到过大概三种情况。第一种是 MCP 工具返回了非预期结构，大模型解析不了，然后整个流程就终止了；第二种是任务上下文太长，Agent 在多轮操作之后超出上下文窗口；第三种是任务拆分不合理，一步让 Agent 干了几十个物体的活，中间某一步返回异常。

排查思路从日志入手。先看 Antigravity 的执行日志，定位中断发生在“生成任务计划”阶段还是“调用 Blender MCP 工具”阶段。如果是工具返回结构问题，去服务端日志看具体报错。如果是上下文过长，把大任务拆成小步骤，先只建货架，再建 AGV，最后做路径动画，每完成一步再进入下一步。我给一个很实用的经验：所有需要多轮操作的复杂任务，都提前让 Agent 写“分阶段执行计划”，每阶段完成后停下来汇报结果，比让 Agent 一口气跑完的容错率高得多。

5.2 Blender MCP 连接被拒、403 或更新出错

连接类的报错，九成是环境配置问题。我把常见情况整理成一张速查表。

还有一条安全底线必须反复强调：Blender MCP 服务端监听地址保持 127.0.0.1，不要为了“局域网协作”改成 0.0.0.0。改完看似方便，实际是把一个没有任何权限校验的建模服务暴露到网络上，被人扫描到之后可以随意增删你的场景。团队协作的正确做法是各跑各的本地服务，或者加正规的认证网关。

5.3 导出 JSON 后前端数据对不上

这是做 Web 端数字孪生最常见的问题，症状就是“Blender 里明明是正确的，导出到前端就乱套了”。我遇到的典型翻车现场有三种。

第一种是修改器没应用。模型在 Blender 里看着是对的，是因为修改器还没执行，导出时用的是底层网格数据，前端渲染出来就是另一副样子。解决办法是导出前选择所有物体，应用修改器。第二种是物体旋转和缩放没应用。你手动旋转过货架，但物体的 Rotation/Scale 数值没有写入网格本身，导出后再做世界变换就会出现奇怪的偏移。第三种是单位不一致。Blender 默认单位是米，一般前端也是米，但有些自定义渲染器或旧项目用厘米，导出时不做换算，尺寸直接差一百倍。

导出一律走这个标准流程：全选物体，应用全部变换（Ctrl+A），应用修改器，检查命名唯一性，然后再执行导出工具。养成这个习惯之后，导出数据对不上的概率会大幅降低。

最后分享我自己养成的习惯。每次新项目一开始，我会强制所有场景物体遵循“前缀_编号”的命名规范，货架叫 SHELF_01，AGV 叫 AGV_01，路径曲线叫 PATH_AGV_01。名字起得越严谨，后面写数据驱动脚本、导出 JSON、对接前端就越省力。数字孪生项目做到后期，真正卡住进度的往往不是渲染效果，而是这种基础规范没做到位导致的连锁返工。这套 Antigravity + Blender MCP 的流程在快速原型和方案验证阶段是真的好用，但前提是前面的规划和规范做到位，不然 AI 生成得越快，返工起来越酸爽。