一次请求究竟经过哪里

四段跳转，全部在你的机器上

助手从不直接与 Revit 对话。中间隔着两个进程，而它们都在你的机器上。

1. 你正在使用的助手

   通过 MCP 发出请求。它并不了解 Revit API，只知道 FLOW 允许它看到的那份工具清单。

2. AI Connection

   接收请求，先对照允许的工具面进行核对，然后才转发。工具清单正是在这里收窄的。

3. 后台运行时

   负责排队作业并保存会话状态。它之所以存在，是因为 Revit 只在单一线程上接受指令，而助手随时都可能提问。

4. Revit 内的插件

   在 Revit 进程内运行，并在合法线程上调用 Revit API。这里只有它会真正触碰模型。

模型留在你的机器上。FLOW 只发送任务所需的上下文。

先预览，再批准，然后才执行

在你同意之前，FLOW 不会改动模型。三个环节，每一个都以前一个为前提。

1. 预览

   工具以空跑方式运行，报告它将会改动什么——多少个图元、哪些参数、哪些取值——但不触碰模型。

2. 批准

   你阅读预览结果并予以放行。没有这一步，就没有下一步。

3. 执行

   改动在一个具名的 Revit 事务中提交，因此撤销会一次退回一步，而不是几百步。

这描述的是 FLOW 与你之间的协作方式，并不是对同一台机器上其他软件所作的承诺。

助手够不到整个工具库

默认情况下，MCP 面是经过筛选的，并非全部 413 个工具。读取模型的范围很宽，写入模型的范围则很窄。

写入仅允许出现在 13 个名称前缀之下，外加 6 个被逐一指名的工具。清单之外的一切，对助手而言并不存在。

另有四个工具被直接拒绝，即便它们的名称符合某个被允许的前缀：

• document.close_non_active
• element.delete_safe
• project.purge_safe
• view.delete_filter_safe

该清单随产品以配置文件的形式一并交付，而不是一项需要你自行开启的设置。

413 个工具，分属 68 个分组

这是运行时真正注册成功的工具数量，而不是源码中声明的名称数量。两个数字并不相同，我们印出的是较小的那个。

八个名称，来自八个不同的分组：

• query.parameter_filter
• spatial.clash_detect
• audit.naming_convention
• sheet.dependencies
• annotation.inspect_tag
• level.list
• room.list
• schedule.compare

一旦印出的数字与真实工具库出现偏差，或上面任何一个名称不再注册，本页会让自身的构建失败。

没有读回，就不算完成

改动提交之后，FLOW 会把每一个被改动的图元从模型中重新读出来。

你拿到的是它在模型中读到的结果，而不是工具原本打算做的事。空跑不会读回任何内容，因为还什么都没有发生。

当清单长到无法完整返回时，结果会明确说明它已被截断。一份无法承认自己不完整的清单，比没有清单更糟。

运行环境

这份清单直接取自安装程序。它只会为下列 Revit 版本部署代理。

• Windows 10 或 11
• Revit 2024、2025 或 2026
• 在运行 Flow 和 Revit 的同一台 Windows 电脑上，有一个能启动本机 MCP 服务器的 AI 应用

来自真实 Revit 的截图

尚未提供。我们还没有从真实的 Revit 会话中采集到这组截图，也不会用示意图来填补这个位置。等到有了真实截图，它们会出现在这里。