AI流程执行中断是流程运行途中被主动暂停、挂起，等待人工确认、外部数据或资源条件满足后仍可继续的中间状态；流程执行失败则是某一步骤或整个流程因错误、超时或条件不满足而终止，需要修复后重跑。两者的核心差异在于：中断保留执行现场、具备恢复路径，失败已经停止、必须处置。本文按定义、边界、对照、机制、示例和管理做法逐层说明，帮助你在流程停在半途时快速判断属于哪一种。
要点总览（TL;DR）
- AI流程执行中断是流程运行途中被暂停、挂起，等待人工确认、外部数据或资源条件满足后仍可继续的中间状态，核心特征是保留执行现场、具备恢复路径。
- 流程执行失败是某一步骤或整个流程因错误、超时或条件不满足而终止，需要修复后重跑，核心特征是已终止、必须处置。
- 判断时先看流程是否保留执行上下文、是否存在明确的待处理事项：有则按中断处理，补齐输入后继续；已终止并留下错误记录则按失败处理。
- 中断与失败应分开记录和统计，中断率反映协作与等待效率，失败率反映执行质量与稳定性；把中断误当失败重跑会浪费已完成的工作。
- 中断需要待办、提醒和时限管理，否则可能挂到超时转为失败；失败需要进入缺陷或异常处理流程，等待不会让问题自行恢复。
AI流程执行中断到底是什么状态
AI流程执行中断，指一个已经启动并正在运行的AI驱动流程，在到达结束状态之前被暂停或挂起，等待某个外部条件满足后再继续执行。它既不是流程尚未开始，也不是流程已经结束，而是处在“运行中”与“已结束”之间的中间态。判断一个流程是否处于中断，可以看三个特征是否同时成立：流程已经产生执行记录、当前停在某个具体节点、存在明确的待处理事项。
中断的典型触发场景包括以下几类：
- 等待人工审批或确认：例如AI完成需求评审意见草稿后，需要负责人确认才能进入下一环节。
- 等待外部数据或系统回调：流程调用了外部系统，需要等对方返回结果才能继续判断。
- 等待模型输出确认：AI生成的内容需要人工审核通过后才允许写入正式记录。
- 等待资源或额度：执行所需的计算资源、调用额度或并发名额暂时不可用，流程挂起等待释放。
中断最重要的性质是可恢复。流程在挂起时会保留执行上下文，包括已经完成的步骤、当前节点、已获取的输入数据和中间结果。条件满足后，流程从断点继续，不需要从头重跑。这也是中断与失败在体验上的直接差别：中断是“等一等再走”，失败是“停下来处理”。
从状态机角度看，一个AI流程通常经历未启动、运行中、中断、已结束几个位置。中断位于运行中与已结束之间，可以回到运行中，也可以在超时或条件恶化后转入失败。理解这个位置，有助于后续判断流程当前到底卡在哪一类状态。
中断状态的边界：哪些情况算中断，哪些不算
中断容易被和几种相邻状态混淆，划清边界才能准确判断。下面按常见情形逐一说明。
中断与排队等待、未启动的区别。排队等待指流程已经提交但尚未获得执行资源，流程本身还没有开始跑；未启动指触发条件尚未满足，流程根本没有进入执行。中断的前提是流程已经运行过，并且产生了执行上下文。一个简单的判断方法是看有没有“已完成的步骤”：有，才可能是中断；没有，更可能是排队或未启动。
中断与人工跳过、条件分支不执行的区别。人工跳过指某个节点被有意略过，流程继续往下走；条件分支不执行指判断条件不满足，某条分支被设计为不进入。这两种情况流程都在正常推进，没有停下来等待。中断则表现为流程停在某处、不再自动前进，并且有明确的待处理事项。
中断与主动取消、终止的区别。主动取消是人为决定不再执行，终止是流程被强制结束，两者都进入结束状态，不会自行恢复。中断保留恢复可能，取消和终止则关闭了这条路径。如果流程是被有意停掉的，应记录为取消或终止，而不是中断。
中断持续时长与超时升级为失败的关系。中断可以持续一段时间，但很多流程会为等待设置时限。超过时限仍未等到输入或资源，流程可能被判定为超时失败。也就是说，中断是暂时状态，超时是把中断转为失败的一种机制。设置合理的等待时限，并在临近时限时提醒责任人，可以减少“挂着挂着就失败”的情况。
中断和失败的区别：从触发原因到处置方式
把中断和失败放在同一组口径下对照，差异会更清楚。两者都表现为流程没有正常走完，但原因、状态、数据留存和后续动作完全不同。
| 对照维度 | 执行中断 | 执行失败 |
|---|---|---|
| 触发原因 | 等待人工确认、外部数据、模型输出审核、资源或额度 | 模型调用异常、工具返回错误、参数校验不通过、超时无响应 |
| 状态表现 | 挂起、待处理，流程仍处于可继续的位置 | 已终止，流程停止推进 |
| 是否可恢复 | 条件满足后可从断点继续 | 需要修复问题后重跑或人工补救 |
| 上下文与数据 | 保留执行现场和中间结果 | 产生错误记录，已完成的步骤可能需要重新执行 |
| 处置方式 | 补充输入、完成审批、释放资源后继续 | 定位错误、修复配置或数据后重跑 |
| 对流程结果的影响 | 延迟完成，结果通常不受损 | 本次执行未产出预期结果，需重新执行 |
从处置角度看，中断的处理重点是“把缺的东西补上”。责任人需要知道流程在等什么、等谁、等到什么时候，然后完成对应动作，流程即可继续。失败的处理重点是“把错的地方修好”。需要查看错误信息、定位出问题的节点，修复后重新发起执行。把中断误当失败直接重跑，会浪费已经完成的工作；把失败误当中断长期挂起，则会让问题一直得不到解决。
对流程整体结果的影响也不同。中断通常只造成延迟，流程最终仍能产出结果；失败则意味着本次执行没有拿到预期产出，需要额外投入修复和重跑的成本。因此在统计流程健康度时，中断率和失败率应分开观察，前者反映协作与等待效率，后者反映执行质量与稳定性。
AI驱动流程中中断与失败的机制与组成
要判断一次停摆属于中断还是失败，需要了解AI流程由哪些环节组成、状态由谁判定。一个典型的AI驱动流程包括：触发、模型调用、工具调用、条件判断、人工节点和结果输出。不同环节出问题，对应的状态类型往往不同。
中断常见于人工节点和外部依赖处。人工确认节点天然需要等待，流程在这里挂起是设计内的行为；外部系统回调需要等对方返回，也属于等待型停摆；模型输出待审时，流程会停在审核环节，直到有人确认通过或驳回。这些位置的共同点是：流程没有出错，只是缺少继续前进的条件。
失败常见于执行出错的位置。模型调用异常，例如服务不可用或返回格式不符合预期；工具调用返回错误，例如接口报错或数据不存在；参数校验不通过，例如必填字段缺失或类型不符；超时无响应，例如等待超过设定时限仍无结果。这些情况的共同点是：流程遇到了无法自行跨越的障碍，继续等待也不会自动好转。
无论中断还是失败，都需要可观测的信息来支撑判断。执行日志应记录流程走到哪个节点、发生了什么、当前在等什么或错在哪里；当前节点信息帮助定位停摆位置；待处理事项则说明需要谁做什么。缺少这些记录时，中断和失败在外观上都只是“流程没动”，判断成本会明显上升。因此，在流程设计阶段就把状态记录和待处理信息纳入考虑，比事后排查更有效。
具体例子与常见误解
用两个演示情景可以更直观地看出区别。情景一：AI根据需求文档生成评审意见草稿，流程进入人工确认节点，等待需求负责人确认。此时流程停在确认节点，草稿和上下文都已保存，负责人确认后流程继续流转。这属于中断。情景二：AI在流程中调用外部接口获取数据，接口返回错误，流程无法继续，执行终止并留下错误记录。这属于失败，需要排查接口问题后重跑。
实际使用中，有三种误解比较常见。
误解一：把中断当成失败而直接重跑。看到流程停住就重新发起执行，结果重复生成了草稿、重复占用了资源，之前已完成的工作也被浪费。正确做法是先确认流程是否在等待某个输入，如果是，补上输入即可继续。
误解二：把失败当成中断而长期挂起等待。流程已经因为错误终止，却被当作“还在等”，迟迟没有人处理。失败不会因为等待而自行恢复，需要有人定位问题并修复。判断依据是看有没有错误记录和终止状态，而不是只看流程有没有产出结果。
误解三：认为中断不需要记录和跟进。中断虽然可恢复，但如果没有人知道流程在等什么、等了多久，就可能一直挂到超时，最终转为失败。中断同样需要待办、提醒和时限管理，才能发挥“可恢复”的价值。
在研发管理中如何区分记录中断与失败
把概念落到管理动作上，关键是让两类情况在记录层面就能被区分，而不是靠人回忆。可以从三个方面入手。
第一，用不同状态或标记区分。挂起待处理的状态应与已失败的状态分开设置，让看板或列表一眼能看出哪些流程在等人、哪些流程出了问题。第二，中断要生成待办或通知到具体责任人，明确在等什么、截止时间是什么；失败则进入缺陷或异常处理流程，记录错误信息和修复进展。第三，保留执行上下文，包括当前节点、已完成步骤和中间结果，既方便中断恢复，也方便失败复盘。
在ONES中，这类区分可以借助工作项状态、待办流转和执行记录来承载。ONES Assistant可将自然语言指令转化为ONES中可追踪的工作，例如创建缺陷、更新状态并通知项目负责人，使流程中的待处理事项和异常事项都有对应的记录和责任人。其AI能力基于ONES权限体系执行，输出过程可追踪、结果可审计，便于团队在复盘时还原流程当时停在哪、为什么停。需要说明的是，具体状态模型和待办机制应结合团队实际配置，本文不展开产品层面的状态机细节。
管理上的判断口径可以归纳为一句话：先看流程是否保留执行现场、是否存在明确的待处理事项，如果是，按中断处理，补齐输入后继续；如果流程已终止并留下错误记录，按失败处理，修复后重跑。把这条口径写进流程规范和值班约定，中断与失败的区分就会从个人经验变成团队共识。
常见问题
流程停在人工审批节点很久没有推进，这算中断还是失败？
只要流程仍保留执行现场、当前节点明确、存在待处理事项，就属于中断，即使已经停了较长时间。需要关注的是等待时限：如果流程配置了超时机制，超过时限仍未等到审批结果，可能被判定为超时失败。此时应先确认流程是否已转入失败状态，再决定是补充审批继续，还是修复后重跑。
中断后流程一直没人处理，会自动变成失败吗？
取决于流程是否设置了等待时限。设置了时限的流程，在超过时限仍未获得输入或资源时，可能被判定为超时失败；没有设置时限的流程则会一直挂起。无论哪种情况，中断都需要生成待办并通知责任人，明确在等什么、截止时间是什么，避免流程长期无人跟进。
流程因外部接口报错而停止，修复接口后应该继续还是重跑？
外部接口报错属于执行失败，流程已经终止并留下错误记录，通常需要修复接口问题后重新发起执行。如果平台支持从失败节点恢复，也可以按实际能力选择续跑，但前提是确认已完成的步骤和中间结果仍然有效。判断依据是流程是否处于终止状态，而不是看它有没有产出结果。
团队规模较小、流程不多时，有必要把中断和失败分开记录吗？
流程数量少时，靠人工沟通也能应付，但随着流程增多，混在一起记录会让两类问题都难以跟踪。分开记录的成本主要是状态设置和待办约定，收益是能看清哪些流程在等人、哪些流程出了错。可以先从关键流程开始区分，再逐步推广到其他流程。
ONES 能否承载中断待处理与失败两类记录？
ONES 可以通过工作项状态、待办流转和执行记录来承载这类区分。ONES Assistant 可将自然语言指令转化为 ONES 中可追踪的工作，例如创建缺陷、更新状态并通知项目负责人，使待处理事项和异常事项都有对应记录和责任人。具体状态模型和待办机制需要结合团队实际配置，本文不展开产品层面的状态机细节。
