Hermes Agent Cron定时任务链测评：预运行门控与零成本触发

想象一下这个场景：你正在睡觉，或者忙着跟客户扯皮，而你的AI助手却在悄无声息地替你完成一系列任务。它会每天定时采集情报，根据条件判断是否需要处理，然后自动执行一个多阶段流水线，最后把结果精准无误地投递到你指定的任何平台——可能是你的私人Telegram频道，也可能是团队的Discord群。

这听起来很酷吧？这几个典型场景就是Hermes Agent里的定时任务（Cron）子系统能做的好事：自动把每日AI新闻简报推送到Telegram、在SSL证书到期前14天发出零成本的告警、或者在竞品仓库有新动态时自动生成一份分析报告。

接下来，我就把这套Hermes Cron子系统的核心机制和实战配方，完完整整地拆解给你看。如果你还没部署Hermes Agent，建议先去翻翻基础指南，把环境搭好。

基础配置：从零创建第一个定时任务

三种创建方式

Hermes贴心地提供了三种创建定时任务的方法，但最终都指向同一个核心工具：cronjob。选择哪种，全看你的习惯和场景。

方式一：聊天里甩一条斜杠命令

如果你习惯在聊天界面操作，这是最快的方式，直接跟Hermes发号施令就行。比如，想设置一个30分钟后提醒自己检查构建的临时任务：/cron add 30m "Remind me to check the build"。想每隔2小时检查服务器状态，或者每小时汇总一次新订阅，也都是一句话的事。

方式二：在终端里敲CLI命令

对于习惯命令行的老手，这是最直接、最可控的方式。功能上跟斜杠命令完全一样，但能让你在脚本里更方便地集成。比如：hermes cron create "every 2h" "Check server status"。

方式三：自然语言对话

这可能是最人性化的方式。你根本不需要记住任何特定语法，只要像个正常人一样告诉Hermes你的需求就行。例如，直接说：“每天早上9点，帮我检查Hacker News上关于AI的新闻，然后把摘要发到我Telegram上。”它就会自动把这句话解析成一个定时任务。

这三种方式效果完全等价，因为Hermes内部都交由统一的cronjob工具来执行。所以，哪种顺手用哪种。

调度格式

定时间隔的玩法非常灵活，从简单的“多少秒后”到复杂的“每个工作日早上9点”都能支持。我们用一个表格来快速理解：

对于默认会永远循环执行的间隔和Cron表达式，你可以通过 repeat=N 参数，来限制它精确执行N次。

投递目标

定时任务跑完了，结果往哪送？这是通过--deliver参数指定的。支持的平台多达15个以上，从你日常用的聊天软件到智能家居中枢，基本全覆盖了。

生命周期管理

创建了任务，自然还得管起来。Hermes提供了一套完整的命令，让你能像管理后台进程一样，对定时任务进行全生命周期管理。

这里有个贴心的设计：所有操作都支持按任务名称查找（大小写不敏感），再也不用为了管理一个任务而去死记硬背那串十六进制的ID了。

任务链：用 context_from 串联多阶段流水线

核心问题

Cron任务最让人头疼的一点是，每次运行都在一个完全隔离的新会话里，没有任何“记忆”。但在真实的自动化场景中，事情往往是前后关联的：你得先采集数据，然后过滤筛选，再格式化，最后才能发布。这每一个环节都需要知道上一个环节的结果。

传统的做法，要么在提示词里硬编码“去读某个文件”，要么用一个共享目录做中转。但Hermes的context_from参数，用一种更优雅的方式解决了这个问题：任务B在启动时，可以自动获取到任务A最近一次成功运行的输出，并将其作为自己的“上下文”前缀。

工作原理

流程非常清晰，就像一条流水线：任务A执行完毕后，它的输出会被保存下来。然后，当任务B被触发时，它会自动读取并加载任务A的最近一次输出，形成一张“小抄”，放在它的提示词前面。这样，任务B的Agent在执行时，就像是直接看到了上游传来的数据，完全不需要去手动指定文件路径。

经典三级流水线

举个例子，一个典型的“AI新闻采集与分析”流水线，就可以拆成三个任务，并通过context_from串联起来。

• 「AI News Collector」：每天7:00准时启动，负责去Hacker News上抓取最新的10条AI/ML新闻，输出一个编号列表（含标题、链接和一句话摘要）。
• 「AI News Triage」：在7:30启动，它会引用"AI News Collector"作为上下文。然后，对这10条新闻进行评分（互动潜力和新颖度，各1-10分），只保留两项都≥7的精品，最后输出一个带评分和理由的排名列表。
• 「AI News Brief」：8:00启动，引用"AI News Triage"的结果，为这些精选的新闻生成可以直接发布到社交媒体的推文草稿。如果没有新闻入围，就回复 [SILENT]，实现静默。

链接格式

在配置时，引用方式非常灵活：
- 单任务引用：context_from="AI News Collector"
- 多任务引用：context_from=["task-a", "task-b"]，当需要多个上游任务汇聚到一个下游时，它们的输出会按顺序拼接起来，这就是经典的扇入（fan-in）模式。

设计要点

• 任务链读取的是上游任务最近一次成功完成的输出，而不是等待同一时间周期内正在运行的上游。
• 支持按名称或ID引用，使用起来非常方便。
• 链条长度没有硬性限制，但根据经验，建议保持在3-5级以内，太长的链条反倒难以管理。
• 如果上游任务从未执行过（没有输出），下游任务依然会正常运行，只是没有额外的上下文而已。

预运行门控：用 wakeAgent 实现零成本高频轮询

核心问题

有些场景需要高频轮询，比如每1-5分钟检查一次服务器状态。但如果每次都启动一个Agent去进行复杂的推理，月底看到账单时恐怕会心疼。
这里就轮到wakeAgent门控机制登场了。它就像一道智能闸门，在执行Agent之前，先跑一个轻量级的脚本。这个脚本会判断：这次有新的变化需要处理吗？如果回答“没有”，就直接跳过Agent，一个令牌都不会消耗。

工作流程

流程可以概括为：调度触发 → 运行预检查脚本 → 根据脚本输出的JSON来决定下一步。如果JSON里是{"wakeAgent": false}，那就跳过，任务静默结束。如果{"wakeAgent": true}，就唤醒Agent，甚至可以带上context字段，直接传递一些必要数据给它。

门控食谱一：文件变更检测

最常见的场景莫过于文件监控：只有当目标文件（比如feed.json）被修改了，才唤醒Agent。脚本的逻辑很简单：比较当前文件的修改时间戳（mtime）和上次记录的时间，两者不一致就说明有变化。

这里有个跨平台的小麻烦：Linux用stat -c %Y，macOS则要用stat -f %m。

门控食谱二：外部标志位

另一个常用场景是外部系统通过创建标志文件来通知Hermes：“有新数据了，快来处理！” 门控脚本只需要检测这个标志文件是否存在。存在，就删掉它并唤醒Agent；不存在，就跳过。

门控食谱三：数据库行数检查

对于数据库监控，脚本可以检查最近一段时间内是否有新数据行。如果有，就唤醒Agent，并把新增的行数通过context字段传给它。这样Agent就不用再重复查询数据库，可以直接基于数据行数进行后续操作。

设计要点

• wakeAgent字段默认是true，所以即使脚本写得有疏漏，Agent的唤醒功能也能正常工作。
• context字段是门控脚本与Agent沟通的桥梁，可以携带任意数据，有效减少Agent的资源消耗。
• 门控脚本本身的运行开销极低，一个bash脚本通常能在10毫秒内完成。

成本对比

我们算一笔账。假设每5分钟轮询一次，一个月总共8,640次。
- 如果没有门控，每次都要调用Agent，成本完全取决于所选模型的定价。
- 如果启用门控，假设每天只有2次真实的数据变更，那么Agent的调用次数会降到大约60次。
- 如果直接用--no-agent模式运行纯脚本，成本直接归零。

这中间的差距非常可观，甚至能减少99.3%的Agent调用成本。

无 Agent 纯脚本模式：零 token 看门狗

核心概念

坦白说，很多定时任务根本不需要AI参与。比如内存超标了发个告警、磁盘快满了通知一声、SSL证书快过期了提醒一下。这些场景只是一个纯脚本就能解决的事，只需要一个可靠的调度器和消息投递通道。

为此，Hermes专门设计了--no-agent模式。它就像一个“看门狗”，只做两件事：按照调度执行脚本，然后根据脚本输出来决定是否发送消息。整个过程零LLM调用，零Token消耗。而且，它仍然使用Hermes统一的调度器和投递路由，跟Agent模式的任务完全共存，管理方式也完全一样。

脚本输出规则

模式的核心逻辑在于脚本的输出是否符合规则：
- 脚本正常退出(exit 0)，并且有非空的stdout输出，那这个输出就会被投递出去。
- 如果脚本正常退出，但stdout为空，那就认为是“一切正常”，静默跳过，不发任何消息。
- 如果stdout包含了{"wakeAgent": false}，同样会静默跳过。
- 脚本非零退出，或者执行超时，Hermes认为这是看门狗本身出问题了，会立刻投递错误告警，确保你不会在“无声”中错失问题。

创建方式

你可以通过CLI手动创建，比如创建一个每5分钟检查一次内存的超额告警任务。也可以直接跟Hermes聊天，用自然语言说“一旦内存超过85%就在Telegram上提醒我”，它会自动帮你搞定脚本创建和任务配置。

典型适用场景

这种模式的应用场景非常广泛，从系统监控到业务指标，基本覆盖了IT运维的方方面面。

判断一个场景该用Agent模式还是纯脚本模式，标准很简单：任务的输出内容是否需要AI进行推理？如果脚本自己就能搞定，那就用纯脚本模式。

两种模式共享同一个调度器，管理命令完全通用，不需要为了不同模式而去维护两套工具链。

[SILENT] 静默抑制：只有真正有事才通知

定时任务最大的痛点是什么？是通知轰炸。每隔几小时就收到一条“一切正常”的消息，这会让通知渠道很快就变成没人看的背景噪音。Hermes的解决方案很巧妙：当Agent的最终响应以[SILENT]开头时，通知会被完全抑制。

你只需要在提示词末尾加一句：“如果一切正常，没什么需要报告的，就用 [SILENT] 开头回复我。” 这样一来，Agent判断无事可报，就会回复[SILENT] All systems normal，这条消息就不会发出来。只有当它发现问题，回复具体的告警内容时，你才会收到通知。而任务的输出依然会保存在本地供事后审计。

这让你可以放心地设置高频率任务，只有真正需要你关注的结果才会打扰你。

workdir 绑定：让定时任务理解项目上下文

默认行为

默认情况下，Cron任务运行在和主线对话完全隔离的环境中，它不知道你项目根目录里有AGENTS.md、CLAUDE.md之类的项目级配置文件。

绑定项目目录

通过--workdir参数，这个问题就迎刃而解了。绑定之后，
- 项目的AGENTS.md、CLAUDE.md、.cursorrules等系统提示词会被自动注入。
- 任务中用到的terminal、read_file等工具，都会以这个目录为基准进行工作。
- Agent自然而然地就理解了项目的结构，你完全不用在提示词里解释文件是怎么布局的。

一个小限制：带有workdir的任务在调度周期内是串行执行的，这是为了安全，防止多个任务的终端环境互相污染。

profile 隔离

通过--profile参数，甚至可以让不同的定时任务使用完全独立的Hermes配置，比如不同的模型、API Key和投递目标，非常适用于需要严格隔离的场景。

17 个官方自动化模板分类解读

Hermes官方提供了17个经过社区验证的自动化模板，覆盖了开发、运维、情报、业务等多个场景，非常值得参考。

开发工作流（4个）

DevOps 与监控（3个）

研究与情报（3个）

GitHub 事件自动化（3个）

业务运营（2个）

多 Skill 工作流（2个）

模板使用建议

这些模板是很好的起点，但千万别照搬。一定要根据自己的实际需求去调整：把通用占位符换成你自己的仓库和频道；根据信息密度调整执行频率；最关键的是，给每个任务加上[SILENT]逻辑，确保没事的时候别来烦你。

与 Persistent Goals 的互补关系

Hermes里还有另一个自动化机制——持久目标，它和Cron形成了完美的互补。

它们甚至可以组合使用：比如，Cron每天早上9点按计划触发一个任务，而这个任务内部则可以设定一个Persistent Goal，比如“找到3条值得写推文的AI新闻”。Agent就会在任务内部自动迭代，直到达成目标为止，这比简单的一次搜索要可靠得多。

调度器工作机制

理解底层机制有助于你在遇到问题时能快速排查。Gateway守护进程每60秒会触发一次调度器的“心跳”（tick）：
1. 它首先加载任务列表。
2. 检查每个任务的下次运行时间是否已到。
3. 为每个到期任务创建一个全新的Agent会话。
4. 接下来是关键的步骤：它会把挂载的Skill注入到会话中，然后执行任务的提示词，等待完成。
5. 最后，将Agent的最终响应投递到配置好的目标，并更新任务的运行元数据和下一次的调度计划。

另外，一个文件锁的存在有效防止了重叠的调度心跳重复运行同一批任务。

关键约束

这里有一个很重要的安全边界：Cron任务执行时，Agent是无法在任务内部递归创建新的Cron任务的。这是为了防止因为某个Agent在定时任务里“头脑发热”，不断创建新的定时任务，最终导致调度链指数级膨胀，耗尽所有资源。

工具集控制与 Provider 恢复

你可以通过enabled_toolsets字段，实现对单个任务可用工具的精细控制。其优先级是：任务级配置 > 平台全局配置 > 内置默认。

此外，Cron任务还继承了模型降级策略和凭据池轮换。当主API Key限流或模型不可用时，任务会自动降级到备选Provider或轮换到凭证池中的下一个Key，确保任务不会因为资源枯竭而失败。

5 个完整配方（可直接复制）

配方一：三级 AI 新闻流水线

每天自动采集、筛选、生成推文草稿，并投递到Telegram和Discord。这个配方我们刚才已经详细拆解过，你只需要按照三级流水线的模式，分别配置好数据收集、筛选、简报三个任务，并串联起来即可。

配方二：智能 SSL 证书监控（零成本）

用纯脚本模式实现零成本的SSL证书到期监控。脚本会每天检查所有域名的证书有效期，只有14天内到期才会告警。如果没有到期的，就静默跳过。全年运行成本为零。

配方三：项目级 CI 健康巡检

工作日每天早上9点，这个任务会自动审计项目的PR和CI状态。它会把未合并的PR、CI的成功率、以及是否有超过7天未review的PR汇总起来，并发布到团队频道。如果一切正常，就用[SILENT]回复，保持安静。

配方四：竞品仓库监控 + 分析

每天早上8点，这个任务会扫描多个竞品仓库，检查过去24小时内是否有新的PR、Issue或Release。一旦发现重大变更（比如新版本、安全修复），还会生成附带简要影响分析的报告。如果没有新活动，就静默。

配方五：macOS Gateway 完整部署 + 知识库联动

在macOS上部署Hermes Gateway，并让Cron任务与知识库目录联动起来。关键踩坑点：每次运行 hermes gateway install 后，它会从内置模板重新生成 plist 文件，覆盖你手工设置的工作目录。所以每次升级或重装Gateway后，都别忘了重新修补一下工作目录。

Skill 挂载：给定时任务装上专业工具

Cron任务可以挂载一个或多个Skill，从而在执行时获得额外的专业能力。比如，挂载blogwatcher Skill来监控RSS源，挂载github-pr-workflow Skill来自动审查PR，或者挂载obsidian Skill来将论文摘要自动存档到你的笔记系统里。

自包含提示词：Cron 任务的黄金法则

最后，也是最最重要的一条法则：Cron任务运行在全新的会话中，没有任何记忆和上下文。因此，你的提示词必须自包含，也就是要包含Agent完成任务所需的一切信息。

错误的例子是：“给我做个常规的早间简报。” Agent根本不知道“常规”是什么意思。正确的做法是把需求说得明明白白：搜索什么、搜多少篇、用什么格式、用什么语气、输出结构是什么。总之，提示词越具体，任务执行得越精准。