返回博客列表

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

2026年3月18日 | Ruichen Zhou | 约 8 分钟阅读
OpenClaw Linux 监控 自动化 QQ Bot

系列文章：本文是「OpenClaw + 基础设施」系列的第 2 篇。

  1. OpenClaw (Clawdbot) 多端部署：Gateway + Tailscale Serve + Node 配对
  2. OpenClaw Cron 监控实战：QQ Bot 通知链路排障与 Prompt 调优（本文）
  3. OpenClaw 多节点运维：Token 持久化、Gateway 冲突排障
  4. Tailscale + ZeroTier + FRP：11 台跨国设备的三层 Overlay 分工
  5. 1C1G VPS 服务编排：MetAPI 网关 + Nanobot + DERP 的资源取舍

本文记录如何用 OpenClaw cron 任务监控实验室 Linux 工作站，替代完整监控系统（Prometheus + Grafana），实现异常告警和每日摘要。

当前架构：

  • Gateway：Mac mini (100.100.1.3)，运行 OpenClaw Gateway（Jarvis 中枢）
  • Node：实验室 Linux 工作站 (100.100.1.5) + 一台 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）

为什么不上 Prometheus

对一台个人工作站，当前需求不需要 Prometheus + Grafana + exporter 全家桶。没有多节点集群、历史趋势分析、容量规划或团队值班面板的需求，只需要监控几个关键指标：GPU 温度异常、磁盘空间不足、系统负载异常、网络中断。

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

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

最小健康检查配置

检查项包括：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 设计的问题。

QQ Bot delivered:false 排障

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

查看 run metadata，发现关键字段：

status: ok
delivered: false
deliveryStatus: not-delivered

任务执行成功，但消息未投递。仅看顶层 status 会完全掩盖这个问题。

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

ToolInputError: to required

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

关键结论：通知系统中 ok 不等于送达，必须检查 delivery metadata。

8 个任务砍到 4 个

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

确认 QQ 通道稳定后，关闭 Telegram 侧的重复任务，只保留 QQ 作为主通道，Telegram 作为备用。任务数从 8 降到 4。

备用链路应该存在，但不应在日常运行中将主链路的复杂度翻倍。

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，不改底层逻辑）：

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

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

Skill 生态补全中的问题

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

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

三个问题叠加，说明该链路当前不够可靠，最终手动绕过。Skill 适合串联命令行、邮件、天气、消息渠道等分散能力，但尚未达到完全产品化的稳定程度。

当前系统状态：日报和异常告警均可正常运行，出问题时主动通知。通知链路需要手动验证 delivery metadata，prompt 需要迭代调优，skill 可靠性仍在完善中。

评论