最近半个多月我把主力 Agent 框架换成了 OpenClaw顺手接了好几个 MCP 工具本来想体验一把“AI 自动干杂活”的爽感结果月底一算 API 账单直接愣住了明明没聊几句话token 消耗却比我以前纯对话多出好几倍。一开始我还以为是模型变贵了后来把日志导出来逐条对才发现问题出在 MCP 上。每次看起来简简单单的对话后台都在反复运输一大堆看不见的内容——工具描述、工具返回结果、历史消息全都要按 token 重新计费。这篇就把我的接入过程、踩坑记录、实测数据和优化方案完整摊开讲给正在用 OpenClaw 接 MCP、又对 token 账单发愁的朋友当份参考。文章适合这几类人刚接触 OpenClaw 和 MCP、想搞清楚 token 为什么消耗这么快的新手已经在用但被 API 账单吓一跳的玩家以及想接入本地模型但不知道该怎么权衡成本和效果的人。1. 先搞清楚OpenClaw、MCP、token 这三者到底怎么连起来1.1 OpenClaw 是个什么东西我为什么拿它当主力OpenClaw 是一个开源的智能体运行框架可以理解成一个“有手有脚的 AI 助手核心”。普通聊天机器人只能跟你你一句我一句OpenClaw 不一样它会根据你的指令去执行真实操作读文件、改代码、查数据、操作浏览器、调用各种本地工具然后把结果反馈回来继续处理。我选择 OpenClaw 主要有三个原因第一部署方式灵活Windows、Linux、Docker 都能跑我这边就是先用 Docker 搭了服务端再在 Windows 上用客户端连接管理。第二它支持 OpenAI 兼容 API也能接 Ollama 这类本地模型对于想控制成本的人来说非常友好。第三它原生支持 MCP 协议可以快速把生态里现成的 MCP server 接进来不用自己造轮子。当然OpenClaw 也不是零门槛。它的配置项不少上下文管理、工具权限、MCP server 注册这些都得自己调默认配置用起来大概率会踩坑。我后面讲到的 token 超量消耗很多就是因为对它的上下文机制不够了解。1.2 MCP 是给 AI 开的 USB-C 口MCP 的全称是 Model Context Protocol模型上下文协议。最早是给 AI 编程工具设计的目的是让 AI 应用能统一接入外部工具和数据源现在已经被很多 Agent 框架、IDE、浏览器插件广泛采用。举个好理解的例子以前每个 AI 应用接工具都是各接各的A 应用想读文件要自己写一套文件接口B 应用想查数据库又要自己写一套数据库驱动工具方也要为每个应用做适配非常碎片化。MCP 相当于给 AI 客户端开了一个标准 USB-C 口工具方只需要做一个 MCP server任何支持 MCP 的客户端都能插上直接用。架构上分三端MCP server 负责提供工具能力MCP client 负责转发请求和结果LLM 是大脑决定什么时候调用哪个工具。比如你问 OpenClaw“我这个目录下最大的文件是什么”OpenClaw 里的模型判断需要文件系统能力就通过 MCP client 调用 filesystem serverserver 扫描后把结果返回模型再组织成自然语言回答你。理解了这层关系你就能明白为什么 token 会烧得快工具调用不是模型直接知道答案而是模型先发起调用服务器执行完再把结果回传。这个回传内容是要进入模型上下文的而且不是用完即走它会留在对话历史里后面每一轮继续跟着计费。1.3 token 到底怎么算一次对话凭什么收好几笔钱Token 是模型处理文本的最小单位。你可以粗略理解成“模型眼里的字词块”。英文大概 4 个字符算 1 个 token中文通常一个字就会拆成 1 到 2 个 token。所以“帮我看看今天的天气”这句话在模型眼里大约是 10 个 token 上下。计费方式通常是按 token 用量收费而且既算你发进去的也算模型生成的。发进去的部分叫 prompt token生成的叫 completion token两者往往价格不一样。关键在于对话不是只统计一次而是每一轮追问都会把前面所有内容再重新发一遍。比如你第一轮问 A模型回了 B第二轮你继续问 C这时候发给模型的不是只有 C而是 A B C 全部重发。所以对话越长、中间塞进去的工具结果越大后面的每一轮就越贵。我接入 MCP 后发现 token 暴增根本原因就在这里——工具返回的大段内容被反复重发而不是只统计一次就完事。2. 接入实操从零给 OpenClaw 装一个 MCP 工具2.1 环境准备Node.js、OpenClaw 本体、MCP server先把环境搭好。我这里以 Windows Docker 部署 OpenClaw 为例MCP server 用 Node.js 版本因为生态最全踩坑资料也最多。第一步安装 Node.js建议装 18 或 20 的 LTS 版本太老的版本跑不起来现代 MCP server。装完在终端里执行node -v和npm -v确认版本号正常。第二步部署 OpenClaw。最简单的做法是拉官方镜像起来把数据目录挂载出来。如果是 Windows Companion 模式下载对应客户端安装包启动后按引导连接服务端 IP 和端口。我当时卡过一次网络发现后来直接在配置文件里手动指定服务端地址就好了。第三步是准备 MCP server。先用官方测试用的 filesystem server 练手一条 npx 命令就能启动后续换成自己写或社区开发的 server 也走同样的注册逻辑。测试阶段尽量别一上来接十几个工具不然出了问题很难定位。2.2 配置文件里写什么一个标准的 mcpServers 块OpenClaw 的 MCP 配置本质上是一个 JSON 结构核心是mcpServers字段每个 server 要写清楚启动方式和参数。我最终的配置大概是这样的{ mcpServers: { filesystem: { command: npx, args: [ -y, modelcontextprotocol/server-filesystem, D:/workspace ], env: {} }, custom-tool: { command: node, args: [D:/mcp-servers/custom-tool/index.js], env: { LOG_LEVEL: info } } } }command是启动命令args是传给命令的参数。filesystem server 支持的参数是要开放的目录白名单把需要读写的目录写进去别全盘开放。自定义 MCP server 通常把入口 JS 文件路径写在 args 里就行。这个配置文件在很多 MCP 客户端里是通用的比如 Claude Desktop、Cline 都认这套结构。所以你在 OpenClaw 里写好后换到别的客户端也能复用减少重复劳动。改完配置一定要重启 OpenClaw 进程很多连接问题并不是配置错了而是配置根本没被重新加载。2.3 工具调用链路模型、客户端、server 三方怎么传话配置好之后一次工具调用大概分五步第一步模型收到你的问题根据系统提示词里声明的“你有哪些工具可用”来判断要不要调用工具。第二步如果决定调用模型不是直接输出答案而是先输出一个结构化的工具调用请求比如“调用 filesystem 的 list_directory 方法参数是 D:/workspace”。第三步MCP client 收到这个请求按照配置找到对应 server把请求转发过去。第四步server 真正执行操作比如列出目录结构把结果返回给 client。第五步client 把工具返回结果追加到对话历史中再连同原问题和工具调用记录一起发给模型模型才最终生成回答。这五步里第三步到第五步是最容易忽略 token 成本的地方。工具返回结果一旦进入历史后续每一轮都会跟着被重发。我见过有人一个工具返回了 3000 行日志模型只用了其中两行结论但后面五次追问这 3000 行就跟着被重发了五次你算算这烧了多少。2.4 第一个实验让 OpenClaw 通过 MCP 读文件并总结我做的第一个实验是让 OpenClaw 读取一个 markdown 文件并总结内容。文件不大大概几百行按理说输出几句话就够了。实际流程是我发起“总结一下这份文档”模型先调用 filesystem server 的读文件工具把完整文件内容拉回来然后才开始总结。那次我看了一下 API 日志模型回答只有 200 多个 token但整个请求链路上光文件内容就占了 2000 多 token如果有历史消息再叠上去总量就很可观了。做完这个实验我就明白了要控制 token重点不是让模型少说废话而是控制那些“看不见的输入”尤其是工具返回结果和工具定义本身。3. 我把账算明白了一次普通对话token 是怎么翻着倍烧的3.1 真实消耗公式每次请求都在为哪些内容买单先把公式写出来这个是全文最核心的内容每次 API 请求的 token 消耗大约是系统提示词 历史对话含之前所有工具返回结果 全部已注册工具的定义 当前用户输入 模型可能的输出上限注意几个容易被忽略的项工具定义不是免费的。每个 MCP server 注册后它提供的所有工具的名称、描述、参数 JSON Schema都会被塞进系统提示词里发给模型。一个复杂的 server 可能有十几个工具光定义就能占几千 token而且每一轮请求都会重复计入。工具返回结果默认全量进历史。MCP client 通常不会帮你截断server 返回多少下一次请求就发送多少。模型输出上限也会影响计费。很多平台按实际生成量计费但有些按预留上限计费或混合计费配置里的max_tokens设太高即使模型没输出那么多也可能按更高档位算。3.2 实测数据一次“读文件并总结”花掉了多少 token我把我自己的实测数据贴出来配置是 OpenClaw filesystem MCP OpenAI 兼容 API。系统提示词大约 800 tokenfilesystem server 注册了 8 个工具工具定义合计约 1200 token。第一次用户提问“总结一下 data.md”约 10 token。第一次请求发出去800 1200 10约 2010 token。模型决定调用工具实际输出了一个函数调用指令这一小段大概 50 token。然后 client 把文件内容拿回来了我这个 data.md 大概 3000 token。第二次请求发出去800 1200 10 50 3000约 5060 token。模型最终生成了总结假设 200 token。这整个过程算下来用户感知到的就是“一问一答”但实际 API 侧的 token 消耗已经超过 7300 token。其中最惊人的是文件内容这一项占了约 40%而且它还会留在历史里。如果我继续追问第二句这 3000 token 的文件内容会跟着再次被完整发送相当于每一轮追问都在为上一次的“偷看文件”行为重新付钱。3.3 四宗罪偷跑 token 的常见元凶第一宗罪工具返回结果不截断。很多 MCP server 提供的是“取全部内容”类工具文件多大就返回多大数据库查询多少行就返回多少行。模型其实可能只需要其中一部分但 context 照单全收。第二宗罪工具定义过于冗长。有些人给工具写 description 写了几百字参数 schema 又套了好几层每多写一个中文字每一轮请求就多付一次钱。一次对话二十轮这段描述就被付了二十次钱。第三宗罪历史消息完全没有压缩。默认情况下每一轮对话都是全量历史重发包括之前的工具返回。OpenClaw 虽然有上下文管理机制但如果不开自动摘要长对话的 token 消耗是指数级增长的。第四宗罪并行工具调用放大消耗。OpenClaw 支持模型一次调用多个工具几个工具同时执行各自返回结果一起堆进上下文。功能很爽但如果每个工具都返回大段内容一轮下来 token 就爆炸了。3.4 本地模型的另一本账Ollama 就不烧钱了吗既然 API 按 token 收费很多人第一反应是“那我换本地模型”。我确实也把 Ollama 接入 OpenClaw 跑过一阵子qwen2.5 系列小模型都能跑API 账单确实是归零了但代价是另一本账。本地模型不烧 token 钱烧的是显存和响应速度。3B 级别的小模型在普通电脑上能跑但工具调用能力明显偏弱经常出现模型不理解工具参数、该调用时不调用、调用格式错误等。而且本地模型上下文窗口如果设置小了大文件返回结果很快就把上下文塞满直接报错。我的建议是实验和熟悉阶段用本地模型正式干活且对质量有要求时用 API 模型然后把上下文优化做好。不要单纯为了省 token 费用牺牲效果那可能是更大的隐形浪费。4. 优化方案把 token 消耗压下去又不牺牲工具能力4.1 对工具返回下手截断、预览、分页读取最直接有效的优化是减少进上下文的数据量。第一个办法是截断。在 MCP client 侧或者自己封一层 wrapper对工具返回结果做长度限制比如只保留前 N 行或前 N 个字符超出部分丢弃。但对“读文件并总结”这类任务直接截断可能丢失关键信息所以我不是无脑截断而是区分场景。第二个办法是提供“预览型工具”。我后来自己写了一个read_file_preview工具只读取文件头部 50 行和尾部 50 行返回一个带行号标记的预览文本。模型先看预览决定下一步如果真需要全量内容再调用完整读取工具。这样一来大多数不需要全文的场景就只用付 100 行的 token 成本而不是整个文件。第三个办法是分页读取。文件系统、数据库查询都可以做成带 offset 和 limit 参数的分页工具模型需要多少就取多少。这比返回全量再让模型自己筛选聪明得多。代价是需要自己写一点工具代码但对消耗大头场景非常值得。4.2 对工具定义下手精简、卸载、按需加载工具定义是每轮请求的固定成本一个 1200 token 的工具定义五十轮对话就是 60000 token 的隐形消耗。所以优化工具定义特别划算。首先卸载不用的 MCP server。不要贪多只保留当前任务真正需要的工具。我一度接了五个 server其中三个其实很少用到但它们的工具定义每一轮都在交钱。后来全部移除系统提示词立刻瘦身。其次精简描述和参数 schema。工具 description 写清楚用途即可不用写小作文。参数 schema 里没必要的字段就删掉default能省就省。以我经验大部分工具的描述和参数描述精简到原来的三分之一并不影响模型理解。最后如果 OpenClaw 支持按会话加载不同工具集就按需加载。一个任务是文件处理就只挂 filesystem一个任务是浏览网页就只挂 browser。别把一堆工具常年挂在那当背景板。4.3 对对话历史下手摘要压缩、定时清空长对话里历史消息是最大的 token 吞噬者尤其是工具返回结果留在历史里的场景。OpenClaw 有一些上下文管理策略核心是摘要压缩当对话超过一定长度把更早的历史消息交给模型生成一段摘要然后用摘要替代完整历史。这个机制能省很多 token但要注意副作用——摘要会丢失细节模型可能忘记之前处理过哪些具体数据。所以我会在关键任务完成后主动开新会话而不是长期复用同一个上下文。养成一个好习惯每完成一个目标就执行一次会话重置。这不丢人反而能保证每次任务上下文干净、准确、成本低。很多人舍不得清历史觉得翻旧账方便但实际翻旧账的频率比你想象的低得多token 成本却实实在在。4.4 对模型和预算下手切换模型、设置上限不同模型的 token 单价差很多。同样一次工具调用旗舰模型和中端模型可能差五倍十倍的价。如果你的任务主要是文件整理、数据提取这类结构化操作不涉及复杂推理完全可以用中端模型处理让 OpenClaw 在很复杂的任务时才切到旗舰模型。OpenClaw 接入的是 OpenAI 兼容 API 的话一般可以在配置里设置max_tokens和上下文窗口。把max_tokens限制在一个理智范围内避免模型长篇大论。另外看 API 平台是否支持硬性消费上限设置每日或每月的预算告警。API 账单的实时通知一定要开我第一次发现 token 异常就是靠账单告警否则可能月底才反应过来。还有一个实用技巧记录每次会话的 token 用量养成查看日志的习惯。OpenClaw 的日志里通常能看到每次请求的 token 统计随手翻一翻哪些操作烧钱一目了然。5. 常见问题速查与避坑清单5.1 几个高频问题连不上、超时、上下文爆掉先说说我实际遇到过的几个问题。MCP server 连不上。最常见的原因是 npx 启动失败或者端口不通。stdin/stdout 型 server 不用端口但如果你看到它一直重启先用终端手动跑一遍启动命令看报错信息。我遇到过 Node 版本不兼容也有一次是目录路径里有中文导致解析失败手动跑命令时瞬间暴露问题。工具调用超时。有些 MCP server 执行耗时较长比如扫描整个目录默认 timeout 太短会直接中断。在 OpenClaw 配置里可以调大超时时间我的做法是设置成原来的三倍。如果还是超时就该怀疑是不是工具本身设计有问题比如扫描了不该扫描的大目录。上下文窗口爆掉。报错信息通常是 context length exceeded说明历史加工具返回超过了模型最大上下文。这时候不是调大窗口就完事窗口调大会让单次请求更贵还会增加延迟。正确思路是先清理历史、截断工具返回把总量降下来。我见过有人把 200K 上下文的窗口塞满单次请求费用高得离谱这属于反向优化。5.2 鉴权 token 失效先按这个顺序排查OpenClaw 和 MCP 生态里还容易出现另一种“token”——鉴权 token。它跟计费 token 不是一回事但名字一样经常让人混淆。接入某些需要登录的 MCP server 或远程 API 时报错会提示 token exchange failed、access token 失效、refresh token 无效之类。遇到这种问题我的排查顺序是先看配置里的 API key 或访问令牌是不是过期了去服务商后台重新生成一个然后检查系统时间做 OAuth 时时间偏差太大会直接判定 token 无效再清理本地缓存的登录状态重新走一次登录流程。大部分“token exchange failed”都是前面这三个原因之一。要注意鉴权 token 和模型 token 是两个完全不同的东西出问题时先分清是哪一种。如果你根本没接需要登录的外部服务却报 token 问题那通常是配置格式不对或者服务商拒绝了请求不要被关键词误导。5.3 我的最终实践建议把整套经验浓缩成几条我自己现在每天在用的规则第一条默认只挂必要的 MCP 工具装完用完就卸载不要让工具列表越长越离谱。第二条所有可能返回大数据的工具都要有截断或分页机制拒绝全量返回。第三条每完成一个任务就清空会话别让历史变成复利债。第四条用日志和账单盯住成本不要等月底再惊讶。第五条能用本地模型验证的实验就别烧 API 额度。我在实践中最大的体会是token 浪费从来不是某一个瞬间的大额支出而是隐藏在每个细节里的重复计费。工具定义多几个字、返回结果多几行、历史多留几轮单独看都不起眼乘上对话轮数就变成了账单一角的惊人数字。把上下文当成“每轮都要重新付钱的空间”来管理心态会完全不一样。这套方法在 OpenClaw 上验证有效换到其他支持 MCP 的客户端也基本通用。如果你已经在用别的 Agent 框架按同样的思路去检查工具返回和历史压缩大概率也能找到偷跑 token 的元凶。