1. 从一次账单异常说起OpenClaw 接 MCP 的 token 消耗陷阱前阵子我把 OpenClaw 接上了 MCPModel Context Protocol本意是想让它能直接调用本地文件系统、数据库和一些内部工具省去每次手动复制粘贴的麻烦。配置过程挺顺利工具也确实跑起来了但月底一看 API 账单我愣住了——用量比平时翻了将近三倍而我实际的对话次数并没有明显增加。这个现象不是个例。我在几个开发者社群里问了一圈发现不少人在 OpenClaw 上接入 MCP 之后都遇到了类似情况对话轮次没变但 token 用量悄悄涨上去了。问题出在哪简单说MCP 的工具描述、工具调用结果、以及每一轮对话中重复携带的上下文都在持续消耗 token而很多人根本没意识到这部分开销的存在。这篇文章就是把我排查和优化这个问题的完整过程整理出来。不管你是刚接触 OpenClaw 和 MCP 的新手还是已经在用但没注意过 token 消耗的老用户都能从里面找到可以直接落地的优化方案。我会从 MCP 的工作原理讲起拆解 token 到底烧在了哪里然后给出具体的配置调整和实操步骤最后附上我踩过的坑和排查技巧。2. MCP 到底是什么先搞懂它在 OpenClaw 里干了什么2.1 用生活化类比理解 MCP 的角色MCP 全称 Model Context Protocol你可以把它理解成 OpenClaw 和外部工具之间的“翻译官加调度员”。没有 MCP 的时候OpenClaw 只能靠自己的知识回答问题或者你手动把数据喂给它。有了 MCPOpenClaw 就能通过一套标准协议去调用外部工具——比如读文件、查数据库、调 API、操作浏览器等等。打个比方OpenClaw 是一个很聪明但只待在办公室里的顾问MCP 就是给他配了一部电话和一本通讯录。顾问需要什么信息就照着通讯录打电话给对应的部门部门把结果告诉他他再继续思考。听起来很美好但问题在于——每一次打电话通讯录的内容、通话的内容、对方的回复全都要记录在顾问的工作日志里而这个日志是按字数收费的。2.2 MCP 在 OpenClaw 中的工作流程具体到 OpenClaw 的运行机制一次带 MCP 的对话大致经历这几个阶段工具注册阶段OpenClaw 启动时会读取所有已配置的 MCP Server把每个 Server 提供的工具名称、功能描述、参数 schema 全部加载进来。这部分内容会作为系统提示的一部分每一轮对话都要重新发送给模型。意图识别阶段你发一句话OpenClaw 把这句话连同所有工具描述一起发给模型模型判断是否需要调用工具、调用哪个工具、传什么参数。工具调用阶段模型返回工具调用指令OpenClaw 执行对应的 MCP 工具拿到返回结果。结果整合阶段工具返回的结果被追加到对话历史中再次发给模型模型基于结果生成最终回复。关键点在于第 1 步和第 4 步。工具描述是固定开销每轮都发工具返回结果如果很大比如读了一个大文件、查了一堆数据库记录那这部分内容也会进入上下文后续每一轮对话都会带着它。2.3 为什么 token 消耗会“偷偷”涨上去很多人以为 token 消耗只跟自己输入的文字和模型输出的文字有关但实际上在 OpenClaw MCP 的场景下token 消耗来自四个部分消耗来源是否每轮重复典型大小系统提示 工具描述是500-3000 token用户输入否几十到几百 token工具调用参数否几十到几百 token工具返回结果是进入历史后几百到几万 token最容易被忽视的就是第一项和第四项。如果你接了五六个 MCP Server每个 Server 提供十几个工具光工具描述就能轻松超过 2000 token。而如果某个工具返回了一个 5000 字的文件内容这 5000 字会一直留在对话历史里后面每问一句都要重新计费一次。3. 拆解 token 消耗到底烧在了哪些环节3.1 工具描述看不见的固定开销我拿自己的配置做了一次实测。在 OpenClaw 中接入三个 MCP Server文件系统、SQLite 数据库、和一个内部 API 网关。用 OpenClaw 自带的 token 统计功能如果没有可以通过 API 返回的 usage 字段查看得到这样一组数据纯对话不接 MCP系统提示约 300 token接入三个 MCP Server 后系统提示 工具描述约 2800 token也就是说每轮对话还没开始干活就已经烧掉了 2800 token。如果一天对话 100 轮光工具描述就消耗 28 万 token。按主流模型的定价这笔开销一个月下来相当可观。更麻烦的是很多 MCP Server 的工具描述写得非常冗长。比如某个数据库工具的描述是“This tool allows you to execute SQL queries against the connected SQLite database. It supports SELECT, INSERT, UPDATE, DELETE statements. The query parameter should be a valid SQL string. Returns the query results as a JSON array.” 这段话本身就有 50 多个 token而实际上模型只需要知道“执行 SQL 查询”就够了。3.2 工具返回结果滚雪球式的上下文膨胀工具返回结果是另一个大头。我遇到过一次典型情况让 OpenClaw 通过 MCP 读取一个配置文件文件大概 3000 字。读完之后我接着问了几个跟这个文件相关的问题。结果每一轮对话那 3000 字的文件内容都在上下文里重新发送一遍。假设文件内容 3000 token后续问了 5 个问题那就是 3000 × 5 15000 token 的额外消耗。如果读的是一个更大的文件比如日志文件或者数据导出这个数字会成倍增长。这里有个容易被忽略的细节OpenClaw 默认会把完整的工具返回结果保留在对话历史中即使后续对话已经不需要这个结果了。它不会自动做上下文压缩或结果摘要。3.3 多轮对话中的重复携带OpenClaw 的对话机制是每次请求都把完整的对话历史发给模型。这意味着第 1 轮系统提示 工具描述 用户输入第 2 轮系统提示 工具描述 第 1 轮全部内容 新输入第 3 轮系统提示 工具描述 第 1、2 轮全部内容 新输入……对话轮次越多历史越长每轮消耗的 token 就越多。如果中间还穿插了工具调用和大量返回结果膨胀速度会更快。这就是为什么很多人感觉“明明没聊几句token 就没了”。3.4 一个真实的消耗测算我拿一次实际对话做了完整测算。任务很简单让 OpenClaw 通过 MCP 读取一个项目目录下的所有 Python 文件统计代码行数然后生成一份简要报告。环节token 消耗系统提示 工具描述2800用户输入50第一次工具调用列目录120目录返回结果800第二次工具调用读文件1150文件1内容返回2200第三次工具调用读文件2150文件2内容返回1800第四次工具调用读文件3150文件3内容返回2500最终生成报告600合计约 11320 token而如果我不通过 MCP而是手动把文件内容整理好一次性发给 OpenClaw消耗大概只有 4000 token 左右。差距主要来自工具描述的固定开销和多次工具调用的往返。4. 实操优化把 token 消耗压下来的具体方案4.1 精简 MCP Server只留必要的工具第一步是做减法。我检查了自己配置的所有 MCP Server发现有几个其实很少用到但它们的工具描述一直在消耗 token。具体操作打开 OpenClaw 的 MCP 配置文件通常在~/.openclaw/mcp.json或项目目录下的mcp.config.json。列出所有已配置的 Server逐个评估最近一周的使用频率。把使用频率低的 Server 注释掉或移除。{ mcpServers: { filesystem: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, /path/to/project] }, sqlite: { command: npx, args: [-y, modelcontextprotocol/server-sqlite, /path/to/db.sqlite] } } }注意移除 Server 之前先确认没有其他流程依赖它。我有一次把数据库 Server 关了结果第二天跑自动化脚本时直接报错排查了半天才想起来是自己关的。4.2 给工具描述“瘦身”很多 MCP Server 的工具描述是开发者写死的但 OpenClaw 支持在配置层面对工具描述做覆盖或过滤。具体做法是在 MCP 配置中增加toolOverrides字段不同版本的 OpenClaw 可能字段名不同以官方文档为准{ mcpServers: { filesystem: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, /path/to/project], toolOverrides: { read_file: { description: 读取指定路径的文件内容 }, list_directory: { description: 列出目录下的文件 } } } } }把原本几十个 token 的描述压缩到十几个 token十几个工具加起来就能省下几百 token。虽然单次看起来不多但乘以对话轮次之后差距很明显。如果 OpenClaw 版本不支持 toolOverrides另一个办法是直接修改 MCP Server 的源码或使用社区维护的精简版 Server。我自己fork了一个文件系统 Server把工具描述全部改成了中文短句token 消耗直接降了 40%。4.3 控制工具返回结果的大小工具返回结果是 token 消耗的大头必须加以控制。我的做法是在 MCP Server 层面做截断和摘要文件读取限制单次读取的最大行数或字符数比如最多返回 200 行超出部分提示“文件过长已截断”。数据库查询强制加 LIMIT默认最多返回 50 条记录。API 调用只返回关键字段过滤掉冗余的元数据。以文件系统 Server 为例可以在启动参数中加一个环境变量来控制MCP_FS_MAX_LINES200 npx -y modelcontextprotocol/server-filesystem /path/to/project然后在 Server 代码中读取这个环境变量对返回内容做截断。如果你用的是现成的 Server 不支持这个参数可以考虑自己写一个简单的包装层。实操心得截断阈值不要设得太小否则模型拿不到足够信息会反复调用工具反而增加往返次数。我的经验是文件类 200-500 行、数据库 30-50 条比较合适具体看任务类型。4.4 及时清理对话历史OpenClaw 本身提供了一些对话管理功能但默认行为是保留完整历史。我建议在以下几种情况下主动开启新对话完成一个独立任务后不要在同一对话里继续问不相关的问题。工具返回了大量内容且已经处理完毕后续不再需要时。对话轮次超过 20 轮时考虑总结一下关键信息然后开新对话。如果 OpenClaw 版本支持自动摘要功能可以开启它。原理是当对话历史超过一定长度时自动把前面的内容压缩成摘要减少后续请求的 token 量。配置方式一般是在设置中开启autoSummarize并设置触发阈值{ conversation: { autoSummarize: true, summarizeThreshold: 15, maxHistoryTokens: 8000 } }4.5 用流式输出减少等待和重试虽然流式输出本身不直接减少 token 消耗但它能降低因超时导致的重试概率。OpenClaw 在等待 MCP 工具返回时如果超时可能会重新发起请求造成额外的 token 消耗。开启流式输出后模型可以边生成边返回减少整体响应时间。在 OpenClaw 配置中开启流式输出{ model: { stream: true } }另外合理设置超时时间也很重要。MCP 工具调用超时设得太短会导致频繁重试设得太长又会让用户等太久。我的经验值是文件操作 10 秒、数据库查询 15 秒、网络请求 30 秒。5. 常见问题与排查技巧实录5.1 token 用量突然暴涨怎么排查遇到 token 用量异常我一般按这个顺序排查看工具描述总量在 OpenClaw 启动日志中查找工具注册信息统计所有工具描述的总 token 数。如果超过 3000说明 Server 接太多了。看单次工具返回大小在对话日志中搜索工具返回结果看看有没有特别大的返回。超过 2000 token 的返回就要警惕。看对话轮次统计平均每个任务的对话轮次。如果超过 15 轮说明可能存在反复调用工具的情况。看是否有重试检查日志中是否有超时重试记录每次重试都会重新发送完整上下文。5.2 工具调用失败导致的额外消耗MCP 工具调用失败时OpenClaw 通常会把错误信息返回给模型模型可能会尝试重新调用或者换一种方式调用。这个过程会产生额外的 token 消耗。常见失败原因和解决方法问题现象可能原因解决方法工具调用超时网络慢或工具执行时间长增加超时时间优化工具性能参数格式错误模型生成的参数不符合 schema简化参数 schema减少必填项权限不足MCP Server 没有对应权限检查文件权限或 API 密钥Server 未启动配置错误或进程崩溃检查 MCP Server 日志确认进程状态避坑技巧给 MCP Server 加上健康检查在 OpenClaw 启动时自动检测 Server 是否可用。不可用的 Server 直接跳过注册避免模型调用时才发现问题。5.3 不同 MCP Server 的 token 效率对比我实测了几个常用 MCP Server 的 token 效率供参考Server 类型工具数量工具描述 token典型返回 token效率评价文件系统官方11约 1200500-5000描述偏长建议精简SQLite官方6约 800200-3000描述适中需加 LIMIT浏览器社区版15约 20001000-8000描述冗长返回巨大自定义 API 网关3约 300100-500效率最高推荐自建从表里可以看出自建精简版 MCP Server 的 token 效率远高于通用 Server。如果你的使用场景比较固定强烈建议自己写一个只包含必要工具的 Server。5.4 一个容易被忽略的细节工具调用参数模型生成工具调用参数时也会消耗 token。如果参数 schema 很复杂模型需要生成很长的 JSON这部分也是要计费的。简化参数 schema 不仅能减少生成消耗还能降低出错概率。比如一个查询工具原本的 schema 要求传table_name、columns、where_clause、order_by、limit、offset六个参数模型每次都要生成一大段 JSON。改成只传一个query参数让模型直接写 SQL生成消耗能减少一半以上。6. 我的最终配置方案和效果对比经过上面这一轮优化我的 OpenClaw MCP 配置变成了这样MCP Server 从 5 个精简到 2 个文件系统 自建 API 网关工具描述从约 4500 token 压缩到约 900 token文件读取限制 300 行数据库查询限制 30 条开启自动摘要阈值设为 15 轮超时时间按工具类型分别设置优化前后的对比指标优化前优化后降幅单轮基础消耗2800 token900 token68%典型任务总消耗11000 token4200 token62%日均消耗100 轮约 28 万 token约 9 万 token68%这个降幅对我来说已经非常满意了。当然具体数字会因使用场景不同而有差异但优化思路是通用的减少工具数量、精简工具描述、控制返回大小、及时清理历史。最后分享一个我最近才发现的技巧OpenClaw 的某些版本支持在对话中动态启用/禁用 MCP 工具。也就是说你可以在不需要工具的时候把它关掉需要的时候再打开。这样在纯聊天场景下就不会有工具描述的固定开销。具体命令是/mcp disable server-name和/mcp enable server-name如果你的版本支持强烈建议用起来。