为什么干净起点的通过率不够用
绝大多数智能体评测从一个正确的初始状态出发，问的是：给定正确起点，能否抵达目标。这个问法在实验室里没问题，但它默认了一件生产环境里几乎不成立的事——智能体接手时，状态是对的。
真实情况相反。上一步可能来自另一次运行、另一个智能体、一个人类同事，或者一个抽风的工具；文件、表格、记录里可能已经被写进了错误内容。如果评测从不从破损状态出发，那么「智能体有没有能力发现」就从未被测量过，而对外公布的那个通过率对此保持沉默。
异步场景是同一枚硬币的另一面。当主智能体继续干活而子智能体在后台跑，结果到达时任务状态可能已经变了。主智能体必须判断：哪些工作要更新、哪些要保留、哪些检查要重做、哪些改动是禁止的。端到端成功率同样回答不了这个问题——它只看最终有没有成。
两份基准的价值，就在于各自补上了被掩盖的那一列。
两份基准的设计对照
| 维度 | CUA-Recovery | Async-RBench |
|---|---|---|
| arXiv 编号 | 2610.27645 | 2610.32429 |
| 提交时间 | 2026-10-20 05:06 UTC | 2026-10-23 09:53 UTC |
| 篇幅 | 33 页、13 图、18 表 | 25 页、16 图 |
| 作者数 | 14 位 | 8 位 |
| 规模 | 测试集 2250 个错误状态 / 100 个任务；训练集 8.6K 轨迹 / 377 个任务 | 200 个可执行任务 / 8 类场景 |
| 被测对象 | 6 款计算机使用智能体 | 9 款智能体 |
| 核心指标 | EAR、Rubric Score、Pass@3 | DRS、任务成功率（分开报告） |
| 操控变量 | 接管深度（根因后 0 到 25 步） | 结果投递方式（异步 / 批量） |
| 代码 | github.com/xu-hu-2002/CUA-Recovery | github.com/pope8zdt/Async-RBench |
两者的共同结构很清楚：都引入了一个常规评测里不存在的操控变量（接管深度、投递方式），都把过程指标与结果指标分开记，都明确公布了边界。这三点是判断一份基准是否值得采信的硬标准。
ReRail：如何造出真正「已经错了」的状态
CUA-Recovery 的难点不在出题，在于错误状态必须是真实智能体真的会犯的那种错。用人工注入的办法做这件事，注入的错误类型与分布往往与实际失败不符，测出来的结论不能外推。
ReRail 的做法分三步：先把 MyPCBench 的任务合成为带可执行真相（executable ground truth）的长程工作流——所谓可执行真相，是指每一步的正确值都能被计算出来；然后收集多套策略实际产生的、被验证器确认的失败；最后把这些失败转换为经过核验的恢复轨迹。抽取自 619 次失败轨迹。
关键一步是定位根因步：找到每次失败最先出错的那一环，然后把运行重放到根因之后 0 到 25 步的某个位置，让新智能体从这个状态接手，并且不告诉它出了事。这个「不告知」是整套设计的核心——一旦告知，测的就变成了修复能力而非觉察能力。
最终测试集是 2250 个人工核验的错误状态，覆盖 100 个任务；另有 8.6K 轨迹、377 个任务的训练集。
常规评测问「给你一个干净的桌面，你能不能做完」；CUA-Recovery 问「给你一个别人已经搞砸的桌面，你能不能看出哪里砸了、还能不能收场」。前者测执行，后者测执行加判断，而生产环境里后者才是常态。
三个指标分开记：觉察、完成度、三次内完成
CUA-Recovery 报三个独立数字，这个切分本身就很值得学习：
| 指标 | 全称 | 回答什么问题 | 不回答什么 |
|---|---|---|---|
| EAR | Error Awareness Rate | 智能体有没有说出「前面有地方错了」 | 说了之后有没有改 |
| Rubric Score | 评分细则得分 | 任务完成了多少 | 是否完整完成 |
| Pass@3 | 三次内完整完成率 | 给三次机会能否完整做完 | 一次就做对的能力 |
把「觉察」单独列为一列，是这份基准最重要的设计决定。因为在可观测性系统里，一个默默把错误继承下去的智能体与一个谨慎核对的智能体，在完成度仪表盘上长得一模一样。只有单独记一列，两者才分得开。
CUA-Recovery 成绩单
作者给出的汇总读数如下（六款智能体 × 六种接管深度）：
| 指标 | 最高值 | 含义 |
|---|---|---|
| 错误觉察率 EAR | 最高 44.0% | 六款智能体六种深度下的最好成绩也未过半 |
| Pass@3 | 最高 25.5% | 三次机会内完整完成任务的比例，四分之三以上做不到 |
| 干净起点能力 vs 觉察能力 | 一款 66.9% vs 最高 18.5%；另一款 5.1% vs 14.1%–26.1% | 两组数字不相关 |
| 觉察后通过率 | 15.6%（六款均值） | 认出错误的运行通过验证器的比例 |
| 未觉察通过率 | 12.2%（六款均值） | 没认出错误的运行通过验证器的比例 |
这里面最反直觉的是第三行。干净起点的能力与觉察能力几乎不相关。一款智能体从干净起点能解出 66.9% 的源任务，却最多只能觉察自己失败中 18.5% 的错误；另一款干净起点只有 5.1%，觉察率反而能到 14.1%–26.1%。
这条结论的实践含义很直接：不能用一个智能体在常规榜单上的排名，去推断它在破损状态下的表现。采购时看的那张榜，与生产环境里真正会出事的那一列，是两个不同的能力维度。
觉察不等于修复：那 3.4 个百分点
把觉察与未觉察两组的通过率放在一起，可以看出「说出来」与「改回去」之间的距离：
| 分组 | 通过验证器比例 | 差值 | 相对提升（本文推算） |
|---|---|---|---|
| 认出了继承错误 | 15.6% | +3.4 pp | 约 27.9% |
| 没有认出 | 12.2% | 基准 | 基准 |
认出错误带来的收益是 3.4 个百分点，相对提升约 27.9%。这个数字要两面看：一方面它说明觉察确实有用，不是虚指标；另一方面，认错之后的通过率仍然只有 15.6%，说明大部分时候智能体说出了问题，却把受影响的状态原样留在那里。
作者的原话是：智能体常常点出了问题，却让受影响的状态保持不变。本文认为这是整份材料里最值得工程团队记住的一条。它意味着「让智能体学会报错」只是起步，真正难的是让它具备回滚与修正的能力——后者需要状态管理、幂等写入与事务边界，属于系统层而非模型层的能力。
错误总是最后一步才显形
第三组读数解释了为什么觉察这么难：
| 观测 | 数值 | 推论 |
|---|---|---|
| 错误在根因后三步及以上才显性的比例 | 78.1% | 绝大多数错误不会当场暴露 |
| 显性延迟的中位步数 | 17 步 | 半数的错误要走过十几步才看得见 |
| 首个证据直到最后一步才出现的失败 | 602 次中的 361 次 | 约六成失败根本没留下中间线索 |
这组数字把觉察问题的难度具体化了。中位 17 步的延迟意味着：接管深度为 0（刚出错就接手）时，智能体几乎不可能有线索可用。这也从侧面解释了为什么 EAR 的最高值只有 44.0%——不是模型不够聪明，而是可观测的证据来得太晚。
本文据此做一条推断（作者未直接给出该表述）：接管深度越大，觉察率应当越高，因为累积的证据越多。这与「六种接管深度下 EAR 最高 44.0%」这一口径一致——最高值很可能出现在较深的接管点。若要在自己的系统里复现这个结论，需要按深度分层统计，而不是只看汇总值。
对工程实践的提醒是：监控不能只看最终结果。如果错误平均要走 17 步才显性，那么在最终结果上做告警已经太晚。中间态的一致性校验——写入前后比对、跨系统对账、关键字段断言——才是把显性延迟压下来的手段。
根因分布：问题在脑不在手
| 根因类别 | 占比 | 说明 |
|---|---|---|
| 规划与感知 | 57.3% | 判断错了或看错了，不是点错了 |
| 终止错误 | 23.5% | 包括需求未满足就报告成功 |
| 其余（含操作类） | 约 19.2%（本文按余数推算） | 论文未单列细项 |
超过一半的根因是规划与感知，接近四分之一是终止错误。合起来约八成的失败与「手上的动作」无关，而与「脑子里的判断」有关。
终止错误这一项尤其值得单拎出来：它指的是在需求尚未满足时报告成功。这类失败不会留下任何异常，日志里显示任务完成，验证器却判不通过。对外部观察者来说，这与真正完成毫无区别。
本文注意到这份分布与 Async-RBench 的结果存在呼应：后者得分最低的两类场景是重复报告与子智能体失败，同样属于状态判断而非动作执行。两份独立材料在这一点上收敛，说明「判断何时算完成、判断状态是否已变」是当下智能体能力的一处共性瓶颈。
微调能补多少，以及它顺手补了什么
作者在训练集上微调了 Qwen3.5-35B-A3B，效果如下：
| 指标 | 微调前 | 微调后 | 增量 |
|---|---|---|---|
| 平均 EAR（留出恢复状态） | 19.9% | 35.2% | +15.3 pp |
| Rubric Score | 5.0% | 16.1% | +11.1 pp |
| MyPCBench Pass@3 | 基线未单列 | +15.3 分 | 起点能力同步提升 |
| Odysseys Pass@3 | 基线未单列 | +10.8 分 | 跨基准迁移 |
两个方向都值得说。其一是幅度：EAR 从 19.9% 到 35.2%，提升明显，但仍未达到 44.0% 这个已有模型的最好水平，也仍未过半。训练数据能补一部分，补不满。
其二是迁移：在恢复轨迹上训练之后，从干净起点完成任务的能力也涨了（MyPCBench +15.3 分、Odysseys +10.8 分）。这条容易被人忽略，但它说明一件事——恢复能力与起点能力并非彼此独立，二者共享一部分底层能力（理解任务状态、核对约束、判断完成条件）。因此把它们当成两条独立的能力线去分别投入，可能会重复计算收益。
Async-RBench：迟到的结果怎么接
换到异步场景。Async-RBench 的设定是：主智能体继续工作，子智能体在后台跑，结果到达时任务状态可能已经改变。此时主智能体要同时处理好几件事——哪些工作要更新、哪些要保留、哪些检查要重做、哪些改动是禁止的。
两个设计要点支撑了可复现性：
- 场景控制器（scenario controller）：用预定义的任务状态条件来调控结果投递时机，解决「自然异步到达难以复现」的问题
- 事件响应契约 ERC（Event Response Contract）：明确规定每次响应必须改变什么、保留什么、避免什么、重新验证什么
ERC 是这份基准最有价值的部分。它把「正确处理迟到结果」这件模糊的事，拆成了四个可判定的维度。任何团队在自己系统里做异步设计，都可以直接借用这四个问题。
DRS 与成功率的落差
动态重规划分 DRS 把响应过程与响应结果等权加权，并且与任务成功率分开报告。九款智能体的结果如下：
| 指标 | 数值 | 口径 |
|---|---|---|
| DRS 区间 | 19.2 – 45.1 | 九款智能体，满分 100 |
| DRS 全距 | 25.9 分（本文推算） | 45.1 减 19.2 |
| 异步投递任务成功率 | 平均 26.0% | 按该基准的执行协议 |
| 批量投递任务成功率 | 平均 29.7% | 同上 |
| 成功率落差 | -3.7 pp（本文推算） | 相对下降约 12.5% |
| 得分最低场景 | 重复报告、子智能体失败 | 均为状态判断类 |
有两条值得单独强调。其一，九款智能体在异步下的成功率全部低于批量投递。没有例外。这说明这不是某个实现的缺陷，而是结构性的——只要结果迟到、状态已变，现有智能体的处理就会打折。
其二，DRS 的上限只有 45.1。满分 100 的指标，最好的智能体也拿不到一半。按本文推算的全距 25.9 分看，九款智能体之间的差异，小于它们与满分之间的差距。这意味着异步结果处理目前还是一项普遍薄弱的能力，而不是「谁家做得好」的差异化竞争点。
提示重规划的收益只有两三分
作者在三个智能体上试了一个直观的改进：每当有结果到达，就提示主智能体重建计划。收益是 DRS 提升 2.6 到 3.5 分。
| 口径 | 数值 |
|---|---|
| 改进幅度 | DRS +2.6 到 +3.5 分 |
| DRS 全距 | 25.9 分（本文推算） |
| 改进幅度占全距比例 | 约 10.0% 到 13.5%（本文推算） |
| 距满分的剩余差距 | 最好情况仍差 54.9 分（本文推算） |
本文据此的判断是：提示词层面的补救不足以解决异步处理问题。把收益放回全距里看，两三分大约相当于九款智能体之间差距的十分之一；而相对于满分的缺口（54.9 分），这两三分几乎可以忽略。要解决它，需要的是 ERC 那类结构性契约——把「该改什么、该留什么、该避免什么、该重验什么」显式化，并在运行时可检查，而不是在提示词里叮嘱一句「记得重建计划」。
需要说明：该实验只在三款智能体上做，作者未披露是哪三款，也未给出统计显著性口径。上述推算只作量级参考。
两份基准各自的边界
| 基准 | 作者声明的边界 | 本文补充的注意点 |
|---|---|---|
| CUA-Recovery | 单一桌面环境；智能体使用各自脚手架；LLM 裁判经人工标注校验，略偏严格 | 脚手架差异会混入得分，不宜把六款智能体的排名当作模型能力排名 |
| CUA-Recovery | 错误状态来自既有策略的失败，分布随策略变化 | 换一代模型后失败分布会变，基准需要持续重建 |
| Async-RBench | 由场景控制器按预置条件投递，非自然到达 | 真实环境的时序更混乱，读数应视为下界 |
| Async-RBench | 九款智能体的具体清单与脚手架细节未完全公开 | DRS 区间不可直接映射到具体产品选型 |
| 两份共同 | 均为预印本，未经同行评议 | 结论应视为阶段性，需等待后续版本 |
本文未对两份基准做独立复现，所有读数均来自论文摘要与公开转述，未用于给任何产品排名。
读榜检查清单
基于两份基准的方法学，给出一份可直接用于采购与自评的检查项：
- 凡是会写入持久状态的智能体，都要单独测「从破损状态接管」。把「是否觉察」与「是否修复」记成两列，不要合并成一个通过率。只读问答型智能体可以只测干净起点。
- 不要拿常规榜单排名推断破损状态表现。CUA-Recovery 显示干净起点 66.9% 的智能体觉察率最高只有 18.5%，两者不相关。
- 把根因到显性的延迟做成指标。中位 17 步意味着结果层告警必然滞后，需要在中间态加一致性校验。
- 为异步结果定契约。借用 ERC 的四个问题：必须改变什么、必须保留什么、必须避免什么、必须重新验证什么。写成可检查的规则，而不是提示词。
- 要求供应商提供失败注入测试结果，而非仅提供顺畅路径演示。重点关注中断支付、重复工单、重复客户沟通、数据库状态变更、部分完成的审批这五类场景。
- 把过程指标与结果指标分开看。DRS 与任务成功率、EAR 与 Pass@3，都是同一件事的两面。只看结果，会系统性地高估系统健壮性。
综合两份基准，一个冷静的结论是：当前智能体在「把事情从头做到尾」上的能力，明显强于「发现事情已经做错了并收场」的能力。生产环境里真正会累积损失的，往往是后者。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。