给 OpenClaw 接上 MCP 之后我做的第一件事不是测试工具好不好用而是打开 token 账单看了一眼。结果让我有点意外——原本一次很普通的对话比如“帮我查一下某个目录下的文件”在没有接入任何 MCP 工具之前可能只需要 1000 多个 token接上 MCP 之后同样的意图账单直接翻了好几倍。说实话OpenClaw 这个项目我关注了有一阵子。它本质上是一个本地优先的 AI Agent 框架你可以把它理解成一个“带手带脚的 AI 助手底座”装好之后它能读文件、执行命令、操作各种软件再通过 MCP 这样的标准协议把你想要接入的外部能力数据库、浏览器、绘图软件、IDE 等一个个挂上去。MCP 全称 Model Context Protocol是一种给大模型“接外设”的开放协议社区里也常叫它“AI 应用的 USB 接口”。把 OpenClaw 和 MCP 接在一起就是让 Agent 拥有更多可调用的真实工具。但这套组合有一个绕不开的代价token。每次对话模型都要把工具清单、历史记录、返回结果全部重新读一遍这些看不见的消耗确实在偷偷烧钱。1. 先把基础拆清楚OpenClaw、MCP、token 到底怎么配合1.1 OpenClaw 是干嘛的OpenClaw 在社区里通常被定位成一个开源的 Agent 运行时。它和那种“网页上聊两句就完事”的 AI 不一样它跑在你自己的机器上可以真正操作你的文件系统、终端和软件。我身边不少朋友把它当成一个可以自己改造的“私人助理”有人拿它做自动化日报有人让它定时整理下载目录还有人用它去控制本地开发环境里的编译任务。它的核心优势在于“可编排”。OpenClaw 提供了一套技能Skill系统和工具调用机制你不需要每次都在 Prompt 里写大段指令而是把常用能力封装成可复用的模块。比如我可以告诉它“扫描某个目录下的所有 Python 文件”它就能基于这套封装去做。对我这种不爱反复写提示词的人来说这个设计比裸调 API 顺手得多。不过也有不少人刚接触时会困惑一点OpenClaw 本身不内置某个大模型它更像一个“调度中枢”。真正做推理和决策的是后面接的大模型 API。所以你问“OpenClaw 只能用接入 API 的方式使用算力吗”答案是目前主流用法确实是接 API本地小模型也能试但效果和速度差别很大。这也解释了为什么 token 问题在 OpenClaw 场景下会被放大——每个决策都要经过大模型而大模型的每次“思考”都要花钱。1.2 MCP 到底是什么MCP 是 Anthropic 在 2024 年底提出来的一套开放协议现在已经被大量 AI 工具支持。它的思路很直接让大模型和外部工具之间有一个统一的“插拔接口”。以前你想让 AI 读数据库、操作浏览器、调用某个软件每个都要单独写集成代码有了 MCP工具方只要实现一个 MCP Server任何支持 MCP 的客户端都能直接调用。你可以把它类比成电脑上的 USB 接口。键盘、鼠标、U盘各自的驱动和协议都不同但通过 USB 这个统一标准插上就能用。MCP 对 AI 应用来说就是这个 USB 口OpenClaw 是主机MCP Server 是外设两者之间走的是标准化的 JSON-RPC 消息。在 OpenClaw 里接 MCP意味着我不需要关心某个工具内部是怎么实现的只要在配置里写上 Server 地址和参数Agent 就能在需要时自动调用它。听起来很美对吧但问题恰恰出在“自动调用”这四个字上——每次调用都要付出 token 成本。1.3 token 这个“计价单位”为什么敏感token 是大模型处理文本的最小单位。中文一个字大概对应 1 到 2 个 token英文一个单词通常 1 到 3 个 token。模型计费时不但计算你发送过去的内容也算它回复的内容而且很多 API 是按总 token 数阶梯计费的。关键在于Agent 的每一轮对话并不像普通聊天那样只发一次请求。OpenClaw 接到你的问题后会先调用模型“想一下该怎么做”然后模型可能决定调用某个 MCP 工具工具执行完返回结果模型再看结果继续推理可能又调用下一个工具……这个循环每走一步都要把“到目前为止的全部对话历史”重新发给模型一次。也就是说同样的内容模型实际上看了好几遍每一遍都计费。我在实际操作里第一次意识到这个问题是在接入了一个文件搜索 MCP 之后。我只是问了一句“找一下上周生成的日志”结果后台日志显示模型先看了一遍工具列表选定了搜索工具又看了一遍搜索参数说明然后工具返回了一个很长的文件清单模型又把那个清单完整读了一遍最后才给我总结。整个流程消耗的 token是我预想中的 5 倍以上。所以给 OpenClaw 接 MCP 这件事本质上是在“能力”和“成本”之间做平衡。工具越多、返回数据越臃肿单次对话的 token 就越大。2. 我接 MCP 的完整过程以及接入后踩到的第一个坑2.1 环境准备先让 OpenClaw 跑起来我用的是一台 Ubuntu 22.04 的机器8 核 CPU、16G 内存跑 OpenClaw 和几个轻量 MCP Server 完全够。安装过程不复杂官方提供了一键安装脚本本质上是拉取依赖、初始化配置目录、生成默认配置文件。装好后OpenClaw 会在用户目录下创建一个.openclaw文件夹里面放着config.json和skills/目录。Windows 上我也装过一遍步骤稍微多两步需要先确保 Python 3.10 和 Node.js 18 都装好因为 OpenClaw 本身是 Python 写的但很多 MCP Server 是 Node.js 写的。这里提醒一句如果你在 Windows 上配置 OpenClaw建议用 WSL 2 而不是原生 Windows 环境省得多很多权限和路径问题。跑起来之后我建议先做三件事第一确认 OpenClaw 自带的基础命令能用比如让它帮你列一下当前目录第二看日志输出是否正常确保没有奇怪的报错第三手动在配置里指定你打算用的模型不要用默认值。默认模型不一定是最经济的后面会细说。2.2 给 OpenClaw 挂上第一个 MCP Server配置 MCP Server 的入口在 OpenClaw 的config.json里。一个典型的配置片段长这样{ mcpServers: { filesystem: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, /tmp/demo], env: {} } } }这段配置的意思是启动一个名为filesystem的 MCP Server通过npx运行官方的文件系统工具包并且只允许它访问/tmp/demo这个目录。保存配置后重启 OpenClaw再用一句“帮我看看 /tmp/demo 里有什么文件”来验证如果它正确列出了文件就说明 MCP 接通了。这里有个容易被忽略的小细节args里最后那个路径决定了这个 MCP Server 能访问的目录范围。我第一次配置时贪方便写了/结果工具返回时动不动就把整个根目录的子目录名带出来既浪费 token 又暴露了不必要的信息。后来我一律改成只给工具一个最小可用的目录安全性和 token 开销都改善了很多。2.3 接入后先别急着用看一眼日志我通常的做法是接好一个新 MCP Server 后先开一个空对话问它“你现在能做什么”然后把日志里显示的 token 统计复制下来。这一步不是为了好玩而是建立一个基准线。没有这个基准后面你是很难判断到底是哪次改动把 token 烧上去的。我接第二个 MCP Server一个数据库查询工具时就是因为没做基准测试排查了很久才发现问题不在工具本身而在于工具注册时带了一大段 description这段描述被模型当成了参考文档每次对话都会完整读一遍。所以现在我的习惯是每加一个工具都先看一眼“空对话时模型的 tool schema 占了多少 token”。这个数据在你自己的 API 调用日志、或者 OpenClaw 的调试模式里都能看到。3. 每次对话里token 到底烧在了哪些环节3.1 “名片费用”工具清单被反复发送大模型并不知道你有多少工具可用它每次收到请求时都要靠请求里的工具描述去理解“你有这些能力”。OpenClaw 也一样它会把所有已注册的 MCP 工具连同工具的名称、描述、参数结构一起塞进给模型的系统消息里。这就是我前面说的“名片费用”。每接一个 MCP Server只要里面注册了 5 个工具那你的请求里就多出 5 张名片。名片越精致——描述越详细、参数结构越复杂——token 就越多。我接的那个数据库 MCP单个工具的描述里写了一长串示例 SQL 和字段说明光那个工具的 schema 就占了 800 多个 token。当时我没注意直到对比账单才反应过来。更麻烦的是这个“名片”是在每一轮请求里都会出现的不是只付一次钱。建议你在配置 MCP Server 时先看看它到底注册了哪些工具。如果有些工具你根本不会用到就要想办法在 Server 端过滤掉或者干脆不注册。3.2 上下文累积效应对话越长单次请求越贵这是 Agent 场景里最隐蔽的烧钱点。普通聊天时只发最近的几轮消息但 Agent 要保证任务连续性通常会把“系统提示词 工具定义 历史消息 当前输入 各轮工具调用记录”全部放在一次请求里。拿我刚才那个“查上周日志”的例子来说具体消耗大概是这样的第一次请求系统提示词含工具列表约 1200 token加上用户问题 50 token共 1250 token。模型回复说“我要调用文件搜索工具”这段回复约 100 token。OpenClaw 执行搜索把工具返回的 3000 字文件清单作为 tool message 拼进上下文。此时新的请求变成1200 50 100 3000 4350 token。模型读到文件清单后又回复“我找到了这些是上周的日志”约 80 token。如果你接着问“里面最大的文件是哪个”下一次请求就是 1200 50 100 3000 80 你的新问题 30 4460 token。可以看到工具返回的那 3000 token在后面的每一轮对话里都会被反复计算。这就是为什么同样一段对话越聊到后面单次请求的 token 就越高。很多人觉得“我也没说多少句话啊怎么账单这么高”原因就在这里。3.3 “工具返回体”是最大的变量工具返回的内容是这些环节里弹性最大的。有的 MCP Server 设计得比较粗糙不管用户要什么一查就返回一堆字段。比如那个数据库工具我让它查“用户表有多少行”它把整个表结构连同索引信息都返回了光这几百行文本就占了 4000 token。MCP 协议本身不会限制返回体的大小所以这个坑只能自己踩。我在 OpenClaw 里加了一个中间层逻辑调用 MCP 之后先做一次结果预处理把明显无关的字段删掉再交给模型。这样做之后同样一个数据库查询从 4000 token 降到了 600 左右效果立竿见影。另外一个容易忽略的点是工具返回的错误信息也占用 token。MCP Server 一旦报错会把整个堆栈信息返回给 AgentAgent 再把这些错误信息读一遍试图“理解”。遇到这种情况最好的办法是服务端捕获异常后只返回一句话级别的错误摘要而不是原始堆栈。3.4 失败重试与流式输出的重复计费MCP 调用不是每次都能一次成功的。超时、连接失败、Server 端没安装依赖、参数不对都会导致调用失败。失败本身不一定是大问题问题是 Agent 在失败后往往会自动重试。每次重试都意味着一次完整的模型往返而这几次往返里前面已经消耗掉的历史上下文都会再算一遍。我实测过一个场景某个 MCP Server 因为端口被占用启动失败OpenClaw 不知道它挂了还是尝试调用它结果连续重试了 4 次才报错。那 4 次重试每次都要重新发送同样的上下文和工具定义等于把同一次请求的钱付了 4 遍。流式输出同样要小心。OpenClaw 在调用部分大模型 API 时默认开启流式输出便于实时显示回复。流式本身不额外收费但如果你的上层还做了日志记录、结果备份、或者消息监听这些数据在传输和处理时也可能被重复统计。虽然这部分通常比较小但积少成多。4. 实测数据三组对话的 token 账单对比4.1 我设计的三个测试场景为了把问题讲清楚我做了一个简单但真实的对照测试。用的模型是某主流 API 的中档模型计费规则是输入 0.15 美元/百万 token输出 0.6 美元/百万 token。OpenClaw 版本是最新的稳定版MCP 工具接入了一个文件搜索工具和一个数据库查询工具。三个场景分别是场景 A不接入任何 MCP 工具纯粹聊天问三个问题。场景 B接入 MCP但只问一个不需要调用工具的问题比如“11 等于几”。场景 C接入 MCP问一个需要调用工具的问题比如“列出 /tmp/demo 下的文件”。每个场景都从零开始新会话记录完整的一次“问题-回答”过程的 token 消耗。4.2 结果和我的分析测试结果如下表场景单次请求 token调用 MCP 次数总 token估算成本A无 MCP6500650约 0.0002 美元B有 MCP 但不调用185001850约 0.0006 美元C有 MCP 且调用一次540015400约 0.002 美元如果只看 C这个成本貌似也不高。但要注意这是单次任务、新会话、并且只调用了一次工具的理想情况。真实使用中一个稍微复杂点的任务会调用 3 到 5 次工具再加上后续追问一个任务跑下来 3 万到 5 万 token 是很常见的。再把场景 B 和 A 对比就能很清楚地看到“工具定义”本身的成本明明什么都没干只是多挂了一个 MCP Server单次请求 token 就从 650 涨到了 1850。如果你同时挂了 5 个 MCP Server每个都带一堆工具那这个基础开销会非常可观。4.3 手动算一笔账假设我每天用 OpenClaw 处理 20 个任务每个任务平均 30 万 token这个数字在重度使用时并不夸张按混合费率每百万 token 大概 0.3 美元算一天就是 9 美元一个月 270 美元。我见过一个团队把 OpenClaw 当团队 Bot 用接了十几个 MCP Server一个月 token 账单直接冲到四位数人民币。他们一开始也搞不懂钱去哪了后来把日志翻出来才发现工具定义和重复调用占了超过 60% 的消耗。所以这不是一个可以忽略的“小钱”。给 Agent 做 token 预算和给服务器做资源预算一样是正经要花时间的事情。5. 降低 token 消耗的几招招招能落地5.1 精简 MCP 工具注册不是越多越好第一原则只注册必要的工具。MCP Server 打开后通常会把它内部所有的工具都暴露出来。但你的日常任务可能只需要其中两三个。OpenClaw 这边如果你无法在配置层面直接过滤工具有两个替代办法一是用不同的配置 profile把工具分组二是通过 Skill 层的逻辑只对特定任务加载对应 Server。我在实际使用中会把常用的工具控制在 5 个以内。这 5 个工具是文件搜索、目录列表、代码检索、数据库自定义查询、HTTP 请求。其他能力都做成按需启动的临时 Server用的时候现挂。每少一个工具base token 就少一块。尤其要警惕那些描述写得又长又花哨的工具比如“本工具用于在结构化存储介质中执行高级语义检索操作支持自然语言输入与排序输出”这种描述对模型理解没有任何帮助反而白白占了 200 多个 token。5.2 给工具返回加“瘦身层”MCP Server 的数据返回体是可以通过客户端处理来瘦身的。我建议在 OpenClaw 调用 MCP 之后、把结果交给模型之前加一个轻量级中间层做三件事第一字段裁剪。只保留当前任务可能用到的字段。比如数据库查询如果只是要统计数量那就把数据行的详细内容去掉只返回一个数字。第二长度限制。给工具返回设置一个硬上限比如超过 2000 token 就截断并在末尾加一句“结果过长已截断可按需继续查询”。第三错误摘要。统一捕获异常返回精炼的错误信息。这三步做下来我的工具返回体平均减小了 70% 以上。效果最明显的是数据库查询类工具从动不动几千 token降到了几百 token 以内。5.3 上下文裁剪别让历史消息无限膨胀OpenClaw 默认会保留会话历史但对一个长期运行的 Agent 来说历史消息可能涉及几百轮工具调用。这些历史里的工具返回体如果不清理会像滚雪球一样越来越大。我的方案是给会话设置“上下文集装箱”每轮对话结束后把现有的历史做一次压缩。压缩策略很简单超过 20 轮之后把更早的消息摘要成几句话保留信息丢掉细节。工具调用记录这一类中间产物如果没有被明确标记为“重要”我会在下一次请求前清掉只保留模型最终的回复。有朋友问这样做会不会影响任务质量我的经验是大部分日常任务涉及的状态不超过最近 10 轮。更早的内容压缩成摘要并不会让模型“失忆”反而能让它更聚焦在当前任务上。如果你的任务确实长可以按任务类型做不同的上下文窗口策略而不是一刀切。5.4 模型和参数也要精打细算不是所有模型都适合跑 Agent。有些模型虽然单次 token 便宜但“理解工具调用”的能力弱导致 Agent 反复重试、多次修改参数反而更烧钱。我实测下来适合 MCP 场景的模型至少要满足两个条件一是能稳定输出结构化工具调用二是能遵守“只调用一次、不要反复尝试”的指令。此外max_tokens这个参数别设置得太大。控制模型输出的最大长度如果单次回复 200 token 就能完成任务就不要留 2000。这个参数很多人在纯聊天时不在意但在 Agent 场景下模型偶尔会“一本正经地废话”把输出撑得很长白白增加成本。温度和top_p也建议调低。Agent 任务不是创意写作温度太高会让模型产生不必要的发散回复。我一般设置 temperature 为 0.2 左右减少无效输出也能让工具调用更稳定。5.5 API 缓存和请求复用现在不少大模型 API 支持 prompt caching也就是如果请求里有相同的前缀内容后面相同的部分可以打折甚至免费。OpenClaw 这类框架也逐步在适配这个能力。要利用好缓存关键在于让每次请求的前缀尽可能稳定。这意味着固定系统提示词、固定工具定义、固定消息顺序尽量别在对话中途插入变化很大的内容。如果每次请求都在前面动态插一段“当前时间”“当前目录”这类高频变化的信息缓存就很难生效。我的做法是把系统提示词分两部分前面是完全静态的定义后面才是动态信息。静态部分尽量保持不变动态部分单独拼装。这样缓存命中率会明显提升账单上的“输入 token 费用”能降一截。6. 常见问题排查实录6.1 每次对话 token 翻倍但功能没变化这种现象十有八九是工具定义被重复注入导致的。排查思路是先看日志里每次请求的头几百个 token确认工具描述是否占据了很大比重。如果占了超过三分之一先精简工具数量再看看 MCP Server 的配置里是不是存在重复注册。我遇到过一次因为 OpenClaw 的一个 bug同一个 MCP Server 在配置解析时被加载了两次导致工具列表翻倍。排查方法就是在日志里搜 Server 的启动记录发现两行重复的注册信息。删掉重复项之后token 消耗立刻回到正常水平。6.2 工具返回 JSON 太大一次查询耗掉几千 token解决办法就是前面说的“瘦身层”。这里再补充一个技巧如果你没法改 MCP Server 的代码可以在 OpenClaw 的外部用一层 HTTP 代理包住 MCP Server在代理里做响应过滤。不要截断 JSON 的括号结构否则模型读到残缺的 JSON 可能产生误判最好的方式是只保留 key 而不打印所有 value。比如原始返回是{items: [{id: 1, desc: ......}, ...]}你可以改成{items: [{id: 1}, ...]}。这样模型能看到数据的结构和数量又不会被大段内容淹没。6.3 MCP 连接失败、超时的问题这类问题和 token 的关系是间接的但影响很大因为失败会触发重试重试就是重复计费。我自己遇到的常见原因是MCP Server 进程因为启动时缺少依赖而退出或者端口被占用。排查时先看 OpenClaw 日志里有没有 MCP 进程的退出码再手动在终端跑一遍npx命令确认 Server 能单独启动。另外凡是需要访问外部地址的 MCP Server都要考虑网络环境的可用性。网络不同、或者目标地址不可达时超时时间会拖得很长Agent 反复重试token 消耗会连续上涨。遇到报错信息里出现 token 相关字段的先看看时间戳那多半不是模型的问题而是网络请求本身超时了。6.4 工具循环调用停不下来这是 Agent 场景里最让人头大的问题。模型可能因为工具返回的结果不符合预期就一直重新调用同一个工具把对话活活拖成一场“无限循环”。每次循环都是一次完整请求token 消耗非常快。我的排查方法是三步第一在 OpenClaw 里设置单次任务的最大工具调用次数超过就强制结束第二检查工具返回的格式是否足够清晰模型如果看不清数据边界就会反复去“确认”第三检查工具描述里有没有让模型误解的措辞比如某个工具名为“query_all”描述又写“可获取所有信息”模型就会倾向于用它来试探所有问题。6.5 登录失效、token 刷新失败这类报错使用 OpenClaw 时经常遇到各种 token 相关的报错比如登录时提示 token exchange failed、刷新失败、或者“access token could not be refreshed”。这里说的 token和前面讨论的“消耗型 token”是两个概念前者是访问凭证后者是计费单位。很多人混在一起导致排查方向完全跑偏。遇到访问凭证类报错优先检查 API Key 或 OAuth 登录状态是否过期。如果日志里明确提示 token endpoint 返回了错误那就去对应服务商的状态页面确认当前认证服务是否正常同时确认本机时间和实际时间是否一致时钟偏移也会导致签名类错误。还有一个常见原因是多端登录互相踢掉会话把其他终端的登录状态清掉再重新认证基本就能解决。不要为了绕开认证限制去折腾任何不正规的访问方式合规使用 API 才最稳妥。这类报错本质上都是配置或凭证问题冷静排查就能定位。最后再分享一点我的体会搞过一轮 MCP 接入之后我现在对 Agent 的成本控制有了完全不同的理解。以前我总觉得“token 贵”是模型厂商的问题现在我发现更多时候是自己的架构浪费了太多 token。工具定义写得臃肿、返回体不瘦身、上下文不裁剪再便宜的大模型也扛不住这种消耗。我现在养成了一个习惯每周花 10 分钟把 OpenClaw 的日志导出来统计一下各 MCP 工具被调用的次数和平均 token 消耗。数据库查询工具如果一周只被调用了 3 次我就把它挪出常驻配置改成按需加载。文件搜索工具如果平均每次返回 1000 token 以上我就想办法加过滤参数。这套习惯坚持下来我的每月 token 账单大概降了 40%而且功能一点没少。如果你正要开始给 OpenClaw 接 MCP我的建议是别一口气接很多工具先接一个跑一周把 token 账单研究明白再决定要不要加下一个。工具不是越多越好少而精才是 Agent 场景下的省钱之道。
OpenClaw接入MCP后token翻倍？AI Agent的token优化实战
给 OpenClaw 接上 MCP 之后我做的第一件事不是测试工具好不好用而是打开 token 账单看了一眼。结果让我有点意外——原本一次很普通的对话比如“帮我查一下某个目录下的文件”在没有接入任何 MCP 工具之前可能只需要 1000 多个 token接上 MCP 之后同样的意图账单直接翻了好几倍。说实话OpenClaw 这个项目我关注了有一阵子。它本质上是一个本地优先的 AI Agent 框架你可以把它理解成一个“带手带脚的 AI 助手底座”装好之后它能读文件、执行命令、操作各种软件再通过 MCP 这样的标准协议把你想要接入的外部能力数据库、浏览器、绘图软件、IDE 等一个个挂上去。MCP 全称 Model Context Protocol是一种给大模型“接外设”的开放协议社区里也常叫它“AI 应用的 USB 接口”。把 OpenClaw 和 MCP 接在一起就是让 Agent 拥有更多可调用的真实工具。但这套组合有一个绕不开的代价token。每次对话模型都要把工具清单、历史记录、返回结果全部重新读一遍这些看不见的消耗确实在偷偷烧钱。1. 先把基础拆清楚OpenClaw、MCP、token 到底怎么配合1.1 OpenClaw 是干嘛的OpenClaw 在社区里通常被定位成一个开源的 Agent 运行时。它和那种“网页上聊两句就完事”的 AI 不一样它跑在你自己的机器上可以真正操作你的文件系统、终端和软件。我身边不少朋友把它当成一个可以自己改造的“私人助理”有人拿它做自动化日报有人让它定时整理下载目录还有人用它去控制本地开发环境里的编译任务。它的核心优势在于“可编排”。OpenClaw 提供了一套技能Skill系统和工具调用机制你不需要每次都在 Prompt 里写大段指令而是把常用能力封装成可复用的模块。比如我可以告诉它“扫描某个目录下的所有 Python 文件”它就能基于这套封装去做。对我这种不爱反复写提示词的人来说这个设计比裸调 API 顺手得多。不过也有不少人刚接触时会困惑一点OpenClaw 本身不内置某个大模型它更像一个“调度中枢”。真正做推理和决策的是后面接的大模型 API。所以你问“OpenClaw 只能用接入 API 的方式使用算力吗”答案是目前主流用法确实是接 API本地小模型也能试但效果和速度差别很大。这也解释了为什么 token 问题在 OpenClaw 场景下会被放大——每个决策都要经过大模型而大模型的每次“思考”都要花钱。1.2 MCP 到底是什么MCP 是 Anthropic 在 2024 年底提出来的一套开放协议现在已经被大量 AI 工具支持。它的思路很直接让大模型和外部工具之间有一个统一的“插拔接口”。以前你想让 AI 读数据库、操作浏览器、调用某个软件每个都要单独写集成代码有了 MCP工具方只要实现一个 MCP Server任何支持 MCP 的客户端都能直接调用。你可以把它类比成电脑上的 USB 接口。键盘、鼠标、U盘各自的驱动和协议都不同但通过 USB 这个统一标准插上就能用。MCP 对 AI 应用来说就是这个 USB 口OpenClaw 是主机MCP Server 是外设两者之间走的是标准化的 JSON-RPC 消息。在 OpenClaw 里接 MCP意味着我不需要关心某个工具内部是怎么实现的只要在配置里写上 Server 地址和参数Agent 就能在需要时自动调用它。听起来很美对吧但问题恰恰出在“自动调用”这四个字上——每次调用都要付出 token 成本。1.3 token 这个“计价单位”为什么敏感token 是大模型处理文本的最小单位。中文一个字大概对应 1 到 2 个 token英文一个单词通常 1 到 3 个 token。模型计费时不但计算你发送过去的内容也算它回复的内容而且很多 API 是按总 token 数阶梯计费的。关键在于Agent 的每一轮对话并不像普通聊天那样只发一次请求。OpenClaw 接到你的问题后会先调用模型“想一下该怎么做”然后模型可能决定调用某个 MCP 工具工具执行完返回结果模型再看结果继续推理可能又调用下一个工具……这个循环每走一步都要把“到目前为止的全部对话历史”重新发给模型一次。也就是说同样的内容模型实际上看了好几遍每一遍都计费。我在实际操作里第一次意识到这个问题是在接入了一个文件搜索 MCP 之后。我只是问了一句“找一下上周生成的日志”结果后台日志显示模型先看了一遍工具列表选定了搜索工具又看了一遍搜索参数说明然后工具返回了一个很长的文件清单模型又把那个清单完整读了一遍最后才给我总结。整个流程消耗的 token是我预想中的 5 倍以上。所以给 OpenClaw 接 MCP 这件事本质上是在“能力”和“成本”之间做平衡。工具越多、返回数据越臃肿单次对话的 token 就越大。2. 我接 MCP 的完整过程以及接入后踩到的第一个坑2.1 环境准备先让 OpenClaw 跑起来我用的是一台 Ubuntu 22.04 的机器8 核 CPU、16G 内存跑 OpenClaw 和几个轻量 MCP Server 完全够。安装过程不复杂官方提供了一键安装脚本本质上是拉取依赖、初始化配置目录、生成默认配置文件。装好后OpenClaw 会在用户目录下创建一个.openclaw文件夹里面放着config.json和skills/目录。Windows 上我也装过一遍步骤稍微多两步需要先确保 Python 3.10 和 Node.js 18 都装好因为 OpenClaw 本身是 Python 写的但很多 MCP Server 是 Node.js 写的。这里提醒一句如果你在 Windows 上配置 OpenClaw建议用 WSL 2 而不是原生 Windows 环境省得多很多权限和路径问题。跑起来之后我建议先做三件事第一确认 OpenClaw 自带的基础命令能用比如让它帮你列一下当前目录第二看日志输出是否正常确保没有奇怪的报错第三手动在配置里指定你打算用的模型不要用默认值。默认模型不一定是最经济的后面会细说。2.2 给 OpenClaw 挂上第一个 MCP Server配置 MCP Server 的入口在 OpenClaw 的config.json里。一个典型的配置片段长这样{ mcpServers: { filesystem: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, /tmp/demo], env: {} } } }这段配置的意思是启动一个名为filesystem的 MCP Server通过npx运行官方的文件系统工具包并且只允许它访问/tmp/demo这个目录。保存配置后重启 OpenClaw再用一句“帮我看看 /tmp/demo 里有什么文件”来验证如果它正确列出了文件就说明 MCP 接通了。这里有个容易被忽略的小细节args里最后那个路径决定了这个 MCP Server 能访问的目录范围。我第一次配置时贪方便写了/结果工具返回时动不动就把整个根目录的子目录名带出来既浪费 token 又暴露了不必要的信息。后来我一律改成只给工具一个最小可用的目录安全性和 token 开销都改善了很多。2.3 接入后先别急着用看一眼日志我通常的做法是接好一个新 MCP Server 后先开一个空对话问它“你现在能做什么”然后把日志里显示的 token 统计复制下来。这一步不是为了好玩而是建立一个基准线。没有这个基准后面你是很难判断到底是哪次改动把 token 烧上去的。我接第二个 MCP Server一个数据库查询工具时就是因为没做基准测试排查了很久才发现问题不在工具本身而在于工具注册时带了一大段 description这段描述被模型当成了参考文档每次对话都会完整读一遍。所以现在我的习惯是每加一个工具都先看一眼“空对话时模型的 tool schema 占了多少 token”。这个数据在你自己的 API 调用日志、或者 OpenClaw 的调试模式里都能看到。3. 每次对话里token 到底烧在了哪些环节3.1 “名片费用”工具清单被反复发送大模型并不知道你有多少工具可用它每次收到请求时都要靠请求里的工具描述去理解“你有这些能力”。OpenClaw 也一样它会把所有已注册的 MCP 工具连同工具的名称、描述、参数结构一起塞进给模型的系统消息里。这就是我前面说的“名片费用”。每接一个 MCP Server只要里面注册了 5 个工具那你的请求里就多出 5 张名片。名片越精致——描述越详细、参数结构越复杂——token 就越多。我接的那个数据库 MCP单个工具的描述里写了一长串示例 SQL 和字段说明光那个工具的 schema 就占了 800 多个 token。当时我没注意直到对比账单才反应过来。更麻烦的是这个“名片”是在每一轮请求里都会出现的不是只付一次钱。建议你在配置 MCP Server 时先看看它到底注册了哪些工具。如果有些工具你根本不会用到就要想办法在 Server 端过滤掉或者干脆不注册。3.2 上下文累积效应对话越长单次请求越贵这是 Agent 场景里最隐蔽的烧钱点。普通聊天时只发最近的几轮消息但 Agent 要保证任务连续性通常会把“系统提示词 工具定义 历史消息 当前输入 各轮工具调用记录”全部放在一次请求里。拿我刚才那个“查上周日志”的例子来说具体消耗大概是这样的第一次请求系统提示词含工具列表约 1200 token加上用户问题 50 token共 1250 token。模型回复说“我要调用文件搜索工具”这段回复约 100 token。OpenClaw 执行搜索把工具返回的 3000 字文件清单作为 tool message 拼进上下文。此时新的请求变成1200 50 100 3000 4350 token。模型读到文件清单后又回复“我找到了这些是上周的日志”约 80 token。如果你接着问“里面最大的文件是哪个”下一次请求就是 1200 50 100 3000 80 你的新问题 30 4460 token。可以看到工具返回的那 3000 token在后面的每一轮对话里都会被反复计算。这就是为什么同样一段对话越聊到后面单次请求的 token 就越高。很多人觉得“我也没说多少句话啊怎么账单这么高”原因就在这里。3.3 “工具返回体”是最大的变量工具返回的内容是这些环节里弹性最大的。有的 MCP Server 设计得比较粗糙不管用户要什么一查就返回一堆字段。比如那个数据库工具我让它查“用户表有多少行”它把整个表结构连同索引信息都返回了光这几百行文本就占了 4000 token。MCP 协议本身不会限制返回体的大小所以这个坑只能自己踩。我在 OpenClaw 里加了一个中间层逻辑调用 MCP 之后先做一次结果预处理把明显无关的字段删掉再交给模型。这样做之后同样一个数据库查询从 4000 token 降到了 600 左右效果立竿见影。另外一个容易忽略的点是工具返回的错误信息也占用 token。MCP Server 一旦报错会把整个堆栈信息返回给 AgentAgent 再把这些错误信息读一遍试图“理解”。遇到这种情况最好的办法是服务端捕获异常后只返回一句话级别的错误摘要而不是原始堆栈。3.4 失败重试与流式输出的重复计费MCP 调用不是每次都能一次成功的。超时、连接失败、Server 端没安装依赖、参数不对都会导致调用失败。失败本身不一定是大问题问题是 Agent 在失败后往往会自动重试。每次重试都意味着一次完整的模型往返而这几次往返里前面已经消耗掉的历史上下文都会再算一遍。我实测过一个场景某个 MCP Server 因为端口被占用启动失败OpenClaw 不知道它挂了还是尝试调用它结果连续重试了 4 次才报错。那 4 次重试每次都要重新发送同样的上下文和工具定义等于把同一次请求的钱付了 4 遍。流式输出同样要小心。OpenClaw 在调用部分大模型 API 时默认开启流式输出便于实时显示回复。流式本身不额外收费但如果你的上层还做了日志记录、结果备份、或者消息监听这些数据在传输和处理时也可能被重复统计。虽然这部分通常比较小但积少成多。4. 实测数据三组对话的 token 账单对比4.1 我设计的三个测试场景为了把问题讲清楚我做了一个简单但真实的对照测试。用的模型是某主流 API 的中档模型计费规则是输入 0.15 美元/百万 token输出 0.6 美元/百万 token。OpenClaw 版本是最新的稳定版MCP 工具接入了一个文件搜索工具和一个数据库查询工具。三个场景分别是场景 A不接入任何 MCP 工具纯粹聊天问三个问题。场景 B接入 MCP但只问一个不需要调用工具的问题比如“11 等于几”。场景 C接入 MCP问一个需要调用工具的问题比如“列出 /tmp/demo 下的文件”。每个场景都从零开始新会话记录完整的一次“问题-回答”过程的 token 消耗。4.2 结果和我的分析测试结果如下表场景单次请求 token调用 MCP 次数总 token估算成本A无 MCP6500650约 0.0002 美元B有 MCP 但不调用185001850约 0.0006 美元C有 MCP 且调用一次540015400约 0.002 美元如果只看 C这个成本貌似也不高。但要注意这是单次任务、新会话、并且只调用了一次工具的理想情况。真实使用中一个稍微复杂点的任务会调用 3 到 5 次工具再加上后续追问一个任务跑下来 3 万到 5 万 token 是很常见的。再把场景 B 和 A 对比就能很清楚地看到“工具定义”本身的成本明明什么都没干只是多挂了一个 MCP Server单次请求 token 就从 650 涨到了 1850。如果你同时挂了 5 个 MCP Server每个都带一堆工具那这个基础开销会非常可观。4.3 手动算一笔账假设我每天用 OpenClaw 处理 20 个任务每个任务平均 30 万 token这个数字在重度使用时并不夸张按混合费率每百万 token 大概 0.3 美元算一天就是 9 美元一个月 270 美元。我见过一个团队把 OpenClaw 当团队 Bot 用接了十几个 MCP Server一个月 token 账单直接冲到四位数人民币。他们一开始也搞不懂钱去哪了后来把日志翻出来才发现工具定义和重复调用占了超过 60% 的消耗。所以这不是一个可以忽略的“小钱”。给 Agent 做 token 预算和给服务器做资源预算一样是正经要花时间的事情。5. 降低 token 消耗的几招招招能落地5.1 精简 MCP 工具注册不是越多越好第一原则只注册必要的工具。MCP Server 打开后通常会把它内部所有的工具都暴露出来。但你的日常任务可能只需要其中两三个。OpenClaw 这边如果你无法在配置层面直接过滤工具有两个替代办法一是用不同的配置 profile把工具分组二是通过 Skill 层的逻辑只对特定任务加载对应 Server。我在实际使用中会把常用的工具控制在 5 个以内。这 5 个工具是文件搜索、目录列表、代码检索、数据库自定义查询、HTTP 请求。其他能力都做成按需启动的临时 Server用的时候现挂。每少一个工具base token 就少一块。尤其要警惕那些描述写得又长又花哨的工具比如“本工具用于在结构化存储介质中执行高级语义检索操作支持自然语言输入与排序输出”这种描述对模型理解没有任何帮助反而白白占了 200 多个 token。5.2 给工具返回加“瘦身层”MCP Server 的数据返回体是可以通过客户端处理来瘦身的。我建议在 OpenClaw 调用 MCP 之后、把结果交给模型之前加一个轻量级中间层做三件事第一字段裁剪。只保留当前任务可能用到的字段。比如数据库查询如果只是要统计数量那就把数据行的详细内容去掉只返回一个数字。第二长度限制。给工具返回设置一个硬上限比如超过 2000 token 就截断并在末尾加一句“结果过长已截断可按需继续查询”。第三错误摘要。统一捕获异常返回精炼的错误信息。这三步做下来我的工具返回体平均减小了 70% 以上。效果最明显的是数据库查询类工具从动不动几千 token降到了几百 token 以内。5.3 上下文裁剪别让历史消息无限膨胀OpenClaw 默认会保留会话历史但对一个长期运行的 Agent 来说历史消息可能涉及几百轮工具调用。这些历史里的工具返回体如果不清理会像滚雪球一样越来越大。我的方案是给会话设置“上下文集装箱”每轮对话结束后把现有的历史做一次压缩。压缩策略很简单超过 20 轮之后把更早的消息摘要成几句话保留信息丢掉细节。工具调用记录这一类中间产物如果没有被明确标记为“重要”我会在下一次请求前清掉只保留模型最终的回复。有朋友问这样做会不会影响任务质量我的经验是大部分日常任务涉及的状态不超过最近 10 轮。更早的内容压缩成摘要并不会让模型“失忆”反而能让它更聚焦在当前任务上。如果你的任务确实长可以按任务类型做不同的上下文窗口策略而不是一刀切。5.4 模型和参数也要精打细算不是所有模型都适合跑 Agent。有些模型虽然单次 token 便宜但“理解工具调用”的能力弱导致 Agent 反复重试、多次修改参数反而更烧钱。我实测下来适合 MCP 场景的模型至少要满足两个条件一是能稳定输出结构化工具调用二是能遵守“只调用一次、不要反复尝试”的指令。此外max_tokens这个参数别设置得太大。控制模型输出的最大长度如果单次回复 200 token 就能完成任务就不要留 2000。这个参数很多人在纯聊天时不在意但在 Agent 场景下模型偶尔会“一本正经地废话”把输出撑得很长白白增加成本。温度和top_p也建议调低。Agent 任务不是创意写作温度太高会让模型产生不必要的发散回复。我一般设置 temperature 为 0.2 左右减少无效输出也能让工具调用更稳定。5.5 API 缓存和请求复用现在不少大模型 API 支持 prompt caching也就是如果请求里有相同的前缀内容后面相同的部分可以打折甚至免费。OpenClaw 这类框架也逐步在适配这个能力。要利用好缓存关键在于让每次请求的前缀尽可能稳定。这意味着固定系统提示词、固定工具定义、固定消息顺序尽量别在对话中途插入变化很大的内容。如果每次请求都在前面动态插一段“当前时间”“当前目录”这类高频变化的信息缓存就很难生效。我的做法是把系统提示词分两部分前面是完全静态的定义后面才是动态信息。静态部分尽量保持不变动态部分单独拼装。这样缓存命中率会明显提升账单上的“输入 token 费用”能降一截。6. 常见问题排查实录6.1 每次对话 token 翻倍但功能没变化这种现象十有八九是工具定义被重复注入导致的。排查思路是先看日志里每次请求的头几百个 token确认工具描述是否占据了很大比重。如果占了超过三分之一先精简工具数量再看看 MCP Server 的配置里是不是存在重复注册。我遇到过一次因为 OpenClaw 的一个 bug同一个 MCP Server 在配置解析时被加载了两次导致工具列表翻倍。排查方法就是在日志里搜 Server 的启动记录发现两行重复的注册信息。删掉重复项之后token 消耗立刻回到正常水平。6.2 工具返回 JSON 太大一次查询耗掉几千 token解决办法就是前面说的“瘦身层”。这里再补充一个技巧如果你没法改 MCP Server 的代码可以在 OpenClaw 的外部用一层 HTTP 代理包住 MCP Server在代理里做响应过滤。不要截断 JSON 的括号结构否则模型读到残缺的 JSON 可能产生误判最好的方式是只保留 key 而不打印所有 value。比如原始返回是{items: [{id: 1, desc: ......}, ...]}你可以改成{items: [{id: 1}, ...]}。这样模型能看到数据的结构和数量又不会被大段内容淹没。6.3 MCP 连接失败、超时的问题这类问题和 token 的关系是间接的但影响很大因为失败会触发重试重试就是重复计费。我自己遇到的常见原因是MCP Server 进程因为启动时缺少依赖而退出或者端口被占用。排查时先看 OpenClaw 日志里有没有 MCP 进程的退出码再手动在终端跑一遍npx命令确认 Server 能单独启动。另外凡是需要访问外部地址的 MCP Server都要考虑网络环境的可用性。网络不同、或者目标地址不可达时超时时间会拖得很长Agent 反复重试token 消耗会连续上涨。遇到报错信息里出现 token 相关字段的先看看时间戳那多半不是模型的问题而是网络请求本身超时了。6.4 工具循环调用停不下来这是 Agent 场景里最让人头大的问题。模型可能因为工具返回的结果不符合预期就一直重新调用同一个工具把对话活活拖成一场“无限循环”。每次循环都是一次完整请求token 消耗非常快。我的排查方法是三步第一在 OpenClaw 里设置单次任务的最大工具调用次数超过就强制结束第二检查工具返回的格式是否足够清晰模型如果看不清数据边界就会反复去“确认”第三检查工具描述里有没有让模型误解的措辞比如某个工具名为“query_all”描述又写“可获取所有信息”模型就会倾向于用它来试探所有问题。6.5 登录失效、token 刷新失败这类报错使用 OpenClaw 时经常遇到各种 token 相关的报错比如登录时提示 token exchange failed、刷新失败、或者“access token could not be refreshed”。这里说的 token和前面讨论的“消耗型 token”是两个概念前者是访问凭证后者是计费单位。很多人混在一起导致排查方向完全跑偏。遇到访问凭证类报错优先检查 API Key 或 OAuth 登录状态是否过期。如果日志里明确提示 token endpoint 返回了错误那就去对应服务商的状态页面确认当前认证服务是否正常同时确认本机时间和实际时间是否一致时钟偏移也会导致签名类错误。还有一个常见原因是多端登录互相踢掉会话把其他终端的登录状态清掉再重新认证基本就能解决。不要为了绕开认证限制去折腾任何不正规的访问方式合规使用 API 才最稳妥。这类报错本质上都是配置或凭证问题冷静排查就能定位。最后再分享一点我的体会搞过一轮 MCP 接入之后我现在对 Agent 的成本控制有了完全不同的理解。以前我总觉得“token 贵”是模型厂商的问题现在我发现更多时候是自己的架构浪费了太多 token。工具定义写得臃肿、返回体不瘦身、上下文不裁剪再便宜的大模型也扛不住这种消耗。我现在养成了一个习惯每周花 10 分钟把 OpenClaw 的日志导出来统计一下各 MCP 工具被调用的次数和平均 token 消耗。数据库查询工具如果一周只被调用了 3 次我就把它挪出常驻配置改成按需加载。文件搜索工具如果平均每次返回 1000 token 以上我就想办法加过滤参数。这套习惯坚持下来我的每月 token 账单大概降了 40%而且功能一点没少。如果你正要开始给 OpenClaw 接 MCP我的建议是别一口气接很多工具先接一个跑一周把 token 账单研究明白再决定要不要加下一个。工具不是越多越好少而精才是 Agent 场景下的省钱之道。