OpenClaw Token 省流与提速分享
今天跟大家揭秘OpenClaw的Token消耗黑洞，并分享一套官方推荐的省流方案。更重要的是，省Token不仅省钱，还能让AI响应速度快2-5倍
痛点根源："我只是问了一句'项目文件在哪个位置'，就花了2块钱。让AI写代码，新增两个功能模块就花了100。这钱到底怎么没的？"
一、Token 是什么，为什么要省
1.1 什么是 Token？
不是字符，不是字数 约4个英文字符 ≈ 1 token，中文约1-2个字 ≈ 1 token 计费公式：输入token + 输出token = 总费用 每次你跟 Agent 对话，背后都在消耗 Token： 输入 Token：你发的消息 + 系统提示词 + 所有工具返回结果 + 历史上下文 输出 Token：Agent 生成的回复内容 Token 消耗 = 钱 + 速度。上下文越长，每次回复越慢、越贵
1.2 省token和提速的关系是什么呢？
核心原理：Transformer计算复杂度O(n²)
模型处理上下文时，每个token都要和其他所有token计算注意力关系。
根据我们的日常体感也能感知出来
结论：因此其实我们省token不仅省钱主要是能提速
二、openclaw工作链路
想要省token，那么首先我们得了解openclaw的工作流程
2.1 OpenClaw 每次调用到底发了什么？（核心！）
|
步骤 |
组件 |
具体操作 |
Token 消耗点 |
|
消息接收 |
Gateway 网关 |
从WhatsApp/Telegram/微信等 30+ 渠道接收用户消息 |
❌无 Token 消耗 |
|
会话路由 |
Session Manager |
根据渠道/用户路由到对应 Agent 会话 |
❌无 Token 消耗 |
|
上下文组装 |
Context Builder |
注入系统提示(SOUL.md/AGENTS.md) + 历史记录 + 当前消息 |
✅首次 Token 消耗系统提示词通常占 500-2000 tokens |
|
模型调用 |
Pi Agent Runtime |
通过 RPC 调用配置的模型(Claude/GPT/本地模型) |
✅核心 Token 消耗输入: 上下文输出: 模型回复 |
|
工具执行 |
Tool System |
如需浏览器/文件操作/代码执行等，触发工具调用 |
✅额外 Token 消耗工具结果会再次输入模型 |
|
响应输出 |
Channel Adapter |
将模型回复发送到原渠道 |
❌无 Token 消耗 |
OpenClaw 每次模型调用的完整请求内容如下：
|
组成部分 |
说明 |
估算大小 |
|
系统提示词 |
角色定义、工具列表、技能列表、运行时信息，行为指令 |
~10,000 token token占比15-25% |
|
工作区注入文件 |
|
视文件大小，每轮都注入 token占比20-35% |
|
完整对话历史 |
会话中按时间顺序排列的所有结构化消息记录，包括User 消息，Assistant 消息，System 消息 |
随对话指数增长 token占比20-40% |
|
工具调用和返回结果 |
exec输出、read文件内容、搜索结果 |
往往是大头！ token占比30-60% |
【关键洞察】
1、固定成本占比高 系统提示词(10K) + 工作区文件 = 每轮固定消耗15,000-30,000 tokens，即使简单对话也无法避免
2、动态成本增长快 对话历史和工具结果随使用指数增长，长会话可能占总消耗的60%以上
3、工具调用是最大变量 一次`read`大文件或`exec`长输出可能瞬间消耗数万tokens，是最需要控制的环节
【生动类比】
1、"假设你问一个5字的简单问题，但系统提示词10K + 注入文件5K + 历史对话20K = 35K token输入。按Claude Opus价格（$15/M token），你还没看到回答，就已经花了3毛5。这还没算模型思考的输出token。"
2、"就像你给同事发微信'文件在哪？'，但同事每次回复前都要把你们之前的所有聊天记录从头读一遍，而且读的越多收费越多。"
3、"我问'文件在哪'花了2块钱，模型是实打实的使用一些工具，例如exec从头到找尾，工具访问那么多文件当然费劲。“
问题：大家可能会问什么算一段完整的对话历史
"完整对话历史"指的是当前session（会话）里的所有消息。
- 一个session就是一次连续的对话。比如：
你打开OpenClaw，开始聊天，这就是一个session
聊到一半，你输入 /new 开了新session，或 /reset 历史清空
如果不重置，一直聊下去，这个session里的消息会越来越多
- 指数增长的意思：
不是消息数量指数增长，而是Token消耗随对话长度加速增长。
因为每轮对话，模型都要把之前所有消息再读一遍：
第1轮：读系统提示词10K + 你的问题100 token
第5轮：读系统提示词10K + 前4轮对话历史4K + 新问题100 token
第20轮：读系统提示词10K + 前19轮历史19K + 新问题100 token
越往后，历史负担越重，Token消耗和响应时间都指数级恶化。
所以及时 /new 开新session，就是切断这个累积，让成本和速度回到初始状态。
总结：我们openclaw回答越来越慢，token越用越多主要是因为
- 对话越长 → 历史消息越多 → 每轮输入token越大
- 工具返回结果（代码文件、命令输出）动辄上千token
- 编码任务中模型频繁调用工具（read→exec→read），每次调用都是一轮完整上下文
2.2 逐一击破思路
|
组成部分 |
token占比 |
优化策略 |
|
系统提示词 |
15-25% |
禁用未使用的技能模块• 精简角色定义描述• 按需使用不同类型模型 |
|
工作区注入文件 |
视文件大小，每轮都注入 20-35% |
精简注入文件· 合并重复配置项 Prompt Cache 命中文件头 1KB 保持一致 |
|
完整对话历史 |
随对话指数增长 20-40% |
及时开新会话，善用/new上下文归零，善用压缩 /compact 压缩历史，或自动触发（75%阈值）主动执行"压缩前记忆落盘" |
|
工具调用和返回结果 |
往往是大头！ 30-60% |
禁用不必要的自动工具调用• 会话隔离+输入输出精简化 |
|
日常监控 |
人的主动性干预 |
实时监控 Token 消耗• 设置阈值触发优化动作 |
三、省流技巧
2.1 黄金三板斧
第1招：选对模型
|
模型 |
输入价格 |
输出价格 |
适用场景 |
首Token延迟 |
|
Claude Opus 4.6 |
$15/M |
$75/M |
复杂推理 |
800-1500ms |
|
Claude Sonnet 4.6 |
$3/M |
$15/M |
日常编码 |
400-800ms |
|
Claude Haiku |
$0.25/M |
$1.25/M |
简单问答 |
200-400ms |
|
Kimi K2.5 (官方API) |
$0.60/M |
$2.50-3.00/M |
长文本处理、中文优化、高性价比 |
300-600ms |
操作指令：
- 查看当前模型：/model
- 查看模型列表：/models
- 看提供商手下还有什么模型/models provider
- 切换：/model <provider/model>
- 进行一个简单的测试，临时切换不同的模型去相同指令模型token消耗
同一个提供商，使用不同的模型执行简单的命令 /model custom-ai-service-tal-com/claude-opus-4.6(模型名) /new 跟xx说你好 模型执行完毕完毕 /status
- 补充一个常用指令：查看当前状态/status
/status返回内容解析表
|
内容 |
含义 |
|
OpenClaw 2026.3.23 (ccfeecb) |
当前运行的 OpenClaw 平台版本号 |
|
🧠 Model: custom-ai-service-tal-com/claude-sonnet-4.6 · 🔑 api-key (models.json) |
|
|
🧮 Tokens: 252k in / 1.2k out · 💵 Cost: $0.0000 |
|
|
📚 Context: 51k/256k (20%) · 🧹 Compactions: 0 |
|
|
🧵 Session: agent:maying:yach:direct:v0028140 • updated just now |
|
|
⚙️ Runtime: direct · Think: off |
|
|
🪢 Queue: collect (depth 0) |
|
同一个提供商，使用不同的模型执行稍微复杂的命令 /model custom-ai-service-tal-com/claude-opus-4.6(模型名) /new 查询xx文件地址在哪里 模型执行完毕 /status
Claude Opus 4.6（旗舰模型）在复杂任务中表现出更强的规划能力，仅需80K输入Token即可完成核心决策，输出精简至406 Token[1]。
Claude Sonnet 4.6（轻量模型）因推理深度不足，需多次迭代调用工具，输入Token激增至705K（达Opus的8.8倍），输出也因冗余解释增至4.7K
你可能会想，那什么时候用a模型什么时候用b模型，系统是否可以自动切换呢？这里涉及到路由规则扩展
若需增强自动切换精度，需手动添加路由规则，可自行探索：
（~/.openclaw/openclaw.json）：{
"modelRouting": {
"rules": [
{
"match": "contextLength > 16000", // 长上下文用Opus
"model": "anthropic/claude-opus-4-6"
}
]
}
}
结论：当进行简单的指令，例如联系某人时，使用轻量模型，会节省部分成本，，而当进行复杂指令时，反而是使用贵的模型更省钱，响应也会更快
第2招：精简注入文件（每轮省数千token，提速50%）
每轮注入：AGENTS.md/SOUL.md/TOOLS.md/IDENTITY.md/USER.md/MEMORY.md等文件会自动注入——这些都是 Token。
怎么做：
- MEMORY.md 只保留真正长期有价值的内容，定期清理过时条目
- AGENTS.md 写精准，不要堆砌重复规则
- 临时信息写 daily log，不要写进 MEMORY.md
诊断命令： /context list 查看token占用
/context detail 完整明细
优化目标：每个人每个行业需求不一致，可以针对性的进行优化配置
第3招：及时开新会话（提速最显著）
核心：长对话历史是Token大头。完成一任务用/new，成本归零，速度恢复。
/new — 开新会话
- 完全新的上下文窗口，agent什么都不记得了
- 之前的对话历史对agent不可见
- 适合：切换完全不同的话题，彻底"清空"agent
但是你可能不想开启新的会话，那么同时还有其他几个有用的指令针对你所需的不同情况
/reset — 重置当前会话
- 清空对话历史，但还在同一个 session 里
- 系统提示（AGENTS.md、SOUL.md 等注入文件）会重新加载
- 适合：同一个话题跑偏了，想从头来一次，同时让注入配置刷新
/compact — 压缩上下文
- 不清空对话，而是把之前的对话内容压缩成摘要
- 释放 token 空间，让我"记住精华"但占用更少上下文
- 适合：长对话快撑满了，但还想继续同一个任务，不想断
对于最常用的工具小总结就是
/new→ 领域级隔离（清除工作区+历史）/reset→ 任务级切换（仅清历史）/compact→ 过程级优化（摘要替代原始记录）
如果想要撤销压缩，执行/compact 后的10分钟内可用/undo compact
其他两个指令不可撤销❌
实操
1、对/compact指令进行观察，先查看当前token数
2、然后输入/compact执行压缩，明显可以看到token压缩
3、执行/undo compact ，你会发现其实还是会有丢损的，但是基本能恢复
得出结论：使用/compact及时可以恢复，但是也会有折损，有利也有弊
2.2 进阶用
善用压缩（Compaction）
当上下文用到 75% 以上时，OpenClaw 会触发自动 Compaction，把历史消息压缩成摘要。
压缩共有两种机制：
自动压缩：接近上限自动触发
手动压缩：/compact主动触发，也就是上面提到过的
当然这里自动的机制也是可以自定义配置的
原理：旧对话转摘要，保留最近~20K完整内容
警告：压缩丢失指令、偏好、工具结果、图片，只有写入文件的内容幸存，并且自动压缩是不可逆的❌，只有手动压缩10分钟内可逆，当然这个都是可以配置的
Compaction具体影响内容如下：
|
丢弃的 |
保留的 |
|
历史对话轮次： 删除与当前任务无关的早期对话（如已解决的日志分析步骤） |
当前任务依赖项 最近用户查询直接引用的文件或数据（如“基于 utils.py 第20行实现”）。 未解决的错误或待办事项（如“待修复：内存溢出”） |
|
未标记为关键的文件内容： 移除已分析且无后续依赖的代码/日志文件全文（如 server.py 的已修复部分） |
当前聚焦的文件片段 （如用户正在编辑的 moduleB.py 行30-50）。 用户通过指令保留的内容 （如 /retain moduleA.py） MEMORY.md 中的决策摘要 （如“模块B需兼容API v2”） |
|
工具调用中间结果： 清除已完成的工具调用（如 read_file 返回的代码内容），仅保留最终结论 |
工具调用的关键输出 （如最终的结论报告） |
|
低权重信息： 删除重复提示、冗长解释（如AI的思考过程若未标记为保留） |
会话元数据 会话ID、任务目标、Agent状态（如 🧵 Session: agent:maying:yach...）。 |
你能做的：
- 主动执行"压缩前记忆落盘"指令，让重要内容在压缩前写入文件，MEMORY.md或者你需要的地方
- 不要在一个 session 里塞太多不同任务，导致上下文快速膨胀，那就会触发压缩机制，你再询问对话可能会自动给丢掉一些细节，这个时候就不能怪agent笨了，他只是变省流版agent了
openclaw缓存机制
- 缓存的生成：
- 取 SOUL.md 等文件开头 1KB → 拼成静态区
- 计算静态区哈希值 → 作为缓存钥匙
- 加载 MEMORY.md 等动态内容 → 与静态区拼接成完整提示词
- 存储：钥匙 → 完整提示词
- 缓存的触发：
新请求时，重新计算静态区哈希：
-
- 匹配钥匙 → 直接返回缓存（追加新动态内容）
- 钥匙不匹配 → 冷启动（哈希失效 ，重算提示词+ 延迟/成本增加）
系统提示词静态区和动态区的来源
优势
因此：设想我们可以根据这个原理，让我们的语言更多命中缓存从而直接复用降低token，以及尽量不让缓存失效，这样就可以经常命中
实操优化及原理
根据的三原理
- 哈希锁头：系统对文件头 1KB 内容生成哈希值 → 相同输入 0ms 响应，成本降90%。
- 动态免疫：1KB 后内容不参与哈希 → 仅末尾追加不影响缓存。
- 冷启动惩罚：静态区任何修改（增删字符/空格）→ 哈希失效 → 延迟+200ms，成本+$0.1/次。
具体操作
1. 术语一致性（防静态区误改）
- 语言统一 → 避免开发者手动“纠正”术语污染静态区
- 实操
|
✅ |
“分析模块a的api接口”，“提bug”和我们文件头术语一致，更容易命中 |
|
❌ |
“检查组建b的协议设计”，“新建问题记录”术语偏离，可能就会修正我们的静态区，从而导致增加延迟 |
2、指令标准化（强制安全操作）
- 对于我们的工作区文件进行改动时改动，只用“追加”，禁用“插入/修改”，引导行为 → 物理写入仅发生在文件末尾-即动态区（哈希范围外），不然如果命中静态区又会修改增加延迟
- 实操
|
✅ |
“在xx.md末尾追加规则：新服务需鉴权”or“在memory.md文件里记住xx” |
|
❌ |
“在soul.md第一行进行修改” |
3、时空表达冻结（防格式污染）
- 日期仅 YYYY-MM-DD，时间用 HH:MM
- 实操：
|
✅ |
“2024-06-15 14:30 发生错误” |
|
❌ |
“今天下午2点半出问题了” |
4、缓存配置
- 缓存配置也有助于我们的优化，若不配置任何缓存规则，OpenClaw 将启用 全局默认策略，其行为和风险如下
1、默认策略内容
缓存保留时长：short（5分钟）
覆盖范围：所有模型（Opus/Sonnet 均适用）。
技术依据：保守策略避免内存溢出（尤其高并发场景）
2、默认策略的风险
3、关键数据对比
- 为此我们可以优化我们的缓存配置有以下内容
|
配置项 |
内容 |
效果 |
|
cacheRetention |
"cacheRetention": "long",// 1小时缓存周期 默认short=5分钟，long=1小时 |
高单价模型启用长缓存，避免默认短缓存导致的频繁冷启动。 |
|
heartbeat： |
"heartbeat":"55m"// 缓存到期前55分钟保活 |
定期轻量请求保持缓存热度 |
|
session_inherit_cache |
"session_inherit_cache": true // 同任务跨会话继承缓存 命中继承条件：
会话1和会话2需使用 相同任务标识（如 task_id=模块A优化）。
在 cacheRetention: long（1小时）内发起会话2。 |
分步任务（如需要先编码再对编码进行测试） 配置时： 会话1编码任务，结果返回用户，会话2直接复用会话1的缓存 → 冷启动归零。 不配置时： 会话1编码任务，结果返回用户，会话2需重新加载会话1已处理的代码 → 额外冷启动成本 $0.1 |
- 配置缓存策略我们也可以直接配置文件修改，有以下两种方式
方案一：使用cacheRetention 控制模型对话历史缓存保留周期
（~/.openclaw/openclaw.json）： {
"agents": {
"defaults": {
"models": {
"anthropic/claude-opus-4-6": {
"params": {
"cacheRetention": "long" // Opus 模型专用长缓存策略
}
},
"anthropic/claude-sonnet-4-6": {
"params": {
"cacheRetention": "short"//Sonnet 模型专用短缓存策略
}
}
}
}
}
}
方案二：动态缓存规则配置
（~/.openclaw/openclaw.json）：
{
"agents": {
"defaults": {
"cacheRules": [ // 在此添加动态缓存规则
{
"match": "taskType == 'status_check'",
"retention": "short"
},
{
"match": "contextLength > 16000",
"retention": "long"
}
],
"models": {
"anthropic/claude-sonnet-4-6": {
"params": {
"cacheRetention": "short" // 基础策略，被动态规则覆盖
}
}
}
}
}
}
}
上面两种配置不同配置原则主要是区别在是基础配置还是动态规则配置
两者的关系
- 基础策略（
cacheRetention）- 静态定义：如
"cacheRetention": "short"表示该模型默认使用固定的短周期缓存策略，适用于无动态条件的场景。short默认5分钟，long默认1小时。 - 作用范围：作为全局默认值，当无动态规则匹配时生效（参考华为云CDN的默认缓存规则）。
- 静态定义：如
- 动态规则（
cacheRules）- 条件覆盖：通过
"match": "contextLength > 16000"等条件动态覆盖基础策略，定义何时使用long或short。 - 阈值自定义：
16000是人为设定的阈值边界，实际值需根据业务调整（如阿里云CDN按文件类型设置不同阈值）
- 条件覆盖：通过
目前很多企业都在应用了动态缓存规则，可以助于不同模型更好的工作
编码任务最小化上下文（用 Claude Code）
写代码是最消耗 Token 的场景——代码文件大、来回修改多。
核心策略：会话隔离+输入输出精简化
|
层级 |
核心目标 |
具体做法 |
实例 |
|
会话隔离 |
主上下文不膨胀 |
主session spawn一个子session编码任务 ，主 session 只负责"说需求、看结果"，不卷入代码细节，子session只处理代码，可被主打断 |
主 session："实现 JWT 登录，Redis 存 token，输出到 login-result.md" → spawn Claude Code 写代码 → 主 session 读取 login-result.md 验收汇报结果 |
|
输入精简 |
减少探索轮次 |
子session初始化：全量注入必要文件，后续不再重复传输 |
开Claude Code时一次性注入：项目结构、地址、API文档、数据库表结构。后续只问"xx怎么修改"，不再传背景 |
|
明确指令：一次性粘贴代码+说明问题，不让模型逐个read 最好可以限制read大小 |
❌ "优化这段代码" → AI反复read试探 ✅ "优化Login函数（贴代码），token验证失败，参考auth.js第15-25行" |
||
|
输出过滤 |
工具返回不进垃圾 |
结果压缩返回，仅关键变更摘要 |
❌ “给我看看日志文件” → 10万行进上下文 ✅ "看日志最后30行，只看ERROR级别的" → 30行进上下文 |
/usage 监控消耗
随时用 /usage 查看当前 session 的 Token 使用情况，判断是否需要 /new。
建议：
- 超过 50% 开始注意
- 超过 75% 考虑落盘 +
/new - 超过 90% 强制
/new，否则回复质量会下降
核心命令： /status 模型/上下文%/上轮token/预估费用/响应时间
/usage tokens 每条显示token消耗
/usage full token+费用+缓存命中率
/usage cost 累计费用摘要
/context list 上下文构成明细-很详细
使用方法：输入/usage相关指令后，agent先开启展示的模式，然后你再问他问题他就会返回对应的内容
实操：我开启了/usage full后，我再问问题，他在回答的结尾会返回以下内容，对应字段含义如下
2.3 实际场景举例分析
场景1：问"文件在哪"
触发2-3轮工具调用，每轮带完整上下文
解决：定向搜索，给一个大致范围进行find，or，”先使用3次find命令查询定位”限制使用次数，明确输出内容“只提供文档的具体位置，不需要提供文档内容”，在查询文档为之前先/new，清空上下文，换模型，复杂场景用贵的模型，更强推理能力，claude-sonnet-4.6换成Claude Opus 4.6。成本2.19➡️1.23，省43.84%成本，减少了79.2%的延迟
场景2：编码任务——新增两个功能模块
模型需要：读取现有代码 → 理解架构 → 编写新代码 → 测试 → 修复
每一步都可能读多个文件（每个文件内容都进入上下文）
对话越长，每轮携带的历史越多
100元 ≈ 大量的工具调用循环 + 长对话上下文累积
解决：编码前 /context list 检查上下文token构成或者用/statu监控一下。MEMORY.md超5K立即清理，只留当前项目决策。功能 A 和功能 B 分两个 Session，会话隔离，也会让上下文清爽一点
场景3：最烧钱的极端情况
"让AI读一个1000行的日志文件找错误。模型会read→分析→再read→再分析...这个文件内容会在多轮对话中反复被携带，可能产生数万token的重复计费。"
解决：在定位错误的关键节点主动压缩历史消息（如通过指令 /compact），将冗长日志替换为精简摘要，释放上下文空间，或者精简定位，只读error错误，分析后计入缓存，可以记录在 MEMORY.md，下次同类问题零成本
场景4：测试场景
“例如我首次测试一个新的测试项目，告诉他很多操作步骤协助我完成，其中教育他就有很多流程，后续再进行测试该项目，质问他上次教过你了你怎么不会”
解决：当时第一次教育完成执行完操作，及时让他总结，可以写skill或者自己进行总结，然后MEMORY.md同时记录，当下次提及相关测试场景时，主动调用该skill，进行测试前/new，避免过多历史记录，完成一次操作前后使用 /context list 或者/statue记录消耗token值，及时优化skill，当一波测试结果输入文档后及时/compact压缩，每一波压缩一遍，使用工具查看返回值提取关键信息时，使用grep工具精准查询
更多推荐
7
0- 0
已为社区贡献1条内容
所有评论(0)