把 Hermes Agent 变成可靠的定时任务：Cron、告警与人工确认
透明说明：本文由 AI 辅助整理，文中的命令和结论已经结合实际运行环境检查，发布内容仍由作者负责。
定时执行不等于可靠运行
一次性使用 Agent，只要当场检查结果即可；定时 Agent 却要面对调度器停止、上游没有数据、脚本报错、输入污染，以及失败后长期无人查看等问题。
所以，真正要解决的不是“每天自动问一次模型”，而是把任务拆成一条可观察、可暂停、可复核的流水线。
本文使用的实际场景，是让 Hermes 定时运行一个公开编程挑战扫描器。扫描器只读取公开元数据，排除报名已经截止、奖金为零、方向不相关和明显用于测试的条目，然后把少量结构化候选交给 Hermes 生成中文摘要。
它不会自动注册、接受条款、提交代码，也不会读取账户凭据或支付信息。这类低权限任务，很适合作为 Agent 定时任务的起点。
把“发现机会”和“执行操作”隔开
我的处理流程分为五层：
- Cron 只负责按计划触发任务，不承诺业务一定成功。
- 普通脚本读取公开数据，并完成确定性的过滤。
- Hermes 只接收必要的结构化字段。
- 每次运行都留下可以查询的执行记录。
- 候选结果进入人工审核，而不是直接触发报名或提交。
这个设计有两个直接好处。
第一，模型不需要读取完整的远程描述，能够缩小提示注入的影响范围。远程标题、标签和链接都只被当作数据，不能改变 Agent 的权限和任务目标。
第二，即使模型判断错误，系统也没有外部账户写权限。错误最多停留在“建议人工查看”这一层，不会直接变成报名、付款或者对外消息。
最终的规则阅读、AI 使用许可确认、报名和作品提交，仍然由人完成。
先查看本机帮助，不要猜参数
Hermes 的 Cron 功能提供任务创建、查看、暂停、恢复、手动触发和执行历史等能力。不同版本的参数可能发生变化，所以应先检查自己安装版本的帮助信息：
hermes--versionhermescron--helphermescroncreate--helphermescronstatus hermescronlist hermescronruns在创建任务之前，可以先把需求写成与工具无关的配置草稿：
job: schedule: "<人工确认的 Cron 表达式或执行间隔>" command: "bash ./hermes/opportunity_scout.sh" output: "<本地、受控的日志位置>" on_failure: "写入告警队列，等待人工处理"然后再根据本机hermes cron create --help，把这些字段映射成真实参数。这样可以避免从过期教程复制命令。
业务脚本本身也应先脱离 Cron 单独验证：
npmtestnpmrun checknpmrun scannpmrun scan ----humanbashhermes/opportunity_scout.sh推荐顺序是：
- 运行测试；
- 做语法和静态检查；
- 查看人类可读的扫描结果；
- 最后才创建定时任务。
任务创建完成后，可以做一次受控触发，然后立即检查执行历史。不要等到第二天才发现脚本根本没有正常运行。
只读监控与告警
一个定时任务至少需要监控三个信号：
- 调度器是否仍在运行；
- 任务是否存在，并且没有被意外暂停；
- 最近一次执行是否成功。
最简单的只读检查脚本可以是：
#!/usr/bin/env bashset-euopipefail hermescronstatus hermescronlist hermescronruns这段脚本只负责收集状态，不会修改任务。
需要注意的是，“脚本执行成功”与“发现了有价值的机会”是两件不同的事。例如，扫描结果为空，可能只是当天没有任何条目通过奖金、截止时间和方向过滤，并不代表系统故障。
我会把告警分成三类：
- 调度器停止、脚本连续失败：需要尽快处理；
- 扫描成功但没有候选：只记录，不告警；
- 出现符合条件的候选：通知人工查看。
候选本身永远不会直接触发账户操作。
常见失败场景
1. 调度器没有运行
任务配置虽然存在，但永远不会触发。此时应先使用status检查调度器，再查看任务列表和执行历史，而不是反复删除重建任务。
2. 任务被暂停或配置发生漂移
定期用list对照预期配置。恢复任务前先确认暂停原因，因为暂停往往是人为止损，而不是普通故障。
3. 上游返回空数据
空数据不一定是错误。测试、接口请求、过滤结果和业务候选数量需要分开判断。不要因为暂时没有候选，就自动放宽奖金或截止时间条件。
4. 上游字段发生变化
字段变化导致解析失败时，任务应明确失败并发出告警，不能悄悄忽略字段或把异常数据当成正常结果。
5. 远程文本夹带指令
挑战名称、职位描述、网页标题和链接都属于不可信数据。不要让这些内容改变系统提示、执行命令、读取本地文件或扩大工具权限。
6. 为了跑通任务而自动批准 Hook
无交互环境中，未经审核的 Hook 不应该被默认批准。更稳妥的方式是先由人检查 Hook 内容，在测试环境运行，再决定是否允许定时任务使用。
7. 直接升级正在运行的任务
发现新版本不等于必须立即升级。应先阅读变更说明，在测试环境重新运行测试、静态检查和只读扫描，再安排升级与回退。
自动化应该停在哪里
适合交给定时任务的工作包括：
- 读取公开信息；
- 做确定性过滤；
- 生成结构化摘要；
- 查询任务状态；
- 保存本地执行记录；
- 创建等待人工查看的提醒。
不适合直接自动执行的工作包括：
- 登录第三方账户；
- 自动报名、投标或提交作品；
- 自动接受平台条款；
- 自动评论、私信或联系用户；
- 读取浏览器 Cookie、账户令牌和支付信息；
- 修改付款、结算或其他不可逆设置。
即使扫描器找到了有奖金的候选，也只能说明“值得人工检查”。人仍然需要阅读完整规则，确认平台是否允许 AI 辅助，并明确批准后续动作。
Cron 的价值，是稳定地产生证据和提醒，而不是制造“完全无人值守赚钱”的幻觉。
什么时候适合使用这套方法
这套设计适合公开信息巡检、定期质量检查、内部摘要和任何“结果先进入人工队列”的低风险任务。
如果任务必须拥有写权限，或者会产生付款、提交、发信等外部影响，就需要重新设计权限隔离、审批、审计和回滚机制，不能直接沿用这个只读示例。
对刚开始使用 Agent 的人来说，最好的第一步不是追求全自动，而是先做到：
自动收集，自动整理，自动提醒；人工确认，人工发布，人工承担最终责任。
