# Lesson 02｜监控与播报：如何做“异常优先、不刷屏”的 cron 体系

# 核心问题

很多团队的自动化最终死在两件事：

1. 没有监控：坏了没人知道；
2. 监控太吵：每小时“我还活着”刷屏，大家很快把通知静音，真正异常也看不到。

这一课讲一套可落地的 cron 告警设计：“任务层有流水、通知层有门控、群里只看关键变化”。

# 案例（真实）

# 案例 A：每小时网络探测，但只在异常/提醒窗口才通知

这条 cron 的关键不是“能测速”，而是把“刷屏风险”变成显式规则。

• 证据1：sessionKey=agent:main:cron:c01564b6-bd97-4a17-9e4d-a48f311c0518:run:ad07a702-52d0-44c4-8240-148802406a97｜2026-03-04T00:58:51.203Z｜quote 摘要："仅在出现异常，或到达提醒窗口时才发送通知..."
• 证据2：同 sessionKey｜2026-03-04T00:59:20.851Z｜quote 摘要："{ "ok": true, "messageId": "4675" ... }"

# 案例 B：新闻监控的“24h 时窗 + 多源兜底 + 单次发送”

同一条监控既要抗 429，也要避免重复消息；用“24h 首发时窗”强制去重，是典型的产品化规则。

• 证据1：sessionKey=agent:main:cron:b3c9715e-ee3c-4036-8940-f97e48e405c3:run:f741429b-206e-4883-82fd-2586bb0e1b38｜2026-03-04T00:23:32.398Z｜quote 摘要："严格时窗规则：仅纳入过去24小时内首次发布内容。"
• 证据2：同 sessionKey｜2026-03-04T00:24:27.730Z｜quote 摘要："web_search error: ... (429)..."
• 证据3（结果回执）：sessionKey=agent:main:cron:b3c9715e-ee3c-4036-8940-f97e48e405c3｜2026-03-04T00:26:10.499Z｜quote 摘要："{ "ok": true, ... }"

# 失败点（监控/播报常见坑）

1. 把 cron 当“消息生产机”：每次执行都发一条“我跑完了”，最后所有人都 mute。
2. 没有分离“流水”和“播报”：没有本地日志/结构化输出，导致你只能依赖群消息追溯历史。
3. 没有“去重/时窗”：同一新闻/同一异常反复发，信噪比下降。
4. 失败不可见：任务内部失败但依然发“成功”，或者干脆不回执。

# 关键转折：把通知当成“产品界面”，而不是“日志 dump”

好的告警不是“信息越多越好”，而是：

• 只在需要人介入时打扰
• 一眼能看懂：是什么问题、严重吗、要做什么
• 能回溯：原始流水在本地/文件里

这也是为什么案例 A 要“异常才通知”，案例 B 要“24h 首发时窗”。

# 可复用 SOP：异常优先的 cron 告警设计（5 步）

1. 任务输出先落盘（机器可读）

   • 例如脚本写 jsonl/markdown 摘要。
   • Unknown：如果你当前没有落盘机制，就先标 Unknown，并把“落盘”列为下一步改造。

2. 定义通知门控（Alert Gating）

   • 规则最少三类：
     • 异常触发（error/阈值超标）
     • 提醒窗口触发（例如每天固定时间一条健康汇总）
     • 静默（其余时间不发）
   • 证据：案例 A 已明确写出“仅异常或提醒窗口才发送”。

3. 定义去重与时窗

   • 新闻/情报类：用“24h 首发”或 hash 去重（证据见案例 B）。
   • 指标类：用“跨阈值变化”去重（例如从正常→异常、异常→恢复才通知）。

4. 通知内容结构化（面向人）

   • 标题：任务名 + 状态（ok/error）
   • 关键指标：2~5 个
   • 下一步：要不要人处理？处理什么？

5. 最终只发一次（汇总式）

   • 不在中间过程刷屏；中间细节留给本地日志。

# 课后作业

1. 选一个你团队最想做的 cron（网络、新闻、额度、备份都行），写出你的“通知门控规则”：
   • 异常阈值是什么？
   • 提醒窗口是什么？
   • 去重键是什么？
2. 设计一条“恢复通知”：当异常恢复时才发（从 error→ok）。
3. 用一句话写清楚这条 cron 的价值：如果所有人都 mute 了它，这条系统还有意义吗？如果没有，说明你还没把“异常优先”做到位。