host-local 配置的真实数据流向

第一次看到 host-local 这个词，我下意识以为它是“数据不出本机”的意思。毕竟名字就摆在那，local 嘛，本地嘛。结果认真梳理一遍 0 的配置逻辑后，我才发现自己想得太简单了——这个设定管的是“在哪跑”，不是“发给谁”，两件事完全不是一回事。

我拿一个具体场景来捋。假设你在隔离仓库里用 CLI 起了一次代码审计，配置里选了 host-local。整个执行链条是这样的：工作流引擎在你的机器上启动，读取工作区里的文件，调用工具、产生中间输出，写运行记录，最后生成报告。到这里为止，听起来全都在本机，很安心。

但关键在于，引擎本身不带推理能力。它需要显式配置一个模型提供方——OpenAI、Anthropic、DeepSeek 这些，资料里列了约 14 家。每一次它需要模型做判断，就会把上下文发到那个提供方：代码片段、文件路径、工具输出，都可能跟着请求一起出去。引擎在本机跑，推理在别处完成，这是两件并行的事实，host-local 只保证前者。

所以真正的数据流向是这样的：工作区文件 → 本机引擎 → 模型请求 → 远端提供方 → 响应回到本机 → 分诊 → 独立会话验证（又是一轮请求）→ 报告落盘。报告里可能包含代码片段和模型响应，它们留在本机，但源头已经出过门了。

搞清楚这一点之后，配置时该问的问题就变了。不是“我开了 host-local 所以安全吗”，而是“这类代码允许送到哪一家的哪个区域端点”。如果合规上完全不能外发，那只有一条路：接入本机或自建的模型服务，把最后那跳也收回来。

我现在的习惯是，动手前先把工作区划小。一个仓库一个工作区，别把不相关的项目塞在一起。然后按数据必经的三段去核对——哪些文件会被读、哪家模型会收到什么、报告和运行记录最后存在哪、谁来清。host-local 只是第一段的答案，后面两段得自己补上。