💻 computer science

Robust Agent Compensation (RAC): Teaching AI Agents to Compensate

本文介绍了鲁棒代理补偿（RAC），这是一种基于日志的恢复范式，可集成到 LangChain 等现有代理框架中，为可靠执行提供安全网，并在复杂基准测试中展现出优于最先进恢复方法的延迟和令牌经济性表现。

原作者： Srinath Perera, Kaviru Hapuarachchi, Frank Leymann, Rania Khalaf

发布于 2026-05-06

📖 1 分钟阅读☕ 轻松阅读

原作者： Srinath Perera, Kaviru Hapuarachchi, Frank Leymann, Rania Khalaf

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

以下是用通俗易懂的语言和日常类比对论文《鲁棒代理补偿（RAC）》的解释。

问题：人工智能中的“哎呀”时刻

想象你雇佣了一位非常聪明但有点笨拙的旅行代理（人工智能代理）为你预订行程。他们成功预订了你的航班和酒店。但随后，当他们尝试预订租车时，系统崩溃了。

灾难性后果： 你现在手里握有已确认的航班和酒店，却没有车。你为无法使用的服务付了款，整个行程也被毁了。在人工智能领域，这被称为“意外副作用”。代理失败了，却留下了它没有清理的烂摊子。

当前的 AI 代理就像那个笨拙的代理：一旦陷入困境，它们往往只是停止运行，却留下了已确认的航班和酒店。它们不知道如何“撤销”已经做过的事情。

解决方案：RAC（“撤销”按钮）

作者提出了一种名为鲁棒代理补偿（RAC）的新系统。你可以将 RAC 想象成位于 AI 代理下方的一个超级安全网，或者一个数字版的“撤销”按钮。

RAC 不是要求 AI 自己去想办法修复错误（它经常搞错），而是像一个严格的项目经理，详细记录代理采取的每一个步骤。

工作原理（类比）

想象 AI 代理是一位正在烹饪复杂菜肴的厨师。

日志： 当厨师切洋葱、烧水、煎牛排时，RAC 就像一名书记员，在笔记本上写下每一个动作。
失误： 厨师把牛排煎糊了。
恢复：
- 旧方法（无 RAC）： 厨师惊慌失措，也许试图刮掉烧焦的部分，或者直接端上烧焦的牛排。这顿饭就毁了。
- RAC 方法： 书记员看到了烧焦的情况。RAC 立即告诉厨师：“停下！我们需要撤销最后三个步骤。”
- RAC 查看日志，找到“煎牛排”这一步，并说：“好的，我们需要逆转这个操作。”然后，它寻找一个“补偿”动作（例如“扔掉烧焦的牛排并退款”）。
- 如果厨师无法修复牛排，RAC 会退得更远：“好的，撤销烧水。”然后，“撤销切洋葱。”
- 结果： 厨房完全回到了厨师开始之前的样子。没有焦味，没有浪费金钱。系统保持整洁。

三步安全计划

当 AI 代理失败时，RAC 不会轻易放弃。它遵循一个严格的三步计划：

重试： “也许只是个小故障。让我们再试一次那个步骤。”
寻找替代方案： “好吧，第一个工具失败了。让我们尝试用不同的工具来完成同样的工作。”
补偿（撤销）： “好吧，我们无法修复它。让我们回头，按相反顺序取消我们到目前为止所做的所有操作，这样就不会留下烂摊子。”

为什么这比其他方法更好

该论文将 RAC 与处理错误的两种其他方法进行了比较：

“直接问 AI"的方法（ReAct）： 这就像问那位困惑的厨师：“嘿，你把牛排煎糊了，你该怎么办？”厨师可能会产生幻觉（编造内容）或因复杂性而困惑。这种方法既慢又不可靠。
“先规划一切”的方法（SagaLLM）： 这就像一位厨师在烹饪任何东西之前，试图先写出一本完美的 50 页食谱书。如果烤箱在途中坏了，厨师必须从头开始重写整本 50 页的书。这需要耗费大量的时间和能量（Token）。

RAC 是“金发姑娘”式的完美方案：

它不依赖 AI 去“思考”如何摆脱灾难（这既慢又容易出错）。
它不需要每次出错时都重写整个计划。
它只需检查日志，逆转导致混乱的特定步骤，并让计划的其余部分继续推进。

结果：更快、更便宜

作者在困难的任务（如预订行程和安排工作）上测试了 RAC，这些任务被设计为容易出错。

速度： 与“先规划一切”的方法相比，RAC 的速度快了1.5 到 8 倍。
成本： RAC 使用的"Token"（AI 思考的货币）显著更少。因为它不会在每次发生小错误时都浪费时间重新规划整个世界，所以节省了大量的金钱和时间。
可靠性： RAC 确保当事情失败时，系统处于清洁状态，没有遗留的扣款或损坏的预订。

“魔法”成分：日志

RAC 的秘诀在于事务日志。

在过去，开发人员必须编写复杂的代码来告诉 AI 如何撤销每一种可能的错误。这就像告诉厨师：“如果你打碎了鸡蛋，这里是清理方法；如果你烤焦了吐司，这里是刮除方法。”要预测每一次事故是不可能的。
有了 RAC，开发人员就不需要编写这些代码。他们只需告诉系统：“这是你使用的每个工具的‘取消’按钮。”RAC 会自动记录操作，并确切知道在出错时如何按相反顺序按下这些“取消”按钮。

总结

鲁棒代理补偿（RAC） 是一种让 AI 代理更可靠的新方法。与其指望 AI 聪明到能自己收拾烂摊子，RAC 更像是一位严格的会计，完美记录每一个动作。如果 AI 犯了错误，RAC 会立即逆转步骤以清理混乱，确保系统永远不会留下“损坏”的状态。它使 AI 代理更快、更便宜，也更加值得信赖。

技术摘要：鲁棒代理补偿（RAC）

1. 问题陈述

本文解决了 AI 代理执行中可靠性这一关键挑战，具体聚焦于防止“非预期的执行副作用”。尽管现代 AI 应用日益依赖代理（定义为感知并作用于其环境的实体）来执行复杂任务，但这些代理通常在动态的、运行时确定的工作流（例如 ReAct 或 Plan-and-Execute 模式）中运行。

当代理或其底层工具在执行过程中失败时，先前成功的操作可能已经产生了副作用（例如，航班已预订但酒店预订失败）。在此类场景中，系统会处于不一致状态。现有的恢复技术面临显著局限：

手动恢复：要求开发者预判所有可能的执行路径并为动态场景编写恢复代码是不可行的且容易出错。
基于大语言模型（LLM）的恢复（ReAct/提示工程）：依赖 LLM 推断恢复步骤或“撤销”操作是不可靠的。正如先前工作所指出的，LLM 在处理复杂的失败上下文时存在困难，导致错误，尤其是在少样本示例不足的情况下。
基于规划的恢复（例如 SagaLLM）：依赖预先规划和迭代重规划的方法，在面对未知错误时，其令牌消耗和延迟成本可能变得高得令人无法接受。它们经常触发不必要的重规划循环，并可能因规划阶段的幻觉而留下副作用。

核心问题在于如何构建一个代理图以实现可靠执行（定义为无论结果如何，绝不留下非预期的副作用），而不过度增加开发者的负担，也不依赖 LLM 易错的推理能力来处理恢复逻辑。

2. 方法论：鲁棒代理补偿（RAC）

作者提出了鲁棒代理补偿（RAC），这是一种基于日志的恢复范式，作为架构扩展实现，兼容大多数现有代理框架（例如 LangGraph、CrewAI）。RAC 将恢复机制与代理的推理循环解耦，提供了一个独立于代理错误处理能力的“安全网”。

核心架构

RAC 引入了三个主要组件：

工具拦截器：一个中间件层，拦截所有工具调用。它在持久的事务日志中记录每个操作（开始、完成、错误）。
错误拦截器：检测故障（包括平台级错误和用户提示定义的语义错误），并触发恢复过程。
恢复与补偿管理器（RCManager）：处理故障解决的核心逻辑引擎。

恢复工作流

当发生故障时，RCManager 执行确定性的三步流程：

重试：对于瞬态错误（通过错误代码或 LLM 分析识别），系统尝试带退避机制的重试。
替代搜索：如果重试失败，系统提示 LLM 寻找替代工具以实现目标。
补偿（回滚）：如果重试和替代方案均失败，RCManager 启动回滚。它根据事务日志重建执行图，按拓扑顺序对操作进行排序，确保在补偿父操作之前先补偿其依赖项，并按后进先出（LIFO）顺序执行补偿操作。

定义补偿对

RAC 的关键要求是能够将操作映射到其逆操作（例如，book_flight $\to$ cancel_flight）。RAC 支持三种发现这些配对的方法，优先级如下：

代理框架 API：开发者在代理配置中显式定义补偿对和输入映射。
模型上下文协议（MCP）：工具定义包含注解（例如 x-compensation-tool），允许任何使用该工具的代理动态发现补偿对。
LLM 发现：如果缺少显式定义，系统提示 LLM 推断补偿操作，并根据先前的执行结果映射输入。

如果找不到补偿操作，RAC 假设该工具没有副作用（这是为未来工作指出的一个简化假设）。

3. 主要贡献

本文概述了六项主要贡献：

RAC 范式：一种基于日志的恢复架构，可通过扩展点集成到大多数代理框架中，确保在不修改现有代理代码的情况下实现可靠执行。
基准测试扩展：识别并扩展了现有基准测试（ $\tau^2$ -bench 和 REALM-Bench），以包含“动态故障”（提示中未明确描述的故障）和需要多步补偿的“不可解场景”。
互操作性标准：利用 MCP 规范定义补偿对，为框架发现恢复逻辑创建了一种标准化、可互操作的方式。
性能分析：实证证据表明，在复杂问题上，RAC 在延迟和令牌经济性方面优于最先进的基于 LLM 的恢复方法（特别是 SagaLLM）。
推理解耦：证明了将恢复逻辑与 ReAct 代理分离，通过从推理循环中移除错误处理的负担，使这些代理能够解决更难的问题。
开源实现：提供了基于 LangChain/LangGraph 的 RAC 参考实现。

4. 评估结果

作者将 RAC 与三个基线进行了评估：

SagaLLM：一种最先进的基于规划的方法。
LG（LangGraph）：一个原生 ReAct 代理。
LG(PE)：一个带有恢复提示工程的 ReAct 代理。

实验设置：

基准测试：扩展的 $\tau^2$ -bench（航空、零售、电信）和 REALM-Bench（规划/调度）。
模型：主要使用 gemini-2.5-flash，消融研究使用 GPT-5.4。
指标：成功率、完成率、延迟（时间）和令牌效率。

主要发现：

令牌效率与延迟：对于复杂问题（特别是在 REALM-Bench 中），与 SagaLLM 相比，RAC 在延迟和令牌经济性方面表现出1.5 倍至 8 倍的性能提升。SagaLLM 在面对意外中断时经常陷入昂贵的重规划循环，消耗显著更多的令牌（例如，在特定故障案例中，时间多消耗 20 倍，产生 34k 个不必要的补偿）。
动态故障：在存在动态故障的场景中（例如 P12、P13、P14），原生 ReAct 代理（LG）甚至带有提示工程版本（LG(PE)）经常失败或放弃。SagaLLM 在重规划循环和令牌限制方面存在困难。RAC 通过依赖确定性的回滚而非重新规划整个工作流，成功处理了这些情况。
高推理模型：使用高推理模型（GPT-5.4）进行的消融研究显示了混合结果。虽然它在某些情况下提高了成功率，但也导致了幻觉并增加了成本（每个任务高达 150 万令牌），且无法保证可靠性，这表明仅靠更高的推理能力不足以实现鲁棒的恢复。
ReAct 提升：通过将错误处理卸载给 RCManager，RAC 框架内的 ReAct 代理能够更有效地处理故障上下文，表现出解决比其独立运行时更难问题的能力。

5. 意义与主张

本文主张 RAC 提供了一种确定性实现来处理基于补偿的恢复，独立于代理采取的具体操作。其主要意义在于：

可靠性：确保即使面对未知或动态中断，代理也不会使系统处于不一致状态。
效率：通过避免基于规划的方法中常见的“重规划循环”，降低与恢复相关的计算成本（令牌和时间）。
架构分离：将可靠性问题与代理的推理循环解耦。这使得推理引擎可以专注于任务执行，而 RCManager 保证状态一致性，有效地“教导”代理进行补偿，而无需它们自己推理补偿逻辑。
实用性：提供了一种解决方案，开发者只需进行最少的代码更改，利用现有框架的扩展点和 MCP 等标准化协议。

作者总结道，虽然基于规划的方法具有价值，但动态代理工作流固有的不确定性使得像 RAC 这样基于日志、专注于补偿的安全网成为构建鲁棒、生产就绪的 AI 代理系统所必需的组件。