给 OpenClaw 接 MCP我发现每次对话都在偷偷烧token如果你最近在玩 OpenClaw或者正打算把一堆 MCP 工具接进去建议先看完这篇再动手。我是在本地把 OpenClaw 跑起来之后顺手接了三四个 MCP server刚开始觉得挺爽——查天气、读文档、操作数据库、调浏览器全都自动化了。直到某天我打开后台的 token 用量统计人直接愣住一个只有几十轮对话的日常会话居然烧掉了几十万 token。聊的内容不多钱却哗哗往外走问题的根源就是 MCP 工具本身在“偷偷烧token”。这篇文章不是单纯教你怎么给 OpenClaw 装 MCP而是想带你搞清楚一件事为什么接入 MCP 之后每次普通对话的 token 消耗都会肉眼可见地暴涨这些 token 到底烧在哪里有没有办法既保留工具能力又把成本压下来以下内容都来自我实际部署、实测和反复调优的过程适合已经装好 OpenClaw、正打算折腾 MCP 的开发者也适合被账号账单吓到、想搞清楚钱花到哪去的人。1. OpenClaw 的 MCP 接入到底做了什么1.1 OpenClaw 还不太像一个“产品”更像一个组装车间OpenClaw 本质上是一个开源的、本地部署的个人 AI 助手框架很多人拿它来复刻类 Claude 的桌面使用体验。它跟官方 App 最大的区别是你可以自由接模型、接工具、改系统提示词所有组件自己说了算。为了扩展能力OpenClaw 提供了两种方式一种是内置的 Skill直接写在项目里另一种就是接 MCP server把外部工具的能力统一代理进来。MCPModel Context Protocol你可以理解成“工具接口的 USB 口”。以前每个 AI 工具都要专门写一套插件协议适配成本很高MCP 出现以后大家约定好规格任何支持 MCP 的客户端都能一键挂载任意 MCP server。OpenClaw 在其中扮演客户端角色它通过 MCP 协议把外部能力接进对话流程让模型在需要时自动调用。我实际配置的时候用了非常标准的 MCP 客户端方式。OpenClaw 的配置入口是一个 JSON 文件里面声明你要挂载的每个 server不同系统的安装路径不大一样但结构是统一的。我用的配置片段大概长这样{ mcpServers: { filesystem: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, /Users/me/documents], env: {} }, github: { command: npx, args: [-y, modelcontextprotocol/server-github], env: { GITHUB_TOKEN: 你的token } } } }配置完重启 OpenClaw它启动时就会自动连接这些 server然后从每个 server 拉取一份“工具清单”。这份清单不是给你看的而是给模型看的——它会被塞进每次请求的系统提示词里。到这里MCP 的接入工作就算完成了表面上看一切都很顺但 token 的消耗陷阱也从这一刻开始埋下了。1.2 一个很容易被忽略的细节工具清单是“全量注入”的很多人以为 MCP 工具是你提到它的时候模型才去查实际不是。OpenClaw 在每次构造请求时会把所有已连接 MCP server 提供的工具定义、参数 schema、描述信息全部注入到系统提示词里。举个例子我只接了 filesystem 和 github 两个 server它们的工具定义加起来就有几十个。每个工具的描述、输入参数、格式说明折算成 token 大概是 8000~12000 token。这部分成本在你还一个字没打的时候就已经产生了。也就是说每次发起对话、每次让模型产生新回复底层请求里都包含这一坨“固定开销”。如果你把 MCP server 接得特别多——比如又加了数据库、浏览器、文档解析那情况就更夸张了。我后来数了数有个测试环境挂了 7 个 MCP server光工具清单就占了接近 3 万 token这个数字几乎等于某些小模型上下文窗口的十分之一。关键在于不管你当场用不用这些工具它们都会被带上场。2. “每次对话都在偷烧token”的底层机制拆解2.1 一次普通问答实际发生了两轮完整请求先明确一个概念AI 对话不像人脑所有记忆都要靠请求里的历史文本来承载。OpenClaw 接 MCP 之后一次你眼里的“普通问答”在底层可能拆成了至少两轮请求。第一轮你问“帮我看看项目目录结构”OpenClaw 把系统提示词含全部工具清单加上你的话发给模型。模型看到有 filesystem 工具可用决定调用它。这时候模型返回的不是最终答案而是一个“工具调用请求”格式是标准 function call。这一轮请求已经消耗了一次输入的 token。第二轮OpenClaw 收到调用请求后去执行真正的目录读取操作把结果比如一堆文件列表作为新消息追加到上下文里再次发送给模型。模型拿到结果后才开始写真正的回复。这一轮请求的输入里除了新工具结果还要带上前面全部内容——历史对话、第一次请求内容、完整工具清单。也就是说一次问答产生了两次完整请求的处理量token 就这么翻倍了。这就是为什么接完 MCP 以后你感觉聊天内容没变多但账单比之前涨了一截。MCP 不只是增加了可用工具它还改变了请求的交互模式从“一问一答”变成了“一问-工具调用-工具返回-生成答案”的链式结构。2.2 工具返回的数据会“赖在”上下文里不走如果说工具清单是固定成本那工具返回结果就是最不可控的变量。MCP server 返回的数据OpenClaw 默认会原样塞进对话历史。很多工具返回的东西非常“膨胀”尤其文件读取、网页抓取、数据库查询这类一次返回就是几千甚至上万 token。更麻烦的是这些返回结果不会因为你用完就消失。它们会作为历史消息一直留在上下文窗口里后续每一轮新请求都会把它们完整带上。你让 MCP 读了一次大文件可能后面十轮对话都在为这次读取买单。多轮对话结束后你回头统计真正的大头不是你的问题也不是模型的回答而是被工具“读进来”的那些原始数据。我做过一个统计某次会话总量 82000 token其中用户提问累计只有 6000 token助手回复累计 18000 token剩下的 58000 token 全是工具定义加工具返回结果。换句话说有 70% 的 token 花在了“模型根本不需要从头到尾都记着”的内容上这种烧法非常隐蔽也最值得警惕。2.3 模型每回复一句话都要重新“背一遍”全部对话当你知道这个机制以后就不会再被“聊得很短为什么花这么多”这个问题困扰了。根本原因是大模型的每次输出都必须把完整的上下文从头到尾读一遍。比如你发了 10 条消息每条 300 token累计 3000 token但模型生成了 5 次回复每次都要把 3000 token 当输入重新处理输入侧消耗就变成了 15000 token而不是 3000 token。这还没有算工具清单和工具返回的增量。接 MCP 以后这个效应被放大得更明显工具清单是固定大块工具返回结果越滚越大你的每一条新消息都背负着全部“历史包袱”。哪怕你只问了一个特别简单的问题底层账单也按全量上下文计算并且每生成一次回复就算一遍全量。所以“每次对话都在偷偷烧token”并不是错觉而是架构决定的必然现象。MCP 提升了自主性代价就是上下文变得臃肿而这个臃肿在每个输出 token 上都成倍放大了成本。3. 实测数据盘点我那一晚到底烧了多少token3.1 一个有参考价值的实测会话记录为了让你对数字有更直观的感受我贴一份自己当时记录的真实会话数据。那是一个很普通的晚上我让 OpenClaw 帮我做三件事查看本地某个文件夹的结构、在 GitHub 上找一个指定仓库的信息、然后根据这些内容简单总结一下。整个会话的主线用户消息只有几条每条 100~300 tokenOpenClaw 的回复也不算长。但最终账单上的数字吓我一跳。我把请求日志导出来整理了一下得到下表环节携带内容单次输入token次数累计token系统提示词工具清单角色设定约 9600多次约 48000用户消息我的问题约 300多个约 8000工具调用响应模型发起的 function call约 1000多个约 4000工具返回结果文件列表仓库信息约 4000多个约 16000助手最终回复模型生成的真实答案输出约 1600多个约 8000这里特别说明每个“环节”不是只算一次——对话轮次越多前面的内容越会被反复计入。例如系统提示词那 9600 token在每一轮请求里都会重新出现一次。一个看起来只有十几轮交互的会话顶层累计输入消耗达到 8 万多 token其中系统提示词和工具相关数据占了近八成。换算成费用高端模型上一次这种程度的闲聊就能顶普通订阅好几天的份额。3.2 怎么自己查“偷烧”的部分别卡在账单里猜要在存量问题上做到心里有数我建议你按下面三个步骤做一次自查。第一看请求日志OpenClaw 在 debug 模式下会打印每次请求的消息列表你可以从里面精确看到工具清单占了多少 token、工具结果占了多少 token。第二统计 usage 字段如果你用的模型 API 返回 usage 对象把它按 prompt_tokens、completion_tokens 拆开算一算比例。第三启用后台用量报表主流平台的控制台都能按会话、按天查看 token 消耗重点看“每会话 token 成本”和“每日 token 消耗”这两个指标。我自己写了一个很小的统计脚本用来把每次请求的消息条数和预估 token 数导出来import json def estimate_tokens(text): # 粗略估算中文按字符数折算 return int(len(str(text)) * 0.8 8) def analyze_log(log_path): with open(log_path, r, encodingutf-8) as f: logged json.load(f) total 0 breakdown {system: 0, user: 0, tool: 0, assistant: 0} for req in logged: for msg in req.get(messages, []): role msg.get(role, ) content msg.get(content, ) size estimate_tokens(content) total size if role in breakdown: breakdown[role] size print(f总消耗预估: {total} token) print(json.dumps(breakdown, indent2, ensure_asciiFalse)) if __name__ __main__: analyze_log(openclaw_log.json)这个脚本虽粗糙但能帮你在没有官方统计时快速摸清 token 到底花在哪个角色身上。如果发现 user 和 assistant 占比都很小、system 和 tool 占比奇高那基本就能锁定是 MCP 接入导致的额外烧费。4. 控制token消耗的优化手段与避坑经验4.1 第一优先级砍工具列表给工具定义“瘦身”既然 MCP 工具清单是固定开销那最直接的控制方式就是减少一次性挂载的 server 数量。我不建议把所有工具都常驻开启而是按“当前任务需要的才挂载”这个原则来配置。OpenClaw 支持在配置里对不同场景维护多份配置或者动态启用/禁用某个 server。实践下来比较舒服的做法是留一个“精简常驻”配置只挂最常用的三四个轻量 server需要做批量文件处理或者数据库操作的时候再临时开启专用的 MCP 配置。另外如果你用的是 OpenAI 或 Anthropic 系模型工具描述写得越短、参数 schema 越精简注入的固定 token 就越少。同一个工具描述从 100 词压到 30 词能省下不少固定消耗而且模型照样能理解。有朋友问过能不能让 OpenClaw“按需加载”MCP 工具只注入用户当前意图相关的工具目前版本的 OpenClaw 不支持细粒度懒加载工具的注入维度是 server 级别不是工具级别。你在社区里看到的一些插件或补丁能实现“动态筛选”但那些大多需要改 OpenClaw 源码稳定性要自己多测试。对绝大多数人来说从配置源头控制数量才是性价比最高的手段。4.2 第二优先级控制工具返回结果别让数据“赖着不走”工具返回结果的大小是你可控的而 MCP server 通常不会主动给你做压缩。我在这里分享几条实测有效的手段用“精确参数代替模糊请求”例如调用 filesystem 时尽量指定子目录或具体文件而不是把整个根目录读一遍调用数据库时放在 SQL 里加 LIMIT只取前几十条。让模型在调用工具前先确认目标在系统提示词里写清楚规则比如“读取文件前先判断大小超过 1MB 先列出前 100 行”。虽然这会增加一点系统提示词长度但能大幅减少工具返回的膨胀量。对工具返回做截断或摘要某些 MCP server 支持自定义输出配置比如返回字段数、返回行数限制。如果 server 不支持可以自己写一个中间代理层把过大的返回结果截短后再交给 OpenClaw。我自己的习惯是给 OpenClaw 的系统提示词里加一句“当你调用工具后如果确认结果已经满足需求就不要再重复返回大段原始内容。”这句话看着不起眼实际能有效阻止模型在后续轮次里反复引用工具结果。4.3 第三优先级利用上下文窗口管理机制主动“清理”对话历史OpenClaw 本身有一些上下文管理相关的配置你需要认真看一遍。最重要的参数是历史消息保留轮数或上下文最大 token 阈值。合理设置这两个值能让它在大堆工具结果占满上下文之前自动截断最早的历史消息。不过这里有个坑有些项目对“最早消息”的判定是粗暴的可能把关键系统提示词或工具定义也一起截掉导致模型失忆甚至调用出错。我在实测里遇到过类似问题——调低历史保留轮数之后工具调用中断、模型开始胡编文件路径。后来我把配置改成“只裁剪很早的普通对话消息保留系统提示词和最近工具结果”情况才稳定下来。如果你用的是支持 prompt caching 的模型服务商记得主动声明可缓存的系统提示词部分。有些商家对命中缓存的内容按半价甚至更低计费而 MCP 工具清单这种每轮都重复的内容恰恰是缓存收益最明显的场景。虽然各家模型商的服务条款和接口字段不同但“尽量让系统提示词固定不变、不要每轮动态改一点”这个原则是通用的。系统提示词每次都变缓存就失效保持稳定命中日积月累能省不少。4.4 常见的隐性烧费场景与避坑清单最后整理几个我在实际使用过程中踩过或观察到的隐性烧费场景这些情况在日志里特别难发现但它带来的成本增幅非常大。场景原因应对措施模型反复调用失败工具工具报错后模型会不断重试每次重试都是一轮完整请求给工具调用设置最大重试次数超时立即放弃检查 MCP server 日志循环调用工具导致上下蔓延模型被“工具可用”诱惑思考时反复切换工具系统提示词里限制每个任务最多调用 2~3 次工具工具返回内容被原样无限保存大文件被读进上下文后再也不清理用专用 MCP server 或脚本对大文件做摘要后再回填多会话并行共用同一份长上下文后台任务和聊天任务互相污染给不同任务建不同会话及时 clear 上下文这些场景有一个共同点它们都不是因为你“聊太多”而烧钱而是因为请求结构设计不合理。只要把这几个点控制住就算继续开着 MCP日常对话的 token 成本也能压回比较健康的范围。5. 经过这番折腾我留下的几条个人使用经验折腾了这么一圈我的结论不是“MCP 不能接”而是“接了以后不能再沿用裸聊天的习惯期待成本不变”。OpenClaw 让我深刻体会到一件事工具越强大上下文就越沉重——模型的每一次回复都在为它能看到的所有工具和数据支付全量费用。我自己现在养成的习惯是这样日常使用只开两三个核心 MCP server比如文件读写和代码搜索真正要做专项任务才单独开一个载入更多 server 的配置会话开久了主动清理上下文而不是让历史无限滚下去另外每个月固定翻一次平台的 token 用量按会话维度排查异常。这套做法跑了一段时间我把日均 token 成本压到了优化前的三分之一左右功能上暂时也没觉得缺什么。如果你也遇到“没聊几句但 token 飙得飞快”的情况先别急着怀疑 MCP 或 OpenClaw按上面这套逻辑把账算一遍系统提示词占多少、工具结果占多少、历史裁剪策略是否生效。绝大多数问题都出在这三个环节里。工具本身是免费的但每次调用、每段返回结果、每轮完整请求都在量化为真实成本想真正用好 Agent就得学会管理它的“记忆”而不是纵容它无限堆积。