AI多步骤任务执行到一半中断，恢复的第一步是定位中断点并盘点已经产生的副作用，再判断原因属于偶发失败还是流程缺陷，最后在断点续跑、检查点重放和整体重做之间选择。本文按“界定现场—验证原因—选择处置—验收预防”的顺序给出可执行步骤，适用于由AI串联多个工具或步骤、且部分步骤会写入外部系统的任务场景。
要点总览（TL;DR）
- 恢复的第一步是定位中断点并盘点已产生的副作用，直接点重试可能让已成功的写操作再执行一次。
- 用可复现性区分偶发失败与结构性缺陷：同输入重试即成功倾向偶发，同一步骤反复失败倾向流程设计问题。
- 按条件选择恢复方式：无副作用或已幂等时断点续跑，有可信中间产物快照时检查点重放，上下文丢失或产物不可信时整体重做并先清理残留。
- 有副作用的步骤在外部写入未确认生效前不重复提交，已生效的动作做去重或补偿处理。
- 恢复后同时做结果验证与过程验证，并把检查点、幂等键、超时与重试上限、告警责任人落到流程改动上。
中断发生在哪一步：先界定症状与影响范围
中断恢复最忌讳直接点“重试”。在多步骤任务里，重试可能让已经成功的写操作再执行一次。第一步应把“中断”还原成一份可核对的现场记录，明确三件事：停在哪一步、前面做完了什么、外部系统被改动了什么。
常见的中断表现可以归为几类，症状不同，后续排查方向也不同：
- 步骤超时：某一步长时间无返回，任务停在“执行中”，后续步骤未启动。
- 工具调用失败：接口返回错误码、鉴权失败或返回格式与预期不符，步骤直接报错。
- 上下文丢失：模型在后续步骤中拿不到前序结果，出现重复提问、遗漏参数或答非所问。
- 人工审批卡住：任务在等待确认环节停滞，审批人未处理或超时未配置。
- 外部系统返回异常：目标系统状态变更、字段校验不通过或配额耗尽。
接着要区分两类步骤：可安全重试的步骤，以及已经产生副作用的步骤。读取、查询、生成草稿这类操作重试成本低；写库、发消息、提交代码、创建工单这类操作一旦执行成功，重复执行就会产生重复数据、重复通知或冲突提交。对后者，恢复前必须先确认外部动作是否已经生效。
现场记录建议包含以下字段，形成一份可直接交接的清单：
| 记录项 | 填写内容 | 用途 |
|---|---|---|
| 最后成功步骤 | 步骤编号、完成时间、产出物位置 | 确定续跑起点 |
| 当前失败步骤 | 错误信息、返回码、重试次数 | 定位原因 |
| 未执行步骤 | 剩余步骤清单及依赖关系 | 评估重做范围 |
| 副作用清单 | 已写入的数据对象、已发出的消息、已提交的变更 | 防止重复执行 |
| 影响范围 | 涉及的数据对象、下游依赖、需通知的角色 | 决定是否暂停下游 |
影响范围要写具体：哪些记录被创建或修改、哪些下游任务依赖本次产出、哪些人需要知道任务暂停。范围不清时，先暂停下游消费，避免基于半成品继续推进。
原因假设与排除证据：分清偶发失败和结构性缺陷
中断原因不能靠猜。有效做法是先列出假设，再为每个假设指定验证方式和证据来源，用证据把假设标记为成立、排除或待定。原因大致分三类，处置方向差别很大。
| 假设类别 | 典型假设 | 验证方式与证据 | 结论倾向 |
|---|---|---|---|
| 偶发类 | 网络抖动、模型超时、接口限流、临时权限失效 | 原样重试一次并比对日志；查看返回码与时间点是否集中 | 重试可恢复 |
| 结构性 | 步骤依赖顺序错误、上下文超出长度、工具返回格式不符、缺少幂等设计 | 检查步骤编排与依赖图；核对中间产物快照；复现相同输入 | 需改流程才能稳定恢复 |
| 环境类 | 凭据过期、目标系统字段或接口变更、配额耗尽 | 检查凭据有效期、接口文档变更记录、配额用量 | 先修复环境再恢复 |
区分偶发与结构性的关键证据是“可复现性”。同一输入、同一环境下重试一次即成功，且日志中没有格式或依赖异常，倾向偶发；重试后在同一位置再次失败，或换一个输入仍在同一步骤出错，倾向结构性问题。此时继续重试只会放大副作用风险，应先修改步骤设计或参数。
证据来源要固定：执行日志用于确认时间线与返回码，工具返回码用于判断失败类型，中间产物快照用于确认前序结果是否完整可信，审批记录用于判断人工环节是否真的卡住。把假设、验证方式、证据和结论整理成一张原因假设表，待定项标注清楚，避免把推测写成结论带入处置。
按中断类型选择恢复方式：续跑、重放还是重做
恢复方式的选择取决于两个条件：中断点之前是否留下了可信的中间产物，以及失败步骤是否已产生外部副作用。满足条件时优先选择影响面最小的方式。
断点续跑
适用于失败步骤无副作用或已做幂等处理、前序产出完整可信的情况。操作顺序是：确认最后成功步骤的产出已落盘，核对失败步骤的输入参数，从该步骤重新执行，后续步骤按原顺序继续。续跑前不要清理已有产出，否则会丢失续跑依据。
检查点重放
适用于任务在关键节点保存了中间产物快照的情况。从最近一个一致状态的检查点开始，重新执行其后的步骤。重放前要确认快照与当前外部系统状态一致；若快照之后外部数据已被他人修改，重放可能覆盖新数据，此时应先备份或改为局部重做。
整体重做
适用于上下文已丢失、中间产物不可信或步骤间状态已混乱的情况。重做前必须先清理残留：撤销未完成的草稿、标记已创建的重复对象、撤回误发的通知。清理动作本身要有记录，避免清理与重做交叉造成二次混乱。
无论选择哪种方式，处置前先做备份或快照，并设定明确的停止点：外部写入未确认生效前，不重复提交同一动作。对已生效的外部动作，采用去重或补偿处理——已创建的工单先查询再决定是否新建，已发出的通知补发说明而非重发原文，已提交的代码变更先确认合并状态再决定是否重新提交。
人工审批中断是另一类情形。恢复时要补齐三样信息：审批人是否明确、审批意见是否记录、超时策略是否配置。审批人缺失时先指定责任人，审批意见缺失时要求补充结论再继续，超时未处理时按预设策略升级或退回，避免任务无限期悬挂。
当这类多步骤任务运行在研发管理平台中时，中断现场需要有人能接续处理。ONES Assistant 连接 ONES Project、ONES Wiki 与 ONES TestCase，能理解项目、工作项、迭代和 Wiki 页面等真实工作上下文，并把执行结果保存为工作项、Wiki 页面等内容。这意味着中断点、已完成步骤和待办事项可以沉淀为可追踪的工作项与文档，责任人和后续动作有明确载体；其输出过程可追踪、结果可审计，便于交接时核对。任务级的断点续跑与检查点重放机制需以实际部署配置为准。
恢复后的验证与复发预防
任务重新跑完不等于恢复成功。验收要同时看结果和过程：结果层面核对最终产出与预期是否一致、下游系统状态是否正确、是否存在重复数据或重复通知；过程层面检查日志是否完整、每个步骤的状态是否可追溯、检查点是否可复用。两项都通过，才能关闭本次中断。
恢复验收清单可按以下条目逐项核对：
- 最终产出与任务目标逐项比对，无缺项、无多余项。
- 外部系统中已写入的对象数量与预期一致，重复项已清理或标记。
- 下游依赖方已收到正确状态，未基于半成品继续执行。
- 执行日志覆盖中断前后全过程，失败步骤有明确错误记录。
- 相关角色已知晓中断原因、处置方式和最终结果。
复发预防要落到具体改动上。为关键步骤增加检查点并记录中间产物，让下次中断有可重放的起点；为有副作用的操作设计幂等键，使重复提交不产生重复结果；为每个步骤设置超时与重试上限，超过上限即告警而非无限重试；明确失败告警的接收人和升级路径，避免任务静默停滞。最后，把本次中断的原因、验证证据和处置动作整理成排查条目，纳入团队的问题记录，下次出现相似症状时可直接对照，缩短定位时间。
常见问题
任务中断后，能不能直接从头再跑一遍？
整体重跑适合上下文已丢失、中间产物不可信或步骤间状态已混乱的情况，但前提是先清理残留。如果中断前已有写库、发消息、提交代码、创建工单等动作生效，直接重跑会产生重复数据、重复通知或冲突提交。更稳妥的顺序是：先确认哪些外部动作已经生效，清理或标记重复对象，再整体重做，并保留清理记录以便核对。
重试一次就成功了，还需要继续排查原因吗？
需要留下记录，但排查深度可以降低。重试即成功且日志中没有格式或依赖异常，通常倾向偶发类原因，例如网络抖动、限流或临时权限失效。建议把失败时间点、返回码和重试结果记入排查条目；如果同一位置在后续任务中再次出现，就应按结构性问题重新检查步骤依赖、上下文长度和工具返回格式。
人工审批环节卡住导致任务停滞，恢复时要注意什么？
审批中断的恢复重点是补齐三样信息：审批人是否明确、审批意见是否记录、超时策略是否配置。审批人缺失时先指定责任人；审批意见缺失时要求补充结论再继续；超时未处理时按预设策略升级或退回。补齐后再让任务继续执行，避免在结论不明的情况下推进后续有副作用的步骤。
检查点重放时，快照之后外部数据被改过怎么办？
此时重放可能覆盖他人新写入的数据。处置方式是先备份当前外部状态，再判断影响范围：若改动集中在少数对象，可改为局部重做；若涉及面广，应放弃该快照，重新建立一致状态后再执行后续步骤。重放前核对快照与当前外部系统状态是否一致，是避免覆盖的关键动作。
在 ONES 中运行这类多步骤任务，中断现场如何交接？
ONES Assistant 连接 ONES Project、ONES Wiki 与 ONES TestCase，能理解项目、工作项、迭代和 Wiki 页面等真实工作上下文，并把执行结果保存为工作项、Wiki 页面等内容，输出过程可追踪、结果可审计。中断点、已完成步骤和待办事项可以沉淀为可追踪的工作项与文档，便于责任人接续处理。任务级的断点续跑与检查点重放机制需以实际部署配置为准。
