定时任务中途失败，怎样让Agent只补缺失的步骤？

资料已经收集，报告也已生成，最后的写入却没有返回结果。重新执行整个任务，可能重复生成报告或重复发送；直接跳过，又可能漏掉真正没有完成的动作。

失败恢复首先要回答的不是“怎样再跑一次”，而是“上次到底完成了什么”。可以用 Buda 的持久化 Drive 和定时任务指令搭建检查点方法，让每轮先检查已有成果，再决定补做哪一步。这个方法需要团队定义状态和核验依据，不能把一个文件当成事务锁，也不能承诺绝对只执行一次。

先找到同一份业务工作

Buda Automations可以按 Cron、Interval 或 Once 发起工作，并保留运行状态、时间及关联会话。运行记录帮助定位一次执行；业务工作可能跨越多次执行。

因此，给每份交付物定义稳定的业务身份：所处理的对象、业务日期或数据区间、交付类型及版本。第二天补跑昨天的报告，仍然属于昨天那份工作。重试时间可以更新，业务日期不能跟着变成今天。

如果输入发生变化，明确决定是补齐原版本，还是创建修订版，并保留替代关系。否则，两个内容不同的文件可能被误当作一次任务的同一结果。

把完成证据放在每一步旁边

检查点不是一份只有勾选框的清单。它至少要指向输入、产物、核验结果和外部动作的实际凭据。

可以把这些内容保存在工作目录的清单文件中，让 Agent 每次读取。记录结构是团队设计的约定；Drive 提供的是文件持久化能力，不会自动替团队校验业务状态。

失败、未开始和结果未知必须分开

“未开始”意味着没有发起动作，可以在当前授权内执行。“已失败”需要检查错误原因是否已消除，再从必要位置重试。

最容易出问题的是“结果未知”：请求已经发出，但连接中断，没有拿到明确响应。此时不能直接将状态写成失败。服务器可能已经保存了记录，消息也可能已经送达。

先用目标系统支持的查询方式检查实际结果。若 API 提供幂等键，可按其正式契约使用同一个键；若目标系统没有对应机制，就明确记录未知状态，由有权限的人决定下一步。一个本地的“准备发送”标记，不足以证明发送成功；没有本地成功记录，也不足以证明目标端没有结果。

恢复顺序从核验开始

第一步，读取原业务身份和输入版本，找到对应的检查点与产物。

第二步，打开已经存在的文件，检查内容是否完整、可读、对应本次输入。不要只看文件名和修改时间。

第三步，查询已发起外部动作的目标端状态。先处理未知结果，再决定重试。若上一轮已经完成交付且没有新输入，输出已完成的核验结果即可。

第四步，列出真正缺失的阶段，只补这些阶段；如果上游输入变化影响下游内容，重新生成受影响部分，并保留旧版本。

第五步，保存本轮实际结果与剩余问题。没有完成的阶段保持未完成，不能用“本次运行结束”覆盖业务状态。

让下一轮一开始就读恢复规则

把恢复方法写进定时任务的执行指令或适用 Skill，才能让后续运行知道先看什么。可采用下面这段起始要求：

先读取该业务日期和对象对应的检查点、原输入版本及已有产物。核验各阶段完成证据，只继续缺失或明确失败且可重试的部分。外部动作超时或结果未知时，先查询目标端；无法核清则停止该动作并报告。保留原业务日期、原始文件和版本关系。发现另一轮正在处理同一工作时，先核对归属，不能覆盖其进度。最后写入实际完成状态、产物入口及剩余问题。

反复使用时，可以在 Buda AI 的 Marketplace 搜索并安装合适的 Skill，再检查是否覆盖这些规则。安装 Skill 本身不会让目标系统获得幂等写入能力。

两轮同时运行怎么办？

先约定谁拥有当前工作，以及归属依据在哪里。共享文件可帮助人和 Agent 看见状态，但不能仅凭一个文件名就宣称获得了可靠并发锁。对关键外部写入，应使用目标系统支持的版本校验、幂等或其他并发控制机制。

如果看到另一轮仍在处理，不要为了赶进度直接抢占。核查其当前产物和状态；无法确认归属时，保留现场并报告具体冲突。相比重复执行一次不可撤回的动作，明确的暂停更容易恢复。

用三个状态检查恢复方法

先在低风险内部任务上检查：已有完整文件时，Agent 是否真的打开并复用；某阶段明确失败时，是否只补受影响部分；外部结果未知时，是否先查目标端而不是重新发送。这些是建议的验收条件，需要保留实际输入与输出后才能称为通过。

定时任务的价值来自持续产生可用结果。把部分完成和未知状态保存清楚，下一轮才能接着工作，而不是每次都从“重新来一遍”开始。