Hermes Cron Job 示例：日报、监控、内容复盘和 no-agent Watchdog

Hermes 应用 进阶 进阶 预计 15 分钟 发布于 2026/6/1 核验于 2026/6/3

Hermes cron 最容易被误用成“能定时就定时”。真正有价值的 cron job，应该能回答三个问题：为什么要周期性触发，输出发给谁，失败后怎么停。

官方文档这轮把 cron 能力讲得更清楚了：现在统一通过 cronjob 工具管理，既支持一次性任务和周期任务，也支持 pause、resume、edit、run 和 remove；任务结果可以回到 origin chat、保存到本地文件，或投递到已配置的平台目标。对应用层用户来说，这意味着你不必把 cron 只理解成“命令行定时器”，而应该把它当成一个长期运行的任务总线。

下面这些示例不追求炫技，而追求可落地。

先用官方能力划分任务形态

在挑第一个 cron job 前，先按官方能力拆分：

如果任务只需要脚本 stdout，就别强行上 LLM；如果任务需要归纳、分类、解释，再让 Agent 参与。

示例 1：每周内容缺口复盘

适合内容站、文档站、工具导航站。

任务目标：每周统计哪些教程太短、哪些搜索意图缺页、哪些官方资料需要重新核验。

输出方式：发到个人消息入口或本地摘要文件。

风险等级：低。它只读内容，不自动发布。

这个任务适合 AgentClaw 这类站点。cron 负责触发，Hermes 负责总结，人工决定下一批写什么。它能把“我该更新什么”变成稳定节奏。

更稳的写法是把 delivery 先设成 origin 或 local。这样结果会回到创建任务的会话，或者落到本地输出目录，便于你先观察两三轮，再决定要不要接 Telegram、Discord 或 Slack。

示例 2：每日构建健康检查

适合个人项目和小团队项目。

任务目标：定时运行 build 或 smoke，失败时生成摘要。

输出方式：失败时投递到 Telegram、Slack 或本地通知。

风险等级：中。它可以读项目、运行命令，但不应该自动改代码。

如果只是检查命令是否成功，可以先用 no-agent watchdog；如果失败后需要解释日志，再让 Hermes 参与总结。

官方文档明确提到 no-agent 模式会把脚本输出原样投递，不走模型。这个模式的价值是克制：平时静默，异常时再把 stdout / stderr 摘要送出来。

示例 3：依赖更新提醒

适合长期维护的开源或内容项目。

任务目标：定期查看依赖、框架、官方文档或 API 变化。

输出方式：生成“需要关注 / 可以忽略 / 需要人工确认”三类列表。

风险等级：低到中。建议只提醒，不自动升级。

这类任务的价值是减少遗忘，而不是替你做决定。它尤其适合官方资料还在快速迭代的产品线，因为 cron 可以提醒你“该看一眼”，但不替你自动改正文。

示例 4：每周 memory 清理提醒

适合长期使用 Hermes 的用户。

任务目标：提醒用户检查 MEMORY.md 和 USER.md 是否有重复、过期或敏感内容。

输出方式：本地提醒或个人消息。

风险等级：低。不要让 cron 自动删除 memory，先生成建议。

memory 清理很像整理项目约定。你不做，它就慢慢变乱；自动做，又容易误删。

如果你只想提醒而不是输出长文，可以让任务返回短摘要；如果想完全不打扰，只落地文件，也可以让任务把结果写到本地输出目录，等人工批量处理。

示例 5：skill-backed 周报

适合已经有稳定 skill 的工作流。

任务目标：定期调用一个经过审查的 skill，生成固定格式周报。

输出方式：投递到指定消息入口或保存到固定目录。

风险等级：中。关键在于 skill 已经审查过。

不要让 cron 调用临时脚本。cron 会把一次动作变成长期动作，长期动作必须先通过安全审查。

这也是为什么示例 5 必须先有 skill，再有 schedule。先审查动作，再放大调用频率，顺序不要反。

示例 6：no-agent Watchdog

适合服务心跳、端口检查、磁盘空间、简单 API ping。

任务目标：只在异常时提醒。

输出方式：失败时输出 stdout / stderr 摘要。

风险等级：取决于脚本。只读检查通常较低。

no-agent 的好处是克制：不需要模型的时候不调用模型，成功时可以安静，异常时再找你。

如果你只是想把现有脚本接入 Hermes 交付链路，这个模式比“为了定时而重写成 prompt”更实际。

交付方式要先定，不然后期会混乱

Hermes cron 的 delivery 不是小细节，而是治理边界。你至少要先选一种：

官方文档还提到：即使不投递到外部目标，输出也会保存在本地，适合审计和复盘。对于团队项目，这比“只看聊天窗口”稳得多。

两个容易踩的边界

1. cron 不是递归自动化生成器

官方文档专门限制了 cron 运行时的 cron 管理能力，目的就是避免任务自己再创建、修改一堆任务，最后没人知道调度面发生了什么。

所以你要把 cron 理解成“执行层”，不是“无限繁殖自动化的母任务”。

2. 静默输出不是失败

如果任务结果被标记为静默，外部不会收到消息，但本地仍可能有审计输出。遇到“没收到提醒”时，不要马上判断为任务没跑，先看任务是否本来就是静默设计。

上线前写清 5 件事

每个 cron job 上线前，至少写清：

1. 触发频率。
2. 运行 profile。
3. workdir。
4. delivery 目标。
5. 停用方式。

如果一个任务没有停用方式，它就不该上线。长期运行的自动化，必须能优雅停止。

再补一项很实用的字段：owner。谁创建、谁验收、谁停用，要写清楚，不然两周后你只会看到一个“还在跑但没人认领”的后台任务。

完成检查

• 你已经选出一个低风险 cron 示例。
• 你知道它是否需要 LLM。
• 你已经决定结果先发回 origin、local 还是平台目标。
• 你写清了输出发到哪里。
• 你没有让第一批 cron 自动修改生产资源。
• 你知道失败后如何暂停或删除任务。