OpenClaw MCP 踩坑实录：从 Connection closed 到排查思路全记录

时效性说明：本文记录的是 OpenClaw 2026.6.1 版本的 MCP 调试经历。部分问题（如 brave-search 与 Node.js 子进程的兼容性）在后续版本中可能已经修复，建议对照当前版本文档阅读。

最近在 Ubuntu 原生环境里给 OpenClaw 2026.6.1 做了一次 MCP（Model Context Protocol）服务"大体检"。目标很简单：把搜索、浏览器、代码、文件、数据库这些能力全部接上，让 Agent 能调用外部工具。结果算是"基本成功"——context7、chrome-devtools、github、sqlite 都跑通了，但 brave-search 和 filesystem 这两个服务却暴露出两个截然不同的问题：一个是运行时兼容性陷阱，一个是 schema 验证不兼容。

本文把排查过程、根因分析和可复用的诊断方法整理出来，供后续类似踩坑参考。

最终成果一览

安装完成后，7 个 MCP 服务的状态对比如下：

从结果看，真正跑不通的有两类：运行时崩溃（brave-search）和 配置不兼容（filesystem）。下面分别说。

踩坑 1：brave-search 启动失败 —— Connection closed

这是本次调试中最有代表性的一个问题。

症状：每次 gateway 重启后，日志里反复出现：

[bundle-mcp] failed to start server "brave-search":
McpError: MCP error -32000: Connection closed

服务明明写在 openclaw.json 里，配置看着也没问题，但就是起不来。

排查过程：

1. 先怀疑环境变量：一开始以为是 BRAVE_API_KEY 没传进去，在 openclaw.json 的 env.vars 里加了 key，重启 gateway。结果照常报错。后来才搞清楚，env.vars 注入的是 gateway 进程本身，跟 MCP 子进程不是一回事。

2. 对比正常服务：把 context7、github 的配置和 brave-search 拿来对比。context7 只有 command，github 有个空 env: {}，都正常。说明配置格式本身不是问题。

3. 手动启动测试：直接在终端运行 brave-search 二进制，不管有没有带环境变量，都能正常输出 “Brave Search MCP Server running on stdio”，而且手动发送 JSON-RPC initialize 请求也能拿到正确响应。证明二进制文件本身完全健康。

4. 协议级验证：通过管道把原始 JSON-RPC 消息喂给 brave-search，服务正常返回协议握手响应。这进一步排除了"二进制坏了"的可能。

5. 日志交叉验证：翻 /tmp/openclaw/openclaw-2026-06-05.log，确认错误发生在 bundle-mcp 子系统，服务启动后立刻断开连接。

根因分析：OpenClaw 2026.6.1 的 MCP 子进程管理机制，默认假设所有 MCP 服务器都是 Node.js 进程。brave-search 是一个 Rust 编译的二进制文件，在 stdio 通信握手阶段与 OpenClaw 的预期存在差异，导致连接刚建立就被关闭。

简单说：服务本身没问题，但 OpenClaw 的"月子中心"只照顾 Node.js 宝宝，Rust 宝宝一哭就被请出去了。

结论与后续：当前临时方案是禁用 brave-search，用 context7（文档搜索）+ web_fetch（网页抓取）顶替搜索能力。长期来看，等 OpenClaw 修复对非 Node.js MCP 子进程的兼容性，或者 brave-search 官方提供更适配的打包方式。

踩坑 2：mcp-server-filesystem 被 schema 验证卡住

这个问题的性质跟 brave-search 不同：服务本身没问题，是 OpenClaw 2026.6.1 的 MCP schema 验证把 filesystem 的配置格式当成不合规，直接拒绝启动。

处理方式比较直接：在配置里加一句 "enabled": false，眼不见为净。等 OpenClaw 更新 schema 验证规则后再重新启用。

这件事给我们的提醒是：MCP 生态里，服务端和客户端的 schema 同步是个持续痛点。今天能用的配置，下个版本可能就报错。

关键发现：环境变量注入的两条独立通道

调试过程中还有一个非常重要的发现，容易让人混淆：

• env.vars 配置节 → 注入 OpenClaw gateway 进程 的环境变量
• mcp.servers.<name>.env → 单独给 某个 MCP 子进程 注入环境变量

这两条通道互不干扰、互不传递。很多初次配置 MCP 的用户会把 API Key 放在 env.vars 里，然后纳闷为什么 MCP 服务里拿不到值。记住：MCP 子进程需要的 key，必须写在它自己的 env 里。

可复用的排查方法论

不管遇到什么 MCP 启动问题，下面这套流程基本都能用：

1. 先看日志定方向：从 bundle-mcp 子系统的报错确定是"连接断开"、“schema 错误"还是"文件不存在”。
2. 对比正常服务：找同一个 OpenClaw 实例里能正常跑的 MCP，把配置拿来逐字段对比。
3. 隔离变量测试：手动在终端运行 MCP 二进制，排除"服务本身坏了"的可能。
4. 协议级验证：用原始 JSON-RPC 消息测试，确认服务协议层是否正常。
5. 源码/日志交叉验证：结合 OpenClaw 的 subsystem 日志和 MCP 服务源码，定位是客户端问题还是服务端问题。

这套方法不仅适用于 OpenClaw，换成 Claude Code、Cursor 等 MCP 客户端也基本通用。

修复方案汇总

关联阅读

• [[OpenClaw MCP 安装与调试报告（2026-06-05）]]
• [[2026-06-30 OpenClaw 内存膨胀排查与修复]]

相关工具与参考

• OpenClaw —— 本次调试的主体环境
• brave-search-mcp-server —— Brave 官方 MCP 服务
• context7-mcp —— 文档检索 MCP 服务
• chrome-devtools-mcp —— Chrome DevTools 官方 MCP 服务
• modelcontextprotocol/servers —— MCP 官方参考实现仓库（含 filesystem、sqlite 等）

后续关注

• OpenClaw 后续版本是否修复对非 Node.js MCP 子进程的启动兼容性
• brave-search 官方是否有针对 OpenClaw 子进程管理方式的适配计划
• mcp-server-filesystem 的 schema 验证规则何时更新
• 社区里是否出现更稳定的 Rust/Go 语言 MCP 服务打包方案

经验教训速查

• env.vars ≠ MCP env：两条独立的环境变量通道，不要混用
• 配置正确 ≠ 能启动：openclaw.json 写得再漂亮，也可能被运行时兼容性卡住
• 手动能跑 ≠ OpenClaw 能跑：stdio 模式下正常，不代表通过 MCP 管理器启动也正常
• Rust/Go 二进制要额外小心：Node.js 生态的 MCP 客户端对非 Node.js 子进程的 stdio 握手可能存在隐性假设
• schema 验证是双刃剑：能拦住错误配置，也可能误伤合法但格式"非标准"的服务

如果你也在 OpenClaw 上折腾 MCP，希望这篇文章能帮你少走弯路。有问题或新发现，欢迎交流。

–全文完–

若你有故事想讲、有困惑想聊、或是想找个人说说心里话，甚至只是吐槽发泄一下情绪，都欢迎来找我聊聊：　　　《内容已折叠，点击展开》

希望我写的每一个字，成为我自己和某个人活下去、拼下去的力量。　　　　　　　　　　　　　　　　　　　　　《内容已折叠，点击展开》

“技术终归是工具，而我们一次次认真把问题理顺，守住的其实不只是页面样式和代码输出，还有那一点不愿被混乱打败的心气，是每一个深夜仍愿点灯前行的人。”

转载请注明来自https://oklife.me。