第十章：没有新消息，任务怎样继续
简报已经能按要求完成，你希望下周再检查一次官方变化。这里新增的首先是触发与调度问题：什么时候启动、使用什么配置、结果放在哪里，以及失败后是否应该重做。
有了定时任务，并不等于拥有一个持续思考的 Agent。调度器可以启动模型驱动任务，也可以只执行确定性的脚本。
10.1 把触发、执行与投递拆开
假设周一到点了，调度器成功启动任务；随后网络失败，模型没取得材料；最终错误说明也可能因消息渠道不可用而没送到。这是一条包含三种不同状态的链路。
| 环节 | 需要确认的事 |
|---|---|
| 触发 | 这次运行是否已受理，属于哪个任务与触发时刻？ |
| 执行 | 是否取得需要的资料，如何结束，有哪些限制？ |
| 保存 | 是否留下可找回的输出和状态？ |
| 投递 | 输出被哪个渠道接收，是否真的送达？ |
“已在后台启动”只能说明启动或受理情况，不能替代后续终态。
10.2 Hermes 的定时任务可以带方法，也可以不用模型
该版本的 Cron 能组织一次性或重复任务，附加技能，并通过配置的方式投递结果。正常 Agent 任务会在相应运行上下文中执行，不能假设它自动继承你此刻聊天里的所有临时细节。
如果任务只是定期读取一个已知接口并原样保存结果，也可能用脚本方式完成。选择模型驱动任务，是因为需要解释与调整；选择确定性流程，是因为规则已经足够明确。第一章的区分在这里仍然适用。
所以，为简报任务保存稳定的目标、来源范围和交付标准，比依赖“它应该还记得上次怎么做”可靠。可以复用第七章的技能，但技能也要能独立说明输入和判断条件。
10.3 恢复之前，先确认哪一步已经发生
一个典型难题是：执行完成了，投递状态却不明确。若直接重跑整项任务，可能重复生成文件或重复发送结果。这涉及幂等性：同一次操作重复处理时，怎样避免产生多份不该重复的副作用。
Hermes 的该版本文档描述了运行标识、持久结果与投递交接的恢复约定，并对中断和未知状态保留审核边界。学习重点不是背状态名，而是看它怎样区分“没做”“做完了”“是否送达还不确定”。
教学示意：如果已有本次简报文件和对应运行记录，只是投递失败，恢复可以优先处理投递；如果无法确认敏感操作是否发生，则不应盲目重复执行。
不写代码的小练习
构造“任务已完成，但投递状态未知”的记录。列出哪些证据能证明执行完成、哪些只能证明消息已受理，再说明你会恢复哪一步，怎样避免重复副作用。
本章要点
- 调度负责触发，Agent 负责执行中的判断，两者可以组合也可以分开。
- 触发、执行、保存和投递需要分别确认。
- 后台任务需要完整的目标、配置和方法，不能依赖隐含聊天上下文。
- 恢复应先核对已发生的操作，防止重复副作用。
理解题
1. 定时任务列表显示“已运行”，却没有收到简报，可能在哪里失败？
可能执行未完成、结果未保存，或投递路径失败。先查具体运行和交接记录，再判断是否需要重跑任务或仅重试投递，不能只依赖一个笼统状态。
2. 每小时抓取固定 JSON 并原样保存，需要 Agent 吗？
未必。规则明确且没有解释性决策时，脚本与调度器可能更简单。只有出现资料解释、条件变化或需要调整行动等需求时，再考虑引入模型驱动部分。
对照官方实现
时间上可以延续任务后，下一章讨论另一种扩展：把一项工作交给多个 Agent。