OpenCode 新增 MCP 连接复用：多项目开发少开几份工具

2026 年 11 月 6 日，OpenCode 在 v2.2.6 更新日志中公布 MCP 连接复用，让配置相同的多个项目有机会共用工具连接。经常同时维护前端、后端和内部脚本的开发者，值得检查那些随项目重复启动的服务。本文讲清它能省掉哪类重复工作、为什么打开开关仍可能不生效，以及怎样用一次小规模对照决定是否保留。

[配图建议：多个项目的轨道汇入共同连接枢纽，另一条轨道保持独立 + 铜版与水粉结合的科技杂志插画。]

一、项目开得越多，工具也要跟着开很多份吗

先看一个常见场景：你在几个目录间切换，每个项目都接入同一套文档查询或设计工具。对开发者来说，它们是同一个服务；对客户端来说，却可能是一组组分别建立的连接。

OpenCode 的更新针对这个重复层：同一个 OpenCode 服务中，符合条件的目录可以共享一条 MCP 连接及工具列表。 官方将收益概括为减少进程、加快启动；这是产品更新的目标，实际改善仍取决于你连接什么服务。来源：OpenCode 11 月 6 日更新日志

可以把它理解为几间工作室共用一个工具柜。工作室仍各做各的项目，取工具时经过共同入口。值得关注的首先是启动和连接管理：打开第二个项目时，能否少做一次服务初始化，而不是要求模型突然更擅长写代码。

连接成本与模型调用成本要分开记录。 即使后台连接变少，每次任务仍可能查询同样多的资料、返回同样长的内容。判断这个更新是否有价值，应看你原本花在重复初始化上的时间，不能直接推导出 token 账单下降。

还有一个日期容易混淆：相关 PR 在 11 月 4 日合并，版本更新日志日期是 11 月 6 日。本文讨论后者带来的可用配置，不把代码合并日与版本公告日当成同一事件。来源：PR #61185

[配图建议：同一工具重复建立连接与多个目录共用入口的对照，不展示性能数字 + 简洁流程示意图。]

二、最容易漏掉的条件：开关打开，仍可能各连各的

官方文档提供按服务器启用的 pool: true，默认关闭。下面按文档示例展示 V2 配置层级，适用于已经准备使用该远程服务的人；它不会替你完成授权：

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "servers": {
      "cloudflare": {
        "type": "remote",
        "url": "https://mcp.cloudflare.com/mcp",
        "pool": true
      }
    }
  }
}

能复用还要同时满足协议和配置条件。 文档限定共享连接使用 MCP 2026-07-28 修订版；启用 pooling 且没有设置 protocol 时，会按 auto 协商。旧协议服务或显式 legacy 配置仍按目录分别连接。

远程服务需要地址、请求头、OAuth 设置及登录账户等一致；本地服务则要核对命令、工作目录和环境变量，超时与协议设置也参与匹配。共享 OAuth 连接还需使用同一服务器名。“看起来访问同一个网站”不足以证明配置相同。 来源：MCP 共享连接文档

最实用的排查顺序是：先确认协议，再比较账户，最后比较项目覆盖配置。比如测试项目使用沙箱凭据，正式项目使用生产凭据，分开连接本来就合理。不要为了看到连接数下降，把不同身份改成同一个身份。

本地工具尤其要留意路径。文档要求跨项目复用时设置固定 cwd；沿用项目默认目录，通常仍会分别启动。但改变目录也可能改变工具行为：一个按相对路径读取配置的程序，换了启动位置，读到的文件就可能不同。先弄清工具是否依赖当前项目，再考虑共享。

[配图建议：协议、账户、工作目录三道检查关卡，匹配后才能汇入共享入口 + 清晰的技术编辑信息图。]

三、先共享公共查询，项目状态留给独立连接

下面是基于功能边界给出的试用建议，并非官方兼容性名单：

这张表的依据是项目状态依赖程度。如果每次调用已经明确给出目标，服务本身也支持多个调用方，共享更容易评估；如果工具默认“当前打开的项目就是目标”，就要先确认这句话在共享后是否仍成立。

实现说明还提到两项值得纳入验收的行为：共享连接不声明目录 roots，最后一个使用目录释放后会立即关闭；共享进程崩溃时，所有使用方都会看到失败。来源：PR 的共享与独立连接说明

因此，不应只测试正常查询。可以在测试环境里先关掉一个项目，确认另一个仍能工作；再全部关闭并重新打开，检查连接能否恢复。对依赖目录 roots 的工具，直接保留原配置往往更省事。

复用越成功，共同依赖也越集中。 这是架构上的取舍：重复进程少了，但排查故障时，需要知道哪些项目共用同一个入口。给试点留一份简短记录——服务名、使用账户、目标环境、参与项目——比同时给所有工具打开开关更容易维护。

[配图建议：公共文档查询共用工具柜，带项目路径或客户身份的工具分别放置 + 温暖的等距工作台插画。]

四、用一次小规模对照，决定是否值得保留

试用从一项低风险查询服务开始。以下是建议流程，不是本站已执行的性能测试：

1. 留基线。 在同一 OpenCode 服务里打开两个测试目录，记录当前连接、相关进程及工具可用所需时间；固定服务版本、账户和调用内容。
2. 只改一个开关。 为选定服务器启用 pooling，让连接重新建立。用 opencode mcp list 查看状态，再结合日志与本地进程观察；这个命令显示连接状态，本身不足以证明已经复用。来源：官方管理说明
3. 核对结果。 两个项目分别查询一个可验证的目标，检查账户、返回内容和资源位置。连接数减少而结果指向错误，不能算通过。
4. 测试关闭与恢复。 依次退出项目、重新连接，观察另一方是否可用，以及工具失败时能否识别影响范围。异常时撤销这项配置，再比较原行为。

计时最好分成“工具准备完成”和“模型回答完成”。后者会受到网络、推理和输出长度影响，单次快一点很难归因。重复几次、保留原始记录，才适合讨论自己环境里的改善；不必急着把结果换算成一个漂亮的百分比。

如果你只开一个项目，或常用服务仍走旧协议，这次更新可以暂缓。它更适合同时维护多个目录、反复连接相同工具的人。需要优化的是已经存在的重复开销，先观察到它，再决定开关是否值得留下。

[配图建议：同样两个项目进行开关前后对照，记录启动、结果、关闭恢复三个观察项 + 实验记录纸风格信息图。]

总结：今天先找一个被重复启动的工具

OpenCode 的 MCP 连接复用提供了一条减少多项目重复初始化的路径，协议、账户和目录行为决定它能否用好。今天可以先挑一个低风险查询服务，用两个测试目录完成一次开关前后对照；确认结果正确、生命周期正常，再扩大范围。

你最希望跨项目共用的 MCP 工具是什么？它需要记住当前目录，还是每次调用都能明确指定目标？这两个问题，往往比“要不要全部开启”更有助于做决定。

[配图建议：一张写着“选工具—核对条件—小范围验证”的行动便笺 + 克制的手绘编辑插画。]

资料核查：2026 年 11 月 7 日（Asia/Shanghai）。本文依据 OpenCode 官方更新日志、MCP 文档和合并 PR 撰写，未在本站环境实测启动或内存收益；场景与验证流程为解释性建议。封面由内置图像生成工具原创生成，为概念插画。