回答要点
先确认外部状态，再从尚未完成的部分继续；“没收到成功回复”不等于“操作没有发生”。 读取资料失败通常容易重试，但创建记录、发送内容或提交写入时，盲目重来可能产生重复结果。
完整解答
AWS 的官方工程文章用创建云资源说明了这个问题：请求超时后，调用方可能不知道资源是否已建成。它介绍的“幂等”机制，是让同一请求按指定标识重试时不产生额外副作用；关键在服务端支持和请求标识，不能只靠 AI 说一句“不要重复”。官方原文
恢复时可以把状态分成三类：有回执或当前结果可确认的“已完成”，明确未执行的“未完成”，以及请求已发出但结果不明的“待核实”。待核实部分优先用记录编号、版本、操作日志或实际内容查询；如果操作原本支持幂等重试，就遵守该接口的标识和有效期规则。
例如：
继续刚才的批量建档。先查询已创建记录，按原始条目编号与回执核对；已有且内容正确的跳过，确认未创建的继续处理。结果不明的先查询，不直接新增一份；无法查清时，只暂停受影响条目并说明，其他可确认部分继续。
这份状态清单应由 AI 根据工具结果整理，用户不必手工重建全过程。对于文件，检查的是内容与保存位置；对于外部记录，检查的是目标系统中的真实条目，不能用聊天里的“完成”替代。
恢复结束后，还要核对输入条目与输出条目是否一一对应、是否遗漏或重复。工具回执证明一次调用发生了什么，最终状态检查证明整项任务现在是否正确；两者共同支撑“已恢复完成”的结论。