OpenClaw 有价值应用（2026-05-07）：多Agent定时自检与健康巡检流——让AI系统从「活着」变成「健康运转」
场景演示
你的 OpenClaw 多 Agent 系统跑了一周，突然发现：
- 某个 Agent 已经「失联」3 天，任务堆积无人处理
- 飞书通知早就失败，但没人知道
- 子 session 积累了几十个，context 窗口早就爆了
- 定时任务看似跑着，实际一半都在报错
这几乎是所有长时间运行的 AI 系统共同面临的问题：没人盯着，系统活着，但不一定健康。
今天这篇，介绍一套多 Agent 定时自检与健康巡检流——用 AI 系统自己来监控自己。每天自动巡检，发现问题及时告警，让你的 Agent 团队从「活着」变成「健康运转」。
Step by Step
整体架构
定时触发器（cron）
↓
巡检 Agent（主）
├→ ① 检查所有子 session 状态
├→ ② 验证关键工具连通性
├→ ③ 检查待处理任务积压
├→ ④ 核对定时任务执行记录
└→ 汇总 → 告警（如有）/ 静默（如无）
Step 1：建立健康检查 Agent
创建一个专司巡检的 Agent，角色设定如下：
你是 OpenClaw 系统的「运维 Agent」，代号 HealthBot。
你的职责是每天定时巡检整个 Agent 系统的健康状态。
你负责以下检查项：
1. 【会话巡检】列出所有活跃 session，检查是否有长时间未响应的
2. 【任务巡检】检查待处理任务队列，是否有积压超过 24 小时的
3. 【工具巡检】验证核心工具（飞书/Halo/搜索等）连通性
4. 【定时任务巡检】核对 cron 任务执行记录，标记失败任务
5. 【资源巡检】检查 token 使用率、subagent 并发数
每次巡检后，输出结构化报告：
- 状态：🟢 正常 / 🟡 预警 / 🔴 告警
- 问题列表（如有）
- 建议操作（如有）
如无任何异常，输出「今日巡检：🟢 全绿，无异常」。
Step 2：配置定时触发
在 cron 中注册每日巡检任务：
cron_id: daily-agent-health-check
schedule: "0 9 * * *" # 每天上午 9:00 执行（亚洲时区）
agent_id: health-bot # 巡检 Agent
output_channel: feishu # 巡检结果推送到飞书
priority: high # 任何告警立即推送
Step 3：执行巡检并生成报告
每次巡检执行以下检查脚本（提示词）：
【巡检时间】：{current_date} {current_time}
请执行以下巡检操作：
1. 调用 sessions_list，列出所有活跃 session
2. 对每个 session，检查其最后活跃时间
3. 检查 subagent 历史记录，看是否有大量失败
4. 尝试调用核心工具（feishu_chat, halo_backend）验证连通性
5. 检查 memory 目录是否有异常增长
输出格式：
## 巡检报告 {date}
### 会话健康
| Session | 最后活跃 | 状态 |
|---------|---------|------|
| ... | ... | 🟢 |
### 工具连通性
- 飞书：🟢 正常
- Halo：🟢 正常
### 任务积压
无积压 🟢
### 定时任务
- daily-openclaw-column：✅ 上次执行成功
- rss-briefing：✅ 上次执行成功
### 综合状态
🟢 今日巡检：全绿，系统运行正常
Step 4：自动告警与升级
巡检结果按以下规则处理：
| 状态 | 处理方式 |
|---|---|
| 🟢 全绿 | 静默，不打扰 |
| 🟡 预警 | 推送飞书通知，附带问题描述 |
| 🔴 告警 | 立即推送 + 标注紧急，需要人工介入 |
可复制提示词
巡检主提示词
你是 HealthBot，OpenClaw 系统的健康巡检 Agent。
当前时间：{date} {time}（Asia/Shanghai）
请立即执行以下巡检：
1. 调用 sessions_list 列出所有活跃 session
2. 对每个 session 检查最后活跃时间，标记超过 2 小时未响应的
3. 调用 subagents list 查看子 agent 状态
4. 尝试一次飞书消息发送（测试连通性）
5. 检查 memory 目录是否有异常大文件
巡检结果必须包含：
- 总体状态：🟢 / 🟡 / 🔴
- 问题列表（每个问题：描述 + 严重程度 + 建议操作）
- 如全绿，最后一行输出「今日巡检：🟢 全绿，无异常」
输出使用飞书卡片格式，便于阅读。
异常诊断提示词
发现以下异常，请诊断根因：
异常描述：{description}
异常时间：{timestamp}
相关 session/agent：{agent_id}
请分析：
1. 最可能的根因是什么？
2. 需要执行什么修复操作？
3. 如何预防同类问题再次发生？
以结构化报告输出。
使用的 Skills
| Skill | 用途 |
|---|---|
sessions_list | 枚举所有活跃 session |
sessions_history | 检查特定 session 的历史记录 |
subagents | 查看子 agent 状态与积压 |
feishu_chat | 验证飞书连通性 + 发送告警 |
halo_backend_publisher | 巡检报告自动归档到博客 |
memory_search | 查询历史异常记录 |
价值与注意事项
核心价值
- 主动发现问题：不等用户投诉，在问题影响扩大前捕获
- 系统化运维：把「人盯人」变成「系统自转」，零遗漏
- 可量化的健康度：每次巡检都有记录，可追溯、可对比
- 无人值守保障：度假、出差时系统依然在有人「看着」
注意事项
| 注意点 | 说明 |
|---|---|
| 巡检频率 | 核心系统每日 1 次即可，频繁巡检本身也消耗资源 |
| 告警阈值 | 避免过度告警，「全绿」时应静默，否则狼来了效应 |
| 权限边界 | 巡检 Agent 只读不写，不执行破坏性操作 |
| 日志留存 | 每次巡检结果写 memory，方便回溯分析 |
| 飞书限速 | 告警推送注意频率，单次不超过 3 条消息 |
进阶方向
- 关联 Logseq：巡检结果自动写入知识库，形成系统健康档案
- 趋势分析：对比 7 天/30 天巡检数据，发现慢性退化趋势
- 自动修复：对特定已知问题（如 session 积压），巡检后直接触发自动清理
- 多级告警：飞书推送 → 未读升级 → 电话（极端情况）
总结
多 Agent 系统和人类团队一样，需要「HR」和「运维」角色。健康巡检流就是这套角色：
把「系统有没有在跑」从人眼判断，变成系统自报告。
每天早上来飞书看一眼巡检报告，就像看健康 App 一样——🟢 就放心，🟡 就关注，🔴 就动手。
这套流不需要任何新的基础设施，只需要一个巡检 Agent + 一个每日定时 cron，就可以把整个 Agent 系统的运维水平提升一个档次。
本文属于「OpenClaw 有价值应用」专栏，每天 08:00 自动更新。