推荐语

OpenClaw用户必看！揭秘八大技巧与六大原则，帮你轻松省下大量Token开销。

核心内容：
1. OpenClaw天生"烧Token"的四大深层原因分析
2. 控制Token消耗的八大实用技巧
3. 长期省钱的六大核心原则

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

很多人第一次认真用 OpenClaw，都会有一个共同感受：它不是有点贵，而是贵得很快。你以为自己只是发了几句简单的话，但账单和 usage 却在飞涨。原因并不只是“模型单价高”，更重要的是 OpenClaw 的工作方式决定了：每一轮都不是只把你这一句话发给模型，而是把一整包上下文重新组织后再发一次。

官方文档明确说明，OpenClaw 每次运行都会重建自己的 system prompt，其中包括工具列表、skills 元数据、工作区信息、运行时元数据，以及注入的 workspace bootstrap 文件；上下文还会包含对话历史、工具结果、附件等内容。

所以，理解 OpenClaw 的省钱方法，不能只盯着“回复别太长”。真正的大头通常在别的地方：长会话、静态文件注入、memory、工具 schema、工具输出、heartbeat、cron、视觉输入、缓存命中失败。只要这些地方没控制住，你把回复从 800 字压到 300 字，省下来的往往只是零头。

OpenClaw为什么天生容易“烧 token”

第一层原因，是它每轮都在重新装 prompt。官方的 token/cost 文档写得很直白：OpenClaw 会在每次运行时组装自己的 system prompt，里面带有工具列表、skills 列表以及其他运行元信息。也就是说，你看到的是“同一个会话继续聊”，模型实际看到的却是“新的一次完整请求，只是附带了上文”。这和很多人直觉里的“只追加一句话”完全不是一回事。

第二层原因，是工作区文件会被自动注入。OpenClaw 的 Agent/bootstrap 机制会把一部分工作区文件当作 Project Context 注入到系统提示里。官方文档说明，像 AGENTS.md、SOUL.md、TOOLS.md、IDENTITY.md、USER.md 这类文件都会参与 bootstrap 注入，而且还存在 bootstrapMaxChars 与 bootstrapTotalMaxChars 这样的上限控制项，说明这块本身就是官方承认的重要 token 来源。

第三层原因，是 memory 机制本质上不是“免费记住”，而是“文件 + 检索 + 提醒”。官方 memory 文档提到，memory 会和会话 token 阈值、flush、compaction 等过程发生关系；这说明 memory 不是一个完全脱离上下文成本的外挂，而是会进入整体 prompt/上下文管理体系。社区最近还专门有人提 issue，希望把 MEMORY.md 的注入方式做成 full/core-only/on-demand，因为大文件 MEMORY 会额外浪费数千 token。

第四层原因，是工具不只是“调用一次花一点”，而是工具 schema 本身就要占位。官方文档明确提到，系统 prompt 里会包含 tool list，skills list 则至少会带元数据；而 tools 的 schema 也会被模型看到。这意味着你暴露给主代理的工具越多、工具描述越长、能力面越宽，基础税就越高。

第五层原因，是工具输出和附件也会进入上下文。官方 context 文档把工具结果、附件都算在 context 里，这就解释了为什么很多人“查个网页”“读个日志”“看个文件”之后，后续每轮 token 都开始明显抬升——不是那次调用本身贵，而是它留下来的内容在后面持续收税。

第六层原因，是 heartbeat 和 cron 常常在后台默默吃钱。官方配置和 automation 文档都把 heartbeat、cron 作为内建机制来讲，而且 heartbeat 文档专门强调它会跑完整 agent turn，并给出了 isolatedSession、lightContext、独立便宜模型等降本建议。这说明对很多人来说，最隐蔽的成本并不在你手动发的消息，而在自动化任务。

第七层原因，是 prompt cache 并不总能稳稳命中。官方单独有 prompt caching 文档，说明 provider 可以复用未变化的 prompt 前缀，从而降低成本、提高速度；但社区 issue 里也已经有人反馈，在一些自动回复场景下，Anthropic 的 cache 会频繁 miss，表现为 cacheWrite 很高、cacheRead 为 0。也就是说，缓存是重要的降本工具，但不是绝对保险。一旦会话太乱、动态内容太多、前缀不稳定，缓存收益就会明显变差。

钱到底花到哪了

真正有效的省钱，第一步不是瞎压 prompt，而是先定位。OpenClaw 官方已经把一套比较完整的诊断入口给你了。最值得先用的是 /status、/context list、/context detail、/usage tokens 和 /usage full。官方 session/context 文档明确说明，/status 可以查看当前会话上下文使用情况，/context list 与 /context detail 可以看 system prompt 和注入文件中谁占得最多；usage tracking 文档则说明 /usage tokens 和 /usage full 能在回复中显示 token 统计。

这几个命令的价值很大，因为它们能帮你判断：你现在的问题到底属于哪一类。比如，如果 /context detail 显示 bootstrap 文件特别肥，那就优先瘦 AGENTS.md、SOUL.md、MEMORY.md；如果 usage 里 cacheWrite 持续很高、cacheRead 很低，那就说明缓存没吃上红利；如果自动化流里即使只回复一句简单内容，每轮还是要吃掉巨量输入 token，那就大概率是 heartbeat/cron 在用重上下文跑。

你可以把排查思路记成一句话：先分清是“基础盘子太大”，还是“单次任务太重”，还是“后台在偷偷跑”。这三种问题的解法完全不同。基础盘子大，靠瘦身；单次任务太重，靠改用法；后台偷跑，靠改自动化配置。

技巧一：少背历史

在所有办法里，效果通常最大的一条，是缩短会话寿命。OpenClaw 官方有专门的 session management / compaction 文档，说明它支持 manual 和 auto compaction，并且会追踪会话 token 估算、context window、reserveTokens 等概念。这背后的含义很直接：长会话就是贵，会话一长就必须压缩，否则上下文会越来越重。

所以，最朴素但最管用的使用习惯是：一个任务一个 session，做完就压缩（/compact）或新开（/new）。不要把代码调试、文章写作、日常闲聊、自动化巡检全塞进同一个长期主会话里。对 OpenClaw 来说，这种“什么都在一个线程里继续”的习惯几乎就是在主动抬高税基。

这里还有一个容易被忽略的点：compaction 虽然重要，但也不是万能神药。社区里甚至有人提过 issue，说 compaction 某些时候会退化成“Summary unavailable due to context limits”，导致摘要效果不好。这不代表 compaction 没用，而是说明你不能把所有节省希望都押在“让它自动帮我总结一切”上。更稳的策略是：先控制会话长度，再用 compaction 做兜底，而不是反过来。

技巧二：精简工作区文件

很多人用 OpenClaw 时，喜欢把 AGENTS.md、SOUL.md、TOOLS.md、USER.md 写得很丰满，恨不得把个人风格、项目说明、做事哲学、常见任务模板全塞进去。这样做短期很爽，但中长期几乎一定变成 token 黑洞。官方文档已经清楚表明，system prompt 每轮都会组装，workspace bootstrap files 会被注入；社区 issue 甚至直接批评过“workspace file injection wastes 93.5% of token budget”，可见这不是边角问题，而是典型大头。

所以，静态文件的写法要从“百科全书”改成“最小必要规则集”。AGENTS.md 只保留长期稳定的行为规则，不要写成长篇操作手册；SOUL.md 保留身份边界和高层风格约束，不要写散文；TOOLS.md 只写工具使用红线和调用偏好，不要塞十几页示例；USER.md 只保留对未来长期有用的个人偏好，不要存临时任务说明。官方既然提供了 bootstrap 大小上限控制项，就说明它鼓励你把这层控制在可管理范围内。

一个很好的原则是：规则留在 bootstrap，材料放到外部，按需 read。因为官方已经说明，skills 的详细说明通常是 metadata 先进入 system prompt，具体 instructions 在需要时再用 read 加载。这种按需加载思路，其实也适合你自己的项目材料。不要把案例库、风格样本、长文档常驻注入，而是需要时再读。

技巧三：优化MEMORY.md

很多人把 MEMORY.md 当“长期知识库”来用，什么都往里堆：历史项目背景、之前聊过的所有偏好、长篇操作约定、甚至大段摘要。这种做法在 OpenClaw 里特别容易出问题，因为 memory 既和检索相关，也和 compaction/flush 等机制相关。官方 memory 文档说明，memory flush 会在 token 阈值附近触发，并与 sessions.json 等状态挂钩；这说明 memory 是整个上下文生态的一部分，不是“免费外挂”。

更关键的是，社区已经明确有人指出：大体量 MEMORY.md 会带来明显 token 浪费，所以才有人提“configurable MEMORY.md injection mode”。这个信号很明确：MEMORY.md 最适合存高价值、长期稳定、低体积的信息，不适合存大量材料。例如你的角色、持久偏好、长期项目代号、固定输出格式，这类内容适合放；长篇知识、流程细节、调研资料，更适合放在可检索文件或普通文档里，靠 read / search 按需取。

如果你当前的使用方式更像“即时助手”而不是“长期陪跑型 agent”，那一个很直接的办法就是考虑关闭 memory 插槽。官方文档明确允许把 memory 插件设成 "none"。对很多只想写稿、读文件、跑工具的人来说，memory 带来的收益并没有想象中那么大，但额外复杂度和潜在成本却是真实存在的。

技巧四：按需启用技能和工具

OpenClaw 的一个巨大诱惑，就是你可以装很多 skill、接很多 tool，然后让它“什么都会一点”。但从 token 角度看，这种配置通常并不划算。官方 token/context/system prompt 文档都明确表示，system prompt 会包含 tools list、skills list。虽然 skill 的正文是按需 read，但 metadata 也不是零成本；工具 schema 更不是零成本。

所以，主代理最该遵循的原则不是“功能全”，而是“职责窄”。最省钱的做法往往是：主代理只暴露它经常要用、真正高频的工具；其他低频或重型能力，按需启用，或者用子代理隔离。尤其是那些描述复杂、schema 很长、输出又很重的工具，如果常驻在主代理上，基础上下文会被一直抬高。

如果你真的需要很多能力，比较合理的架构是：把主代理做轻，把具体子任务交给独立子代理或独立 session。因为官方 delegate / system prompt 相关文档已经说明，子代理会有自己的 session，且在一些情况下会对 bootstrap 注入做过滤，避免把所有静态上下文都一股脑继承过去。这比让一个“全能型主代理”背着全部历史和全部工具跑到死，通常省很多。

技巧五：及时清理工具输出

很多人以为“调用工具一次就多花一点 token”，于是只关注调用次数。其实更重要的是：工具返回了什么，以及这些返回有没有继续留在历史里。官方 context 文档已经把 tool results 明确算进上下文窗口；session pruning 文档则进一步说明，pruning 的核心作用之一，就是在调用前裁掉不再必要的旧 tool results，从而减少 cache write 体积和输入压力。

这意味着你在使用上要形成一套克制策略。看文件时，先看目录、标题和命中段落，不要动不动整篇读入；查日志时，只看报错前后几十行，不要把上万行原样塞进去；看网页时，先提取摘要或关键段，不要让它一次把整页 HTML/正文都吃进来。OpenClaw 能读很多东西，不代表你每次都该让它全量读。

如果你用的是 Anthropic 一类对 prompt cache 比较敏感的 provider，这个问题更明显。官方 token/cost 与 prompt caching 文档都强调了 cacheWrite / cacheRead 的存在；旧 tool results 越多，动态变化越大，越容易反复重写缓存而不是复用缓存。所以，工具输出清理得越及时，长期成本通常越低。

技巧六：降低输入文件大小

如果你的使用习惯里经常带图、看截图、做视觉理解，这块也要单独注意。官方 token use 文档给了 imageMaxDimensionPx 这类控制项，说明视觉输入的 token 压力是官方明确识别和支持优化的。图越大、信息越杂、分辨率越高，视觉模型要处理的输入就越重。

因此，视觉类使用最省钱的办法非常朴素：能用文本就用文本，非要用图就裁重点。不要把整屏截图、整页网页、整张长图直接扔过去；先裁到局部，先缩到重点区域，再让它看。你让模型看一张“屏幕全景”，很多时候它并不比看一张“报错框局部图”得到更多有效信息，但成本可能高得多。

技巧七：前台会话与后台自动化分层

如果你已经开了自动化，一定要单独检查这部分。OpenClaw 官方文档明确把 Cron Jobs 定义为 Gateway 的内建调度器，而 heartbeat 则会跑完整的 agent turn。更重要的是，官方给 heartbeat 专门列了几种降本手段：启用 isolatedSession 可以把每次 heartbeat 的上下文规模从非常大的量级压到更小的量级；lightContext 可以只带 HEARTBEAT.md；还可以给 heartbeat 单独指定更便宜的模型。

这说明什么？说明对很多人来说，最该先做的事不是改前台聊天，而是先审计后台自动化。你可能以为自己“今天也没聊几句”，但实际上 heartbeat 每 5 分钟跑一次，cron 每天跑几次，跑的还是重系统提示、重 memory、重工具集，那账单自然就会很夸张。

比较合理的原则是：前台会话和后台自动化要彻底分层。前台需要深推理、需要高质量，就用贵模型；heartbeat、例行巡检、状态同步、早晚报这类任务，尽量换成便宜模型，尽量用独立 session，尽量用 light context。后台任务的目标通常不是“最聪明”，而是“稳定、够用、便宜”。

技巧八：稳定prompt前缀，提高缓存命中率

官方 prompt caching 文档把作用说得很清楚：未变化的 prompt 前缀可以被 provider 复用，从而降低 token 成本、提高速度、提升长会话可预测性。换句话说，OpenClaw 这种“每轮重组 prompt”的架构，理论上其实很需要缓存来救。

但缓存是否能发挥作用，取决于你的前缀是否稳定。如果你每轮都在不断改 system 前缀的有效内容，比如不停注入新文件、让 tool output 大幅波动、使用方式导致 prompt 大范围变化，那缓存命中率就会很差。社区关于 cache miss 的 issue 已经说明，在某些自动流里会出现高 cacheWrite、低 cacheRead 的情况，这会导致你看起来“明明是继续聊”，实际上 provider 每轮都在重吃一大块输入。

所以，从使用习惯上说，最利于缓存的方式通常是：让基础 prompt 尽量稳定，把变化留给小范围的用户输入和必要的少量工具结果。静态规则不要来回改，工作区大文件不要反复注入，自动化任务不要动不动带全历史跑。

OpenClaw省token快速指南

如果你不想一次改太多，可以按下面这个顺序来做，通常收益最大。

第一步，先开诊断。先用 /status、/context detail、/usage full 看一轮。你的目标不是立刻优化，而是先判断：是 bootstrap 太肥，还是历史太长，还是工具输出过多，还是后台在跑。官方文档已经把这些诊断入口给全了。

第二步，先处理会话。无论是哪种问题，只要你当前会话已经很长，都应该先做 compaction 或直接新开 session。长会话不清，后面很多优化都会被稀释。

第三步，瘦静态文件。检查 AGENTS.md、SOUL.md、TOOLS.md、USER.md、MEMORY.md，把一切不是“长期稳定且高价值”的内容拿出去。并且考虑下调 bootstrapMaxChars 和 bootstrapTotalMaxChars，让系统不要默认吃太多静态上下文。

第四步，审计自动化。把 heartbeat、cron 单独拎出来看频率、上下文、模型、会话策略，优先打开 isolatedSession 和 lightContext，并考虑改用便宜模型。

第五步，精简能力暴露面。主代理只保留高频工具和必要技能，其余低频能力按需启用，或者做成子代理。这样你能同时压低系统提示、工具 schema、技能元数据三个部分。

第六步，调整使用方式。以后读文件、看网页、分析日志、看图片，都走“先缩小范围，再深入”的路线。不要把 OpenClaw 当成一个无底洞式上下文吞咽器。

OpenClaw省token日常操作守则

真正日常可执行的做法，其实可以压缩成一套守则。

第一，不要在一个会话里跨任务。写文章就是写文章，调试代码就是调试代码，自动化就是自动化。任何跨任务混用，都会让历史膨胀得很快。

第二，每次说需求时一次说全。因为在 OpenClaw 里，“补一句”不是便宜的小事，而是又跑了一轮完整请求。相比“先分析一下”“继续”“展开一点”“再改下标题”，一次说清楚目标、格式、长度和边界，通常更省。这个结论虽然属于使用经验，但和 OpenClaw 每轮重组上下文的机制是直接一致的。

第三，静态规则短，动态材料外置。规则进 bootstrap，材料放文件，按需 read。不要反过来。

第四，MEMORY.md 只存“记住你是谁”和“长期约束”，不要存“所有东西”。社区关于 configurable MEMORY 注入的讨论，本质就是在提醒大家：把 MEMORY 当仓库，最终一定反噬。

第五，重工具输出及时切断。读完长日志、长网页、长文件后，不要继续在同一个重历史会话里来回打磨。适当总结后另起新 session，往往更省。这个思路和官方 session pruning / compaction 的设计方向是一致的。

第六，自动化任务一律默认“轻模型、轻上下文、独立会话”。别把后台任务当成前台对话的自然延长。