AI流程出现异常时，处理顺序比工具选择更关键：先把异常限定到具体环节，记录现场信息；再按假设逐条取证排除；随后按影响分级处置，该重试的重试、该转人工的转人工、涉及数据写入的先停下来；恢复后用同一输入回归并抽样比对，最后把根因和新增校验写回流程。本文覆盖AI驱动执行环节的异常处理，确定性规则配置与接口连接实现不在重点范围内。
要点总览（TL;DR）
- 先把异常拆到具体环节：输入解析、模型输出、工具接口、规则判定、人工审批、下游写入，并记录时间、输入样本、模型与提示版本、调用链路和影响范围。
- 原因在验证前只是假设，按先外部依赖与变更、再输入与提示、最后模型能力边界的顺序逐条取证，每条假设留下证实、证伪或暂未排除的结论。
- 处置按影响分级：单条异常幂等重试后转人工，批量异常暂停并降级，涉及下游写入先停止写入、保留现场与备份，回滚需审批。
- 恢复后用同一输入回归并对同类任务抽样比对，确认失败率、转人工率、重试次数、处理时延回到基线，再退出降级通道。
- 把根因、处置动作和新增校验写回流程文档与版本记录，指定复发监测责任人和复查周期，形成闭环。
先界定异常：AI流程里哪些表现算异常
“AI流程异常”是一个笼统说法，落到排查时需要拆成可观察的症状。同一个失败现象，可能来自输入解析、模型输出、工具调用、规则判定、人工审批或下游写入中的任一环节。先分类，才能把排查范围收窄到一两个环节，避免一上来就怀疑模型能力。
按环节划分，常见症状可以归为六类：输入解析失败，表现为文档格式不识别、字段缺失、抽取结果为空；模型输出偏离预期，表现为答非所问、格式不符合约定、结论与输入事实矛盾；工具或接口调用失败，表现为超时、返回错误码、权限被拒；规则判定冲突，表现为同一输入在相似条件下得到不同判定，或阈值附近频繁翻转；审批卡滞，表现为任务停在待审状态无人推进、审批人缺失；下游写入错误，表现为状态未更新、字段写错、重复写入。
每一类症状都需要留下可复盘的现场信息，否则后续只能凭印象归因。建议至少记录五项：发生时间与时间窗口、触发异常的原始输入样本、当时使用的模型版本与提示版本、完整调用链路（经过哪些工具与接口）、影响范围（单条、一批还是已波及下游）。
| 症状类别 | 典型表现 | 需记录的现场字段 |
|---|---|---|
| 输入解析失败 | 格式不识别、字段缺失、抽取为空 | 原始文件、解析器版本、失败字段 |
| 模型输出偏离预期 | 答非所问、格式错误、与事实矛盾 | 输入样本、模型与提示版本、原始输出 |
| 工具/接口调用失败 | 超时、错误码、权限拒绝 | 接口名、请求参数、响应码、调用时间 |
| 规则判定冲突 | 相似输入判定不一致、阈值附近翻转 | 规则版本、阈值、判定输入与结果 |
| 审批卡滞 | 任务长期待审、审批人缺失 | 审批节点、审批人、停留时长 |
| 下游写入错误 | 状态未更新、字段写错、重复写入 | 目标系统、写入记录、影响条数 |
分类之后还要区分单次偶发与批量系统性异常。判断依据是同一时间窗口内同类症状的出现频次、是否集中在某一输入类型或某一环节、是否伴随近期的版本或配置变更。单次失败先保留样本观察，批量出现则立即进入原因排查并考虑临时处置。
原因假设与排除证据：逐条验证再下结论
异常原因在验证之前都只是假设。把“模型能力不行”直接当结论，往往会掩盖真正的输入质量问题或接口权限失效。可行的做法是先列出候选假设，为每条假设指定能证实或证伪的证据，再按由外到内的顺序逐条排除。
排查顺序建议先排除外部依赖与近期变更，再查输入与提示，最后才评估模型能力边界。外部依赖和变更最容易验证，也最常是真正原因；模型能力问题验证成本最高，放在最后可以避免过早下判断。
| 原因假设 | 验证证据与取证方式 | 排查顺序 |
|---|---|---|
| 输入数据质量问题 | 抽取失败样本人工核对原始文件；统计失败样本的格式、字段完整度分布 | 第2步 |
| 提示或上下文设计缺陷 | 用同一输入在旧提示版本下重跑对比；检查上下文是否被截断或混入无关内容 | 第3步 |
| 模型版本或参数变更 | 核对变更记录与异常发生时间是否吻合；用旧版本重跑同一批样本 | 第1步 |
| 工具/接口超时或权限失效 | 查看接口响应码与耗时日志；用相同凭证单独调用验证权限 | 第1步 |
| 规则阈值不合理 | 取阈值附近的判定样本，检查是否存在集中翻转；对比历史阈值 | 第3步 |
| 人工审批环节遗漏 | 核对审批节点配置与审批人名单；检查是否有任务绕过审批直接流转 | 第2步 |
每条假设的验证要留下结论：证实、证伪或暂未排除。证实后仍需确认它能否解释全部症状，只解释部分症状说明可能还有叠加原因。暂未排除的项要写明下一步取证动作和责任人，不能因为当前处置已生效就默认它不存在。
区分偶发失败与系统性缺陷，可以看三个信号：同一输入重复执行是否稳定复现；失败是否集中在特定输入类型、特定时段或特定环节；失败率相对基线的偏移是否持续。稳定复现且集中出现的，按系统性缺陷处理；偶发且无集中特征的，先记录样本、设置观察窗口，同时保留现场以便复现。
按影响分级处置：重试、转人工、降级与停止写入
处置动作的风险差别很大，重试一条任务和回滚一批已写入的数据完全不是一回事。分级的口径按影响范围确定：仅影响单条结果、影响一批任务、影响下游数据或对外交付。级别越高，处置越要先控制影响面，再谈修复。
| 影响级别 | 典型情形 | 处置动作 | 停止点与回退条件 |
|---|---|---|---|
| 单条结果异常 | 个别任务输出错误或调用失败 | 幂等重试；仍失败则转人工复核 | 重试达到上限即停止，转人工 |
| 一批任务异常 | 同类症状集中出现，影响一个批次 | 暂停该批次自动执行，降级到确定性规则或人工通道 | 确认原因并修复后再恢复批量执行 |
| 影响下游数据 | 错误结果已写入下游系统或状态 | 立即停止写入，保留现场与备份，评估已写入范围 | 完成影响范围核对与回滚方案审批后再操作 |
| 影响对外交付 | 错误结果已进入对外交付物 | 停止交付流程，通知相关方，启动人工复核 | 复核通过并留痕后方可继续交付 |
可重试的前提是操作幂等，即重复执行不会产生重复写入或重复扣减等副作用。不满足幂等的操作，重试前要先确认上一次执行的实际状态。重试需要设上限和间隔，达到上限仍失败就转人工，避免无限重试掩盖问题、放大下游压力。
输出不可信时转人工复核，交接要带齐字段：原始输入、模型输出、异常症状、已尝试的处置、怀疑原因。判定人应是具备该业务判断权限的角色，复核结论要回写到任务记录，作为后续验证和复盘的依据。
链路中断时，降级到确定性规则或人工通道可以维持流程运转，但要明确降级期间的输出标记，避免降级结果被当作正常结果流入下游。涉及数据写入或状态变更的异常，第一步是停止写入并保留现场，包括当前数据快照、写入日志和待处理队列；回滚或修正操作需要经过审批，并在操作前后各留一份备份。所有处置动作，包括谁在什么时间执行了什么、结果如何，都应记录在案。
异常从发现、定级、处置到复核，往往涉及多个角色和多次状态流转。这类流转和记录可以承载在 ONES 的工作项与 Wiki 中：把异常登记为工作项，按级别设置处理状态与责任人，处置结论和复盘文档沉淀到 Wiki 页面，使过程可追踪。ONES Assistant 可基于项目、工作项与 Wiki 上下文回答问题并执行操作，把结果保存为工作项或 Wiki 页面，适合在异常处置过程中减少重复录入和页面切换。
恢复验证与复发预防：怎么确认真的修好了
处置生效不等于问题解决。恢复验证要回答两个问题：原来的异常输入现在能否正常处理，同类任务是否也恢复正常。验证通过后，还要把这次异常转化为流程里的新增防线，否则同类问题会以相似方式再次出现。
恢复验证按以下清单执行：
- 用触发异常的同一输入样本重跑，确认输出符合预期，且格式与字段完整。
- 对同类任务抽样比对，样本覆盖不同输入类型和边界条件，确认没有引入新的偏差。
- 核对监控指标是否回到基线：失败率、转人工率、重试次数、处理时延。指标未回基线说明修复不完整或存在叠加原因。
- 确认降级通道已退出、临时规则已撤销，流程回到正常执行路径。
防复发措施围绕四个校验点展开：输入校验，在解析后检查必填字段与格式，不合格的输入提前拦截；输出置信度阈值，低于阈值的输出自动转人工而非直接放行；接口健康检查，对关键依赖设置定时探测与超时告警；审批兜底，对高风险操作保留人工确认节点。这些校验点按本次根因选择性增加，不必一次性全部上线。
根因、处置动作和新增校验要写回流程文档，并同步更新提示版本或规则版本的变更记录，注明变更原因和生效时间。复发监测需要指定责任人和复查周期，例如由流程负责人按周查看同类症状的出现频次，连续若干周期无复发后再降低监测频率。复盘记录可沉淀在 ONES Wiki 中，与对应工作项关联，便于后续追溯和交接。
常见问题
异常只出现一次，需要立刻按系统性缺陷处理吗？
不必立刻升级处理。先判断三个信号：同一输入重复执行是否稳定复现、失败是否集中在特定输入类型或环节、失败率相对基线的偏移是否持续。偶发且无集中特征的，记录样本、设置观察窗口，同时保留现场以便复现；稳定复现且集中出现的，按系统性缺陷进入原因排查并考虑临时处置。
重试看起来最简单，什么情况下不能直接重试？
重试的前提是操作幂等，即重复执行不会产生重复写入、重复扣减等副作用。不满足幂等的操作，重试前要先确认上一次执行的实际状态。另外重试要设上限和间隔，达到上限仍失败就转人工，避免无限重试掩盖问题、放大下游压力。
降级到人工通道期间，产出结果怎么处理？
降级可以维持流程运转，但降级期间的输出要明确标记，避免被当作正常结果流入下游。同时记录降级开始时间、涉及任务范围和恢复条件，恢复后对降级期间产出的结果做抽样复核，确认无误后再并入正常流程。
已经写入下游的错误数据，处置顺序是什么？
第一步是停止写入并保留现场，包括当前数据快照、写入日志和待处理队列；第二步评估已写入范围，确认影响条数；第三步制定回滚或修正方案并经过审批，操作前后各留一份备份；最后核对影响范围，确认下游数据一致后再恢复写入。
ONES 在异常处置过程中能承担哪些环节？
异常从发现、定级、处置到复核涉及多个角色和多次状态流转，这类流转可以承载在 ONES 的工作项中，按级别设置处理状态与责任人；处置结论和复盘文档可沉淀到 ONES Wiki 并与对应工作项关联，便于追溯和交接。ONES Assistant 可基于项目、工作项与 Wiki 上下文回答问题并执行操作，把结果保存为工作项或 Wiki 页面，减少处置过程中的重复录入和页面切换。
