用自然语言写定时任务：Hermes Agent Cron 调度系统

传统 Cron 的痛点

系统管理员对 crontab 肯定不陌生。0 3 * * * 表示每天凌晨 3 点执行——熟练的人秒懂，不熟练的人每次都得查语法。

但 cron 的问题不只是语法反人类。更深层的问题是：传统 cron 只能执行固定的命令或脚本。如果你的定时任务需要判断（比如「如果磁盘使用率超过 80% 才告警」）、需要多步骤串联（比如「先备份数据库，然后检查备份文件大小是否合理，再上传到 S3」）、需要异常处理（比如「如果备份失败就重试三次，还不行就发通知」），你就得写脚本，而且脚本里的逻辑可能比正经业务代码还复杂。

Hermes Agent 内置的 cron 调度系统换了一种思路：用自然语言描述你想定时做的事情，让 Agent 的推理能力来处理执行过程中的各种情况。

基本用法

创建定时任务

一条命令搞定：

1	hermes cron add "每天早上 9 点检查服务器的磁盘使用率，如果超过 80% 就发 Telegram 通知"

Hermes Agent 会：

理解你的自然语言描述
解析出执行频率（每天早上 9 点 → 0 9 * * *）
把任务描述保存为一个 cron 技能
注册到内置的调度器中

你不需要写 cron 表达式，也不需要写 bash 脚本。

查看已有任务

1	hermes cron list

输出类似：

ID  | 频率           | 描述                                    | 上次执行 | 状态
1   | 每天 09:00     | 检查磁盘使用率，超80%告警               | 04-11    | 正常
2   | 每周一 10:00   | 汇总上周 Git 提交统计                   | 04-07    | 正常
3   | 每6小时         | 检查 SSL 证书到期时间                   | 04-12    | 正常

修改任务

1	hermes cron update 1 "改成每 6 小时检查一次，阈值改成 70%"

删除任务

1	hermes cron remove 1

手动触发

不想等到计划时间，马上执行一次看看效果：

1	hermes cron run 1

和传统 Cron 的区别

关键区别在于执行层面。传统 cron 执行的是一条固定命令，Hermes Agent cron 执行的是一个任务意图，由 Agent 在执行时实时推理具体操作。

这意味着：

自适应能力。你的任务描述是「检查 Nginx 状态」，Agent 在不同系统上会用不同的命令——Ubuntu 上用 systemctl status nginx，CentOS 6 上可能用 service nginx status。你不需要为不同环境写不同的脚本。

异常处理。命令执行失败时，Agent 不是简单地报个 exit code 1 就完事了。它会分析错误原因，尝试替代方案，如果真搞不定才通知你。

上下文感知。Agent 有记忆系统，它知道上次执行的结果是什么、你的偏好是什么。比如上次检查磁盘时发现了一个大文件，这次可能会主动看看那个文件还在不在。

结果投递。执行完的结果可以通过任何已配置的消息平台投递——Telegram、Discord、Slack，甚至邮件。传统 cron 要做到这个需要额外配置 sendmail 或写 webhook。

实际自动化场景

场景一：服务器巡检

1	hermes cron add "每天早上 8 点做一次服务器全面巡检：CPU、内存、磁盘、网络、进程，生成巡检报告发到 Telegram"

Agent 每天 8 点会自动：

执行 top、free、df、netstat 等命令
检查关键进程是否在运行
对比上一次巡检的数据，标注异常变化
把巡检报告格式化后发到你的 Telegram

如果发现异常（比如某个进程意外挂掉），报告里会特别标注，而不是把所有正常数据一股脑丢给你。

场景二：数据库备份

1	hermes cron add "每天凌晨 2 点备份 PostgreSQL 数据库，压缩后传到 /backup 目录，保留最近 7 天的备份，超过的自动删除"

这个任务如果写成 bash 脚本，大概要 30-40 行，还得处理各种边界情况（备份失败怎么办、磁盘满了怎么办、旧备份锁住了怎么办）。用 Hermes Agent cron，一句话就包含了所有意图，Agent 在执行时会自己处理这些情况。

而且你还可以追加要求：

1	hermes cron update 2 "备份完后验证备份文件完整性，如果备份文件小于上次的 50%，可能有问题，发告警"

场景三：SSL 证书监控

1	hermes cron add "每天检查所有域名的 SSL 证书有效期，如果有证书在 14 天内到期就发 Telegram 提醒"

Agent 会自动检测你配置的域名列表（从 Nginx 配置或者持久记忆中读取），逐一检查证书有效期。

场景四：日志分析

1	hermes cron add "每天下午 5 点分析今天的 Nginx 访问日志，统计 Top 10 IP、Top 10 URL、4xx/5xx 错误分布，生成简报发 Telegram"

这种需要多步数据处理的任务，传统 cron 要写一堆 awk/sed/sort 的管道命令。Hermes Agent 直接理解你想要什么，自己组织命令。

场景五：代码仓库维护

1	hermes cron add "每周一早上 9 点检查所有 Git 仓库的未合并分支，超过 30 天没更新的列出来发 Slack"

适合团队 lead 做代码仓库卫生检查。

结果投递配置

定时任务执行完，结果怎么通知你？

投递到消息平台

前提是你已经配好了对应平台（参考多平台接入教程）：

1	hermes cron add "每天 9 点巡检" --notify telegram

1	hermes cron add "每周汇总" --notify discord --channel 111222333

投递到文件

如果你只想存个记录：

1	hermes cron add "每天 9 点巡检" --output /var/log/hermes/daily-check.log

多目标投递

1	hermes cron add "数据库备份" --notify telegram,slack --output /var/log/hermes/backup.log

仅告警

大部分巡检任务在正常状态下不需要通知你，只在出问题时才通知：

1	hermes cron add "每小时检查服务状态" --notify-on-error telegram

这个太实用了——你不想每小时收到一条「一切正常」的消息，但你确实想知道什么时候出了问题。

调度器内部机制

Hermes Agent 的 cron 调度器是内置的，不依赖系统的 crontab。这意味着：

不需要 root 权限。普通用户就能创建和管理定时任务。

跨平台一致。在 Linux、macOS、WSL2 上的行为完全一样，不存在系统 cron 的兼容性问题。

与 Agent 记忆联动。调度器知道 Agent 的记忆和技能状态。如果某类任务已经有了技能文件，定时执行时会自动调用技能，效率更高。

执行追踪。每次定时任务的执行过程都有完整记录——什么时候开始、执行了哪些命令、结果是什么、有没有报错。方便事后审查。

调度精度是分钟级的，和系统 cron 一样。如果你需要秒级精度，这不是 Hermes Agent cron 适合的场景。

自然语言解析的准确性

你可能担心：自然语言描述频率，Agent 能准确理解吗？

实测下来，常见的中文表达解析都没问题：

你说的	Agent 理解为
每天早上 9 点	`0 9 * * *`
工作日下午 3 点	`0 15 * * 1-5`
每隔 6 小时	`0 /6 * *`
每周一和周四上午 10 点	`0 10 * * 1,4`
每月 1 号凌晨	`0 0 1 * *`
每 30 分钟	`/30 * * *`

如果你的表达比较模糊（比如「经常检查一下」），Agent 会追问你想要多频繁。

创建任务后，Agent 会回显它理解的频率让你确认：

1 2	你: 工作日午饭后检查一下邮箱 Hermes: 我理解为：每周一到周五 13:00 执行。是否正确？

这个确认步骤避免了误解。

任务依赖与编排

有些定时任务之间有依赖关系。比如：先备份数据库，备份成功后再清理临时文件。

Hermes Agent cron 支持简单的任务链：

1	hermes cron add "每天凌晨 2 点：先备份 PostgreSQL，备份成功后清理 /tmp 下超过 7 天的文件，最后发送执行报告到 Telegram"

注意这里用了「先……后……最后……」的自然语言描述来表达顺序和依赖。Agent 会按描述的顺序执行，如果前一步失败，后续步骤会根据语义判断是否继续。

对于更复杂的编排需求（比如并行执行多个任务后汇总结果），目前 Hermes Agent 的 cron 还不太擅长。这种场景更适合用子代理的方式来实现。

和系统 Cron 的共存

Hermes Agent 的内置调度器和系统 crontab 互不冲突。你完全可以两者并用：

简单的固定命令（比如日志轮转）继续用系统 cron
需要智能判断和灵活处理的任务用 Hermes Agent cron

不建议两边都配同样的任务——会重复执行。

资源占用

调度器本身几乎不占资源。它就是一个计时器，到点了才触发 Agent 执行。Agent 执行任务时的资源消耗取决于任务复杂度和选择的模型。

一个经验数据：每次定时任务执行，平均消耗 500-3000 tokens（取决于任务复杂度）。如果你用 OpenRouter 上的中端模型，大概每次几分钱到几毛钱。每天跑 10 个巡检任务，月成本可能就几十块。

实际使用建议

从简单任务开始。先配一个「每天检查磁盘空间」这样的简单任务，确认调度、执行、通知全链路跑通。
合理设置频率。不是越频繁越好。每分钟巡检一次服务器既浪费 token 又没必要。根据业务需要设合理的频率。
善用 –notify-on-error。正常状态不需要通知，异常状态才需要。这能大幅减少通知噪音。
定期查看执行日志。虽然 Agent 会自动处理异常，但你还是应该定期看看执行情况，确保没有持续失败的任务。
利用技能系统。如果某个定时任务执行得足够多次，Agent 会自动生成技能文件来优化执行效率。你也可以手动为高频定时任务编写技能文件。

cocoloop 社区有不少人分享了他们的 cron 配置方案。有人用 Hermes Agent cron 管了十几台服务器的日常巡检，每天早上打开 Telegram 就能看到所有服务器的状态简报。这种感觉确实不错。

目录