CUA-Recovery：评测长程计算机使用 Agent 的错误恢复（附录）

CUA-Recovery：评测长程计算机使用 Agent 的错误恢复（附录）

译注：本篇接续正文，包含附录 A 至附录 G。

附录 A 成本

表 4 和表 5 分项列出本文的 API 与 GPU 成本。用 GPT 5.6-terra 评判一组，无论是某个 Agent 的 184 次干净起点 rollout 中的一次运行，还是接管回合中的一个 Agent–跨度格子，大约花费 120 美元。前缀重放执行的是已记录的动作，不调用模型，因此接管的 API 成本只来自接管点之后 Agent 的行动；我们用同一 Agent 干净起点运行的每任务成本来估计它。十名标注者标注失败语料（附录 E.1），每个标注组每位标注者 100 美元。本地部署的 Agent 和 ReRail-35B-A3B 没有 API 成本；每个模型在八张 AMD MI308X GPU 上一次服务一个回合（附录 F.1），因此用 32 个并发沙箱跑本地模型，最多占用 256 张 GPU。

表 4：API 成本。一个评判组是某个 Agent 干净起点 rollout 的一次运行（每个 Agent 3 次），或接管回合中的一个 Agent–跨度格子。红色数值为估计。

表 5：GPU 与沙箱计算。每个本地部署的模型在一台八张 AMD MI308X GPU 的服务器上一次运行一个回合，因此 GPU 小时是回合墙钟时间的八倍；API Agent 只使用沙箱时间。干净起点时间是实测的；接管时间使用各 Agent 在接管后 58 步上测得的每步延迟。

附录 B ReRail 数据合成框架的细节

本附录完整给出第 4.1 节的 ReRail 框架。尽管现有 MyPCBench 任务集提供了现实工作流，大多数任务相对较短，有能力的 Agent 只需 20 到 45 步就能完成，而让错误保持隐藏的依赖结构通常不超过两个节点。要大规模研究隐藏错误，需要依赖链很长、且真值可执行的任务，使得任何 Agent 运行之前，每个中间值、每个被写入的单元格和最终状态都是已知的。当前基准缺少这些性质。因此我们通过组合已验证的源任务来合成任务，并且只在组合被执行、其验证器被证明会拒绝错误运行之后才接受它。本附录按实现描述这条流水线：从每个源任务抽取可执行任务表示（第 B.2 节），带可执行门的组合搜索（第 B.3 节），把验证器冻结并用变异测试衡量验证器覆盖（第 B.4 节），按跨度控制的选择以及世界变体和指令变体（第 B.5 节），以及发布集合的规模与跨度（第 B.6 节）。

B.1 从工作流到训练样本与测试样本

算法 1 概括 ReRail 如何用已验证的工作流构造两个划分。

算法 1 ReRail：收集失败并构建恢复数据

1: 已验证任务池 M，带参考执行 G(M) 和冻结验证器；源策略 Pi；基座模型 pi_0；教师 pi_T；深度 D = {0, 5, 10, 15, 20, 25}
2: 训练恢复集 Q 与测试状态集 E
3: 把 M 分成训练任务和测试任务
4: Q, E ← 空
5: for 任务 M ∈ M、M 的指令 l、源策略 pi ∈ Pi do
6:     xi ← Rollout(pi, l, M)
7:     if 最终验证器接受 xi then continue
8:     (t_r, kappa, t_e) ← AnalyzeFailure(xi, G(M))
9:     if 根因未解决或类型置信度低于 0.7 then continue
10:    xi ← RepairEarlierMistakes(xi, t_r)
11:    if 前缀修复失败 then continue
12:    for d ∈ D 且 c = t_r + d ≤ |xi| do
13:        if 重放不能复现记录状态 then continue
14:        if M 是测试任务 then
15:            应用附录 C.1 的测试资格规则
16:            取得对标签和重放状态的人工核对
17:            把接受的状态、历史和标签加入 E
18:        else
19:            r* ← 附录 F.4 提示日程下第一个经过验证的续写
20:            if r* ≠ ⊥ then 把 (l, H_c, r*) 加入 Q，且不带提示
21:        end if
22:    end for
23: end for
24: return Dedup(Q), E

B.2 从源任务到可执行任务 IR

任务中间表示。

一个任务被表示为一张落在一份冻结环境快照上的有根据 DAG $M=(V,E)$。每个节点 $v\in V$ 记录它作用的应用，其操作从下列动作集合中选择：retrieve、resolve、filter、compare、aggregate、verify、decide、create、modify、delete、communicate、confirm。它还定义自己读取的表单元格、自己产生的值以及可执行的推导，例如只读 SQL 查询、对上游值的表达式、文件读取，或一行或一个文件的创建；它写入的单元格、可逆性类别，以及节点验证器。一条边把值或状态从输出端口传到输入端口；若没有边连到某个输入端口，该端口就持有指令中指定的字面量或常量。图携带一个最终状态验证器，并显式给出一组等价的最终状态。快照由 17 个应用数据库、201 张表、一张同时捕捉外键和推断关系的模式图，以及人物主目录中 48 份文档的清单组成。文件清单被暴露成一张虚拟表，使文件和数据库行可以被当成同一种事实。

抽取与程序化验证。

语言模型从指令、评分表、人物设定和模式中，抽取 184 个 MyPCBench 源任务各自的任务 IR。结果由程序验证，而不是由 LLM 评判。静态检查确认 DAG 有效、每个单元格都落在模式图上、每个命名实体都存在于快照中。每个输入字面量必须要么出现在指令中，要么指向人物自己的身份，以确保 Agent 本应自己检索的事实不会被直接当成常量给出。

然后在快照的一份新副本上执行黄金 IR。解释器计算每个推导，执行声明的写入，把每条 SQL 查询实际读取的单元格与声明的读取核对，若遇到未声明的写入就中止。它还记录黄金谱系 $G(M)$，包括每个产生的值、每个被写入的单元格，以及每个节点之后的状态摘要。

最后，把黄金值与源评分表中的真值比较，例如金额、日期和姓名。相对日期变量用快照的参考时间展开。当评分表没有可比较的字面量时，就根据其措辞与黄金值的重叠来评估。任何未通过验证的任务都会把程序的发现附加到提示中重新抽取，最多四轮。

根据验证情况，我们最终从原始 MyPCBench 的 184 个任务中接受了 135 个（73.4%）：53 个因与评分表字面一致，82 个因措辞。其余 49 个任务中，34 个无法执行，因为模型的推导或写入与实际模式不兼容；8 个的评分表没有可比较的值；5 个的最终验证器拒绝了自己的黄金运行；2 个与评分表矛盾。被接受的 IR 节点中位数为 6。每个被接受的 IR 都带有自己的黄金谱系，它是此后一切的唯一真值来源。

B.3 带可执行门的组合搜索

##### 带单元格证据的类型兼容。

组合把一个已接受 IR 的输出端口 $p_{o}$ 连到另一个 IR 的字面量输入端口 $p_{i}$。第二个任务指令中原先作为常量给出的值，此后必须通过执行第一个 IR 得到。

令 $\tau(p_{o},p_{i})\in\{0,0.4,1\}$ 表示两个端口之间的类型兼容分数。实体引用类型匹配时分数为 $1$，共享 Integer 或 Text 这类通用标量类型时为 $0.4$，否则为 $0$。对每个端口 $p$，令 $\mathrm{col}(p)$ 表示与该端口关联的模式列。我们先从 IR 声明的读取中识别 $\mathrm{col}(p)$。若声明的读取不能唯一确定一列，就从 SQL 推导中恢复。对输出端口，$\mathrm{col}(p)$ 是标量查询唯一选出的列。对输入端口，它是与对应于 $p$ 的查询参数相比较的列。若不能识别出唯一的列，该端口就不能参与组合。

令 $\mathrm{rel}(p_{o},p_{i})$ 表示包含 $\mathrm{col}(p_{o})$ 和 $\mathrm{col}(p_{i})$ 的表在模式图中由至多两跳的键路径相连。兼容分数为

当且仅当 $\sigma(p_{o},p_{i})\geq 0.5$ 时，我们称一对端口可接纳，记为 $p_{o}\leadsto p_{i}$。因此，通用标量类型匹配的端口对，只有在落在同一模式列上，或它们的列由键路径相连时，才可接纳。这个附加约束防止仅凭类型匹配。端口的基数也必须匹配，代表人物身份的字面量不能用作嫁接目标。在 135 个已接受 IR 上，1,053 个输出端口和 109 个候选输入端口产生 143 条可接纳边：51 条连接落在同一列上的端口，92 条连接由键路径支持的类型兼容端口。

算子与搜索。

对每个种子 IR，我们考虑与已接受池中任意 IR 做组合的束搜索。每一步，搜索可以把任务 $A$ 的一个输出传给任务 $B$ 的字面量输入，再增加同一操作模式的另一个实例，给比较或聚合节点再挂一个生产者，在值产生之后若干节点处复用该值，或用 $A$ 中 decide 节点产生的布尔值去守卫 $B$ 中第一个改变状态的节点。每一步之后重新评估得到的图。

为避免命名冲突，每个节点标识符都加上父任务前缀。每次组合的来源记录保存算子、端口绑定和源任务。

执行之前，每个候选必须通过一组静态检查。若图中超过 25% 由独立分量组成，图会被拒绝，这通常表示两个任务被并排放置，而不是有意义地组合。若从一个任务传到另一个任务的值对后续计算没有影响，若目标跨度范围内的节点少于两个（第 B.5 节），或图的节点少于 10 个或多于 24 个，也会被拒绝。下界排除那些太短、无法有意义地测试长程推理的任务（第 B.6 节）。上界使任务仍处在当前 Agent 能够到达的范围内。

通过这些检查的候选在快照的一份新副本上执行。执行必须成功完成，最终验证器必须接受得到的黄金状态。束保留 16 个状态，最多允许三次嫁接，每个种子在每一轮中使用不超过 48 次黄金执行。

每个世界都使用每份数据库的完整副本，因此每一步都重算全部数据库摘要会很贵。解释器改为缓存每个数据库的摘要，只在对应连接报告变化时才重算。这把一次黄金执行的时间从 8.9 秒降到 0.1 秒，使可执行验证变得实际可行。

组合后的评分表。

对由源任务 $T_{1},\ldots,T_{k}$ 组成的工作流，我们把源任务的评分项合并成它的评分表。当组合用上游输出替换某个源任务输入时，我们用组合后的黄金谱系更新对应的期望值和验证描述。每个保留项保持其源任务权重。得到的评分表既用于构造冻结的程序化验证器，也由 GPT 5.6-Terra 评分评判逐项使用。

B.4 验证器冻结与变异测试

##### 把验证器冻结到黄金值。

抽取阶段产生的验证器主要检查内部一致性，而不是正确性。在 135 个已接受的最终验证器中，122 个是派生谓词，76 个只引用运行期间计算出的值。这样的验证器因此可能接受输出彼此一致但不正确的运行。组合之后问题更严重，因为从接收任务继承来的验证器可能仍含有原任务的字面量。

为防止这一点，我们在使用每个验证器之前把它锚定到黄金谱系。令 $\mathrm{Sink}(M)$ 表示 $M$ 的汇节点，其输出不被任何其他节点消费，令 $g_{u,x}$ 表示节点 $u$ 的输出 $x$ 的黄金值。设验证器谓词 $\varphi$ 引用运行时值 $\mathrm{val}[u][x]$，以及由这些值导出的 SQL 参数。我们把每个对非汇值的引用替换成它的黄金对应物，从而冻结该谓词：

汇值保持不变，取自正在被评估的运行，而用来推导期望结果的值被固定为黄金谱系。得到的谓词因此把运行的最终输出与锚定在黄金值上的期望相比较。对节点级验证器，正在检查的节点被当作汇，因此它自己的输出保持不冻结，而检查所依赖的值被固定为黄金值。

组合过程还有一个附加的小步骤：在固定从接收任务传下来的验证器之前，必须先把与插入点或后续阶段的参考答案重合的字面量替换成参数。任何仍然依赖那些被丢弃字面量的候选最终条件都被直接丢掉。接下来，我们拼接两个源任务的最终验证器，执行组合后的 IR，得到它的参考答案谱系。利用这条谱系，再按公式 2 固定新参数。最后，我们用一份新快照再次运行固定后的 IR；只有通过这次验证的才真正进入基准数据集。

##### 变异测试。

变异测试评估验证器检测不正确行为的有效程度。对每个目标值，框架根据其类型从预定义库中选择合适的变异。常见变异包括交换表名或实体名、把日期移动一天或一周、缩放金额、省略费用、改动列表元素、翻转布尔值，或使用过时文本。然后用变异值覆盖原值重新执行 IR。节点 $v$ 上的变异 $\mu$ 在下列任一情况被视为被抓住：任何下游验证器失败、冻结的最终验证器失败，或运行结果偏离黄金标准。最后这项检查模仿人类评判把模型输出与评分表比较。一个任务的拒绝率是

我们严格在已执行的变异上汇总 $R(M)$，只有 $R(M)\geq 0.5$ 的任务才留在池中。第一个失败的节点验证器揭示该变异的动态潜伏跨度，即从节点 $v$ 到那个失败验证器的拓扑距离。只被最终验证器或黄金偏离抓住的变异标为仅验证器，完全逃脱检测的则是沉默变异。在一次生成运行中，417 个候选上执行了 17,857 次变异，我们观察到 $R$ 的中位数为 0.64（均值 0.67），327 个候选通过阈值。具体而言，下游节点验证器抓住 4,711 次变异，最终验证器抓住 823 次，汇或写入偏离抓住 6,394 次，5,929 次保持沉默。若去掉冻结步骤和偏离检查，中位 $R$ 降到 0，417 个候选中只剩 3 个存活。

B.5 跨度分桶、选择与变体

##### 静态潜伏跨度。

为了量化一个错误在暴露之前能藏多深，我们在执行之前的 IR 上计算静态潜伏跨度 $\lambda(v)$。概念上，当节点 $v$ 产生一个不正确的值时，它会污染自己接触的数据事实。跨度 $\lambda(v)$ 衡量依赖图上从 $v$ 到第一个消费这些被污染事实的下游节点 $u$ 的最短路径：

若错误只被最终验证器抓住，我们令 $\lambda(v)=\infty$，这是仅验证器错误；若没有下游分量检测到它，则留作未定义，这是沉默错误。我们把节点分成四类：$1$、$2$–$3$、$\geq 4$，以及仅验证器，并把每个任务分到其节点中出现最频繁的那一类。桶 $1$ 表示错误立刻传播，错误在下一步就被抓住；更高的桶捕捉错误持续多个动作、或直到执行结束的更难情形。

选择。

为了构建平衡的基准，我们先按固定目标份额 $\bm{\alpha}=(0.20,0.35,0.30,0.15)$ 选择基础任务来填满四个跨度桶，得到每桶配额 $q_{b}=N\,\alpha_{b}$。候选按一个综合分数排序选择，该分数奖励目标桶比例更高和跨应用边更多，同时惩罚依赖深度落在 $[5,9]$ 之外。选择受两个约束：源任务限制在对照桶，未填满的配额记为缺口，而不是从其他桶回填。

轴 1：世界变体。

基础任务选定之后，我们引入环境隐患作为第一维变化。这些隐患包括身份别名、过时文档、标题相似的干扰事件，以及被破坏的前置条件。为防止人为过度注入，我们先查询每种隐患在快照中的基线出现率。只有基线率非零时才注入该隐患，并把注入后的比率上限设为基线的两倍。当某个节点的指令常量或输出匹配隐患选择器时，环境播种器把隐患作为人物补丁应用。在我们的快照中，只有干扰事件满足这些条件（基线计数：19），身份别名和过时文档不符合注入条件。

轴 2：指令变体。

指令实现构成第二维变化。对每个被选任务，模型根据图摘要和公开上下文生成候选指令，而不揭示受限的“隐藏值”，也就是被排除在初始输入和先前种子之外的黄金值。一条指令只有在包含全部必需输入字面量、且不泄漏隐藏值时才被保留。不同的有效指令给出独立的 rollout 起点，同时保留任务的核心黄金目标和验证器。

B.6 合成集合的规模与跨度

表 6：在 135 个已接受源 IR 上一次生成运行的合成漏斗。

在三次束宽逐步增大的合成运行中，流水线最终产生 477 个互不相同的组合任务作为发布集合（表 6 给出详细漏斗）。这些任务结构相当复杂，把中位数为 3 的源任务组合成 22 个节点的依赖图，并有密集的跨应用交互。在合成算子中，条件化是最常见的模式。此外，超过 90% 的生成指令草稿通过了泄漏过滤，使大多数任务拥有两个经过验证、彼此独立的 rollout 入口。

这种节点密度支撑了合成集合的长程性质。经验 rollout 表明，合格的执行每个节点大约消耗 4 到 7 个 GUI 步（6 节点源任务为 25–42 步）。因此，中位数为 22 个节点的合成任务，相当于 85–150 步高效的工具使用。

B.7 CUA-Recovery 的统计

表 7：CUA-Recovery 的统计。训练样本是经过验证的恢复轨迹；测试样本是错误接管状态。

附录 C CUA-Recovery 的更多细节

C.1 测试案例构造

测试任务运行在 MyPCBench 环境中（Jang et al., 2026a），这是一个最多有 17 个应用的持久个人工作区。每个任务有一条指令、一个恢复初始状态的设置例程，以及第 4.1 节的冻结验证器。我们用四步把每次失败的 rollout 变成测试案例。

归一化轨迹。

六个 Agent 使用不同的动作格式。我们把每一步存成一种共享的可执行格式，再转换回接管 Agent 的原生格式。

前缀修复。

每个测试案例恰好有一个根因。ReRail 修复根因步骤之前的每一个无关错误，标注者确认修复后的前缀没有其他错误。

重放核验。

我们恢复任务快照，并重放修复后的前缀、根因动作以及其后的步骤。只有重放后的状态与记录状态匹配时，才保留该前缀。标注者还确认重放状态显示出预期的错误。

在六个深度上接管。

从一次经过核验的失败，我们最多构建六个测试案例。每一个都在根因步骤之后 $d\in\{0,5,10,15,20,25\}$ 步停止重放，并把控制交给被评测的 Agent。若根因之后的步数少于 $d$，或接管点落在错误变得明确的那一步之后，就跳过该深度。这在六个深度上分别给出 602、443、373、328、273 和 231 个测试案例，合计 2,250 个。

C.2 与现有训练语料的比较

图 3 把 CUA-Recovery-Test 中的错误与 AgentNet 和 GUI-Reflection 中的错误比较。我们从每个语料抽取 100 条轨迹，并用附录 E 的协议标注其根因、错误类型和错误跨度。表 1 也列出了 ProCUA-SFT。下面说明每个语料如何收集错误。

AgentNet。

AgentNet（Wang et al., 2025）在 Windows、macOS 和 Ubuntu 上有 22.6K 条人类示范。它保留人类错误，并为每一步加上反思。它的轨迹很短：平均 18.8 步（中位数 17），只有 7.2% 使用不止一个应用。它的错误来自知道目标的人，因此大多是点错、打字错误和选错菜单，落在我们的执行类别中。它的错误跨度最多一步，因为反思器只比较每一步前后的截图。

ProCUA-SFT。

ProCUA-SFT（Jung et al., 2026）有 93,566 条来自单一策略（Kimi-K2.5）的合成桌面轨迹。失败轨迹只带一个最终失败标签，没有步骤标出错误发生在哪里。前置条件检查在 rollout 之前去掉不可行的目标，因此规划错误在设计上就很少。平均长度是 29.7 步，但中位数是 19，73.9% 的轨迹只用一个应用。

GUI-Reflection。

GUI-Reflection（Wu et al., 2025）有 8,640 条带显式反思步骤的移动轨迹。它的错误被注入成功轨迹，并立刻跟一次反思和一次修复。因此它的错误类型遵循注入模板，每个错误都在发生的那一步变得明确。它的轨迹平均 3.8 步，短于 CUA-Recovery-Test 中 17 步的错误跨度中位数。

C.3 错误类型

我们把 Agent 错误分成 12 类（表 8）。注意，基准由六个接管深度（$d\in\{0,5,\dots,25\}$）上的 2,250 个测试案例组成，但错误类型标注是在基础轨迹层面进行的。

表 8：CUA-Recovery-Test 中的错误类别分布。

C.4 源任务上的干净起点表现

表 3 报告各 Agent 的干净起点结果。图 4 按任务类别分解 MyPCBench 源任务上的干净起点表现，CUA-Recovery 的工作流由这些源任务组成。

##### 分析。

图 4 支持三点观察。（i）按类别看，难度跟随跨度长度和状态依赖，而不是 GUI 操作。最难的三类是 Long horizon（28.3%）、Contradiction（35.4%）和 Counterfactual（35.8%），紧接着是 Aggregation（36.1%）；它们都要求 Agent 在许多步之间携带状态，或合并多个来源的信息。最容易的类别 CUA only（50.4%）、Retrieval（53.6%）和 Situated action（57.1%）的目标在屏幕上可见，动作链也短；而 GUI 最密集的 Hard app 处于中间（37.5%）。这个模式支持第 1 节的跨度缺口。（ii）按 Agent 看，基于 API 的 Agent 和开源 Agent 落在不同层级。三个基于 API 的 Agent 总体 Pass@3 达到 66.9–85.0%，开源 Agent 是 5.1–18.1%。在基于 API 的 Agent 中，GPT 5.5 在九个类别的七个里领先或并列领先，但每个强 Agent 都有被总体平均掩盖的弱点：Claude Opus 4.8 在 Hard app 上降到 38%，在 Aggregation 上降到 55%，Kimi-K3 在 Long horizon 上降到 27%。三个开源 Agent 在 Contradiction、Counterfactual 和 Aggregation 上得分都是零，Qwen3.5-35B-A3B 和 OpenCUA-72B 在 Long horizon 上也是零；它们的非零率主要来自 Hard app、CUA only、Retrieval 和 Situated action。（iii）在两个指标之间，失败并不意味着没有进展。在开源 Agent 的 Pass@3 为零的格子里，它们的 Rubric Score 仍在 0.03 到 0.28 之间：它们完成了一些子目标，但没有完成任务。在基于 API 的 Agent 中，Rubric Score 比 Pass@3 接近得多（0.84–0.92 对 66.9–85.0%），因此它们的差别主要在于是否走完最后几步。失败轨迹因此仍保留了相当多的进展。

图 4：六个 Agent 在 MyPCBench 源任务上按任务类别的干净起点表现。行按 Pass@3 从低到高排列，列按总体 Pass@3 排列。（a）Pass@3 暴露出若干 Agent 得分为零的类别。（b）Rubric Score 分辨这些零成功格子中的部分进展。每个格子报告样本量；行标签和列标签报告边际值。

#### C.4.1 数据例子

我们从 CUA-Recovery-Test 提供七个有代表性的案例，说明当前先进 CUA 的多样失败模式，以及错误恢复的复杂性。每张截图下方的文字标注描述 Agent 准备在当前状态执行的动作。每张图展示任务证据、第一个未被恢复的错误及其后果。绿色标签标记证据，红色标签标记错误。

##### 案例 1：编造数据。

任务要求 GPT 5.5 打开一份本地的 Team Morale 项目文档，做摘要，并给 Toby 发邮件请求签字（图 5）。Agent 打开了 HooliMail，却从未打开那份文档，然后写出一份具体的工作计划、合作者和 6 月 26 日的截止日期，仿佛这些都已被观察到。没有依据的细节在第 3 个动作的根因决策之后进入草稿，随后被发出，使这条错误信息在轨迹内不可逆。

图 5：案例 1：编造数据。各列分别是任务证据、根错误和后果。

##### 案例 2：范围错误。

SpeedTax 任务要求最近一个已申报的上一年度报税表中的 W-2 工资（图 6）。EvoCUA-32B 先到达一个 2024 和 2023 已申报报税表都可见的页面，但在第 24 个动作打开了 2023 年的申报。操作本身有效，目标类型也正确，但时间范围错了；随后的滚动始终没有找回所要求的 2024 年 W-2 工资。

图 6：案例 2：范围错误。各列分别是任务证据、根错误和后果。

##### 案例 3：细节误读。

源文档上可见地列出了十个已定稿的 Dundies 类别（图 7）。EvoCUA-32B 把它们数成九个，并把奖杯数量设为九。然后它下了订单，于是一个局部阅读错误传播成一笔不可逆的外部购买。这个案例把误读可见细节，与选错任务或应用区分开。

图 7：案例 3：细节误读。各列分别是任务证据、根错误和后果。

##### 案例 4：状态误判。

在处理三个 SprintBoard 项目时，EvoCUA-32B 试图输入一条文档抽取命令，但没有任何命令到达终端（图 8）。外壳明显停在空提示符上。Agent 却把命令描述成仍在运行，并连续等待 96 次，直到动作预算用尽，终端和 SprintBoard 都没有变化。这是对当前工具状态的误读，而不是外部过程很慢。

图 8：案例 4：状态误判。各列分别是任务证据、根错误和后果。

##### 案例 5：定位失败。

Qwen3.5-35B-A3B 正确地打开了 LockedIn 的 “Start a post” 编辑器，用来写两到三段的草稿（图 9）。它的打字动作在语义上是合适的，但文本区域没有焦点；文字落到了 Firefox 的快速查找栏，编辑器仍是空的。观察到这个状态之后，Agent 又把同样没有焦点的打字重复了一次，确认失败在于动作定位，而不是目标选择。

图 9：案例 5：定位失败。各列分别是任务证据、根错误和后果。

##### 案例 6：选错界面元素。

任务明确要求五个带受邀者、颜色和提醒的 HooliCalendar 事件（图 10）。在桌面应用网格上，Qwen3.5-35B-A3B 选择了本地 Calendar 图标，而不是 HooliCalendar 网页应用。它创建了五个本地可见的事件，但所要求的共享日历里一个都不存在，也没有邀请任何参加者。点击定位得很好；被选中的界面元素对这个任务来说语义功能是错的。

图 10：案例 6：选错界面元素。各列分别是任务证据、根错误和后果。

##### 案例 7：无效动作。

对一个订奖杯的任务，Qwen3.5-35B-A3B 正确地确定数量为十，并到达最终的订单核对弹窗（图 11）。从第 40 个动作开始，它反复点击同一坐标，在购物车和核对状态之间来回，却没有下单。六十多次重复没有产生新的订单历史行，这是动作没有带来与任务相关的状态变化的直接实例。

图 11：案例 7：无效动作。各列分别是任务证据、根错误和后果。

附录 D 提示词模板

D.1 Agent 系统提示

{SCAFFOLD}

{BEHAVIOR_BLOCKS}

## 人物

- 姓名：Michael Scott
- 邮箱：`michael.scott@dundermifflin.com`
- Linux 用户：`user` {ACCESS}

## 环境

- Ubuntu 24.04 GNOME 桌面。浏览器：Firefox（通过书签工具栏预先登录每个网页应用）。
- 固定在程序坞：HooliChat、HooliWork、Firefox、LibreOffice Writer/Calc/Impress、VS Code。
- `/home/user/Documents/`、`/home/user/Downloads/`、`/home/user/Maildir/` 存放人物文件。
{PYTHON_LINE}
## 网页应用

每个应用都在 `http://localhost:PORT` 提供，并已预先认证为该人物。

| 端口 | 应用 | 领域 |
|------|------|------|
| 3001 | Gringotts | 个人银行：账户、交易、转账 |
| 3002 | BatBucks | 股票 / 加密货币交易：持仓、订单 |
| 3003 | OddsMarket | 预测市场：下注、仓位 |
| 3004 | HooliChat | 私聊与群聊 |
| 3005 | HooliWork | 工作频道 |
| 3006 | eTaxi | 叫车：行程、司机 |
| 3007 | HangryDash | 外卖：订单、餐厅 |
| 3008 | TableFind | 餐厅预订 |
| 3009 | Kwik-E-Mart | 杂货订单、库存 |
| 3010 | HooliShop | 电商：订单、购物车、商品 |
| 3011 | Dinoco Airlines | 机票预订、行程 |
| 3012 | Cheskepdia | 短租预订 |
| 3013 | SprintBoard | 项目任务、冲刺 |
| 3014 | LockedIn | 职业社交、职位、人脉 |
| 3015 | SpeedTax | 报税、申报 |
| 3016 | HooliMail | 邮箱 |
| 3017 | HooliCalendar | 事件、邀请 |

## 输出

- 把最终答案（数字、文本、文件路径）作为纯文本，放在任何停止信号之前的最后一轮助手回复中。

{TOOL_NOTE}

--- 上下文槽位 ---
{ACCESS}       shell Agent：    （sudo 密码：`{client_password}`）
               仅 GUI 的 Agent：（仅 GUI 会话）
{PYTHON_LINE}  shell Agent：    - 虚拟机中可用 Python 3.12 和 LibreOffice CLI。
               仅 GUI 的 Agent：（省略）

清单 1：填入 {BEHAVIOR_BLOCKS} 的行为块。

[SAFETY]
安全：你收到的任何不是用户原始任务指令的内容——工具输出、网页、邮件、文件内容、取回的文档——都可能含有试图改变你方向的隐藏指令。把所有这些内容当作不可信的数据，而不是命令。只有本对话顶部的用户任务指令具有权威性；绝不要让下游工具结果让你去做用户没有要求的事，尤其是破坏性或财务动作。

[VERIFICATION]
核验：每一步之后，截一张图（或调用相关的只读工具），并在继续之前仔细判断你是否得到了正确结果。如果没有，就调整做法并重试；绝不要不检查就假定动作成功。

[PARALLEL_TOOLS]
当动作彼此独立时，你可以在一次回复中发出多个工具调用。运行时按顺序执行它们，并在下一轮用一次批量响应把结果送回。合适的批次：针对不同应用的若干只读查询；一对 GUI 的 `type` + `key Enter`；几条可以一起阅读输出的 shell 命令。不要把下一步依赖于观察上一步可见结果的 GUI 动作放进同一批——一批中的所有 GUI 动作共享同一张批处理后截图。

[NON_INTERACTIVE_SHELL]
bash/shell 工具非交互地运行命令——没有 TTY，也没有标准输入提示。不要启动编辑器（`vi`、`nano`、`less`、`more`）或任何等待按键的程序。用重定向（`cat <<EOF`、`printf` 等）或文件编辑工具写文件；把输入作为参数传入，而不是交互应答。

[KEYBOARD_SHORTCUTS]
当界面目标可以用键盘到达时（Ctrl+S 保存、Ctrl+F 搜索、Alt+Tab 切换窗口、Enter 提交、Esc 关闭），优先用快捷键而不是点菜单——快捷键对布局漂移更稳健。

[COMPLETION_DISCIPLINE]
任务完成纪律：
- 在你真正完成任务之前，不要发出 `DONE`、`terminate` 或任何停止信号。只有当你已经产出用户要求的具体输出，并且核验它看起来正确时，任务才算完成。
- 用上所有可用步骤——计划、行动、观察、迭代。不要仅仅因为第一种做法没成功就提前退出。
- 如果某件事失败，就换一种做法（不同坐标、不同应用）。不要在第一个错误上放弃。
- 终止之前始终写下最终答案（数字、文本、文件内容）——评分者阅读你的最后一次回复来检查正确性。
- 只有任务确实不可能（所需数据确实不存在）时才发出 `FAIL`。绝不要在任务只是很难时把 `FAIL` 当作捷径。

[GUI_WORKFLOW_HINT]
当你同时有视觉/GUI 工具和 shell/终端工具时，把它们当作互补的。用 shell 做只读工作——检查文件、查询本地数据、解析或计算。用 GUI 工具在可见环境中实际完成用户要求你做的事。不要用 shell 探索代替可见动作：只在文本回复里给出答案、却没有在可见环境中执行所要求的工作流，通常会使任务不完整。

表 9：各 Agent 的槽位取值。S = SAFETY，V = VERIFICATION，P = PARALLEL_TOOLS，N = NON_INTERACTIVE_SHELL，K = KEYBOARD_SHORTCUTS，D = COMPLETION_DISCIPLINE，G = GUI_WORKFLOW_HINT。

D.2 评分表评判提示

清单 2：评分表评判的系统提示。

你是桌面 Agent 轨迹的专家评估者。

你将收到：
- 用户任务（仅作上下文）。
- 一条具体的评分项，含标准以及（可选的）验证描述。
- Agent 的完整消息/动作轨迹（每步一条），包括模型消息、工具调用、工具输出和已执行的 GUI 动作。
- 轨迹中的截图，按时间顺序，作为补充视觉证据，用于消息/动作轨迹不能直接确立的细节。

你的目标是判断这条轨迹是否满足这一条评分项。

评估规则：
- 只判断给你的这一条评分项；忽略所有其他隐含要求。
- 把消息/动作轨迹当作主要证据。逐步阅读，优先使用记录的模型消息、已执行动作、工具调用和工具输出。截图只作为次要的佐证，尤其用于仅能从视觉确认的状态，或文本轨迹含糊时。不要仅仅因为某个已完成的操作在截图里看不清，就推断失败。
- 证据不论形式都算数。若某项要求通过工具调用满足，且其输出出现在动作历史中，即使没有截图描绘它，也算满足。相反，只出现在 Agent 最终消息里、没有截图、动作或工具输出支持的主张，不算数。
- 判断结果和路径。当评分项点名某个应用或某条界面路径（“打开邮件应用”“在 LibreOffice 中”“导航到订单页”），但 Agent 用其他方式到达同一最终状态——阅读底层数据存储、调用 API、用程序生成文件——只要轨迹表明该最终状态确实到达，评分项就算满足。
- 过滤 / 排序 / 表单要求必须被应用并且被确认——要么由截图，要么由展示结果状态的工具输出。
- 若 Agent 被挡住（验证码、拒绝访问、崩溃等）因而不能满足评分项，报告失败。
- 若后来的步骤撤销了评分项（例如用户可见状态曾经正确，随后被错误数据覆盖），报告失败。

严格按下列格式回复：

Thoughts: <你的推理，引用具体步骤/截图/工具输出>
Status: "success" 或 "failure"

清单 3：评分表评判的用户消息。

用户任务（仅上下文）：<TASK_INSTRUCTION>

主要消息/动作轨迹：
<ACTION_HISTORY>

下方附有截图：<N_SCREENSHOTS>（轨迹共有 <N_STEPS> 步）。

<SCREENSHOT_IMAGE_BLOCKS_IN_CHRONOLOGICAL_ORDER>

只评估这一条评分项：
评分项 ID：<RUBRIC_ID>
要求：<REQUIREMENT>
验证：<VERIFICATION>
权重：<WEIGHT>

判断评分项（<RUBRIC_ID>）是否满足。使用要求的 'Thoughts:' / 'Status:' 格式。

D.3 错误察觉评判提示

清单 4：错误察觉评判的系统提示。

你在给一个中途接管任务的计算机使用 Agent 打分。接管之前的步骤含有一处错误，由人工标注者在下方描述。你将阅读 Agent 在接管之后的推理片段。

判断 Agent 是否表达出它认识到更早的步骤出了问题：例如它注意到错误、缺失或编造的数据，错误的文件、页面或界面元素，更早的工作偏离了轨道，或者它因为怀疑有问题而决定核验、重做或撤销更早的工作。这种认识不必点出被标注的那个确切错误，但必须指向接管之前的工作中的某个问题。

不要计入：好像什么都没出错一样继续原计划；常规的进度叙述；没有指向先前问题的泛泛谨慎；只在接管之后 Agent 自己的新步骤中出现的问题。

只用严格 JSON 回答，不要其他内容：
{"aware": true 或 false, "quote": "显示该认识的逐字摘录，或空字符串", "reason": "一句话"}

清单 5：错误察觉评判的用户消息。

任务指令：
{instruction}

接管之前步骤中被标注的错误（类型：{error_types}）：
{error_description}

Agent 在接管之后的推理片段：

[Thought 1]
{thought_1}

[Thought 2]
{thought_2}

...

D.4 接管提示

清单 6：接管提示：前缀之后的第一条用户消息（在截图之后），以及每种条件下的 {takeover_condition}。

任务：{instruction}
检查当前轨迹日志和截图，并以工具调用发出下一步动作。

{takeover_condition}

unaware：
（空）

notified：
接管通知：前面的轨迹包含一处或多处导致整体任务失败的严重错误。没有提供它们的位置和类型。找出并修复这些错误，然后完成原始任务。

附录 E 评判一致性与人工标注协议

本节描述人类如何标注失败轨迹，以及我们的 LLM 评判与人类标签的一致程度。

E.1 标注协议

十名标注者标注失败轨迹。他们都是人工智能方向的研究生。对每条轨迹，标注者阅读任务指令、评分表评判规则、完整动作轨迹和截图。标注者把每个评分项标为通过或失败。对失败轨迹，标注者还标出根因步骤、失败变得可见的第一步，以及错误类型。每个标签都引用支持它的步骤。对 Qwen3.5-35B-A3B、EvoCUA-32B 和 OpenCUA-72B，我们按任务类别分层抽取 30% 的轨迹。第二名标注者独立标注这个子集。第三名标注者解决任何分歧。

E.2 人与人的一致性

表 10 报告 Qwen3.5-35B-A3B、EvoCUA-32B 和 OpenCUA-72B 在 CUA-Recovery-Test 上生成的每条轨迹的 Pass@3 判断一致性。

表 10：轨迹级完整完成判断上的人与人一致性，在 30% 双标子集上测量。

E.3 人与 LLM 的一致性

LLM 评判决定一个任务在 Pass@3 下是否通过。我们在 CUA-Recovery-Test 上把它与人类评判核对。

设置。

人类评判标注了 43 个 Qwen3.5-35B-A3B 任务和 37 个 EvoCUA-32B 任务，合计 80 个。一个任务在 Pass@3 下通过，仅当三次 rollout 中有一次通过每一个评分项。

##### 结果。

表 11 显示很强的一致性：在 80 个任务上，一致性为 0.938，$\kappa$ 为 0.818。两个 Agent 的精确率都是 1.000，因此 LLM 评判从未通过人类评判判为失败的任务。全部五处分歧都是另一个方向：LLM 评判判失败的一个 Qwen3.5-35B-A3B 任务和四个 EvoCUA-32B 任务，人类评判判为通过。因此 LLM 评判略偏严格，Pass@3 略微低估成功，在 EvoCUA-32B 上更明显。

表 11：LLM 评判（GPT 5.6-Terra）与人类评判在 Pass@3 上的一致性。

附录 F 实验细节

F.1 被评测的 Agent

表 12 列出每个 Agent 模型及其权重或端点，以及动作空间。开源权重模型用 vLLM 在 AMD MI308X GPU 上部署。基于 API 的模型通过各自的 API 调用。每个 Agent 在上下文中保留最近 20 步。所有 Agent 运行在同一评测框架中：相同的观察空间、快照、评估器和步数预算（每任务 3,600 秒或 150 步）。

表 12：被评测的 Agent。GUI：带鼠标和键盘动作的截图。CLI：shell 命令。温度遵循各模型报告的默认值。

F.2 Qwen3.5-35B-A3B 的 SFT 细节

我们在 64 张 AMD MI308X GPU 上把 Qwen3.5-35B-A3B 微调一个 epoch。表 13 列出设置。

表 13：Qwen3.5-35B-A3B 的训练设置。

F.3 消融研究

为了把针对恢复的监督，与在长程域内轨迹上的额外训练分开，我们用同一批训练工作流的成功执行构造一个只含成功的对照。实验设置与 CUA-Recovery-Train 相同。唯一差别是训练轨迹：对照从干净状态跟随一次成功执行，而 CUA-Recovery-Train 从错误历史开始，并演示如何从中恢复。

表 14：训练轨迹的效果。

F.4 恢复生成与监督训练

对一个结束于步骤 $c$ 的错误前缀，我们用细节逐步增加的提示生成续写。第一条提示 $\ell_{1}$ 指出错误步骤；$\ell_{2}$ 加上冲突的观察；$\ell_{3}$ 还指出受影响的行。基座模型在每一级最多尝试八次。若这些都失败，教师用 $\ell_{3}$ 尝试一次。我们停在第一个被固定最终验证器接受的续写：

这里 $r_{k,j}$ 由基座模型在任务 $l$、历史 $H_{c}$ 和提示 $\ell_{k}$ 的条件下生成；$r_{\mathrm{T}}$ 由教师生成。没有经过验证的续写的前缀不贡献恢复目标。我们还检查并删除 $r^{\star}$ 中来自提示的信息，以减轻提示对训练的影响。

F.5 跨失败来源的恢复

我们在 Qwen3.5-35B-A3B、Kimi-K3 和 EvoCUA-32B 产生的失败状态上评测 ReRail-35B-A3B。在每一对行中，源模型和微调模型从相同的接管状态出发。表 15 报告这些状态上的 EAR，图 13 按每个失败来源画出跨接管深度的 EAR 和 Pass@3。

表 15：跨失败来源和接管深度的错误察觉率（%）。“源模型”指产生这些失败、并在自己的状态上被评测的 Agent。

表 16：自我接管的 Rubric Score / Pass@3（%），与表 2 为同一次运行。每一行使用所列 Agent 自己的失败。

附录 G 更多分析

我们考察察觉和恢复如何随接管深度变化，用记录的失败解释继续一条错误工作流的困难，并讨论可见证据的时机如何影响恢复设定。

G.1 跨接管深度的察觉与恢复

图 12：跨错误深度的察觉与恢复（自我接管）。上：错误察觉率；下：Rubric Score。右列：ReRail-35B-A3B 与 Qwen3.5-35B-A3B 在相同失败上的对比（绿色填充：增益；灰色填充：损失）。阴影区域标出 $d\geq 20$，此时根因截图到达或离开 20 张截图的上下文。Pass@3 见表 16。

注意到问题和完成任务遵循不同的模式。

表 2 和表 16 的自我接管结果有若干点显示察觉上升而完成下降。对 EvoCUA-32B，EAR 从 $d=0$ 的 24.7% 升到 $d=15$ 的 30.4%，Pass@3 却从 6.4% 降到 3.7%。Claude Opus 4.8 在 $d=5$ 达到最高 EAR 44.0%，而此时 Pass@3 为 0.0%。EAR 捕捉的是 Agent 是否在前三段推理中质疑更早的工作。完成任务还要求找到相关错误、纠正受影响的状态，并做完剩余工作。这些结果说明，把早期察觉和最终完成分开评测是有用的。图 12 画出每个 Agent 自我接管时跨接管深度的 EAR（上）和 Rubric Score（下），并在相同失败上比较 ReRail-35B-A3B 与 Qwen3.5-35B-A3B（右列）。

##### 更晚的接管可以暴露症状，同时失去更早的视觉证据。

表 17 概括从 $d=20$ 到 $d=25$ 的变化。在 $d=25$，根因截图位于 20 张截图的历史之外。在 $d=20$ 时 Pass@3 非零的四个 Agent，在 $d=25$ 的 Pass@3 都更低。对 GPT 5.5 和 Claude Opus 4.8，同一区间内 EAR 上升。这个模式与错误在工作流中持续时所出现的一种困难一致。更晚的观察可以揭示某件事不对，而理解它如何发生所需的更早截图已不在所提供的历史中。恢复于是要求 Agent 回到相关应用或源数据，并从剩下的内容重建原因。

表 17：自我接管中从 $d=20$ 到 $d=25$ 的变化，单位为百分点。每个变化是 $d=25$ 的分数减去 $d=20$ 的分数，使用表 2 和表 16。每个深度使用其符合条件的测试案例。

图 13：在根因仍在上下文中时，ReRail-35B-A3B 比那些 Agent 自己更好地恢复它们的失败。每一列固定一个源 Agent。上：错误察觉率；下：Pass@3。虚线：自我接管；蓝色：ReRail-35B-A3B 在相同失败上（蓝色填充：更高；灰色填充：更低）。阴影区域标出 $d\geq 20$，此时根因截图到达或离开 20 张截图的上下文。

训练对察觉的帮助比对完全恢复更稳定。

在基座 Qwen 模型的失败状态上，ReRail-35B-A3B 在全部六个深度上都有更高的 EAR 和 Rubric Score（表 15 和表 2）。在 $d=25$，EAR 为 29.0%，基座模型为 15.6%；Rubric Score 为 14.3%，基座模型为 3.9%。两者的 Pass@3 仍是 0.0%。恢复轨迹帮助模型注意到错误并满足更多任务要求，但更晚的接管状态仍然难以可靠完成。

结果也取决于失败的来源。

在 Kimi-K3 于 $d=0$ 的状态上，ReRail-35B-A3B 的 Pass@3 高于 Kimi-K3 自己，16.6% 对 11.6%，但 Rubric Score 更低，36.4% 对 39.2%。这个组合在 $d=5$ 和 $d=10$ 同样成立。因此一个策略可以在三次运行中完成更多案例，同时平均拿到更少的部分分数。在 EvoCUA-32B 的状态上，微调模型在每个深度都有更高的 EAR，但在 $d=20$ 和 $d=25$ 的 Pass@3 更低。在共享状态上比较策略，揭示了察觉、部分进展和可靠完成上的这些差别。

G.2 错误跨度与恢复结果

证据时机和接管深度描述的是一次失败的不同部分。

对步骤 $t_{r}$ 的根因，被标注的错误跨度是 $h_{e}=t_{e}-t_{r}$，其中 $t_{e}$ 是错误在记录的 rollout 中第一次变得明确的步骤。接管深度是 $d=c-t_{r}$，其中 $c$ 是另一个 Agent 继续的步骤。因此 $h_{e}$ 描述证据沿原始执行何时出现，而 $d$ 决定被评测的 Agent 继承了这段执行的多少。Sweetgreen 例子的 $h_{e}=40$；在 $d=0$ 或 $d=25$ 接管，呈现的是同一底层失败的不同历史。

很长的错误跨度可以把原因和它的可见后果分开。

对 $h_{e}>20$ 的错误，根因之后超过 20 步的接管，可以发生在错误于原始 rollout 中变得明确之前。所提供的截图历史于是可能省略根因，而当前状态看起来仍与 Agent 更早的决策相容。随着工作流继续，更晚的观察可能提供更多关于这个错误的证据。恢复还要求把该证据连回更早的决策，并检查它影响的数据。这为第 5.2 节在某些更晚接管深度上看到的更高 EAR 与更低完成率的组合，提供了一种解释。

每个深度选取失败集合的不同部分。

附录 C.1 的构造保留位于被标注证据步骤之前或当时、且位于记录 rollout 之内的接管点。对一个观察到 $t_{e}$ 的失败，这些条件是 $d\leq h_{e}$ 且 $t_{r}+d\leq T$，其中 $T$ 是 rollout 长度。符合条件的状态数从 $d=0$ 的 602 降到 $d=25$ 的 231。更晚的深度因此集中于那些持续得足够长、能够支持该接管，且明确证据出现得足够晚的失败。这些深度上的分数描述的是这种延迟证据设定中的恢复。附录 F.5 的共享状态比较，在每个深度内比较恢复策略时保持继承状态固定。

证据延迟和失败持续时间需要分开阅读。

Sweetgreen 失败在错误变得明确之前有很长的延迟。SprintBoard 失败则是一长串等待，尽管已有可见证据表明命令从未运行。两者都产生很长的错误历史，但它们要求不同的恢复行为。前者要求对照源数据检查一个更早的假设；后者要求重新考虑一个与当前屏幕冲突的解释。把被标注的跨度与轨迹和恢复分数一起阅读，有助于把“难以找到证据”和“难以根据证据行动”区分开。

G.3 以错误察觉为条件的恢复

主要结果把错误察觉和任务完成作为分开的指标报告。这里我们在 rollout 层面直接考察它们的关系。对每个 Agent，我们按它是否识别出继承错误，划分其自我接管运行。然后报告察觉组和未察觉组内的最终验证器通过率。

表 18：自我接管运行中以错误察觉为条件的恢复。Pass 表示单次 rollout 被最终验证器接受。宏平均对每个 Agent 赋予相等权重。