Hermes Agent Cron 定时自动化：任务链 + 预运行门控 + 零成本触发

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 工具执行。

调度格式

间隔和 Cron 表达式默认永远运行，可通过 repeat=N 限制执行次数。

投递目标

创建任务时用 --deliver 指定结果投递到哪里：

支持的平台超过 15 个，包括 WhatsApp、Signal、Matrix、飞书、企业微信、钉钉、Home Assistant 等。

生命周期管理

所有操作支持按名称查找（大小写不敏感），不用记十六进制 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] 开头回复

链接格式

多任务引用时，输出按列表顺序拼接——实现扇入（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——即照常唤醒 Agent
• context 字段可携带任意数据传递给 Agent，减少 Agent 重复查询
• 门控脚本的开销是系统级别（进程启动 + 脚本执行），对于 bash 脚本通常在 10ms 以内完成
• 同一机制适用于 Agent 任务和 no-agent 任务

成本对比

假设每 5 分钟轮询一次、每天 288 次 tick、每月 8,640 次：

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

核心概念

有些定时任务根本不需要 AI 推理——内存超标了告警一下、磁盘快满了通知一声、SSL 证书快到期了提醒一下。这些场景用脚本就能搞定，只需要一个靠谱的调度器和投递通道。

Hermes 的 no-agent 模式（--no-agent）正是为此设计：

调度 tick → 运行脚本 → 有输出？投递 / 无输出？静默

• 零 LLM 调用——零 token、零模型消费
• 同一调度器——与 Agent 任务共存，暂停/恢复/列表/日志/投递均通用
• 同一投递路由——脚本输出直接发送到 Telegram/Discord/邮件

脚本输出规则

关键设计：非零退出码始终投递错误告警。这意味着看门狗本身出了问题，你一定会收到通知。

创建方式

CLI 创建：

用 no-agent 模式创建一个内存看门狗，每 5 分钟检查一次，超过阈值时告警：

提示词：生成内存看门狗脚本和 Cron 任务

请帮我完成两步操作：

1. 生成 ~/.hermes/scripts/memory-watchdog.sh 脚本：用 free 命令计算内存使用百分比，超过 85% 时输出 "RAM {百分比}% on {hostname}"，未超过时不输出任何内容（空 stdout = 静默 tick）
2. 创建 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

典型适用场景

选择依据：Agent 还是 no-agent？

判断标准很简单——输出内容是否需要推理。如果脚本能直接计算出最终要发的消息（阈值比较、字符串拼接、数据格式化），用 no-agent。如果输出需要理解语义、做总结、写分析，用标准 Agent 模式。

两种模式共存于同一个调度器中，暂停、恢复、列表、日志、投递的管理命令完全通用，不需要为不同模式维护不同的工具链。

完整示例：磁盘空间告警

脚本每 15 分钟检查根分区和 /home 分区的使用率，超过阈值时输出告警文本触发投递，未超过时不输出任何内容——空 stdout 等于静默 tick。

提示词：生成磁盘空间告警脚本和 Cron 任务

请帮我完成两步操作：

1. 生成 ~/.hermes/scripts/disk-alert.sh 脚本：用 df -h 检查根分区 / 和 /home 分区，阈值设为 90%，使用 awk 提取使用率百分比，超过阈值时输出 "Disk {使用率} full on {挂载点}"，未超过时不输出
2. 创建 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"

绑定后的效果：

重要限制：带 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 个）

DevOps 与监控（3 个）

研究与情报（3 个）

GitHub 事件自动化（3 个）

业务运营（2 个）

多 Skill 工作流（2 个）

模板使用建议

不要照搬模板——它们是起点不是终点。根据你的实际需求调整：

1. 把模板中的通用占位换成你的具体仓库、频道、搜索关键词
2. 根据信息密度调整频率——竞品监控每天够用，内存告警可能需要每 5 分钟
3. 给每个任务加上 [SILENT] 逻辑——没事别发消息

与 Persistent Goals 的互补关系

Hermes 还有另一个自动化机制——持久目标（Persistent Goals），与 Cron 形成互补：

组合用法：Cron 任务按计划触发，内部设定 Goal 驱动迭代。例如每天 9:00 的 Cron 任务，Goal 设为「找到 3 条值得写推文的 AI 新闻」——Agent 自动迭代直到找齐。

调度器工作机制

理解底层有助于排障。Gateway 守护进程每 60 秒 tick 一次调度器：

1. 从 ~/.hermes/cron/jobs.json 加载任务列表
2. 检查每个任务的 next_run_at 是否到期
3. 为每个到期任务创建全新 AIAgent 会话
4. 可选注入挂载的 Skill
5. 执行提示词至完成
6. 投递最终响应到配置目标
7. 更新运行元数据和下次计划时间

文件锁 ~/.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 任务

请帮我完成两步操作：

1. 生成 ~/.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}（静默跳过），有告警输出告警文本（触发投递）

2. 创建 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

关键踩坑点：

1. hermes gateway install 每次执行都会从内置模板重新生成 plist，覆盖你手工设的 WorkingDirectory。每次升级或重装 Gateway 后必须重新修补。
2. Gateway 的 WorkingDirectory 决定了所有 Cron 任务中相对路径的基准。设置为知识库根目录后，任务中 read_file('inbox/todo.md') 直接落在知识库里。
3. 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",
)

推荐搭配

安全与存储

安全扫描

定时任务的提示词在创建和更新时自动扫描：

• 提示注入模式（Prompt Injection）
• 凭据泄露模式
• 不可见 Unicode 技巧
• SSH 后门尝试

包含以上模式的提示词会被直接阻止。

任务存储

任务存储使用原子文件写入（写入临时文件后重命名），防止并发损坏。

自包含提示词：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 新闻，筛选高质量内容，格式化为推文草稿
• 竞品监控 → 分析 → 通知：监控竞品仓库活动，分析影响，有重大变化时通知
• 安全扫描 → 分类 → 告警：运行依赖审计，按严重程度分类，只通知高危漏洞

社区最佳实践总结

与其他自动化方案的对比

Hermes Cron 的核心优势是 Agent 推理与调度的原生融合——不是「脚本写完了调个 API」，而是「AI 直接理解任务语义并决策输出」。

排障指南

任务不执行

最常见的原因是 Gateway 没有运行。检查步骤：

# 检查调度器状态
hermes cron status

# 如果显示未运行，重启 Gateway
hermes gateway restart

# macOS 上确认 launchd 服务状态
launchctl list | grep hermes

任务执行了但没收到消息

按顺序排查：

1. 检查投递目标是否正确：hermes cron list 查看任务的 deliver 字段
2. 检查输出是否被静默：查看本地输出 ~/.hermes/cron/output/{job_id}/ 最近的文件，确认是否以 [SILENT] 开头
3. 检查平台连接：确认 Telegram/Discord 等平台的凭据和频道配置正确
4. 手动触发一次：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 频道：翔宇工作流
• 微信公众号：搜索「翔宇工作流」