OpenClaw 定时任务和 heartbeat 到底选哪个：官方五维对照表逐行拆解
如果你搜过「openclaw cron vs heartbeat」，多半会落到一个只有一句话的页面上：那页已经合并走了，官方把内容挪到了自动化总览页的「Automations vs Heartbeat」小节。顺带说一句，文档里现在管定时调度叫 Automations，不再叫 cron；cron 表达式仍然是它支持的一种写法，但概念名已经换了。你在旧文章、旧笔记里看到的 “cron job” 和现在文档里的 “automation”，指的是同一套东西。
搞混这两者的后果很具体。你想让 Agent 每 30 分钟看一眼收件箱，结果配成了 automation，于是每次检查都开一个全新的隔离会话，Agent 不知道你半小时前刚跟它讨论过什么，还每次都往任务账本里塞一条记录；反过来，你想让日报每天早上九点整发出去，却挂在 heartbeat 上，结果它「大约」在九点前后某个时刻跑，还可能因为主队列正忙而被推后。这两种错配都不会报错，只会让你觉得「这东西不太靠谱」。
所以先把一句话结论摆在前面：需要精确时间或者需要干净的独立上下文，用 Automations；需要带着主会话的完整上下文、时间点差不多就行，用 Heartbeat。 下面按官方那张表逐行说清楚为什么。
官方的五维对照表
文档里给的对照维度只有五个，但每一行背后都有实际影响：
| 维度 | Automations | Heartbeat |
|---|---|---|
| 触发时机 | 精确（cron 表达式、一次性任务） | 近似（默认每 30 分钟） |
| 会话上下文 | 全新隔离会话，或共享会话 | 主会话的完整上下文 |
| 任务记录 | 始终创建 | 从不创建 |
| 结果投递 | 渠道、webhook，或静默 | 直接出现在主会话里 |
| 典型场景 | 报告、提醒、后台作业 | 收件箱检查、日历、通知 |
触发时机这一行是最容易被低估的。Heartbeat 官方口径是「近似」，默认每 30 分钟一次，它本质上是一次周期性的主会话轮次，不是一个到点必响的闹钟。任何对「几点几分」有要求的活儿，都不该往 heartbeat 里塞。
会话上下文这一行决定了「Agent 记不记得你」。Automation 可以跑在全新的隔离会话里，好处是干净、互不污染，还能给它换一个不同的模型（官方举的例子就是每周深度分析这类任务可以用不同模型跑）；代价是它对你主会话里正在聊的东西一无所知。Heartbeat 相反，它就发生在主会话里，检查结果直接以内联形式出现在你的会话流中。
任务记录这一行会影响你事后复盘的能力。所有 automation 运行都会在后台任务账本里落一条记录，可以用 openclaw tasks list 和 openclaw tasks audit 查「跑过什么、什么时候跑的」。Heartbeat 轮次从不创建任务记录——这意味着你没法用任务账本去审计心跳做过什么。想留痕，就得走 automation。
Heartbeat 那几条容易踩的硬约束
文档在 heartbeat 词条里额外写了几条约束，比对照表更值得抄下来贴在墙上：
- 不延长会话新鲜度：heartbeat 轮次不会延长每日/闲置的会话重置新鲜度。也就是说，别指望靠心跳「把会话续着」，该重置还是会重置。
- 监控清单是提示词上下文，不是任务队列：官方原话是 heartbeat monitor scratch 属于「小块提示词上下文」，需要周期性执行的活儿应当排成 automation 作业。往心跳清单里堆一长串待办，方向就跑偏了。
- 空清单会直接跳过：清单为空时这一轮以
empty-heartbeat-file跳过。所以你如果在日志里看到这个标记，那不是故障，是「没东西可检查」。 - 忙的时候自动延后：定时的 heartbeat 会在这几种情况下自动推迟——主队列或 automation 工作正忙、同一个 Agent 有另一次回复或嵌入式运行正在进行、解析出来的目标会话本身还有进行中或排队中的工作。
最后一条是排查「心跳好像没跑」时最先要看的方向：它可能不是坏了，而是按设计让路了。这跟网关那套健康检查是两回事，别拿 health 的结果去判断心跳有没有执行，两者的关系可以另看health 与 heartbeat 两套健康检查的区别。
Automations 这边能做的事
Automations 是 OpenClaw 内置的调度器，官方描述里有三个关键动作：持久化作业、到点唤醒 Agent、把输出投递到聊天渠道或 webhook 端点。支持的触发形态有三类：
- 一次性提醒（对应「20 分钟后提醒我」这种，用
--at）； - 循环的 cron 表达式（对应「每天早九点」「每周一次」）；
- 入站 webhook 触发。
投递方式上，除了发到渠道和 webhook，还可以选择静默——跑完不打扰你，但记录照留。这条组合起来看就很清楚了：automation 是「有交付物」的自动化，heartbeat 是「有觉察力」的自动化。
如果你的定时任务压根没触发，那是另一类问题，排查路径见定时任务不触发怎么查。
官方给的场景对照，直接照着抄
总览页还给了一张按用例反查机制的表，把 automations、heartbeat 和另外几种机制放在一起。这张表比抽象的维度更好用，因为它直接说「这种需求选哪个、为什么」：
| 需求 | 推荐机制 | 官方给的理由 |
|---|---|---|
| 每天 9 点整发日报 | Automations | 时间精确、执行隔离 |
| 20 分钟后提醒我 | Automations | 一次性且时间精确（--at） |
| 每周跑一次深度分析 | Automations | 独立任务，可用不同模型 |
| 每 30 分钟看一次收件箱 | Heartbeat | 与其他检查合批、带上下文 |
| 盯着日历上的即将到来的事项 | Heartbeat | 天然适合周期性觉察 |
| 看某个子 Agent 或 ACP 运行的状态 | 后台任务 | 任务账本记录所有分离出去的工作 |
| 审计跑过什么、什么时候跑的 | 后台任务 | openclaw tasks list / openclaw tasks audit |
| 多步研究然后汇总 | Task Flow | 持久编排，带修订追踪 |
| 会话重置时跑个脚本 | Hooks | 事件驱动，在生命周期事件上触发 |
| 每次工具调用都要执行代码 | 插件 hooks | 进程内 hook 可以拦截工具调用 |
| 回复前永远先查合规 | 常驻指令 | 自动注入每一个会话 |
看这张表最大的收获是：很多人纠结「cron 还是 heartbeat」，其实需求根本不在这两者里。「每次工具调用都做点什么」是插件 hook 的活，「每个会话都要遵守某条规矩」是常驻指令的活——后者住在工作区文件里（通常是 AGENTS.md），被注入到每个会话，具体用法可以看常驻指令怎么写、怎么和轮询配合。
混用时的分工
文档在「它们怎么协同」一节给了很明确的分工建议，值得逐条落到自己的配置上：
- Automations 管精确排期（日报、周复盘）和一次性提醒，所有运行都产生任务记录；
- Heartbeat 只管一份合批的监控清单，每 30 分钟过一遍；需要独立节奏的检查，归 automation 管；
- Hooks 响应具体事件（会话重置、上下文压缩、消息流转），插件 hook 负责工具调用层；
- 常驻指令给 Agent 持续的上下文和权限边界；
- Task Flow 在单个任务之上协调多步流程；
- 任务账本自动追踪所有分离出去的工作，供你事后查看和审计。
其中第二条是实践里最有价值的一句：heartbeat 只配一份清单。一旦你发现自己想要「收件箱每 10 分钟、日历每小时、报表每天一次」，那就是三个不同节奏，应该拆成 automation，而不是继续往心跳清单里加行。心跳的定位是「一次轮次里批量过一遍需要留意的东西」，节奏只有一个。
什么时候这套划分不够用，以及文档没写的部分
先说不适用的情况。如果你要的是「事件一发生就立刻反应」，那 automations 和 heartbeat 都不合适——前者是按时间排期，后者是按周期轮询，两者都不是事件驱动。事件驱动那一侧属于 hooks（生命周期事件）和 automations 的入站 webhook 触发。同理，如果你要的是多步、需要中间状态和修订追踪的长流程，单个 automation 也扛不住，那是 Task Flow 的范围。
再说文档口径的边界。这几点官方文档里没有给出具体说明，别自己推断：
- heartbeat 的 30 分钟是「默认值」，具体在哪个配置键上改、可调范围如何，本页没有写明，需要去配置参考里查；
- automation 与 heartbeat 同时到点时的优先级细节，只写到「heartbeat 会在 automation 工作繁忙时自动延后」，更细的调度策略没有展开；
- 各机制的执行开销、并发上限之类的数字，文档未说明。
最后一个提醒是关于命名的。因为文档改过名，社区里「cron job」和「automation」两个词还会长期并存，你在写自己的运维手册时最好统一到 automation，并且在提到 heartbeat 的时候明确一句「它不产生任务记录」——这句话能挡掉后面一大半「我明明配了检查，为什么 tasks list 里什么都没有」的困惑。
延伸阅读
- 从头读起：OpenClaw 架构总览：网关、Agent、渠道、节点、插件五层各管什么，出问题该往哪查
- 本专题共 40 篇，完整分组目录见专题页
- OpenClaw webhook 收不到消息：先分清三条链路，再按注册、鉴权、载荷逐段定位
- OpenClaw hooks 怎么用：事件清单、目录结构与”装了不跑”的三种原因
本文依据 OpenClaw 官方仓库（github.com/openclaw/openclaw）docs/ 下的官方文档整理，核对日 2026-08-17。
我们没有安装或运行过 OpenClaw，因此不涉及界面外观、操作手感与实测耗时的任何描述；
文中的默认值、命令与配置项均为文档口径，不构成对实际运行结果的保证。
该项目迭代很快，请以仓库最新内容为准。接入即时通讯平台前，请自行确认所在平台的规则与合规要求。