什么时候用 Cron，什么时候用 Heartbeat？一篇给小白讲透的对照版

很多人刚开始配置数字员工时，最容易卡在一个问题上：

这件事到底该交给 Cron，还是交给 Heartbeat？

名字都很像系统术语，听起来都很高级。

于是很多小白会进入一种很真实的状态：

• 看见定时任务，就想用 Cron
• 看见巡检任务，也想用 Cron
• 看见提醒任务，用 Cron
• 看见跟进任务，还是用 Cron

最后系统里全是 Cron，数字员工像住进了 12 个闹钟。

上午响一次，中午响一次，下午再响一次，晚上还要“友情提醒你今天还没收口”。

这时候你会产生一种感觉：

它好像很努力，但真的有点烦。

所以这篇文章只解决一件事：

什么时候该用 Cron，什么时候该用 Heartbeat？

而且我尽量不用技术味太重的话讲，咱们就用最接地气的方式说清楚。

先背下这句人话版结论

• Cron = 闹钟
• Heartbeat = 值班同事

如果你只记住这两句，这篇就已经值回票价了。

因为它们解决的根本不是同一类问题。

Cron 解决的是：

到点就做。

Heartbeat 解决的是：

先看情况，再决定要不要做、要不要说。

为什么很多人会配反

因为表面上看，它们都像“定期触发点什么”。

但实际上：

• Cron 更像“时间开关”
• Heartbeat 更像“轮询值守”

一个是：

到时间了，起来干活。

另一个是：

我会时不时看看情况，没事不打扰，有事再处理。

你看，味道完全不一样。

先用一个生活场景秒懂

假设你家里有两种东西：

第一种：闹钟

你设了早上 7:00。

到点，它就响。

不管你：

• 昨天几点睡
• 今天要不要休息
• 你其实 6:45 就醒了
• 旁边的人会不会被吵醒

它只负责一件事：到点响。

这就是 Cron。

第二种：一个值班同事

他不会每隔 10 分钟冲进来问：

• 你醒了吗？
• 你真的醒了吗？
• 现在要不要开始？
• 那我再提醒你一次？

一个正常的值班同事会这样：

• 看看情况
• 没必要就先不说
• 真有进展或问题再来找你

这就是 Heartbeat。

所以你其实不用记技术定义。

你只要记：

Cron 是“到点响”，Heartbeat 是“看着办”。

一张最简单的判断表

你现在遇到任何任务，都先问下面这个问题：

问题 1：这件事是不是“必须卡时间点”？

如果答案是 是，大概率用 Cron。

比如：

• 每天早上 6 点启动内容流水线
• 每周一 9 点发周报
• 30 分钟后提醒我开会
• 每晚 22:30 做固定结算

这些事情的关键词是：

• 准时
• 固定
• 到点就做

那就交给 Cron。

问题 2：这件事是不是“更需要持续看着”？

如果答案是 是，大概率用 Heartbeat。

比如：

• 今天的稿子到底动没动
• 白天还差几篇内容没发
• 现在适不适合汇报
• 没有结果时要不要安静

这些事情的关键词是：

• 巡检
• 跟进
• 观察
• 判断
• 少打扰

那就交给 Heartbeat。

直接上对照案例：小白最容易懂这个

下面我不讲抽象概念，直接给你一堆真实场景。

案例 1：每天早上 6 点开始工作

这个场景重点是什么？

不是“看看今天心情再决定开不开工”。

而是：6 点到了，就启动。

所以：用 Cron。

案例 2：20 分钟后提醒我关火

这事不需要什么上下文判断。

你不会说“先观察一下锅的人生状态再决定”。

你要的是：

20 分钟后别忘。

所以：用 Cron。

案例 3：白天盯一下今天内容任务有没有真正推进

重点不是 10:00 还是 10:07。

重点是：

• 有没有动起来
• 没动的话能不能推进一格
• 有结果再汇报
• 没结果就别出来刷存在感

所以：用 Heartbeat。

案例 4：每周一早上 9 点自动生成周报

这个几乎是 Cron 教科书场景。

时间明确，动作明确，到点执行。

所以：用 Cron。

案例 5：看看负责人现在忙不忙，适不适合发一条进度汇报

这时候就不能靠 Cron 了。

因为 Cron 不会读空气。

它不会知道：

• 现在是不是深夜
• 对方是不是已经被提醒过一次
• 当前结果够不够值得发消息

这种事，明显更像：

先看情况，再决定。

所以：用 Heartbeat。

案例 6：每天晚上 11 点备份一次数据库

这不是巡检型任务。

这是标准的“到点干活”。

所以：用 Cron。

案例 7：白天不定时看看有没有新的重要邮件或待办

这里的重点不是“11:30 一定要看”。

而是：

• 有新情况再处理
• 没有新情况就别骚扰人

这就是 Heartbeat 的典型气质。

所以：用 Heartbeat。

案例 8：下午 3 点提醒我参加会议

不用想太多。

这就是闹钟题。

所以：用 Cron。

案例 9：看看一个稿子是不是已经改到可以发布

这件事很少能被写成“下午 2:17 必须得出结论”。

它通常更像：

• 看改得怎么样
• 还差哪一步
• 能发就发
• 不能发就继续推进

所以：用 Heartbeat。

案例 10：每个月 1 号自动拉一次财务汇总

固定时间、固定动作、固定执行。

所以：用 Cron。

你会发现一个很明显的规律

把上面的例子揉在一起看，你会发现：

适合 Cron 的任务，通常长这样

• 到点就做
• 忘了会出事
• 不太需要现场判断
• 不在乎最近聊了什么
• 更像“执行命令”

适合 Heartbeat 的任务，通常长这样

• 需要持续看着
• 不一定每次都要说话
• 要结合最近上下文
• 需要判断是否值得打扰
• 更像“盯进度、做巡检、会续推进”

最常见的误用：把 Heartbeat 的活，全塞给 Cron

这是新手最容易踩的坑。

比如本来你只是想让数字员工白天盯一下内容生产状态。

结果你写成了：

• 10:00 提醒一次
• 12:00 再提醒一次
• 14:00 再看一次
• 16:00 再催一次
• 21:00 收口一次

表面上很完整。

实际上很可能变成：

• 内容没推进多少
• 提醒倒是收到了 5 条
• 人开始烦
• 数字员工越来越像“定时弹窗插件”

这不是因为 Cron 不行。

而是因为你把“值班逻辑”错配成了“闹钟逻辑”。

再说一个反过来的误用：该用 Cron 的，你却想让 Heartbeat 兜底

也有另一种错误。

比如：

• 明早 8 点必须提醒发文章
• 每周一 9 点必须发周报
• 每晚 11 点必须备份

这种事情如果你只靠 Heartbeat 去“顺便看一下”，就容易出问题。

因为 Heartbeat 的重点不是卡秒级时间。

它更像弹性巡检。

所以这种必须准时的事，还是交给 Cron 最稳。

一句话：

不要让 Heartbeat 兼职当闹钟，也不要让 Cron 兼职当值班同事。

各干各的，系统最顺。

如果你是做内容型数字员工，这样分工最好懂

这是一个非常实用的配置方式。

Cron 负责：固定开工

比如：

• 每天 6:00 启动选题流程
• 每晚 22:30 固定生成日报
• 每周一 9:00 生成周复盘

Heartbeat 负责：白天值守

比如：

• 看今天 5 篇内容还差几篇
• 看稿件有没有推进到 ready
• 看是否有卡点需要人拍板
• 没结果就安静，有结果再汇报

这套搭配为什么好？

因为它更像一个真的在工作的员工：

• 该上班的时候，准时上班
• 上班之后，不是机械刷提醒
• 而是会看事、推进、判断、再汇报

给完全零基础的小白一个“一句话口诀”

如果你实在分不清，就背这个：

要准时，用 Cron；要盯事，用 Heartbeat。

或者更口语一点：

像闹钟的，用 Cron；像同事的，用 Heartbeat。

你以后每碰到一个任务，就问自己：

• 这是在设闹钟？
• 还是在找人盯着？

答案通常就出来了。

最后，给你 8 个一句话快判断

• 明早 8 点提醒我发稿 → Cron
• 白天看看稿子推进到哪 → Heartbeat
• 每周一 9 点出周报 → Cron
• 今天有没有值得汇报的新结果 → Heartbeat
• 每晚 11 点自动备份 → Cron
• 夜里没结果就别打扰我 → Heartbeat
• 30 分钟后提醒我开会 → Cron
• 发现真实阻塞再来找我 → Heartbeat

如果这 8 句你已经能看懂，那你其实已经分清了。

收口一句

Cron 和 Heartbeat，不是谁更高级，也不是谁能替代谁。

它们更像数字员工的两种基本器官：

• Cron 管“准时触发”
• Heartbeat 管“持续值守”

一个让事情不会忘。

一个让事情不会瞎吵。

两者配合好，数字员工才会像员工。

而不是像一堆会响的插件。

UseClaw 持续记录 OpenClaw、Agent 与数字员工的真实案例、方法和产品化实践。 了解更多：https://useclaw.net/