Integration boundaries

This page has not been translated yet. It is shown in Chinese.

这一篇的收获

能判断某项操作是否经过 wanctl，以及“整个宿主切换到远端”还需要谁参与。

连接成功以后，先问路径

MCP 让宿主发现工具、提交参数并接收结果。它建立的是工具调用通道。wanctl 可以在这条通道里提供文件读写、命令执行和工作区管理。原始资料：MCP 工具

但宿主可能同时拥有自己的本地文件工具、浏览器和终端。只有真正走到 wanctl 的调用，才受 wanctl 的工作区绑定影响。

wanctl 工具

读取、编辑、执行等请求携带工作区引用，交给目标设备处理。

宿主的其他工具

仍按宿主自己的实现选择地点。wanctl 无法拦截一个没有经过它的本地文件调用。

先确认调用经过哪个入口，才能判断它工作的地点。

v0.12.1 已提供前两种。第三种需要具体宿主的适配，不能仅靠安装 MCP 自动获得。专属模式的前提是“一段对话独占该 MCP 进程”；共享 HTTP 服务不能把所有聊天当作一个对话。实现与用法

VS Code 把界面相关扩展和工作区相关扩展分开安排：后者可以靠近远端项目运行。值得借鉴的是“界面留在眼前，工作能力靠近文件和运行环境”的分工。原始资料：VS Code 远程扩展架构

在 wanctl 中，通用 MCP 已经能统一它自己的远端工具；若要让宿主所有原生工具都跟着切换，需要宿主也保存并使用这个工作地点。评审设计时，应明确自己正在承诺哪一种接入程度。

AI 已进入 wanctl 工作区，却调用了宿主原生的本地读文件工具。谁能决定这次本地读取是否改走远端？

查看解释（可以跳过作答）

要改变原生工具的路由，必须由宿主的接入或后端适配层参与。模型可以选择正确工具，但 wanctl 不能拦截没有经过它的调用。

看到“支持 MCP”时，再补问一句：覆盖的是哪组工具？下一篇讨论这些工具依赖的状态各自活多久。

如果这一点还不清楚，可以把本篇的问题和你自己的项目场景交给协作 agent，请它换一个例子解释。自检只提供即时反馈，不代表已经掌握；隔一段时间，不看答案再解释一次更有价值。