李枝蔚最近接了个需求，要让 OpenClaw 定期读取本地一个旧项目管理工具导出的数据文件，再在工作区里自动生成周报。翻遍现成的 MCP 仓库，工具一大堆，但大多数要么绑死了某个云服务，要么只适配特定 AI 客户端，没有一个是能直接吃我这套本地文件的。折腾到半夜，我决定不找现成了，自己动手写一个 MCP 服务。
几天下来，从对 MCP 协议一知半解，到在 OpenClaw 里稳定跑通自定义工具，整个过程踩了不少坑，也把协议的几个关键点彻底搞明白了。这篇文章就把这套流程完整写出来：MCP 和 OpenClaw 各自解决什么问题、开发环境怎么准备、协议核心逻辑是什么、怎么手写一个服务端、怎么接进 OpenClaw，以及实际调试中最容易卡住的几个地方。
适合两类人读：一类是想给 OpenClaw 加自定义工具但不知道从哪下手的；另一类是看过 MCP 文档、觉得大概懂了，但真到自己写的时候发现离跑通还差一截的。看完这篇文章，你应该能少踩一大半我踩过的坑。
1. 先弄清楚 MCP 和 OpenClaw 的分工，再决定从零造轮子
很多朋友找我聊 OpenClaw 开发，开口第一句就是"OpenClaw 支持 MCP 了，怎么装？"。这个问法其实暴露了一个常见误区：把 OpenClaw 和 MCP 当成同一个层次的东西。实际上它们是两层东西，一个相当于"协议标准"，一个相当于"协议的使用方"。不把这两者的关系理清，后面写起工具来很容易被绕晕。
1.1 MCP 到底是什么，它和"插件"的本质区别
MCP 全称 Model Context Protocol，模型上下文协议，是 Anthropic 在 2024 年底提出的一个开放协议。它的核心目标特别简单：让 AI 模型能够用标准化的方式调用外部工具、读取外部数据源。你可以把它理解成 AI 应用领域的"USB 接口标准"——每个设备（工具）只要按照 USB 规范设计，插到任何电脑上都能被识别和使用。MCP 就是给 AI 模型外接各种能力的通用接口协议。
很多人第一次接触 MCP，下意识会把它类比成"AI 插件"。这个类比只能算对了三分之一。插件的特点是跟宿主强绑定：Chrome 插件只能在 Chrome 里用，换成 Edge 可能就废了。MCP 不一样，它是客户端和服务端解耦的。客户端是 Claude Desktop、OpenClaw、Cursor 这类支持 MCP 的应用，服务端是独立运行的工具进程。只要服务端实现了 MCP 协议，任何支持 MCP 的客户端都能把它拉起来用。
这意味着一个非常实际的收益：我这次为 OpenClaw 写的工具服务，以后如果我想换到别的 AI 客户端，协议层完全不用改，只需要改一下客户端的连接配置。这种一次开发、多处复用的特性，是传统插件机制给不了的。
还有一个经常和 MCP 混在一起的概念是 Computer Use。热搜里也有人问"computer use 和 mcp 的区别"，这里我多说一句：Computer Use 是 AI 直接操作电脑的一套能力，截屏、识别界面控件、移动鼠标、点击输入，本质是"替你在操作系统里干活"；MCP 则是"允许你调用某个具体能力"的标准接口。打个比方，Computer Use 是让 AI 亲自上手操作电脑，MCP 是给 AI 插上一堆专用工具。两者可以配合用，但不是一回事。
1.2 OpenClaw 在整条链路里的位置
OpenClaw 是一个服务端形态的 AI 自动化代理运行时。它做的事情包括：管理多个大模型提供方、维护工作区文件、执行本地命令、调度技能（Skills），以及通过 MCP 协议连接外部工具。用一句话概括：它负责"做决策"，MCP 工具负责"干具体的事"。
具体到一次任务执行，大致是这个流程：用户给 OpenClaw 一个目标，OpenClaw 内部的大模型把目标拆解成步骤，然后判断每一步需要调用什么外部能力，如果需要，就通过 MCP 协议调用对应的工具服务，拿到结果后继续下一步决策。
这里有个很关键的认知：OpenClaw 本身不实现具体的业务逻辑，比如"扫描工作区文件""查询数据库""操作某个内部系统"，这些都得靠工具提供。MCP 的价值就在于把这些工具标准化，让 OpenClaw 可以用统一的协议去调用，不用为每个工具单独写一套适配代码。
另外还有一个很多人问的问题：OpenClaw 和 ClawHub 有什么区别？简单说，OpenClaw 是运行时本体，ClawHub 是围绕它建立的一个分享生态，类似应用商店，里面放着别人打包好的技能和工具配置。你可以从 ClawHub 拉现成的来用，但真正贴合自己业务的工具，往往还得自己写，这也是这篇文章存在的意义。
1.3 为什么必须自己写工具，而不是攒一堆现成的
先摆结论：现成的 MCP 工具当然可以用，但遇到以下三种情况，自己写几乎是唯一选择。
第一，现成工具质量参差不齐。MCP 生态还处于早期，社区里大量工具是开发者几天内赶出来的，README 写得漂亮，实际一调就发现边界情况完全没处理。我测试过好几个号称"文件处理"的 MCP 服务，连中文路径都处理不好，更不要提大文件流式读取。
第二，数据安全问题。你要处理的数据往往在公司内网、在本地磁盘，甚至涉及不能出内网的敏感信息。把这些数据交给一个第三方维护的 MCP 服务，风险是不可控的。自己写一个本地跑的服务端，数据全程不出本机，心理踏实得多。
第三，也是最核心的一点：只有你自己知道业务长什么样。你需要的是什么数据格式、什么目录结构、什么过滤规则，这些细节只有你清楚，通用工具不可能覆盖到。MCP 服务端的开发成本其实很低，一个标准工具也就是几十到几百行代码的事，相比你花几个晚上去适配别人工具的时间，自己写反而更快。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 开发环境搭建：从命令行报错到模型接通的完整准备
OpenClaw 和 MCP 的关系理清之后，下一步就是先把环境搭起来。这一节我把从安装到模型配置的关键步骤过一遍，重点讲实操中最容易踩的坑，尤其是 Windows 环境下那一堆莫名其妙的报错。
2.1 安装 OpenClaw：Windows 上最典型的坑
如果你在 Windows 上用 PowerShell 执行安装命令后，敲 openclaw 却收到这样的报错：
code复制openclaw : 无法将“openclaw”项识别为 cmdlet、函数、脚本文件或可运行程序的名称
不用慌，这是典型的"可执行文件不在 PATH 里"导致的。出现这个问题的原因通常是两种：一是安装过程中 PATH 环境变量没刷新，重开一个终端窗口就好了；二是安装器把可执行文件放到了某个目录，但没加进系统 PATH。第二种情况需要你手动把对应目录加到环境变量里。
装的时候还会遇到一个问题：安装路径能不能指定？答案是绝大多数情况可以。Windows 下使用 PowerShell 安装脚本时，通常支持 -InstallDir 之类的参数来指定目录。如果你用的是免安装的便携包，解压到任意目录后，记得把解压目录手动加入 PATH。
另外提一句，如果你是 Linux 服务器，安装后看到提示可能存在旧版本的权限审批文件：
code复制legacy exec approvals exist at /root/.openclaw/exec-approvals.json
这是 OpenClaw 升级后把历史审批记录迁移到了新格式，不影响正常使用，可以手动删除或保留，看你自己习惯。
还有一个容易被忽略的点：OpenClaw 有稳定版和开发版两个更新渠道，命令是 openclaw update --channel stable 或 openclaw update --channel dev。作为日常开发，建议用稳定版；如果你需要测试新功能，再切换到 dev 渠道。不要长期留在