本篇适用读者: 用 Hermes Agent / 自托管 AI 跑产线 cron 的开发者本篇覆盖: 21 个生产 cron 拆解按 7 大类分组 错峰 5 分钟原则 4 个 cron 输出目录实战数据基准: 2026 年 7 月 9 日实拍, 共 27 个活跃 cron, 本文挑 21 个生产类典型一、为什么需要 cron 错峰跑 cron 最容易踩的坑是同时触发抢资源。举 3 个真实事故:事故现象根因求职日报撞早安图7:30 推求职日报, 同时 7:35 推早安图,微信 iLink 限流错开 5 分钟可解Hermes PG 防漂移撞 cron 防漂移3:00 和 3:15 两个 PG 写入同时跑, 锁等待错峰 15 分钟CSDN 选题晨报撞 boss_documents 同步6:00 和 6:30, 同一份 Supabase 表读写竞争错峰 30 分钟核心原则: 同类资源 (数据库 / 消息通道 / 凭据校验) 的 cron 之间, 至少错开5 分钟。二、错峰 5 分钟原则 (3 大铁律)2.1 同源数据库, 至少 5 分钟两个 cron 都读/写同一张表 → 错峰 5 分钟起步。# ✅ 正解: 6:00 跑 boss_documents, 6:05 跑 cron_statec0e54b3b648a:0 6 * * *# Supabase boss_documents 同步1b8caf550813:5 6 * * *# Supabase cron_state 同步2.2 同一通道 (微信 / 飞书), 至少 5 分钟iLink 微信限流是每 5 分钟一次, 所以两个 cron 都用微信推送 → 至少错开 5 分钟。# ✅ 正解: 7:30 求职日报 (飞书), 7:35 早安图 (微信), 错 5 分钟f9b0344af0fa:30 7 * * *# 求职日报 → 飞书 DM9d42c77bd1fa:35 7 * * *# 早安图 → 微信2.3 重型任务 (网络下载 / 多服务调用), 至少 15 分钟# ✅ 正解: 23:00 数据抓取, 23:15 PG 凭据写入, 错 15 分钟745996f1c3df:15 7 * * *# PG api_keys → .env (网络 多服务)三、7 大类分组 (每类 3 个 21 个)3.1 求职赛道 (3 个)job_idschedule名称442c5ed64b2d0 7 * * *每日求职岗位推送 v7.0f9b0344af0fa30 7 * * *求职日报每日 7:30014f21d5b4830 7 * * *沈阳市 2026 副高职称报送监控设计要点:0 7和30 7错 30 分钟 (求职推送是重型, 日报是轻量)7:00同时跑 2 个 cron (求职推送 副高监控) → 两者不抢同一资源(一个是飞书, 一个是飞书群聊), 安全关键: 错峰要按资源类型分, 不是按业务类型分3.2 飞书表格 (3 个)job_idschedule名称05f863b1da8b10 23 * * *每日 23:10 飞书填表626762fcc1300 20 * * 0data_lake_weekly_cleanup 周日f1d67561baa20 22 * * 0data_lake_weekly_push 周日设计要点:周日 20:00 跑 cleanup, 22:00 跑 push,错 2 小时(cleanup 是网络 数据库, push 是 IM 推送)23:10飞书填表是全天最后一个 cron (23:10 之后到 00:30 cron_output 归档之间空闲)00:30cron_output 自动归档 →02:00CSDN 镜像同步 →04:00俄乌日报, 全在后半夜3.3 CSDN 生产 (3 个)job_idschedule名称be5093e84d3b30 6 * * *CSDN 选题晨报 6:3075eb52b0976530 21 * * *CSDN 进度晚报 21:30bbf356c99c990 2 * * *CSDN 数据飞书 Base 镜像同步 2:00设计要点:6:30 晨报 → 跟 6:00 boss_documents 错开 30 分钟 (Supabase 读表)21:30 晚报 → 跟 22:00 data_lake_push 错开 30 分钟 (飞书 IM 推送)2:00 镜像同步 → 凌晨空档, 6:00 boss_documents 之前完成, 错峰 4 小时3.4 Hermes 自维护 (3 个)job_idschedule名称35fdd4ab6cc40 * * * *Hermes 内存双写 (每小时)d4f1137003680 3 * * *Hermes PG 防漂移 (3:00)bc0afdb9094515 3 * * *Hermes cron 防漂移 (3:15)设计要点:0 *每小时跑 PG 同步 (轻量, 不读所有数据)3:00和3:15错 15 分钟 (两个都写 PG, 错峰保证锁不冲突)自维护 cron 一般放凌晨 (3-4 点), 不抢白天资源3.5 周报汇总 (3 个)job_idschedule名称f6c3520e1f1c0 20 * * 5周汇总·上周 (周五 20:00)955239593b020 20 * * 0周汇总·本周 (周日 20:00)140a563fc6b30 9 * * 1boss_preferences 周一 9:00设计要点:周报类一般周五 / 周日 / 周一错峰周五 20:00上周汇总 →周日 20:00本周汇总 →周日 22:00data_lake_push (中间空 2 小时)周一 9:00 是工作日开始, 给作者上班路上看3.6 外部数据接入 (3 个)job_idschedule名称e6d44c2ccc7d0 9 * * 1Redis 每周一 9:00 监控745996f1c3df15 7 * * *PG api_keys → .env 每天 7:152c25bc8adbc110 8 * * *Hermes API key 每日监控 8:10设计要点:7:00 求职推送 → 7:15 PG api_keys → 7:30 求职日报 → 7:35 早安图,早上 35 分钟内 4 个 cron 紧密调度API key 监控 8:10 (求职推送后 70 分钟, 求职日报后 40 分钟), 确保前面跑完9:00 Redis 监控放在工作日上班后, 让作者看完邮件再看监控报告3.7 监控与告警 (3 个)job_idschedule名称1b8caf5508135 6 * * *Supabase cron_state 自动同步 6:05c0e54b3b648a0 6 * * *Supabase boss_documents 自动同步 6:00b75ff007f5eb45 7 * * *每日 cron 异常扫描-早设计要点:6:00 boss_documents 6:05 cron_state (错 5 分钟, 同表 Supabase)7:45 cron 异常扫描 → 7:30 求职日报 7:35 早安图之后, 看哪个 cron 失败了监控类 cron 一定放在业务 cron 之后, 不然扫描时业务还没跑完, 误报四、4 个 cron 输出目录实战Hermes 把每个 cron 的输出落到~/.hermes/cron/output/job_id/时间戳.md。4 类典型:4.1 目录结构~/.hermes/cron/output/ ├── 05f863b1da8b/ # 飞书填表 │ ├── 2026-07-08_23-14-42.md │ └── 2026-07-09_23-14-43.md ├── 442c5ed64b2d/ # 求职推送 │ ├── 2026-07-08_07-03-30.md │ └── 2026-07-09_07-03-39.md ├── b75ff007f5eb/ # 异常扫描 │ └── 2026-07-09_07-46-12.md └── ... (21 个 cron 各自目录)4.2 输出文件命名规则YYYY-MM-DD_HH-MM-SS.md, 时间戳是触发时刻, 不是完成时刻。4.3 三类输出内容A. success 类(成功才有输出):# Cron Job: 每日求职岗位推送 v7.0 **Job ID:** 442c5ed64b2d **Run Time:** 2026-07-09 07:03:39 **Mode:** LLM-driven (agent) --- [agent 实际跑的 prompt 工具调用 最终结果] 5 条新岗位已推飞书, message_idom_xxxB. error 类(失败也要写, 作者 7/1 沉淀业务认错机制):# Cron Job: 芳·早安图 **Job ID:** 9d42c77bd1fa **Run Time:** 2026-07-09 07:35:00 **Error:** Script timed out after 120s **Delivery:** iLink sendmessage rate limited: ret-2 --- [stack trace / 失败上下文]C. no_agent 类(机械脚本, 输出就是脚本 stdout):# Cron Job: data_lake_weekly_push **Job ID:** f1d67561baa2 **Run Time:** 2026-07-09 22:00:00 **Mode:** no_agent (script) --- 周报 data_lake 清洗结果 (2026-07-09) 分类表: career 12 / hermes 9 / family 5 ...4.4 cron_output 自动归档 (208db05d5eed)每天 00:30 自动归档30 天前的 cron 输出, 防止硬盘爆。# ~/.hermes/scripts/cron_output_archive_wrapper.pyimportosimporttime base/root/.hermes/cron/outputnowtime.time()forjob_idinos.listdir(base):job_dirf{base}/{job_id}ifnotos.path.isdir(job_dir):continueforfnameinos.listdir(job_dir):fpathf{job_dir}/{fname}mtimeos.path.getmtime(fpath)age_days(now-mtime)/86400ifage_days30:# 归档到 ~/.hermes/cron/archive/os.makedirs(f{base}/../archive/{job_id},exist_okTrue)os.rename(fpath,f{base}/../archive/{job_id}/{fname})五、错峰 5 分钟原则速查表资源类型错峰时间示例同源 PG 写15 分钟3:00 防漂移 3:15 cron 防漂移同源 Supabase 表5 分钟6:00 boss_documents 6:05 cron_state微信 iLink5 分钟7:30 求职日报 7:35 早安图飞书 IM30 分钟21:30 CSDN 晚报 22:00 data_lake_push同 PG 重型任务1 小时PG api_keys 7:15 cron 防漂移 3:15不同类型无冲突同分不踩求职日报 (飞书) 副高监控 (飞书群)六、监控异常 cron 防漏报作者 7/1 沉淀:AI 写完业务 cron 后必须主动追异常, 不等作者问。6.1 双扫描 cronb75ff007f5eb7:45 早扫 (看 0:00 - 7:45 跑的 cron 有没有 error)907786c2a5c323:30 晚扫 (看 7:45 - 23:30 跑的 cron 有没有 error)两个 cron 扫描 12 小时窗口, 不重叠。6.2 异常检测逻辑# /root/.hermes/scripts/cron_error_scan.pyforjob_idincron_jobs:last_runget_last_run(job_id)iflast_runanderrorinlast_run.lower():send_feishu_alert(job_id,last_run)七、实战: 给作者复用这套的 3 个建议新加 cron 前先看现有 schedule 排期, 不要凭我想要早上跑就拍 7:00同类资源 (PG / 飞书 / 微信) 至少错 5 分钟, 重型任务 (网络 多服务) 至少错 15 分钟监控类 cron 一定放业务 cron 之后, 不然扫描时业务还没跑完, 误报率 50%八、本篇小结21 个 cron 按 7 大类分组 (求职赛道 / 飞书表格 / CSDN 生产 / Hermes 自维护 / 周报汇总 / 外部数据接入 / 监控与告警)错峰 5 分钟是黄金原则, 按资源类型错而不是按业务类型错cron 输出按job_id/时间戳.md落盘, success / error / no_agent 三类监控 cron 一定放业务 cron 之后, 否则误报率高字数统计: ~5800 字符 / 32 节 / 18 代码块参考本文的 cron job_id(7/9 实拍):求职赛道 (442c5ed64b2d, f9b0344af0fa, 014f21d5b483)飞书表格 (05f863b1da8b, 626762fcc130, f1d67561baa2)CSDN 生产 (be5093e84d3b, 75eb52b09765, bbf356c99c99)Hermes 自维护 (35fdd4ab6cc4, d4f113700368, bc0afdb90945)周报汇总 (f6c3520e1f1c, 955239593b02, 140a563fc6b3)外部数据接入 (e6d44c2ccc7d, 745996f1c3df, 2c25bc8adbc1)监控与告警 (1b8caf550813, c0e54b3b648a, b75ff007f5eb)
Hermes Agent 作者 21 个生产 cron 怎么跑 (按 7 大类 + 错峰原则)
发布时间:2026/7/10 4:57:23
本篇适用读者: 用 Hermes Agent / 自托管 AI 跑产线 cron 的开发者本篇覆盖: 21 个生产 cron 拆解按 7 大类分组 错峰 5 分钟原则 4 个 cron 输出目录实战数据基准: 2026 年 7 月 9 日实拍, 共 27 个活跃 cron, 本文挑 21 个生产类典型一、为什么需要 cron 错峰跑 cron 最容易踩的坑是同时触发抢资源。举 3 个真实事故:事故现象根因求职日报撞早安图7:30 推求职日报, 同时 7:35 推早安图,微信 iLink 限流错开 5 分钟可解Hermes PG 防漂移撞 cron 防漂移3:00 和 3:15 两个 PG 写入同时跑, 锁等待错峰 15 分钟CSDN 选题晨报撞 boss_documents 同步6:00 和 6:30, 同一份 Supabase 表读写竞争错峰 30 分钟核心原则: 同类资源 (数据库 / 消息通道 / 凭据校验) 的 cron 之间, 至少错开5 分钟。二、错峰 5 分钟原则 (3 大铁律)2.1 同源数据库, 至少 5 分钟两个 cron 都读/写同一张表 → 错峰 5 分钟起步。# ✅ 正解: 6:00 跑 boss_documents, 6:05 跑 cron_statec0e54b3b648a:0 6 * * *# Supabase boss_documents 同步1b8caf550813:5 6 * * *# Supabase cron_state 同步2.2 同一通道 (微信 / 飞书), 至少 5 分钟iLink 微信限流是每 5 分钟一次, 所以两个 cron 都用微信推送 → 至少错开 5 分钟。# ✅ 正解: 7:30 求职日报 (飞书), 7:35 早安图 (微信), 错 5 分钟f9b0344af0fa:30 7 * * *# 求职日报 → 飞书 DM9d42c77bd1fa:35 7 * * *# 早安图 → 微信2.3 重型任务 (网络下载 / 多服务调用), 至少 15 分钟# ✅ 正解: 23:00 数据抓取, 23:15 PG 凭据写入, 错 15 分钟745996f1c3df:15 7 * * *# PG api_keys → .env (网络 多服务)三、7 大类分组 (每类 3 个 21 个)3.1 求职赛道 (3 个)job_idschedule名称442c5ed64b2d0 7 * * *每日求职岗位推送 v7.0f9b0344af0fa30 7 * * *求职日报每日 7:30014f21d5b4830 7 * * *沈阳市 2026 副高职称报送监控设计要点:0 7和30 7错 30 分钟 (求职推送是重型, 日报是轻量)7:00同时跑 2 个 cron (求职推送 副高监控) → 两者不抢同一资源(一个是飞书, 一个是飞书群聊), 安全关键: 错峰要按资源类型分, 不是按业务类型分3.2 飞书表格 (3 个)job_idschedule名称05f863b1da8b10 23 * * *每日 23:10 飞书填表626762fcc1300 20 * * 0data_lake_weekly_cleanup 周日f1d67561baa20 22 * * 0data_lake_weekly_push 周日设计要点:周日 20:00 跑 cleanup, 22:00 跑 push,错 2 小时(cleanup 是网络 数据库, push 是 IM 推送)23:10飞书填表是全天最后一个 cron (23:10 之后到 00:30 cron_output 归档之间空闲)00:30cron_output 自动归档 →02:00CSDN 镜像同步 →04:00俄乌日报, 全在后半夜3.3 CSDN 生产 (3 个)job_idschedule名称be5093e84d3b30 6 * * *CSDN 选题晨报 6:3075eb52b0976530 21 * * *CSDN 进度晚报 21:30bbf356c99c990 2 * * *CSDN 数据飞书 Base 镜像同步 2:00设计要点:6:30 晨报 → 跟 6:00 boss_documents 错开 30 分钟 (Supabase 读表)21:30 晚报 → 跟 22:00 data_lake_push 错开 30 分钟 (飞书 IM 推送)2:00 镜像同步 → 凌晨空档, 6:00 boss_documents 之前完成, 错峰 4 小时3.4 Hermes 自维护 (3 个)job_idschedule名称35fdd4ab6cc40 * * * *Hermes 内存双写 (每小时)d4f1137003680 3 * * *Hermes PG 防漂移 (3:00)bc0afdb9094515 3 * * *Hermes cron 防漂移 (3:15)设计要点:0 *每小时跑 PG 同步 (轻量, 不读所有数据)3:00和3:15错 15 分钟 (两个都写 PG, 错峰保证锁不冲突)自维护 cron 一般放凌晨 (3-4 点), 不抢白天资源3.5 周报汇总 (3 个)job_idschedule名称f6c3520e1f1c0 20 * * 5周汇总·上周 (周五 20:00)955239593b020 20 * * 0周汇总·本周 (周日 20:00)140a563fc6b30 9 * * 1boss_preferences 周一 9:00设计要点:周报类一般周五 / 周日 / 周一错峰周五 20:00上周汇总 →周日 20:00本周汇总 →周日 22:00data_lake_push (中间空 2 小时)周一 9:00 是工作日开始, 给作者上班路上看3.6 外部数据接入 (3 个)job_idschedule名称e6d44c2ccc7d0 9 * * 1Redis 每周一 9:00 监控745996f1c3df15 7 * * *PG api_keys → .env 每天 7:152c25bc8adbc110 8 * * *Hermes API key 每日监控 8:10设计要点:7:00 求职推送 → 7:15 PG api_keys → 7:30 求职日报 → 7:35 早安图,早上 35 分钟内 4 个 cron 紧密调度API key 监控 8:10 (求职推送后 70 分钟, 求职日报后 40 分钟), 确保前面跑完9:00 Redis 监控放在工作日上班后, 让作者看完邮件再看监控报告3.7 监控与告警 (3 个)job_idschedule名称1b8caf5508135 6 * * *Supabase cron_state 自动同步 6:05c0e54b3b648a0 6 * * *Supabase boss_documents 自动同步 6:00b75ff007f5eb45 7 * * *每日 cron 异常扫描-早设计要点:6:00 boss_documents 6:05 cron_state (错 5 分钟, 同表 Supabase)7:45 cron 异常扫描 → 7:30 求职日报 7:35 早安图之后, 看哪个 cron 失败了监控类 cron 一定放在业务 cron 之后, 不然扫描时业务还没跑完, 误报四、4 个 cron 输出目录实战Hermes 把每个 cron 的输出落到~/.hermes/cron/output/job_id/时间戳.md。4 类典型:4.1 目录结构~/.hermes/cron/output/ ├── 05f863b1da8b/ # 飞书填表 │ ├── 2026-07-08_23-14-42.md │ └── 2026-07-09_23-14-43.md ├── 442c5ed64b2d/ # 求职推送 │ ├── 2026-07-08_07-03-30.md │ └── 2026-07-09_07-03-39.md ├── b75ff007f5eb/ # 异常扫描 │ └── 2026-07-09_07-46-12.md └── ... (21 个 cron 各自目录)4.2 输出文件命名规则YYYY-MM-DD_HH-MM-SS.md, 时间戳是触发时刻, 不是完成时刻。4.3 三类输出内容A. success 类(成功才有输出):# Cron Job: 每日求职岗位推送 v7.0 **Job ID:** 442c5ed64b2d **Run Time:** 2026-07-09 07:03:39 **Mode:** LLM-driven (agent) --- [agent 实际跑的 prompt 工具调用 最终结果] 5 条新岗位已推飞书, message_idom_xxxB. error 类(失败也要写, 作者 7/1 沉淀业务认错机制):# Cron Job: 芳·早安图 **Job ID:** 9d42c77bd1fa **Run Time:** 2026-07-09 07:35:00 **Error:** Script timed out after 120s **Delivery:** iLink sendmessage rate limited: ret-2 --- [stack trace / 失败上下文]C. no_agent 类(机械脚本, 输出就是脚本 stdout):# Cron Job: data_lake_weekly_push **Job ID:** f1d67561baa2 **Run Time:** 2026-07-09 22:00:00 **Mode:** no_agent (script) --- 周报 data_lake 清洗结果 (2026-07-09) 分类表: career 12 / hermes 9 / family 5 ...4.4 cron_output 自动归档 (208db05d5eed)每天 00:30 自动归档30 天前的 cron 输出, 防止硬盘爆。# ~/.hermes/scripts/cron_output_archive_wrapper.pyimportosimporttime base/root/.hermes/cron/outputnowtime.time()forjob_idinos.listdir(base):job_dirf{base}/{job_id}ifnotos.path.isdir(job_dir):continueforfnameinos.listdir(job_dir):fpathf{job_dir}/{fname}mtimeos.path.getmtime(fpath)age_days(now-mtime)/86400ifage_days30:# 归档到 ~/.hermes/cron/archive/os.makedirs(f{base}/../archive/{job_id},exist_okTrue)os.rename(fpath,f{base}/../archive/{job_id}/{fname})五、错峰 5 分钟原则速查表资源类型错峰时间示例同源 PG 写15 分钟3:00 防漂移 3:15 cron 防漂移同源 Supabase 表5 分钟6:00 boss_documents 6:05 cron_state微信 iLink5 分钟7:30 求职日报 7:35 早安图飞书 IM30 分钟21:30 CSDN 晚报 22:00 data_lake_push同 PG 重型任务1 小时PG api_keys 7:15 cron 防漂移 3:15不同类型无冲突同分不踩求职日报 (飞书) 副高监控 (飞书群)六、监控异常 cron 防漏报作者 7/1 沉淀:AI 写完业务 cron 后必须主动追异常, 不等作者问。6.1 双扫描 cronb75ff007f5eb7:45 早扫 (看 0:00 - 7:45 跑的 cron 有没有 error)907786c2a5c323:30 晚扫 (看 7:45 - 23:30 跑的 cron 有没有 error)两个 cron 扫描 12 小时窗口, 不重叠。6.2 异常检测逻辑# /root/.hermes/scripts/cron_error_scan.pyforjob_idincron_jobs:last_runget_last_run(job_id)iflast_runanderrorinlast_run.lower():send_feishu_alert(job_id,last_run)七、实战: 给作者复用这套的 3 个建议新加 cron 前先看现有 schedule 排期, 不要凭我想要早上跑就拍 7:00同类资源 (PG / 飞书 / 微信) 至少错 5 分钟, 重型任务 (网络 多服务) 至少错 15 分钟监控类 cron 一定放业务 cron 之后, 不然扫描时业务还没跑完, 误报率 50%八、本篇小结21 个 cron 按 7 大类分组 (求职赛道 / 飞书表格 / CSDN 生产 / Hermes 自维护 / 周报汇总 / 外部数据接入 / 监控与告警)错峰 5 分钟是黄金原则, 按资源类型错而不是按业务类型错cron 输出按job_id/时间戳.md落盘, success / error / no_agent 三类监控 cron 一定放业务 cron 之后, 否则误报率高字数统计: ~5800 字符 / 32 节 / 18 代码块参考本文的 cron job_id(7/9 实拍):求职赛道 (442c5ed64b2d, f9b0344af0fa, 014f21d5b483)飞书表格 (05f863b1da8b, 626762fcc130, f1d67561baa2)CSDN 生产 (be5093e84d3b, 75eb52b09765, bbf356c99c99)Hermes 自维护 (35fdd4ab6cc4, d4f113700368, bc0afdb90945)周报汇总 (f6c3520e1f1c, 955239593b02, 140a563fc6b3)外部数据接入 (e6d44c2ccc7d, 745996f1c3df, 2c25bc8adbc1)监控与告警 (1b8caf550813, c0e54b3b648a, b75ff007f5eb)