挖到 Claude Code 未公开的 MCP 加速开关，tweakcc 当天提交 PR
最近在用 Claude Code 时，用得越顺手，启动时的那阵漫长等待就越显得碍眼。
我装了 9 个 MCP 服务器：sequential-thinking 用来思考，memory 用来记东西，firecrawl 用来抓网页……每一个都是得力助手，但加在一起，每次启动都要对着终端干等十几秒，才能看到输入框。
这十几秒的延迟虽然不算长，但在频繁使用（比如反复重启会话）的场景下，确实有点消磨耐心。
让 Claude 帮我逆向它自己
本来想去翻文档，结果官方文档里关于 MCP 优化的内容一片空白。
考虑到 Claude Code 的 CLI 本质上是一个 JavaScript 文件，虽然发布出来的代码被压缩（minified）过，但环境变量为了能被操作系统识别，通常都是大写字母加下划线，很难被混淆。
于是我直接问 Claude：“你能分析一下你自己的源码，找找有没有控制 MCP 连接的 hidden flags 吗？”
Claude 也很配合，直接用 Grep 工具在它自己的 cli.js 里翻了一遍。还真被它挖出来三个看似相关的变量：
MCP_CONNECTION_NONBLOCKINGMCP_SERVER_CONNECTION_BATCH_SIZEMCP_REMOTE_SERVER_CONNECTION_BATCH_SIZE
变量背后的逻辑
这些变量名非常直观，根据命名就能推测出用途。
MCP_CONNECTION_NONBLOCKING：这正是我要的。现在的启动过程是”阻塞”的，必须等所有服务器连上才让用户说话。设成 1，应该就能”非阻塞”启动，先让我进交互界面，服务器在后台慢慢连。
MCP_SERVER_CONNECTION_BATCH_SIZE：Claude 还特意去 minified 代码里确认了一下逻辑：
1 | .MCP_SERVER_CONNECTION_BATCH_SIZE||"",10)||3 |
翻译过来就是：读取环境变量，默认值是 3。也就是说，我有 9 个服务器，它得排队分三批连。对于本地进程来说，这个并发度确实太保守了。
有趣的闭环
代码里既然有这些开关，我想看看社区里有没有人在用，或者有没有相关的讨论。
这一步挺有意思：我指挥 Claude 用 firecrawl 去搜社区文档，用 grep.app 去搜 GitHub 上的 dotfiles，用 deepwiki 去查相关仓库。
这形成了一个有趣的闭环：我正在用这几个导致启动慢的 MCP 工具，去研究怎么让它们启动变快。
搜索后发现，MCP_SERVER_CONNECTION_BATCH_SIZE 在一些逆向工程项目和 Claude Code 兼容 CLI（如 shcv/claude-investigations、shareAI-lab/Kode-cli）里有记录。但效果最显著的 MCP_CONNECTION_NONBLOCKING，似乎还没人公开提到过——至少在 GitHub 的代码、Issue、PR 里都搜不到相关讨论。
这让我有点意外。一个能把启动时间砍半的开关，居然没人提过？
实测效果
我让 Claude 写了个测试脚本，排列组合测一下这几个变量的效果。
测试环境是 WSL2，Node.js v24。结果非常明显：
| 配置 | 平均启动时间 | 效果 |
|---|---|---|
| 默认配置 | 15.6s | — |
| NONBLOCKING=1 | 7.6s | 快了 51% |
| 只改并发数 | 15.6s | 无变化 |
| 两者全开 | 7.9s | 快了 49% |
只要开了 NONBLOCKING，启动时间从 15 秒降到了 7 秒多，减少了约一半。
而且我发现，单独改并发数（BATCH_SIZE）没用，因为只要是阻塞模式，并发再高也得等最慢的那个连完。只有开了非阻塞，并发数的调整才有意义——能让后台连接更快完成，让工具更早可用。
顺便提一句，既然 Anthropic 最近收购了 Bun，我还测了下用 Bun 运行的效果。本以为会比 Node 快，结果启动速度反而略慢（9.5s vs 7.6s）。不过内存占用确实低了很多，只有 Node 的三分之一。
最终配置
验证完这些后，配置其实很简单，在 .zshrc 里加两行：
1 | export MCP_CONNECTION_NONBLOCKING="1" |
现在打开 Claude Code，7 秒左右就能看到输入框。虽然那几个 MCP 工具可能还在后台连接，但至少我可以先开始输入了。
后记
这类未文档化变量的状态并不稳定，版本升级后可能失效或改名。所以我更愿意把它当成一个临时优化手段，而不是长期依赖的配置。
这次过程里更有价值的其实是方法：先在 cli.js 找到入口，再用 MCP 工具验证社区的使用情况，最后用脚本把效果量化。少了任意一步，都可能把“猜测”当成“结论”。
如果未来官方补上文档，或者提供更稳定的配置入口，这些变量自然就可以退场了。在那之前，它们确实解决了启动慢的问题。
意外的后续
写完这篇文章后，我顺手向 tweakcc（一个 Claude Code 的增强工具）提了个 Issue，建议把 MCP_CONNECTION_NONBLOCKING 内置进去。
没想到不到三小时，维护者就提交了 PR #407，不仅加了非阻塞开关，还把批量大小也做成了可配置项。
这个响应速度让我有点惊喜。从逆向发现到被社区工具采纳，整个过程不到 24 小时。
开源社区的这种效率，大概就是为什么我们愿意花时间挖掘这些细节的原因吧。