评测智能体，大家习惯看「一次能不能做对」。可真实生产里，更常发生的不是它从没做对，而是它做对之后、在出错的边缘能不能收拾残局。10 月 4 日挂出的 UndoBench（arXiv 2610.05622）干的事，就是把「任务能力」和「故障恢复能力」拆开测，结果两者差得相当远。
会做，不等于会救
论文设计了 36 个基础工作流，再配 36 个故障场景，覆盖 8 个企业域。它用反事实配对试验——相同随机种子下，对比「正常跑」与「注入故障后跑」——并辅以线级效果历史与环境状态预言机，来判断智能体到底是在「干活」还是在「善后」。
结论很直白：名义任务完成率达到 83.54%，可一旦进入条件恢复成功率（CRSR）口径，数字掉到 46.72%。更刺眼的是，朴素重试在 53.33% 的 trial 里制造了重复的外部副作用——也就是说，它以为自己在补救，实际上又多干了一遍坏事。
恢复是分阶段依赖的
论文进一步把恢复拆成阶段来看：在状态变更之前，几种方法表现相近，也少有重复副作用；到了部分变更的中间阶段，朴素重试、单调用幂等与零权限日志都会崩；而在提交之后、确认之前，校验加服务端幂等能明显拉高安全性。
这给工程实践一个具体指引：别只在「跑通」层面验收智能体，要在「变更中」与「提交后」两段分别设计恢复路径与幂等边界。只评名义完成率，会系统性掩盖分阶段恢复漏洞，让一个在演示里光鲜的智能体，在生产里悄悄制造重复工单、重复扣款或重复外发。
与同类评测的分工
这段时间的智能体评测正在补不同的盲区：ThinkingBox 看的是智能体在数据库里留下的终态对不对，OffQuery 揭的是协作中隐藏状态的失真。UndoBench 的独特点在于，它把镜头对准「故障发生之后」——也就是恢复与容错这条少有人量的维度。它自我定义了基准，也还需要更多框架与模型来交叉验证，但方向上说清了一件事：完成率与恢复率是两个不相关的维度，生产级智能体必须为部分失败预先设计恢复机制，而不能默认「跑完即正确」。
落到工程实践的三条动作
把论文结论翻译成日常动作，对正在把智能体接进生产系统的团队有三条直接启发。其一，在发起任何外部副作用之前设一道「幂等闸门」：用业务主键加服务端去重，确保同一意图重复到达时只生效一次，而不是又扣一遍款、又发一遍信。其二，把恢复路径按阶段分开设计——变更前、部分变更中、提交后各写一套兜底，别指望一个重试逻辑包打天下。其三，验收指标必须同时看「做没做对」和「做错了能不能收拾」，后者至少要靠故障注入来常态化练习。
朴素重试在过半 trial 里制造重复副作用，这个数字最该被记进每一次上线评审。它提醒我们：智能体的可靠性，不是「成功率」一个数字能概括的，而是「成功时干净、失败时可控」两套能力叠加的结果。少测了哪一半，哪一半就会在生产里悄悄咬你。