我的OpenClaw每天消耗5000万token。以下是我的修复方法。

我在OpenClaw上运行了几个代理（一个内容管道加上一些辅助工具）。上周，我的LLM API用量突然飙升，而我的设置明显没有任何变化。以下是每日token用量的实际情况： - 第1天：约1100万 - 第2天：约2400万 - 第3天：约3300万 - 第4天：约4400万 - 第5天：约3200万 - 第6天：约5100万 6天内大约消耗了1.96亿token，且呈上升趋势。这时很明显不是“我只是忙”，肯定出了问题。所以我没有猜来猜去，而是去查了日志。 OpenClaw将每个会话写入.jsonl转录文件，每次轮询都会记录其自身的token使用量（input, output, cacheRead）。我写了一个小脚本，按代理、按天、按模型汇总token数。有两个数字非常突出： 1. 我所有token的95%都是cacheRead。这意味着模型在重新读取旧对话历史，而不是执行新任务。我真正关心的新任务不到5%。 2. 一个名为“main”的代理（我甚至已经不再使用了）占了总数的56%。 那么“main”在做什么呢？什么都没做。它只是一个旧项目的遗留物。但是OpenClaw的心跳机制每30分钟就戳它一下，日夜不停，询问“有事做吗？”而每次它都必须先加载整个会话历史（几个月前的，大约22.5万token）才能回复“HEARTBEAT_OK”然后继续休眠。也就是说，每天大约48次，它要读一本电话簿来说“没有”。永远如此。而且走的是更昂贵的路线，因为那个代理使用的是默认模型。真正让我抓狂的是：我之前已经尝试过关闭它。我留下了一个空的HEARTBEAT.md文件，本应让代理跳过检查。但在我的构建中，这个跳过并没有生效。它一直在运行。所以如果你也用同样的方式“禁用”了你的代理，去验证一下它是否真的停止了。 修复方法分为两部分： 1. 清除膨胀的会话。心跳每次都会拖着一大堆累积的历史记录。清除那一个会话可以立即降低费用，因为下一次心跳将从空白状态开始。不过要小心，保留你真正的DM/聊天会话，只移除那个垃圾会话。 2. 阻止它重新填充。一次性清除后问题会逐渐复发，因为心跳会不断向会话添加内容。持久的修复方法在配置中： - 将心跳间隔设为“0m”以完全关闭（如果该代理不做任何事情），或者 - 设置isolatedSession: true 加上 lightContext: true，这样每次心跳都在一个新的、很小的上下文中运行，而不是完整的历史。文档说这可以将一次运行从大约10万token降低到2-5千token。 另外我還发现了一个泄漏：我的其他代理也都在重复使用一个不断增长的会话（我传递了一个会话ID，但在这个构建中它并不会真正启动一个新会话），所以它们的上下文随着运行次数而膨胀。同样的思路可以修复：在任务之间重置会话，这样每次运行都从干净状态开始。 如果你不想被账单吓到，以下是一些要点： - 闲置的代理不是免费的。一个拥有臃肿会话的心跳机制可能比你的实际工作花费更多。 - cacheRead 是一个信号。如果你大部分token都是cacheRead，那么你是在为重新读取历史付费，而不是在完成任何任务。 - 检查“关闭”是否真的关闭了。空的HEARTBEAT.md并没有阻止我的代理。 - 阅读转录文件。每次轮询的用量都在那里。你不必猜测。通过一个基本上只是配置变更的操作，我将用量减少了一半以上。希望这能帮其他人省下几百万token。