Agent 遇到异常怎么办？重试、挂起与转人工

先给结论：Agent 异常不能只有“成功/失败”两种结果，更不能遇到问题就无限重试。 正确做法是先判断异常类型，再选择回读、有限重试、等待、挂起或转人工；没有权威终态之前，任务始终保持开放。

这套方法适合跨 CRM、ERP、审批、消息、外部门户的多步任务；一次纯查询失败可以直接返回错误，不必建立复杂队列。若业务没有明确责任人和“怎样算处理完成”，异常队列只会变成另一个没人看的收件箱。

先按结果语义分流

异常类型	典型表现	正确处置	禁止动作
结果未知	超时、连接中断，不知是否已写入	先按幂等键或业务唯一键回读	直接重新提交
临时技术故障	限流、短暂不可用、可恢复网络错误	仅对可安全重放动作有限重试	无限退避、无上限重试
业务校验失败	字段缺失、状态不允许、规则不通过	挂起并指出缺什么	反复调用同一接口
权限或审批失败	无对象权限、批准缺失或过期	拒绝执行，转有权人或重新审批	借用高权限账号绕过
数据冲突	两个权威源不一致、对象版本已变化	进入冲突队列，由责任岗位裁决	Agent 猜一个“更像真的”
外部等待	客户回执、审批、银行或门户状态未返回	保存等待条件和下次检查时间	把“已通知”标成完成
无法核验	读取路径不可用、对象无法定位	标记 UNVERIFIABLE 并转人工	计入成功率

分流顺序很重要。首先判断是否可能已经产生副作用；若结果未知，先回读。其次判断错误是否临时且动作能否幂等重放；只有两个条件同时满足，才进入重试。剩余问题交给等待或人工队列。

重试必须同时满足 4 个条件

1. 失败属于临时故障，不是权限或业务规则拒绝。
2. 动作有幂等键，或有可查询的业务唯一键。
3. 重试次数、间隔和总时限有明确上限。
4. 每次重试使用同一任务与同一幂等语义，不生成新的业务意图。

例如 Agent 创建项目任务时连接中断，如果项目系统支持外部任务号，应先按外部号查询；查到就继续核对字段，查不到才重试。若是“追加一条备注”且没有唯一键，则宁可转人工，也不能冒险追加两次。

异常队列不是错误日志

一条可处理的异常记录至少包括：原任务 ID、业务对象 ID、当前状态、异常类型、最后一次成功步骤、请求与回执摘要、已重试次数、建议动作、责任角色、到期时间、恢复条件和最终验收谓词。

队列应按责任分开：接口故障给 IT，业务校验缺口给对象负责人，金额或账务冲突给财务，权限问题给管理员或审批人，对外承诺冲突给业务负责人。只建一个“Agent 异常群”，最后通常是谁都看见、谁都不负责。

挂起、转人工和复开

挂起表示任务仍然有效，只是在等待条件；转人工表示下一步需要人做裁决或补证。两者都不应被记成失败终态。

人工处理界面应给出最窄决策：补哪个字段、接受哪个版本、是否重放、是否撤销，而不是把整段运行日志扔给员工。人工提交结果后，Agent 从最近安全断点继续执行；若对象在等待期间已经变化，原批准失效，重新校验。

关闭异常也不能靠人点“完成”。例如客服负责人处理了退款冲突，系统还要回读退款到账、订单状态和客户工单；只有验收谓词成立才关闭。后续权威状态再次冲突时，同一异常应复开并保留前次处置链。

用覆盖率防止异常被藏起来

批量任务报告必须同时显示应处理数、已核验数、未核验数，并提供未核验清单。只汇报“已处理多少条”，会把连接失败和无法读取静默省略，形成假完成。

异常处理应与写后回读 6 步配套；跨天等待和断点恢复可继续看Agent 长任务治理。准备把这套机制接入真实系统时，可从AI Agent 落地能力先确定对象、责任岗位、重试边界和权威终态。