企业官网建设流程全解析

做智慧仓储数字孪生项目，最耗时间的从来不是渲染引擎选型，而是“把业务数据变成三维场景”这段路。我之前试过 Unity，导入放样、布光、换材质一套下来，改一次货架布局就重折腾半天；也试过用 Three.js 纯手写，几何体倒是好生成，但库存数据一挂接就写得想摔键盘。后来把 Antigravity 和 Blender MCP 接起来，用自然语言驱动 Blender 搭仓储场景，才发现思路对了，效率能翻好几倍。

这篇文章是系列的上篇，重点解决“链路打通”这件事：为什么选这条路线、环境怎么装、MCP 协议在中间到底干了什么、怎么完成仓库地板到货架阵列的初步搭建，以及我在实际项目里踩过的几个典型报错。适合正在做数字孪生、仓储可视化的朋友参考，看完你可以直接复现一套“AI 说话 → Blender 建模 → 数据挂接”的最小闭环。

1. 为什么选中 Antigravity + Blender MCP 这条技术路线

1.1 先说说数字孪生项目里最容易翻车的三个环节

我接触过不少仓储数字孪生项目，大家技术选型五花八门，但翻车的点高度一致。

第一个是场景建模慢。仓库要几十组货架、几百个托盘位，手工摆模型能摆到怀疑人生。即使用 LOD（多细节层次）简化，光是“复制-对齐-命名”这套动作，重复一百次也会出事故。

第二个是数据绑定乱。数字孪生不只是好看，是要把库存表、设备状态、点位数挂到三维物体上。传统做法是建模工具里建完模型，再用代码按名字去找物体、绑数据，命名稍微不一致，前端就显示错位。

第三个是需求反复改。业务那边今天说通道加宽 20 厘米，明天说货架改成 5 层，一改就要重出一版模型。

这三个痛点指向同一个需求：能不能让一个“听得懂人话”的智能体直接操作三维软件，像带教建模师一样，你描述需求，它动手改场景？

这就是我选择 Antigravity + Blender MCP 这条路线的原因。

1.2 MCP 是什么：它不是某种协议，而是 AI 和软件之间的“接口标准”

先说 MCP。很多朋友看到 MCP 三个字母就以为是某种通信协议，担心是不是要自己实现网络层。其实不用，它的核心定位是：给 AI 大模型提供一套标准化的“工具调用接口”。类比一下，你的电脑上有 USB 口，U 盘、键盘、读卡器都能插上去用，MCP 就是给 AI 和软件之间开了这么个标准插口。Blender 装上一个支持 MCP 的插件后，就等于把“创建物体、修改材质、执行 Python 脚本、导出模型”这些能力封装成了一个个工具，暴露给 AI 调用。

Blender MCP 插件在社区里已经有比较成熟的版本，属于 Blender 插件体系的一部分，通过 Blender 的偏好设置导入即可，启用之后它会自动起一个本地 WebSocket 服务。这个时候，AI 只要能连上这个服务，就能拿到“工具清单”，调用它们来操作 Blender。

Antigravity 在这里扮演的是“任务编排大脑”。它是一个偏重 agent 执行与工作流编排的 AI 智能体平台，你可以在里面新建 agent 项目，配置 MCP server 地址，然后给自然语言指令。Antigravity 负责理解你的话、拆解成步骤、逐个调用 Blender MCP 提供的工具，并汇总结果返回给你。如果走的是浏览器扩展模式，还要在扩展设置里启用 MCP 连接，让 agent 能访问到本地服务。

1.3 为什么不直接用 Blender Python + 让 AI 生成代码？

这是个好问题，也是我踩过坑之后才想明白的。

单纯让 AI 生成 Blender 的 Python 脚本，手动复制到 Blender 里运行，确实也能建模。但问题是：AI 没有反馈闭环。它生成的代码里，物体位置对不对、命名是否冲突、坐标原点有没有漂移，它自己是不知道的。你得每运行一次就切回 3D 视图检查一次，报错了你再把报错贴回去让它改，效率非常低。

MCP 方式最大的优势是“验证与纠错内建在调用流程里”：AI 调用工具创建物体，Blender 执行完返回结构化结果，比如“已创建名为 Floor 的立方体，位置(0,0,0)，尺寸(20,15,0.2)”。AI 看到这个结果，就相当于“亲眼确认”了这一步成功，然后继续下一步。失败也能立刻看到报错并调整。

一句话：AI 写代码是“盲写”，AI 调 MCP 工具是“带传感器操作”。在数字孪生这种需要大量精确操作的场景里，后者靠谱得多。

2. 环境准备：把这套链路从零跑通

2.1 需要安装的组件清单

在实际开始之前，先把环境列清楚，避免装到一半发现版本不对。

这里的核心组合就两个：Blender 开启 MCP 服务，Antigravity 作为 MCP client 去连接它。

2.2 Blender 侧：安装并启动 MCP 插件

Blender 侧安装很简单：下载 MCP 插件的 zip 包，打开 Blender，在菜单栏选Edit→Preferences→Add-ons，点击右上角的下拉按钮选择Install from Disk，选中 zip 包安装，然后在插件列表里勾选启用。

启用之后，插件面板一般会显示本机监听地址，常见的本地端口是 9876 或 8090，具体以你装的插件日志为准。重点关注这几个信息：

• 监听地址形如ws://127.0.0.1:9876，这就是 Blender MCP 的服务端地址
• 插件状态会显示“running”或者面板提示等待连接
• 保持 Blender 窗口开着，不要最小化到系统托盘，某些版本在后台状态会暂停 WebSocket 服务

2.3 Antigravity 侧：添加 MCP Server 并授权工作目录

在 Antigravity 里新建一个 agent 项目，进入工具配置区域，添加一条 MCP server 记录，把地址填成 Blender 插件显示的 WebSocket 地址。填完之后，建议先执行一次“连接测试”或“工具列表拉取”，如果能看到类似create_object、select_object、run_python_code这样的工具名，说明链路已经通了。

这里特别强调工作目录授权。Antigravity 类的 agent 平台通常会让 agent 读文件、写文件、执行命令，你最好给它指定一个专门的仓储项目目录，并配置为可读写。别一上来就给它整个 C 盘或 home 目录的权限，否则 agent 在任务中途万一“理解偏了”，可能把不相关文件搞乱。

2.4 Antigravity 更新出错和登录 403 的排查思路

搜 Antigravity 相关热词的人里，很大一部分是被两个问题卡住的：更新出错，以及登录后出现 403。

更新出错我碰到过一次，现象是启动时提示更新失败，然后 agent 项目配置全部丢失。排查下来，通常是保留的旧配置文件和新增版本字段冲突，属于更新程序没做平滑迁移。处理办法是：先备份自己的 agent 配置，把应用缓存目录清掉（不同平台位置不一样，一般在用户目录下的.cache或Application Support目录里），再重新启动更新。不用重新装系统，也不用重装 Blender。

403 的问题则多半与登录态有关，跟 MCP 链路本身没关系。优先检查系统时间是否准确，很多平台的鉴权逻辑都会校验时间戳，本机时钟偏差超过几分钟就会报 403。其次清理平台浏览器的登录缓存，重新扫码或账密登录。还有人问过“是不是要走反代”，我的建议是这个场景下完全不需要，Antigravity 连接本地 Blender MCP 属于局域内部通信，网络越绕越容易出 403 和超时。

注意：排查 403 时先看日志里的错误码。如果日志明确写的是 token expired 或 clock skew，直接校准时间+重新登录就能解决，不要瞎折腾网络配置。

3. MCP 协议链路拆解：AI 一句话，Blender 怎么动起来的

3.1 链路里到底谁在说话

把链路拆开看，其实就三个参与方：

1. Antigravity agent（MCP client）：理解需求、发起调用
2. Blender MCP 插件（MCP server）：执行具体的三维操作
3. Blender 软件本体：真正干活的渲染器/建模器

它们之间的对话是结构化 JSON。一次完整调用大概长这样：

{ "jsonrpc": "2.0", "method": "tools/call", "params": { "name": "create_object", "arguments": { "type": "CUBE", "name": "Floor", "location": [0, 0, 0], "scale": [20, 15, 0.2] } } }

Blender MCP 收到之后执行创建，返回：

{ "result": { "status": "success", "object": { "name": "Floor", "location": [0, 0, 0], "bounds": [20, 15, 0.2] } } }

这个返回内容相当关键。AI 靠它确认物体确实创建了、坐标正确，再决定下一步动作。如果 Blender 因为命名冲突创建失败，返回里会带 error 信息，AI 就会自己换个名字重试。

3.2 第一个最小实验：让 AI 生成一块仓库地板

链路通了之后，不要急着生成整个仓库，先跑一个最小闭环。我在 Antigravity 里输入的是：

在 Blender 中新建一个场景，删除默认的立方体，创建一个 20m × 15m × 0.2m 的地板块，命名为 WarehouseFloor，材质设为浅灰色。

这句话看似简单，Antigravity 实际拆成了几个动作：新建场景、删除默认物体、创建立方体并缩放尺寸、重命名、添加材质。每一个动作都通过 MCP 调用完成。我在日志里看到，AI 还主动做了一次“查找已存在的同名物体”，发现没有才创建，这说明工具返回的上下文它真的在用。

这个实验验证了三件事：

• MCP 工具列表能正常加载
• 调用工具后返回结果能被 Antigravity 利用
• Blender 侧不会崩溃、不会产生多余物体

3.3 为什么不直接执行一段 Python 脚本？

有人可能会问：Blender MCP 里也有run_python_code这种工具，直接让它跑一段生成脚本，不是一步到位吗？

能做，但不建议作为主要路径。原因是控制粒度和安全边界。你让 AI 直接写脚本执行，相当于把所有能力一次性交给它，它可能写出语法对但逻辑错的代码（比如在某处死循环），你还很难从日志里排查。用细粒度工具（create_object、set_material 这种）时，每一步都是独立的，失败点清晰，AI 可以准确恢复。

实际项目里我的用法是“混合模式”：常规几何体让 AI 用工具逐个创建，涉及批量循环的（比如几十排货架的复制），在数据 JSON 明确的前提下，用run_python_code一次性生成，但要给 AI 设定非常明确的输入和输出约束。这个后面会展开。

4. 仓储数字孪生搭建实战：货架、托盘与业务数据挂接

4.1 先把仓库布局定义成 JSON

这是我最想强调的一步。不要让 AI “凭空想象”仓库长什么样，而是要你用结构化数据把仓库“说”清楚。我一般先用 Python 脚本把业务表格转成布局 JSON，格式类似这样：

{ "warehouse": { "name": "WH-A", "length": 80, "width": 50, "height": 8, "unit": "m" }, "aisles": [ { "direction": "x", "position": 29.5, "width": 2.0 }, { "direction": "x", "position": 50.5, "width": 2.0 } ], "racks": [ { "id": "R03C02", "row": 3, "column": 2, "length": 10, "depth": 1.2, "height": 2.4, "levels": 5, "base_position": [13.0, 8.0, 0.0] } ] }

这一步相当于“把业务语言翻译成几何语言”。AI 拿到 JSON 后，不需要猜货架间距、层高，只需要严格按照数据去生成几何体。

顺带回应一个老被问到的问题：“Blender 如何导出 JSON？”答案是：Blender 本身并不擅长生成业务 JSON，业务 JSON 应该在数据侧完成，Blender 那边负责消费它，再导出带三维信息的 glTF 或场景 JSON。正确的数据流向是：业务数据 → 布局 JSON → Blender 建模 → 带属性模型 → 前端展示。

4.2 让 AI 按数据批量生成货架

布局 JSON 准备好之后，我给 Antigravity 的指令是：

读取项目目录下的 layout.json，按照 racks 列表里的定义，在 Blender 中创建双面货架。 每个货架命名为 rack_<id>，每层隔板用 create_object 创建，层高按 height/levels 计算。 所有货架物体放入名为 Warehouse_Scenes 的集合。

这段指令里最有价值的是“按数据来”这个约束。实测中 AI 会读 JSON、解析字段、计算层高，然后循环创建。如果某一步参数异常（比如某个货架 base_position 缺失），它会停下来说“数据不完整”，而不是硬编一个坐标。这种通过数据约束 AI 行为的方式，比反复叮嘱它“别乱放”要可靠得多。

批量场景里有个工程细节值得注意：Blender 内物体命名要讲究。我们统一用rack_R03C02这种格式，后面挂接库存数据时，前端只需解析物体名就能知道它对应哪个货架，省掉了一遍手动映射。

4.3 数字孪生体：不要追求精致模型，要追求状态可挂接

很多非技术背景的朋友对“数字孪生”有误解，以为要复刻出现实仓库每一颗螺丝钉。其实仓储级别的数字孪生，重点在于“体”和“态”，不在于“形”。货架就是长方体+隔板，托盘就是扁立方体，你要让业务系统能在这个物体上读写库存余量、最近入库时间，这才是关键。

所以建模环节我给的建议是：

• 用简化几何体（Box/Cube）代替高精度模型，渲染压力小，改布局也快
• 给关键物体添加自定义属性。Blender 支持在物体上挂 custom properties，可以直接写入 SKU、容量、当前库存

这个做法很实用。比如你选中一个托盘，在属性面板里就能看到sku、capacity、current_stock这些字段。前端数字孪生网站加载模型后，通过物体名匹配业务数据，就能实现“库存低于阈值时托盘变红”这类视觉效果，完全不用改模型。

4.4 导出带数据的模型

模型建好、属性挂好后，用 Blender 导出 glTF 或带属性的场景文件。glTF 是前端数字孪生展示最常用的格式，Three.js 原生支持。导出时记得勾选Include Custom Properties，否则之前挂的业务属性会丢。

导出这一步也是整个链路质量的“体检报告”。如果模型能顺利导出，说明场景内没有命名冲突、没有非法物体，前端能直接消费；如果导出报错，回头检查物体名还是件小事，要是出现孤立顶点或零尺度物体，那才是真的麻烦。

5. 踩坑实录：这些错误我替你先趟过了

5.1 antigravity agent execution terminated due to error 的三种典型场景

这个报错出现得相当频繁，英文意思是“agent 执行因错误被终止”。我遇到三种典型场景：

第一种是任务过长。让 AI 一次性生成整个仓库的 200 组货架，跑到一半时报错。原因通常是步骤太多，超过了 agent 的单次执行上下文。解决办法很简单：拆分。按“分区”来下指令，A 区货架一批，B 区货架一批，每批之间让 agent 主动汇报结果。

第二种是某个工具调用返回了致命错误。如果被调用的工具抛异常，比如试图在不存在的集合里创建物体，agent 会终止整个任务。排查方法是去看 agent 日志中最后一次工具调用的返回内容，多半是“参数校验失败”或“对象不存在”。

第三种是权限问题。agent 尝试写文件时没有目录写权限，被系统拦截后终止。给 agent 配置工作目录时，一定检查当前操作系统账号对目录是否有写权限。

注意：遇到 terminated due to error 时，第一时间不是重跑，而是定位最后一步。这个错误本身就是“链条断裂前最后一次成功动作之后”的最有力线索。

5.2 Blender MCP 连接不稳定的排查清单

连接不稳定是 Blender MCP 常见问题，我从自己项目里总结了一张排查清单：

特别提一句“本地回环通信”。不少同事的程序在 127.0.0.1 上通信，却被安全软件拦截，导致 AI 一直报超时。凡是本地 MCP 服务连不上，先想到这一步。

5.3 AI 乱建模的防御手段

AI 有时会“过度发挥”。比如你让它创建 5 组货架，它顺手把地板也重铺了一遍；或者你让它改第 3 排货架的层高，它把整个场景重新生成了。这种“乱建模”不是 Bug，而是约束缺失。

我的防御手段有三个，效果都很直接：

• 在指令里加“禁区清单”：比如“本次任务不允许删除任何已存在物体”“不允许修改 warehouse_floor 的材质”
• 在 Antigravity 的项目说明文件里写清楚命名规范和集合结构，让 agent 每次开工前先读取
• 定期导出 glb 作为检查点，一旦 AI 搞乱场景，可以直接从最近的检查点恢复，而不是从头重建

5.4 别给 AI 太高的自由度

这是个人经验里最重要的一条。Antigravity 这类平台能力越强，越要给它明确的边界。自由度太高，它“探索”到 Blender 的奇怪角落（比如连续多次修改渲染引擎设置），你的场景文件就会变得不可控。

我的做法是：把允许 AI 使用的工具列表缩小到建模型相关的十几个函数，其余的通通不暴露。这样 AI 不是能力不够，而是被“关在正确的房间里做事”。数字孪生项目要的是稳定可控，这个原则贯穿始终。

6. 现阶段成果与下一步规划

6.1 当前这套链路跑通后是什么状态

写这篇文章时，我的项目已经处于这样一个状态：给 Antigravity 一句“按照 layout.json 生成仓库 A 区场景”，它会在十几分钟内完成地板、墙体、货架、托盘位的基础建模，并把 SKU 属性挂到对应物体上。生成的 glTF 文件能直接被前端加载，点击货架能看到实时属性。

相比以前手工建模+手写代码绑数据的方式，整个流程的迭代速度快了很多。业务改一次货架布局，我只需要改 JSON、重新生成，不用再守着 Blender 手动挪模型。Antigravity 和 Blender MCP 的组合，确实把“从数据到三维场景”的搬运成本打下来了。

6.2 下篇会做的事

这个系列的下篇，我计划往两个方向深入。

第一个方向是把场景做“活”：引入 3D 点云数据和拉框标注功能，让真实仓库的点云扫描结果和数字孪生场景对齐；同时在前端用 Three.js 搭建可交互的数字孪生展示页，实现货物定位、库存预警这些业务层功能。

第二个方向是把流程做成团队可用：把常用指令沉淀成提示词模板，这样同事不需要理解 MCP 细节，只要会描述需求就能驱动整个建模链路。等于是把“会建模”这件事从个人能力变成团队的基础设施。

6.3 最后分享一点个人体会

做完这个项目，我对 MCP 的判断是：它不神奇，但非常实用。它解决的是“AI 怎么在真实软件里稳定干活”的问题。相比让 AI 生成脚本再人工执行，MCP 的颗粒度控制、结果反馈和错误恢复能力，更适合数字孪生这种需要大量精确操作的场景。

如果你也在做类似的仓储或园区数字孪生项目，我建议先从最小闭环开始：装好 Blender MCP，用 Antigravity 生成一块地板、一个货架，把链路跑通，再逐渐加码。别一开始就想生成整个仓库，链路没稳之前，规模越大，定位 Bug 越痛苦。

最后补一条实用技巧：在 Antigravity 项目里建一个REMEMBER.md文件，把项目规范、命名规则、禁区清单写进去，任务开始前让 agent 先读一遍，能少踩一半的坑。这是我在多次“它怎么又乱来了”之后总结出的最有效约束方式。