AI 流程执行中断时，先别急着重跑。更稳妥的顺序是：确认中断停在哪一步、影响多大，再按触发输入、模型调用、工具接口、权限凭据、执行状态逐层找证据，最后按风险从低到高处置并验证恢复。本文围绕 AI 驱动执行环节的中断排查展开，给出可直接照做的记录表、证据对照和处置清单。
要点总览（TL;DR）
- 中断后先界定现象与影响范围：是单次任务、某类流程还是全部流程，首次发生时间与最近一次成功执行之间有什么变更。
- 按输入与触发、模型调用、工具与接口、权限与凭据、执行状态五层逐层找证据，能用证据排除的方向不再重复猜。
- 重跑前先确认幂等与去重条件，上次执行已产生无法去重的外部副作用时停止重跑，转为人工核对。
- 处置按风险从低到高：无损查看、确认幂等后重试、小范围改配置验证、人工接管、数据修复或回滚。
- 恢复要验证结果一致、下游正常接收、状态流转完整，并把原因与处置过程沉淀为可复用的排查条目。
中断发生在哪一步：先界定症状与影响范围
“中断”是一个笼统的说法，不同表现对应不同的排查方向。第一步要把模糊的“跑不下去了”拆成可观察、可记录的具体现象，同时划定影响边界，避免一上来就改配置或重跑，把现场证据覆盖掉。
常见的表现可以归为几类：任务停在中间状态不再推进；某次调用返回明确报错；流程走完了但输出为空或明显缺内容；长时间无响应、既无报错也无进展；同一任务被重复执行多次。这几类现象指向的原因差别很大，记录时要尽量写清具体表现，而不是只写“失败”。
影响范围决定处置的紧急程度和谨慎程度。需要确认：是单次任务、某一类流程，还是全部流程都受影响；问题是否集中在某个时间段、某个模型、某个外部工具或某个项目。如果只有一条流程在特定输入下失败，优先怀疑输入与参数；如果多条不相关流程同时中断，优先怀疑模型服务、网络或凭据这类公共依赖。
时间线同样关键。记录首次发生时间、最近一次成功执行的时间、两次之间发生过什么变更（配置调整、密钥轮换、外部系统升级、输入数据格式变化）。很多中断都能在“最后一次成功”和“第一次失败”之间找到变更线索。
还要区分中断与相邻问题。结果错误、结果不完整、结果格式不符，属于流程跑完但质量不达标，排查重点在模型输出与校验环节；中断则是执行没有正常走完。两者处置方式不同，混在一起记录会让后续判断失准。
建议用一张简单的现象记录表固定信息，便于交接和复盘：
| 记录项 | 填写内容示例 |
|---|---|
| 具体表现 | 任务停在“待处理”状态，无报错；或调用返回超时错误 |
| 影响范围 | 单次任务 / 某类流程 / 全部流程；涉及哪些项目或团队 |
| 时间线 | 首次发生时间、最近一次成功时间、期间变更 |
| 涉及环节 | 触发、模型调用、工具接口、权限、状态流转 |
| 输入与上下文 | 本次输入内容、参数、关联文档或数据 |
| 已做操作 | 是否重跑过、是否改过配置、改了什么 |
这张表填完，排查范围基本就清楚了：接下来只需在有限的几个方向里找证据。
按层排查：常见原因假设与排除证据
AI 流程的执行链路通常可以分成几层：输入与触发、模型调用、工具与接口、权限与凭据、执行状态。逐层排查的价值在于，每一层都有对应的可观察证据，能用证据排除的方向就不必再猜。下面按层列出常见原因假设和验证方式。
输入与触发层
这一层的问题往往表现为流程根本没启动，或启动后立刻失败。常见假设包括：必填参数缺失、参数格式不符合要求、上下文或文档超出长度限制、触发条件没有满足（如上游状态未变更、定时未到）。验证方式是回看本次触发的原始输入和触发记录，确认参数完整、格式正确、触发条件确实成立。如果同一流程换一份合规输入就能跑通，基本可以锁定输入问题。
模型调用层
典型表现是超时、限流报错、服务暂时不可用，或者模型返回的内容无法被后续步骤解析。验证时查看调用返回的错误码和错误信息：限流通常有明确的频次提示，超时表现为等待超过设定时限，服务不可用多为连接失败或服务端错误。返回内容无法解析则要检查输出格式是否符合下游预期，必要时保留原始返回内容作为证据。若同一时段多个流程同时出现同类报错，优先考虑服务侧或配额问题。
工具与接口层
AI 流程经常要调用外部系统完成查询、写入或通知。这一层的中断表现为外部系统返回错误、返回结构发生变化导致解析失败、连接超时。验证方式是单独调用该接口复现问题，对比返回结构与流程预期字段是否一致。外部系统升级或字段调整是常见诱因，核对接口返回的实际内容比查看流程配置更快定位。
权限与凭据层
令牌过期、授权范围不足、密钥被轮换或配置被改动，都会让流程在某个调用点突然中断，且往往伴随鉴权类错误。验证时核对凭据有效期、授权范围是否覆盖本次操作、近期是否有密钥变更记录。这类问题的特点是“之前一直正常、某天开始全部失败”，与时间线的比对很有价值。
执行状态层
中间状态没有持久化、重试机制缺失或幂等设计不足，会导致任务卡死或重复执行。表现为流程停在某一步无法续跑，或同一动作被执行多次。验证时查看执行记录中状态是否被正确写入、重试次数与间隔是否符合预期、重复执行是否产生了重复写入或重复通知。
把上述假设整理成对照表，边查边标注，能避免反复回到已排除的方向：
| 层级 | 常见原因假设 | 验证证据 | 状态 |
|---|---|---|---|
| 输入与触发 | 参数缺失、格式不符、上下文超长、触发条件未满足 | 原始输入、触发记录、换合规输入复跑结果 | 已排除 / 待验证 |
| 模型调用 | 超时、限流、服务不可用、返回无法解析 | 错误码与错误信息、原始返回内容、同时段其他流程表现 | 已排除 / 待验证 |
| 工具与接口 | 外部系统报错、返回结构变化、连接超时 | 单独调用接口的返回结果、字段对比 | 已排除 / 待验证 |
| 权限与凭据 | 令牌过期、授权不足、密钥变更 | 凭据有效期、授权范围、变更记录 | 已排除 / 待验证 |
| 执行状态 | 状态未持久化、重试与幂等缺失 | 执行记录中的状态写入、重试次数、重复执行痕迹 | 已排除 / 待验证 |
排查时有一个实用原则：先查能一次性解释全部现象的原因。如果所有流程都中断，公共依赖（模型服务、网络、凭据）比单条流程的输入问题更值得先查；如果只有一条流程在特定输入下失败，就回到输入与参数层面。
按风险分级处置：从低影响动作到重建执行
找到方向后，处置动作要按对业务和数据的影响排序。先做只读、无损的动作，再做可回退的变更，最后才考虑重跑、数据修复或重建执行。每一步都应有前置条件和停止点，避免处置本身制造新问题。
第一级：无损动作
查看执行日志与状态记录，确认中断停在哪一步、最后一条成功记录是什么；核对上游输入是否完整、格式是否正确；检查凭据有效期与授权范围。这些动作不改变任何数据，可以放心先做。完成标志是：能说清中断点、能排除或确认输入与凭据问题。
第二级：确认幂等后再重试
重跑是最容易造成二次伤害的动作。重跑前必须确认：该流程涉及的外部写入、通知、状态变更是否具备幂等或去重条件；上次执行是否已经部分完成，重跑会不会重复写入或重复通知。如果无法确认，先查清上次执行的实际影响范围，再决定从断点续跑还是整体重跑。停止点是：一旦发现上次执行已产生外部副作用且无法去重，停止重跑，转为人工核对。
第三级：修改配置并小范围验证
需要调整参数、超时设置、重试策略或接口映射时，先记录变更前的配置，限定变更影响的范围，用少量任务或测试输入验证效果，确认无误后再放开。停止点是：小范围验证出现新的异常，立即回退到变更前配置。
第四级：人工接管
当自动恢复不可行时，明确由谁接管、需要补齐哪些输入、任务当前应标记为什么状态。人工接管不是简单地把任务标成完成，而是要把缺失的环节补上，并在记录中写明接管原因和实际处理结果，供后续复盘。
第五级：数据修复或回滚
涉及数据修复或回滚时，先备份受影响的数据，明确修复范围和停止条件。修复过程中一旦发现影响面超出预期，停止操作并回到备份状态。这类动作风险最高，应放在最后，且需要有人对结果负责。
处置过程中，任务状态和交接记录需要有承载的地方。ONES Assistant 连接 ONES Project、ONES Wiki 与 ONES TestCase，能够理解项目、工作项、迭代和 Wiki 页面等真实工作上下文，并把执行结果保存为工作项、Wiki 页面等内容（依据 F1、F2、F3）。在中断处置场景中，这意味着排查结论、接管记录和后续改进项可以沉淀在同一个工作项或 Wiki 页面里，交接时不必再靠口头说明。ONES 的 AI 能力基于 ONES 权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计（依据 F5），便于在复盘时核对每一步由谁、在什么状态下完成。
验证恢复与减少复发：把中断变成可管理事件
流程重新跑通不等于真正恢复。验证要覆盖结果、下游和状态三个层面，改进要落到监控、流程设计和责任分工上，这样一次中断才能转化为可复用的经验。
恢复验证清单
- 用同一输入重跑，结果与预期一致，且与中断前的部分结果不冲突；
- 下游环节正常接收到输出，没有出现重复接收或遗漏；
- 任务状态流转完整，从触发到结束的每个状态都有记录；
- 涉及外部写入的动作，核对目标系统中数据条数与内容正确；
- 此前被人工接管的任务，补齐的输入和处理结果已记录在案。
补充监控与告警
针对本次中断暴露的薄弱点设置检测项：失败率异常升高、调用超时、输出为空、任务在某一状态停留超过阈值。告警要指向具体流程和环节，避免只报“有异常”而无法定位。对依赖外部接口的流程，可增加返回结构校验，字段缺失时提前告警。
在流程中加入失败分支与兜底
为关键步骤设置重试上限和退避间隔，超过上限后转入人工兜底节点，而不是无限重试或静默失败。对存在外部写入的步骤，补充幂等键或去重判断。失败分支要明确记录失败原因，方便下次排查直接复用。
记录原因与处置过程
把本次中断的现象、排除过程、最终原因、处置动作和验证结果整理成条目，附在对应流程或项目的知识页面中。条目应包含“什么现象对应什么原因、用什么证据确认”，下次遇到相似表现可以直接对照，缩短排查时间。ONES Assistant 贯穿需求、计划、协作、测试、发布与知识沉淀（依据 F4），这类排查条目可以随项目知识一起沉淀，供团队复用。
区分改进责任方
复盘时要分清哪些改进属于流程设计（如重试策略、失败分支、人工节点设置），由流程负责人推进；哪些属于接口与集成问题（如返回结构不稳定、鉴权配置），交由对应系统或集成维护方处理。分开归属，改进项才不会在交接中悬空。
把中断当作一次可管理的事件来处理：现象记录清楚、证据逐层排除、处置按风险排序、恢复经过验证、改进落到具体责任方。这样即使 AI 流程再次中断，团队也有稳定的路径可以走，而不是每次从零开始猜测。
常见问题
流程中断后，怎么判断是单条流程的问题还是公共依赖的问题？
看影响面。只有一条流程在特定输入下失败，优先怀疑输入与参数；多条不相关流程在同一时段同时中断，优先查模型服务、网络、凭据这类公共依赖。再结合时间线比对：如果中断集中在某次密钥轮换、外部系统升级或配置调整之后，公共依赖的可能性更高。先查能一次性解释全部现象的原因，可以少走弯路。
重跑之前需要确认哪些条件，才能避免重复写入或重复通知？
重点确认三件事：上次执行是否已经部分完成、涉及的外部写入和通知是否具备幂等或去重条件、重跑是从断点续跑还是整体重跑。如果无法确认上次执行的实际影响范围，先查清已产生的外部副作用再决定。一旦发现副作用无法去重，停止重跑，转为人工核对并记录已处理的部分。
人工接管任务时，除了把状态改成完成，还需要记录什么？
需要补齐缺失的环节，并写明接管原因、补齐了哪些输入、实际处理结果是什么。任务状态只是结果，接管过程才是复盘依据。如果团队使用 ONES 承载工作项，可以把这些信息直接记录在对应工作项或 Wiki 页面中，交接时不必依赖口头说明。ONES Assistant 能够理解项目、工作项、迭代和 Wiki 页面等真实工作上下文，并把执行结果保存为工作项、Wiki 页面等内容（依据 F2、F3）。
流程已经重新跑通，为什么还要做恢复验证？
跑通只说明这一次执行走完了，不代表结果正确、下游接收正常、状态记录完整。验证要覆盖三个层面：同一输入重跑结果与预期一致且不与中断前的部分结果冲突；下游没有重复接收或遗漏；任务从触发到结束的每个状态都有记录。涉及外部写入的，还要核对目标系统中的数据条数与内容。
复盘时怎么区分流程设计问题和接口集成问题？
看改进项落在哪一侧。重试策略、失败分支、人工兜底节点、超时阈值这类属于流程设计，由流程负责人推进；返回结构不稳定、鉴权配置、连接超时这类属于接口与集成，交由对应系统或集成维护方处理。分开归属后，改进项才不会在交接中悬空。复盘记录可以沉淀在项目知识页面中，ONES Assistant 贯穿需求、计划、协作、测试、发布与知识沉淀（依据 F4），便于团队后续复用。
