为什么 AI 智能体重试前需要证据

如何防止响应丢失导致重复操作

获准办理一笔退款的客服智能体发出请求后，连接却中断了。智能体没有收到成功确认，于是再次尝试发起退款。如果原始请求已经成功，重复操作就可能导致再次退款。

这纯属假设情境。这个例子说明，有些问题单靠提高模型准确率无法解决。如果智能体无法确定自己先前的操作是否改变了环境状态，它应该采取什么行动？

Unite.AI 曾探讨过模型之外的智能体可靠性。在这些讨论中，恢复问题也值得有专门的规则。智能体再次尝试会产生重大影响的操作前，应先确认实际发生了什么，或确保有有效机制能够防止重复产生影响。

未收到响应并不能证明操作失败

未收到响应并不能证明操作失败。这无法说明错误是在执行前发生的、操作已完成但未收到确认，还是流程仍在进行中。

这是分布式系统中的常见问题，亚马逊对此有所阐述。亚马逊解释了为什么重试机制需要设置具体的防护措施，以避免副作用重复发生。智能体会成为系统恢复流程中一个新的决策主体，还能进一步决定如何从错误中恢复。

这些决策可能改变业务的运作方式。例如，以不同金额重试退款，并不只是再次提交同一请求。同样，如果第一个支付服务停止响应，改用第二个支付服务，也不只是再次提交同一请求。

团队必须区分两种授权：允许执行某项操作，以及允许在结果未知时采取恢复措施。原先的批准并不意味着再次执行该操作就是安全的。

近期研究量化了相关风险

一篇2026年9月的预印本《Where Does Exactly-Once Live?》介绍了 LIMBO 基准，并在九种模型上测试了 25,930 个情节。研究人员在模拟服务中测试了确认信息丢失、处理延迟和重复投递等情况。

在作者的主要测试中，1,279 个产生重复效果的情节里，智能体有 90% 报告称操作已成功完成。因此，即使处理过程出错，智能体仍可能报告成功。

这些结果基于受控基准测试，并不能用于估算生产环境中的故障率。测试中的服务是模拟的，且有多项分析属于探索性分析。团队应将智能体操作的实际结果与其成功执行的报告分别评估。

论文还探讨了为什么检查当前状态可能不够。一项仍在处理中的请求，可能会在检查之后才生效。即使状态响应为空，也不代表该请求最终不会生效。

重复尝试必须对应同一意图

接收请求的服务可以通过幂等键识别针对同一操作的重复尝试。如果得到妥善支持，这种方式可确保重复尝试不会产生额外影响。所有重试过程中，幂等键都必须保持不变。

Stripe 的 API 文档列举了幂等键的实现机制及其局限性。例如，对于 API v1，幂等键可在至少 24 小时后删除。再次使用已清理的键会触发新请求。Stripe 还会核对请求方提供的参数是否与初始请求中的参数一致。

幂等性的实际应用应体现在集成层，而不应只写在提示词中。发送操作前，应记录已获批准的操作，并存储其标识符、确切参数、适用时的服务提供商引用，以及操作状态。

对于退款，应记录批准与原始交易之间的关联，以及服务提供商返回的任何退款标识符。仅凭搜索是否存在同额退款来判断，证据说服力较弱，因为两笔合法请求可能金额相同。退款请求与其出现在搜索结果中之间也可能存在延迟；原始请求仍可能处于执行中。

智能体或工作进程重启时，执行层应保留该操作的身份标识。它应拒绝将修改后的请求作为同一操作提交。此类修改意味着这是一个新操作，按照工作流规则，需要重新作出批准决定。

仅有工具说明并不足够

除了工具说明，还应核实接收服务对幂等支持的约定。测试其实现，以确认实际满足了哪些保证。

将不确定性视为一种运行状态

图 1：针对重大操作提出的恢复流程。每次重试都需要当前有效的授权。

确认已完成，意味着工作流会记录结果并继续执行，而不会重复该操作。确认未执行后，只有在原始请求已无待处理状态且授权仍然有效时，才允许再次尝试。

对于结果尚未确定的情况，还有许多因素需要考虑。如果服务提供方提供了有效保证，确保不会产生重复效果，你可以允许使用同一个键重试原始请求。否则，应暂停写入，并通过查询状态、联系服务提供方支持团队或交由获授权的操作人员来查明情况。检查结果不明确，不足以成为授权再次尝试的理由。

如果服务提供方说明了处理时限和结果可见时限，暂停操作也可能是合理的。若没有这些时限，仅凭时间流逝无法确认该操作未曾执行。你必须明确由谁负责处理尚未解决的个案，以及负责人必须在何时进行复核。

从失败中恢复可能需要采用不同的业务流程

如果退款已成功，但随后发送给客户的通知失败，重做整个工作流可能会再次退款。恢复流程应着重完成尚未完成的步骤，同时保留已完成工作的记录。

如果需要纠正先前已完成的操作，Microsoft 提供了有关补偿性交易的指导。每个应用都要自行确定纠正错误的适当方式。补偿措施未必能让事情恢复到原来的状态，而且补偿本身也可能失败。

此外，取消交易可能会产生费用。更正一条消息，也无法确保没有人看过早先的版本。因此，任何恢复操作都必须明确限制代理可以撤销、修改或承诺的事项。超出这些限制的决定必须交由具备相应权限的人员处理。

部署前测试再次尝试

选择一个影响重大的工具，并在测试环境中有计划地进行恢复测试。成功执行后，丢弃对原始请求的响应。将第一个请求的执行延迟到状态检查之后。在恢复过程中，重启工作进程。等待密钥保留期限届满后再试。多次尝试期间，修改一个参数。

评估最终生成的业务记录，而不要只依赖工具的响应。记录重复效果、尚未解决的操作、遗漏的工作、恢复时间以及额外的人工干预。计算每项正确完成任务的成本时，应计入工作流的全部成本，包括交易冲正和对客户的补救措施。

此外，还要测试一个与原始请求类似、但确属新的请求。确保系统能够避免重复创建，同时不会阻止新工作。应分别评估避免重复和最终完成任务的能力。否则，一个终止所有任务的代理可能看起来很安全，实际却几乎没有或完全没有价值。

评估问题应明确表述。系统能否解释：

• 获准执行的是哪项操作？
• 有哪些证据能够证明操作结果？
• 为什么可以再次尝试？

在演示过程中，因不确定性尚未消除而暂停的代理可能显得效率较低。然而，在生产环境中，暂停操作有助于保留客户的原始意图。有效的持久执行意味着系统能够完成获授权的任务，同时不会在不明示的情况下重复执行。