心跳巡检

要解决什么问题

多 Agent 或「工人」场景里，任务往往从 inbox 和群聊两个入口进来：有的是只需确认的通知型消息，有的是必须真正跑完的任务型待办。若只靠人工翻列表，容易漏消息、重复处理，或者把已经挂了很久的 pending 一直拖着不处理。

heartbeat-patrol 把这类巡检做成可 cron 触发的固定流程（文档建议每 5 分钟一次，也支持手动巡检），在 Dashboard API 上拉取状态、执行动作并回写结果。

工作方式

技能依赖 Dashboard：GET inbox / chat 拉取待处理项，POST send / callback 发回复与回调；认证为 Authorization: Bearer {TOKEN}。

典型巡检顺序如下：

1. 扫描 inbox 中 pending 任务
2. 分类：通知型（仅确认）与任务型（需执行）
3. STALE-SKIP：超过阈值（默认 2 小时，即 STALE_THRESHOLD=7200 秒）的 pending 自动跳过
4. 检查群聊新消息
5. 对任务型项执行逻辑或发送回复
6. 标记完成

运行前需配置环境变量 OPENCLAW_ID（当前工人 ID，必填）、DASHBOARD_TOKEN，以及可选的过期阈值。

适用边界与注意点

• 这是编排层巡检：具体「任务怎么执行」仍取决于你接在后面的 Agent 或业务逻辑，技能负责扫、分、跳过过期项、回写与汇报。
• 没有可用的 Dashboard API 或 token 时，整条链路无法工作；cron 频率要与 API 限流、任务耗时匹配，避免 5 分钟周期内堆叠重复执行。
• STALE-SKIP 会主动放弃长时间未动的 pending，适合防止队列毒化，但若业务上允许超长排队，需要调大 STALE_THRESHOLD 或在上游改状态策略。