OpenClaw 中的心跳：先进行廉价检查，仅在需要时使用模型

Source: Dev.to

核心理念：心跳是一个闸门，而不是工作流

把心跳想象成守门人。一个好的心跳会回答以下问题：

• 有什么东西坏了吗？（CI 失败、错误、部署警报）
• 有什么东西变了吗？（新的 PR、排队的新任务、客户的新邮件）
• 有什么是时间敏感的吗？（<2 小时内的日历事件、即将过期的证书）

如果这些问题的答案都是“否”，最好的输出就是一行文字：

HEARTBEAT_OK

任何多余的内容都是噪音。

通常不需要模型来完成这些

大多数心跳逻辑并不是“推理”。它们只是检查状态。以下是不需要 LLM 的例子：

• 仓库是否脏了？
• 是否有打开的 PR？
• 代理队列是否增长？
• 有作业失败吗？
• Slack/WhatsApp 是否断开？

对于这些，使用 shell 脚本 + 少量 API 调用就足够。

#!/usr/bin/env bash
# cheap‑checks.sh – returns HEARTBEAT_OK or an alert list

# Example checks (replace with real logic)
if git status --porcelain | grep .; then
  echo "HEARTBEAT_ALERT: repository has uncommitted changes"
  exit 0
fi

if curl -s https://api.example.com/ci/status | grep "failed"; then
  echo "HEARTBEAT_ALERT: CI pipeline failed"
  exit 0
fi

echo "HEARTBEAT_OK"

实用模式：先走廉价模式

先运行轻量脚本。它的输出要么是：

• HEARTBEAT_OK
• HEARTBEAT_ALERT + 列出发生了哪些变化的要点

只有在打印出警报时才调用模型。这样可以兼顾两方面的优势：

• $0 大多数时间只产生心跳
• 当真的有事发生时仍能得到简洁的人类可读摘要

何时应该使用模型？

当输出受益于语言理解时，模型才值得使用：

• 将多个警报汇总成一条信息
• 当多件事同时变化时决定先做哪件事
• 编写人类真正想阅读的“简报”
• 将原始日志转化为简短的行动计划

在我的设置里，我保持简单：

1. 运行廉价检查。
2. 如果产生警报 → 使用小模型（例如 Claude Haiku）进行摘要并给出后续建议。

调整心跳频率：更快不一定更好

心跳调度类似监控：你希望足够快以捕捉重要事件，但又不至于频繁到变成垃圾信息（或成本失控）。

短间隔（例如每 5 分钟）

适合

• 高速交付（大量 PR / CI 运行）
• 主动的事件响应
• 任何需要“立即响应”的场景

不适合

• 如果每次都运行 LLM，成本会很高
• 通知疲劳（“又一个无意义的警报”）
• 浪费计算资源 / API 调用

长间隔（例如每 30–60 分钟）

适合

• 大多数独立创始人工作
• “保持关注”类工作流
• 在不被打扰的情况下保持信息更新

不适合

• 事后才发现故障
• 某些任务会感觉不到“实时”

一个简单的经验法则

• 积极交付：每 5–15 分钟
• 构建模式但稳定：每 30 分钟
• 仅仅监视：每 60–120 分钟

如果你需要在精确时间点执行（例如“上午 9 点准时提醒”），请使用计划任务（cron）而不是心跳。

结论

如果你在使用 OpenClaw（或任何代理系统）：

• 让心跳廉价且确定性。
• 将模型视为升级层，而非默认路径。
• 调整频率以获取信号而非噪音。

想复制这个模式，先写一个小脚本，输出 HEARTBEAT_OK 或简短的 HEARTBEAT_ALERT 列表——只有在需要时才用模型对警报进行摘要。