返回博客列表

OpenClaw Cron 监控：QQ Bot 通知链路排障与 Prompt 调优

2026年3月18日| 更新于 2026年8月1日| Ruichen Zhou| 约 8 分钟阅读
OpenClawLinux监控自动化QQ Bot

历史说明（2026-08-01）：本文是 2026 年 3 月的历史记录，写的是当时那套 OpenClaw 部署：Gateway 跑在 Mac mini 上，cron 任务做健康检查和每日摘要。后来的告警诊断换成了另一个项目 hermes-agent，两者不是同一个项目，现状见《服务器报警了不用我爬起来查》。正文按当时状态保留。

2026 年 3 月，实验室的 Linux 工作站需要监控 GPU 温度、磁盘空间、系统负载和网络可达性。当时的决定是不上 Prometheus + Grafana，而是用已经在跑的 OpenClaw 配几个 cron 任务，做异常告警和每日摘要。

当时的架构：

  • Gateway：Mac mini，运行 OpenClaw Gateway（Jarvis 中枢）
  • Node：实验室 Linux 工作站 + 一台 VPS
  • 通知通道：QQ Bot（主），Telegram（备用）
  • 已有 Skill：12 个（bluebubbles、clawhub、gemini、healthcheck、model-usage、skill-creator、weather、api-health-check、caldav-calendar、imap-email、journal、provider-onboard）

1. 为什么不上 Prometheus

对一台个人工作站，当时不需要 Prometheus + Grafana + exporter 全家桶：没有多节点集群、历史趋势分析、容量规划或团队值班面板的需求，只需要盯住几个关键指标。

原则：只报故障，不报平安。

当时 OpenClaw 已经在运行，消息渠道也已接通，多配几个 cron 任务比单独起一整套监控系统轻量得多。它的定位是 watchdog，不是完整的 observability 系统。

2. 最小健康检查配置

检查项：GPU 温度和利用率、根分区占用、load average、网络可达性。

对应命令：

nvidia-smi --query-gpu=temperature.gpu,utilization.gpu --format=csv,noheader,nounits
df -h /
cat /proc/loadavg
ping -c 1 -W 2 1.1.1.1

OpenClaw cron 定时执行这些命令，按阈值判断有没有异常：正常时静默，异常时发一条短消息。这种方式做不了长期趋势分析，但对单台工作站的实时告警够用。

此外配了一个 Daily Smart Digest，汇总天气、日程和邮件里值得注意的事项。这个任务比健康检查更容易暴露通知链路和 prompt 设计的问题。

3. QQ Bot delivered:false 排障

测试阶段 QQ Bot 通知一切正常：简单消息、长消息、复杂格式均能送达。但 cron 任务实际运行后，任务状态显示 status: ok，QQ 端却收不到消息。

查看 run metadata，关键字段是：

status: ok
delivered: false
deliveryStatus: not-delivered

任务执行成功，但消息未投递；顶层 status 看不出问题，delivered 和 deliveryStatus 才对应实际投递结果。

手动执行 openclaw message send --channel qqbot --target ...，报错：

ToolInputError: to required

根因是发送参数名不一致：上层看起来已发送，底层因 to 字段未正确传递而静默失败。修复参数映射后，QQ 投递恢复稳定。

4. 8 个任务砍到 4 个

系统里一度堆了 8 个 cron 任务，实际是 QQ 和 Telegram 两条通道各一套近乎重复的配置。初衷是双通道冗余，副作用是同样的问题要排查两遍，故障时还得先判断是哪条链路出的问题。

确认 QQ 通道稳定后，关掉 Telegram 侧的重复任务，只保留 QQ 作为主通道，Telegram 留作备用。任务数从 8 降到 4。备用通道可以有，但不该让日常运行的复杂度因此翻倍。

5. Jarvis 日报 prompt 调优

目标是降低日报的模板感和机器味，让通知读起来像助手提醒，而不是在解析工单字段。

优化前的日报示例：

🌤️ 周日报｜3 月 8 日

今日焦点
斯图加特当前约 10.4°C，天气晴到少云，适合按轻量节奏安排今天。今日无固定日程，可作为低打扰整理/推进日；不过明早 09:30 有一项已确认预约，今天最好顺手把相关准备做完。

行动清单
1. 今天建议优先：确认明天 09:30 与 David Kesselring 的预约材料、出发时间和路线，避免早上临时赶。
2. 顺手处理：查看 Doctolib 的邮箱验证邮件；如果账号还没完成验证，今天补一下更稳妥。
3. 可选清理：DHL / Joybuy 物流通知可快速过一眼，确认是否需要改投递或留意包裹到达。
4. 低优先级：其余来信以资讯和促销为主。

优化前的风险提醒示例：

⚠️ 风险雷达
发生了什么：检测到一项临近预约：Doctolib 已确认你将于 2026-03-09（周一）9:30 赴约 D. Kesselring。
为什么值得注意：这是明确的近期待办事项，若需提前准备材料、确认地点/交通或调整行程，留给你的缓冲时间已不多。
建议下一步：今晚确认预约地点、出发时间、所需证件/病历/保险卡；如无法赴约，尽快查看是否需要改期或取消。
最晚处理时间：明早出发前
风险等级：中
数据置信：高（邮件主题明确写明预约已确认及具体时间）

信息完整度没问题，但过于条款化。

调优只改 cron prompt，其余不动：

  • 先说判断，再说下一步
  • 减少固定字段模板
  • 非真实风险不用“风险雷达”这类警报腔调
  • 能一句话说清的不拆成多个标签

调优后的消息读起来更接近助手提醒，而不是系统生成的结构化输出。个人自动化里，通知质量不只是信息准确性，还包括长期阅读意愿。

6. Skill 生态补全中的问题

尝试让 Jarvis 管理日历时，连续遇到三个问题：

  1. capture.py 直接退出，无错误信息
  2. calendar_assistant.sh 在 workspace 中找不到
  3. khal 可用但缺少默认日历配置，khal new 被拒绝

三个问题叠加，这条链路当时不够可靠，最终手动绕过。skill 适合串联命令行、邮件、天气、消息渠道这些分散的能力，但当时还没到完全产品化的稳定程度。

到三月中旬，日报和异常告警都能正常运行，出问题会主动通知；通知链路要手动验证 delivery metadata，prompt 还在迭代，skill 可靠性仍在完善。

评论