OpenClaw接入MCP后token暴涨？三步优化省70%成本-平芜编程栈

给 OpenClaw 接上 MCP 之后，我发现自己和它的每一次对话，其实都在偷偷烧 token。原本以为只是加了几个工具接口，没想到月底一查 API 账单，数字比想象中高出好几倍。这篇文章不聊高大上的架构，就聊聊我踩过的坑、怎么分析 token 消耗，以及最终如何把一个动辄上万 token 的 MCP 会话压到三分之一以内。如果你刚接触 OpenClaw，或者正准备接 MCP，这里面的计算方法和优化思路应该能让你少花不少冤枉钱。

1. OpenClaw 与 MCP 为什么这么费 token

1.1 OpenClaw 是什么？为什么大家都开始接 MCP

OpenClaw 是我最近大半年主力在用的开源 AI 代理框架。它和普通聊天机器人最大的区别在于，不只是“回复你”，而是能把一句话拆解成多个动作：查数据库、读文件、调用接口、操作浏览器，最后再把结果汇总成自然语言回复。OpenClaw 天生支持 skill（技能包）和 agent（子代理），但真正让它火起来的，是它把 MCP 作为官方推荐的扩展协议。

MCP 的全称是 Model Context Protocol，直译是模型上下文协议，最初由 Anthropic 提出，后来变成一套开放标准。它解决的问题很直接：不同工具之间接口五花八门，AI 模型不可能为每个工具单独写适配器。通过 MCP，工具以统一的方式暴露成“工具清单 + 调用接口”，模型只需按标准格式请求工具即可。你可以在 OpenClaw 里配置一个 MCP server，比如数据库 server、浏览器 server，它们在运行时动态加载给模型。

那么，MCP 为什么会成为 token 消耗大户？关键在于 MCP 的“工具列表”不是按需加载到上下文的，而是每一轮对话都会整体拷贝给模型。这就好比你去餐厅，服务员每次点菜前都要把几十页菜单全文背一遍，哪怕你只点一个菜。OpenClaw 的上下文里装着所有已连接 MCP 的工具定义，每个工具包括名称、描述、参数 JSON Schema，加起来常常是好几千 token。这个开销是隐性的：你表面上是聊了一句话，实际支付的是整本菜单的阅读费。

1.2 一次普通对话到底消耗了多少 token

我拿自己实际使用的一个场景来说明。我在 OpenClaw 里接了两个 MCP server：一个 PostgreSQL 数据库操作，一个 Playwright 浏览器自动化。某天我问它：“帮我查一下上个月订单最多的前 5 个客户，并打开他们公司的官网看一眼。”

这条指令看起来很简单，但实际请求过程是这样的：

OpenClaw 先构造系统提示词（包括角色设定、回答风格、技能说明），大概 1500 token；
然后附加两个 MCP server 的工具定义。Postgres MCP 默认提供 20 来个工具，每个工具的描述和参数 schema 加起来约 2500 token；Playwright MCP 也类似，占 2200 token；
接着是历史对话（如果之前有过几轮），算 500 token；
最后是用户新输入，80 token；
模型第一次响应会生成一个函数调用计划，输出约 300 token；

然后执行工具：查询数据库的工具返回了 200 行记录（限制 10 行后返回 10 行），工具返回结果格式化后约 1200 token；浏览器工具抓了网页标题、截图和正文摘要，约 2500 token。这些工具返回结果又会被拼接到上下文中，继续发给模型做第二次推理。

所以一次问答实际产生的 token 大约是：输入部分 1500 + 2500 + 2200 + 500 + 80 + 300 = 7080，输出部分 1200 + 2500 + 1000 = 4700，合计接近 12000 token。其中真正和用户问题相关的可能只有 80 token，其他全是“菜单”和“原料”。这就是很多人第一次接完 MCP 后感叹“怎么什么都没干，额度就没了”的原因。

2. 接入 MCP 前，先学会算 token

2.1 分清三类 token：输入、输出、缓存

在 OpenClaw 的日志里，你会看到类似usage: {prompt_tokens: 8400, completion_tokens: 1200, total_tokens: 9600}的信息。这里 prompt_tokens 就是前面说的输入 token，它包含系统提示、工具 schema、历史消息、用户消息，以及每次工具返回后被拼接到上下文里的新内容。completion_tokens 是模型生成的部分，包括思考过程、函数调用参数、最终文本。另外还有一个经常被忽略的 cached_tokens——这是部分 API 服务提供的缓存机制，比如 Anthropic 的 prompt caching，命中缓存的部分按更低单价计费，甚至免费。

很多人在统计消耗时只看 total_tokens，却不区分输入和输出，这是不对的。因为输出 token 单价通常是输入的三到五倍。一个工具返回 1000 token，模型再根据这 1000 token 生成 200 token 的总结，计费是按 1000 输入 + 200 输出算的，不是按 1200 平均算。

OpenClaw 自身有 token 估算模块，在配置里可以设置 model_max_tokens 和 max_tokens。但这些参数只控制生成长度，并不能减少工具 schema 带来的输入 token。想要真正降低成本，得从输入侧下手。

2.2 怎么快速估算一次 MCP 调用的成本

先给公式：单次对话成本 = (输入 token 数 / 1M) * 输入单价 + (输出 token 数 / 1M) * 输出单价。

我通常用一套三分钟手动估算法：

在 OpenClaw 配置里打开 debug 日志，或者直接调用一次带工具的接口，拿到 usage 字段。
把 prompt_tokens 拆成三块：固定上下文（系统提示 + 工具定义）、历史上下文、临时上下文（用户输入 + 工具返回）。
算出固定上下文占比。如果超过 50%，说明你挂了太多 MCP 服务器或者工具定义太啰嗦。
用任务的日均调用次数乘以单次成本，就能算出月开销。

举个例子，假设模型是 GPT-4o（输入 5 美元 / 1M token，输出 15 美元 / 1M token）。一次调用 prompt 8000、completion 2000 的成本是：8000/1M * 5 + 2000/1M * 15 = 0.04 + 0.03 = 0.07 美元。如果一天 200 次调用，一天纯模型费用是 14 美元，一个月约 420 美元。而如果固定上下文从 6000 压到 2000，单次成本立刻降到约 0.04 美元，月开销减少近一半。

有人说，那我用便宜的模型不就行了。可以，但要注意很多本地模型（比如通过 Ollama 部署的）完全不按 token 计费，只有硬件电费。如果你只是在 Ubuntu 上跑着玩，用 Ollama 部署 Qwen2.5 或者 Llama3.1，token 成本直接归零。这也是我在非生产力环境里的首选方式。但本地模型能力有限，复杂任务还得用云端 API，所以省 token 的功夫不能省。

3. 实操：给 OpenClaw 接 MCP 的正确姿势

3.1 部署与模型接入：本地跑还是 API 接入

先不说具体代码，先讲部署选型。OpenClaw 官方提供 Docker 镜像和原生安装包。我在 Windows 上直接跑原生包，Linux 服务器上则用 Docker Compose 管理，组网方便。如果你有安卓手机，也可以尝试用 Termux 安装 OpenClaw 手机版，但性能上只适合跑轻量任务，接 MCP server 时能选的不多。我踩过的一个坑是：在 Termux 里直接用 pip 安装某些依赖会编译失败，后来用 Termux 的 pkg 仓库装好 Python 和依赖才顺利跑起来。

模型接入时，OpenClaw 会要求配置 provider 和 api key。这里有两个选择：

远程 API：支持 OpenAI、Anthropic、DeepSeek、通义、Gemini 等。优点是不吃本地硬件，能力上限高。缺点是你要忍受网络延迟，并且每次调用会产生 token 计费。而且 API key 不是永久的，很多服务的 key 或临时 token 会过期，导致 “token exchange failed” 之类的报错。
本地模型：通过 Ollama 接口接入。优点是完全本地推理，没有 token 单价，断网也能用。缺点是模型参数量不大时，推理速度和效果都一般。

如果你问我建议：日常调试验证用 Ollama，生产环境再切远程 API。这样既能控制成本，又能把 MCP 的逻辑调通，不会因为 API 账号出问题卡住整个开发流程。

3.2 MCP server 配置：这几个参数决定 token 胖瘦

OpenClaw 的 MCP 配置一般在 config 文件的 mcpServers 字段里，每个 server 有三个关键配置：

transport：stdio 还是 sse/http。本地进程用 stdio，远程服务用 sse。
command/url：进程命令或服务地址。
headers/params：部分服务需要鉴权 token，比如 Git 私有仓库的 MCP server 需要配置 Personal Access Token。

一个典型的 stdio 配置长这样：

{ "mcpServers": { "postgres": { "transport": "stdio", "command": "npx", "args": ["-y", "@modelcontextprotocol/server-postgres"], "env": { "DATABASE_URL": "postgresql://user:pass@localhost:5432/mydb" } } } }

这里容易踩坑的是工具自动加载。OpenClaw 默认会把 MCP server 暴露的所有 tools 全部注入系统上下文。有些 MCP server（比如社区版的 Kubernetes MCP）动辄几十个工具，描述又长又重复。我见过一个极端的例子：接完一个文件系统 MCP，工具 schema 直接占了 1.2 万 token。这时候你哪怕一句话都不说，每次请求都要为这 1.2 万 token 付费。

怎么瘦身？四个技巧：

只挂必须的 server。比如你只是查数据库，就不要同时挂浏览器和设计软件的 MCP。
自定义描述。很多 MCP server 允许在配置里重写 tool 的 description，你可以把冗余的长描述换成一句话，减少几百 token。
启用命名空间隔离。OpenClaw 支持把 MCP 工具绑定到特定 agent 或 skill，这样主 agent 的上下文里只有一个小型工具子集，需要时再调用子 agent。
用 OpenClaw 的 tool filter 功能。如果版本支持，直接配置允许列表，只注入指定的几个工具。

我提一个冷门但实用的点：如果你的后端是 Java REST 接口，又不想自己写 MCP server，可以看看有没有现成的 MCP 网关，把 REST API 转成 MCP 协议。网上有开源转换工具，用注解把接口元数据自动生成工具定义。但注意，无脑转换出来的 schema 往往又大又乱，一定要在转换后手动清理参数列表，去掉非必填字段。我接过一个订单查询接口，原始 schema 有 200 多行，我把必填参数压缩到 3 个，描述改成一行，token 直接省了 70%。

3.3 控制上下文长度的三个开关

OpenClaw 的上下文管理比普通聊天框架更复杂，因为它既要有历史记忆，又要能执行多步工具调用。我用下来觉得最有效的三个开关：

max_context_tokens：设置上下文上限，超过后强制截断。我一般设成模型最大上下文的 60%，留出工具返回空间。
auto_summarize_threshold：当对话轮次超过阈值，自动把前面的消息总结成一段摘要。这个摘要会替换掉原始对话，虽然会丢掉一些细节，但能大幅抑制上下文线性增长。
session_ttl：会话超时时间，超过后自动清理。如果任务之间关联不大，最省钱的做法就是每次新开会话，把上下文归零。

很多人不敢开自动摘要，担心丢失关键信息。我自己的做法是：把摘要保存到本地日志，同时把摘要内容写得足够结构化（例如时间、任务、结论、未完成事项），这样即使之后需要追问，也能从摘要里恢复大部分上下文。

3.4 用 skill 和子 agent 分摊 MCP 开销

OpenClaw 的 skill 可以理解为一套预设提示词加工具调用组合。你在 skill 里描述的每个步骤，都会变成 agent 的思考指导。我测试过一个很有用的模式：把“网站信息提取”做成一个子 agent，内部挂 Playwright MCP，同时把主 agent 里的 Playwright 工具全部移除。当用户问“帮我看看这个页面有什么内容”时，主 agent 把 URL 传给子 agent，子 agent 用 MCP 抓页面，只返回“标题、摘要、几个关键数值”这种压缩后的结果给主 agent。

这样做的收益是：Playwright 那套长工具 schema 只在子 agent 的上下文中出现，且子 agent 的会话很短。主 agent 收到的只是几百 token 的摘要，总成本自然降下来。同样的思路也适用于代码搜索、数据库查询等大返回工具。类似 IDA Pro 反汇编工具的 MCP、Altium Designer 的 AI 接口 MCP，社区里也已经有人在做，但这类专业工具的定义往往又长又复杂，更应该放到单独 agent 里，不要全局挂载。

4. 常见 token 异常与排查实录

4.1 token exchange failed：80% 是这五个原因

很多朋友部署 OpenClaw 后第一次登录，或者运行一段时间后，会碰到以下报错：

“sign-in could not be completed: token exchange failed”
“token endpoint returned status 403 forbidden”
“Your access token could not be refreshed. Please log out and sign in again.”

先说结论，这些报错绝大多数不是 OpenClaw 本身的问题，而是底层认证流程出了问题。我把常见原因列出来：

access token 过期。OpenClaw 和 OpenAI 等服务的 OAuth 流程中，access token 寿命通常很短，要靠 refresh token 续期。如果 refresh token 也过期或被吊销，就会出现 “could not be refreshed” 的提示。解决办法是重新执行登录流程，不要手动拼接 token。
scope 配置不对。在申请 OAuth app 时，如果没勾选对应的权限范围，token exchange 阶段服务端就会返回 403。检查你在 OpenClaw 里配置的 provider 和 scope 是否一致。
endpoint URL 填错。有些私有化部署或地区版本会使用不同的 token endpoint，你填成了公网地址，自然请求失败。对照服务商文档，修改 base_url。
本地时钟偏差。JWT 签发和校验都依赖时间戳，如果服务器或终端时间不对，可能导致 token 被视为未生效或已过期。用 NTP 同步一下时间。
API key 格式不正确。注意有些平台要求 Bearer token，有些只要裸 key，还有的要在 key 前加特定前缀。OpenClaw 配置里复制的时候不要多带空格。

排查顺序我建议是：先看日志里请求的 URL 和状态码，再检查本地时间，最后重新登录一次。大多数问题都出在过期和 scope 上。

如果你收到类似 “token endpoint returned status 403 forbidden: country” 的报错，那通常意味着服务商对请求来源有访问控制策略。这种情况要先确认你的 API 域名是否匹配服务商文档里的区域端点，再看当前来源地址是否被允许访问该服务。这是服务层面的配置，不是 OpenClaw 的 bug。

4.2 数据库查询返回太大？这是静默烧钱黑洞

MCP 工具返回结果太大是另一个高频问题，但通常不报错，而是“静默烧钱”。比如你让 Postgres MCP 执行一个SELECT * FROM orders，如果有 5 万行，MCP server 会把结果全部塞回给模型。模型上下文不够就直接报错，即使够，下一轮请求也要带上这 5 万行文本，token 瞬间爆炸。

我一开始也踩过这个坑。后来我在 MCP server 的 SQL 模板里强制加LIMIT 20，同时 OpenClaw 端对超过 2000 字符的返回结果做截断，只保留前 30 行字符。这里的关键是“最小可用结果”——工具只需返回能回答问题的最少量信息，而不是把所有数据都拿回来。比如“统计总销售额”，只返回一个聚合值，而不是明细行。

4.3 代码仓库 token 的坑

OpenClaw 接代码库 MCP 时，经常用到 Git 或 GitHub 的 Personal Access Token。这个 token 有有效期，且权限范围要精确。最典型的报错是 push 或者 clone 时提示 “Authentication failed” 或 “token expired”。我之前因为把 token 的有效期设置为 30 天，导致每个月都要重新登录一次。后面改成 fine-grained token，权限只给需要的仓库，过期时间也设置了提醒，省了很多麻烦。

另外，如果你用 JWT 作为 MCP server 的回调 token，务必在服务端实现续签逻辑，否则客户端会在运行中突然收到 401。网上有不少现成的 JWT 续签中间件，比如 Go 语言的 gin-jwt，Python 的 flask-jwt-extended。在 OpenClaw 场景里，你可以把 MCP server 的 access token 做自动刷新，再通过 SSE 推送新的 token。不过我实测下来，自己写刷新循环不如直接用服务商 SDK 的默认行为来得稳。

5. 我只保留这 3 个 MCP，token 直接省 70%

5.1 从 5 个 MCP server 降到 3 个

我的 OpenClaw 一开始接了 5 个 MCP：Postgres、Playwright、文件系统、Git 和一个自定义 HTTP 网关。固定工具 schema 大概 9000 token。优化后我做了三件事：

文件系统 MCP 和 Git MCP 合并到自定义 HTTP 网关里，自己只暴露 4 个工具。
Postgres MCP 删掉了不用的 7 个工具，只保留query、describe、list_tables，schema 从 2500 压到 700。
Playwright MCP 挪进子 agent，主 agent 不再挂载。

最终主 agent 的固定上下文从 9000 降到了 1800 左右，相当于省了 80% 的固定开销。再加上工具返回截断，整轮对话的平均 token 从 12000 降到 4000 上下，费用降幅超过 70%。

这个案例里比较重要的是想清楚：你到底需要哪些能力？很多 MCP 工具集是通用型的，带了大量你根本不会用到的函数。删掉它们，模型做决策时也更快——你给一个 agent 的选项过多，它反而会选错，甚至为了“展示能力”去调用根本不需要的工具，白付一轮工具调用的成本。

5.2 让工具返回最小可用结果

这里我总结一个通用法则：工具返回值应该是“答案”，而不是“数据”。比如：

数据库查询：在 SQL 里聚合，而不是返回明细。
网页抓取：只提取标题、元描述、正文前 500 字符，而不是整个 HTML。
文件读取：只读取与问题相关的行，而不是整个文件。
图片/截图：先压缩再返回，MCP 可以返回 base64，但尽量限制尺寸。

OpenClaw 端也可以配置max_tool_response_tokens，超过部分直接截断。但这个要谨慎，因为截断有可能把重要结论切掉，所以我更建议在 MCP server 内部做裁剪。

5.3 换用支持 prompt caching 的模型

省 token 不是一味地减少输入，还可以利用缓存。Anthropic 的 prompt caching 和 OpenAI 的自动缓存，都能对重复的固定前缀打折甚至免单。OpenClaw 部分版本在 headers 里配置anthropic-beta: prompt-caching-2024-07-31就能启用。启用后，系统提示 + 工具 schema 这部分固定上下文会命中缓存，后续请求的输入成本大幅下降。我在 API 日志里看到 cached_tokens 从 0 涨到几千，账单直接掉了一个档次。

如果预算敏感，也可以用 DeepSeek、Qwen 这类模型。比如 DeepSeek-V3 的输入价格只有 GPT-4o 的几十分之一。很多开源场景下，用它们接 MCP 效果也足够。唯一要注意的是，不同模型的 tool call 格式有细微差异，OpenClaw 都做了一层抽象，不过个别模型调用复杂嵌套工具时会偶尔出错，需要降级为更简单的并行调用。

5.4 我整理的一套 token 审计脚本

最后分享一个我每天跑的小脚本。OpenClaw 会把每次请求的 usage 打到日志里，我写了个 Python 脚本扫描日志，统计每个会话的输入/输出 token、工具调用次数和 MCP server 名称，然后生成一张排行榜。这样我一眼就能看到哪个 MCP 或者哪个会话最烧钱。

import re from collections import defaultdict pattern = re.compile(r'"prompt_tokens":(\d+).*?"completion_tokens":(\d+).*?"tool":\s*"(\w+)"') stats = defaultdict(lambda: [0, 0]) for line in open('openclaw.log'): m = pattern.search(line) if m: prompt = int(m.group(1)) completion = int(m.group(2)) tool = m.group(3) stats[tool][0] += prompt stats[tool][1] += completion for tool, (p, c) in sorted(stats.items(), key=lambda x: x[1][0], reverse=True): print(f"{tool}: prompt={p/1000:.1f}k completion={c/1000:.1f}k")

真实生产环境里，我会把日志接入 Loki 或 SQLite，做成看板。每周看一次，就能发现新增的 MCP server 又偷偷把 token 吃掉了。

写这篇文章的时候，我特意去翻了一下这个月的账单。最夸张的一天，OpenClaw 和大模型聊了 800 多次，消耗了将近 600 万 token，其中一半以上来自 MCP 工具定义和返回结果。现在通过精简 server、子代理隔离、启用缓存，日均消耗只有原来的三分之一。这个优化过程没有高深技巧，无非就是搞清楚每个 token 去了哪里，然后把不必要的开销一个个堵上。如果你也接了 MCP，建议先从工具 schema 的体积开始查起，这往往是最大的浪费源头。最后一个小提醒：记得给密钥设定期限提醒，别像我一样某天半夜被 token 失效的报错叫醒。