AI流程执行中断后，第一步先冻结受影响流程并导出执行日志，保留现场，再按“停在哪一步”定位范围：中断发生在自然语言解析、任务编排、跨对象写入还是人工确认环节。范围清楚后，用日志、返回码和字段校验提示逐项验证原因，按最小范围重试或补数据后重跑，最后用同一输入复验并补上确认点与失败告警。
要点总览（TL;DR）
- 中断后先冻结受影响流程并导出执行日志，保留现场，再按触发解析、步骤编排、对象写入、人工确认、结果回写五个阶段定位中断位置。
- 原因排查把假设与证据分开：权限、字段校验、依赖对象、人工确认、外部接口五类假设，各自对应可观察的日志、返回码或校验提示，拿不到证据的按待验证处理。
- 处置按类型区分：权限类补授权后从失败步骤重试，数据类补齐字段或依赖对象后单条试跑，确认类补发通知或按规代确认，接口类等服务恢复后限量重试。
- 恢复验证用同一输入复验，逐项核对对象状态与结果回写，并检查是否产生重复工作项或重复通知。
- 复发预防落在关键步骤失败告警、高风险写入前确认点、执行账号权限复核和字段约束变更跟踪四项机制上。
中断发生在哪一步：先划清症状与影响范围
中断后的第一动作是停止继续重试，把现场固定下来。AI驱动的流程往往一次串联多个动作，盲目重跑可能造成重复写入或重复通知，反而让后续排查更困难。先记录、再判断，是控制影响面的前提。
定位范围时，按执行阶段拆分观察到的现象。不同阶段的失败表现差异明显，记录时尽量使用系统里能看到的事实，例如报错提示、对象状态、时间点，而不是“感觉没执行成功”这类描述。
| 执行阶段 | 典型现象 | 需要记录的信息 |
|---|---|---|
| 触发与解析 | 指令未被识别，或解析出的任务与预期不符 | 原始触发语句、触发时间、触发人 |
| 步骤编排 | 任务拆解后步骤缺失、顺序错乱或停在某一步 | 已完成的步骤列表、停下的步骤名称 |
| 对象写入 | 工作项、文档或状态未生成，或生成后字段为空 | 目标对象类型、对象标识、写入前后的字段值 |
| 人工确认 | 流程停在等待确认，长时间无进展 | 确认节点、等待时长、通知记录 |
| 结果回写 | 前置动作完成，但结果未回填到原对象 | 回写目标、回写内容、回写时间 |
记录完单次中断后，再判断影响面：是单个任务失败，还是同类流程在同一时间段批量失败。判断依据可以看触发时间是否集中、失败阶段是否一致、涉及对象是否属于同一项目或同一执行账号。批量失败通常指向权限、服务或配置层面的共性问题，单次失败更可能与具体输入或数据状态有关。这个判断直接决定后续排查是查个案还是查共性。
现场记录表建议至少包含四列：阶段、现象、涉及对象、影响范围。表格填完后，再进入原因验证，避免在范围未清时改动配置。
常见原因与排除证据：哪些假设能被日志证实
原因排查的关键是把假设和结论分开。下面几类原因是AI流程执行中断的常见方向，每一类都需要对应的可观察证据才能成立；拿不到证据的，按待验证处理，继续收集而不是直接改配置。
| 原因假设 | 验证证据 | 建议排查顺序 |
|---|---|---|
| 权限或授权过期 | 执行账号的权限记录、令牌有效期、授权变更时间 | 1 |
| 字段校验不通过或必填项缺失 | 写入对象的字段约束提示、校验报错内容 | 2 |
| 依赖对象不存在或状态不符 | 前置工作项、文档、版本的存在性与当前状态 | 3 |
| 人工确认超时或未响应 | 确认节点的等待时长、通知发送与阅读记录 | 4 |
| 外部服务或接口异常 | 调用返回码、超时记录、重试次数 | 5 |
排查顺序按“先内后外、先静态后动态”安排：权限和字段约束属于执行前就能核对的条件，成本低、结论明确，放在前面；依赖对象状态需要跨对象比对，放在中间；人工确认和外部服务涉及等待与第三方，放在后面。这样安排可以在多数情况下用较少步骤排除大部分假设。
权限类假设的验证要点是核对执行账号当前是否仍具备目标对象的操作权限，以及授权是否在中断时间点前后发生过变更。字段类假设看写入时的校验提示，注意区分“字段缺失”和“字段值不符合格式要求”，两者处置方式不同。依赖对象类假设要确认前置对象是确实不存在，还是存在但状态不满足流程要求，例如版本未发布、工作项未进入指定状态。确认类假设看等待时长是否超过设定阈值、通知是否送达。接口类假设看返回码和重试记录，连续超时与明确报错指向的处理方向不同。
当多条假设同时存在证据时，以时间上最接近中断点的证据为主。例如权限在中断前十分钟被调整，优先按权限类处理，其余假设留待复验时确认。
按中断类型处置：恢复步骤与停止点
处置前统一做两件事：冻结受影响流程，防止自动重试继续写入；导出执行日志和对象当前状态，作为后续比对基线。冻结范围以影响面判断为准，批量失败时冻结同类流程，单次失败时冻结单个任务即可。
权限类中断
补齐执行账号所需授权后，从失败步骤重试，不整链重跑。整链重跑会把已完成的写入再执行一遍，容易产生重复工作项。重试前确认授权已生效，重试后核对失败步骤及其后续步骤的对象状态。停止点设在重试两次仍失败时，转为人工核查授权范围是否覆盖全部目标对象。
数据类中断
先补齐缺失的必填字段或创建缺失的依赖对象，再做单条试跑。试跑通过后再处理同批其余任务。停止点设在试跑结果与预期不一致时，此时应回到字段约束和对象状态重新核对，不扩大重跑范围。补数据前保留原始对象快照，便于回退。
确认类中断
补发确认通知，或按流程规定改由指定角色代确认。代确认需要记录代确认人、代确认时间与依据，例如原确认人超时未响应、已通过其他渠道取得同意。停止点设在代确认权限不明确时，此时应升级到流程负责人裁定，不自行扩大代确认范围。
接口类中断
先确认外部服务已恢复，再发起重试，并设置重试上限与停止条件，例如最多重试三次、间隔逐次拉长。外部服务未恢复前不反复重试，避免放大异常和产生大量失败记录。停止点设在达到重试上限仍失败时，转为人工介入并记录外部服务状态。
在ONES中承载这类流程时，AI执行的结果会保存为工作项、Wiki页面等内容，中断后可以直接核对这些对象的当前状态，判断哪些步骤已完成、哪些需要补做。ONES Assistant基于项目、工作项、迭代和Wiki页面等真实上下文执行操作，排查时对照对象状态与执行记录，比只看对话记录更容易还原中断位置。
恢复验证与复发预防
流程恢复不能只看“这次跑通了”，要用同一输入复验，并核对每个步骤的对象状态与结果回写。复验时逐项确认：目标工作项是否生成且字段完整、状态是否流转到预期节点、结果是否回写到原对象、通知是否只发送了一次。
复验中要专门检查重复数据。中断后重试容易产生重复工作项或重复通知，发现后按影响范围清理，清理前确认哪一条是有效记录，避免误删已完成步骤的产物。清理完成后再次核对关联关系，确保依赖对象指向正确。
| 预防措施 | 具体做法 | 复核周期 |
|---|---|---|
| 关键步骤失败告警 | 在对象写入、确认等待、外部调用等步骤设置失败通知，明确接收人 | 随流程变更同步更新 |
| 人工确认点 | 在高风险写入前保留确认节点，设定合理的等待时长与超时处理方式 | 每季度检查一次 |
| 执行账号权限复核 | 核对账号权限范围与令牌有效期，授权变更后同步验证流程 | 按月或随人员变动 |
| 字段约束变更跟踪 | 对象字段或必填规则调整后，回归验证相关流程 | 随配置变更触发 |
复发预防的重点是把这次中断中暴露的薄弱环节固化成检查项。若中断源于权限变更未同步，就在授权流程中加入“变更后回归验证”的动作；若源于确认超时，就调整等待时长或补充提醒渠道。ONES的AI能力基于ONES权限体系执行任务，输出过程可追踪、结果可审计，权限与执行记录的对应关系可以作为定期复核的依据。
最后，把本次中断的阶段、原因、处置动作和复验结果整理成一条记录，归入同类流程的排查知识中。下次出现相似现象时，可以直接从对应阶段入手，缩短定位时间。
常见问题
中断后已经自动重试了几次，还需要先冻结流程吗？
需要。自动重试可能已经产生部分写入，继续重试会让重复数据叠加，排查时更难区分哪一次是有效执行。建议先冻结流程，导出执行日志和对象当前状态，确认已完成步骤和已写入对象后，再决定从哪一步重试。若重试已经产生重复工作项，先确认哪一条是有效记录，再清理其余记录。
多条原因假设同时有证据时，怎么确定先处理哪一个？
以时间上最接近中断点的证据为主。例如执行账号权限在中断前十分钟被调整，优先按权限类处置，其余假设留到复验时确认。若几条证据的时间接近，按排查成本从低到高处理：权限和字段约束核对成本低、结论明确，先做；依赖对象状态需要跨对象比对，其次；人工确认和外部服务涉及等待与第三方，放在后面。
补数据后重跑，怎么避免把已完成的步骤再执行一遍？
重跑范围控制在失败步骤及其后续步骤，不整链重跑。补数据前保留原始对象快照，便于回退；重跑前先做单条试跑，试跑结果与预期一致后再处理同批其余任务。试跑结果不一致时，回到字段约束和对象状态重新核对，不扩大重跑范围。
人工确认超时后由他人代确认，需要留下什么记录？
代确认需要记录代确认人、代确认时间与依据，例如原确认人超时未响应、已通过其他渠道取得同意。代确认权限不明确时，升级到流程负责人裁定，不自行扩大代确认范围。这些记录在后续复验和审计时用于说明该步骤为何跳过原确认人。
流程复验通过后，还需要做哪些长期动作？
把本次中断的阶段、原因、处置动作和复验结果整理成一条记录，归入同类流程的排查知识。同时检查四项预防机制是否到位：关键步骤失败告警的接收人是否明确、高风险写入前是否保留确认点、执行账号权限与令牌有效期是否定期复核、字段约束变更后是否回归验证相关流程。中断若源于权限变更未同步，就在授权流程中加入变更后回归验证的动作。
