企业官网建设流程全解析

1. 从一次账单异常说起：OpenClaw 接 MCP 的 token 消耗真相

第一次发现不对劲，是月底翻 API 账单的时候。我明明只是拿 OpenClaw 做几个日常的代码问答和文档整理，结果 token 用量比上个月翻了将近三倍。当时第一反应是模型调用变多了，但仔细一查日志，发现真正的问题出在我给它接上 MCP 之后——每次对话都在偷偷烧 token，而且烧得毫无知觉。

这个现象其实不是 OpenClaw 独有的。任何支持 MCP（Model 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 工具选择阶段的"试探性调用"

第四个出口跟模型行为有关。当工具很多、描述又相似时，模型经常会出现"试探性调用"——先调一个看看返回啥，不对再调另一个。这种来回试探，每次都是一轮完整的请求加返回。工具描述写得越模糊，这种浪费越严重。

把这四个出口列个表，你就能直观看到钱花在哪了：

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 速查表

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 变强，但强是有代价的。搞清楚代价花在哪，才能既享受能力，又不被账单追着跑。