1. OpenClaw 的 Token 消耗到底花在哪：工具调用与记忆检索场景拆解

OpenClaw 的 Token 消耗计算，是很多刚接触 Agent 框架的朋友最容易被账单吓到的地方。它不是一个「问一句答一句」的聊天机器人，而是一个会自己拆任务、调工具、翻记忆、写文件的自动化代理。你给它一句「帮我整理接口文档并发到群里」，它背后可能跑了五六次模型请求，每次请求都带着一大坨上下文。所以理解 OpenClaw 的 Token 消耗怎么计算，核心不是背公式，而是搞清楚「一次 Agent 回合里，到底有几次 LLM 调用、每次调用塞了什么东西」。

先给一个能直接用的估算公式，后面所有优化都围绕它展开：

单次请求输入 Token ≈ System Prompt + 工具定义 Schema + 会话历史 + 记忆检索结果 + 工具调用链上下文 总消耗 = Σ(每次请求输入 Token) + Σ(每次响应输出 Token)

这里的关键认知是：OpenClaw 的 Token 消耗是「多轮叠加」的。一个用户指令可能触发 3 到 8 次内部 LLM 调用，每次调用都会重新拼一遍 System Prompt 和工具定义。也就是说，固定开销不是花一次，而是花 N 次。很多人觉得 OpenClaw 费 Token，本质是把「一次对话」当成了「一次请求」，实际账单是乘了系数的。

适合谁看这篇：正在用 OpenClaw 做自动化任务、发现配额掉得比预期快、想在不砍功能的前提下把成本压下来的开发者。下面我会按「固定开销 → 动态开销 → 隐形开销」三层拆，每一层都给可复制的配置片段和验证动作。

先看固定开销的构成，这部分每次请求都逃不掉：

固定开销单次大概在 1250 到 6250 Token 之间浮动，浮动的大头就是 Bootstrap 文件和 Skills。你把bootstrapMaxChars从 20000 调到 8000，单次就能省下约 3000 Token；再关掉几个用不上的工具，又能省 700 到 900 Token。这些数字看着不大，但乘以每天几十上百次内部调用，差距就出来了。

动态开销才是真正的大头，主要来自三块：会话历史累积、记忆检索结果注入、工具调用链的往返。会话历史这块，OpenClaw 默认的压缩阈值设得很高，往往要累积到模型上下文窗口的 88% 才触发压缩。用 32K 上下文的模型，意味着要堆到接近 28000 Token 才开始瘦身，这期间每轮请求都拖着这一大坨历史。记忆检索则是每次memory_search把匹配到的片段全量塞进上下文，查得越频繁、返回越多，输入 Token 涨得越快。工具调用链更直接，一次任务里 read、memory_search、message 连着调，每次调用都是独立的请求加响应双向计费。

理解了这三层，优化就有了明确靶子：压固定开销、控动态累积、砍隐形调用。下一节先讲怎么把 TaoToken 这类模型接入层配好，因为模型选型和接入方式直接决定了你的单价和可用上下文窗口，是后面所有优化的前提。

2. TaoToken 前置配置：把模型接入层搭好再谈省 Token

在动手优化 OpenClaw 的 Token 消耗之前，得先把模型接入层理顺。原因很实在：OpenClaw 支持自定义模型提供方，你选的模型、配的上下文窗口、走的接入地址，直接决定了单 Token 单价和你能用的最大上下文。如果接入层没配好，后面调contextCompactionThreshold或者换模型都会卡在「连不上」或者「模型 ID 不认」这种低级问题上。

TaoToken 在这里扮演的是统一模型接入层的角色。它提供 OpenAI 兼容的接口格式，OpenClaw 里配置自定义 provider 时，只要填对 Base URL、API Key、Model ID 三件套就能跑通。官网入口是 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 地址是 https://taotoken.net/api ，注意 API 地址不带 UTM 参数，配置时别把跟踪参数拼进去，否则可能 404。

先说清楚为什么值得单独配一层接入。OpenClaw 的 Agent 回合里内部调用次数多，如果每次都直连不同厂商、每个厂商一套鉴权和计费口径，排查 Token 消耗时你根本对不上账。统一走一个兼容层，所有请求的输入输出 Token 都能在一个地方看，定位高消耗环节会快很多。而且模型可以随时切换，今天用便宜的小模型跑记忆检索，明天换强模型跑主推理，配置改一行就行。

配置前你需要准备三样东西：一个可用的 API Key、确认要用的 Model ID、以及 OpenClaw 的配置文件路径。OpenClaw 的配置通常放在项目根目录的openclaw.json，或者用户目录下的~/.openclaw/config.json，具体看你安装方式。先确认配置文件位置：

# 查看 OpenClaw 当前使用的配置文件路径 openclaw config path # 列出当前已配置的模型 provider openclaw config get models.providers

如果输出为空或者没有你想要的 provider，就手动加。下面是一个完整的 provider 配置片段，直接复制到openclaw.json的models段里：

{ "models": { "default": "gpt-4o-mini", "providers": { "taotoken": { "baseUrl": "https://taotoken.net/api", "apiKey": "sk-你的实际Key", "models": [ "gpt-4o-mini", "claude-3-5-sonnet", "deepseek-chat" ] } } } }

这里baseUrl一定写https://taotoken.net/api，不要带任何查询参数。apiKey换成你在控制台生成的那串。models数组里列你打算用的 Model ID，OpenClaw 启动时会校验这些 ID 是否可用。配好之后，把默认模型指过去：

openclaw config set models.default "gpt-4o-mini" openclaw config set models.providers.taotoken.apiKey "sk-你的实际Key"

如果你更习惯用环境变量管理密钥，OpenClaw 也支持从环境变量读取。在openclaw.json里把apiKey写成"${TAOTOKEN_API_KEY}"，然后在 shell 里 export：

export TAOTOKEN_API_KEY="sk-你的实际Key"

这样密钥不会硬编码进配置文件，提交到 git 也安全。配完之后别急着跑任务，先做一次最小验证，确认接入层通了。用 OpenClaw 自带的模型探测命令：

openclaw models test --provider taotoken --model gpt-4o-mini

正常会返回一个简短的响应和 Token 用量。如果这一步就报 401，说明 Key 不对或者没生效；报连接超时，检查baseUrl有没有拼错。这一步过了，再进下一节做完整的请求验证和 Token 观测。

关于模型选型，给一个实操建议：主推理用能力强的模型，记忆检索和 Memory Flush 这类辅助调用换成便宜的小模型。OpenClaw 支持给不同用途指定不同模型，后面第五节会讲具体怎么配。现在先把接入层跑通，这是所有优化的地基。

3. 可复制配置：工具调用与记忆检索的 Token 优化片段

这一节是全文最核心的部分，直接给可复制的配置。所有片段都基于 OpenClaw 的openclaw.json结构，路径和字段名保持一致，你复制过去改改值就能用。优化思路分三块：砍固定开销、控会话历史、调记忆检索。

先看工具定义的优化。OpenClaw 默认启用一堆工具，每个工具的 JSON Schema 都会在每次请求时发给模型。实测下来，browser、cron、canvas、nodes这四个在纯文本处理或单 Agent 场景里大概率用不上，禁用它们单次能省 1500 到 2000 Token。配置片段：

{ "tools": { "browser": { "enabled": false }, "cron": { "enabled": false }, "canvas": { "enabled": false }, "nodes": { "enabled": false }, "exec": { "enabled": false }, "memory_search": { "enabled": true }, "memory_get": { "enabled": true }, "read": { "enabled": true }, "write": { "enabled": true }, "message": { "enabled": true } } }

注意memory_search和memory_get别关，关了记忆功能直接失效。exec是高危工具，如果你不需要 Agent 执行 shell 命令，关掉既省 Token 又安全。命令行等价操作：

openclaw config set tools.browser.enabled false openclaw config set tools.cron.enabled false openclaw config set tools.canvas.enabled false openclaw config set tools.nodes.enabled false

接着压 Bootstrap 文件和压缩阈值。Bootstrap 文件默认全量加载，AGENTS.md、SOUL.md、IDENTITY.md加起来能到 20000 字符。如果你只用一个AGENTS.md就够，把上限调下来：

{ "agents": { "defaults": { "bootstrapMaxChars": 8000, "contextCompactionThreshold": 0.7, "skills": { "enabled": ["text-processing", "file-ops"] } } } }

bootstrapMaxChars从 20000 降到 8000，单次省约 3000 Token。contextCompactionThreshold从默认的 0.88 降到 0.7，意味着会话历史累积到上下文窗口 70% 就触发压缩，不会拖到快爆了才瘦身。skills.enabled只列你真正用的技能包，没列的不加载，Skills 提示那部分字符量直接归零。

然后是记忆检索的优化，这块最容易被忽略但累积起来很吓人。memory_search每次返回的结果全量进上下文，默认minScore是 0.35，意味着匹配度 0.36 的片段也会塞进去。把它提到 0.5，过滤掉一批弱相关结果：

{ "memory": { "search": { "minScore": 0.5, "maxResults": 5 }, "flush": { "enabled": false, "softThresholdTokens": 6000 } } }

maxResults限制单次检索返回条数，默认可能返回十几条，压到 5 条能显著减少注入的 Token。flush.enabled设为 false 是关掉自动 Memory Flush，改成手动触发。Memory Flush 本身是一次独立的 LLM 调用，会完整消耗一遍 System Prompt 加工具定义，频繁触发就是隐形烧钱。关掉自动后，你可以在任务间隙手动调一次压缩。

最后是模型分层配置，让辅助调用走便宜模型：

{ "models": { "default": "gpt-4o-mini", "taskOverrides": { "memory_flush": "gpt-4o-mini", "memory_search_rerank": "gpt-4o-mini", "main_reasoning": "claude-3-5-sonnet" } } }

主推理用强模型保证任务质量，记忆整理和检索重排这种辅助活交给便宜模型，成本能降一大截。把上面所有片段合并进openclaw.json，保存后重启 OpenClaw 让配置生效。下一节验证这些改动到底省了多少。

4. 验证请求与成功结果：用日志和 Token 计数确认优化生效

配置改完不能凭感觉说「应该省了」，得拿数据说话。OpenClaw 提供了几种观测 Token 消耗的方式，这一节带你一步步验证，顺便把「怎么算」这件事落到实操上。

第一步，开启请求日志。OpenClaw 默认不打印每次请求的 Token 用量，需要手动打开 debug 级别的日志：

openclaw config set logging.level "debug" openclaw config set logging.logTokens true

重启后，每次内部 LLM 调用都会在日志里输出输入输出 Token 数。日志通常落在~/.openclaw/logs/下，按日期分文件。跑一个简单任务，然后 grep 出 Token 相关行：

openclaw run "读取 api/LoginInterface.json 并总结字段" grep -i "token" ~/.openclaw/logs/openclaw-$(date +%Y-%m-%d).log | tail -20

你会看到类似这样的输出：

[LLM] provider=taotoken model=gpt-4o-mini input_tokens=4820 output_tokens=312 [LLM] provider=taotoken model=gpt-4o-mini input_tokens=5310 output_tokens=88 [LLM] provider=taotoken model=gpt-4o-mini input_tokens=210 output_tokens=145

三行对应三次内部调用：第一次是主推理，第二次是工具调用后的续推，第三次是记忆检索的辅助调用。把 input_tokens 加起来就是这次任务的总输入消耗。优化前同样的任务，第一行 input_tokens 可能在 8000 以上，优化后降到 4800 左右，降幅约 40%。

第二步，用 OpenClaw 的用量统计命令看汇总：

openclaw usage --today openclaw usage --since "2026-03-01" --group-by model

输出会按模型和日期聚合 Token 用量，方便你对比优化前后的日均消耗。如果你走的是 TaoToken 接入层，也可以在控制台的用量页面看到按 Key 维度的调用记录，两边数据对得上就说明统计口径一致。

第三步，验证记忆检索的优化效果。故意问一个需要翻历史的问题，观察检索结果注入的 Token：

openclaw run "我上次配置的模型参数是什么" grep -A2 "memory_search" ~/.openclaw/logs/openclaw-$(date +%Y-%m-%d).log

优化前，memory_search可能返回 8 到 10 条结果，注入约 600 到 800 Token；把minScore提到 0.5、maxResults压到 5 之后，通常只剩 2 到 3 条强相关结果，注入降到 200 Token 以内。这一步的验证很关键，因为记忆检索的消耗是「温水煮青蛙」，不专门看日志根本察觉不到。

第四步，确认工具禁用生效。跑一个本该触发 browser 的任务，看日志里还有没有 browser 的 Schema：

grep -i "browser" ~/.openclaw/logs/openclaw-$(date +%Y-%m-%d).log

如果没有任何输出，说明 browser 工具定义已经不再注入请求，固定开销确实降了。如果还有，检查openclaw.json里tools.browser.enabled是不是被其他配置覆盖了，OpenClaw 的配置优先级是「项目配置 > 用户配置 > 默认值」，确认你改的是生效的那一层。

做完这四步，你手里就有了一份优化前后的 Token 对比数据。实测下来，把固定开销压一压、会话阈值调一调、记忆检索收一收，整体消耗降 30% 到 50% 是能稳定做到的，而且不影响核心功能。如果某一步没达到预期，下一节列了几个常见报错和排查方向。

5. 本篇常见错排查：401、local proxy failed、reading choices 逐个解决

优化过程中最容易卡住的不是配置本身，而是各种报错。这一节把 OpenClaw 接入和 Token 优化场景下高频出现的几个错误拎出来，给对照的排查步骤。

报错一：401 Unauthorized

这是接入层最常见的错误，日志里长这样：

[LLM] error: 401 Unauthorized - invalid api key

排查顺序：先确认openclaw.json里models.providers.taotoken.apiKey填的是完整 Key，没有多余空格或换行。如果你用的是环境变量${TAOTOKEN_API_KEY}，确认 shell 里echo $TAOTOKEN_API_KEY能打印出值，且启动 OpenClaw 的终端和 export 的终端是同一个。再检查baseUrl是不是写成了https://taotoken.net/api，末尾不要加斜杠，也不要拼 UTM 参数。最后用 curl 直接测一下 Key 是否有效：

curl -s https://taotoken.net/api/v1/models \ -H "Authorization: Bearer sk-你的Key" | head -20

返回模型列表说明 Key 没问题，问题在 OpenClaw 配置层；返回 401 说明 Key 本身失效，去控制台重新生成。

报错二：local proxy failed / connection refused

[LLM] error: local proxy failed - dial tcp 127.0.0.1:7890: connect: connection refused

这个错误说明 OpenClaw 在尝试走本地代理端口，但那个端口没有服务在监听。常见原因是之前配过HTTP_PROXY或HTTPS_PROXY环境变量，后来代理关了但变量还在。检查并清掉：

env | grep -i proxy unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

然后在openclaw.json里确认没有proxy相关字段。清掉之后重启 OpenClaw，请求会直连baseUrl，不再走本地端口。

报错三：reading choices - unexpected end of JSON input

[LLM] error: reading choices: unexpected end of JSON input

这个错误通常出现在响应体被截断的时候。原因可能是max_tokens设得太小，模型输出到一半被切断，JSON 不完整；也可能是网络中断导致响应没收全。先检查配置里的输出上限：

{ "models": { "maxOutputTokens": 4096 } }

如果设的是 256 或 512 这种小值，调大到 2048 以上再试。如果调大后还报，看日志里这次请求的input_tokens是不是接近模型上下文上限，上下文塞太满也会导致响应异常，这时候该调低contextCompactionThreshold让历史更早压缩。

报错四：OAuth token expired / model not found

[LLM] error: model not found: gpt-4o

如果你在models.providers.taotoken.models数组里列了某个 Model ID，但实际调用时报 not found，说明这个 ID 在当前接入层不可用。先用上一节的 curl 命令拉一下可用模型列表，把数组里的 ID 换成列表里真实存在的。OAuth 相关报错一般出现在用 OAuth 方式鉴权的 provider 上，如果你走的是 API Key 方式，不会碰到；真碰到了就检查是不是混用了两种鉴权配置。

排查完这些，如果 Token 消耗还是偏高，回到第三节逐项核对配置是否真的生效。特别提醒：OpenClaw 的配置有层级覆盖，项目目录下的openclaw.json会覆盖用户目录的配置，改完记得确认改的是生效的那份。用openclaw config get tools.browser.enabled直接查运行时值，比翻文件靠谱。

6. 把优化落到日常：持续观测与模型切换的实操建议

配置调完不是终点，Token 消耗会随着你使用习惯的变化而漂移。今天禁用的工具，明天可能因为新任务又需要开回来；记忆文件越攒越多，检索注入的 Token 也会慢慢涨回去。所以最后一节讲怎么把优化变成日常习惯，而不是一次性动作。

第一件事，把用量观测加进你的例行检查。每周跑一次openclaw usage --since "7 days ago" --group-by model，看哪个模型的消耗占比最高。如果发现辅助调用（记忆整理、检索重排）的消耗超过主推理，说明模型分层没配好，回去检查taskOverrides有没有生效。如果某个工具突然开始高频出现，想想是不是最近开了新场景，评估一下能不能用更轻的方式替代。

第二件事，记忆文件定期清理。OpenClaw 的记忆存在memory/目录下，按日期分文件。时间久了的记忆片段检索价值低，但每次memory_search还是会被扫到。每隔一两周清理一次过期记忆：

# 列出记忆文件及大小 ls -lh ~/.openclaw/memory/ # 删除 30 天前的记忆文件（确认无用后再删） find ~/.openclaw/memory/ -name "*.md" -mtime +30 -delete

删之前扫一眼内容，确认没有还需要回溯的关键配置记录。清理完记忆文件后，检索的候选集变小，memory_search返回的结果更精准，注入 Token 自然降下来。

第三件事，模型切换要跟着任务走。别一个模型用到底。主推理任务重、要求高，用能力强的；批量处理、格式转换、记忆整理这种，切到便宜模型。切换命令很简单：

openclaw config set models.default "gpt-4o-mini" openclaw config set models.taskOverrides.main_reasoning "claude-3-5-sonnet"

改完不用重启，下一次请求就生效。如果你走 TaoToken 接入层，模型 ID 直接用列表里的名字，切换成本就是改一行配置。长期跑编码类或 Agent 类任务的话，可以考虑用 Coding Plan 这类按周期计费的方式，比按 Token 逐次计费更可控，具体在控制台看当前可选的方案。

最后给一个我自己的习惯：每次改完配置，跑一个固定的基准任务，记录这次任务的input_tokens总和，存到一个文本文件里。下次再改配置，跑同一个任务对比。这样你对「这次改动到底省了多少」有量化感知，不会陷入「感觉省了但又说不清」的状态。基准任务选你日常最高频的那种，比如「读一个 JSON 文件并总结」，简单、可复现、消耗稳定。

优化 Token 消耗这件事，本质是让每一分算力都花在刀刃上。固定开销能压就压，动态累积能控就控，隐形调用能砍就砍。做完这几轮，你会发现 OpenClaw 的账单比想象中好管得多。