如何节省OpenClaw 80%的Token消耗

最近正好因为业务在爆改OpenClaw，然后做自己业务的Claw，就给大家分享一下在OpenClaw处理上下文中，一些对于普通用户可以节省Token的Tips。

Skills

OpenClaw的Skills设计是这样的:

磁盘 SKILL.md 文件
    ↓ loadSkillEntries()           — 扫描磁盘
    ↓ filterSkillEntries()         — 按配置过滤
    ↓ applySkillsPromptLimits()    — 截断保护
    ↓ formatSkillsForPrompt()      — 只取名称+描述
    ↓
skillsSnapshot.prompt（纯文本，约几百字节）
    ↓
buildSkillsSection()               — 包裹使用规则
    ↓
system prompt 数组中展开

第一步

OpenClaw的第一步会取你所有 可用 的Skills的 name 和 description放入上下文中。

好消息是：它只会取你前 N 个 skill，默认上限 150 个。

坏消息是：就算只取50个Skills的 name 和 descriptiom也是超高的上下文消耗。

紧接着取出来可用的之后，第二步还会用二分查找找到最大能装下的前缀，默认上限 30,000 字符。

第二步

只有当模型判断真的需要某项技能时，才会自己调用 Read 工具拉取具体的 SKILL.md 回来。（一轮对话只会选中一个，不会选中多个，这是写在源码提示词的东西），然后去执行。

后面的步骤基本都跟节省消耗关系不大了。

Project Context

OpenClaw 启动或者是开启新 Session 时，会自动根据配置（比如 workspace 下的 AGENTS.md、SOUL.md 以及其他指定的上下文文件）提取上下文，并且将它们作为 Project Context 组装到 System Prompt 中。

这也是消耗 Token 最核心的地方，它的文件加载限制设计是这样的：

配置的 Project Context 文件列表
    ↓
buildBootstrapContextFiles()       — 开始分配字符额度 (Budget)
    ↓
    ├— 每个文件最高不超过 20,000 字符 (默认 bootstrapMaxChars)
    ├— 所有文件总计最高不超过 150,000 字符 (默认 bootstrapTotalMaxChars)
    ↓
拼接进 System Prompt 的 Project Context 块

第一步：单文件额度与“掐头留尾”保护机制

好消息是：就算你把单个指导文件（例如 AGENTS.md）写得太长，超过了单文件上限（默认是 20,000 字符），OpenClaw 也没有生硬地一刀切掉后半边，更不会因为读取超限而直接崩掉。它底层采用了一种掐头留尾砍中间的截断策略：

• 保留文件开头的 70% （Head Ratio = 0.7）
• 保留文件结尾的 20% （Tail Ratio = 0.2）
• 将文件中间被砍掉的长段替换为一句 [...truncated, read {fileName} for full content...]

坏消息是：这种截断是完全无脑按物理字数切割的。如果你恰好把一段极长、极其详尽的排错代码或者业务逻辑写在了中间的截断区，大模型甚至连阅读这段逻辑的机会都没有，这部分内容就这么凭空消失了。

第二步：全局预算耗尽保护

我们知道OpenClaw有这些默认文件，但是这只是OpenClaw给的小白用户一个比较好的默认起点配置而已，你完全可以写更多的File去引导大模型，加在Agent.md入口中，或者其他入口里。

如果你的文件实在太多，即使每个都没超过两万字，但全部配置文件的总字数由于堆叠逼近了全局上限（默认 150,000 字符）时：每塞进去一个文件，系统剩余可分配的字符配额（remainingTotalChars）就会疯狂缩减。

当装到某一个文件时，系统发现可用余量少于 64 个字符（源码里写死的门槛 MIN_BOOTSTRAP_FILE_BUDGET_CHARS）时，OpenClaw 会觉得“只剩 64 个字符了，塞个文件名进来毫无意义”。于是，它会直接打断并彻底废弃加载后续队列里的所有上下文文件。

结束

文章写长了没人看，所以多写几章。后面应该会写一些配置上如何节省Token，长记忆最佳的总结机制，长记忆Embed/Query的最佳实践、缓存机制等。

完整的实现，我目前自己测试过，每轮对话能节约30-60%的Token使用。而根据业务完全的魔改版能节约40-80%的Token使用。（我的计算基准是根据OpenClaw里有个Report的函数，并没有计算上游Cache等场景，可能不是特别准确）

所以可以想象的是调优是件很有必要的场景。

欢迎加入我们的OpenClaw调优社区，这里有很多的技术大牛，也有各种寻求帮助的用户。