Vibe新知 | BIM 软件接上 MCP,AI 能做些什么?

你好，吃饱了没？

上篇聊开放 CDE 时，我们提到一个设想：把平台的文档查询、版本核对、问题提交等能力封装成 MCP 工具，让个人智能体在授权范围内接入项目工作。

从平台再往日常使用的软件看，Revit、Rhino，以及我们已经在用的二开插件，能不能也通过 MCP 让 AI 用起来？

中秋的时候，和大家分享了 AI 在 Revit 里搭建的月饼舞台。

有小伙伴私信我，问我究竟是怎么通过 AI 和 MCP 实现的？今天就把这两个话题接起来。

先看看 MCP 是什么，官方和社区已经提供了哪些选择，它能用在哪些地方，再聊聊我们做过的小实验，以及值得继续探索的设想。

MCP 给 AI 增加了一条使用外部工具的通道。

MCP，全称 Model Context Protocol，通常译为“模型上下文协议”。这里的“模型”指 AI 模型。

可以把它理解为一套通用的工具调用约定：工具一侧说明自己能做什么、需要什么输入；AI 一侧发现这些工具，根据任务发起调用，再读取结果。能够围绕任务调用工具、继续处理结果的 AI 助手，通常会被称为 Agent 也就是智能体。^[1]

放到 BIM 场景里，假设一个 MCP 工具能读取构件参数，我们就可以提出：

找出二层所有门，列出没有填写防火等级的构件。

AI 根据请求调用工具，从模型中取得数据，再整理答案。若工具还开放了写入能力，就有机会进一步修改参数或创建构件。

这里顺带认识一下 API。

API 是“应用程序编程接口”。我们通过按钮和窗口使用软件，程序则可以通过 API 调用软件开放的功能。比如，提供构件和参数的标识，读取对应参数值。它可以是本机程序里的函数，不一定是一个网络网址。

这里的 API 还可以分层。以基于 Revit 原生 API 的二次开发为例：开发者调用软件已有的功能，加入自己的代码、算法和项目规则，再把多项操作组合、封装成新的能力。我们日常使用的二开插件，很多就是这样做出来的。

“二开能力 API 化”，就是把已经拓展好的整套算法或业务功能，再通过自己定义的 API 开放给其他程序调用。 比如，原生 API 提供读取构件、读取参数等操作；二开代码负责筛选构件、按公司规则检查编码、汇总冲突；自定义 API 则可以把这一整套工作作为一次“检查构件编码”的调用，对外接收检查范围并返回报告。

所以，“API 里面还有 API”，准确地说是上层 API 背后的代码，会继续调用下层 API。一次自定义 API 调用，内部可能执行多次原生 API 调用，中间还穿插开发者编写的计算和判断。对调用者来说是一个完整功能，对开发者来说则是一组已经组织好的步骤。

如果再接上 MCP，一条可能的调用链就是：

Agent → MCP 工具 → 插件自定义 API → 二开算法与业务逻辑 → 按需调用软件原生 API，最后返回处理结果。

这样，Agent 就能使用团队已经封装好的专业能力，无须每次从读取参数等基础操作重新组织整套流程。已有插件如果只有按钮入口，还需要把背后的业务逻辑整理成可独立调用的接口；给按钮换个名字，并不等于完成了 API 化。

API 提供程序调用能力的接口，MCP 提供让 Agent 发现和调用工具的统一约定。 软件已有 API，仍需要相应的工具封装；而一个 MCP 工具，也可能组合多项操作来完成任务。

因此，接上 MCP 后具体能做什么，要看接入项目开放了哪些工具。它可能只会读模型，也可能支持修改、运行脚本或导出文件。

Agent 通过 MCP 调用软件开放的工具。

这里还要分清：MCP 和 Computer Use，各自解决什么问题？

看到 GPT-6 Astra 的 Computer Use 能力，可能会想到：AI 已经能操作软件了，为什么还需要 MCP？GPT-6 Astra 是模型；Computer Use 是通过界面使用软件的方式；MCP 则是接入外部工具的协议。它们可以配合使用。^[2]

Computer Use 可以理解为让 AI 看界面、点按钮、输入内容，再查看执行后的画面，决定下一步。它不要求目标软件先把每项功能开放为 API，因此能覆盖一些只有界面入口的操作。实际能操作哪些应用，还取决于运行环境提供的权限和控制工具。^[3]

本文重点讨论的 MCP 用法，是把软件或插件已有的 API 能力封装成工具。Agent 提交明确的参数，程序执行，再返回结果。例如批量读取门的防火等级，可以通过接口直接取得数据，不必逐个打开属性窗口。MCP 为工具定义输入结构，也支持结构化返回结果。^[1]

放到日常任务里，我会这样判断：

上面是基于两种执行方式的工程判断，并非本文做过的性能对照测试。MCP 的稳定性来自背后经过验证的程序能力，不是协议自动保证结果正确。 Agent 仍可能选错工具或填错参数；Computer Use 也不是每次必然不同，只是执行过程更容易受到界面状态影响。

还要补一句：MCP 工具背后也可以封装界面自动化。因此，选择时真正要看的是“这个功能最终靠 API 执行，还是靠界面操作”。已有可靠接口的重复工作，优先走 API 工具；只有 UI 入口的环节，再考虑 Computer Use。一个任务也可以把两种方式结合起来。

有哪些现成选择？先分清“谁提供”和“源码是否开放”。

软件厂商已经开始提供自己的 MCP，社区也在开发连接不同软件的实现。但“官方”和“开源”是两个维度：官方项目也可以开源，社区项目也未必提供明确的开源授权。

闭源产品或服务通常需要通过厂商提供的入口使用和更新；开源实现则允许在相应许可证条件下查看、修改和复用代码。MCP 连接器开源，也不代表它连接的 Revit 等商业软件可以免费使用。

下面选一些和 BIM、三维设计相关的入口。对于本次只查到官方功能文档、没有核实到公开源码的项目，明确标为“未核实公开源码”，不直接断言它一定闭源。

资料核对日期：2026 年 10 月 2 日。以上依据官网和仓库说明，未对全部项目做安装实测。Revit 官方目录页与详细页存在差异，此处采用详细页口径，实际使用需核对可获取的组件。

选择时，除了看名字，还要看软件版本、当前工具清单和项目维护情况。比如，旧的 revit-mcp 仓库^[11]已经归档，并指向上表的新仓库；Blender 的常见社区项目也已改名为 mcp-for-blender。旧教程里的入口未必还是现在的推荐入口。

这些工具能用在哪些地方？可以先从三类工作理解。

第一类是查询与整理。让 AI 读取模型里已有的信息，例如构件数量、参数值、类型和空间结构，再按我们的要求筛选、汇总。Revit 社区实现和 IfcMCP 都提供了相关查询能力，具体范围以各自工具为准。^[7][6]

第二类是修改与建模。通过已开放的工具更新参数、创建构件，或执行脚本组织更复杂的操作。RhinoAI、Revit 社区项目和 Bonsai MCP 的实现各有侧重，不能只凭“支持 MCP”就认为它们具备相同的建模能力。^[5][9]

第三类是围绕模型继续工作。例如获取视图、生成报告或处理交付文件。Revit 官方文档列出了模型查询、汇报和视图导出等场景；具体可以串到哪一步，仍取决于选用的工具。^[4]

使用时也要留意操作对象：连接正在运行的 Revit，与直接处理一个 IFC 文件，是两种不同的工作范围。改了 IFC，不会自动更新回原来的 Revit 工程。能够创建三维形状，也不等于已经创建了具有完整 BIM 语义的建筑构件。

对于 BIMer，这带来的一个变化是：我们有机会直接描述要查询和处理的对象，让 Agent 帮忙组织工具调用。实际效果如何，还需要放到具体软件和任务里检验。

中秋舞台，就是我们做过的一次实验。

最初的想法，是在 Revit 里做一个立体月饼，加上“中秋快乐”。后来经过多轮调整，场景里有了凉亭、桌上的月饼、背景中的月亮和嫦娥，以及背对观众、一起望月的两只猫。

我们专门开发了这项场景生成能力，再通过 MCP 交给 Codex 调用。Agent 可以传入参数，读取生成进度和结果截图。我根据实际画面继续反馈：遮挡是否合适、人物和月亮会不会太挤、猫的轮廓是否清楚，再继续修改和验证。

中秋舞台的 Revit 场景导出：调用专门开发的能力生成，再结合截图反馈逐轮调整。

这次实验验证了 Agent 可以调用已开发的场景能力，并结合截图反馈继续迭代。 它还不能说明任意建模需求都能凭一句话自动完成；当时调整部分能力，仍需要修改代码、编译和重新部署。

后续在「BIM现场」，会结合这个项目谈实际用到的 MCP 架构、二开能力 API 化，以及调用 Revit 原生 API 的不同用法。这里先保留这次实验带来的认识：工具能做什么、模型实际变成什么，都可以成为下一轮讨论和调整的依据。

沿着这个实验，还可以做一个设想：让 Agent 用上团队已有的二开插件。

很多团队已经有批量出图、构件编码、参数检查等工具，里面积累了自己的项目规则。沿用前面说的分层关系，把这些拓展好的整体能力开放为自定义 API，再封装成 MCP 工具，Agent 就有机会继续使用它们。

已有插件开放调用能力后，Agent 就有机会使用团队积累的专业工具。

比如，我们希望以后可以这样提出任务：

检查本次交付图纸，按公司的命名规则生成出图计划，列出冲突，再汇总实际输出结果。

这里设想的是 Agent 组织任务，已有插件执行相应的专业功能。人工使用插件的方式也可以继续保留。

再往前想，如果检查工具、处理工具和出图工具之间能够传递明确的结果，Agent 就有机会把原本分散的几段工作衔接起来。但是否真的能完成，取决于这些功能有没有开放、数据能否接续，以及执行结果是否可靠。

对我来说，MCP 值得关注的一点，是它让软件和插件中已有的能力，多了一种被 AI 使用的可能。

我是托马斯，一个做 BIM 的，也在和 AI 一起学着把想法做出来。

关注 VibeBIMer，一起在 AI、Vibe Coding 与 BIM 数字化等相关领域中不断探索。🍜 ✨