Agent 接口失败后，怎样重试、续跑并避免重复执行？

接口超时，只说明调用方没有拿到明确结果，不能据此认定邮件未发、客户未建或订单未写。安全恢复要先核对业务动作状态：确认完成的保留回执；确认未执行且允许重试，或目标接口提供已验证且仍有效的幂等保障时，才按约定重试。其余未知状态先查询、挂起或转人工对账。批量续跑也应以每项业务结果为依据，不能只依赖循环进度或把整个工作流再跑一次。

这篇文章适合已经连接或准备联调外部系统的团队。重点是副作用——发送、创建、修改等真实动作——能否被识别、对账和恢复。界面显示“执行失败”与外部系统没有产生影响，是两件需要分别取证的事。

先分成功、确定未执行和结果未知

查询一次“未找到”也未必足以证明没有执行：目标系统可能延迟可见，或请求仍在处理中。应核对该接口的状态语义、查询条件和时间范围。若没有可靠查询或去重能力，高影响动作可以停止自动重试，交由有权人员确认；不能靠换一个新编号再发一次来绕过未知状态。

HTTP 语义规范限制对非幂等请求的自动重试：需要知道请求本身可安全重复，或能确认原请求没有应用。幂等指多个相同请求产生的预期效果与单次请求相同，响应内容仍可能不同；不是所有接口都有这种保证。参阅：RFC 9110 第9.2.2节。

一个业务动作与多次尝试，分别编号

为业务动作保留稳定标识，再为每次执行尝试单独记录。重试同一意图时沿用原动作关系；若输入或批准内容改变，应按业务规则形成新的动作，并先处理原动作的未知状态。动作标识不能只靠模型每次自由生成，也不能仅凭两次文字相似就判断重复。

AWS Builders’ Library 讨论了用明确请求标识表达意图、参数变化和迟到请求的处理。它说明去重需要接口约定与保留边界，不是“加一个编号”就能保证任意跨系统流程恰好执行一次。参阅：Making retries safe with idempotent APIs。

重试策略要说明哪些错误能重试，何时停

临时故障、速率限制、授权失效、字段错误和业务拒绝，需要不同处置。可以自动重试的路径，应同时限定次数或截止时间、等待方式、状态查询和告警责任；目标服务明确返回等待要求时，按其协议处理。不能把每类错误都交给模型不断“再试一下”。

还要核对重试发生在哪一层：客户端、代理、队列与工作流可能都在重试。同一个用户动作被多层重复发送时，即使单层设置了有限次数，也可能增加实际请求和副作用。并发执行、迟到响应、旧进程恢复都应关联到同一业务动作。

批量续跑保存的是每项结果，不能只保存“做到第几条”

批次恢复示例（非真实运行日志）：设一批10项：6项已确认完成，2项确认未执行并可按批准规则重试，1项结果未知，1项等待人工批准。初始对账为10＝6＋2＋1＋1。重试的2项确认完成后，只能记8项完成，另1项未知、1项待批准；不能因为恢复流程结束，就把整批记为成功。

检查点应指向可核实的业务状态，并在进程中断后仍能取得。只把“第7条”存在运行内存里，无法证明前6条已写到哪里。并行或乱序任务更需要逐项状态，不能用最后一个序号代表前面全部完成。

人工处理后，应把实际结果与原动作台账关联，再允许自动流程恢复。交接时确认是否仍有旧尝试在执行，避免人工和自动流程同时重做。不能只让操作员在聊天里说“已处理”，却不给下一次续跑提供可核对状态。

平台有“重试”按钮，也要核对它重跑了什么

例如 n8n 官方文档区分使用当前保存的工作流与原工作流重试，两者都使用先前执行数据。该说明不能证明任意节点、循环内部或外部副作用都会从安全检查点恢复。实际版本、执行数据保存与重跑范围仍须核对。参阅：n8n View all executions / Retry failed workflows。

恢复前确认使用哪个流程版本，旧输入是否仍有效，审批和权限是否变化。修复流程以后直接拿旧数据重试，可能把新逻辑作用到原来已经部分完成的动作上。若平台的执行历史会清理或随工作流删除，应在项目约定中明确业务台账与排障记录怎样保留，不能把可恢复性完全寄托在一个界面列表。

用故障演练验证真实副作用，再决定开放范围

1. 请求发出前失败：确认目标未受影响，恢复动作与台账一致。
2. 目标已执行但响应丢失：先查出已有结果或使用目标支持的去重约定，不产生第二次同意图效果。
3. 执行中进程重启、重复投递或两个工作者并发：已完成和处理中任务不会被不受控重复执行。
4. 结果查询延迟、旧响应迟到或去重记录过期：未知状态仍可定位和人工接管，不被误记为失败后盲重试。
5. 批次中途失败并人工处理一项：恢复时逐项对账，人工结果不会被后续自动步骤覆盖或重做。

演练使用获准测试对象和环境；保存请求、回执、目标记录、恢复步骤与结果的关联。验收不仅看工作流最后是否绿灯，还要去目标系统核对是否重复、遗漏或出现未批准变更。无法安全制造真实副作用时，可以先做模拟测试，但模拟结果不能代替目标接口的联调证据。

已经发出的邮件通常不能靠回退数据库撤销。取消订单、冲正或补偿写入也可能是一笔新的业务动作，需要自己的授权与回执。恢复目标是明确事实并控制后续动作，不能承诺所有副作用都可以还原。

准备连接实际系统时，先核对接口与授权清单；人工批准与执行对应关系，可接着看Agent 动作怎样保留人工审批与审计。实际的重试、恢复与对账链路，可按企业 AI 项目落地范围在目标系统中验收。