Hermes Agent 定时任务：日报、周报、监控和提醒

从低风险任务开始

定时任务最适合先做信息整理，而不是直接做外部操作。日报、周报、RSS 摘要、竞品监控和会议提醒都属于低风险文本任务，失败了也容易回滚。

必备设计

每个定时工作流都应该有触发时间、输入来源、输出位置、失败重试、日志记录和人工确认策略。没有这些设计，自动化会从省时间变成制造麻烦。

频率不要太高

很多任务不需要每 5 分钟跑一次。竞品监控可以每天一次，Newsletter 摘要可以每周一次，日报可以固定在早上或下班前。频率越高，成本和噪音越高。

daily-briefing: 09:00
weekly-report: Friday 16:00
competitor-monitoring: 08:30

失败策略

定时任务一定会失败：模型限流、输入源为空、网络超时、Gateway 断开、Token 过期都可能发生。建议每个任务只重试有限次数，连续失败后通知维护者，并在输出里明确写出失败位置。

retry_count: 2
on_failure: notify maintainer
fallback: send last successful summary + error reason

输入为空怎么办

很多自动化不是坏在模型，而是输入为空。日报没有 Issue、RSS 没有新内容、任务系统接口返回空数组时，要输出“今天没有新增内容”，而不是让模型编一段看起来合理的总结。

衡量效果

记录节省时间、失败次数、人工修改比例和每月 API 成本。真实数据比“感觉好用”更能指导优化。连续两周都没人看、没人点击、没人反馈的定时任务，就应该降低频率或暂停。

hermes cron：内置调度器的全部子命令

触发时间和失败策略想清楚之后，落地不需要先碰系统配置，内置的 `hermes cron` 覆盖任务的完整生命周期：

hermes cron create   # 新建，用自然语言描述任务
hermes cron list     # 列出全部定时任务
hermes cron status   # 看调度器本身是否在跑
hermes cron run      # 让指定任务在下个 tick 立即执行
hermes cron pause    # 暂停某个任务
hermes cron resume   # 恢复
hermes cron edit     # 修改描述或时间
hermes cron remove   # 删除

`create` 接受自然语言，一句"每个工作日早上九点把未读邮件整理成摘要发到 Slack"就是完整的任务定义，不用先学时间表达式。把"做什么"和"什么时候做"写进同一句话，正是它和系统 crontab 最大的差别——后者只管时间，命令还得自己拼。排查"到点没跑"时最该先看的是 `cron status`：多数时候不是任务写坏了，而是调度器压根没在运行。调试新任务时用 `cron run` 立刻触发一次，看产出对不对，再放回时间表等它自己跑。维护窗口或长假用 `pause` 停掉，回来 `resume`，不必删了重建。

已有 crontab 的服务器：用 cron tick 交出调度权

机器上本来就有一套 crontab 运维习惯时，可以不让 Hermes 长驻当调度器。`hermes cron tick` 把到期任务执行一遍就退出，调度权交给外部：

*/10 * * * * hermes cron tick

任务定义仍由 `hermes cron` 管理，何时检查到期由系统 crontab 决定，执行窗口之外不留任何常驻进程。两种模式的选择规则：自己的电脑或单机自用，让内置调度器跑着最省事；服务器上已经有 crontab 和配套监控，就用 tick 把 Hermes 纳入既有体系，调度入口统一在一处。产出要送进群里时接 `hermes send`，凭证直接复用 `~/.hermes/.env`，投递这一步不再经过 LLM：

hermes send --to discord:#ops --file /tmp/report.md --subject "磁盘巡检结果"

巡检、备份这类产出建议都带上 `--subject`，标题行能让群里翻历史时一眼分清是哪个任务发的。目标格式支持 `platform:chat_id`，要发进群组话题就在后面再补一段 thread_id。不确定可投递的目标有哪些，先用 `hermes send --list telegram` 列一遍再填。

还没有真实场景？可以先领取 [Free Starter 模板包](/free-template-pack)，从低风险只读任务开始试跑。