Hermes Agent 学习笔记 08：Cron 定时任务，让 Agent 从“被动回复”走向“主动执行”

1. 为什么需要 Cron？

前面几期中，我已经学习了 Hermes Agent 的多个核心能力。

CLI/TUI 让 Hermes 可以进入终端工作流；
Tools 让 Hermes 可以读取文件、执行命令、搜索网页；
Memory 让 Hermes 可以记住长期背景；
Skills 让 Hermes 可以沉淀可复用经验；
Messaging Gateway 让 Hermes 可以通过 Telegram、Discord、Slack、Email 等平台长期在线。

但是，这些能力大多数仍然有一个共同特点：它们需要用户先发起任务。

也就是说，用户问一句，Hermes 执行一次；用户不问，Hermes 就不会主动行动。

而真实工作中，有很多任务并不是临时触发的，而是周期性发生的。例如：

每天早上总结 AI Agent 领域新闻；
每周五汇总项目进展；
每小时检查服务器状态；
每天晚上备份某个目录；
每周检查 GitHub issue 和 PR；
每天定时生成学习计划；
定期扫描日志并提醒异常。

这些任务如果每次都靠用户手动输入，就很麻烦。更合理的方式是：用户只配置一次，Hermes 按计划自动执行。

这就是 Cron 定时任务的意义。

简单来说：

普通对话：用户触发 Agent。
Cron 定时任务：时间触发 Agent。

这也是 Hermes 从“被动响应式助手”走向“长期自动化助手”的关键一步。

2. Cron 在 Hermes Agent 中是什么？

Cron 原本是 Unix/Linux 系统中的定时任务机制。它可以按照固定时间规则执行命令，比如每天 9 点运行脚本、每小时检查服务状态、每周生成报告。

Hermes Agent 中的 Cron 借用了这个思想，但它不是简单地执行 shell 命令，而是可以定时触发一个 Agent 任务。

也就是说，Hermes Cron 可以做的不只是：

每天执行一个脚本

而是：

每天让 Agent 理解一个任务、调用工具、整理结果，并把报告发给用户。

这就比传统 cron 更进一步。

传统 cron 偏“执行命令”。
Hermes Cron 偏“执行智能任务”。

例如传统 cron 可以这样做：

0 9 * * * python check_server.py

而 Hermes Cron 可以这样做：

每天早上 9 点，检查服务器状态、总结异常日志，并把结果发到 Telegram。

这里面不仅有定时触发，还有日志理解、结果总结、消息投递和可能的工具调用。

3. Hermes Cron 能做什么？

Hermes Cron 支持的能力大致包括：

创建一次性任务；
创建周期性任务；
暂停任务；
恢复任务；
修改任务；
手动触发任务；
删除任务；
给任务绑定一个或多个 skills；
把结果投递到消息平台；
把结果保存到本地文件；
在指定项目目录中运行任务；
以 no-agent 模式运行纯脚本任务。

这说明 Hermes Cron 不是一个简单的“闹钟提醒”功能，而是一个完整的定时任务管理系统。

它既可以做简单提醒：

30 分钟后提醒我检查构建结果。

也可以做复杂自动化：

每天早上 8 点，搜索 AI Agent 和开源 LLM 的最新消息，筛选最重要的 3 条，用中文生成简报，并发送到 Telegram。

更重要的是，它可以结合前面学过的 Skills。也就是说，你可以先把某类任务的执行流程沉淀成 Skill，然后让 Cron 定时加载这个 Skill 执行任务。

这就形成了一个很自然的自动化链条：

Tools 负责执行动作；
Skills 负责提供流程；
Cron 负责定时触发；
Gateway 负责结果投递；
Memory 负责长期背景。

4. 创建 Cron 任务的三种方式

Hermes 创建 Cron 任务主要有三种方式：

自然语言创建；
/cron slash command 创建；
hermes cron CLI 创建。

4.1 用自然语言创建

最符合 Hermes 风格的方式，是直接用自然语言告诉它：

每天早上 9 点，搜索 AI Agent 领域最新新闻，总结 3 条最重要的信息，并发到 Telegram。

Hermes 会理解这个需求，并通过内部 cronjob 工具创建定时任务。

这种方式最适合普通用户，因为不用记命令，也不用写 cron 表达式。

不过，自然语言虽然方便，也更容易模糊。比如“每天早上”到底是几点？“最新新闻”是过去 24 小时还是过去一周？“发给我”是发到 Telegram、Email，还是当前 chat？

所以在创建重要任务时，最好写得具体一点：

每天早上 8:00，搜索过去 24 小时内 AI Agent 和开源 LLM 的重要新闻。筛选 3 条最值得关注的内容，用中文总结，每条包含标题、来源、两句话摘要，并发送到 Telegram home channel。

这样 Hermes 更容易创建一个稳定可执行的任务。

4.2 用 /cron 创建

在 Hermes 对话界面中，可以使用 /cron 命令：

/cron add "0 8 * * *" "搜索过去 24 小时 AI Agent 和开源 LLM 的重要新闻，筛选 3 条，用中文生成简报，并发送到 Telegram。"

这里的 "0 8 * * *" 是标准 cron 表达式，意思是每天早上 8 点执行。

也可以使用更自然的时间表达：

/cron add "every 2h" "检查服务器状态，如果发现异常则总结并提醒我。"

或者：

/cron add 30m "提醒我检查构建结果。"

/cron 的好处是比纯自然语言更可控。你明确告诉 Hermes 时间规则和任务内容，减少理解偏差。

4.3 用 CLI 创建

也可以直接在终端中创建：

hermes cron create "every 2h" "Check server status"

或者：

hermes cron create "0 8 * * *" "Search AI Agent news and summarize the top 3 stories"

如果任务需要绑定 skill，可以写：

hermes cron create "every 1d at 09:00" "Summarize today's AI news" --skill ai-news-briefing

如果想给任务命名：

hermes cron create "0 8 * * *" "Generate morning AI briefing" --name "Morning AI Briefing"

CLI 方式适合更工程化的场景，比如你在服务器上部署 Hermes，希望通过命令管理任务。

5. 时间表达方式：相对时间、间隔、Cron 表达式和 ISO 时间

Hermes Cron 支持多种时间格式。

5.1 相对时间

相对时间通常表示“一次性任务”。

例如：

30m
2h
1d

分别表示：

30 分钟后执行一次；
2 小时后执行一次；
1 天后执行一次。

例如：

/cron add 30m "提醒我检查模型训练是否结束。"

这类任务执行一次后就结束。

5.2 间隔时间

间隔时间表示周期性执行。

例如：

every 30m
every 2h
every 1d

表示：

每 30 分钟执行一次；
每 2 小时执行一次；
每天执行一次。

例如：

/cron add "every 2h" "检查服务器磁盘空间，如果超过 80% 就提醒我。"

5.3 标准 Cron 表达式

标准 cron 表达式通常是五个字段：

分钟 小时 日期 月份 星期

例如：

0 9 * * *

表示每天 9:00 执行。

0 9 * * 1

表示每周一 9:00 执行。

*/30 * * * *

表示每 30 分钟执行一次。

这种格式更精确，适合稳定任务。

5.4 ISO 时间戳

如果想在某个精确时间执行一次，可以使用 ISO 时间戳：

2026-06-20T09:00:00

这表示在指定日期和时间执行一次。

不过，使用具体时间时要特别注意时区。如果机器时区和用户理解的时区不同，任务就可能在错误时间执行。

6. Cron 任务的黄金规则：Prompt 必须自包含

Hermes Cron 有一个非常重要的规则：

Cron 任务会在新的 Agent 会话中运行，所以任务 prompt 必须自包含。

这是什么意思？

普通对话中，你可以先说很多背景，然后再说：

以后每天按这个格式做。

但 Cron 任务真正执行时，不一定能看到你之前完整的聊天过程。它更像是新开了一个 Agent 会话，只拿到这个定时任务的 prompt，然后开始执行。

所以，Cron prompt 不能写得太省略。

错误写法：

每天早上做我的常规简报。

这个 prompt 太模糊。什么是“常规简报”？搜索什么范围？输出什么格式？发到哪里？是否需要链接？语言是什么？

更好的写法：

每天早上 8 点，搜索过去 24 小时内 AI Agent、开源 LLM 和大模型工具生态的相关新闻。筛选 3 条最重要的信息，用中文输出。每条包含：标题、来源、2 句话摘要、为什么值得关注。最后给出一句总体趋势判断。把结果发送到 Telegram home channel。

这就是自包含 prompt。

也就是说，一个好的 Cron prompt 应该包含：

任务目标；
数据来源；
时间范围；
筛选标准；
输出格式；
语言风格；
投递位置；
异常情况处理方式。

Cron 任务越重要，prompt 越不能偷懒。

7. Cron 和 Skills 的结合

第六期讲过，Skills 是 Hermes 沉淀任务经验的方式。Cron 和 Skills 结合后，就可以定时执行一套固定工作流。

例如，你有一个 skill 叫：

ai-news-briefing

这个 skill 已经规定了如何搜索新闻、如何筛选来源、如何组织简报、如何避免标题党内容。

那么创建 Cron 任务时就可以绑定它：

hermes cron create "0 8 * * *" "生成今日 AI Agent 新闻简报" --skill ai-news-briefing

也可以绑定多个 skills：

hermes cron create "0 9 * * *" "生成本地技术活动和 AI 新闻综合简报" \
  --skill ai-news-briefing \
  --skill local-events

多个 skills 会按顺序加载。顺序很重要，因为后面的 skill 可能依赖前面的上下文。

Cron + Skills 的意义在于：

不要把所有流程都写进每个 cron prompt；
把可复用流程沉淀成 skill；
定时任务只负责说明本次目标。

这样可以让定时任务更简洁，也更稳定。

8. Cron 的投递方式：结果发到哪里？

Cron 任务执行完后，需要把结果送到某个地方。

常见投递方式包括：

origin：发回创建任务的聊天窗口；
local：只保存到本地文件；
telegram：发送到 Telegram home channel；
discord：发送到 Discord；
slack：发送到 Slack；
email：发送到邮箱；
具体平台 chat_id：发送到指定聊天。

如果你是在 Telegram 中创建任务，那么默认可能希望结果发回当前聊天窗口。
如果你是在 CLI 中创建任务，那么结果通常会保存到本地文件。
如果你想让每天的简报发到 Telegram，需要设置 Telegram home channel 或明确指定 delivery target。

例如：

每天早上 8 点生成 AI 新闻简报，并发送到 Telegram。

或者：

hermes cron create "0 8 * * *" "Generate AI news briefing" --deliver telegram

如果只是本地记录，可以使用 local：

hermes cron create "0 23 * * *" "Summarize today's work log" --deliver local

本地输出通常会保存到 Hermes 的 cron output 目录中。

这一点非常重要：
Cron 不只是“执行任务”，还必须明确“结果送到哪里”。

一个没有投递位置的 Cron 任务，即使执行成功，用户也可能感觉“它没有发生过”。

9. Gateway 为什么和 Cron 关系很大？

第七期讲过 Messaging Gateway。这里要强调：Hermes Cron 的自动触发通常依赖 Gateway 的长期运行。

原因很简单：定时任务需要一个长期在线的调度器。如果没有后台进程检查哪些任务到时间了，任务就不会自动执行。

在 Hermes 中，Gateway 会在后台周期性 tick，检查是否有到期任务。如果有，就启动一个新的 Agent session 执行任务，并在完成后投递结果。

所以，如果你发现 Cron 任务没有按时执行，第一件事不是怀疑 prompt，而是检查 Gateway 是否正在运行。

常用命令包括：

hermes gateway

前台运行 Gateway。

或者：

hermes gateway start

启动已安装的 Gateway 服务。

查看状态：

hermes gateway status

也可以手动触发一次 cron tick：

hermes cron tick

这适合调试时使用。

可以这样理解：

Cron 负责定义什么时候做什么；
Gateway 负责长期运行并按时触发它。

如果 Gateway 没有运行，Cron 就像写在纸上的计划，不会自动发生。

10. Cron 任务如何执行？

从内部流程看，一个 Cron 任务执行大致分成几步：

1. Gateway 的后台调度器定期检查任务列表；
2. 从本地 jobs 文件中读取所有任务；
3. 判断哪些任务已经到达 next_run_at；
4. 为到期任务启动新的 Agent session；
5. 如果任务绑定了 skills，先注入对应 skills；
6. 执行任务 prompt；
7. 等待 Agent 完成并生成最终结果；
8. 将结果投递到指定位置；
9. 更新任务运行元数据和下一次执行时间。

这里有几个值得注意的点。

第一，Cron 任务不是复用当前聊天窗口执行，而是新建 session。
所以 prompt 必须自包含。

第二，绑定 skills 会在任务执行前加载。
所以 skill 必须已经安装，并且适合非交互式运行。

第三，投递是调度器负责的，不是任务自己随便发消息。
这可以避免 cron 任务直接调用消息工具造成混乱。

第四，调度器需要避免重复执行同一批任务。
所以 Hermes 会使用锁机制，防止多个 tick 同时运行导致同一个任务被重复触发。

这说明 Hermes Cron 不是简单把一句话扔给模型，而是有完整的任务调度、执行、投递和状态更新流程。

11. 在项目目录中运行 Cron

有些定时任务需要在具体项目目录中运行。

例如：

每天早上检查某个 GitHub 项目的测试状态；
每晚汇总某个代码仓库的 commit；
每周生成项目文档更新报告；
定期检查某个实验目录下的新结果。

这种任务如果不指定工作目录，Hermes 可能不知道应该在哪个项目下执行命令。

所以创建任务时可以指定 workdir：

hermes cron create "0 9 * * *" \
  "检查项目的测试状态，并总结失败原因" \
  --workdir /home/user/projects/demo

这表示任务运行时会在指定目录中执行文件和终端工具。

这里要注意，workdir 非常关键。如果目录错了，Agent 可能读不到正确文件，甚至在错误项目里执行命令。

所以涉及项目自动化时，最好在 prompt 中也再次写清楚：

请在 /home/user/projects/demo 项目中运行，只读取该项目内文件，不要修改任何文件。

这样可以降低误操作风险。

12. Script + Agent：让脚本负责采集，Agent 负责判断

Cron 任务中有一种很实用的模式：先运行脚本，再让 Agent 根据脚本输出进行分析。

例如，监控网站变化时，脚本可以负责：

访问网页；
计算 hash；
和上一次结果比较；
输出变化摘要。

Agent 负责：

判断变化是否重要；
用自然语言解释；
决定是否提醒用户；
生成最终消息。

这种分工很合理。

因为脚本擅长机械、确定、重复的事情；
Agent 擅长理解、总结、判断、表达。

例如：

每小时运行一次网站监控脚本，如果网页内容发生变化，请判断是否是重要更新，并用中文提醒我。

这种模式比让 Agent 每次从头浏览网页、自己比较变化更稳定。

可以总结为：

脚本负责“采集和计算”；
Agent 负责“理解和表达”。

这也是 Hermes Cron 很适合做自动化的原因。

13. No-Agent 模式：有时不需要大模型

并不是所有定时任务都需要 LLM。

例如：

磁盘空间超过 90% 就提醒；
服务器宕机就提醒；
内存占用过高就提醒；
某个文件不存在就报警；
某个接口返回非 200 就通知。

这类任务其实脚本本身就能给出明确结果，不需要模型总结。

如果每次都调用大模型，不仅浪费 token，也可能增加不必要的不确定性。

Hermes Cron 支持 no-agent 模式，也就是只运行脚本，不启动 Agent。脚本的 stdout 会直接作为结果投递；如果没有输出，就可以保持安静。

这适合做 watchdog 类任务。

例如，一个磁盘检查脚本只在异常时输出：

Disk usage is above 90% on /dev/sda1

如果一切正常，它什么都不输出。这样用户只会在有问题时收到提醒。

这类模式非常实用，因为长期自动化不是每次都需要大模型。
能用脚本准确判断的，就不要强行让模型参与。

14. [SILENT]：没有变化时不要打扰用户

定时任务有一个常见问题：如果每天、每小时、每 10 分钟都发消息，用户很快会被打扰。

很多监控任务其实只需要在有变化或有异常时提醒。

Hermes Cron 支持一种静默机制。你可以在 prompt 中要求：

如果没有变化，只回复 [SILENT]。

这样，当任务结果没有必要通知用户时，就可以不投递消息。

例如：

每小时检查一次项目 issue。如果没有新增 issue，只回复 [SILENT]；如果有新增 issue，请列出标题、链接和优先级判断。

这种设计很重要。

一个好的自动化 Agent 不应该“为了证明自己在工作”而不断发消息。
它应该只在用户需要知道的时候提醒。

所以对于监控类 Cron，我建议都加上类似规则：

没有异常时保持静默；
只有出现变化、失败、风险或需要用户决策时才提醒。

15. Context From：让多个 Cron 任务串联

有些自动化任务可以拆成多个阶段。

例如：

任务 A：每天早上抓取 AI 新闻；
任务 B：每天早上抓取 GitHub 项目更新；
任务 C：综合 A 和 B 的结果生成日报。

如果所有事情都塞进一个任务里，prompt 会很长，任务也更容易失败。更好的方式是拆成多个 Cron job，然后让后续任务读取前面任务的输出。

Hermes 支持 context_from 这类机制，让一个 cron job 消费其他任务最近一次成功输出。

这很适合构建流水线：

数据采集任务；
信息过滤任务；
综合摘要任务；
投递任务。

这样就能把复杂自动化拆成多个小任务，每个任务职责更清楚。

这其实和软件工程中的 pipeline 思想很像：

不要写一个巨大的全能任务；
把大任务拆成多个可测试、可复用的小任务。

16. Cron 的常见使用场景

结合 Hermes 的能力，我认为 Cron 适合以下几类任务。

16.1 每日简报

例如：

每天早上 8 点，搜索 AI Agent、开源 LLM、大模型工具生态的最新消息，筛选 3 条，用中文生成简报，发到 Telegram。

这类任务非常适合 Hermes，因为它需要搜索、筛选、总结和投递。

16.2 项目状态汇总

例如：

每天下午 6 点，检查当前项目的 git 状态、最近 commit、open issue 和测试结果，生成项目日报。

这种任务适合结合 workdir、GitHub 工具和 Terminal 工具。

16.3 服务器巡检

例如：

每 2 小时检查服务器 CPU、内存、磁盘和关键服务状态。如果发现异常，用中文解释可能原因并提醒我。

这种任务可以用脚本采集数据，再让 Agent 解释异常。

16.4 学习计划推进

例如：

每天晚上 10 点，总结我今天的 Hermes Agent 学习进度，并给出明天的学习建议。

这种任务适合结合 Memory 和本地笔记。

16.5 论文或技术资料跟踪

例如：

每天搜索 arXiv、GitHub Trending 和相关技术博客，找出 AI Agent 工具调用、Memory、MCP 相关的新资料，生成摘要。

这种任务适合研究生或技术博客作者。

16.6 日志异常检测

例如：

每小时检查一次应用日志。如果发现异常堆栈、错误率升高或安全相关告警，生成简短报告。

这种任务适合安全、运维和后端开发场景。

17. Cron 的风险：自动化越强，越要控制边界

Cron 的风险比普通对话更高。

普通对话通常是用户即时触发，用户还在旁边看着。
Cron 是无人值守执行，用户不一定在场。

这意味着，如果任务写得不好，Hermes 可能会在错误时间、错误目录、错误权限下执行操作。

常见风险包括：

任务 prompt 太模糊；
工作目录设置错误；
投递目标设置错误；
任务重复执行；
多个任务同时触发；
脚本输出太大；
调用工具失败；
模型理解错误；
技能未安装或不适合无交互运行；
没有变化也频繁打扰用户；
高风险命令无人确认。

所以，Cron 任务设计时要更谨慎。

尤其是涉及：

删除文件；
修改代码；
提交 Git；
发送邮件；
调用付费 API；
访问生产环境；
操作数据库；
运行部署命令；

这类任务不建议一开始就完全自动化。

更安全的方式是：

先只读检查；
先生成报告；
先要求人工确认；
先在测试环境运行；
再逐步开放执行权限。

18. 设计 Cron Prompt 的模板

一个比较稳妥的 Hermes Cron prompt 可以使用下面这个模板：

任务目标：
……

执行范围：
……

时间范围：
……

具体步骤：
1. ……
2. ……
3. ……

输出格式：
……

投递要求：
……

安全限制：
1. 不要删除、修改或创建文件，除非明确要求；
2. 不要执行高风险命令；
3. 如果信息不足，输出需要人工确认的事项；
4. 如果没有异常或变化，只回复 [SILENT]。

例如：

任务目标：
每天检查 demo 项目的测试状态，并生成简短报告。

执行范围：
只在 /home/user/projects/demo 目录中执行。

具体步骤：
1. 查看 git status；
2. 判断项目测试命令；
3. 运行只读测试命令；
4. 如果测试失败，提取失败用例和错误原因；
5. 如果测试通过，只输出简短成功摘要。

输出格式：
项目状态、测试结果、失败原因、建议动作。

安全限制：
不要修改、删除或创建任何文件；不要安装依赖；不要执行部署命令。

这种 prompt 比一句“每天检查项目”稳定得多。

19. Cron 排错思路

如果 Cron 任务没有按预期执行，可以按下面顺序排查。

19.1 检查任务是否存在并启用

hermes cron list

确认任务状态是 active，而不是 paused、completed 或 failed。

19.2 检查时间规则

确认 schedule 是否符合预期。

例如：

0 9 * * *    每天 9 点
0 9 * * 1    每周一 9 点
every 2h     从当前时间开始每 2 小时
30m          30 分钟后执行一次

如果你想要周期任务，但写成了 30m，它只会执行一次。

19.3 检查 Gateway 是否运行

hermes gateway status

如果 Gateway 没有运行，Cron 不会自动触发。

19.4 手动触发任务

hermes cron run <job_id>

或者手动 tick：

hermes cron tick

这样可以验证任务本身是否能运行。

19.5 检查投递目标

如果任务运行了但没有收到消息，可能是 delivery 配置错误。

例如 Telegram token、Slack 权限、Email SMTP、home channel 都可能出问题。

19.6 检查日志

常见日志位置包括：

~/.hermes/logs/agent.log
~/.hermes/logs/errors.log

如果是服务运行，还可以查看 systemd 或 launchd 日志。

19.7 检查 skill 是否安装

如果任务绑定了 skill，要确认：

hermes skills list

并确认 skill 名称大小写和目录名一致。

20. 对 Hermes Cron 的理解

学完 Cron 后，我对 Hermes Agent 的整体架构有了更完整的认识。

前面几期可以这样串起来：

CLI/TUI：让用户在终端中直接操作 Hermes；
Tools：让 Hermes 能读取环境、执行命令和调用外部能力；
Memory：让 Hermes 能跨会话保留长期背景；
Skills：让 Hermes 能沉淀可复用流程；
Messaging Gateway：让 Hermes 能长期在线并跨平台交互；
Cron：让 Hermes 能在指定时间主动执行任务。

Cron 是 Hermes 从“交互式 Agent”走向“自动化 Agent”的关键模块。

没有 Cron，Hermes 再强也需要用户主动发起任务。
有了 Cron，Hermes 就可以按照计划持续工作。

但是，Cron 也要求用户更认真地设计任务边界。因为它是无人值守执行，prompt 必须自包含，权限必须控制，投递必须明确，失败必须可排查。

所以，我认为 Hermes Cron 的正确使用方式不是一开始就追求“全自动”，而是逐步推进：

先做提醒；
再做只读报告；
再做监控提醒；
再做脚本 + Agent 分析；
最后才考虑自动执行高风险动作。

21. 小结

这一期主要学习了 Hermes Agent 的 Cron 定时任务系统。

我的理解是，Cron 让 Hermes 从“被动回复用户消息”变成了“按计划主动执行任务”的长期自动化 Agent。它可以创建一次性或周期性任务，可以绑定 skills，可以指定工作目录，可以把结果投递到 Telegram、Slack、Discord、Email 或本地文件，也可以通过 no-agent 模式运行纯脚本任务。

但 Cron 的核心难点不在命令，而在任务设计。一个好的 Cron 任务必须有清晰目标、完整 prompt、明确时间范围、可靠投递位置和严格安全边界。尤其因为 Cron 任务运行在 fresh agent session 中，所以 prompt 不能依赖之前聊天里的隐含上下文。

下一期，我将继续学习 Hermes Agent 的 MCP 集成，看看 Hermes 如何通过 Model Context Protocol 接入外部工具服务器，从而把自己的工具能力扩展到 GitHub、数据库、浏览器、企业系统等更大的生态中。