OpenClaw 定时任务与 Token 降本：关掉 heartbeat 后我省了一半

Thu, 22 Oct 2026 00:55:00 +0800

AI 助理很爽，账单很实在。这篇记录我 9 月底一轮"降本改造"的完整手法和数字，以及围绕定时任务踩过的坑。

降本先算账：钱烧在哪

OpenClaw 的 token 消耗三大头：每次会话注入的上下文、对话历史随轮次膨胀、自动唤醒的后台模型调用。对应的三个手术，全在我机器上真实动过刀：

手术一：注入文件瘦身。 AGENTS/TOOLS/MEMORY 这些每次会话都背着跑。9/25 把 12.6KB 的 TOOLS.md 执行细节迁进专项档案后压到 3.7KB，开机注入总量从 ~42KB 降到 ~20KB，直接 -52%。手法就一句：常驻留指针，细节按需 read。

手术二：heartbeat 永久禁用。 OpenClaw 有心跳机制（默认每 30 分钟唤醒 agent 跑一轮 HEARTBEAT.md 清单）。听着贴心，账上不划算：一天 48 次后台模型调用，还跑在带全部历史的主会话里。我把 heartbeat.every 设 0m 关掉，职能拆给两个便宜替代：

cron 维护班：每天 23:56 提炼 daily 日志进 MEMORY.md、检查失败任务、标超期待办——设成静默模式（delivery none），干完不发消息，专治深夜打扰；
空闲压缩外挂：scripts/idle_compact.js 挂 Windows 计划任务，规则：空闲 ≥30 分钟且 transcript >40KB 才压缩，否则直接 SKIP。纯脚本零模型调用，把"定时唤醒模型"的钱省成 0。

手术三：压缩参数收紧。 compaction 的 maxActiveTranscriptBytes 从 600KB 降到 300KB，加 midTurnPrecheck、压缩后截断，thinkingDefault=off。

不压缩的下场：9/24 连锁报错

降本前我也付过学费。一个老会话涨到 305 条消息后，自动压缩恢复不了当轮，每一轮都重报同一条 “Auto-compaction could not recover this turn”——我微信里看到的就是"一直循环报错"。修复：agents.defaults.compaction 加 reserveTokensFloor=50000，openclaw config validate 通过，旧会话 /new 开新线。教训：长会话主动压缩（/compact 或外挂脚本），别等它自己崩。

cron 任务设计三条经验

现在跑着的：QQ 邮箱检查（08:50/18:10，结果推微信）、每日记忆整理（23:56 静默）。外加三个停用岗位。设计里学到的：

cron 表达式表达不了"8:50 和 18:10 两个时刻"（分钟位相同才行），我拆成两个独立任务；
Windows 语法陷阱：给任务的 prompt 里带了 &&/2>nul/type 这些 cmd 语法，PowerShell 直接炸——给 AI 的指令也要按执行环境的方言写；
推送失败有窗口期：微信主动消息需要近期互动窗口，晨检类任务要设计失败暂存、互动后补发。

最玄学的坑：调度器漂移

维护班连续多班不准点，排查记录值得单独一段：10/19-10/21 连续三班没在 23:56 触发、改成早上 08:40 补跑，漂移模式是 lastRun + 24h；另一头 QQ 邮箱晨检还整 25 天在 cron list 里不可见。根因指向：夜间机器休眠/网关未运行（合盖不休眠设置见安装篇）、以及 10/16 网关重启直接打断过正在跑的 job（报 error）。后来复查 job 又全见、推送恢复——大概率某次网关状态问题，自愈。

结论不漂亮但真实：定时任务的可靠性上限，是你那台机器和网关进程的存活状态。Windows 常驻笔记本跑调度，电源设置和重启时机是要认真管的事。

一份"AI 药方"的打假记录

最后讲个有趣的。为降本我拿过一份别的 AI 给的"修正版配置清单"，逐条对官方 docs 核完：一半是编的——.env 里四个"环境变量"全文档搜不到，推荐替换的模型名不存在，还让我开启一个早已内置的"工具结果自动丢弃"（OpenClaw 的 compaction 本来就有这机制）。照单执行就是在给配置埋雷。AI 给的配置建议，一律先对本机 docs 再上线，这句我写进了工作守则。