绿勾亮了，工作还没交到人手里
9 点，早会摘要准时启动。9 点 07 分，历史记录显示运行结束。9 点半，同事问：今天怎么还没消息？这时再按一次“立即运行”，可能补上结果，也可能把同一条摘要发两遍。
一项 AI 定时工作需要四份证据：确实启动了、读到了该读的材料、做出了合格结果、结果到了指定位置。某一步的成功标记，证明不了后面几步。
Anthropic 在 10 月 8 日发布的自动化参考实现把这个问题讲得很具体：云端 Agent 定时读 Slack 和 GitHub，记住进度，再交付摘要。本文据此做独立分析，用一个原创、虚构的早会案例讲清恢复方法。它不是 Managed Agents 的实际部署记录，也不是 Onevium 性能测试。
先找到最后一份可靠证据
排查时，先问哪一步有证据。下面这张表用于分析团队报告，不对应某款产品的状态名称。
| 检查位置 | 要找的证据 | 找不到时先做什么 |
|---|---|---|
| 启动 | 触发记录、运行编号 | 检查时间、时区和执行环境 |
| 读取 | 各来源的覆盖区间、失败页 | 保留没读到的缺口 |
| 产出 | 已保存、事实可核对的报告 | 接着完成未交付工作 |
| 送达 | 回执，或目标位置的对应消息 | 查明现状后再决定重发 |
以 Claude Managed Agents 为例，定时部署文档把部署尝试和创建出的会话分开记录；有些错误发生在会话创建之前。恢复暂停的部署不会补跑错过的触发，实际执行时间也允许一定抖动。因此，设了一个准确时间，并不代表那个时间一定有完整报告。
不同产品的调度行为不同。这四个问题可以迁移，具体原因仍要查正在使用的产品文档。
昨天没读到的那一段，今天还要接上
设一个虚构场景：工程团队每天北京时间 09:00 看摘要。昨天已成功检查到 09:00，今天任务延迟到 09:25 才开始。如果它读取“最近 24 小时”，起点就变成昨天 09:25。昨天 09:10 出现的一条消息，恰好落在两轮之间的空隙里。
所以，进度要按来源记。代码仓读完了，团队群却连接失败，两者就应该停在不同位置。一个“上次运行：今天”的字段，装不下这种差别。
读完还包括翻完必要的分页。繁忙来源只返回最新 50 条时，不能据此声称整个区间都看过。接口支持游标或分页就继续读取；做不到则留下明确缺口。按时间读取时，还要用稳定的条目编号去重，并考虑相同时间戳和迟到数据。
我们建议把记录分成三件事：
- 读取覆盖： 哪段时间、哪些分页确实检查过。
- 条目决定： 哪些发现进入报告，哪些有理由舍弃，哪些仍待处理。
- 交付状态： 哪份已保存的报告，在目标位置获得了确认。
没有可靠待处理队列时，交付确认前应保守地保留来源检查点。仅因为“写好草稿”就推进它，可能把草稿里的发现一起丢下。有可靠队列的系统可以单独推进读取进度，前提是每条未报告内容仍能被下一轮找回来。
最尴尬的是：发送超时了，消息可能已经到了
假设报告已经保存，09:31 目标群也收到了消息，但回执在途中丢了。Agent 看到的只有请求超时。
现在有两种可能：消息已经发出，或者根本没发出去。直接重发，就是在没有证据时猜一个答案。
Anthropic 的参考实现会记录发送结果不明的状态，并在确认送达后推进报告记录。我们建议再给每一期报告一个稳定编号，发送前先登记尝试。下面是原创的恢复示意，不是产品界面：
保存报告与本期编号
↓
登记本次发送尝试
↓
发往已授权的目标
↓
拿到回执了吗？
是 → 记录消息编号
否 → 保持送达未明
↓
到目标位置核对本期编号
找到一条 → 补登记回执
仍不清楚 → 暂停并交给负责人
虚构的这一期叫 engineering-brief:2026-10-12:Asia-Shanghai。核对后发现群里只有一条对应消息，正文也一致，就记录它的消息编号，补完台账。无法查看目标位置时，保留“送达未明”，由负责人决定怎么恢复。
只查同名标题仍有漏洞：两个并发任务可能同时查到“还没有”，然后各发一遍。更可靠的系统会让同一期交付排队执行，或使用目标接口支持的幂等键——同一个请求编号重复提交，只产生一次对应结果。提示词里写“不要重复”提供不了这种原子保证。目标系统不支持时，就应说明能力边界，并留下可核对的发送记录。
报告到了，也可能只完成了一半
9 点 40 分，团队看到这样一份虚构结果：
发布摘要 · 10 月 12 日
R-17 已在初次检查后合并，不再提醒评审。
R-23 仍需发布负责人决定。
覆盖缺口：本轮无法读取团队群；代码仓已完整检查到 09:25。
这是一份有用的部分结果。若把它标成“一切正常”，问题就被藏起来了。把覆盖和送达分开：覆盖：部分完成，送达：已确认。团队群的检查点仍停在原处，下轮恢复访问时接着补。
补读会遇到看起来已经旧了的消息。要判断它现在是否仍影响决策：不能因为日期是昨天就漏掉，也不能把补回的消息一股脑重新发群。报告 R-23 仍待处理之前，再核对它的当前状态。交到人手里的内容，应反映交付时的事实。
如果草稿里所有发现都已过时，决定整份舍弃，也要记录理由。否则下一轮无法区分“有意筛掉”和“工作丢了”。
便宜地停下来，也需要说清楚停在哪
预算限制也容易让状态产生误解。Claude Managed Agents 的预算文档说明：达到按公开价格计算的限额后，会话会暂停；已经发出的模型请求仍可完成，因此最终数值可能略超阈值。定时部署把预算复制给每一次运行，它不是整个月的累计额度。
设计自己的流程时，先决定预算耗尽后必须留下什么：最后核实的来源位置、已保存的发现、草稿位置，以及尚未查明的发送尝试。把保存这些信息放在可选润色之前。如果平台更早停止执行，下轮就从最后一份可靠记录恢复，不能把尚未落盘的一步当成完成。
费用和完成情况要一起看。十次便宜的运行，若每次都停在有效结果之前，就没有交付十份报告。先查反复绕圈和任务范围是否过大，再决定是否提高限额；改预算仍应由负责人明确决定。
交接记录，要让明天换个人也能接着做
有用的恢复记录不需要很长，但要能指向下一步。下面是虚构的记录样式，不是某个 API 的配置文件：
本期：engineering-brief:2026-10-12
时区：Asia/Shanghai
代码仓已读至：09:25
团队群已读至：前一天 09:00
报告：已保存的第 2 版草稿
覆盖：部分完成，团队群不可访问
送达：未明，发送请求超时
下一步：查看目标位置，确认前不重发
负责人的要求与执行者的观察也应分开。“不汇总发布说明”是一条规则，“今天群消息读取失败”是一条观察。允许执行者修改规则，让失败看起来像成功，就失去了原本的验收标准。
来源使用只读凭据，交付端只开放必要范围，能让这种区分落到真实权限上。工单或网页里出现的文字只是材料，不能授权新增收件人或扩大操作。保存下来的笔记同样需要审视，避免昨天读到的不可信内容变成明天执行时的指令。
先试一次不顺利的运行
选一个测试目标，使用虚构记录，主动安排下面这些情况。这是建议的验收练习；表里写的是预期行为，没有声称测得了成功率。
| 刻意制造的情况 | 应该看到的结果 |
|---|---|
| 晚启动 25 分钟 | 中间缺口仍被覆盖 |
| 一个来源不可访问 | 其他证据可用，缺口仍明确 |
| 消息已送达，但返回超时 | 重发前先核对目标位置 |
| 写完草稿后条目状态变化 | 最终报告反映最新状态 |
| 在交付前停止 | 下轮能找到并恢复已保存工作 |
| 同时启动两次 | 同一期只允许一次交付，或明确暴露限制 |
不用一开始就模拟分布式系统的全部故障。先挑最伤害这项任务可信度的一种：提醒任务可能怕重发，监控摘要可能怕把失联写成平安无事。
使用 Onevium 的团队，可以从现有定时任务教程开始：验证一次手动运行，查看会话与历史，再到实际通知目标核对结果。本文的检查点和发送核对方案属于工作流设计建议，不代表 Onevium 已自动提供这些记录或交付保证。
另一位同事能说清它读了什么、交付了什么、停下来怎样接着做，这项定时工作才有条件扩大使用。接着可以读 Schedule 与 Channel、怎样审查 Agent 执行轨迹，以及怎样衡量 AI 工作流的价值。