1. 从一次账单异常说起OpenClaw 接 MCP 的 token 消耗真相第一次发现不对劲是月底翻 API 账单的时候。我明明只是拿 OpenClaw 做几个日常的代码问答和文档整理结果 token 用量比上个月翻了将近三倍。当时第一反应是模型调用变多了但仔细一查日志发现真正的问题出在我给它接上 MCP 之后——每次对话都在偷偷烧 token而且烧得毫无知觉。这个现象其实不是 OpenClaw 独有的。任何支持 MCPModel Context Protocol的 Agent 框架只要工具链配置不当都会出现类似的隐形消耗。MCP 本身是个好东西它让模型能调用外部工具、读取本地文件、连接数据库把 OpenClaw 从一个聊天机器人变成真正能干活的生产力工具。但问题在于MCP 的每一次工具调用、每一份工具描述、每一轮上下文回传都是要计入 token 的而且很多消耗发生在你看不见的地方。这篇文章我想聊的就是这件事OpenClaw 接入 MCP 之后token 到底被谁吃掉了怎么定位怎么优化。适合已经在用 OpenClaw、或者正准备给它接 MCP 工具链的朋友。如果你只是拿它做纯对话那影响不大但只要你挂了三个以上的 MCP Server这篇文章大概率能帮你把账单砍掉一半。先说结论省得你往下翻token 消耗的大头不在你的提问而在工具描述注入、工具返回结果、以及多轮对话里被反复重放的上下文。这三块加起来能占到总消耗的 70% 以上。下面我一块一块拆。2. MCP 到底在背后做了什么token 消耗的四个隐形出口2.1 工具描述注入每次请求都在重发说明书MCP 的工作机制简单说就是 OpenClaw 在每次向模型发请求时会把当前挂载的所有 MCP 工具的描述name、description、input schema一并塞进 system prompt 或者 tools 字段里。这是协议要求模型必须知道有哪些工具可用、每个工具要传什么参数。问题就在这儿。假设你挂了 5 个 MCP Server每个 Server 暴露 8 个工具那就是 40 个工具。每个工具的描述加上 JSON Schema保守估计 150 到 400 token。40 个工具就是 6000 到 16000 token而且这是每一次请求都要重发的。我实测过一组数据用 OpenClaw 挂载 filesystem、git、sqlite 三个官方 MCP Server工具总数 23 个光工具描述部分就稳定占用 4200 左右的 input token。你问一句今天天气怎么样这 4200 token 照样得付钱。注意工具描述是固定开销跟你的问题长短无关。挂的工具越多这个底噪越高。很多人以为自己只是问了个短问题实际上每次都在为整套工具链买单。2.2 工具返回结果原始数据直接灌进上下文第二个出口是工具调用的返回值。比如你让 OpenClaw 读一个文件MCP 的 filesystem server 会把整个文件内容返回。如果这个文件是 3000 行的日志那就是几万 token 直接进上下文。再比如查数据库一个SELECT *返回 500 行同样全量灌进去。这里最坑的是很多 MCP Server 默认不做截断、不做摘要返回什么就塞什么。模型拿到这一大坨还得再生成一遍回答output token 也跟着涨。我见过最夸张的一次一个 git log 查询返回了 800 条 commit 记录单次调用吃掉 6 万多 token。2.3 多轮对话的上下文重放历史越滚越大第三个出口比较隐蔽。OpenClaw 默认会把整个对话历史带上包括之前所有轮次的工具调用请求和返回结果。也就是说第一轮你读了个大文件第二轮、第三轮、第四轮……这个文件内容会一直被重放直到对话结束或者触发上下文裁剪。这就形成了一个恶性循环工具返回越大 → 历史越长 → 后续每轮重放越贵 → 你越不敢开新对话 → 历史继续滚。我见过有人一个会话跑了 40 多轮后面每问一句都要重放前面几十万 token 的历史。2.4 工具选择阶段的试探性调用第四个出口跟模型行为有关。当工具很多、描述又相似时模型经常会出现试探性调用——先调一个看看返回啥不对再调另一个。这种来回试探每次都是一轮完整的请求加返回。工具描述写得越模糊这种浪费越严重。把这四个出口列个表你就能直观看到钱花在哪了消耗出口触发时机典型占比可控性工具描述注入每次请求20%~35%高可裁剪工具返回结果每次工具调用30%~50%高可截断上下文重放多轮对话15%~30%中可靠策略试探性调用工具选择5%~15%中靠描述优化3. 定位问题先搞清楚你的 token 到底花在哪3.1 打开 OpenClaw 的请求日志优化之前必须先测量不然就是瞎调。OpenClaw 的配置里一般有日志级别选项把它调到 debug 或者 verbose能看到每次请求的完整 payload。重点看三个字段tools数组的长度、messages数组的总字符数、以及单次请求的 input/output token 统计。如果你用的是带用量统计的 API 端点直接在返回里看usage字段最准。我习惯把每次请求的 usage 记到一个本地 CSV 里跑一天下来做个透视哪个环节吃得多一目了然。3.2 用空对话测底噪有个特别简单的办法测固定开销开一个全新会话什么都不问只发一个hi。看这次请求的 input token 是多少。这个数字基本就是你的工具描述底噪。我测下来挂 3 个 Server 大概 4000 出头挂 8 个 Server 能到 12000 以上。如果这个底噪超过 8000说明你的工具链该瘦身了。正常生产环境我建议把底噪控制在 5000 以内。3.3 给工具调用打标记在 OpenClaw 的 MCP 配置里可以给每个 Server 加个标签然后在日志里区分。这样你就能知道是哪个 Server 的返回最占地方。我一般会重点关注三类工具文件读取类、数据库查询类、以及任何返回列表的工具。这三类是 token 大户。3.4 一个真实的排查案例上周帮朋友看他的 OpenClaw 配置账单一个月 200 多刀。我让他先跑空对话测底噪结果是 11000 token。再一看他挂了 9 个 MCP Server其中有个网页抓取工具描述写了 800 多字光这一个工具就占 1200 token。然后看工具返回他经常让 OpenClaw 抓网页返回的是完整 HTML一次 3 万 token 起步。最后看对话轮数平均每个会话 25 轮历史重放占了大头。三处一改砍掉 4 个不常用的 Server、给抓取工具加了 HTML 转 Markdown 的预处理、会话超过 10 轮就开新的。第二个月账单降到 60 多刀。同样的活四分之一的钱。4. 实操优化把 token 消耗砍下来的六个动作4.1 工具瘦身只挂当前任务需要的 Server这是最直接有效的一招。OpenClaw 支持按会话或者按项目动态加载 MCP Server不要图省事把所有 Server 一直挂着。我的做法是按场景分组。写代码的时候只挂 filesystem、git、shell 三个查资料的时候只挂 fetch、search做数据分析的时候才挂 sqlite、pandas。每组控制在 3 到 5 个 Server工具总数不超过 20 个。具体配置上OpenClaw 的 MCP 配置一般长这样{ mcpServers: { filesystem: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, /path/to/workspace] }, git: { command: uvx, args: [mcp-server-git, --repository, /path/to/repo] } } }把不用的 Server 从这段配置里删掉或者拆成多个配置文件按需切换。别小看这一步砍掉一半 Server底噪直接降一半。4.2 精简工具描述自己写比默认的更省很多 MCP Server 自带的工具描述又臭又长动不动就写一大段使用说明。这些描述每次请求都要重发纯属浪费。OpenClaw 一般允许你覆盖工具描述。把那些啰嗦的说明删掉只保留工具名、一句话功能、参数列表。参数说明能省则省模型看 schema 基本能懂。举个例子某个默认描述是这样的This tool allows you to read the contents of a file from the filesystem. You should provide the absolute path to the file. The tool will return the full contents of the file as a string. Be careful with large files as they may consume significant tokens...精简后Read file content. Args: path (absolute).从 60 多个 token 压到 10 个以内。40 个工具这么一改底噪能省 2000 多 token。4.3 工具返回截断在 MCP 层做别等模型这是省钱的关键。工具返回的大块数据一定要在进入上下文之前处理掉。有两个层面可以做第一层MCP Server 侧配置。很多 Server 支持maxResults、maxBytes之类的参数。比如 filesystem server 可以限制单次读取的行数git server 可以限制 log 条数。把这些参数调小默认值往往太宽松。第二层加一个中间处理。如果 Server 不支持截断可以在 OpenClaw 和 Server 之间加个代理对返回内容做预处理。比如 HTML 转 Markdown、JSON 只保留关键字段、长文本做摘要。我常用的一个模式是让工具返回结构化摘要而不是原始数据。比如查数据库不返回 500 行明细而是返回共 500 行前 10 行如下字段分布为……。模型拿到摘要照样能回答token 省 90%。4.4 上下文管理该断就断该裁就裁多轮对话的历史重放是隐形杀手。OpenClaw 的上下文策略要配好设置最大轮数超过 N 轮自动开新会话N 建议 10 到 15。设置上下文窗口上限超过就触发裁剪优先保留最近的对话和系统提示。工具结果不进历史有些框架支持把工具返回标记为临时用完即弃不参与后续重放。这个功能一定要开。如果 OpenClaw 版本支持工具结果摘要化把大的工具返回替换成一句话摘要再存进历史效果立竿见影。4.5 工具描述去重相似工具合并如果你挂了多个功能重叠的 Server比如两个都能读文件、两个都能查网页模型会犯迷糊来回试探。把功能重叠的工具合并成一个或者只保留一个。我见过有人同时挂了三个搜索类 MCP结果模型每次搜索都要试两三次才选对。合并成一个之后试探性调用基本消失。4.6 用便宜模型做工具选择贵模型做生成这是个进阶技巧。工具选择阶段决定调哪个工具、传什么参数其实不需要太强的模型用个小模型就够。OpenClaw 如果支持分阶段指定模型把工具选择交给便宜模型最终回答交给强模型成本能再降一截。不过这个要看框架支持程度不是所有版本都能这么配。如果你的 OpenClaw 支持值得一试。5. 常见问题与排查速查表5.1 为什么我什么都没问token 也在涨大概率是后台有心跳或者自动任务在跑。检查 OpenClaw 有没有配置定时任务、有没有 Server 在主动推送。另外确认一下是不是有多个会话并行每个会话都在独立计费。5.2 工具调用失败会不会也烧 token会。失败的调用同样消耗了请求的 input token而且模型可能重试。如果某个工具频繁失败赶紧修别让它一直空转。5.3 上下文裁剪会不会导致模型失忆会但这是必要的取舍。我的经验是把关键信息比如任务目标、已确认的结论显式写进 system prompt 或者一个记忆文件让它在裁剪后依然保留。别指望模型自己记住。5.4 怎么判断是工具描述贵还是工具返回贵跑两个测试空对话测底噪工具描述单次工具调用测返回。两个数字一对比就知道该优化哪边。一般来说工具多的场景描述贵数据密集的场景返回贵。5.5 速查表现象可能原因排查动作解决方向空对话 token 高工具描述过多数工具数量、看描述长度瘦身 Server、精简描述单次调用 token 暴涨工具返回过大看返回内容大小截断、摘要、预处理越聊越贵历史重放看会话轮数限制轮数、裁剪上下文反复调用同一工具描述模糊或重叠看调用日志优化描述、合并工具账单与预期不符多会话并行看并发会话数收敛会话、按需加载5.6 几个我踩过的坑第一个坑以为工具描述不算钱。早期我挂了一堆 Server 图方便结果底噪比我的问题还贵。后来才明白工具描述是每次请求的固定税。第二个坑让工具返回原始数据。有次让 OpenClaw 读一个 2 万行的 CSV直接爆上下文那一轮花了 8 万多 token。后来改成先读表头和前 100 行需要再翻页成本降了 95%。第三个坑一个会话聊到底。以前觉得开新会话会丢上下文其实把关键结论存成文件新会话读一下就行比一直重放历史便宜太多。第四个坑忽略失败重试。有个 MCP Server 配置错了路径每次调用都失败模型还傻乎乎重试三次。修好之前每次对话都白烧几千 token。6. 一套可复用的 OpenClaw MCP 省 token 配置模板把上面的经验固化下来我现在的标准配置是这样的。你可以直接抄按自己情况微调。Server 分组按任务类型分三组每组不超过 4 个 Server工具总数控制在 15 个以内。切换任务时换配置不用的坚决不挂。描述精简所有工具描述压到 20 token 以内只留功能一句话加参数名。schema 保留说明删掉。返回截断所有列表类工具默认限制 20 条文本类工具默认限制 2000 字符超出部分返回摘要加如需更多请指定范围。上下文策略最大 12 轮超过自动开新会话工具结果标记为临时不参与历史重放system prompt 里维护一个任务记忆区块存关键结论。监控每次请求记录 usage每周做一次透视看哪个环节占比异常。这套配置跑下来我日常使用的 token 消耗比最初降了大概 65%。同样的工作量账单从每月 150 刀左右降到 50 刀出头。最后分享一个我最近在用的技巧给 OpenClaw 加一个成本感知的 system prompt明确告诉它工具调用有成本优先用最少调用完成任务返回结果尽量精简。别小看这句话模型真的会因此少调几次工具、少返回一堆废话。实测下来光这一句提示词就能再省 10% 左右。MCP 让 OpenClaw 变强但强是有代价的。搞清楚代价花在哪才能既享受能力又不被账单追着跑。