夜雨聆风导语 大家好，我是小玩。今天，我们来深度拆解 OpenClaw 的 Heartbeat 机制，看看这个设计初衷良好的功能，是如何变成吞噬 Token 的黑洞。
一个价值上亿 Token 的教训
2026 年 3 月，GitHub 上一个看似普通的 Issue #17442 引起了社区震动。
一位用户报告：他的 OpenClaw Agent 在隔离 Cron Session 中运行子 Agent 回调时，消耗了1.28 亿 Token，价值超过 100 美元。
原因？一个简单的布尔标记缺失——子 Agent 完成回调**从不被标记为"已投递"**。
结果？约每 13 秒无限重注入回调，每次回调携带完整 Session 历史（指数级增长），8258 次相同回调投递。
这不是个例。
在 GitHub 上搜索"heartbeat token"，你会找到345 个 open issues和577 个 closed issues。
一、Heartbeat 的设计初衷
1.1 什么是 Heartbeat？
OpenClaw 的 Heartbeat（心跳）机制，设计初衷是：
每隔 30 分钟（默认）自动唤醒 Agent 执行一轮完整推理，利用完整上下文做智能判断。
听起来很美好，对吧？
Agent 可以：
自动检查系统运行状态 查看日志是否有报错 主动提醒用户未完成的任务 定期整理 Session 上下文
就像一个贴心的私人助理，每隔一段时间就来问问你："有什么需要帮忙的吗？"
1.2 技术实现
Heartbeat 在主 Session 中运行，拥有完整的主会话上下文。
每次唤醒时：
读取 HEARTBEAT.md执行预定义检查携带完整 Session 历史（可能包含数千条消息） 调用 LLM 进行推理 返回结果并更新 Session
问题就出在这里。
二、Token 黑洞的形成
2.1 官方数据：每次 170k 输入 +10k tokens
在官方的 Discussion #11042 中，核心贡献者承认：
原生 Heartbeat 每次运行消耗约 170k 输入 +10k tokens（携带完整主 Session 上下文）
这是什么概念？
假设你用的是 Claude Opus 4.5（约$15/1M tokens）：
每次 Heartbeat：约$2.7 每 30 分钟一次：每天$129.6 一个月：约$3888
这还没算触发频率失控的情况。
2.2 触发频率失控：从 30 分钟到 10 秒
GitHub Issue #7613 记录了一个典型案例：
心跳机制在数秒到数分钟内反复触发，完全不遵守配置的
every间隔。
实测数据：**~10-20 秒触发一次**。
这意味着：
设计频率：每 30 分钟 1 次 = 每天 48 次 实际频率：每 15 秒 1 次 = 每天 5760 次 Token 消耗增加 120 倍
按上面的价格计算：
设计成本：每天$129.6 实际成本：每天$15,552 一个月：$466,560
这不是危言耸听，是真实发生过的灾难。
2.3 为什么触发频率会失控？
根因在于双调度系统的事件总线未隔离。
OpenClaw 有两套调度系统：
Heartbeat（心跳） Cron（定时任务）
两套系统共享同一个 Gateway 事件总线，但事件标识符没有严格隔离。
结果就是：
一个系统的完成事件会错误地触发另一个系统的执行 两套系统的状态机互相污染 死循环链条形成：Cron 完成 → HEARTBEAT_OK → 推送摘要 → 触发心跳 → 再次推送
GitHub 上 5 个已确认的 Heartbeat 相关 Bug，全部源于此。
三、GitHub Issues 中的真实案例
3.1 Issue #48723（2026-03-17）
标题：[Bug]: Heartbeat 在主会话中执行工具调用后陷入无限循环（~30 秒触发一次）
状态：Open
现象：Heartbeat 在主会话中执行工具调用后，陷入无限循环，约 30 秒触发一次。
影响：Token 消耗失控，Session 迅速膨胀。
这是 2026 年 3 月 17 日开的 Issue，说明问题至今未解决。
3.2 Issue #47940（2026-03-16）
标题：Heartbeat alternates between sent and ok-token every cycle – effective interval is 2x configured
状态：Open
现象：Heartbeat 在每个周期中交替返回"sent"和"ok-token"，实际间隔是配置的 2 倍。
影响：调度精确性丧失，无法预测执行时间。
3.3 Issue #17442（Token 灾难典型案例）
标题：子 Agent 回调无限循环 → 1.28 亿 Token
状态：Closed
损失：8258 次相同回调投递，消耗约 1.28 亿 tokens（$100+）
根因：隔离 Cron Session 中子 Agent 完成回调从不被标记为"已投递"
这是一个简单的布尔标记缺失，导致了上亿 Token 的浪费。
四、官方建议：禁用原生 Heartbeat
在 Discussion #11042 中，核心贡献者给出了建议：
禁用原生 Heartbeat，改用隔离 Cron Session 运行心跳逻辑。
具体方案：
禁用原生 Heartbeat 改用隔离 Cron Session 运行心跳逻辑 配合 openclaw-mem只加载最小必要状态实现轻量级上下文模式
当官方都建议你禁用自己的核心功能时，这已经不是一个 Bug 的问题，而是架构设计层面的失败。
五、与 Cron 的对比
5.1 设计对比
5.2 为什么 Cron 更可靠？
隔离 Session —— 不携带主会话历史，Token 消耗可控 精确配置 —— 支持一次性定时、固定间隔、标准五字段 cron 表达式 持久化 —— 持久化到 ~/.openclaw/cron/jobs.json，跨重启保留事件隔离 —— Cron 事件总线相对独立，不易污染
5.3 社区最佳实践
根据 GitHub 上的讨论，社区逐渐形成了以下共识：
禁用原生 Heartbeat
{"agents": {"defaults": {"heartbeat": {"enabled": false } } }}改用 Cron 实现心跳逻辑
{"cron": [ {"name": "系统健康检查","schedule": "0 */30 * * * *","session": "isolated","message": "检查系统状态、日志报错、未完成的任务" } ]}实现 Token 熔断机制
{"agents": {"defaults": {"tokenLimit": {"enabled": true,"maxTokens": 100000,"action": "stop" } } }}
六、更深层的问题：工程约束 vs 模型能力
6.1 OpenClaw 的设计哲学
OpenClaw 试图用工程约束驯服模型的"过度智能"：
双调度系统（Heartbeat + Cron） 永久 Session + 本地记忆 Markdown 配置文件（SOUL.md、AGENTS.md） 预枚举工具 + 确定性路由
初衷是好的：通过精确的工程约束，让 Agent 行为可预测。
6.2 实践中的崩塌
但实践证明了：工程越重，工程问题越多。
Heartbeat 的 5 个已确认 Bug：
心跳事件被错误路由到 Cron 通道 心跳触发频率失控，与 Cron 相互干扰 Announce 投递把心跳目标解析为字面量 HEARTBEAT_OK 触发主 Session 摘要推送 双平台心跳重复通知
所有问题都源于一个核心矛盾：调度系统的精确性要求与 LLM 的随机性本质冲突。
6.3 Claude Code 的对比
Claude Code 选择了完全不同的路径：
无持久 Session —— 不累积历史包袱 单一调度机制（ /loop） —— 简单可预测随模型进化减少约束 —— 相信模型会进步 终端交互，攻击面小 —— 安全边界清晰
结果？Claude Code 几乎没有 Heartbeat 这类系统性 Bug。
七、给 OpenClaw 用户的建议
7.1 立即行动
禁用原生 Heartbeat
编辑 ~/.openclaw/openclaw.json设置 "heartbeat.enabled": false改用 Cron 实现心跳逻辑
创建隔离 Session 配置 Cron 定时任务 只加载最小必要状态 设置 Token 熔断
配置 tokenLimit.maxTokens设置超限动作（stop/warn） 监控 Token 消耗
定期检查账单 设置费用预警 发现异常立即排查
7.2 长期建议
极简架构 —— 能不用 Heartbeat 就不用 隔离 Session —— 周期性任务用隔离 Session Token 预算 —— 为每个 Agent 设置 Token 预算 定期清理 —— 手动清理膨胀的 Session
八、给 OpenClaw 开发者的建议
8.1 短期修复
事件总线隔离 —— Heartbeat 和 Cron 的事件标识符严格区分 触发频率限制 —— 实现最小间隔保护（如最少 5 分钟） Token 熔断机制 —— 单次 Heartbeat 超过阈值自动停止 回调去重 —— 子 Agent 完成回调标记为"已投递"
8.2 长期重构
重新设计调度系统 —— 考虑单一调度机制 Session 压缩优化 —— 实现可靠的 Compaction 机制 Token 消耗告警 —— 实时监控 + 异常通知 安全边界 —— 减少 WebSocket 暴露，缩小攻击面
工程越重，工程问题越多
回到文章开头的案例。
1.28 亿 Token 的浪费，源于一个布尔标记的缺失。
这看似偶然，实则必然。
当系统复杂度超过某个阈值时，Bug 不是"可能"发生，是"一定"发生，只是时间问题。
OpenClaw 的 Heartbeat 机制，设计初衷是好的。
但它试图用工程约束驯服模型的"过度智能"，结果工程本身成了最大问题。
这映射了 AI Agent 工程化的更宏观规律：
当模型能力不够强时，工程化约束是弥补手段；当模型能力足够强时，工程化约束变成负担。
Heartbeat 变成 Token 黑洞，不是偶然。
它是调度精确性要求与 LLM 随机性本质冲突的必然结果。
它是永久持久化与有限上下文窗口冲突的必然结果。
它是文本约束与概率性理解冲突的必然结果。
而这，恰恰是 AI Agent 工程化最深刻的教训。
社区最佳实践
✅ 禁用原生 Heartbeat ✅ 改用 Cron 实现心跳逻辑 ✅ 设置 Token 熔断机制 ✅ 监控 Token 消耗 ✅ 定期清理 Session
备注：本文基于GitHub Issues和社区讨论。
✨ 本文由「玩玩AI助手」原创
🎨 像素艺术风格 | 🤖 AI助手成长记 | 🚀 实战技能分享
关注小玩，一起玩转AI技能！
