有个同事跟我说，他每天早上的第一件事，是打开几个网站，看看有没有新动态，整理一下发到群里。每天都这样，雷打不动。
我问他：这件事你想做，还是你不得不做？
他说，不得不做。因为没人做就没人看到。
这种工作——固定频率、步骤明确、结果有格式要求——正好是 AI 最擅长接管的那类。Hermes 的 Cron 定时任务功能，就是专门干这件事的：你描述一次，它自动跑，结果发到你指定的地方，人不用在场。
01 | 三种方式创建，哪种都行
Cron 任务的创建方式很灵活，不需要记命令，对话里说一句就够：
三种创建方式：对话、/cron 命令、CLI — 效果完全一样
最省事的是直接在对话框里说，Hermes 自己理解并建好任务：
| 每天早上 9 点，抓 Hacker News 的 AI 相关新闻，整理成摘要发到 Telegram |
也可以用 /cron 命令，格式更精确，支持标准 Cron 表达式：
| /cron add "0 9 * * *" "抓取 HN AI 新闻并汇总" --skill blogwatcher # 或者用自然语言时间 /cron add "every 2h" "检查服务器状态并发送报告" |
任务建好之后，用 hermes cron list 查看状态，可以随时暂停、继续、修改，不需要删掉重建：
| hermes cron pause <job_id> # 暂停 hermes cron resume <job_id> # 继续 hermes cron edit <job_id> --schedule "every 4h" # 改频率 hermes cron edit <job_id> --skill blogwatcher # 换技能 hermes cron run <job_id> # 立即触发一次 |
02 | 时间格式：自然语言和 Cron 表达式都支持
四种时间格式：一次性延迟 / 循环间隔 / Cron 表达式 / 精确时间
时间格式不需要死记，四类场景对应四种写法：
| 场景 | 写法 | 含义 |
|---|---|---|
| 跑一次 | 30m / 2h / 1d | N 分钟/小时/天后跑一次 |
| 固定间隔 | every 2h / every 1d | 每隔多久循环执行 |
| 精确时间 | 0 9 * * * | 标准 Cron 表达式，每天 9:00 |
| 工作日 | 0 9 * * 1-5 | 周一到周五 9:00 |
| 指定日期 | 2026-06-01T09:00 | 某一天某一时刻，跑一次 |
| 自然语言 | every sunday 9am | 每周日早上 9 点 |
任务结果发到哪里，也可以精确指定：telegram（发到 Telegram 主频道）、telegram:-100xxx:17585（发到特定群话题）、feishu、weixin……或者直接all，广播到所有接入的平台。
03 | 真正强大的地方：任务流水线
单个任务能做的事有限。Cron 真正强大的地方，是多个任务可以串成流水线——前一个任务的输出，自动变成下一个任务的输入。
三个 Job 通过 context_from 串联：采集 → 筛选 → 推送，每步自动衔接
比如一套每天自动追踪 AI 新闻的流水线，三个任务，半小时内全自动完成：
| # Job 1 — 07:00 采集 "抓取 Hacker News Top10 AI 相关内容，存到 ~/data/raw.md" schedule: "0 7 * * *" # Job 2 — 07:30 筛选（自动拿到 Job1 的输出） "读取 raw.md，给每条打分 1-10，取 Top5 存到 ~/data/ranked.md" schedule: "30 7 * * *" context_from: job1_id # Job 3 — 08:00 推送（自动拿到 Job2 的输出） "读取 ranked.md，写 3 条推文草稿（含标签），发到 Telegram" schedule: "0 8 * * *" context_from: job2_id |
context_from 就是把这条链穿起来的那根线——每个任务不需要知道前一个任务的细节，只需要声明自己依赖谁，Hermes 在运行时自动把对应输出塞进来。
04 | 监控任务：没问题就安静，有问题才说话
除了内容生成类任务，Cron 还有一类很实用的场景：服务器监控。
设计思路和普通定时任务不一样——监控任务的理想状态是大多数时候什么都不说，只有出问题才报警。Hermes 为此提供了两个机制：
[SILENT] 静默模式：如果一切正常，让 AI 回复以 [SILENT] 开头，这条消息就不会推送出去，但仍然保存在本地日志里。
| # 提示词这样写： 检查 nginx 是否在运行（systemctl status nginx）， 以及 https://example.com 是否返回 HTTP 200。 如果一切正常，只回复 [SILENT]。 否则，描述具体问题。 # 调度： schedule: "*/10 * * * *" # 每 10 分钟检查一次 |
no-agent 脚本模式：对于不需要 AI 推理的简单检查（内存用量、磁盘空间），可以直接跑脚本，完全跳过 LLM，零 token 消耗：
| # 告诉 Hermes： "每 5 分钟检查内存，超过 85% 就推送到 Telegram" # Hermes 会自动写脚本并建任务，等同于： hermes cron create "every 5m" \ --no-agent \ --script memory-watchdog.sh \ --deliver telegram \ --name "内存监控" |
no-agent 模式下：脚本有输出 → 发出去；脚本无输出 → 静默；脚本报错 → 发错误告警（防止监控本身挂掉却无人知道）。
05 | 几个省心的细节
提示词要写完整。Cron 任务每次都在全新的会话里跑，不记得上下文。提示词要自包含——不能写「检查一下之前说的那个服务器」，要写「SSH 到 192.168.x.x，用 deploy 账号，检查 nginx 状态」。
指定工作目录。如果任务需要操作某个项目，加上 --workdir /path/to/project，Hermes 会自动加载那个目录下的 AGENTS.md、CLAUDE.md，就像在项目里交互式运行一样。
任务不会套娃。Cron 运行时会禁掉创建新 Cron 任务的能力，防止任务自己给自己排更多任务，不用担心失控。
Gateway 要跑着。定时任务由 Gateway 守护进程驱动，每 60 秒检查一次是否有到期任务。用 hermes gateway install 装成系统服务，开机自启，不用手动维护。
06 | 说在最后
Cron 对我最大的改变，不是某个具体任务跑起来了，而是对「哪些工作可以不用我在场」有了新的判断标准。
固定频率、步骤明确、结果有格式要求——符合这三条的工作，基本都可以试试交给定时任务。早报整理是这样，服务监控是这样，定期汇报也是这样。
你现在有哪些工作是每天重复做、但并不享受做的？评论区聊聊，也许下一篇可以用具体案例讲怎么配。