UndoBench：别只看智能体能否完成任务，还要看它能否安全恢复

2026年10月6日阅读约 3 分钟

导语

当AI智能体开始操作企业软件，判断它“会不会做事”只是第一关。真正危险的场景往往发生在工具调用出现超时、响应丢失或状态不明确之后：智能体可能再次发起请求，表面上完成了任务，却同时造成重复付款、重复创建记录或其他难以撤销的外部影响。

UndoBench正是针对这一问题设计的评测基准。它试图把“正常情况下的任务能力”和“发生故障后的恢复能力”分开，而不是用一次成功或失败的任务结果笼统概括智能体表现。

用反事实配对隔离故障影响。 基准覆盖36个基础工作流和36个故障场景，涉及8个企业领域。研究者在相同种子下分别运行正常版本与注入故障的版本，并结合网络线级效果历史、环境状态等判定依据，观察故障究竟改变了什么。
完成任务不等于安全恢复。 在冻结的“丢失确认”实验中，12个测试工作流共进行了5760次执行、2880组配对试验。名义任务能力达到83.54%，但条件恢复成功率只有46.72%；采用朴素重试时，53.33%的试验出现重复外部效果。
恢复能力取决于故障阶段。 在尚未发生状态变更前，各方法表现接近，具备能力的运行也没有出现重复效果。进入部分变更阶段后，朴素重试、单次调用幂等机制和零权限日志记录在被测复合工作流中均难以有效处理问题。若已经提交但尚未收到确认，验证操作与服务端幂等机制则更有助于降低风险。
代价也应纳入评测。 研究记录显示，故障运行的延迟增加29.3%，完成阶段令牌增加10.5%，工具调用次数增加55.8%。这说明即使最终恢复成功，额外成本和操作压力仍可能使方案不适合生产环境。

UndoBench的重要价值，不只是给出一个新的成功率指标，而是改变了工具型智能体的验收视角。传统基准倾向于检查最终状态是否正确，却可能忽略中间过程是否产生了不可逆副作用。对于支付、工单、库存、权限或数据写入等任务，重复执行本身就可能比一次失败更严重。

这项研究也提醒工程团队：恢复机制不能只依赖模型“自己想明白”。在确认丢失、部分提交和状态不透明的场景中，系统需要提供可验证的状态查询、明确的效果历史、服务端幂等键，以及与权限边界匹配的审计能力。未来评测还可以进一步比较单次恢复的时间、令牌和工具调用成本，而不只统计是否最终完成。

对于模型开发者而言，较高的正常任务成功率并不能代表智能体已经具备可靠的操作能力。部署前应同时测试故障注入、重复副作用和阶段化恢复表现，才能更接近真实企业环境中的安全要求。