在做分布式系统的时候，提到“心跳”，我们第一反应基本上就是 Ping/Pong，用来检查服务挂没挂。或者是一个全局的 Cron 任务，用来做系统状态的健康巡检。
但在写 OpenClaw 这个 Agent 框架时，我发现如果只把心跳当成存活探针，那就太局限了。系统级的定时任务是“从外向内”调度的，但一个合格的 Agent 应该是一个自治个体。所以我给每个 Agent 引入了 `heartbeat.md`，它更像是这个 Agent 的“生物钟”和“状态机”。
这篇文章简单聊聊 OpenClaw 里心跳机制的设计，以及它是怎么和记忆引擎配合跑起来的。
一、 为什么需要 Agent 级别的心跳？
传统开发里，大模型其实是个被动的函数：你给输入，它给输出。如果不发 Prompt，它就永远在那“休眠”。
但在 OpenClaw 里，心跳机制打破了这个被动局面。心跳触发后，Agent 不是机械地去跑预设脚本，而是会跑一个“内省”的流程：
- 打快照：醒来先看看自己当前在干嘛，任务跑到哪一步了。
- 查记忆：带着当前的快照，去检索 `memory.md`（底层的 Embedding 和 Reranker 会把相关的历史经验或者踩过的坑捞出来）。
- 自我纠偏：把现在的状态和检索到的记忆扔给大模型，让它判断现在的执行路径对不对，不对就及时调整。
这就让 Agent 有了主动找活干和自我修正的能力。
二、 真实场景：Agent One 与“记忆宫殿”
直接上实际业务场景。我目前设计了一个双 Agent 协同的信息处理架构，核心就是靠这两者的心跳差来驱动的。
- Agent One（干活的）：就是个信息收集器，专门在各个论坛和贴吧抓数据。
- 记忆宫殿（处理的）：是个 Sub-agent，负责把 One 抓回来的海量数据进行蒸馏、降噪，最后沉淀为核心记忆。
它们的 `heartbeat.md` 配置逻辑完全不同：
配置拆解：
- Agent One（执行层）：是个“苦力”，心跳频率简单粗暴，直接配置 interval: 30m，每半小时准时醒来拉数据，无条件执行。
- 记忆宫殿（记忆层）因为要调用大模型做蒸馏，很吃资源。所以我把它的心跳设成了一个奇怪的数字 43m21s，主要是为了错峰，防止和其他任务并发踩踏。而且它醒了不一定干活，得满足“积累的数据大于 50 条”，才会真正触发蒸馏逻辑，把提纯后的数据写进自己的 memory.md。
三、踩坑：如何避免 Token 爆炸和 Prompt 丢失？
这套架构刚跑起来的时候，遇到了 Agent 圈子里最经典的坑：高频心跳 + 长上下文 = 灾难。
如果每次心跳都带着大段的记忆去找大模型，结果就是大模型经常出现 "Lost in the middle"（中间注意力丢失），直接忘掉你要它干嘛，而且 API 的 Token 消耗巨大，非常烧钱。
为了填这个坑，我在 OpenClaw 里定了个死规矩：极简触发 + 物理隔离。
- Agent One 在触发心跳时，只带当前的“动作记忆”（你要去抓什么信息），绝对不带记忆宫殿里的任何历史记忆。 只有当它拉到了新数据，觉得拿不准时，才用关键词去检索记忆宫殿的 memory.md。用检索代替全量加载，保证了 Prompt 极度干净。
- 记忆宫殿也是“日清日结”。 它的心跳触发后，只读取当天新进来的数据，处理完就存，绝不会把过去的旧账翻出来再蒸馏一遍，硬生生把单次心跳的 Token 消耗锁死在了安全线以内。
四、结语
使用 OpenClaw 这段时间最大的体会是，部署流程并不难，难的是怎么让它自己动起来。heartbeat.md 加上一套隔离良好的记忆引擎，算是给 Agent 注入了一点真正的“自主性”，至少它现在能按着自己的节奏，慢慢沉淀有用的数据了。