最近一周我都在折腾 OpenClaw 接入 MCPModel Context Protocol本来只是想让它帮我查一下本地文件、跑几个脚本结果越用越发现不对劲一次看起来很普通的对话后台 token 消耗量比我预想的高出一大截。OpenClaw 是本地部署的开源个人 AI 助手MCP 是让 Agent 调用外部工具的标准协议这俩组合起来确实强大但 token 的隐性消耗几乎没人提前跟你说清楚。这篇东西就记录我这次接 MCP 的完整过程、配置思路以及把 token 账单一层层拆开之后踩过的坑给正准备上手或者已经在用的人一点参考。1. 先说清楚OpenClaw 是什么MCP 解决了什么问题1.1 OpenClaw一个长在终端里的“数字管家”OpenClaw 本质上是一个可以跑在自己电脑上的 AI Agent 框架核心特点是你拥有完整的控制权。它不像网页版 ChatGPT 那样开个对话框聊完就走而是给你一个常驻的助手进程你可以给它配置各种技能skill、接入不同的大模型 API甚至让它定时执行任务比如每天早上去抓某个网站的数据、整理某个目录里的文件改动。常见部署方式有几种直接在本地用 Node.js 跑、通过 Docker 跑、或者在 Windows 上配合 WSL 环境运行。我第一次在 Windows 上装的时候就碰到过提示“OpenClaw 无法安全验证 WSL 环境”的情况后来在 PowerShell 里执行wsl --status检查发现 WSL 版本没升级到 2重新更新一下 WSL 内核就好了。如果你也是 Windows 用户建议优先把 WSL 2 环境弄干净因为后面很多 MCP server 依赖 Linux 下的指令和脚本跑在 WSL 里可比在 PowerShell 里舒服多了。OpenClaw 能做的事上限很高但能不能发挥出来取决于你能给它接上多少“外部能力”。光靠模型本身聊天它也就回答你问题一旦它能调你的文件系统、数据库、浏览器、命令行工具性质就完全不同了。而把这些外部能力标准化的那层东西就是 MCP。1.2 MCP 协议给 Agent 装上标准化的“外接器官”MCP 的全称是 Model Context Protocol由 Anthropic 在 2024 年底提出现在已经被大量 AI 客户端支持OpenClaw、Claude Desktop、Codex、Cherry Studio 这些都在兼容它。你可以把 MCP 理解成 USB 接口以前每个外设都要专用的插槽和驱动现在统一成 USB 口只要设备支持 USB插上去就能用。MCP 做的就是把“模型能调用的工具”统一成一套标准——一个 MCP server 对外暴露若干工具tool每个工具用 JSON Schema 描述自己的入参和返回值MCP client也就是 OpenClaw负责发现这些工具、在需要时调用它们并把结果喂回给模型。这个设计的价值在于解耦。模型不需要知道工具内部是怎么实现的它只需要知道“有个工具叫read_file输入是路径输出是文件内容”就够了。服务器端用什么语言写都不重要Python、Node.js、Go 都行只要走同一套协议。但这里埋了一个很多人没意识到的坑MCP 的标准化让工具接入变得简单也让工具产生的数据毫无阻碍地涌进模型的上下文。每一次工具调用返回的内容模型都要完整“读”一遍才能决定下一步动作而这些内容全都换算成 token。你接入的 MCP 工具越多、返回的数据越肥你的账单就越难看。这就是我这篇文章最想展开的部分。2. 给 OpenClaw 接 MCP 的完整实操2.1 动手前先把环境理清楚我以最经典的场景举例让 OpenClaw 通过 MCP 去操作本地文件系统比如“统计某个目录下最近修改过的文件”。这个场景足够简单又能完整走通“模型→MCP client→MCP server→本地命令→返回值→模型”的链路。准备下面三样东西OpenClaw 本体从 Node.js 官网下载 LTS 版本装好再按 OpenClaw 的官方文档完成初始化。装好后终端里能执行openclaw命令。MCP server这里我用一个自己写的 Python 小服务提供两个工具一个是list_recent_files一个是get_file_size。用现成的 filesystem MCP 官方包也行但自己写一遍更容易理解协议内部发生了什么。一个大模型 API keyOpenClaw 需要配置一个可调用的模型接口用 OpenAI 系的、Claude 系的或者本地 Ollama 部署的模型都可以。我个人建议调试阶段先用 Ollama 或者便宜的模型等链路跑通了再切到能力更强的模型省钱又省心。2.2 第一步准备一个可以被调用的 MCP 服务MCP server 说白了就是一个常驻进程监听标准输入输出或者 HTTP 端口通过 JSON-RPC 和 client 通信。我这里用 Python 的mcp官方 SDK 快速写一个。# file_mcp_server.py from mcp.server import Server from mcp.server.stdio import stdio_server import os import time app Server(file-helper) app.tool() async def list_recent_files(directory: str, days: int 7) - str: 列出指定目录下最近 N 天内修改过的文件 result [] now time.time() for root, _, files in os.walk(directory): for name in files: path os.path.join(root, name) mtime os.path.getmtime(path) if now - mtime days * 86400: result.append(f{path} | 修改时间 {time.strftime(%Y-%m-%d %H:%M, time.localtime(mtime))}) if not result: return 最近没有文件变动 return \n.join(sorted(result)[-50:]) app.tool() async def get_file_size(filepath: str) - str: 获取单个文件的大小和行数 size os.path.getsize(filepath) line_count 0 with open(filepath, encodingutf-8, errorsignore) as f: for _ in f: line_count 1 return f{filepath} 大小 {size} 字节{line_count} 行注意几个细节。第一工具的描述文字要写清楚模型是靠这些描述来决定“什么时候调用哪个工具”的描述越准确调错工具的概率越低。第二返回内容我故意做了裁剪和排序只返回最新的 50 条这后面会讲是为了控制 token 消耗。第三这里用的是 stdio 模式也就是 OpenClaw 直接拉起这个 Python 进程通过标准输入输出通信不需要额外开端口。2.3 第二步在 OpenClaw 配置里注册 MCP 服务OpenClaw 的配置文件通常是一个openclaw.json或者config.yaml里面可以声明 mcpServers。核心配置长这样mcpServers: file-helper: command: python args: [file_mcp_server.py]如果你的 MCP server 跑在远程也可以改成 HTTP 模式的配置比如url: http://127.0.0.1:8000/mcp。但本地场景下用 stdio 模式最稳不用处理端口占用和跨域问题。配好之后重启 OpenClaw在交互界面里输入类似/tools的命令应该能看到list_recent_files和get_file_size已经出现在可用工具列表里。如果看不到优先检查两件事Python 进程有没有报错退出配置文件里args的路径是不是相对路径导致找不到文件。使用 python 这种裸命令时注意这个命令要能在 OpenClaw 的运行环境里直接执行否则要写完整路径。2.4 第三步验证调用链路是否打通配置生效后直接对 OpenClaw 说一句“帮我看一下 D:/projects 这个目录最近 3 天有哪些文件改动过。”这时候模型内部会发生这一串事情模型看到你的请求判断出需要调用list_recent_files工具于是让 OpenClaw 去执行这个工具OpenClaw 把参数{directory: D:/projects, days: 3}传给 MCP serverMCP server 扫描目录返回文件列表OpenClaw 把这一大段文本塞回给模型模型基于结果生成最后的回答。第一次跑通的时候你会很有成就感但这时候我建议你打开 OpenClaw 的日志模式或者直接盯着 API 的用量统计看你会立刻意识到刚才那一次“简单对话”消耗的 token 数量完全不简单。这就是下一节要拆解的。3. token 消耗每次对话里看不见的隐形支出3.1 先搞明白 token 在模型眼里长什么样token 不是“字数”它是模型处理文本的最小单位。中文里一个汉字大致对应 1 到 2 个 token英文一个单词平均对应 1.3 个 token一段代码的 token 密度更是高得吓人。不管你是输入还是输出只要是模型“看”过的内容全都按 token 计费。一次完整的模型请求账单由两部分组成prompt token你发给模型的所有东西和 completion token模型回复你的内容。非流式接口还会把 token 用量原样返回给你很多 Agent 框架却不把这个信息暴露给用户所以你会感觉“我不就用了一下吗怎么钱没了”。关键认知是prompt token 不只是你敲的那句话它包含系统提示词、历史对话、工具定义、工具返回结果。你每多接一个 MCP server工具定义就会占掉一块每多调一次工具返回结果就变成新的一批 token 塞进 prompt。对话越长、工具调用越多prompt 就越臃肿费用是呈阶梯式上涨的。3.2 实测一次对话账单拆解我给你算一笔我实测的账。假设我用的是一个中等价位的 API 模型场景就是上面那句“查看 D:/projects 最近 3 天文件改动”。系统提示词OpenClaw 自带的角色设定大约 1500 token。工具定义我注册的两个工具各自包含名称、描述、参数 schema 和示例大约 800 token。用户消息“帮我看一下 D:/projects 这个目录最近 3 天有哪些文件改动过”约 40 token。模型第一轮回复它决定调用list_recent_files这轮回复本身就是 completion token约 100 token。工具返回结果假设目录下有 30 个文件文件名加时间戳约 600 token。模型第二轮回复基于结果整理给你的最终回答约 300 到 500 token。单看一轮总共也就 3500 token 左右换成价格可能只有几分钱。但问题是真实对话不会这么干净。如果你问的是“最近 3 天文件改动顺便帮我看看最大的那个文件再按行数排个序”模型就要先调list_recent_files从结果里挑出候选文件再挨个调get_file_size甚至可能需要第三个工具。工具调用轮数一多每一轮都要重新把前面所有内容作为 prompt 发一次第一轮 prompt系统提示 1500 工具定义 800 用户 40 2340 token第二轮 prompt2340 第一轮模型调用 100 第一次工具返回 600 3040 token第三轮 prompt3040 第二轮模型调用 100 第二次工具返回 400 3540 token第四轮 prompt3540 第三轮模型调用 100 第三次工具返回 500 4140 token一次看起来“就问了几个问题”的对话实际上发送给模型的 token 总量是 13000 往上比你最后看到的那几行回答多了一个数量级。我第一次看到日志里一次对话烧掉 1 万多 token 时真的愣了好几秒这就是偷偷烧 token 的来源。3.3 为什么接 MCP 之后 token 涨得特别快对比没接 MCP 之前同样是聊 5 轮天prompt 基本就是对话历史来回滚增长是线性的。接了 MCP 之后增长变成“每多一次工具调用就多一轮完整上下文重发”而且工具返回的内容通常又长又结构化一次文件列表、一段数据库查询结果、一屏网页抓取内容动辄上千 token。我把最容易让 token 失控的几个点列一下工具定义全量常驻。你注册了 10 个 MCP server、总共 50 个工具那这 50 个工具的描述就永远压在每次请求的 prompt 里哪怕模型这次根本用不到它们。工具返回内容不做截断。比如 MCP server 返回一个 2000 行的文件列表模型会全部读一遍。你只是想知道“有没有包含 error 的文件”模型却被迫看完 2000 行。多轮工具调用叠加。Agent 的典型错误是“一步一步来”本来一次能查完的它非要拆成三步每一步都额外付一次全量上下文费用。history 越来越多。OpenClaw 默认会在一个会话里保留多轮历史如果是长会话每一轮工具调用引发的 prompt 膨胀还会把历史一起带上越滚越大。3.4 怎么量化自己到底烧了多少我建议你从三个地方交叉确认用量。第一模型服务商的用量面板。如果你用的 OpenAI 系 API后台直接能看到每天的 prompt token / completion token 曲线但这个面板不细分到对话想定位“哪次对话烧得多”比较难。第二OpenClaw 自己的日志。把日志级别调到 debug每次请求结束后通常能看到本次消耗的 token 统计。如果没有那就看请求体的大小日志里打印出完整 prompt 的话自己数一下长度就心里有数了。第三在 OpenClaw 后面套一层用量记录脚本。把 OpenClaw 的 API 请求转发到一个记录中间层记录每次请求的 token 数、耗时、请求时间。实测下来这是最精确的定位方式可以精确到“哪一次 MCP 调用花了多少钱”。这步做完你就知道真正的钱花在哪了。绝大多数情况下你会发现排名第一的不是模型回答而是各种工具返回结果和非必要的工具定义。4. 常见问题与排查技巧实录4.1 登录失败 / token 刷新异常的通用解法给 OpenClaw 配好模型 API 之后最常遇到的就是各种登录态问题。比如提示 “sign-in could not be completed: token exchange failed: error sending request”或者 “failed to refresh token: 400 bad request: invalid refresh_token: empty string”。我总结的排查顺序是这样的先分清是登录 token 还是 API key。前者是 OpenClaw 与模型服务商账号体系的认证后者是你直接填的密钥。遇到 token exchange 一类的错误优先怀疑是登录态过期。清理本地缓存的登录凭据重新走一遍登录流程。大部分 Agent 框架把凭据放在用户目录下的隐藏文件里不要手贱去改删掉让程序重新生成就行。检查系统时间。token 校验涉及签发时间和过期时间本机时间偏差超过几分钟就会直接报 token exchange failed这个问题最隐蔽也最好解决把系统时间自动同步打开。排查网络策略。403 forbidden 之类的错误里如果带有 country 字样基本是服务端在根据请求来源区域做校验跟你账号的地区设置不一致就会失败。这时你需要检查网络出口是否符合该服务的覆盖范围并确保 OpenClaw 进程没有走到奇怪的代理链路。另外我在重装了 OpenClaw 之后遇到过 refresh_token 为空字符串的奇怪问题最后重新初始化配置并登录才解决这种属于本地登录态和程序版本不匹配造成的优先用官方文档里的清理方式处理。排查这些的时候不要反复试错直接打开日志看具体报错链路效率最高。4.2 MCP 工具不生效 / 找不到工具工具没出现在可用列表里先别急着怀疑协议有问题。我遇到过的原因按概率排序MCP server 进程根本没起来。用 stdio 模式时OpenClaw 拉起子进程如果命令不对、路径不存在、Python 依赖缺了进程秒退工具列表自然空空如也。工具 schema 格式不合法。比如参数类型写了type: string却传了数组或者缺少必要的description字段部分 client 会忽略这个工具而不是报错。配置没有热加载。OpenClaw 一般在启动时读取 MCP 配置改完必须重启。排查方法就三步先手动在终端跑一遍python file_mcp_server.py确认不报错再把 MCP server 的输出重定向到日志文件看它有没有打印错误最后逐个工具调用不要用自然语言让模型猜直接在配置里写死测试。4.3 上下文越滚越大花钱越来越快这是接 MCP 之后最严重的问题而且往往等你发现账单已经刷了好几天了。缓解手段我实测有效的是这几个给工具返回内容加截断。像我的list_recent_files返回前用[:50]限制条数无论目录里有多少文件模型只看到 50 条。踏实了一点信息少 10% 没关系费用能省 60%。控制会话上下文长度。OpenClaw 有会话历史的清理策略可以把历史窗口调小或者要求每处理一个任务就开新会话。我习惯按任务切会话而不是一个会话里连续扔十几个任务。减少同时注册的 MCP server。不用的就不往配置里写因为工具定义是常驻 prompt 的少一个是一个。使用支持 Prompt Caching 的模型服务商重复的系统提示和工具定义可以命中缓存价格能低不少。4.4 长期使用配置建议速查表下面这张表是我目前跑下来比较顺手的配置参考不一定适合所有人但可以当起点项目建议理由调试阶段模型Ollama 或廉价 API 模型链路没通之前别用贵模型生产模型按任务选别一刀切简单任务用便宜模型复杂推理上强的MCP server 数量常用 2 到 3 个每个 server 都占 prompt 空间工具返回严格限制条数和长度减少 token 最直接有效的办法会话策略按任务开新会话防止历史把上下文滚爆日志级别生产环境 infodebug 仅在排查时开debug 会记录大量内容本身也吃资源用量监控定期导出账单核对避免事后才发现在狂烧5. 我踩过坑之后的几点体会给 OpenClaw 接 MCP 这件事技术上真正难的不是配协议而是建立“每次对话都有成本”的意识。我一开始只顾着把各种 MCP server 都怼上去文件系统、数据库、浏览器控制全接上结果两天下来 token 消耗比平时翻了快 5 倍而我自己在对话里根本没感觉到差别。后来我把工具数量砍到只剩两个最常用的又在每个工具返回结果那里加了裁剪逻辑会话也改成按任务重置消耗才降下来。我现在的习惯是每个月固定看一眼用量面板单独算一次 MCP 相关请求占了百分之多少。只要超过总用量的六成我就会警惕是不是上下文膨胀了。另外一个很实用的小技巧如果你有多个模型可用可以给 OpenClaw 配置“轻任务走便宜模型重任务走强模型”的路由。因为 MCP 工具调用有一部分是纯粹的结构化往返用便宜模型完成完全没问题只有最后的总结分析才需要更强的推理能力。这样搭配下来能用的能力一点没少开支却小了一大截。MCP 本身是个好东西它让本地 Agent 第一次有了真正意义上的“手和脚”。但工具越强越要会控制喂养给模型的“食量”。希望这篇记录能帮你少走几步弯路尤其是那些看不见的 token一定从一开始就盯着它们。