你有没有遇到过这种情况：在网上点了一个按钮，页面卡住了，不知道到底成没成功，于是又点了一次。结果呢，钱被扣了两次。
现在把这个场景换成一个AI agent。它正在帮你处理一笔订阅续费，调用了支付接口，钱已经扣了，但是网络在这一瞬间掉线了，服务器的确认消息没有送回来。AI agent这边收到的是一个连接超时的错误。它不知道钱到底扣没扣，它只知道"这次调用失败了"。于是它做了人类在遇到页面卡顿时最自然的反应：重试。
结果是账户被扣了两次钱。
这不是一个假想场景，这正是本篇论文作者们想要揭穿的问题。他们给这个基准测试起了个挺直白的名字：UndoBench，字面意思就是"撤销基准"，专门用来考验AI agent在出错之后能不能把事情"撤回"或者正确处理，而不是在不知道实际发生了什么的情况下，鲁莽地再操作一遍。
**现在的AI agent评测，大多数只回答了一个问题：它能不能把活干完。**
但没人问第二个问题：当活干到一半出了岔子，它能不能收拾干净。
这篇论文想告诉你的核心事实是,这两件事根本不是一回事。一个agent可能有83%的概率能顺利完成任务，但当你故意在它执行到关键节点时掐断网络连接，它的恢复成功率可能只有46%,甚至更糟,它可能在不知不觉中让你的账户被重复扣款。
这件事到底难在哪
先说一个可能违反直觉的事实。你可能觉得,只要AI足够聪明,遇到错误它应该能"反应过来"吧?毕竟现在的大语言模型已经能写代码、能规划复杂任务了。
但问题的根源不在于AI够不够聪明,而在于一个更底层的东西:信息不对称。
当一次远程操作(比如支付、写数据库、调用某个企业系统)执行到一半,网络出了问题,AI agent拿到的只有一个错误提示,比如"连接超时"。但这个错误提示没有告诉它一个至关重要的事实:操作到底是在服务器那边成功了,只是确认消息没传回来,还是压根就没执行成功。
这两种情况,处理方式应该完全不同。
> 分布式系统*:指多台计算机通过网络协作完成任务的系统架构,企业的云服务、支付系统、数据库大多运行在这样的架构之上,它们天然存在网络延迟、丢包、超时等问题。
>
> 丢失确认*(lost acknowledgment):论文里反复出现的核心术语,指的是服务器端操作已经成功执行,但返回"成功"的这条消息在传输途中丢失了,导致客户端(也就是AI agent)根本不知道操作到底成没成功。
人类工程师处理这类问题已经有几十年的经验积累了,行话叫幂等性设计、写前日志、补偿事务,这些都是为了应对"操作结果不确定"这种情况而发明的工程手段。但现在大多数AI agent的架构,把工具调用当成一个"黑箱请求响应",出了错,无非两种处理方式:崩溃,或者把错误信息丢回给大模型,让它自己"反思"一下该怎么办。
而现有的那些知名基准测试,比如SWE-bench(专门测代码修复能力的)、ToolBench、API-Bank、AgentBench、WebArena,它们考察的几乎全是"正常情况下agent能不能把事情做对",没有一个专门去模拟"网络突然抽风""服务器刚执行完就掐线"这种场景。
这就好比你去考驾照,所有的考试内容都是在晴天、空旷的场地里完成的,从来没人问过你:遇到突然爆胎,或者刹车失灵,你会怎么处理。
**如果一个评测体系从来不制造故障,它就永远发现不了agent在故障面前有多脆弱。**
这正是UndoBench想要填补的空白。
把"会不会做"和"会不会收拾烂摊子"分开算
论文提出的第一个核心设计,叫做反事实配对试验(counterfactual paired trials)。
这个词听起来挺学术,其实原理很朴素。简单说就是:同一个任务,用完全相同的随机种子跑两次。一次是正常环境,什么故障都不发生,看agent能不能把任务做对,这叫"控制组"。另一次是在同样的起点上,故意在某个关键时刻注入一个故障(比如就在刚才说的那种丢失确认的场景),看agent这时候会怎么应对,这叫"故障组"。
为什么一定要配对着测,而不是分别单独测两组数据取平均值?
因为如果你只测故障组,会出现一个混淆的问题:agent在故障组里表现差,到底是因为它本身就不擅长做这个任务(连正常情况下都做不好),还是因为它遇到故障就不知道怎么办了?这两种原因混在一起,你根本分不清是哪个在起作用。
论文里给出了一个数学表达,叫条件恢复成功率(Conditional Recovery Success Rate,简称CRSR)。它的定义是:只统计那些在正常情况下本来就能做对的任务,再看这些任务遇到故障时,agent还能不能恢复成功。
打个比方。假设你想知道一个外科医生在手术中突发大出血时的应急能力如何,你肯定不会随便找一个连基本缝合都做不好的实习生来测,因为就算他应对出血失败了,你也无法判断这是因为他基本功不行,还是真的在应急处理上有缺陷。你应该找一群本身手术做得挺熟练的医生,然后看他们遇到突发出血时的反应,这才是干净的实验设计。
> 条件恢复成功率(CRSR)*:只在agent本来就有能力完成该任务的那些试验里,统计它遇到故障后还能成功恢复的比例,公式上写作P(成功|故障,有能力)。
论文的实验数据很直白地展现了这种分离的意义。在12个保留测试任务上,跨两个开源模型、两套框架、三种恢复策略,一共跑了5760次执行,2880组配对试验。结果显示:正常完成任务的成功率是83.54%,但在遇到"操作已提交但确认丢失"这种故障时,条件恢复成功率骤降到46.72%,而不考虑能力条件的整体恢复成功率更低,只有39.03%。
**换句话说,一个本来能把任务做对的agent,一旦遇到确认丢失这种棘手场景,成功率直接被砍掉将近一半。**
更让人不安的是另一个数字:在用最朴素的"重试"策略去处理故障时,53.33%的试验里产生了重复的外部副作用,也就是真的发生了类似重复扣款这样的事情。
三种恢复策略,放在同一个考场里比成绩
既然知道问题存在,那自然要问:有没有办法解决?
论文测试了三种主要的恢复策略,算是给了三种不同的"应急预案"打了分。
第一种叫朴素重试(Naive Retry),也就是行业里最常见的做法:遇到错误就重新发一次请求,最多试三次,每次间隔时间逐渐拉长。这是绝大多数现有AI agent系统默认采用的办法,简单直接,但正如前面提到的,它完全没有考虑"这次操作到底成没成功"这个关键信息。
第二种叫幂等性(Idempotency)。这个词听起来专业,其实原理很好理解:给每次操作生成一个独一无二的"身份证号",如果服务器那边发现同一个身份证号的操作之前已经处理过了,就直接告诉你"这个我处理过了",而不会再执行一遍。
> 幂等性密钥*(idempotency key):给每次调用生成一个基于任务上下文和参数计算出的唯一标识(论文中用SHA-256哈希算法生成),重复发送带相同密钥的请求,服务器会识别出这是重复操作,从而避免二次执行。
这就好比你去银行柜台存钱,工作人员给你的存款单上印了一个唯一的流水号。如果因为打印机卡纸,你以为单子没出来,又去柜台存了一遍,银行系统凭着流水号就能识别出这是同一笔操作,不会把钱存两次。如果没有这个流水号机制会怎样?银行只能凭"存款人姓名加金额"这种模糊信息去判断,万一你今天恰好又存了同样一笔钱(纯属巧合),系统根本分不清这是重复提交还是你真的存了两笔。
第三种策略叫EvoUndo-RB1,这是论文作者在另一篇论文里提出的方法在本次基准测试里的"受限版实现"。它的做法是agent自己在本地维护一份操作日志,把每次工具调用的参数都做哈希记录下来,一旦检测到故障就去查这份日志进行"事后对账"。但要注意的是,这个版本的实现是在"零权限"条件下运行的,意思是它完全看不到远程系统的内部状态,也没有预先注册好的补偿操作函数,只能靠自己手头那份日志瞎猜。
实验结果显示出了明显的分层。
幂等性策略相比朴素重试,条件恢复成功率提升了10.72个百分点(从42.77%升到53.49%),重复副作用的发生率(DER)从53.33%降到45.42%,降低了7.91个百分点。但这个提升并不是均匀分布在所有场景里的,它集中在那些服务器本身支持幂等密钥追踪的接口上。论文里统计到,12个测试任务里只有3个端点真正支持了这种密钥去重机制,这3个端点上幂等策略的条件恢复成功率是百分之百,重复副作用是零。但剩下6个不支持幂等去重的端点,盲目重试直接造成了百分之百的重复执行。
而EvoUndo-RB1这个零权限版本,表现跟朴素重试基本持平,只高了1.12个百分点,统计学意义上几乎可以认为没有差异。原因也不复杂:它没有办法知道一个未经确认的操作到底在远端是否真的执行了,本地日志再详细,也架不住信息根本不在它手里。
**这个结果揭示了一个挺残酷的事实:再聪明的agent,如果拿不到关键信息,聪明也没用。**
这就像一个侦探破案,他可能逻辑推理能力一流,但如果案发现场的监控录像根本不让他看,他再怎么推理也推不出凶手是谁。信息的可获得性,直接决定了智能能发挥到什么程度。
故障发生的时间点,决定了一切
论文最有意思的一个发现,是关于"时机"的。
同样是故障,发生在不同的执行阶段,对恢复的难度影响天差地别。
论文划分了几个关键的时间窗口。第一个叫变更前(PRE_MUTATION),指的是远程系统还没开始修改任何东西之前,传输就断了,比如连接超时或者DNS解析失败。这时候因为远端什么都没发生,重新发一次请求是绝对安全的,无非是浪费点时间。
第二个叫变更中(DURING_MUTATION),指的是远程系统正在执行一个由多个步骤组成的复合操作,执行到一半出了岔子,留下了一个"半成品"状态。这是最棘手的情况。
第三个叫变更后确认前(POST_MUTATION_PRE_ACK),也就是开篇讲的那个场景:操作已经在远端成功提交,但确认信息还没传回来,传输就断了。这时候的核心矛盾是"结果不确定性"。
论文用一个具体例子说明了变更中故障的恐怖之处。在数据库迁移这个任务里,数据库的架构正在被改变,操作执行到一半时注入故障,结果是:朴素重试、幂等密钥、还有零权限的EvoUndo,三种方法的条件恢复成功率全部是0%,而且重复副作用的发生率高达82.5%到97.5%。
只有一种叫"验证后重试"(Verify-Before-Retry,论文里编号B6)的方法做出了一点成绩,但也只是在部分任务上管用。比如在一个云服务蓝绿部署的任务里,B6通过主动查询服务目录,发现目标服务其实已经成功上线了,于是聪明地跳过了重复部署这一步,实现了百分之百的恢复成功率,零重复副作用。但在另外三个任务上(涉及Git操作、对象存储、数据库迁移),B6全部失败了,原因各不相同:Git那边是因为锁文件没清理导致报错,对象存储那边是因为分段上传的中间状态根本查不到,数据库那边是因为部分建表操作和未提交的元数据产生了冲突。
**这说明一件事:光是"能看到"远端状态还不够,你还得有"能修复"的手段。**
这就好比医生给病人做检查,CT片子拍出来了,医生看到了问题所在,但手里没有合适的手术器械,知道病灶在哪也动不了手。观察能力和干预能力,是两件独立的事。
而在变更后确认前这个阶段,情况反而乐观一些。因为这时候操作已经确定完成了,问题只是"确认信息"没传回来,所以验证机制和服务器端的去重机制可以发挥很大作用。论文专门做了一个叫B2-K的强化实验,给所有12个测试任务都配上了服务器端的幂等去重机制,结果条件恢复成功率从标准幂等策略的33.20%跃升到97.24%,重复副作用降到了0%。
这个对比特别鲜明。同样是"幂等性"这个思路,在变更后确认前这个阶段几乎能把问题根治,但在变更中这个阶段完全无能为力。
> 补偿事务*(compensating transaction,也叫Saga模式):当一个多步骤操作执行到一半失败时,通过执行一系列"反向操作"把已经完成的步骤撤销掉,从而让系统恢复到操作开始前的状态,是分布式系统里常见的容错设计模式。
这就引出了论文的核心结论:恢复能力不是一个单一的、固定的属性,而是跟"故障发生在哪个阶段"紧密绑在一起的。你不能简单地说"这个agent的恢复能力是46.72%",正确的说法应该是"这个agent在变更前阶段恢复能力接近78%,在变更中阶段恢复能力接近0%,在变更后确认前阶段恢复能力大约21%到53%,具体取决于用了什么恢复策略"。
换了更先进的商业模型,问题还在不在
这里有一个很自然的疑问:前面说的这些问题,是不是因为用的开源小模型(Llama-3.1-8B和Llama-3.2-3B)能力有限造成的?如果换成更强的商业模型呢?
论文团队专门做了一轮扩展实验,用谷歌的Gemini 3.8 Flash和智谱的GLM-5.2 MaaS这两个商业API模型重新跑了一遍完全相同的测试。
结果有点扎心。
两个模型在正常情况下的任务完成率都相当不错,Gemini达到80.69%,GLM达到77.71%。听起来表现挺强的。但在遇到"操作提交后确认丢失"这个故障场景时,Gemini的条件恢复成功率只有21.08%,GLM是21.89%,两者的"能力恢复差距"都超过了55个百分点。
而且朴素重试在这两个商业模型上导致的重复副作用更严重:Gemini的重复率是65.62%,GLM是51.25%。
**这说明一个挺重要的事实:模型本身的通用推理能力再强,也不会自动解决这个结构性问题。**
这就像一个考试成绩特别好的学生,逻辑推理题做得又快又对,但你让他去修一台从没见过的机器,他照样会一头雾水,因为"擅长推理"和"知道这台机器哪里坏了"根本是两种不同的本事。推理能力解决不了信息缺失的问题,这是架构层面的短板,不是靠堆更聪明的大脑能绕过去的。
为了让这个结论站得住,他们做了哪些额外的严谨性工作
一篇好的基准测试论文,光有漂亮的结论还不够,得证明这个结论不是测量误差或者实验设计的bug造成的。
论文在附录里花了相当大的篇幅做各种校验。比如他们专门检查了配对试验里,控制组和故障组在故障注入之前的提示词是不是完全一致的,结果显示在所有能力匹配的试验对里,一致性达到了100%。他们还设计了72个"对抗性测试用例",故意在系统里埋入各种人为的异常状态(比如重复的操作记录、缺失的操作记录、损坏的最终状态),看他们的判定系统能不能准确识别出这些异常,结果全部72个用例都被正确识别,没有一个漏报或误报。
他们还追踪了模型提供商自己那层网络重试机制(跟论文测试的agent层恢复策略是两件独立的事)有没有偷偷污染实验数据,结果发现只有12次这类底层重试,涉及8次执行,而且全部发生在真正的工具调用之前,没有一次干扰到实际的操作结果。
这些细节听起来有点枯燥,但它们恰恰是让这个研究站得住脚的地方。一个基准测试如果连自己的"测量尺子"都不准,那测出来的所有数字都没有意义。
写在后面
读完这篇论文,最让我意外的其实不是那个53.33%的重复扣款数据,虽然这个数字确实挺吓人。真正让我停下来想了一会儿的,是EvoUndo-RB1这个"零权限"实验的设计。
论文作者故意不给这个方法任何额外的特权,不让它访问沙箱内部状态,不给它预注册的补偿函数,就是想看看一个"聪明但信息受限"的agent到底能走到哪一步。结果是它跟最朴素的重试策略几乎打平。这个设计本身像是一种自我批评,因为EvoUndo是这几位作者自己另一篇论文提出的方法,他们没有在这篇新论文里给自己的方法开后门,而是老老实实地展示了它在受限条件下的真实水平。这种诚实度在学术写作里不算常见。
还有一个细节值得单独说一下:论文里提到,在变更中这个最棘手的阶段,唯一表现出一点效果的B6方法(验证后重试),靠的也不是什么高深的算法,只是多了一步"先去看看现在到底是什么状态"的动作。这个发现背后藏着一个朴素但容易被忽略的道理:很多时候agent出错不是因为它不够聪明,而是因为它压根没想到要先确认一下现状。这跟人类工作中犯的错误其实很像,很多失误不是能力不够,而是省略了那个"先核实一下"的习惯动作。
这篇论文留下的一个悬而未决的问题是:如果故障同时发生在多个地方,或者是那种恶意制造的、更复杂的拜占庭式故障,现在的这套恢复策略还能撑得住吗?论文自己在局限性部分也承认,他们目前只测试了单一故障注入的场景,级联故障、并发故障还没有被覆盖。
一个AI agent在替你管理钱、管理代码、管理企业系统的那一刻,它脚下到底踩的是什么样的地基,这个问题恐怕才刚刚开始被认真追问。
Q&A
Q1：UndoBench是什么？
A：UndoBench是一个专门测试AI agent故障恢复能力的基准测试,包含36个基础工作流和36个故障场景,覆盖8个企业领域,通过配对试验把"任务完成能力"和"故障恢复能力"分开测量，重点考察agent在遇到网络故障、确认丢失等问题时能否安全处理，而不产生重复扣款之类的副作用。
Q2：为什么AI agent遇到网络故障容易重复扣款？
A：因为agent在操作失败后收到的错误提示里，往往不包含"操作到底有没有在远端成功执行"这个关键信息。如果系统采用最朴素的重试策略，遇到错误就直接重新发请求，而远端操作其实已经成功提交了，就会导致重复执行，论文实验显示这种情况发生概率高达53.33%。
Q3：幂等性机制能完全解决重复扣款问题吗？
A：不能完全解决。幂等性机制需要服务器端配合支持去重，论文测试的12个任务里只有3个端点真正支持这种机制，这些端点上效果很好，重复率降到零。但剩下的端点不支持，照样会出现重复执行。而且在"操作执行到一半"这种更复杂的故障场景下，幂等性机制的恢复成功率直接降到0%。
