AI流程异常处理，指AI参与执行或决策的流程在运行中偏离预期时，系统或人员完成识别、判定与处置的过程。它包含哪些类型、按可恢复程度如何分档，直接决定重试、修正、人工确认还是回滚。本文从异常对象和可恢复程度两个维度展开，并说明两者如何组合决定处置路径。
要点总览（TL;DR）
- AI流程异常处理按发生对象分为七类：输入异常、模型输出异常、工具调用异常、状态与数据异常、权限与合规异常、资源与超时异常、业务规则冲突。
- 按可恢复程度分为五档：自动重试即可恢复、修正输入后可恢复、人工确认后可恢复、需回滚或补偿、不可恢复需终止。
- 分档按四个问题依次判断：是否已产生副作用、步骤是否可重放、修复所需信息是否可得、影响范围多大。
- 类型与可恢复程度是两个独立维度，同一类型可落在不同档位，处置路径由组合结果决定，不能把类型直接当严重程度。
- 异常分级结果建议记录为工作项或异常单据，保留类型、档位、处置动作与责任人，便于复盘统计。
AI流程异常处理是什么，边界在哪里
AI流程异常处理的对象是“AI参与执行或决策的流程”。当模型生成内容、调用工具、读写业务数据或触发后续动作时，结果与预期不一致、执行中断或产生错误副作用，就需要进入异常处理：先识别异常发生在哪个环节，再判断影响范围和可恢复条件，最后选择处置动作并留下记录。
本文讨论的范围限定在AI驱动执行环节的异常类型与可恢复程度。具体包括：输入是否满足模型和工具的要求，模型输出是否可用，工具调用是否成功，流程状态和数据是否一致，权限与合规是否被触发，资源与时间是否够用，AI结果与业务规则是否冲突。这些内容共同回答“出了什么问题、严重到什么程度、该怎么处理”。
以下内容不在本文展开：确定性规则自动化的流程编排设计，属于研发流程自动化的范畴；MCP等接口连接方式与扩展开发的具体实现，属于开放接口与扩展开发主题；模型训练与调优方法，属于模型能力建设。本文也不做具体产品的异常处理能力、版本与价格对比。
异常处理与流程监控、日志告警是相邻但不同的动作。监控和告警负责发现“偏离发生了”，异常处理负责回答“这是什么异常、能不能恢复、由谁处置”。告警可以触发异常单据，但告警本身不替代分级和处置。把三者混在一起，容易出现“告警很多、处置很少”的情况。
AI流程异常包括哪些类型
按异常发生的对象和环节，可以把AI流程异常分为七类。分类的目的是定位责任方和修复手段：输入问题回到上游数据，模型输出问题回到提示词与校验，工具调用问题回到接口，状态问题回到流程设计，权限问题回到授权配置，资源问题回到配额与调度，规则冲突回到业务约束。
| 异常类型 | 典型表现 | 识别信号 |
|---|---|---|
| 输入异常 | 必填字段缺失、日期或枚举格式不符、上下文超过模型窗口 | 入参校验失败、截断提示、字段为空 |
| 模型输出异常 | 返回内容不符合约定结构、事实与知识库不一致、拒答或空返回 | 结构校验不通过、引用核对失败、返回长度为零 |
| 工具调用异常 | 接口报错、返回字段结构变化、调用超时 | 错误码、响应结构比对失败、超时日志 |
| 状态与数据异常 | 中间状态丢失、同一步骤重复执行、写入结果与源数据不一致 | 状态机缺步、幂等键重复、对账差异 |
| 权限与合规异常 | 越权读取或写入、敏感内容被策略拦截 | 权限拒绝记录、内容安全拦截事件 |
| 资源与超时异常 | 模型配额耗尽、并发受限、长任务超过时限 | 配额告警、限流响应、任务超时 |
| 业务规则冲突 | AI给出的结论与审批规则、阈值约束不一致 | 规则引擎校验不通过、审批退回 |
七类异常的处置责任并不相同。输入异常通常由上游系统或提交人修正；模型输出异常需要检查提示词、上下文和输出校验；工具调用异常要区分是接口故障还是参数问题；状态与数据异常往往需要幂等设计和补偿；权限与合规异常必须先确认授权边界；资源与超时异常可以通过排队、降级或延长时限缓解；业务规则冲突则需要业务方确认规则本身是否仍然有效。
如何按可恢复程度给异常分级
可恢复程度回答的是“这个异常能不能继续往前走、需要付出什么代价”。建议分为五档，从轻到重依次是：自动重试即可恢复、修正输入后可恢复、人工确认后可恢复、需回滚或补偿、不可恢复需终止。分档不按异常类型直接套用，而按四个判断问题依次确认。
| 档位 | 判断问题 | 典型处置 |
|---|---|---|
| 自动重试即可恢复 | 异常由瞬时因素引起，且该步骤可重放、未产生副作用 | 有限次数重试，记录重试次数与结果 |
| 修正输入后可恢复 | 修复所需信息可得，补齐或纠正输入后步骤可重新执行 | 退回上游补数据，修正后重跑 |
| 人工确认后可恢复 | 信息基本齐全，但需要人判断输出是否可用或是否继续 | 转人工复核，确认后放行或退回 |
| 需回滚或补偿 | 已产生副作用，如已写入数据、已发出通知、已占用资源 | 执行回滚、冲正或补偿动作，再决定是否重跑 |
| 不可恢复需终止 | 关键前提已破坏，修复成本高于重新发起，或影响范围不可控 | 终止流程，保留现场，转人工重新发起 |
四个判断问题建议按顺序问：第一，是否已经产生副作用，这决定能不能直接重放；第二，该步骤是否可重放，重复执行会不会造成重复写入；第三，修复所需的信息是否可得，缺的是数据、权限还是业务决策；第四，影响范围有多大，是单条记录、一个批次还是跨系统。顺序很重要，先看副作用可以避免把已写入的步骤当成瞬时故障反复重试。
分级结果需要落到可追踪的载体上。常见做法是为异常建立异常单据或工作项，记录异常类型、可恢复档位、发生环节、处置动作、责任人和处理时间。这样做的价值在于复盘：同类异常反复出现时，可以统计是输入质量问题多，还是工具调用不稳定多，进而决定改上游数据、改接口还是改提示词。在ONES中，这类记录可以借助工作项承载，ONES Assistant能够理解项目、工作项、迭代和Wiki页面等真实工作上下文，并把自然语言指令的结果保存为工作项、Wiki页面等内容，便于把异常分级结论与处置过程留在同一处。具体字段和状态流转需按团队实际配置确定。
类型与可恢复程度如何组合判断
类型和可恢复程度是两个独立维度。类型说明“问题出在哪”，可恢复程度说明“要付出什么代价处理”。同一类型可以落在不同档位，因此不能把类型直接等同于严重程度。
以工具调用异常为例。接口瞬时超时且该步骤未写入任何数据，属于自动重试即可恢复；接口返回结构变化导致解析失败，需要开发确认字段映射，属于修正输入或配置后可恢复；调用已经成功扣减库存但后续步骤失败，则进入需回滚或补偿。再以模型输出异常为例。空返回且未触发下游动作，可以重试；输出格式不合法但内容可读，可以转人工确认；输出已被写入正式文档并对外发布，则需要撤回或更正，属于回滚类处置。
组合判断建议按以下顺序进行：
- 先定影响范围：异常是否已经影响外部对象，涉及单条、批次还是跨系统。
- 再定是否可重放：该步骤重复执行是否安全，是否已有幂等保护。
- 最后定处置人：自动重试由流程执行，修正输入由上游数据责任人处理，人工确认由业务或技术复核人处理，回滚由具备写权限的负责人执行。
需要升级处理的组合情形包括：影响范围跨系统且已产生副作用；同一异常在短时间内重复出现；涉及权限与合规拦截；修复所需信息掌握在多个团队手中。这些情形建议直接进入人工确认或回滚档，并同步通知相关责任人，避免在自动重试中消耗时间。
把类型当严重程度是常见错误。输入异常听起来轻，但如果缺失的是审批所需的关键字段，流程会卡在合规环节；模型输出异常听起来重，但空返回往往只需一次重试。判断严重程度应看副作用和影响范围，而不是看异常名称。
相邻概念区别：与规则自动化异常、接口故障的分工
AI流程异常处理容易与另外两类问题混淆，区分清楚有助于把问题交给正确的处理路径。
| 对比项 | 触发方式 | 典型处置 | 归属 |
|---|---|---|---|
| AI流程异常 | AI执行或决策结果偏离预期，表现不确定 | 按类型与可恢复程度分级处置 | 本文讨论范围 |
| 确定性规则自动化异常 | 预设条件满足或校验不通过 | 走固定分支，如退回、跳过、通知 | 研发流程自动化 |
| 接口连接故障 | 连接失败、鉴权失败、协议不匹配 | 排查连接配置与扩展实现 | 开放接口与扩展开发 |
确定性规则自动化的异常由明确条件触发，处置分支在设计时就已确定，例如字段为空则退回提交人、金额超阈值则转审批。这类问题的重点是编排设计是否覆盖完整，不需要按AI输出的不确定性来分级。接口连接故障关注的是通道是否可用，例如MCP连接建立失败、凭证过期、返回协议不符，处理方式是检查连接配置和扩展代码。
模型质量问题需要单独说明。偶发的输出格式错误可以按流程异常处理；如果同类输出问题持续、批量出现，说明提示词、上下文组织或模型选择存在系统性问题，应转入模型评估与提示词优化，而不是逐条重试。把持续性问题当偶发异常处理，会掩盖真正的原因。
三类问题在同一流程中同时出现时，按发生环节归属：AI生成或决策环节的偏离归AI流程异常；预设条件触发的分支归规则自动化；连接建立和数据传输失败归接口故障。归属清楚后，责任人和修复手段才能对应上。
具体例子与常见误解
以下为演示情景，用于说明判断过程，不对应具体企业真实案例。
某团队用AI辅助处理需求变更：AI读取变更单，判断影响范围，调用项目接口写入关联工作项，并通知相关负责人。运行中出现一次异常：AI已生成影响范围说明，调用写入接口时返回超时，随后重试成功写入，但通知环节重复发出了两条消息。
按本文口径判断：写入接口超时属于工具调用异常；重复通知属于状态与数据异常，因为同一步骤被执行了两次。可恢复程度方面，写入超时未产生副作用时可归入自动重试即可恢复；重复通知已经产生副作用，归入需回滚或补偿，处置动作是撤回重复消息并向接收人说明。记录时分别建立两条异常记录，标注类型、档位、处置动作和责任人。这个例子说明，一次运行中的异常可能分属不同类型和不同档位，需要拆开判断。
常见误解一：所有异常都应自动重试。重试适合瞬时、可重放、无副作用的步骤。对已写入数据或已发出通知的步骤反复重试，会放大重复写入和重复通知的问题。重试前应先确认幂等条件。
常见误解二：模型输出异常等同于模型不可用。空返回、格式不合法、单条事实偏差都属于输出层面的问题，可以通过校验、重试、补充上下文或转人工确认解决。只有持续、批量、多场景出现的输出问题，才需要进入模型评估。
常见误解三：人工介入即代表不可恢复。人工确认是五档中的一档，含义是人来判断输出是否可用，确认后流程可以继续。它与不可恢复需终止不同，后者是前提已破坏、只能重新发起。把两者混为一谈，会导致本可继续的流程被过早终止。
这些误解带来的代价很具体：无差别重试造成重复数据和重复通知；把输出问题当模型故障导致频繁更换模型却不见改善；把人工确认当终止导致流程周期变长、重复发起增多。按类型定位环节、按可恢复程度决定动作，并保留处置记录，才能让异常处理既不过度也不遗漏。
常见问题
AI流程异常和确定性规则自动化的异常，在处置上有什么不同？
确定性规则自动化的异常由预设条件触发，处置分支在设计阶段就已确定，例如字段为空退回提交人、金额超阈值转审批，重点是编排设计是否覆盖完整。AI流程异常源于AI执行或决策结果偏离预期，表现不确定，需要先判断类型和可恢复程度，再选择重试、修正、人工确认或回滚。两者在同一流程中同时出现时，按发生环节归属：AI生成或决策环节的偏离归AI流程异常，预设条件触发的分支归规则自动化。
模型输出异常反复出现，应该逐条重试还是转去做模型评估？
区分偶发与持续。偶发的空返回、格式不合法、单条事实偏差，可以通过校验、重试、补充上下文或转人工确认解决。如果同类输出问题持续、批量、多场景出现，说明提示词、上下文组织或模型选择存在系统性问题，应转入模型评估与提示词优化。把持续性问题当偶发异常逐条重试，会掩盖真正的原因，流程周期也会被拉长。
人工确认属于可恢复还是不可恢复？
人工确认是五档中的一档，含义是由人判断输出是否可用，确认后流程可以继续，属于可恢复。它与“不可恢复需终止”不同，后者是前提已破坏、修复成本高于重新发起，只能终止并转人工重新发起。把两者混为一谈，会导致本可继续的流程被过早终止，重复发起增多。
异常分级结果记在哪里比较合适？
常见做法是为异常建立异常单据或工作项，记录异常类型、可恢复档位、发生环节、处置动作、责任人和处理时间。这样在同类异常反复出现时，可以统计是输入质量问题多还是工具调用不稳定多，进而决定改上游数据、改接口还是改提示词。在ONES中，这类记录可以借助工作项承载，ONES Assistant能够理解项目、工作项、迭代和Wiki页面等真实工作上下文，并把自然语言指令的结果保存为工作项、Wiki页面等内容，便于把分级结论与处置过程留在同一处。具体字段和状态流转需按团队实际配置确定。
已经产生副作用的步骤，还能直接重试吗？
不建议直接重试。重试适合瞬时、可重放、无副作用的步骤。对已写入数据、已发出通知或已占用资源的步骤反复重试，会放大重复写入和重复通知的问题。这类情形应归入需回滚或补偿档，先执行回滚、冲正或补偿动作，再决定是否重跑。判断顺序上先看副作用，可以避免把已写入的步骤当成瞬时故障处理。
