第十二章：定时任务怎样触发、执行和投递
简报现在有明确的身份、方法和交付对象。你希望“每周一早上整理一次”，不用临时再发消息。把这句话存下来，还缺什么？
系统必须有人持续看时间，知道任务属于哪个 Profile，届时取得材料、组织输入、执行，并留下结果。假如草稿已生成但聊天平台离线，不能把它当成“周报没写”，也不能假装用户已经收到。
本章把没有新消息时的一次任务拆成生命周期。产物是一张任务定义卡，以及触发、运行、保存、投递各阶段的状态表。
12.1 调度器决定何时开始，Agent 决定如何完成
调度器是按时间或事件启动工作的程序。Cron 原本是一类时间调度约定，在 Hermes 中也用来统称相关任务功能。它不需要模型每秒想一遍“到周一了吗”。
时间规则和当前时刻的比较可以由确定性程序完成。轮到任务时，再启动需要判断的模型与工具循环。这样把持续等待和实际推理分开，避免让一个模型会话一直占着资源等时间过去。
Hermes 支持单次延迟、间隔、固定时间表达等形式，也有事件触发路径。底层触发器可以有不同提供者，实际任务执行与交付仍有共同的生命周期。替换时钟，不应重新实现整套简报逻辑。
还有一个有用的反问：每次触发都需要 Agent 吗？如果工作只是运行固定程序并原样交付结果，Hermes 也支持不经过模型的任务方式。需要核对相互矛盾的自然语言材料，才有理由加入判断循环。
12.2 任务定义必须独立于“刚才那段聊天”
定时任务不是让模型在周一继续记住周五的最后一句话。Hermes 的计划运行可以在新的 Agent 会话中开始，不自动带入创建任务时的整段对话。
因此，任务定义需要包含稳定目标，或能明确找到所需材料。第九章的方法可以作为技能绑定并在运行时加载；第八章的偏好也应按实际记忆机制提供。不能只写“照旧整理一下”，却没有保存“旧”指什么。
| 任务卡项目 | 简报教学设计 | 缺失的后果 |
|---|---|---|
| 归属 | 个人简报 Profile | 读到错误记忆、账号或技能 |
| 时间与时区 | 用户确认的每周一早上 | 不同运行环境对时间理解不同 |
| 输入与方法 | 本周材料位置、简报技能、去重与冲突规则 | 新会话没有足够依据 |
| 完成标准 | 最多三件，不足说明，保留条件 | 为凑数重复或编造 |
| 工作位置 | 如需项目文件，明确所在目录 | 找不到方法或写错位置 |
| 交付方式 | 先保存草稿；获授权后送到指定目标 | 生成与发送边界不明 |
Hermes 可以为任务绑定工作目录，将相关项目说明和文件工具的工作位置与本次运行关联。它解决“从哪里找项目”的问题，不能替代操作系统权限或对外发送的授权。
12.3 一次到点运行怎样展开
回到统一任务时序，差别发生在开头：这次提出目标的是已保存任务，而不是一条刚到的聊天消息。后续仍要解析模型、准备输入、调用工具、处理反馈与交付。
Hermes 的执行前检查会核对模型凭据、绑定技能、工作位置等条件。已知配置不满足时，可以先阻止运行并记录配置阻塞，避免到模型调用中途才发现基础资源不存在。
正式运行时，调度系统需要认领本次执行，防止相邻检查周期重复启动同一项工作。对于长任务，它还要跟踪运行归属；只有仍有权完成记账的运行，才可以更新对应结果。这里的“认领”是一种状态协调，不是模型写一句“我开始了”。
运行结束后记录产物和状态，再处理配置的投递路径。接收端可能在线、离线或拒绝消息，因此投递可以进入单独队列。把交付拆出来，才有条件在发送失败后保留已经完成的草稿。
12.4 哪个模型、哪个方法，是创建时定死的吗
不一定。Hermes 的任务可以跟随全局模型选择，也可以有任务或调度层面的配置。未固定的任务，在下次触发时可能采用新的默认模型。绑定的技能也需要按实际加载规则取得内容。
跟随最新配置便于集中维护；固定选择有利于控制变化，但会增加单独更新和失效处理的负担。两者都不能省略第十章的兼容与能力检查。
例如，你周五换了主模型，周一的简报可能首次在该模型上运行。如果从未测试它的工具调用和事实边界，后台任务就成了第一次试验。更稳妥的维护方式是保存上次运行的实际模型、技能变化与结果范围，再决定是否允许新组合用于投递。
这是一条设计建议，不表示 Hermes 会自动锁住所有方法版本或为每次配置变化提供结果等价保证。
12.5 电脑关机以后，不能用一个“自动补跑”概括
本地调度依赖相应服务实际运行。关闭聊天窗口不一定关闭网关；关闭电脑则会使本机无法按时处理。再次启动以后，还要判断哪些时间点错过、哪些已经执行过。
Hermes 对错过的周期有恢复与记账规则，包含迟到运行、合并积压或按设置跳过等情况。一次性任务与周期任务也有不同处理。不能假定离线五周后必定补发五份简报。
为什么不一律补齐？旧的“今天消息”可能已经过期，集中执行会产生突发开销和大量通知。为什么又不一律跳过？某些检查确实仍然有价值。调度设计需要区分“每个时间点都不可遗漏”和“恢复后了解当前状态即可”。
对于每周新闻，通常应先明确恢复时的资料时间范围。一次当前简报不能冒充五次历史检查，已错过的时段也不能悄悄被标成按时完成。
12.6 生成状态和投递状态分别看
| 观察到的状态 | 可以判断什么 | 还不能判断什么 |
|---|---|---|
| 配置阻塞 | 正式任务未按正常路径开始 | 修复后是否还能取得原时间范围资料 |
| 任务运行失败 | 本次没有正常交付可用产物 | 已执行的工具是否产生过外部变化 |
| 产物已生成、投递排队 | 内容阶段结束，交付尚未结算 | 接收人是否已经看到 |
| 投递失败 | 输出未按预期到达目标，或结果无法确认 | 是否应该重做内容或直接重发 |
| 投递已结算 | 系统按相应交付规则记录了结果 | 人类是否阅读、内容是否事实正确 |
Hermes 的记录区分运行错误、配置阻塞、排队中和投递失败等状态。具体成功记号还要结合是否设置目标、是否有抑制投递等情况解释，不能把一个状态词当成“读者已收到并认可”的证明。
尤其是发送后连接中断：消息可能已到达，确认却没有回来。这时盲目重发可能重复。第十五章会用这个例子解释为什么需要“结果未知”这一类状态。
12.7 从手动到后台，先验证哪些事情
先用相同任务卡手动触发，检查新会话是否能独立找齐材料与方法；再在受控时间验证调度；最后在测试目标确认投递。三个试验分别覆盖内容、时间和渠道，不能用其中一个代替全部。
案例目前是一份架构设计，没有创建真实简报任务或外发消息。它新增的成果，是“任务定义不依赖当前聊天”以及“一次执行有自己的结果记录”。这些成果会在故障与评估章节继续使用。
本章要点
- 触发器解决何时开始，任务执行解决怎样完成，结果投递解决交给谁。
- 新会话需要独立任务定义和可加载材料，不能依赖“刚才那段聊天”。
- 执行归属、错过时间点和投递状态需要明确记账，不是让模型自己承诺。
- 修复发送故障通常不必重做整份简报；结果未知时更不能直接假定发送失败。
理解题
1. 定时任务回复“找不到简报方法”，而交互对话昨天还能使用，先查什么？
查任务实际所属 Profile、绑定技能、工作目录和新会话的输入。昨天的对话可能已展开方法正文，定时运行没有继承整段聊天。先定位加载与归属，不能直接归咎于模型遗忘。
2. 草稿已保存，平台发送失败，应否重新搜索所有材料？
未必。先确认产物完整、来源与时间范围仍适用，再处理交付阶段。重新生成可能增加开销、引入不同结果；但若原产物缺失或已过时，也不能未经核对就重发。
3. 离线三周后只运行一次，能否据此说调度器丢了两次任务？
需要结合错过时间点的策略和记录。系统可能合并积压后执行一次，也可能明确跳过。应检查每个时段如何记账，不能用“当前只看到一次运行”推断三次都已完成或全部被静默丢弃。
下一章讨论一次任务内部的分工：什么时候值得让另一个 Agent 加入。