Hermes Agent 的定时任务(Cron)让 AI 在你睡觉时替你干活:每天定时采集情报、按条件判断是否需要处理、多阶段流水线自动衔接、结果投递到你指定的任何平台。三个典型场景——每日 AI 新闻简报自动推送到 Telegram、SSL 证书到期前 14 天告警零成本运行、竞品仓库有新动态时自动生成分析报告。
本文完整覆盖 Hermes Cron 子系统的核心机制和实战配方。如果你还没部署 Hermes Agent,建议先阅读 Hermes Agent 完全指南 完成基础搭建。
基础配置:从零创建第一个定时任务
三种创建方式
Hermes 支持三种方式创建定时任务,核心是统一的 cronjob 工具:
方式一:聊天中用斜杠命令
/cron add 30m "Remind me to check the build"
/cron add "every 2h" "Check server status"
/cron add "every 1h" "Summarize new feed items" --skill blogwatcher
方式二:独立 CLI 命令
hermes cron create "every 2h" "Check server status"
hermes cron create "every 1h" "Summarize" --skill blogwatcher --name "feed-summary"
方式三:自然语言对话
直接告诉 Hermes 你要什么,它自动转换为定时任务:
Every morning at 9am, check Hacker News for AI news and send me a summary on Telegram.
三种方式效果完全等价,Hermes 内部都通过统一的 cronjob 工具执行。
调度格式
| 格式 | 示例 | 行为 |
|---|---|---|
| 相对延迟 | 30m、2h、1d |
一次性执行 |
| 间隔 | every 30m、every 2h |
永续循环 |
| 标准 Cron 表达式 | 0 9 * * *(每天 9:00) |
五段式精确控制 |
| 工作日限定 | 0 9 * * 1-5 |
仅周一到周五 |
| ISO 时间戳 | 2026-03-15T09:00:00 |
一次性精确时间 |
间隔和 Cron 表达式默认永远运行,可通过 repeat=N 限制执行次数。
投递目标
创建任务时用 --deliver 指定结果投递到哪里:
| 目标 | 说明 |
|---|---|
origin |
返回创建任务的原始聊天(消息平台默认) |
local |
保存到本地 ~/.hermes/cron/output/(CLI 默认) |
telegram |
Telegram 主频道 |
telegram:123456 |
指定 Telegram 聊天 ID |
discord |
Discord 主频道 |
discord:#engineering |
指定 Discord 频道 |
slack / email / sms |
各平台主频道 |
telegram,discord |
多平台广播(逗号分隔) |
all |
广播到所有已连接的主频道 |
支持的平台超过 15 个,包括 WhatsApp、Signal、Matrix、飞书、企业微信、钉钉、Home Assistant 等。
生命周期管理
| 操作 | 命令 | 说明 |
|---|---|---|
| 列表 | hermes cron list |
查看所有任务、状态和下次运行时间 |
| 暂停 | hermes cron pause <id或名称> |
保留任务但停止调度 |
| 恢复 | hermes cron resume <id或名称> |
重新启用 |
| 手动触发 | hermes cron run <id或名称> |
在下次 tick 立即执行 |
| 编辑 | hermes cron edit <id> --schedule "0 8 * * *" |
修改调度时间 |
| 移除 | hermes cron remove <id或名称> |
永久删除 |
| 状态 | hermes cron status |
检查调度器是否运行 |
所有操作支持按名称查找(大小写不敏感),不用记十六进制 ID。
任务链:用 context_from 串联多阶段流水线

核心问题
Cron 任务运行在完全隔离的会话中,没有前次运行的记忆。但实际场景中,经常需要前一个任务的输出作为下一个任务的输入——采集数据后筛选,筛选后格式化,格式化后发布。
传统方案是手动在提示词里写「读某个文件」,或者用共享目录中转。Hermes 的 context_from 参数直接解决这个问题:任务 B 运行时,自动获得任务 A 的最近一次成功输出作为上下文前缀。
工作原理
任务 A 执行完成 → 输出存入 ~/.hermes/cron/output/{job_a_id}/
↓
任务 B 触发时 → 自动读取任务 A 的最近输出 → 前缀到任务 B 的提示词
↓
任务 B 的 Agent 直接看到上游数据 → 无需硬编码文件路径
经典三级流水线
三个定时任务通过 context_from 自动串联,上游输出作为下游的上下文前缀注入:
提示词:生成三阶段 AI 新闻流水线的 Cron 任务
请帮我用 Hermes cronjob 工具创建三级流水线。要求:
- 第一阶段「AI News Collector」:每天 7:00(
0 7 * * *)采集 Hacker News 前 10 条 AI/ML 新闻,输出编号列表(标题、URL、一句话摘要) - 第二阶段「AI News Triage」:每天 7:30(
30 7 * * *),context_from设为"AI News Collector",对每条新闻按互动潜力和新颖度评分 1-10,只保留两项均 ≥ 7 的条目,输出排名列表附评分和理由 - 第三阶段「AI News Brief」:每天 8:00(
0 8 * * *),context_from设为"AI News Triage",为入围新闻生成推文草稿(hook 行、核心洞察、URL、标签),无合格新闻时以[SILENT]开头回复
链接格式
| 格式 | 用法 |
|---|---|
| 单任务(字符串) | context_from="AI News Collector" |
| 多任务(列表) | context_from=["task-a", "task-b"] |
多任务引用时,输出按列表顺序拼接——实现扇入(fan-in)模式:一个下游任务聚合多个上游的结果。
设计要点
- 链接读取的是上游任务最近一次成功完成的输出,不会等待同一 tick 内正在运行的上游
- 支持按名称或 ID 引用
- 链条长度无硬性限制,实际建议 3-5 级以内
- 上游未执行过(无输出)时,下游正常运行但没有额外上下文
预运行门控:用 wakeAgent 实现零成本高频轮询

核心问题
高频轮询(每 1-5 分钟)场景下,绝大多数 tick 其实没有新内容需要处理。如果每次都启动 Agent 进行推理,月底账单会很难看。
wakeAgent 门控机制让脚本在 Agent 启动之前决定本次是否需要调用——脚本判断没有新状态时,直接跳过 Agent,零 LLM 调用、零 token 消耗、零成本。
工作流程
调度 tick → 运行预检查脚本 → stdout 最后一行输出 JSON
↓
{"wakeAgent": false} → 跳过 Agent,静默结束
{"wakeAgent": true} → 正常唤醒 Agent 处理
{"wakeAgent": true, "context": {...}} → 唤醒并传递数据
门控食谱一:文件变更检测
只有当目标文件被修改时才唤醒 Agent。脚本通过比较文件的修改时间戳与上次记录来判断是否有变化:
提示词:生成文件变更检测门控脚本
请帮我生成 ~/.hermes/scripts/feed-changed.sh,用于 Hermes Cron 预运行门控。要求:
- 监控目标文件
$HOME/data/feed.json - 用状态文件
$HOME/.hermes/scripts/.feed-changed.last记录上次检测的 mtime - 用
stat获取目标文件的修改时间(注意 Linux 用stat -c %Y,macOS 用stat -f %m) - 与状态文件中记录的上次时间对比
- 文件不存在或未变化时输出
{"wakeAgent": false} - 有变化时更新状态文件并输出
{"wakeAgent": true}
门控食谱二:外部标志位
其他系统通过创建标志文件通知 Hermes「有新数据了」。门控脚本检测标志文件是否存在,存在则删除并唤醒,不存在则跳过:
提示词:生成外部标志位门控脚本
请帮我生成 ~/.hermes/scripts/flag-ready.sh,用于 Hermes Cron 预运行门控。要求:
- 检查
/tmp/new-data-ready标志文件是否存在 - 存在时:删除标志文件(
rm -f),输出{"wakeAgent": true} - 不存在时:输出
{"wakeAgent": false} - 其他系统只需
touch /tmp/new-data-ready即可触发 Agent
门控食谱三:数据库行数检查
数据库有新数据时才唤醒,并把新增行数通过 context 字段传给 Agent,减少 Agent 重复查询:
提示词:生成数据库行数检查门控脚本
请帮我生成 ~/.hermes/scripts/new-rows.py(Python 3),用于 Hermes Cron 预运行门控。要求:
- 连接 SQLite 数据库(路径自定义,如
/home/me/data/app.db) - 查询最近 2 小时内
messages表的新行数(WHERE ts > strftime('%s','now','-2 hours')) - 新行数 < 1 时输出
{"wakeAgent": false} - 新行数 ≥ 1 时输出
{"wakeAgent": true, "context": {"new_rows": N}},将行数传递给 Agent
设计要点
wakeAgent字段缺省时默认true——即照常唤醒 Agentcontext字段可携带任意数据传递给 Agent,减少 Agent 重复查询- 门控脚本的开销是系统级别(进程启动 + 脚本执行),对于 bash 脚本通常在 10ms 以内完成
- 同一机制适用于 Agent 任务和 no-agent 任务
成本对比
假设每 5 分钟轮询一次、每天 288 次 tick、每月 8,640 次:
| 方案 | 月度 Agent 调用 | 月度成本 |
|---|---|---|
| 无门控(每次都调 Agent) | 8,640 | 按模型定价计算 |
| 有门控(日均 2 次真实变更) | ~60 | 减少 99.3% |
| no-agent 纯脚本 | 0 | $0 |
无 Agent 纯脚本模式:零 token 看门狗

核心概念
有些定时任务根本不需要 AI 推理——内存超标了告警一下、磁盘快满了通知一声、SSL 证书快到期了提醒一下。这些场景用脚本就能搞定,只需要一个靠谱的调度器和投递通道。
Hermes 的 no-agent 模式(--no-agent)正是为此设计:
调度 tick → 运行脚本 → 有输出?投递 / 无输出?静默
- 零 LLM 调用——零 token、零模型消费
- 同一调度器——与 Agent 任务共存,暂停/恢复/列表/日志/投递均通用
- 同一投递路由——脚本输出直接发送到 Telegram/Discord/邮件
脚本输出规则
| 脚本行为 | 结果 |
|---|---|
| exit 0 + 非空 stdout | stdout 原样投递 |
| exit 0 + 空 stdout | 静默 tick,不投递 |
exit 0 + stdout 含 {"wakeAgent": false} |
静默 tick |
| 非零退出码 | 错误告警投递(坏掉的看门狗不会无声失败) |
| 脚本超时 | 错误告警投递 |
关键设计:非零退出码始终投递错误告警。这意味着看门狗本身出了问题,你一定会收到通知。
创建方式
CLI 创建:
用 no-agent 模式创建一个内存看门狗,每 5 分钟检查一次,超过阈值时告警:
提示词:生成内存看门狗脚本和 Cron 任务
请帮我完成两步操作:
- 生成
~/.hermes/scripts/memory-watchdog.sh脚本:用free命令计算内存使用百分比,超过 85% 时输出"RAM {百分比}% on {hostname}",未超过时不输出任何内容(空 stdout = 静默 tick) - 创建 Hermes Cron 任务:
hermes cron create "every 5m",参数--no-agent、--script memory-watchdog.sh、--deliver telegram、--name "memory-watchdog"
- 脚本需要
chmod +x
聊天创建(Hermes 自动判断适合 no-agent):
Ping me on Telegram if RAM is over 85%, every 5 minutes.
Hermes 会自动完成:写脚本到 ~/.hermes/scripts/ → 调用 cronjob(no_agent=True) → 配置投递。
脚本存放规则
- 必须位于
~/.hermes/scripts/ - 绝对路径、
~/展开和路径遍历(../)均被拒绝 - 解释器由文件扩展名决定:
.sh/.bash用/bin/bash,其他用 Python
典型适用场景
| 场景 | 频率 | 说明 |
|---|---|---|
| 内存/磁盘/GPU 看门狗 | 每 5 分钟 | 超阈值才告警,其余静默 |
| 服务端点健康检查 | 每 30 分钟 | 宕机时推送,正常时静默 |
| SSL 证书到期监控 | 每天一次 | 14 天内到期才通知 |
| CI 部署通知 | 触发式 | 部署完成发送 commit SHA |
| 定期业务指标 | 每天一次 | Stripe 收入汇总 |
| 心跳检测 | 每 10 分钟 | 证明主机存活 |
选择依据:Agent 还是 no-agent?
判断标准很简单——输出内容是否需要推理。如果脚本能直接计算出最终要发的消息(阈值比较、字符串拼接、数据格式化),用 no-agent。如果输出需要理解语义、做总结、写分析,用标准 Agent 模式。
两种模式共存于同一个调度器中,暂停、恢复、列表、日志、投递的管理命令完全通用,不需要为不同模式维护不同的工具链。
完整示例:磁盘空间告警
脚本每 15 分钟检查根分区和 /home 分区的使用率,超过阈值时输出告警文本触发投递,未超过时不输出任何内容——空 stdout 等于静默 tick。
提示词:生成磁盘空间告警脚本和 Cron 任务
请帮我完成两步操作:
- 生成
~/.hermes/scripts/disk-alert.sh脚本:用df -h检查根分区/和/home分区,阈值设为 90%,使用awk提取使用率百分比,超过阈值时输出"Disk {使用率} full on {挂载点}",未超过时不输出 - 创建 Hermes Cron 任务:
hermes cron create "*/15 * * * *",参数--no-agent、--script disk-alert.sh、--deliver telegram、--name "disk-alert"
- 脚本需要
chmod +x
[SILENT] 静默抑制:只有真正有事才通知
定时任务最大的痛点是通知轰炸——每隔几小时收到一条「一切正常」的消息,很快就会把通知渠道变成噪声源。
Hermes 的解决方案:当 Agent 最终响应以 [SILENT] 开头时,投递被完全抑制。
提示词末尾加一句:
"If everything is healthy and there's nothing to report, respond with [SILENT]."
效果:
- Agent 判断无事可报 → 回复
[SILENT] All systems normal→ 不发消息 - Agent 发现问题 → 回复具体告警内容 → 正常投递
- 输出仍保存在本地
~/.hermes/cron/output/供事后审计 - 失败的任务始终投递,不受
[SILENT]影响
这让你可以放心设置高频率任务——只有真正需要你关注的结果才会打扰你。
workdir 绑定:让定时任务理解项目上下文
默认行为
Cron 任务默认运行在隔离环境中,不加载任何项目级的 AGENTS.md、CLAUDE.md 或 .cursorrules。
绑定项目目录
通过 --workdir 参数改变这一行为:
hermes cron create "0 9 * * 1-5" \
"Audit open PRs, summarize CI health, and post to #eng" \
--workdir /home/me/projects/acme \
--deliver "discord:#engineering"
绑定后的效果:
| 项 | 说明 |
|---|---|
| 系统提示词 | 项目的 AGENTS.md、CLAUDE.md、.cursorrules 自动注入 |
| 工具工作目录 | terminal、read_file、write_file、search_files 以该目录为基准 |
| 上下文理解 | Agent 天然了解项目结构,无需在提示词中解释文件布局 |
重要限制:带 workdir 的任务在调度 tick 内串行执行(非并行池),防止终端状态互相污染。路径必须是存在的绝对目录。
profile 隔离
通过 --profile <name> 让任务使用独立的 Hermes 配置(不同的 .env、config.yaml、HERMES_HOME):
hermes cron create "0 3 * * *" \
"Tail the security log and flag anomalies" \
--profile night-ops
适用场景:不同项目使用不同的模型、不同的 API Key、不同的投递目标。
17 个官方自动化模板分类解读

Hermes 官方提供了 17 个经过验证的自动化模板,覆盖三种触发类型(定时调度、GitHub 事件、API 调用)和五大场景。
开发工作流(4 个)
| 模板 | 触发 | 做什么 |
|---|---|---|
| Nightly Backlog Triage | 每晚 2:00 | 对新 Issue 打优先级标签 P0-P3,按 bug/feature/docs/security 分类 |
| Automatic PR Code Review | GitHub Webhook | 自动审查新 PR,检查安全/性能/代码质量,投递审查评论 |
| Docs Drift Detection | 每周一 9:00 | 扫描已合并 PR,检测代码变更是否遗漏了文档更新 |
| Dependency Security Audit | 每天 6:00 | 运行 pip audit + npm audit,报告 CVSS >= 7.0 的漏洞 |
DevOps 与监控(3 个)
| 模板 | 触发 | 做什么 |
|---|---|---|
| Deploy Verification | API 调用 | CI/CD 部署后自动烟雾测试,验证健康端点和版本号 |
| Alert Triage | API 调用 | 接收 Datadog/PagerDuty 告警,关联近期变更,生成分诊摘要 |
| Uptime Monitor | 每 30 分钟 | 脚本检查多端点可用性,仅宕机时通知([SILENT] 模式) |
研究与情报(3 个)
| 模板 | 触发 | 做什么 |
|---|---|---|
| Competitive Repository Scout | 每天 8:00 | 监控竞品仓库的 PR、Issue 和 Release |
| AI News Digest | 每周一 9:00 | 搜索 AI 新闻、GitHub 趋势仓库、arXiv 论文,生成周报 |
| Paper Digest with Notes | 每天 8:00 | 搜索 arXiv 论文,用 Obsidian Skill 保存笔记 |
GitHub 事件自动化(3 个)
| 模板 | 触发 | 做什么 |
|---|---|---|
| Issue Auto-Labeling | GitHub Webhook | 新 Issue 自动打标签、发初始回复 |
| CI Failure Analysis | GitHub Webhook | CI 失败时分析日志、定位原因、建议修复 |
| Auto-Port Changes | GitHub Webhook | PR 合并后自动移植到其他仓库 |
业务运营(2 个)
| 模板 | 触发 | 做什么 |
|---|---|---|
| Stripe Payment Monitoring | API 调用 | 监控支付失败和争议事件 |
| Daily Revenue Summary | 每天 8:00 | 编译每日业务指标 |
多 Skill 工作流(2 个)
| 模板 | 触发 | 做什么 |
|---|---|---|
| Security Audit Pipeline | 每周日 3:00 | 组合多 Skill 进行全面安全审计 |
| Content Pipeline | 每周三 10:00 | 研究趋势话题、生成博文大纲 |
模板使用建议
不要照搬模板——它们是起点不是终点。根据你的实际需求调整:
- 把模板中的通用占位换成你的具体仓库、频道、搜索关键词
- 根据信息密度调整频率——竞品监控每天够用,内存告警可能需要每 5 分钟
- 给每个任务加上
[SILENT]逻辑——没事别发消息
与 Persistent Goals 的互补关系
Hermes 还有另一个自动化机制——持久目标(Persistent Goals),与 Cron 形成互补:
| 维度 | Cron | Persistent Goals |
|---|---|---|
| 触发方式 | 时间驱动(定时调度) | 目标驱动(达标即停) |
| 会话模型 | 每次全新会话 | 同一会话跨轮次持续 |
| 典型时长 | 分钟级单次执行 | 可能跨越数小时 |
| 适用场景 | 循环监控、定时报告 | 复杂重构、迭代式搜索 |
| 成本模式 | 单次 Agent 调用 | 最多 20 轮迭代 |
组合用法:Cron 任务按计划触发,内部设定 Goal 驱动迭代。例如每天 9:00 的 Cron 任务,Goal 设为「找到 3 条值得写推文的 AI 新闻」——Agent 自动迭代直到找齐。
调度器工作机制

理解底层有助于排障。Gateway 守护进程每 60 秒 tick 一次调度器:
- 从
~/.hermes/cron/jobs.json加载任务列表 - 检查每个任务的
next_run_at是否到期 - 为每个到期任务创建全新
AIAgent会话 - 可选注入挂载的 Skill
- 执行提示词至完成
- 投递最终响应到配置目标
- 更新运行元数据和下次计划时间
文件锁 ~/.hermes/cron/.tick.lock 防止重叠的调度 tick 重复运行同批任务。
任务存储与输出
任务定义存储在 ~/.hermes/cron/jobs.json 中,使用原子文件写入(写入临时文件后重命名)防止并发损坏。每次任务执行的输出保存到 ~/.hermes/cron/output/{job_id}/{timestamp}.md,可用于 context_from 链接和事后审计。
投递响应包装
默认情况下,Hermes 会在投递消息中包含标题和页脚,标识该消息来自定时任务而非实时对话。可通过 cron.wrap_response: false 关闭这个包装,让消息看起来和普通对话一样。
关键约束
Cron 执行的会话无法递归创建更多 Cron 任务——Hermes 在 Cron 执行内部禁用 Cron 管理工具,防止失控的调度循环。这是一个有意为之的安全边界:如果 Agent 能在定时任务中创建新的定时任务,很容易产生指数级膨胀的调度链,最终耗尽所有资源。
工具集控制与 Provider 恢复
精细控制工具集
通过 enabled_toolsets 逐任务控制可用工具:
cronjob(
action="create",
name="weekly-news-summary",
schedule="every sunday 9am",
enabled_toolsets=["web", "file"], # 只给 web 搜索和文件读写
prompt="Summarize this week's AI news..."
)
优先级:任务级 enabled_toolsets > hermes tools 平台配置 > 内置默认。
Provider 恢复
Cron 任务继承配置的模型降级策略和凭据池轮换。主 API Key 限流时,自动降级到备选 Provider 或轮换到凭据池中的下一个 Key。
实际效果:早上 8 点多个 Cron 任务集中触发,主模型配额用完时,任务自动切换到备选模型继续执行,不会因为限流失败。

5 个完整配方(可直接复制)
配方一:三级 AI 新闻流水线
每天自动采集、筛选、生成推文草稿,投递到 Telegram 和 Discord:
提示词:生成三级 AI 新闻流水线 Cron 任务
请帮我用 hermes cron create 创建三级流水线。要求:
- 第一级「ai-news-collect」:每天 7:00(
0 7 * * *),搜索 Hacker News、Reddit r/MachineLearning 和 arXiv 的 AI Agent 新闻,聚焦开源框架/工具使用突破/多 Agent 系统,输出编号列表(标题、URL、一句话摘要),--deliver local - 第二级「ai-news-triage」:每天 7:30(
30 7 * * *),--context-from "ai-news-collect",按互动潜力和新颖度两轴评分 1-10,只保留两项均 ≥ 7 的条目,输出排名列表附评分和理由,--deliver local - 第三级「ai-news-brief」:每天 8:00(
0 8 * * *),--context-from "ai-news-triage",为每条入围新闻写推文草稿(hook 行 < 50 字符、核心洞察 1-2 句、URL、标签最多 3 个),无合格新闻时以[SILENT]开头回复,--deliver "telegram,discord"
设计要点:
- 三级
context_from串联,上游输出自动注入下游 - 第三级使用
[SILENT]——没有合格新闻时不打扰 - 投递逗号分隔同时推送多平台
配方二:智能 SSL 证书监控(零成本)
每天检查所有域名 SSL 证书,14 天内到期才告警,全年运行成本 $0:
用 no-agent 模式实现零成本 SSL 监控——脚本直接检查证书有效期,无需 AI 参与:
提示词:生成 SSL 证书到期监控脚本和 Cron 任务
请帮我完成两步操作:
- 生成
~/.hermes/scripts/ssl-check.sh,set -euo pipefail。要求:
- 定义域名列表变量(如
example.com api.example.com docs.example.com)和阈值变量(14 天) - 遍历每个域名,用
openssl s_client连接 443 端口获取证书到期时间 - 用
openssl x509 -noout -enddate提取到期日期,计算剩余天数 - 兼容 macOS(
date -j -f)和 Linux(date -d)的日期解析 - 剩余天数 ≤ 阈值时累积告警文本
"SSL WARNING: {域名} expires in {天数} days" - 所有域名检查完毕后:无告警输出
{"wakeAgent": false}(静默跳过),有告警输出告警文本(触发投递)
- 创建 Hermes Cron 任务:
hermes cron create "0 9 * * *",参数--no-agent、--script ssl-check.sh、--deliver telegram、--name "ssl-expiry-watch"
- 脚本需要
chmod +x
设计要点:
- no-agent 模式零 LLM 调用
- 没有到期域名时输出
{"wakeAgent": false}静默跳过 - 有告警时直接输出文本投递
配方三:项目级 CI 健康巡检
工作日每天 9 点检查项目 PR 和 CI 状态,全绿时静默:
工作日每天 9 点自动审计项目 PR 和 CI 状态,全绿时静默不打扰:
提示词:生成项目级 CI 健康巡检 Cron 任务
请帮我用 hermes cron create 创建 CI 健康巡检任务。要求:
- 调度
"0 9 * * 1-5"(仅工作日) - 提示词包含四步:①用
gh pr list --state open --limit 10汇总未合并 PR;②用gh run list --limit 5报告 CI 通过/失败率;③检查是否有 PR 超过 7 天未 review;④将结果发布到 #eng 频道 - 全部 PR 已 review 且 CI 全绿时以
[SILENT]开头回复 --name "morning-ci-health"--workdir绑定项目目录(Agent 自动加载 AGENTS.md/CLAUDE.md 理解项目结构)--skill github-pr-workflow(挂载 GitHub Skill 增强能力)--deliver "discord:#engineering"
配方四:竞品仓库监控 + 分析
每天早上监控竞品的新 PR 和 Issue,有重要动态时生成分析报告:
提示词:生成竞品仓库监控 Cron 任务
请帮我用 hermes cron create "0 8 * * *" 创建竞品监控任务。要求:
- 监控 4 个仓库:
anthropics/claude-code、openai/codex、All-Hands-AI/OpenHands、aider-chat/aider - 对每个仓库执行三步
gh命令:①gh pr list --repo REPO --state all --limit 10 --json number,title,createdAt;②gh issue list --repo REPO --state open --limit 5 --json number,title,labels;③gh release list --repo REPO --limit 3 - 只汇总最近 24 小时内创建的新条目
- 所有仓库均无新活动时以
[SILENT]开头回复 - 重大变更(新 release、安全修复、breaking change)附带简要影响分析
--name "competitor-scout"--deliver "telegram,discord:#research"
设计要点:
- 四个竞品仓库一次扫完
- 只关注最近 24 小时的新动态
- 无活动时静默
- 重大变更时附带影响分析
配方五:macOS Gateway 完整部署 + 知识库联动
在 macOS 上部署 Gateway 并让 Cron 任务与知识库目录联动:
pipx install "hermes-agent[messaging]"
hermes gateway install
plutil -replace WorkingDirectory \
-string "$HOME/projects/knowledge-base" \
~/Library/LaunchAgents/ai.hermes.gateway.plist
前三步完成安装、注册 launchd 服务和修补工作目录后,还需要重启 Gateway、验证状态并创建绑定知识库的 Cron 任务:
提示词:完成 macOS Gateway 部署和知识库联动
请帮我完成 Hermes Gateway macOS 部署的后续步骤。要求:
- 重启 Gateway:
hermes gateway restart - 验证运行状态:
hermes cron status和hermes cron list - 创建一个绑定知识库的 Cron 任务:每天 9:00 读取工作目录下的
inbox/todo.md,汇总标记为 urgent 或 overdue 的条目,无紧急事项时以[SILENT]回复 --name "kb-todo-check"、--deliver telegram
关键踩坑点:
hermes gateway install每次执行都会从内置模板重新生成 plist,覆盖你手工设的WorkingDirectory。每次升级或重装 Gateway 后必须重新修补。- Gateway 的
WorkingDirectory决定了所有 Cron 任务中相对路径的基准。设置为知识库根目录后,任务中read_file('inbox/todo.md')直接落在知识库里。 - macOS 上
stat -c %Y不可用,门控脚本需改用stat -f %m获取修改时间。
Skill 挂载:给定时任务装上专业工具
Cron 任务可以挂载一个或多个 Skill,让 Agent 在执行时拥有额外能力。
单 Skill 挂载
cronjob(
action="create",
skill="blogwatcher",
prompt="Check the configured feeds and summarize anything new.",
schedule="0 9 * * *",
name="Morning feeds",
)
多 Skill 挂载
cronjob(
action="create",
skills=["blogwatcher", "maps"],
prompt="Look for new local events and interesting nearby places.",
schedule="every 6h",
name="Local brief",
)
推荐搭配
| Skill | 功能 | Cron 搭配场景 |
|---|---|---|
blogwatcher |
RSS/Atom 源监控 | 每日早报、内容趋势追踪 |
github-pr-workflow |
PR 生命周期管理 | 自动 Code Review |
youtube-content |
YouTube 视频分析 | 竞品频道监控 |
obsidian |
Obsidian 笔记读写 | 论文摘要自动存档 |
kanban-orchestrator |
看板式任务编排 | 定时任务巡检 |
安全与存储
安全扫描
定时任务的提示词在创建和更新时自动扫描:
- 提示注入模式(Prompt Injection)
- 凭据泄露模式
- 不可见 Unicode 技巧
- SSH 后门尝试
包含以上模式的提示词会被直接阻止。
任务存储
| 项 | 路径 |
|---|---|
| 任务定义 | ~/.hermes/cron/jobs.json(原子写入) |
| 任务输出 | ~/.hermes/cron/output/{job_id}/{timestamp}.md |
| 脚本目录 | ~/.hermes/scripts/ |
| 调度锁 | ~/.hermes/cron/.tick.lock |
任务存储使用原子文件写入(写入临时文件后重命名),防止并发损坏。
自包含提示词:Cron 任务的黄金法则
Cron 任务在完全全新的会话中运行——没有之前对话的记忆、没有聊天历史、没有上下文。提示词必须包含 Agent 完成任务所需的一切。
错误写法:
Do my usual morning briefing.
Agent 不知道「usual」是什么。
正确写法:
Search the web for the latest news about AI agents and open source LLMs.
Find at least 5 recent articles from the past 24 hours.
Summarize the top 3 most important stories in a concise daily briefing format.
For each story include: a clear headline, a 2-sentence summary, and the source URL.
Use a friendly, professional tone.
Format with bullet points and end with a total story count.
具体到:搜索什么、多少篇、什么格式、什么语气、输出结构。
社区常见定时任务模式
每日简报类
Reddit 社区中最受欢迎的 Cron 用例是每日简报。一位用户分享了完整的晨间自动化配置:
- 09:00 Daily Briefing:融合天气、Google Calendar 日程、iCloud Reminders 全日事件,投递到 Telegram
- 08:30 Hermes 更新追踪:检查
NousResearch/hermes-agent仓库最近 24 小时的提交,分页遍历所有页,投递变更摘要
这种配置的价值在于:你每天早上打开 Telegram 就能看到今天的完整日程 + 关注领域的最新动态,不需要手动打开日历、GitHub、新闻网站逐一检查。
系统看门狗类
无 Agent 模式的经典场景:
- Every 5m 内存看门狗:RAM 超过 85% 时告警,no-agent 模式零 LLM 成本
- Every 30m 服务端点检查:检查多个 URL 的可用性,仅宕机时通知
- Every 15m 磁盘空间告警:磁盘使用率超过 90% 时告警
这些任务全年运行成本为零——纯脚本执行,只有出问题时才投递告警。
内容管线类
多阶段流水线是 Hermes Cron 最能体现差异化的场景:
- 研究 → 筛选 → 格式化 → 发布:每天自动搜索 AI 新闻,筛选高质量内容,格式化为推文草稿
- 竞品监控 → 分析 → 通知:监控竞品仓库活动,分析影响,有重大变化时通知
- 安全扫描 → 分类 → 告警:运行依赖审计,按严重程度分类,只通知高危漏洞
社区最佳实践总结
| 原则 | 说明 |
|---|---|
| 提示词必须自包含 | 不依赖对话历史,写清搜什么、多少篇、什么格式 |
| 频率匹配信息密度 | 新闻简报一天一次够用,系统告警需要分钟级 |
| 默认加静默 | 每个任务都考虑 [SILENT],只有真正有事才通知 |
| 先手动测试再自动化 | 先在对话中跑一次确认效果,再创建 Cron 任务 |
| 给任务起好名字 | 所有管理命令支持按名称操作,好名字比记 ID 轻松 |
与其他自动化方案的对比
| 维度 | Hermes Cron | OS crontab | n8n / Make |
|---|---|---|---|
| 调度能力 | 内建 | 内建 | 内建 |
| Agent 推理 | 原生集成 | 无 | 需外接 API |
| 任务链衔接 | context_from 自动 |
手动文件中转 | 连线拖拽 |
| 智能门控 | wakeAgent |
无 | 条件节点 |
| 零 LLM 模式 | --no-agent |
默认如此 | 需跳过 AI 节点 |
| 多平台投递 | 15+ 目标内建 | 需自写 | 需配节点 |
| 静默抑制 | [SILENT] |
自行实现 | 需配条件 |
| 项目上下文 | --workdir |
无 | 无 |
| 部署成本 | 自托管免费 | 免费 | SaaS 按量 |
Hermes Cron 的核心优势是 Agent 推理与调度的原生融合——不是「脚本写完了调个 API」,而是「AI 直接理解任务语义并决策输出」。
排障指南
任务不执行
最常见的原因是 Gateway 没有运行。检查步骤:
# 检查调度器状态
hermes cron status
# 如果显示未运行,重启 Gateway
hermes gateway restart
# macOS 上确认 launchd 服务状态
launchctl list | grep hermes
任务执行了但没收到消息
按顺序排查:
- 检查投递目标是否正确:
hermes cron list查看任务的deliver字段 - 检查输出是否被静默:查看本地输出
~/.hermes/cron/output/{job_id}/最近的文件,确认是否以[SILENT]开头 - 检查平台连接:确认 Telegram/Discord 等平台的凭据和频道配置正确
- 手动触发一次:
hermes cron run <任务名>观察执行过程
context_from 没有注入上游输出
检查上游任务是否成功执行过。context_from 读取的是上游最近一次成功完成的输出。如果上游从未成功执行(没有产出 ~/.hermes/cron/output/{job_id}/ 下的文件),下游任务正常运行但不会有额外上下文。
门控脚本不生效
确认脚本位于 ~/.hermes/scripts/ 目录下,并且有执行权限(chmod +x)。脚本的 {"wakeAgent": false} 必须出现在 stdout 的最后一行——如果脚本在 JSON 之后还有其他输出,门控判断会失效。
macOS 上 Gateway 工作目录被重置
每次运行 hermes gateway install 都会从模板重新生成 plist 文件。解决方案是在每次 install 之后立即执行 plutil -replace WorkingDirectory 修补,然后 gateway restart。建议把这三步写成一个小脚本,每次升级 Hermes 后运行。
FAQ
Hermes Cron 和操作系统 crontab 有什么区别?
操作系统 crontab 只负责按时运行脚本,输出靠你自己处理。Hermes Cron 在此基础上集成了 Agent 推理层(可选开启或关闭)、多平台投递路由(Telegram/Discord/邮件等 15+ 目标)、context_from 任务链自动衔接上下游输出、wakeAgent 门控按条件跳过调用、以及 Skill 挂载实现工具增强。简单说:crontab 管调度,Hermes Cron 管调度 + 推理 + 投递 + 串联。
Hermes 定时任务的执行成本是多少?
取决于模式。no-agent 纯脚本模式零 LLM 调用,成本为 $0。带 wakeAgent 门控的任务,只在门控脚本判定需要唤醒时才调用 Agent——未唤醒的 tick 成本为 $0。常规 Agent 任务每次执行消耗一次模型推理费用,具体金额取决于你配置的模型和任务复杂度。三种模式组合使用可以把月度成本控制在极低水平。
context_from 任务链能串多少级?
没有硬性级数限制。你可以按 Job 1 → Job 2 → Job 3 → ... 任意延伸。每一级读取的是上游最近一次成功完成的输出,不会等待同一 tick 内正在运行的上游任务。实际建议控制在 3-5 级以内——超过 5 级的流水线通常意味着中间环节可以合并。
wakeAgent 门控脚本失败了会怎样?
非零退出码时,Hermes 视为错误状态并投递错误告警——坏掉的看门狗不会无声失败。wakeAgent 字段缺省时默认 true,即照常唤醒 Agent。设计原则是:宁可多唤醒一次,不能漏掉真正需要处理的事件。
定时任务可以访问项目的 CLAUDE.md 吗?
默认不可以——Cron 任务运行在隔离会话中,不加载任何项目级配置。通过 --workdir 参数指定项目目录后,AGENTS.md、CLAUDE.md、.cursorrules 会自动注入系统提示词,终端和文件工具也以该目录为工作目录。需要注意带 workdir 的任务在调度 tick 内串行执行。
如何在 macOS 上让 Gateway 后台常驻?
运行 hermes gateway install 注册 launchd 服务。关键踩坑点:每次执行 gateway install 会从内置模板重新生成 plist,覆盖手工修改的 WorkingDirectory。自定义工作目录时,每次安装后需用 plutil -replace WorkingDirectory -string '/your/path' 修补,然后 hermes gateway restart 生效。
[SILENT] 静默抑制是什么?
Agent 最终响应以 [SILENT] 开头时,投递被完全抑制——不发消息到任何平台。输出仍保存在本地供审计。解决定时任务的通知轰炸问题:只有真正需要关注的结果才会打扰你。注意失败的任务始终投递错误告警,不受 [SILENT] 影响。
Cron 和 Persistent Goals 能一起用吗?
可以组合。Cron 是时间驱动(按计划触发全新会话),Persistent Goals 是目标驱动(同一会话内跨轮次持续直到达标)。组合用法:Cron 按计划触发任务,内部设定 Goal 驱动迭代。例如每天 9:00 的 Cron 任务,Goal 设为「找到 3 条值得写推文的 AI 新闻」,Agent 自动迭代直到找齐——比单纯的「搜一次就完」更可靠。
延伸阅读
- Hermes Agent 完全指南——从零部署到日常使用的完整路径
- Hermes Agent Docker 部署实战——容器化部署方案
- Hermes Agent 成本控制实战——多模型策略和预算管理
- Hermes Kanban 多 Agent 编排——看板式多 Agent 协作
- Claude Code Hooks 新手指南——另一种事件驱动自动化的实现
下一步
- AI 编程实操课:Claude Code + Codex + Agent 工作流,覆盖一人公司、自媒体自动化、AI 副业全场景。237 篇实战教程 + 最佳实践 + 源码包,跟着做就出成果。国内版-FlowUS | 国际版-BMC
- YouTube 频道:翔宇工作流
- 微信公众号:搜索「翔宇工作流」






















