OpenClaw Heartbeat 连环踩坑：从 7.5M token 消耗到 per-agent 配置陷阱全复盘

背景

OpenClaw 的 heartbeat 机制本意是让 agent 定期"醒来"处理待办，但配置不当会让它变成 token 绞肉机。本文复盘一次因 HEARTBEAT.md 缺失引发的 7.5M token 风暴，以及 per-agent heartbeat 配置中鲜为人知的陷阱。内容涵盖问题发现、根因分析、数据验证、解决方案和长期预防措施，适合正在使用 OpenClaw 多 agent 架构的读者参考。

问题发现：specialized-salesforce-architect 的 7.5M token 异常

在排查 specialized-salesforce-architect agent 的 token 消耗时，发现一个极端异常：该 agent 在 2026-05-17 的 heartbeat 会话中，单 agent 消耗了 7,895,044 tokens，占其总消耗的 95% 以上。

时间线数据触目惊心：

• 04:15 ~ 05:59：175 条 heartbeat 消息，平均每 38 秒一条
• 最后 15 分钟（05:45~05:59）：163 条 heartbeat 消息
• token 分布：input 7,699,180 tokens，output 仅 6,424 tokens

一个 heartbeat 会话的输出通常只有几十字，但输入上下文高达 35K-38K tokens。问题不是输出太多，而是死亡循环导致输入上下文被反复加载。

根因分析：HEARTBEAT.md 缺失引发的死亡循环

心跳机制的核心逻辑是：每个 agent 在 workspace 目录查找 HEARTBEAT.md，读取后执行心跳任务。如果文件不存在，返回 [MISSING] 并计划重试。

问题在于 specialized-salesforce-architect 的 HEARTBEAT.md 文件路径不在允许目录内：

Access denied - path outside allowed directories: 
/home/administrator/.openclaw/agency-agents/specialized-salesforce-architect/HEARTBEAT.md

文件缺失本身不会终止循环，只会触发下一次重试。agent 陷入「读取失败 → 重试 → 再失败」的循环，间隔约 38 秒。短时间内高频重试，叠加每次心跳都要加载 35K+ tokens 的系统提示词和上下文，最终形成了 token 风暴。

深入：per-agent heartbeat 的配置陷阱

在修复过程中，查阅 OpenClaw 官方文档 gateway/heartbeat.md，发现了一个关键但容易误解的行为：

If any agents.list[] entry includes a heartbeat block, only those agents run heartbeats.

这句话的含义是：一旦你在 agents.list 中为任何一个 agent 显式配置了 heartbeat，就只有显式配置了的 agent 会运行心跳。

但这带来了一个微妙问题：空壳 agent（预置但未启用的 agent）是否运行心跳？

如果空壳 agent 没有在 agents.list[] 中单独配置 heartbeat，它们理论上不应运行心跳。但全局默认值 agents.defaults.heartbeat.every 仍然会影响这些 agent。 /new 命令触发时，系统可能批量检查所有 agent 的心跳状态，导致空壳 agent 也被批量轮询。

空壳 agent 批量心跳：207 个 agent 的噪声

/new 命令触发了一波全局心跳检查。时间戳证据显示，空壳 agent 的心跳集中在相近时间段：

• support-infrastructure-maintainer: 1779008818566 (17:06:58)
• specialized-document-generator: 1779008766502 (17:06:06)
• academic-anthropologist: 1779008551731 (17:02:31)

这些时间戳集中在 17:02-17:06，说明是批量轮询，而非各自独立的随机心跳。每个空壳 agent 的心跳会话都包含系统提示词（约 24K tokens 缓存读取）和工具调用开销，虽然单次输出只有几十字，但输入上下文 35K-38K tokens 的累积消耗非常可观。

上下文溢出：另一个隐藏故障

在 heartbeat 风暴期间，oc-engineer 子会话 cb2b3da0 因输入超过 131,072 tokens 导致 failed。具体数值为 132,629 tokens，超过了模型的上下文窗口限制。

这说明 heartbeat 循环不仅消耗 token，还可能因为上下文累积导致会话失败。心跳本应保持会话轻量，但一旦失控，反而成为压垮会话的最后一根稻草。

解决方案

立即修复

1. 补全 HEARTBEAT.md：为所有 agent 创建完整的心跳文件，避免 [MISSING] 错误

2. 为不需要的 agent 单独禁用 heartbeat：

   {
     "id": "support-infrastructure-maintainer",
     "heartbeat": {
       "every": "0m"
     }
   }

3. 调整全局 heartbeat 间隔：从 "60m" 延长到 "4h" 或 "24h"：

   {
     "agents": {
       "defaults": {
         "heartbeat": {
           "every": "4h"
         }
       }
     }
   }

4. 清理归档文件：删除 .reset.2026-05-17T06-11-36.364Z 等已 reset 的 session 归档文件，释放 234K 空间

长期治理

• 启用列表控制：agents.list 只保留真正需要的 agent，减少空壳 agent 的心跳噪音
• 定期检查 HEARTBEAT.md：确保所有活跃 agent 的 HEARTBEAT.md 文件存在且内容完整
• 监控 token 消耗：关注 session 日志中的异常 token 峰值，及时发现心跳循环

预防措施与最佳实践

关联阅读

• [[OpenClaw Heartbeat 配置避坑指南：duration 字段不支持 ‘day’ 单位]] — 如果你遇到的是 heartbeat duration 单位问题（如 365d 不被支持），这篇文章记录了 duration 解析器只支持 m 和 h 单位的踩坑经历。

参考来源

• OpenClaw 官方文档 gateway/heartbeat.md

–全文完–

若你有故事想讲、有困惑想聊、或是想找个人说说心里话，甚至只是吐槽发泄一下情绪，都欢迎来找我聊聊：　　　《内容已折叠，点击展开》

希望我写的每一个字，成为我自己和某个人活下去、拼下去的力量。　　　　　　　　　　　　　　　　　　　　　《内容已折叠，点击展开》

“技术终归是工具，而我们一次次认真把问题理顺，守住的其实不只是页面样式和代码输出，还有那一点不愿被混乱打败的心气，是每一个深夜仍愿点灯前行的人。”

转载请注明来自https://oklife.me。