MCP 能不能干掉你的 Revit 插件？先把这套技术栈讲透

最近圈子里被问得最多的一句话："你们做 Revit 插件开发的，大模型起来了，是不是要失业了？"

每次听到这种话我都想笑。不是笑他们天真，是笑这帮人把 AI 想得太玄学了——仿佛模型一响，Ribbon 上的按钮就能自己消失。

今天先把这套东西用一句话讲透，再回答一个更实际的问题：用 MCP 驱动 Revit 建模，到底能不能把插件替了？

一、这台车是怎么拼的

拿汽车打比方，AI 这套技术栈一下子就清楚了：

1. 大模型（LLM）= 发动机。 提供原始动力——算力、推理、生成。光有它，车不会动。
2. Agent = 车架 / 底盘。 承载并连接所有部件，决定往哪走、何时调用什么、怎么协调。
3. Skill = 变速箱 + 专用套件。 把发动机的"蛮力"转成具体的、专业的、可复用的工作流——挂运动挡变赛道取向，挂雪地挡变安全取向，换套件就能干不同的活。
4. MCP = 标准化接口 / 通用耦合器。 重点来了：它本身不提供动力，但定义了"任何合规设备都能插上来"的统一规范，好比全行业统一了充电口。

顺手补全后半截：Tool（工具调用）= 车轮 / 机械臂，真正接触外界执行原子动作；Memory（记忆）= 行车记录仪 + 保养手册，跨会话留经验。

一句话收口：引擎给力，车架载物，Skill 是专业能力模块，MCP 是让模块和外设能统一热插拔的接口标准。 注意，这里没有一句话说"MCP 能替代谁"。

二、MCP 驱动 Revit，能替代插件吗？

直接给结论：不能。 MCP 改变的是"谁触发、怎么编排"，插件变成 MCP 的宿主 / 桥接层，而不是被删掉。

为什么？因为 Revit API 有三条外部进程跨不过去的硬边界：

1. 必须进程内执行。 所有 Document、Transaction、元素创建 API 只能在 Revit.exe 的地址空间里调。一个独立的 MCP Server（Node/Python 进程）没法直接 new Wall()。要在进程外驱动，必须有个进程内组件去"代执行"——这个组件就是插件本身。
2. 必须在 API 上下文里。 写操作要包在 Transaction 里，且大多得在 ExternalCommand / Idling / ExternalEvent 回调中跑，不能随便甩在任意线程上。

所以真相很朴素：MCP 把"人按按钮"换成"Agent 发指令"，但转动 Revit 的那双手，还是插件。 那些喊"插件要没了"的人，大概率是没真正写过一行 Transaction。

三、那 MCP 到底香在哪？

不是替代，是新增一条交互通道。三个场景是真有用，不是 PPT 上的概念：

1. 自然语言建模。 "在 3 轴剪力墙开 1.2m 门洞" → Agent 解析意图 → 调 create_opening(wall_id, 1.2)。这正是 AI+Revit 的核心价值，按钮做不到这么顺。
2. 跨系统编排。 读 MongoDB 族库 → 选族 → Revit 里批量放置 → 回填参数，多步链路 Agent 一口气串完，纯按钮插件很难做。
3. Ribbon 不爆炸。 200 个功能不用做 200 个按钮，暴露成 200 个 tool schema，让 LLM 自己判断调哪个。

但别上头。对施工交付物而言，按钮是确定的，Agent 是概率的——LLM 会编错参数、编错元素 id。BIM 模型出错会直接传导到算量和施工，所以生产环境必须保留"人工在环 + 事务回滚 + 参数校验"。这行省不掉，省了就是拿交付物开玩笑。

四、想落地？先给你一段能跑的骨架

真要做，第一步别碰写操作，先在插件里宿主一个 MCP Server，暴露只读工具试水。核心是把 MCP 调用投回 Revit 主线程——这是整件事的命门：

// IMCPBridge.cs — 在插件内宿主 MCP Server 的桥接骨架（Revit 2020 / C#）
publicinterfaceIMCPTool
{
string Name { get; }
// 在 API 上下文里执行，返回 JSON 结果
stringExecute(UIApplication app, JObject args);
}

// 用 ExternalEvent 把 MCP 调用投回主线程
publicclassMcpExternalEventHandler : IExternalEventHandler
{
privatereadonly Queue<(IMCPTool, JObject, TaskCompletionSource<string>)> _queue
        = new Queue<(IMCPTool, JObject, TaskCompletionSource<string>)>();
privatereadonlyobject _lock = newobject();
private ExternalEvent _ev;

publicvoidStart()
    {
        _ev = ExternalEvent.Create(this);
    }

public Task<string> InvokeAsync(IMCPTool tool, JObject args)
    {
var tcs = new TaskCompletionSource<string>();
lock (_lock) _queue.Enqueue((tool, args, tcs));
        _ev.Raise(); // 投回 Revit 主线程
return tcs.Task;
    }

publicvoidExecute(UIApplication app)
    {
while (true)
        {
            (IMCPTool tool, JObject args, TaskCompletionSource<string> tcs) job;
lock (_lock)
            {
if (_queue.Count == 0) break;
                job = _queue.Dequeue();
            }
try { job.tcs.SetResult(job.tool.Execute(app, job.args)); }
catch (Exception ex) { job.tcs.SetException(ex); }
        }
    }
}

// 只读工具示例：列出当前文档所有墙类型及数量
publicclassListWallTypesTool : IMCPTool
{
publicstring Name => "list_wall_types";
publicstringExecute(UIApplication app, JObject args)
    {
var doc = app.ActiveUIDocument.Document;
var result = new JObject();
// 只读操作无需 Transaction，收集器直接在 API 上下文运行
var groups = new FilteredElementCollector(doc)
            .OfClass(typeof(Wall))
            .Cast<Wall>()
            .GroupBy(w => w.WallType.Name);
foreach (var g in groups)
            result[g.Key] = g.Count();
return result.ToString();
    }
}

读操作先跑通，写操作（放置族、改参数）再加 Transaction 包裹 + 参数 Schema 校验 + Undo 事务组，MCP 通道一样要过厂家授权。传统 Ribbon 路径保留给老用户和批量生产，MCP 作为"智能模式"并存，谁也别革掉谁。

五、读者各自怎么看

• 设计院： 别慌，插件还在。AI 是帮你少点按钮、用嘴建模，不是让你丢掉现有工具链。
• 施工单位： 模型错一点，施工错一片。AI 写模型必须人工在环，交付物不是实验田。

总结

大模型是发动机，Agent 是车架，Skill 是变速箱，MCP 是标准化接口。用 MCP 驱动 Revit，是把优易 BIM 助手从"工具栏"升级成"自然语言控制面"的合适技术——但它架在插件之上，不是绕开插件。先读后写、人工在环，可行性才能变成产品力。那些喊"插件要没了"的，先让他跑通一个 Transaction 再来聊。

优易科技 | 优易BIM助手 欢迎转发