自动接入 MCP 的配置生命周期：追加、冲突与撤回

同一份本地工具服务接入多个 Agent，难点往往落在客户端配置上：配置是本次启动生效，还是所有新进程都能看到？用户原来已经配好的 MCP 会不会被覆盖？工具返回成功之后，怎样判断任务真的继续了？

我是 Termexo 的维护者。本文以 v0.10.10 已实现的五种客户端接入为例，整理可以复用的设计取舍。内容由 AI 辅助整理；示意图与真实界面来源分别标明。

一、把运行生命周期与配置生命周期分开

按照已实现连接路径绘制的技术图，非软件截图。

服务端管理工作区、终端和任务，默认关闭，开启后只监听本机回环地址。默认地址是 http://127.0.0.1:7421/mcp。自动接入的客户端通过 stdio 桥接程序访问它，桥接每次请求读取当前端口与系统凭据，生成的配置和启动命令不包含令牌。

这三个层次的生命周期并不相同。桌面服务关闭后，配置条目仍被客户端识别，不代表工具能够响应。已经运行的 Agent 也不会因为更新了一份配置就必然重载，需要重新启动；attach 连接的原进程同样需要重启。

排查时应先确认服务运行，再确认当前进程载入配置，最后确认请求获得真实返回，避免用“配置文件里有一行”代替链路验证。

二、配置归属决定撤回范围

Claude Code、Codex 与 OpenCode 使用本次启动配置，保留已有 Profile 或其他 MCP 服务。其中 OpenCode V1 和 V2 的结构不同，需要分别生成 mcp 与 mcp.servers 配置。

Grok Build、Antigravity 使用用户级配置。这意味着在 Termexo 外启动、读取同一份配置的相应客户端，也可能看到 termexo-desktop 条目。这种影响应该在使用说明中写清楚，不能只把它描述成某个窗口内部的开关。

关闭自动连接或服务并应用后，Termexo 移除自己添加的内容，保留其他配置。遇到用户已有的同名服务，或者原配置无法解析，会提示错误。

可复用的原则是明确配置归属：追加时知道哪些字段属于本工具，撤回时也只处理这些字段。解析失败时，保留用户文件比猜测其意图更可靠。测试应覆盖已有其他服务、同名条目和格式错误，而不只覆盖空配置。

三、从只读目标开始检验权限

19 个工具覆盖工作区与终端、任务，以及部分设置。终端与任务范围默认允许，设置访问单独开启；读取配置不包含凭据。Agent 自身的工具审批继续生效。

v0.10.6 真实录屏封面，仅用于说明终端归属；不是 v0.10.10 MCP 设置截图。

列出工作区、读取指定测试终端、创建草稿任务和关闭进程，影响显然不同。首次验证可只发送“调用 workspace_list，列出工作区，不要创建任务、发送输入或修改设置”。先核对实际目标，再逐项验证写操作。

这里的权限分组并不等同于组织级统一审计或多人授权系统。桌面 MCP 是本地工作台的操作入口，需要按它实际提供的粒度安排使用流程。

四、用可观察结果定义操作完成

terminal_write 成功只表示输入已交付终端；task_execute 成功表示启动流程建立了任务与终端绑定。一个 Agent 可能仍在等待回车、审批或补充信息。任务的完成标记也不能代替代码验收。

验证可以拆成四步：握手并发现工具；对隔离工作区做真实查询；由自动接入的 Agent 发起真实工具调用；检查后续终端状态和实际产物。每一步回答的问题不同，应该分别记录。

目前任务执行支持 Claude Code、Codex、OpenCode 和 Grok Build。Antigravity 可以在终端中自动接入 MCP，但看板任务暂不支持由它执行。连接支持列表和任务执行支持列表不能混用。

五、记录不同深度的集成证据

本次正式 Windows 程序通过官方 MCP SDK 完成 stdio 握手，发现 19 个工具，并查询隔离桌面的工作区。自动接入的 Codex 任务终端实际调用 workspace_list，返回测试工作区。

Grok 完成握手和工具发现，OpenCode 2.0.15 隔离服务确认连接，Antigravity 确认条目被识别为启用，Claude 配置合并由 Rust 测试覆盖。这些是不同深度的证据，不能写成五种模型都完成了同一项端到端任务。

Codex 的任务试验还通过 terminal_write 补发了回车，提示词全程自动提交仍需要进一步验证。把这个步骤记录下来，其他开发者才知道复现时可能需要处理哪里。详细过程见 公开联调记录。

多个 Agent 修改同一目录时，仍要用不同目录或 Git worktree 隔离，并安排人工整合与验收。统一工具入口让现场可以被查询，不会自动解决并行修改冲突。