AI 智能体为何需要在重试前先确认证据

如何防止丢失的响应变成重复操作

一名有权生成一笔退款的客服人员发送了请求，但连接中断。该客服人员没有收到成功确认，于是尝试再次发送退款。如果最初的请求已经成功，那么该客服人员的重复操作可能会导致第二笔退款。

这纯粹是假设。该示例所代表的问题无法仅靠模型准确性来解决。如果智能体无法确定其先前的操作是否改变了环境状态，它应该采取什么行动？

Unite.AI 已探讨过超越模型的智能体可靠性。在这些讨论中，恢复问题理应拥有自己的规则。在第二次尝试执行有后果的操作之前，智能体应确认发生了什么，或者拥有针对重复影响的有效保证。

未返回的响应并不能证明某个操作已经失败。它既不能表明错误是否发生在执行之前，也不能表明操作是否已在没有确认的情况下完成，或者进程是否仍在进行中。

正如亚马逊所描述的那样，这是分布式系统中的一个常见问题。亚马逊解释了为什么重试机制需要针对重复副作用采取特定的防护措施。智能体为系统的恢复路径增加了一个新的决策实体。它们可以就如何从错误中恢复做出额外决策。

这些决策可能导致业务运营方式发生变化。例如，以不同的金额重试退款，并不只是同一请求的又一次迭代。同样，当第一个支付服务停止响应时选择第二个支付服务，也不只是同一请求的又一次迭代。

团队必须区分授予执行某项操作的权限与授予从未知结果中恢复的权限。最初的批准并不意味着再次执行该操作是安全的。

近期研究衡量了这一风险

2026年9月的一篇预印本《Where Does Exactly-Once Live?》提出了LIMBO基准，并在九个模型上测试了25,930个episode。其模拟服务在确认丢失、处理延迟和重复投递的情况下接受了测试。

在作者主测试中产生重复副作用的1,279个episode里，智能体有90%报告成功完成。因此，即使发生了错误处理，智能体也可能报告成功。

这些结果基于受控基准测试，并不估计生产环境中的故障率。这些服务是模拟的，若干分析属于探索性分析。团队应将智能体行动的结果与其关于成功执行的报告分开评估。

该论文还讨论了为什么检查当前状态可能不够充分。仍在处理中的请求可能在检查之后生效。即使状态响应为空，也不意味着该请求最终不会生效。

接收服务有一种方法，可通过幂等键识别对同一操作的重复尝试。如果得到正确支持，该方法可确保重复尝试不会产生额外影响。幂等键必须在所有重试期间保持稳定。

Stripe 的 API 文档提供了幂等键的机制与局限性的示例。对于 API v1，键在至少 24 小时后可以被删除。再次使用已清除的键将导致新的请求。Stripe 还会验证请求者提供的参数与初始请求中的参数是否匹配。

幂等性的整体实际应用在于它存在于你的集成层中，而不仅仅存在于提示词中。在派发操作之前，先记录已批准的操作。存储其标识符、确切的参数、适用时的提供商参考以及操作状态。

如需退款，请将批准与原始交易的关联以及任何返回的提供商退款标识符一并存储。搜索相同金额的任何退款说服力较弱，因为两个合法请求可能金额相同。退款请求与其出现在搜索结果中之间也可能存在延迟。原始请求可能仍在运行。

当智能体或工作进程重启时，执行层应保留该身份。它应拒绝作为同一操作提交的修改后请求。此类更改代表一个新操作，根据工作流规则需要新的批准决定。

仅靠工具描述是不够的

除工具描述外，还要核实接收服务的契约是否支持幂等性。测试其实现，以确认实际满足了哪些保证。

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

图1. 针对有后果操作提出的一条恢复路径。每次重试同样需要当前授权。

已确认完成意味着工作流将记录结果并继续执行，而不重复该操作。已确认未执行则允许再次尝试，但前提是不存在任何仍处于待处理状态的原始请求，且授权仍然有效。

关于未解决的结果，还有更多需要考虑的因素。如果存在提供商支持的、针对重复影响的有效保证，你可以允许使用同一键重试原始请求。否则，应暂停写入，并通过状态查询、提供商支持或经授权的操作员进行核对。无定论的检查不足以构成授权再次尝试的充分理由。

当提供商记录了处理与可见性边界时，暂停也可以是有正当理由的。没有这些边界，仅凭经过的时间无法确认该操作未被执行。你必须界定未解决案例的归属方，以及这些归属方必须在何时审查它们。

如果退款成功，但随后的客户通知失败，重复整个工作流可能会导致重复退款。恢复应侧重于完成未完成的步骤，同时保留已完成工作的证据。

如果需要对先前已完成的操作采取纠正措施，Microsoft 提供了有关补偿事务的指导。每个应用程序决定补偿错误的正确方式。补偿不一定能把事情恢复到初始状态，而且补偿本身也可能失败。

此外，取消交易可能会产生费用。更正消息无法确保某人没有看到较早的版本。因此，任何恢复活动都必须明确限制智能体可以撤销、更改或提交的范围。超出这些限制的决策必须转交给具有必要权限的人员。

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

评估最终生成的业务记录，而不是仅仅依赖工具响应。记录重复影响、未解决的操作、遗漏的工作、恢复时间以及额外的人工干预。使用总工作流成本（包括交易冲正和客户补救）计算每个正确完成任务的成本。

此外，测试一个与原始请求类似的真实第二请求。确保你的系统在避免创建重复项的同时不会阻止新工作。分别评估重复避免情况和最终任务完成情况。否则，一个终止所有任务的智能体可能看起来是安全的，却几乎或完全没有提供价值。

你的评估问题应清晰陈述。系统是否能够解释：

哪项操作获得了授权？

存在什么证据来证明其结果？

为什么允许再次尝试？

因未解决的不确定性而暂停的智能体在演示中可能显得效率较低。然而，在生产环境中，暂停可以保留客户的原始意图。有用的持久性意味着系统在完成授权任务时，不会在暗中重复执行这些任务。