工作原理

一次请求究竟经过哪里

没有任何云端替你建模。FLOW 经由托管端点和你机器上的连接器工作，调用方要求时可以先把改动空跑预览，改完后把读回的结果告诉你。

从指令到模型的四段跳转

助手从不直接与 Revit 对话。中间隔着三个环节——托管端点、账户 hub、Revit 内的连接器——只有最后一个运行在你的机器上。

你正在使用的助手
通过 MCP 向 FLOW 的托管端点发出请求。它并不了解 Revit API，只知道 FLOW 允许它看到的那份工具清单。
托管端点
765tflow.com/mcp 对调用进行认证，并对照已声明的工具面进行核对。助手看到的工具清单正是由这里决定的。
账户 hub
把核对过的调用以签名命令的形式，路由到你账户的机器所打开的连接器。
Revit 内的连接器
通过自己建立的向外连接接收签名命令——你的机器上没有任何端口在监听。它验证命令并在合法线程上调用 Revit API；这里只有它会真正触碰模型。

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

由你连接的助手决定执行什么——没有任何环节等待人工点击。每次写入都在一个具名事务中提交并随后读回；调用方要求预览时，工具会先空跑报告将要改动什么。

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

MCP 只有一个工具面：运行时真正注册的 464 个工具。已登录的账户看到的是它的全部——读取和写入共用同一份清单。

该表面上的每个工具都由各自的注册信息加入允许名单。没有声明的工具对助手而言并不存在——没有拒绝名单，只有允许名单。

凡接受可执行内容的工具在此表面一律被拒绝，无论其注册信息如何声明。

该清单随目录一起从托管侧下发——不是你机器上的配置文件，也不是需要你自行开启的设置。

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

该数字会与真实工具库自动核对。

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

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

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

FLOW 开始工作前，机器上需要具备的条件。