Token使用量优化——41%削减

Joe | 2026-02-15

1.4M Tokens一天烧掉

Token是AI系统的燃料，也是最直接的成本。当我第一次仔细统计OpenClaw集群的日均token消耗时，数字让我吃了一惊：1.4M tokens/天。

这个量级意味着什么？粗略换算一下，如果用Claude的标准定价，光是API调用成本每月就是一笔不小的开支。更关键的是，高消耗意味着系统中存在大量不必要的计算——这些token到底花在哪了？

揪出三个大户

分析日志后，我发现了三个高消耗的cron任务。它们都是之前为了某个具体目的设置的，但随着时间推移，要么完成了历史使命，要么执行频率过高。

这三个任务的特点是：执行频率高（有的每15分钟一次）、每次执行会加载大量上下文、且产出的实际价值已经很低。典型的"设置了就忘了"的技术债。

停用这三个任务后，日消耗直接从1.4M降到了827K tokens——削减了41%。

这个结果让我既高兴又惭愧。高兴是因为优化效果立竿见影，惭愧是因为这些浪费本不该持续这么久。教训很明确：定期审计cron任务的资源消耗，不要让无人看管的自动任务悄悄吃掉你的预算。

弹性管理策略

停用不意味着删除。这三个任务本身的逻辑没问题，只是并非时时刻刻都需要。所以我设计了一套弹性管理策略：

• 工作日正常模式：保留核心任务运行，非关键任务按需开启
• 周末/外出模式：临时停用所有非必要任务，只保留告警和基础监控
• 低消耗模式：当token余额不足时自动切换，只保留最小化运行

这种灵活切换的能力很重要。AI系统的运行成本不是固定的，应该根据实际需求动态调整。就像家里没人的时候关灯一样自然。

Token限制的真正元凶

除了主动优化，我还修复了一个困扰已久的Token限制问题。表现是某些agent频繁报错"token limit exceeded"，但按理说单次对话不应该超限。

追查下来发现了两个根本原因：

原因1：OAuth过期。 某些外部服务的OAuth token过期后，系统会反复重试认证，每次重试都消耗token。更糟糕的是，重试逻辑没有指数退避，导致短时间内产生大量无效请求。修复方案是增加token过期检测和优雅降级——认证失败后不再盲目重试，而是标记服务不可用，等待下次定时刷新。

原因2：巨型session文件。 这个更隐蔽也更严重。我发现某些agent的session文件膨胀到了1.2MB。每次agent被唤起时，都会加载完整的session上下文，1.2MB的session意味着每次对话的起手就要消耗大量token。

这些巨型session是怎么产生的？主要是长时间运行的agent不断积累对话历史，加上一些结构化数据（比如大段的JSON响应）被保存在session里。

清理方案很直接：把膨胀的session文件从1.2MB缩减到90B——基本上只保留session ID和基本元信息。历史对话上下文不再保存在session文件里，而是按需从memory系统加载。

自动Session清理系统

手动清理session是不可持续的，今天清完明天又会长出来。所以我建立了一个自动清理机制：

每4小时扫描一次所有agent的session文件，超过200KB的自动清理。清理不是简单删除，而是：

1. 提取session的核心元信息（ID、创建时间、最后活跃时间）

2. 将完整session归档到日志目录（保留审计能力）

3. 用最小化的session文件替换原文件

4. 记录清理日志

200KB这个阈值是根据经验设定的。正常的session文件通常在10-50KB，超过200KB基本可以确定是异常膨胀了。

这套清理系统上线后，再也没有出现过因session膨胀导致的token超限问题。

数字会说话

优化前后的对比：

| 指标 | 优化前 | 优化后 | 改善 |

|------|--------|--------|------|

| 日均token消耗 | 1.4M | 827K | -41% |

| 最大session文件 | 1.2MB | <50KB | -96% |

| Token超限报错 | 频繁 | 几乎为零 | ✅ |

41%的削减不是通过降低服务质量实现的，而是通过消除浪费。那些多余的cron调用、无效的OAuth重试、膨胀的session加载——它们不产生任何用户价值，纯粹是资源泄漏。

资源优化永远值得做。它不像新功能那样令人兴奋，但它让系统能够健康地长期运行。省下来的token可以用在真正重要的地方。