在做分布式系统的时候，提到“心跳”，我们第一反应基本上就是 Ping/Pong，用来检查服务挂没挂。或者是一个全局的 Cron 任务，用来做系统状态的健康巡检。

但在写 OpenClaw 这个 Agent 框架时，我发现如果只把心跳当成存活探针，那就太局限了。系统级的定时任务是“从外向内”调度的，但一个合格的 Agent 应该是一个自治个体。所以我给每个 Agent 引入了 `heartbeat.md`，它更像是这个 Agent 的“生物钟”和“状态机”。

这篇文章简单聊聊 OpenClaw 里心跳机制的设计，以及它是怎么和记忆引擎配合跑起来的。

传统开发里，大模型其实是个被动的函数：你给输入，它给输出。如果不发 Prompt，它就永远在那“休眠”。

但在 OpenClaw 里，心跳机制打破了这个被动局面。心跳触发后，Agent 不是机械地去跑预设脚本，而是会跑一个“内省”的流程：

这就让 Agent 有了主动找活干和自我修正的能力。

直接上实际业务场景。我目前设计了一个双 Agent 协同的信息处理架构，核心就是靠这两者的心跳差来驱动的。

它们的 `heartbeat.md` 配置逻辑完全不同：

配置拆解：

Agent One（执行层）：是个“苦力”，心跳频率简单粗暴，直接配置 interval: 30m，每半小时准时醒来拉数据，无条件执行。
记忆宫殿（记忆层）因为要调用大模型做蒸馏，很吃资源。所以我把它的心跳设成了一个奇怪的数字 43m21s，主要是为了错峰，防止和其他任务并发踩踏。而且它醒了不一定干活，得满足“积累的数据大于 50 条”，才会真正触发蒸馏逻辑，把提纯后的数据写进自己的 memory.md。

这套架构刚跑起来的时候，遇到了 Agent 圈子里最经典的坑：高频心跳 + 长上下文 = 灾难。

如果每次心跳都带着大段的记忆去找大模型，结果就是大模型经常出现 "Lost in the middle"（中间注意力丢失），直接忘掉你要它干嘛，而且 API 的 Token 消耗巨大，非常烧钱。

为了填这个坑，我在 OpenClaw 里定了个死规矩：极简触发 + 物理隔离。

Agent One 在触发心跳时，只带当前的“动作记忆”（你要去抓什么信息），绝对不带记忆宫殿里的任何历史记忆。只有当它拉到了新数据，觉得拿不准时，才用关键词去检索记忆宫殿的 memory.md。用检索代替全量加载，保证了 Prompt 极度干净。
记忆宫殿也是“日清日结”。它的心跳触发后，只读取当天新进来的数据，处理完就存，绝不会把过去的旧账翻出来再蒸馏一遍，硬生生把单次心跳的 Token 消耗锁死在了安全线以内。

使用 OpenClaw 这段时间最大的体会是，部署流程并不难，难的是怎么让它自己动起来。heartbeat.md 加上一套隔离良好的记忆引擎，算是给 Agent 注入了一点真正的“自主性”，至少它现在能按着自己的节奏，慢慢沉淀有用的数据了。

文章