hermes教程-Cron 故障排除

作业未触发

检查 1：确认作业存在且处于活动状态

hermes cron list

查找作业并确认其状态为 [active]（而非 [paused] 或 [completed]）。如果显示 [completed]，则可能是重复次数已用尽——编辑作业以重置它。

检查 2：确认调度计划正确

格式错误的调度计划会静默地默认为一次性执行，或完全被拒绝。测试你的表达式：

如果作业触发一次后从列表中消失，这是一次性调度计划（30m、1d 或 ISO 时间戳）——属于预期行为。

检查 3：网关是否在运行？

Cron 作业由网关的后台 ticker 线程触发，该线程每 60 秒触发一次。常规的 CLI 聊天会话不会自动触发 cron 作业。

如果你期望作业自动触发，你需要一个正在运行的网关（前台使用 hermes gateway，或作为已安装服务使用 hermes gateway start）。对于一次性调试，你可以使用 hermes cron tick 手动触发一次 tick。

检查 4：检查系统时钟和时区

作业使用本地时区。如果你的机器时钟错误或时区与预期不同，作业将在错误的时间触发。验证：

date
hermes cron list   # 将 next_run 时间与本地时间进行比较

投递失败

检查 1：确认投递目标正确

投递目标区分大小写，并且需要配置正确的平台。配置错误的目标会静默地丢弃响应。

其他支持的平台包括 mattermost、homeassistant、dingtalk、feishu、wecom、weixin、bluebubbles、qqbot 和 webhook。你还可以使用 platform:chat_id 语法（例如 telegram:-1001234567890）定位到特定聊天。

如果投递失败，作业仍会运行——只是不会发送到任何地方。检查 hermes cron list 中更新的 last_error 字段（如果可用）。

检查 2：检查 [SILENT] 的使用

如果 cron 作业没有产生输出，投递会被抑制。如果代理响应包含 cron 静默标记 [SILENT]，投递也会被抑制。这对于监控作业是有意为之——但请确保你的提示词没有意外地抑制所有内容。

使用类似“如果没有任何变化，仅回复 [SILENT]”的提示词。避免要求代理在较长的解释中包含 [SILENT]，因为 cron 会将该标记视为抑制信号。

检查 3：平台令牌权限

每个消息平台机器人需要特定的权限才能接收消息。如果投递静默失败：

• Telegram：机器人必须是目标群组/频道的管理员
• Discord：机器人必须具有在目标频道发送消息的权限
• Slack：机器人必须被添加到工作区并具有 chat:write 范围

检查 4：响应包装

默认情况下，cron 响应会带有页眉和页脚包装（config.yaml 中的 cron.wrap_response: true）。某些平台或集成可能无法很好地处理此问题。要禁用：

cron:
  wrap_response: false

技能加载失败

检查 1：确认技能已安装

hermes skills list

技能必须先安装，然后才能附加到 cron 作业。如果缺少技能，请先使用 hermes skills install <skill-name> 或通过 CLI 中的 /skills 安装它。

检查 2：检查技能名称与技能文件夹名称

技能名称区分大小写，并且必须与已安装技能的文件夹名称匹配。如果你的作业指定了 ai-funding-daily-report，但技能文件夹是 ai-funding-daily-report，请从 hermes skills list 确认确切名称。

检查 3：需要交互式工具的技能

Cron 作业运行时禁用了 cronjob、messaging 和 clarify 工具集。这可以防止递归创建 cron、直接发送消息（投递由调度器处理）以及交互式提示。如果技能依赖这些工具集，它将无法在 cron 上下文中工作。

查看技能的文档，确认它是否能在非交互（无头）模式下工作。

检查 4：多技能排序

当使用多个技能时，它们按顺序加载。如果技能 A 依赖于技能 B 的上下文，请确保 B 先加载：

/cron add "0 9 * * *" "..." --skill context-skill --skill target-skill

在此示例中，context-skill 在 target-skill 之前加载。

作业错误和失败

检查 1：查看最近的作业输出

如果作业运行并失败，你可以在以下位置看到错误上下文：

1. 作业投递到的聊天（如果投递成功）
2. ~/.hermes/logs/agent.log 中的调度器消息（或 errors.log 中的警告）
3. 通过 hermes cron list 查看作业的 last_run 元数据

检查 2：常见错误模式

脚本的“没有那个文件或目录” script 路径必须是绝对路径（或相对于 Hermes 配置目录）。验证：

ls ~/.hermes/scripts/your-script.py   # 必须存在
hermes cron edit <job_id> --script ~/.hermes/scripts/your-script.py

作业执行时“未找到技能” 技能必须安装在运行调度器的机器上。如果你在不同机器之间移动，技能不会自动同步——使用 hermes skills install <skill-name> 重新安装它们。

作业运行但未投递任何内容 可能是投递目标问题（参见上面的投递失败）、没有输出，或响应包含 cron 静默标记 [SILENT]。

作业挂起或超时 调度器使用基于不活动的超时（默认 600 秒，可通过 HERMES_CRON_TIMEOUT 环境变量配置，0 表示无限制）。只要代理在积极调用工具，它就可以一直运行——计时器仅在持续不活动后触发。长时间运行的作业应使用脚本来处理数据收集，并仅投递结果。

检查 3：锁竞争

调度器使用基于文件的锁定来防止重叠的 tick。如果运行了两个网关实例（或 CLI 会话与网关冲突），作业可能会被延迟或跳过。

杀死重复的网关进程：

ps aux | grep hermes
## 杀死重复进程，只保留一个

检查 4：jobs.json 的权限

作业存储在 ~/.hermes/cron/jobs.json 中。如果该文件对你的用户不可读或不可写，调度器将静默失败：

ls -la ~/.hermes/cron/jobs.json
chmod 600 ~/.hermes/cron/jobs.json   # 你的用户应拥有它

性能问题

作业启动缓慢

每个 cron 作业都会创建一个新的 AIAgent 会话，这可能涉及提供商身份验证和模型加载。对于时间敏感的调度计划，请增加缓冲时间（例如，使用 0 8 * * * 而不是 0 9 * * *）。

重叠作业过多

调度器在每个 tick 内顺序执行作业。如果多个作业同时到期，它们会一个接一个地运行。考虑错开调度计划（例如，使用 0 9 * * * 和 5 9 * * * 而不是两者都在 0 9 * * *），以避免延迟。

大型脚本输出

输出数兆字节的脚本会拖慢代理，并可能达到令牌限制。在脚本层面进行过滤/总结——只输出代理需要推理的内容。

诊断命令

hermes cron list                    # 显示所有作业、状态、next_run 时间
hermes cron run <job_id>            # 安排在下一次 tick 执行（用于测试）
hermes cron edit <job_id>           # 修复配置问题
hermes logs                         # 查看最近的 Hermes 日志
hermes skills list                  # 验证已安装的技能

获取更多帮助

如果你已经按照本指南操作但问题仍然存在：

1. 使用 hermes cron run <job_id> 运行作业（在下一个网关 tick 时触发），并在聊天输出中查看错误
2. 检查 ~/.hermes/logs/agent.log 中的调度器消息和 ~/.hermes/logs/errors.log 中的警告
3. 在 github.com/NousResearch/hermes-agent 提交 issue，并附上：
   • 作业 ID 和调度计划
   • 投递目标
   • 你期望的结果与实际发生的情况
   • 日志中的相关错误消息

有关完整的 cron 参考，请参阅 使用 Cron 自动化一切 和 计划任务 (Cron)。