每月多花80%冤枉钱？OpenClaw隐形Token消耗完全拆解与实战优化

用了 OpenClaw 一个月，账单出来你有没有傻眼？

明明感觉自己就问了一些问题，但 Token 消耗和你想象中差了好几倍。原因其实不复杂：你真正的对话内容只占整体消耗的 5–20%，剩下那 80–95% 是你看不见的隐形开销。

这篇文章把这些隐形开销一条一条拆出来，配上可以直接用的配置思路，帮你把月账单降下去。

一个真实案例：一个用 Claude Sonnet 跑心跳检查的监控代理，后台消耗悄悄占了整体账单将近 40%。换模型+迁移 Cron 之后，这个代理的月消耗降了 70% 以上——而功能一点没损失。

---

先诊断，再下药

优化前，建议先摸清自己的消耗结构，不然容易瞎改：

/status               # 当前会话已用多少
/usage full           # 每次回复的详细拆分
/context detail       # 哪些文件/历史在消耗上下文
du -h ~/.openclaw/agents/*/sessions/*.jsonl | sort -h

最后那条命令专门看会话文件大小，超过 500KB 就是该处理的信号。

---

第一条：模型选错，是最贵的浪费

这是单条优化效果最明显的一项。

很多人默认所有任务都用主力模型（Claude Sonnet 或类似档次），但监控代理心跳、定时状态检查、格式化这类任务，用再贵的模型也不会更聪明——成本却可能高 10–20 倍。

推荐的国内分层方案：

任务类型	模型选择	理由
代码/写作/复杂分析	DeepSeek-V3 / 通义千问-Max	性价比高，中文强
心跳/监控/Cron	豆包1.5 / Gemini 2.5 Flash	接近免费，够用
长上下文/推理	GLM-4-Air / 通义千问-Max	推理链接近 Sonnet
图文混合任务	Kimi-VL / Qwen-VL-Max	国内多模态首选

会话中切换很简单：

/model openai/deepseek-chat

另外，如果任务不需要深度推理，关掉 thinking 模式可以避免额外消耗：

"thinking": { "type": "disabled" }

---

第二条：配置文件悄悄”吃”了你很多钱

SOUL.md、AGENTS.md、USER.md、TOOLS.md 这几个文件有个特点——每次 API 调用都会全量注入。文件越大，每次调用的基础成本越高，跟你问了什么无关。

一个常见的问题是：很多人的配置文件里有大量”以防万一”的规则，但实际上从来没有触发过。把这些删掉，配置文件体积通常能缩减 30–50%，固定开销跟着下来。

用 $include 语法复用公共规则，避免同样的内容在多个文件里重复出现。核心文件尽量少改，改得越频繁，提示缓存的命中率越低（见第七条）。

---

第三条：技能越多，基础消耗越高

每个技能的描述字段，在每次调用时都会注入到系统提示里，哪怕这个技能根本没有被触发。单个技能大约 50–100 Token，技能数量一多，固定成本就上去了。

处理思路：

• 高频使用的技能保留，低频的改成手动触发
• 低频技能加上 disable-model-invocation: true，彻底阻止自动注入
• 技能描述只写触发条件，详细逻辑放正文里（用到了才加载）

---

第四条：历史对话是个会膨胀的黑洞

会话历史随轮次增长，规律接近指数级，长期跑下来能占到上下文窗口的 40–60%。

几个控制手段：

压缩时切低成本模型： 不要用 Sonnet 做压缩，先 /model haiku，再 /compact，完成后切回来。

子代理隔离大任务： 大批量输出的任务丢给子代理跑，只把最终结果返回主会话。

/subagents spawn main "任务描述"

定期清理 session 文件： 超过 500KB 的会话文件就是膨胀的信号，定期处理。

---

第五条：心跳机制可能是账单飙升的罪魁祸首

这条是社区里踩坑最多的一条，值得重点说。

原生 Heartbeat 有两个已知问题：

1. 模型覆盖不生效——你设了便宜模型，实际可能还是用了贵的
2. 触发频率异常——设了 30 分钟，实际可能每 10–20 秒触发一次，消耗直接炸

解决方案：彻底关掉原生心跳，改用隔离 Cron：

"heartbeat": { "every": "0m" }

Cron 任务里指定低成本模型，再加上自动清理和日志限制：

"cron": { "sessionRetention": "24h" },
"runLog": { "maxBytes": "2mb", "keepLines": 2000 }

多个后台任务尽量合并成单次调用，能省掉大约 75% 的上下文注入成本。实测后台消耗可降 **50–80%**。

---

第六条：多个代理用同一套配置，是在浪费

如果你跑了多个代理，全局统一配置很省事，但代价是资源错配：监控代理不需要大上下文窗口，给了也是浪费；开发代理需要足够的上下文，配少了又不够用。

在 agents.list 中为每个代理单独配置：

• 模型选择（监控 → 豆包/Flash，开发 → DeepSeek/Sonnet）
• 上下文窗口大小
• 压缩策略

按代理职责差异化配置，整体消耗通常可降 **20–40%**。

---

第七条：提示缓存没开，等于白白付固定读取费

开启提示缓存后，固定内容（配置文件、系统提示）的读取成本可以降到大约 **10%**。

这是因为 AI 提供商会对完全相同的前缀内容做缓存，后续调用读取时费用大幅优惠。

有效利用的关键：

• 保持配置文件前缀稳定，频繁修改会让缓存失效
• 定时任务间隔设置成略小于缓存 TTL，让缓存保持”热”的状态

---

第八条：工具调用结果留在历史里，是持续的负担

工具调用产生的大段输出，如果一直留在会话历史里，每次后续调用都要带着它，是累积性的浪费。

几条规则建议写进 AGENTS.md：

• 用精确检索工具，别直接读整个文件
• 多个独立查询合并成一次批量调用
• 大输出任务走子代理，主会话只拿结论
• 并发控制："maxConcurrent": 1
• 图像降采样：imageMaxDimensionPx: 800

---

第九条：本地模型承接简单任务（进阶）

2026 年本地模型的能力已经足够处理大量低复杂度任务，而成本接近于零。

常见的迁移目标：状态检查、日志监控、简单格式化、定时巡检。

可以用轻量路由层（社区里有 ClawRouter 可参考）按任务复杂度分发：

复杂度	去哪跑
简单	本地模型（0 成本）
中等	Gemini Flash / DeepSeek
复杂	Claude Sonnet

需要显卡 ≥ 24GB VRAM，可以从 Cron 任务开始小范围迁移试试。

---

额外：别等账单来了才知道超了

• 在 API 提供商控制台设置每日消费上限
• 限制子代理并发："subagents": { "maxConcurrent": 3 }
• TOOLS.md 里加预算监控逻辑，消耗到 75% 时主动提醒

---

从哪里开始？

如果不知道先改哪条，按这个顺序来：

先做这三件事（效果最明显）：

1. 关闭原生心跳，迁到隔离 Cron + 便宜模型
2. 对代理做模型分层，后台任务用 Haiku/Flash
3. 设置历史自动重置 + 软阈值

做完再看这三件：

• 配置文件和技能精简
• 多代理差异化配置
• 开启提示缓存

有余力再搞：

• 工具调用规范化
• 本地模型路由

按这个顺序做完前两批，Token 消耗通常能降 60–90%。

---

有任何配置问题欢迎评论区交流，或联系我提供有偿远程协助。

免责说明：以上优化来自社区实践和个人测试，效果因使用场景不同而有差异。建议小范围验证后再全量应用，迁移前备份好配置文件和 session。