智能体工作流失败后，什么时候该停止重试？

智能体工作流遇到失败，不宜统一设置“再试一次”。建议先区分临时故障、输入或权限问题，以及外部操作结果不明，再明确尝试次数、总耗时、费用和接手责任。以下依据官方资料整理，未做产品实测。

先判断：失败的是请求，还是业务结果？

假设智能体已向客户系统提交一张工单，却在等待响应时超时。此时能确认的是调用方没有按时拿到结果，不能直接确认工单没有创建。AWS的工程经验文章也提醒：超时或失败并不意味着远端副作用尚未发生，重试还可能加重已过载系统的负担。[1]

编辑建议：把失败先分成三类。临时连接故障，在接口允许且操作可安全重复时才进入重试；输入错误或权限不足，先修正条件；写入结果不明，先凭业务标识查询外部记录。无法查清时暂停并交接，不让模型凭猜测继续创建。具体错误码如何分类，以目标接口说明为准。

别把框架默认值当作业务承诺

Temporal文档区分Activity和Workflow Execution：前者默认有关联的重试策略，后者默认没有。其策略可以配置最大尝试次数、退避及不可重试错误等规则。[2] 这些是该框架的行为，并不意味着所有智能体平台都采用相同默认值。

建议逐项检查模型SDK、工具客户端和工作流引擎由哪一层负责重试，避免同一故障在多层重复尝试。对关键操作写清总尝试次数是否包含首次执行、最长允许等待多久，以及业务失效后如何停止。次数和时长应按实际任务确定，不照搬一套通用数字。

幂等键也有适用范围

Stripe提供了一个具体例子：在API v1中，端点开始执行后会保存同一幂等键的首次响应，后续同键请求会返回已保存响应，包括500错误；同键参数不一致会报错，键被清理后再次使用则可能产生新请求。[3] 因此“带了键”不能简化为“可以无限重试直到成功”。

编辑建议：把同一次业务操作的标识保留下来，核对接口支持范围、有效期和参数一致性。结果不明时，不要仅为了绕过旧错误就生成新键。接口不支持幂等时，需要结合业务唯一约束、查询和人工核对设计处理方式；单独在本地记录“已执行”也不能证明远端一定成功。

用一张停止规则表控制时间与成本

可以直接填写：操作名称｜允许重试的条件｜最多总尝试次数｜总等待上限｜可用费用预算｜外部结果查询方式｜停止后的状态｜接手人。费用预算应覆盖可能重复发生的模型或工具调用；如何计费需查所用服务，本文不假定每次失败都收费。

再用测试环境演练三类情形：临时故障后恢复、持续失败直到达到上限、写入成功但响应丢失。记录尝试次数、累计耗时、外部实际结果，以及可获取的费用数据。预算无法实时精确获取时，应标明估算口径，并配合调用次数或平台额度限制，不能声称已实现精确金额熔断。

停止时向接手人提供任务标识、最后确认的状态、错误摘要和建议核对的外部记录，避免转交密钥或敏感原文。由业务负责人定义何时不再值得重试，工程负责人落实停止规则，运营或支持人员负责后续跟进；小团队可以兼任，但不能遗漏责任。停止本地重试不等于已取消远端操作，接手人仍需核对最终业务状态。

适用条件与限制

本文是依据2026年10月15日可访问资料整理的运行设计建议，未验证任何项目的具体配置。Temporal行为仅限引用文档；Stripe示例仅讨论API v1，不能推广到v2或其他服务。AWS资料为工程经验。重试规则不能保证零重复操作或零费用，仍需在授权测试环境验收。