工具调用智能体正被部署进企业软件系统，但常用基准几乎只评名义任务完成，等于把规划能力与运行时故障恢复捆成一个分数。UndoBench 把这两件事拆开：36 个基础工作流、36 个故障场景，覆盖 8 个企业领域；用相同随机种子做反事实成对试验，并配上线级副作用历史和环境状态预言机，从而分别度量任务能力与恢复能力。
名义完成率掩盖恢复失败
冻结的确认丢失研究里，作者在 12 个留出 TEST 工作流上评了两种开源权重模型、两种框架、三种恢复范式，共 5760 次执行、2880 组成对试验。名义能力达到 83.54%，条件恢复成功率（CRSR）降到 46.72%。朴素重试在 53.33% 的试验中产生重复外部副作用。扩展到商业 API 模型后，这种能力与恢复的分离再次出现。
恢复效果取决于执行进行到哪一步
跨互补执行边界的结果更具体：恢复是分阶段的。变异发生前，各方法在有能力的试验中表现接近，且没有重复副作用。部分变异期间，朴素重试、按调用幂等、零权限日志（zero-privilege journaling）在所评测的复合工作流上都垮掉。提交之后、确认到达之前，校验与服务器端幂等能明显提高安全性。材料因此认为，只看名义完成会掩盖关键、且随阶段变化的恢复问题。摘要未给出各阶段分项数字，解读应保守；但阶段差异已说明，失败即重试在变异后并不安全。
我的判断
这份工作的价值是评测口径，不是又一张榜。它把企业真正怕的重复外部效果，从任务完成率里剥离出来。数字已经具体：名义八成多，条件恢复不到一半，盲目重试半数以上会写两遍。适用面窄，针对工具调用和企业工作流，且依赖线级效果与状态预言机；材料没有点名模型、框架和八个领域，也没有完整展开 CRSR 定义，不能拿去给所有智能体打总分。摘要在 phase-dependent recovery 处截断，后续细节看不到。开发者更该改的是验收习惯：完成率之外，至少单测确认丢失和部分变异，并把服务器端幂等当成恢复策略，而不是假设模型再试一次就能兜住。