适用读者: 用 Hermes Agent / Claude Code / 任何 AI 助手搭生产级 cron 自动化的独立开发者关键词: Hermes Agent / cron / 任务调度 / 错峰 / 监控 / Supabase / 飞书 / 微信公众号一、为什么 27 个 cron 是 Hermes Agent 产线作者用 Hermes Agent 搭个人 AI 助手 1 个月, 沉淀27 个活跃 cron(实测, 不是估算). 拆开看是 7 大类, 错峰排期, 全自动化.为什么不是 5 个不是 50 个?少了 ( 10): 关键业务没保护, 异常没人扫, 失败没人接管多了 ( 50): 维护成本爆炸, cron 互相打架 (e.g. 两个 cron 同时改同一张表)27 个 7 大业务块 × 平均 4 个监控/补位 cron 平衡点.下面把 27 个 cron 按 7 大类拆解, 每个 cron 都含: job_id / 节奏 / 干什么 / 业务定位.二、27 个 cron 总览表 (按 schedule 排)#job_id节奏 (cron 表达式)业务定位类别106a185a3111d0 4 * * *每日新闻拉取业务流2208db05d5eed30 0 * * *30 天历史归档自维护3d4f1137003680 3 * * *PG 内存防漂移错峰防漂4bc0afdb9094515 3 * * *cron 元数据防漂移错峰防漂5c0e54b3b648a0 6 * * *Supabase 主表同步Supabase 同步61b8caf5508135 6 * * *Supabase cron 状态同步Supabase 同步7be5093e84d3b30 6 * * *CSDN 选题晨报CSDN 流水线8442c5ed64b2d0 7 * * *求职岗位推送 (v7.0)业务流9014f21d5b4830 7 * * *职称报送监控业务流10745996f1c3df15 7 * * *PG 凭据同步 .env凭据监控11f9b0344af0fa30 7 * * *求职日报推送业务流129d42c77bd1fa35 7 * * *微信公众号早安图业务流13b75ff007f5eb45 7 * * *cron 异常扫描-早错峰防漂142c25bc8adbc130 8 * * *API key 监控凭据监控15acc33460189e0 8 * * *错题本 → PG 记忆凭据监控16e6d44c2ccc7d0 9 * * 1Redis 周一监控凭据监控17140a563fc6b30 9 * * 1boss_preferences 周报错峰防漂1835fdd4ab6cc40 * * * *Hermes 内存双写自维护1905f863b1da8b10 23 * * *每日飞书填表业务流20907786c2a5c330 23 * * *cron 异常扫描-晚错峰防漂21f6c3520e1f1c0 20 * * 5周汇总·上周错峰防漂22626762fcc1300 20 * * 0data_lake 周清错峰防漂23955239593b020 20 * * 0周汇总·本周错峰防漂24f1d67561baa20 22 * * 0data_lake 飞书周报错峰防漂2575eb52b0976530 21 * * *CSDN 进度晚报CSDN 流水线(注: 另有 2 个冷备 cron 暂未在表, 略.)三、7 大类业务定位3.1 类别 1: 错峰防漂 (8 个)每天/每周固定时间扫系统状态, 漂移告警. 这是 Hermes Agent “自维护” 的核心.错峰原则 (作者实战, 永久生效):5min 缓冲: 任何依赖型 cron (e.g. A 写完表 → B 读表), 间隔 ≥ 5 min整点 5min 偏移: 把同一时段的 cron 错开0/5/15/30/45/55, 不堆0 7 * * *跨服务错峰: 本地 cron 远程 API (飞书 / 微信 / Supabase) 错开, 防 IP/API 限流# 8 个错峰防漂 cron 的 schedule 分布 (作者实测 7/8)00:30 cron_output_archive(30天归档)03:00 hermes_pg_sync_skills(PG 内存漂移)03:15 hermes_pg_sync_cron(cron 元数据漂移)06:00 sync_boss_documents(Supabase boss_documents)06:05 sync_cron_state(Supabase cron_state)07:45 cron_error_scan(异常扫描-早)20:00 weekly_summary_*(周五/日周汇总)22:00 weekly_data_lake_push(周日飞书周报)23:30 cron_error_scan(异常扫描-晚)3.2 类别 2: 凭据监控 (3 个)10 个第三方服务 (Apify / Upstash / WaveSpeed / Cloudinary / Notion / GitHub / AMAP / Redis / 飞书 / 微信) 的 key 健康度.# 三件套07:15 pg_keys_to_env# PG hermes_meta.api_keys → .env (本地)08:30 cron_run_apikey_test# 10 服务 key 实测 (推送/邮件/...)00:08 sync_mistakes_to_memory# Supabase hermes_mistakes → PG memory_entries关键设计: 凭据监控 cron 永远用 no-agent 模式 (0 token), 失败 → exit code ! 0 → 飞书告警.3.3 类别 3: CSDN 流水线 (4 个)CSDN 每日 2 篇节奏的 4 件支撑.06:30 csdn_queue_morning_push# 拉 Top 5 planned, 推飞书21:30 csdn_queue_evening_push# 全状态分布 推荐 Top 322:00 weekly_data_lake_push# 飞书 data_lake 周报XX:35 csdn_rss_sync# 作者自己 RSS 入库 (待建, 7/8 作者拍板)6 选项设计(csdn-blog-orchestrator skill, 永久生效):作者写文前必问 6 个选项 (系列/篇幅/代码/配图/实名/link)作者沉默 不动AI 自查改稿 (作者改 1 处 AI 必自查全篇同类)3.4 类别 4: Supabase 同步 (2 个)每天凌晨 6:00 跑 2 个 Supabase 表同步, 5min 错峰.06:00 sync_boss_documents_wrapper# 89 条云盘 2 手动登记 → Supabase06:05 sync_cron_state_wrapper# 27 个 cron 元数据 → Supabase cron_state架构设计 (作者 6/29 拍板): Supabase read-only MCP 模式, 写入走 SQLAlchemy. 3 重持久化: Supabase PG (本地) 飞书 docx.3.5 类别 5: 业务流推送 (5 个)每日业务推送, 错峰 5min 排, 不堆整点.04:00 ru_ua_daily# 国际新闻每日 4:0007:00 job_push_v7# 求职岗位推送 7:0007:00 title_monitor# 职称报送监控 7:0007:30 daily_report# 求职日报 7:3007:35 morning_pic# 微信公众号早安图 7:353 个错峰理由:求职 副高 都在 7:00 整点, 是因为两条业务独立 错峰用不同通道 (一飞书一 iLink)早安图 7:35 跟 7:30 求职日报 错峰 5min, 防止 iLink 限流3.6 类别 6: 自维护 (2 个)Hermes Agent 自身状态维护.00:30 cron_output_archive# 30 天 cron output 自动归档00:00 hermes_pg_sync_memory# 每小時一次 PG 内存双写自维护设计原则:不依赖外部服务 (本地 cron)失败 3 次重试, 第 4 次触发人工告警每周日凌晨 3:00 跑全量一致性校验3.7 类别 7: 错峰监控 (2 个)每天 7:45 早 23:30 晚两次扫描 cron 异常.07:45 cron_error_scan_wrapper# 扫描当日所有 cron statuserror23:30 cron_error_scan_wrapper# 扫描昨日 23:00-23:00 所有 cron12h 窗口设计 (作者 7/7 拍板): 早 7:45 扫昨夜 23:30-今早 7:45, 晚 23:30 扫今早 7:45-23:30. 不漏报.四、错峰 5min 实战 (作者踩 3 次坑总结)作者在 7/7 之前踩过 3 次坑, 都是两个 cron 同时跑导致:4.1 坑 1: 凭据监控 飞书推送同 7:15 跑 → iLink 限流# ❌ 错:07* * * job_push_v7# 7:00 整157* * * pg_keys_to_env# 7:15 整# 后果: 7:15 求职日报 iLink 凭据 cron 撞, iLink 429 限流正解: 错峰 5min# ✅ 对:07* * * job_push_v7157* * * pg_keys_to_env307* * * daily_report357* * * morning_pic457* * * cron_error_scan4.2 坑 2: data_lake 跟 weekly_summary 同 20:00 → Supabase MCP 锁# ❌ 错:020* *0data_lake_cleanup020* *0weekly_summary_this# 后果: Supabase MCP 锁表 30s正解: 错峰 2h# ✅ 对 (作者 7/1 拍板):020* *0data_lake_cleanup020* *5weekly_summary_last# 5 (周五)020* *0weekly_summary_this# 0 (周日)022* *0weekly_data_lake_push# 22:00 飞书推送, 跟 20:00 错开 2h4.3 坑 3: cron 异常扫描 cron 自身启动同分钟 → 误报# ❌ 错:0* * * * hermes_pg_sync_memory0* * * * cron_error_scan# 后果: 整点时 cron_error_scan 看到 hermes_pg_sync_memory 还在跑, 报漂移正解: 错峰 30s (作者 7/7 拍板)# ✅ 对:0* * * * hermes_pg_sync_memory# 整点1* * * * cron_error_scan# 整点过 1 分钟五、no-agent 模式 vs LLM 模式 (作者选型)Hermes Agent cron 任务分 2 种执行模式:5.1 no-agent 模式 (17 个, 0 token)# 标志: script no_agentTruehermescroncreate--name...--schedule0 7 * * *\--scriptwrapper.py --no-agent--deliverlocal适用: 跑批/同步/扫描/告警/数据清理. 输出是固定格式 (markdown / JSON), 0 token 消耗.作者 no-agent 17 个:凭据监控 3 个 (pg_keys_to_env / cron_run_apikey_test / sync_mistakes)错峰防漂 5 个 (weekly_summary_* / data_lake_*/ boss_preferences)错峰监控 2 个 (cron_error_scan 早/晚)自维护 2 个 (cron_output_archive / sync_boss_documents)业务流 5 个 (ru_ua / job_push / title_monitor / morning_pic / daily_report)5.2 LLM 驱动模式 (10 个, 每次执行消耗 token)# 标志: prompt skills no_agentFalse (默认)hermescroncreate--name...--schedule0 7 * * *\--prompt...--skillsskill1,skill2--deliverorigin适用: 需推理的任务 (e.g. 求职日报生成自然语言摘要, 早安图文案生成).作者 LLM 10 个:求职 1 个 (job_push_v7, 多步推理 apify 抓 飞书填)求职日报 1 个 (daily_report)飞书填表 1 个 (5f86 23:10)飞书周报 1 个 (data_lake_weekly_push)CSDN 2 个 (morning_push / evening_push)职称监控 1 个早安图 1 个飞书周报 2 个 (boss_preferences / weekly_summary)5.3 选型决策树任务类型模式理由跑批/同步/扫描no-agent固定输出, 0 token告警/数据清理no-agent固定输出, 失败即告警自然语言生成LLM需推理 写摘要多步数据处理 (抓→存→推)LLM需调用多个工具用户特定通知LLM需个性化文案实战比例 (作者 7/8 实测): 17 no-agent : 10 LLM 63% : 37%.no-agent 比例越高 越省钱.六、3 个 LLM cron 模板 (作者实战)下面是 3 个 LLM 驱动的 cron, 作者可参考复用.6.1 求职日报 (daily_report)hermescroncreate\--name求职日报\--schedule30 7 * * *\--prompt查询 Apify 拉取今日新增 5 个岗位 (json 格式), 写一段 200 字总结, 推飞书作者私聊. 失败 → 飞书告警.\--skillsapify-skill-factory,lark-cli\--deliverorigin6.2 早安图推送 (morning_pic)hermescroncreate\--name早安图推送\--schedule35 7 * * *\--prompt拉今日天气 节日 励志语, 用 Cloudinary nano-banana-pro 出 16:9 早安图, 推微信. 失败 → 飞书告警.\--skillscloudinary,feishu\--deliverweixin6.3 CSDN 晨报 (csdn_queue_morning_push)hermescroncreate\--nameCSDN 选题晨报\--schedule30 6 * * *\--prompt查 csdn_planning_queue 中 planned Top 5, 写 200 字当日推荐, 推飞书. 失败 → 飞书告警.\--skillslark-cli,supabase\--deliverlocal(完整 cron 模板见 csdn-blog-orchestrator skill 6.10 节)七、cron 命名 4 原则 (作者 7/8 拍板)cron 名字 ≠ job_id, 是给人在 dashboard 看的标签. 命名原则:业务 节奏: “求职日报 7:30” / “周汇总·上周 五 20:00” / “data_lake 周清 周日 20:00”类别前缀: “CSDN 选题晨报” / “Supabase 同步” / “Hermes PG 防漂移”公开化 (v6.2 铁律): 不要用真名/真公司/真金额. 任何作者/“作者”/家庭成员名 都不在 cron 名里出现错峰标识: 同一分钟跑多个 cron 时, 名字末尾加 -早 / -晚 / -a / -b作者 27 个 cron 命名实战 (v6.2 改写后):求职日报 (原已删真名)早安图推送 (原已删真名)职称监控 (原已删地名, 改通用名)(完整 v6.2 改写规则见 boss_preferences pref_csdn_no_personal_info)八、cron 失败告警 3 步法 (作者 7/1 拍板)cron 失败是常态, 关键是怎么让作者立刻知道.8.1 第 1 步: 业务 cron 失败 → 飞书# cron output exit code ! 0 → 飞书告警importsubprocess rsubprocess.run([python3,real_work.py],capture_outputTrue,textTrue,timeout120)ifr.returncode!0:subprocess.run([/root/.hermes/node/bin/lark-cli,im,messages-send,--chat-id,OWNER_OPEN_ID,--text,f[{JOB_NAME}] 失败\nstderr:{r.stderr[:500]}])8.2 第 2 步: 早 7:45 晚 23:30 cron 异常扫描hermescroncreate--name每日cron异常扫描-早\--schedule45 7 * * *--scriptcron_error_scan_wrapper.py\--no-agent--deliverlocal扫描逻辑: 查 hermes 输出目录~/.hermes/cron/output/job_id/时间戳.md, 找 last_statuserror 的 job_id 列表, 推飞书.8.3 第 3 步: 周一 9:00 boss_preferences 周报每周一全量同步 boss_preferences 表 → 飞书推作者, 包含 cron 漂移周对比.九、cron 漂移自愈 3 层架构 (作者 7/1 拍板)cron 漂移 cron 元数据 / 凭据 / 业务数据在 3 个存储层不一致. 自愈 3 层架构:L1: hermes-meta (本地 PG) -- 7/1 拍板 source of truth ↓ hermes_pg_sync_memory 每小時 L2: Supabase (云) -- 7/1 拍板云端 mirror ↓ weekly_data_lake_cleanup 周日 L3: data_lake_archived (PG L3a) -- 7/1 拍板冷库 (90 天) ↓ weekly_data_lake_push L3: Supabase data_lake_synced -- 7/1 拍板云端 metadata实测 (作者 7/8):漂移 0 次 (7/1-7/8 之间)任何层不一致 → 5min 内自动恢复 (cron 跑批触发)每周日 22:00 飞书周报推作者十、错峰 5min 决策表 (作者 7/8 拍板)同分钟 cron 数错峰策略理由1 个任意 schedule不冲突2 个错峰 5min一前一后, 防止网络/IP 限流3-5 个错峰 5min 整点偏移避免 iLink / API 限流6 个拆成不同小时 5min 偏移大批量必须分散作者 7/8 27 个 cron 实战分布:7:00-7:35 5 个 (求职 职称 凭据 日报 早安图) — 都是 5min 错峰20:00 周五/周日 3 个 — 拆 3 个 cron03:00 / 03:15 / 06:00 / 06:05 4 个 — 都是 5min 错峰十一、写在最后27 个 cron 不是越多越好, 也不是越少越好. 作者用 1 个月调出来这个数, 关键是:7 大类业务全覆盖错峰 5min 不打架no-agent 模式 63% 占比, 0 token 跑批漂移自愈 3 层架构失败告警 12h 窗口下一篇: 作者会讲 “Hermes Agent cron 防漂移 自愈: 3 层数据生命周期” (queue qid4), 敬请期待.附录 A: 27 个 cron 一键查询脚本#!/usr/bin/env bash# list_crons.shhermescronlist21|\grep-E^\s[a-f0-9]{12}\s\[active\]|\awk{print $1}|sort/tmp/active_crons.txtecho活跃 cron 数:$(wc-l/tmp/active_crons.txt)cat/tmp/active_crons.txt附录 B: 错峰 5min 排期表 (复制可用)# 全天错峰 5min 排期 (作者 7/8 实跑) 04:00 ru_ua_daily 06:00 sync_boss_documents 06:05 sync_cron_state 06:30 csdn_queue_morning_push 07:00 job_push_v7 07:00 title_monitor 07:15 pg_keys_to_env 07:30 daily_report 07:35 morning_pic 07:45 cron_error_scan 08:00 sync_mistakes_to_memory 08:30 cron_run_apikey_test 09:00 redis_usage_monitor (周一) 09:00 boss_preferences_weekly_sync (周一) 00:30 cron_output_archive 03:00 hermes_pg_sync_skills 03:15 hermes_pg_sync_cron 20:00 weekly_summary_last (周五) 20:00 data_lake_weekly_cleanup (周日) 20:00 weekly_summary_this (周日) 22:00 weekly_data_lake_push (周日) 23:10 daily_lark_table_fill 23:30 cron_error_scan 00:00 hermes_pg_sync_memory (每小時) 21:30 csdn_queue_evening_push附录 C: 参考资源Hermes Agent 官方文档: https://hermes-agent.nousresearch.com/docscron-sop skill (作者沉淀的 SOP): /root/.hermes/skills/cron-sop/csdn-blog-orchestrator skill (6 选项 SOP): /root/.hermes/skills/csdn-blog-orchestrator/类似讨论: https://github.com/nousresearch/hermes-agent/issues