企业官网建设流程全解析

最近在做一个智慧仓储可视化项目，核心需求是把仓库的实时库存、设备状态、订单流转全部映射到一副可交互的3D场景里。传统方案是前端工程师用Three.js一点点搭场景、绑数据，然后写死一堆交互逻辑，遇到业务调整就得改代码，非常折腾。后来我换了一条路：让AI Agent直接操刀Blender建模——用Antigravity做任务编排，通过MCP协议把Blender的Python API暴露给智能体。这篇文章把项目落地过程中的方案选型、实操步骤和踩过的坑完整拆一遍，如果你也在做数字孪生相关的东西，尤其是仓储物流领域的可视化，应该能少走不少弯路。

1. 项目全景：Antigravity 和 Blender MCP 到底解决了什么问题

1.1 数字孪生项目最卡壳的环节其实不在建模

很多人一听到"数字孪生"就以为难点在3D建模，实际上真做起来你会发现，建模只是体力活。仓库里几百个货架、几千个货位、几十台AGV，这些模型本身花点时间都能建出来。真正让人头疼的是"模型怎么跟着业务数据动起来"。

传统做法是这样的：业务系统里库存数据发生变更 → 后端推送消息 → 前端写一段JavaScript去改Three.js里某个对象的颜色、位置或显隐。听起来不复杂，但一旦数据量上来、状态维度变多，比如库容、温度、湿度、AGV电量、任务优先级一起变动的时候，那套"事件监听+状态同步"的代码就会被拖进泥潭。而且每次业务方提一个新的可视化维度，前端就得改一遍代码、重新走一遍测试发版流程。

我这次想验证的是另一个思路：让AI Agent成为建模和联动的中枢。Antigravity负责理解指令、拆解任务，Blender MCP负责把Blender的建模能力变成AI能直接调用的工具。这样业务想要什么效果，直接告诉Agent，Agent自己去找模型、调参数、改状态，整个链路的灵活度提升了一个量级。

1.2 Antigravity 在这个项目里的定位

Antigravity不是传统意义上的建模软件，它是一个AI Agent运行环境。你可以把它理解成一个"任务指挥官"：给它一个目标，比如"把一区货架的库存饱和度可视化出来"，它会自动拆解成若干子任务，然后逐个执行。

在仓储数字孪生这个场景里，Antigravity主要承担三件事。第一，理解业务意图，把我们提出的可视化需求翻译成可执行的动作序列。第二，调用MCP工具，通过标准化的协议去操作Blender里的模型。第三，处理异常，比如某个货架ID找不到、库存数据缺失，它有能力判断错误并调整策略。

选Antigravity还有一个很实际的原因：它的Agent执行过程是可见的，每一步做了什么、调用了哪个工具、返回了什么结果，都有日志。这个特性在调试阶段特别有用，你不需要去猜AI到底理解了什么，直接看执行轨迹就能定位问题。

1.3 Blender MCP 把"AI 指挥建模"变成了现实

Blender本身有一个非常完整的Python API，也就是bpy，理论上你可以用脚本控制Blender里的几乎所有操作。但问题是，让一个不熟悉Blender的AI直接写bpy脚本，它很容易写出已经废弃的API、或者忘掉必须先进入正确的模式才能编辑网格，错误率非常高。

Blender MCP在这里起到的作用是"翻译官"。它把Blender的常用操作封装成一个个语义清晰的工具函数，比如"创建长方体""设置材质颜色""移动物体""复制物体"等。AI不需要知道Blender内部API怎么调用，只需要按MCP协议把一个工具名和参数JSON发过来，Blender MCP Server就会去执行具体的bpy操作。

这个设计模式我越想越觉得有价值。它其实是在AI和硬件/软件之间建立了一层"语义接口"，AI不关心你是Blender还是Maya，甚至不关心你是3D软件还是机械臂，只要MCP Server把工具暴露成统一协议，AI就能直接控制。

2. 方案选型：为什么是 MCP 协议，以及为什么选 Blender

2.1 MCP 到底是什么，它解决的最本质问题是什么

MCP的全称是Model Context Protocol，模型上下文协议。它是一个开放标准，定义了大模型应用如何与外部工具、数据源进行标准化交互。本质上，MCP做的是把"AI调用工具的接口"这件事统一了。

以前接入一个外部工具，需要在代码里专门写一套集成逻辑，比如调用某个Python函数、发出某个HTTP请求、解析某个私有格式的数据。每个工具一套玩法，AI被硬编码在特定的工具链上，换一个环境就失效。MCP的思路是建立起一个"万能插座"：工具方按照MCP协议实现一个Server，提供一系列工具；AI侧通过MCP Client连接Server，按协议去发现工具、调用工具、接收结果。工具侧和AI侧彻底解耦。

我在项目里实测下来的感受是，MCP的价值不只是"省了对接时间"，更重要的是它让AI具备了"可扩展的肢体"。你给Blender装一个MCP Server，AI就具备操控Blender的能力；给浏览器装一个MCP Server，AI就能自动化页面操作；给数据库装一个，AI就能查询数据。这种能力是可以叠加的，你是做一个"数字孪生"项目还是"自动化测试"项目，区别只在于你接入了哪些MCP Server。

2.2 Antigravity 相比"让 AI 直接生成 .py 脚本"的优势

有人问，为什么不直接让AI写一个完整的Python脚本，然后在Blender里运行？这个思路我一开始也试过。提示词里把需求写清楚，让AI输出一段代码，我复制到Blender的Scripting工作区运行。这套流程有两个非常致命的问题。

第一，脚本是一次性的，不灵活。业务方今天想看"库存超过80%的货架标红"，明天改成"超过60%就要闪烁提醒"，你每次都得让AI重新生成脚本、重新粘贴、重新运行。Antigravity的Agent模式不一样，它是一个持续运行的智能体，你随时给它下一个新指令，它自己会去调用对应工具完成改动。

第二，脚本出错时排查成本高。AI生成的脚本经常有边界问题，比如遍历物体时默认遍历了全部场景对象，结果把不需要修改的模型也改了。在Antigravity的模式下，每一步都是工具调用的形式，操作有明确的对象作用域，出错时能快速定位是哪一步的操作逻辑不对。

2.3 在数字孪生早期阶段，Blender 是比 Unity/Three.js 更顺手的建模端

做数字孪生的3D展示层，选型上通常有三条路：Blender、Unity、Three.js（或者其他WebGL框架）。说实话每个方案都有它的适用场景，但在项目早期、强数据驱动建模的阶段，Blender的优势最明显。

Blender是免费的，对个人开发者和中小企业非常友好。它的Python API成熟且稳定，几乎能把界面上的所有操作映射到底层接口。更关键的是，Blender MCP生态已经有人在维护，你能找到很多封装好的工具函数直接复用，不用自己从头写。Unity更适合做高交互的实时应用、尤其是需要物理引擎和复杂动画的场合，但它的工程结构重，包体积大，早期验证想法阶段体感很笨重。Three.js是纯Web方案，适合做最终的产品化前端，但它的建模能力很弱，更多是把已有的3D模型加载到页面里展示，而且数据联动逻辑还是得靠手工写代码。

我的判断是：Blender适合做"数据到资产的构建"环节，Three.js适合做"资产到用户"的展示环节。前面提到的Through Antigravity+Blender MCP做的是前者，先把模型资产和业务数据绑定好，后面如果要上线，再把资产导出成Three.js能识别的格式。

3. 环境准备与工具链搭建：从零接入 Antigravity 和 Blender MCP

3.1 Blender 版本选择和 Python 环境确认

我用的Blender版本是4.1，考虑到MCP相关插件和工具库的兼容性，不建议用特别新的4.2或者特别老的3.x版本，4.1是当前比较稳妥的选择。Blender启动后，打开左侧的Scripting工作区，确认Python控制台能够正常执行import bpy，这是后面所有操作的基础。

Blender内置的Python解释器是独立的，不跟你系统里安装的Python共享包。所以当你需要给Blender安装第三方库时，不能用pip直接装，要指定Blender的Python解释器。这一步很多人会踩坑，我一般用如下方式确认：

# 进入 Blender 自带的 Python 环境 /Applications/Blender.app/Contents/Resources/4.1/python/bin/python3.11 --version

Windows系统路径类似，找到Blender安装目录下的python文件夹即可。确认好版本之后，后面安装mcp、websockets等库时都会用到这个解释器。

3.2 搭建 Blender MCP Server 并暴露建模工具

Blender MCP Server的核心作用是把Blender的操作封装成MCP协议里的tools。我用的是社区里比较成熟的blender-mcp项目，它会起一个WebSocket服务，监听来自MCP Client的连接请求。先安装依赖：

# 假设你已经定位到 Blender 的 Python 解释器 blender_python -m pip install mcp websockets

然后克隆项目代码，在Blender的Scripting工作区里运行bpy_mcp_server.py这个脚本。运行后会看到控制台输出类似"Blender MCP Server listening on ws://..."的信息。这时候Blender已经变成了一个等待指令的MCP Server。

接下来需要确认MCP Server暴露了哪些工具给AI调用。以blender-mcp为例，常用的工具包括：

• create_box：创建立方体
• set_material：设置物体材质和颜色
• move_object：按坐标移动物体
• duplicate_object：复制物体
• delete_object：删除物体
• combine_meshes：合并网格
• set_wireframe：切换线框显示模式

每个工具的输入参数都是结构化的JSON格式，Antigravity就是通过这些参数理解你的意图，并完成对Blender的控制。

3.3 在 Antigravity 中配置 MCP 连接

Antigravity侧需要把刚才启动的WebSocket服务地址配置进去。一般在Antigravity的设置里找到MCP相关的配置项，添加一个新的连接，填入服务地址。注意地址格式要完整，包括协议前缀、IP、端口和路径，缺失任何一部分都会导致握手失败。

配置完成后，可以做一个最简单的连通性测试。在Antigravity的对话框里输入"在Blender中创建一个长宽高分别为2、4、1米的长方体，命名为warehouse_base"。如果链路没问题，你会看到Antigravity调用了create_box工具，参数也匹配了长方体的尺寸，Blender视口里随即出现一个对应的几何体。

3.4 首次联通时的关键配置检查清单

我第一次联通的时候折腾了一个多小时，最后发现是端口没有开放。如果用的是远程服务器，需要检查防火墙是否放行了WebSocket端口；如果是本机，要确认Blender进程和Antigravity进程有没有运行在同一局域网段。另外检查一下Antigravity代理和连接服务有没有走不必要的中间节点，MCP的WS握手对网络的干净度是有要求的。

还有一个容易被忽略的点：Antigravity的Node.js环境版本会直接影响MCP协议版本的协商。某些加密算法和帧格式在较老的Node版本下无法正常工作。建议Node版本至少保持在18以上，安装前可以用node -v确认一下。

4. 核心实现：从空场景到完整仓储数字孪生

4.1 先把仓储场景的"数字需求"理清楚

开工之前最重要的一步是把需求讲透。这个仓储数字孪生要展示什么、服务谁、达到什么精细度，这三个问题直接影响后续模型结构的设计。以我自己这个项目为例，核心用户是仓储运营人员，他们要看的是一区货架的库容情况、每台AGV的当前位置和状态、以及最近一小时出入库任务对应的货位变化。

建模之前我列了一张简单的表：

这张表决定了后面MCP工具的参数设计。比如我要让AI给某个货架按照库存占用比例批量设置颜色，就需要工具接收"货架编号"和"占用率"两个参数。

4.2 用 MCP 指令批量生成仓储基础模型

正常情况下，你不可能在Blender里手动放置几百个货架，这会累死。我选择用Antigravity发布一个批量任务，让AI循环调用create_box和move_object两个工具来生成货架阵列。

比如我要求生成一个10排8列的货架区，每排货架有4层，层高0.6米。从交互上来讲，我只需要在Antigravity对话框里用自然语言描述一遍任务，它就会自行拆解成循环调用。第一次执行的时候我特别盯着中间过程，AI确实在按规律的坐标间距生成模型，没有跳排和乱序。这看起来简单，但如果是让AI直接写python脚本，很容易因为循环边界问题多建几个或者漏建几个，且排查起来极费时间。

批量建模的另外一个好处是你随时可以回退。Antigravity的每一步操作都有记录，如果我观察到生成的货架密度太大会遮挡视线，我可以让AI批量删除、重新调整间距。传统脚本方式要么全删重来，要么手抄坐标去定位，操作成本完全不在一个量级。

4.3 库存数据如何绑定到货架模型的视觉状态

模型建完后，最核心的链路是把业务数据映射到模型上。简化一点说：每个货架都对应一个货架编号，我从仓储管理系统里导出一份JSON格式的库存数据，包含货架编号和当前库存值。Antigravity需要做的就是读取这个JSON，比对编号，找到Blender里对应的物体，再调用set_material改变它的材质颜色。

实现这个逻辑的关键点在于编号的对应关系。前面建模时，我给每个货架物体设置的名称就是"rack_row01_col03"，这样JSON里的编号row01_col03就能直接关联。这种命名规范在数字孪生项目里非常重要，它保证了AI在跨系统操作时有清晰的锚点。

实际的MCP指令执行效果是：库存占用率大于80%的货架变成红色，50%到80%变成橙色，低于50%保持深绿色。AI会先统计JSON里有多少货架的占用率超过阈值，然后逐个调用材质更换工具。整个过程在场景规模500个货架以内的情况下执行效率非常高，几乎感觉不到延迟。

4.4 用数据驱动动画表现 AGV 路径和任务流转

静态的仓储模型只能反映一个时刻的状态，数字孪生的价值更体现在"变化"上。我的第二期目标是把AGV的运动轨迹和任务流转也放进场景里。Blender MCP在动效方面的工具相对基础，但是配合数据驱动的方式也能实现。

我先把一批AGV的轨迹点坐标整理成JSON数组，AI根据轨迹点顺序，逐个调用move_object。每一步移动之间加入一定的时间间隔，视觉上就是AGV在库区间穿行。如果要更细腻一些，还可以让AI对这些轨迹点做插值计算，生成平滑的曲线运动路径。

不过要提醒一下，Blender的视图性能是会成为瓶颈的。如果场景里有几千个物体，再加上频繁的动画更新，视口会明显卡顿。我后来把不需要实时显隐的模型全部冻结了修改器并关闭了阴影投射，才算把帧率稳定住。这一点在数字孪生项目里一定要提前规划，不要等建到一半再返工。

5. 踩坑记录：Antigravity 执行终止、MCP 连接失败和 Blender 性能优化

5.1 Antigravity Agent 执行到一半终止怎么办

我在开发过程中遇到最多的一个问题就是"antigravity agent execution terminated due to error"。这个报错看起来吓人，实际上绝大多数情况是Agent在执行某个工具时收到了异常返回，而Agent无法自行恢复，就终止了整条执行链。

排查步骤我总结为三步。第一步，到Antigravity的日志面板里找到对应任务的执行轨迹，看具体是调用哪个工具的时候断的。我遇到过一次是AI在读取JSON文件时，把文件路径写错了，工具返回失败，Agent直接终止。第二步，检查Blender MCP Server的控制台输出，看工具侧有没有打印出具体的Python堆栈信息。很多时候问题出在bpy调用本身，比如参数里传了一个不存在的材质名称。第三步，给MCP工具做"防御性返回"。就拿创建货架来说，如果AI传入了负数尺寸，工具应该返回一个明确的错误信息，而不是让bpy抛出一个底层异常。工具返回的提示越清晰，Agent下一步就越容易做出正确决策。

5.2 MCP 连接失败/401/403 的排查思路

MCP连接的底层走的是WebSocket协议，所以一旦连接失败，网络层面的排查思路和排查WebSocket逐一对应。首先检查地址前缀是不是wss://，如果是http://或者ws://，连接大概率会被拒。然后是token的有效期，很多MCP Server需要带鉴权信息，Antigravity需要在配置连接时填上有效的token，过期后重新换取。

还有一次遇到的是协议版本不兼容。Antigravity的MCP客户端和Blender MCP Server端对协议版本的要求不一致，导致握手中断。解决办法是把双方都升级到最新版本，然后重启Blender侧的Server进程。

5.3 Blender 场景文件越来越大，越来越卡

Blender数字孪生项目做了一段时间后，文件体积会迅速膨胀，场景一复杂就拖慢视口刷新。这个问题很大程度是建模前期不注意清理造成的。比如用MCP工具批量创建模型后，会残留大量材质槽、UV贴图和未使用的数据块，这些对渲染毫无帮助，却白白占着内存。

我后来在每个操作阶段结束后，都会主动调用Blender的清理逻辑。比如创建货架阵列完成后，先用脚本遍历所有创建出来的物体，去掉重复材质引用；再执行bpy.ops.outliner.orphans_purge()清理孤立数据块。Antigravity虽然能驱动建模，但它本身不具备"审美洁癖"，所以"定期打扫"这个动作必须由人在工程层面把控。

5.4 性能优化的具体操作清单

如果你发现场景卡顿，可以按我的优先级逐项检查。第一步关闭阴影投射，仓储场景里绝大多数物体根本不需要投影。第二步调整材质球数量，几百个货架不要每个都分配独立材质，应该只保留几套标准材质轮换使用。第三步减少高模模型，货架这种规则几何体用box就够了，不需要引入圆柱体螺丝和圆弧倒角。第四步关闭视图环境光遮蔽，Blender的视口着色设置里有一堆加重GPU负担的开销，项目早期全部关掉。

这套优化方案执行完之后，我在一个4000多物体粒度的仓储场景里，视口帧率从十几帧恢复到了比较流畅的水平。数据联动和视角旋转都顺滑了很多。

6. 一点个人体会和下一步计划

这个项目做到现在，我最深的一个感受是：AI驱动数字孪生建设的价值不在于它把建模变简单了多少，而在于它把"人与模型的交互方式"彻底改变了。以前你面对一个复杂的3D场景，只能通过鼠标和脚本去慢慢调整参数；现在你可以直接用业务语言跟场景对话，"把这个区域改成暖色调，同时把库存高的货架往前排显示"，AI会把你说的每一步落到具体工具操作上。它像一个熟悉Blender的实习生，执行力强、有问必答、不抱怨加班，只要你把需求描述清楚，它就能交付一个相当可用的结果。

当然它也不是万能的。Blender MCP目前的工具集合还没覆盖到刺客级建模技巧，比如复杂的曲线放样、雕刻、粒子系统这些高级功能都有待开发。对于仓储数字孪生这种以规整几何体为主的场景来说，现有工具已经够用了；如果你要做流体力学模拟或者影视级特效，那还是老老实实自己动手吧。

标题是"（上）"，这期我重点讲的是"Antigravity + Blender MCP的环境搭建和基础场景生成"。下一期我计划深入讲几个进阶方向：一是如何用Blender MCP实现仓储数据从CSV接入到模型状态的自动更新，二是如何把Blender里做好的场景导出成Three.js能加载的glTF格式，再接到前端页面上，三是如何让Antigravity在无人值守模式下定期拉取业务数据去刷新场景状态。这几个方向做下来，基本就是一个能应付实际业务演示的完整数字孪生小系统了。如果对这套组合拳感兴趣，建议你拿一个简单的仓储布局开始试，先跑通一条链路，再逐渐加数据维度和视觉维度。