Token 消耗降低 90%：OpenClaw 降本增效实战指南

Token 消耗降低 90%：OpenClaw 降本增效实战指南

大家想学习更多AI知识，可以收藏：
GPTBUYS、ZeoAPI

对于工程团队来说，Agent 不是“能跑就行”，而是要“可控、可观测、可计费”。OpenClaw 的强大之处在于上下文、记忆、工具、Heartbeat、Prompt Caching 都能协同工作；但这些能力一旦配置不当，也会迅速放大 token 消耗。本文不讲空泛原则，直接围绕官方文档与可验证实践，给出一套能落地的降本路径：先观测，再定位，再收敛，再固化。

摘要

摘要：OpenClaw 的 token 成本核心来自上下文注入、Heartbeat 调度、模型路由、缓存命中率和工具/记忆链路。官方文档明确指出，Heartbeat 启用isolatedSession: true可将单次消耗从约 100K token 降到约 2K–5K，属于最直接、收益最高的降本开关之一。配合lightContext: true、Prompt Caching、上下文治理、规则文件瘦身、便宜模型路由和会话清理，工程上实现 90% 级别降本是完全有可能的。关键不在“少用功能”，而在于把稳定上下文缓存掉、把不必要上下文切掉、把便宜任务路由到便宜模型上。

为什么 OpenClaw 容易“偷偷烧 token”

摘要：先理解成本构成，才能避免盲目优化。

根据 OpenClaw 官方 Context 文档，上下文不只是聊天历史，还包括系统提示、工具调用结果、附件、项目上下文、记忆等内容，这些都会进入模型上下文窗口并产生 token 消耗。[3] 这意味着很多团队看到“只是问了一个简单问题”，实际上后面已经带了大量隐含输入。

几个常见的成本来源如下：

1. 会话历史持续累积
   多轮对话越长，后续每一轮越贵。如果不做压缩、清理或隔离，会形成滚雪球效应。[3][8]

2. Heartbeat 本质上是完整 agent turn
   官方 Heartbeat 文档明确指出，heartbeat 不是轻量 ping，而是完整代理执行轮次；间隔越短，token 烧得越快。[1]

3. 规则与项目上下文过胖
   项目 bootstrap、规则文件、技能说明、MEMORY.md、daily memory 等，都会以不同方式注入上下文。[3][6]

4. 工具与 MCP 级联调用
   一次任务如果触发多个工具、产生大量结果，再被模型重复消费，会显著抬高 token。[4][8]

5. 模型选型不合理
   官方帮助中心特别提醒，Gemini 等模型在某些配置下可能带来高额账单，说明“任务—模型匹配”是成本控制核心变量之一。[5]

所以，OpenClaw 降本不是单点调参，而是完整的“上下文治理 + 调度治理 + 路由治理 + 观测治理”。

先做观测：别在看不见的地方优化

摘要：没有 token 可观测性，任何“优化”都只是猜。

官方 Context 文档给了很实用的诊断命令：/context list、/context detail、/usage tokens、/compact。[3] 这组能力非常适合做第一轮排查。建议团队把它作为固定巡检流程：

• 用/usage tokens看当前会话总 token 走向
• 用/context list看有哪些上下文源被注入
• 用/context detail定位哪一项最重
• 用/compact在长会话中做阶段性压缩

如果你希望更细粒度地看到“浪费发生在哪一轮、哪个子代理、哪个提示词”，可以引入token-optimizer插件。它支持 session 审计、每轮成本计算、昂贵提示识别、子代理花费排行，并且专门检测空转、误路由、重试抖动、工具级联、循环模式等 10 类浪费。[4]
这类工具的价值不只是“算账”，更重要的是帮助你定位：

• 是谁在反复发相同前缀？
• 是哪类任务被路由到了过贵模型？
• 是哪个 Agent Team 在反复重试？
• 是哪个工具返回过大结果集？

实践建议是：先跑 1 周观测，再做配置变更。否则很容易为了省 5% token，反而牺牲了 30% 的任务成功率。

Heartbeat：最容易拿到 90% 级降本的开关

摘要：Heartbeat 是高频成本源，优先级应排第一。

这是本文最关键的一节。根据 OpenClaw 官方 Heartbeat 文档，启用：

• isolatedSession: true

可以避免每次 heartbeat 都发送完整对话历史，把单次 heartbeat 从约100K token降到约2K–5K token。[1]

这不是边角优化，而是数量级优化。假设你把 heartbeat 设得很频繁，例如每几分钟执行一次，那么不隔离会话时，历史上下文会被不断重放；而一旦启用隔离，heartbeat 的上下文载荷立即缩小。

官方同时还建议配合以下项继续压缩成本：[1]

• lightContext: true
• 选择更便宜的模型
• 缩小HEARTBEAT.md
• 降低 heartbeat 频率

这里有一个经常被忽略的工程事实：调度策略本身就是成本变量。
Heartbeat 不是越勤快越好。很多团队默认把它当成“保活机制”，结果变成了“高频完整推理机制”。建议做三层设计：

1. 按业务价值定义 heartbeat 频率
   只有需要主动巡检、后台自动处理、持续监控的任务才配置 heartbeat。

2. 按任务复杂度设计 heartbeat 模式
   简单检查走轻模型 + 轻上下文；复杂分析才走重模型。

3. 为 heartbeat 单独维护最小上下文
   不要复用主对话全量历史，不要把与监控任务无关的信息塞进去。

这一条往往就能解释很多“为什么账单突然翻倍”的问题。

上下文治理：真正的降本主线

摘要：大部分 token 浪费，本质都是不必要上下文被送进模型。

OpenClaw 官方 Context 文档明确说明，上下文由多个来源共同组成，而且项目上下文注入存在字符上限，例如 bootstrap 单文件上限 20,000 chars。[3] 这给了我们非常明确的治理方向：不是所有能注入的内容都应该注入。

可以从以下几方面下手：

1. 控制规则文件体积

很多团队会把大量规范写进.clawrules、项目规则、技能说明里，结果每轮都反复带入。实践上建议：

• 规则分层：全局规则、项目规则、任务规则分开
• 把 rarely used 的规则移出热路径
• 避免长篇自然语言堆砌，改为短句 + 明确约束
• 定期审查HEARTBEAT.md、MEMORY.md、技能提示

Thunderbit 的实战文章也提到，缩短.clawrules、增加.clawignore是快速止血手段。[8]

2. 缩小工作区暴露面

如果模型总能“看到太多文件”，它就更容易把无关内容拉进上下文。应通过忽略规则减少不必要的工作区扫描与注入。[8]

3. 控制记忆检索规模

来自 explain-openclaw 的拆解指出，memory_search支持片段截断与结果数量限制，也就是说记忆检索本身可以通过 snippet caps 控制 token。[6]
建议原则是：宁可多次小检索，也不要一次性灌入大量历史记忆。

4. 长会话主动压缩

长会话中使用/compact，把已完成阶段的历史压缩掉。[3]
必要时直接/clear重开会话，避免把老任务包袱带进新任务。[8]

上下文治理的目标不是“极限精简”，而是“只保留对当前任务有用的信息”。

Prompt Caching 与模型路由：把重复输入变成缓存，把简单任务变成便宜单

摘要：成本下降不只靠少发 token，还靠少重复计算、少用贵模型。

OpenClaw 官方 Prompt Caching 文档指出，提示词缓存可复用稳定前缀，避免每轮重复处理 system/developer 指令与稳定上下文。[2]
同时，OpenClaw 对不同上游的缓存统计做了统一映射：

• cacheRead：缓存命中读取
• cacheWrite：缓存写入

这对工程团队非常关键，因为你终于能把“缓存省了多少钱”纳入监控与审计。[2]

对于 Gemini 直连，官方还支持通过cacheRetention自动创建和复用cachedContents，进一步降低重复输入开销。[2]

这里建议两个落地动作：

1. 识别稳定前缀

适合缓存的内容通常包括：

• system / developer 指令
• 稳定的项目约束
• 固定格式的工具协议
• 低频变化的背景知识

不适合缓存的内容：

• 高频变化的用户输入
• 最新工具结果
• 临时调试日志
• 瞬时状态数据

2. 按任务分层路由模型

官方帮助中心明确提示模型选择会直接影响账单，[5] explain-openclaw 也建议自动路由、开发阶段使用 floor 变体、显式模型 pin、按任务选模型。[6]

非常实用的分层策略是：

• 轻任务：分类、改写、格式整理、简单提取 → 低价模型
• 中任务：常规代码理解、普通问答、文档生成 → 中档模型
• 重任务：复杂规划、多工具推理、难题诊断 → 高性能模型

这样做的核心不是“一刀切换便宜模型”，而是建立正确的模型路由规则。

Key Comparison Table

摘要：下面把常见降本动作、收益和代价放在同一张表里，便于工程决策。

实战代码示例

摘要：下面给出两个最值得先落地的配置方向：Heartbeat 隔离与缓存/观测。

示例 1：Heartbeat 最小化配置思路

# purpose: 将 heartbeat 从“重上下文完整会话”改为“轻上下文独立会话”heartbeat:enabled:true# key: 使用独立会话，避免重复发送主对话全量历史isolatedSession:true# key: 尽量只保留执行 heartbeat 必需的信息lightContext:true# key: 不要把 heartbeat 频率设得过高，频率本身就是成本变量intervalMinutes:30model:# key: 将巡检类任务路由到更便宜模型，复杂任务再升级name:cheap-monitor-model

上面这段并非特定版本的完整配置模板，但体现了官方 Heartbeat 文档支持的核心优化方向：isolatedSession: true、lightContext: true、低频调度、便宜模型。[1]

示例 2：用命令做上下文与 token 巡检

# purpose: 定位当前会话 token 异常来源# step1: 查看总 token 使用情况，判断是否异常增长/usage tokens# step2: 列出所有上下文来源，定位是谁被注入/context list# step3: 查看某个上下文详情，确认是否存在超长规则/工具结果/context detail# step4: 对长会话做压缩，减少后续轮次的历史负担/compact

这是官方 Context 文档直接支持的一组诊断手段。[3]
建议把它们写进团队 SOP，例如“任务超过 30 分钟、会话超过 N 轮、账单异常波动时必须执行”。

示例 3：围绕缓存命中做成本观测

{"purpose":"监控 Prompt Caching 实际效果","metrics":{"inputTokens":128000,"cacheWrite":32000,"cacheRead":96000},"checkpoints":["观察稳定前缀是否被反复复用","核对 cacheRead 是否随多轮调用上升","缓存命中低时，检查 system/developer 前缀是否频繁变化"]}

OpenClaw 文档已统一抽象cacheRead与cacheWrite，适合直接接到你的成本看板或告警系统里。[2]

代码块注释规范

摘要：代码示例要让读者能“复制即懂”，注释必须克制但有效。

建议遵循以下 4 条规则：

1. 先写目的，再写步骤
   每个代码块顶部先用 1 行注释说明“这个配置/命令是干什么的”。

2. 只注释关键字段和关键步骤
   不要每一行都解释，重点标注真正影响成本的参数，如isolatedSession、lightContext、路由模型、缓存指标。

3. 注释解释“为什么”，而不是重复“是什么”
   例如不要写“intervalMinutes: 30表示间隔 30 分钟”，而应写“频率本身就是成本变量，不宜过高”。

4. 注释与正文结论保持一致
   代码块中的建议必须能在正文找到依据，避免示例与论点脱节。

常见问题与排错

摘要：下面列出几个最常见、最容易被忽略的坑。

1. 开启了 heartbeat，但账单仍然很高
   先确认是否真的启用了isolatedSession: true，并检查 heartbeat 频率是否过高。[1]

2. 明明提问很短，为什么 token 很大
   大概率不是用户输入长，而是系统提示、项目规则、记忆、工具结果一起被注入了。用/context list和/context detail排查。[3]

3. 缓存看起来没省钱
   先看cacheRead是否持续增长；如果没有，说明稳定前缀变化太频繁，缓存复用条件没有满足。[2]

4. 切到便宜模型后效果变差
   这是路由策略问题，不是“便宜模型不能用”。把复杂规划、长链路推理保留给高性能模型，把轻任务下放。[5][6]

5. 长会话越来越慢、越来越贵
   及时/compact，必要时/clear，不要让单个会话承担整个项目生命周期。[3][8]

结论：按“4 步闭环”推进，而不是零散调参

摘要：真正可复制的降本方案，一定是闭环工程。

如果你希望在 OpenClaw 上稳定实现 90% 级别的 token 降本，建议按下面 4 步执行：

1. 先观测
   用/usage tokens、/context list、token-optimizer建立基线。[3][4]

2. 先打大头
   优先改 Heartbeat：开启isolatedSession: true，再结合lightContext: true、低频调度、轻量模型。[1]

3. 做上下文治理
   缩规则、控记忆、减注入、压长会话、清理无关文件。[3][6][8]

4. 固化缓存与路由
   用 Prompt Caching 复用稳定前缀，用模型路由把简单任务分流到低价模型。[2][5][6]

一句话总结：OpenClaw 的降本不是“少问一点”，而是“少重复、少注入、少误用、少高频重推理”。
如果你的团队还没有开始做 token 可观测性，建议今天就先从 Heartbeat 和上下文巡检开始。

参考资料

1. Heartbeat - OpenClaw
   https://docs.openclaw.ai/gateway/heartbeat

2. Prompt Caching - OpenClaw
   https://docs.openclaw.ai/reference/prompt-caching

3. Context - OpenClaw
   https://docs.openclaw.ai/concepts/context

4. GitHub - alexgreensh/token-optimizer: Find the ghost tokens. Fix them. Survive compaction. Avoid context quality decay.
   https://github.com/alexgreensh/token-optimizer

5. OpenClaw Token Usage & Cost Control Guide (2026)
   https://www.getopenclaw.ai/zh/help/token-usage-cost-management

6. explain-openclaw/06-optimizations/cost-token-optimization.md at master · centminmod/explain-openclaw
   https://github.com/centminmod/explain-openclaw/blob/master/06-optimizations/cost-token-optimization.md

7. GitHub - OnlyTerp/openclaw-optimization-guide: Make your OpenClaw AI agent faster, smarter, and cheaper.
   https://github.com/OnlyTerp/openclaw-optimization-guide

8. How I Cut OpenClaw Token Usage 90% (Cheapest Models Inside)
   https://thunderbit.com/blog/how-to-reduce-openclaw-token-usage