GraceBench：诊断图形界面智能体的执行稳定性

GUI 智能体如何失败：用于执行稳定性诊断的 GraceBench

Ridong Zhang、Shuxian Liang、Chaoqun Wan、Zhen Huang、Xian-Sheng Hua

Institute of AI for Engineering, Tongji University

项目页：https://iaie-physicalai.github.io/GraceBench

摘要。随着 GUI 智能体越来越多地被部署来做移动任务自动化，其可靠性不仅取决于最终任务结果，也取决于它们是否沿着稳定的交互轨迹到达这些结果。无论在日常自动化场景还是测试工作流中，多余动作、绕路和执行错误都会给采集到的数据增加噪声，引入不可逆的副作用，或削弱信任，即便智能体最终完成了任务。因此有必要系统诊断执行稳定性，包括智能体是否偏离可行路径、进入循环、陷入停滞，或从不稳定动作中恢复。然而现有基准主要评估最终任务成功，或一小部分中间里程碑，步骤级执行行为仍不清楚。为弥补这一缺口，我们提出 GraceBench，一种在线评测框架。它把移动应用的可达交互空间表示为 UI Transition Graph（UTG，界面转移图），为步骤级执行诊断提供结构参照。为了让动态界面观察与图状态可靠对齐，GraceBench 在这种图对齐表示上使用以视频为据的轨迹评测，通过偏离率、循环负担率和恢复能力等指标，评估超出最终成功之外的过程稳定性。GraceBench 包含横跨 10 个应用的 169 项任务，并构造了 10 张 UTG，其中有 2,909 个规范 GUI 状态和 3,116 条观察到的转移。在 3,718 条轨迹上，GraceBench 表明结果分数掩盖了执行不稳定：GPT-5.6 Sol 取得最高成功率（SR），但恢复能力最低；51.24% 的成功运行仍包含一次偏离或循环；成功率（SR）和完成率（CR）相同的轨迹，在恢复行为上仍可能相差很大。代码将公开。

译注：原文 Markdown 抽取在摘要后有一张无单元格内容的空表，HTML 中此处没有可转录的数据，故不保留空表。

1 引言

图形用户界面（GUI）智能体越来越被期望代表用户操作真实软件环境（Zhang 等人，2025），从完成日常移动任务（Rawles 等人，2025）到支持软件测试的数据采集工作流。在这类设定中，智能体的能力并不只由它最终是否到达目标状态决定；执行过程本身同样重要。在基于 GUI 的自动化测试中尤其如此：系统性能、日志、资源占用和行为信号往往沿执行轨迹采集。如果智能体偏离、重复动作或未能恢复，这些依赖路径的测量就会变嘈杂，难以解释、复现和信任（Dong 等人，2021）。因此，执行稳定性是把 GUI 智能体可靠部署到真实交互环境中的一项关键要求。

现有 GUI 智能体基准主要评测任务完成，通常检查最终状态是否满足目标条件（Rawles 等人，2025）。终态成功有用，但对执行过程的稳定性几乎不提供可见性。一些近期工作引入中间里程碑，例如必要状态或子任务，以测量分阶段进展（Chai 等人，2026a；Chen 等人，2025），但这种评测仍然是粗粒度的：它隐含地把任务当成大体线性，并忽略复杂交互环境中每个动作的效果。只检查预先定义的语义里程碑，基于里程碑的评测无法评估里程碑之间的执行稳定性。如图 1 所示，现有评测方法无法区分一个成功的智能体是沿稳定路径前进、偏离后再恢复，还是在完成前落入重复循环。没有步骤级诊断信号，就很难系统理解真实 GUI 交互中的执行不稳定。

图 1：现有基于里程碑的过程评测的局限。一次干净执行和一次带有中间循环的不稳定执行，可以满足相同的语义里程碑，因而得到相同结果。只观察里程碑是否达成，会隐藏循环、恢复行为，以及沿执行轨迹引入的噪声。

为处理这一缺口，我们提出 GraceBench，一个用于诊断 GUI 智能体在真实移动应用中执行稳定性的基准。GraceBench 使用 UTG，把一个应用的有限可达交互空间表示为一张图。在 UTG 中，节点对应 GUI 状态，边对应状态之间可执行的动作转移（Yang 等人，2015；Wen 等人，2024）。这张图充当评测执行的坐标系：节点表明智能体在哪里，边表明智能体正往哪里移动，周围的图则揭示还有哪些替代交互可用。GraceBench 把每项任务定义在任务专属的 UTG 子图上，并把记录下来的执行轨迹映回这张图，做步骤级诊断。因为动态移动界面会在动作期间和动作之后变化，GraceBench 使用同步的视频证据，把观察与图状态对齐，并诊断相邻决策之间发生了什么。

基于这种 UTG 表示，GraceBench 对 GUI 智能体的评测超出最终成功。它包含横跨 10 个应用和多个领域的 169 项任务，建立在 10 张、共 2,909 个规范 GUI 状态的 UTG 上；每项任务匹配到的状态及其一跳邻域平均覆盖 41.09 个规范 GUI 状态，为步骤级诊断提供局部结构参照。每项任务配有简洁指令和详细指令两种变体，使我们既能在自主路径规划下、也能在步骤级执行指导下评测稳定性。除成功率和完成率外，GraceBench 报告偏离率、循环负担率和恢复能力，以评测 GUI 智能体的执行稳定性。

我们在两种指令条件下，于全部 169 项任务上评测了 11 个模型，其中包括 2 个 GUI 专用模型和 9 个通用模型，得到 3,718 条轨迹。不稳定驱动 GUI 智能体失败，并且即使在成功结果背后仍然存在。在这些轨迹中，智能体经常因路径偏离和循环而失败，同时 51.24% 的成功轨迹仍包含一次偏离或循环。即便取得最高成功率的 GPT-5.6 Sol，在其观察到的恢复机会上恢复能力也最低。结果受控的比较进一步表明，成功和完成结果相同的轨迹在恢复行为上仍可能相差很大，说明仅凭最终成功会高估 GUI 智能体的可靠性。

表 1：与有代表性的 GUI 智能体基准的比较。Venue 表示有代表性的发表场合或预印本年份；其余列概括对过程评测、在线执行、多路径任务、图参照、稳定性指标和视频证据的支持。

我们的贡献概括如下：

• 我们提出 GraceBench，一个专门用于在真实移动应用环境中评测 GUI 智能体执行稳定性的基准。
• 我们提出一种以视频为据的在线评测框架，把记录下来的智能体轨迹映射到界面转移图上，从而对偏离、循环和恢复能力做步骤级诊断。
• 我们系统评测了多种类型的 GUI 智能体，并识别出仅从最终成功很难观察到的共同不稳定模式，为今后诊断和优化 GUI 智能体能力提供证据。

2 相关工作

2.1 移动 GUI 智能体基准

早期 GUI 智能体基准主要依赖离线评测，把预测动作与一条唯一的标准轨迹逐步匹配（Rawles 等人，2023；Li 等人，2024）。这种协议可以扩展，但把 GUI 控制简化成轨迹模仿，忽略了多条有效路径，以及智能体从偏离中恢复的能力。以 AndroidWorld（Rawles 等人，2025）为代表的近期在线基准，允许智能体与可执行环境交互，并从最终界面状态评测任务完成。然而，最终成功指标仍然粗糙：它们揭示任务是否完成，却不揭示执行有多可靠。具备过程意识的基准进一步引入中间监督。A3（Chai 等人，2026a）评测必要语义状态的完成比例，SPA-Bench（Chen 等人，2025）核验预先定义的应用级子任务，ProBench（Yang 等人，2025）采集过程信息以检查关键步骤是否完成。这些工作超出了只看结果的评测，但其信号仍主要定义在里程碑或语义检查点上。因此，它们对发生在里程碑之间的失败可见性有限，也无法区分仅仅成功的执行和稳定的执行。我们的工作聚焦于这一缺失层，在执行状态和动作转移的粒度上评测 GUI 智能体。

2.2 面向 GUI 智能体的图结构表示

图结构已被广泛用于把 GUI 交互建模为离散界面状态上的转移。现有工作把这类表示用于应用探索和知识构造（Sun 等人，2025；Chai 等人，2026b）、任务生成和预训练（Ye 等人，2025；Wu 等人，2024），以及运行时规划或恢复（Yu 等人，2026；Guo 等人，2025；Zhong 等人，2026）。这些方法表明，图为多步骤、多路径的 GUI 交互提供了一种自然抽象。在 GUI 智能体评测中，ColorBench（Song 等人，2025）遍历界面状态以构造应用级图，而 MobiFlow（Feng 等人，2026）通过轨迹融合和状态压缩构造更抽象的图。两项工作都用图结构让离线评测更接近真实交互。然而，它们仍然忽略真实环境中的动态变化，例如变化的内容和界面组件，如何影响智能体执行；GraceBench 则把实况执行轨迹与界面转移图对齐，以诊断步骤级偏离、停滞、恢复和执行稳定性。

3 GraceBench

为把上文所推动的基于图的诊断落到操作上，GraceBench 在基准构造和评测全程使用任务专属 UTG 作为共享参照。我们先建立应用级 UTG，并在 10 个多功能移动应用上整理 169 项长程任务，每项都有简洁指令和详细指令。智能体随后在物理设备上执行这些任务，同时 GraceBench 记录同步的动作、观察和视频证据。

图 2 概述由此得到的 GraceBench 流程：面板（a）说明由智能体驱动的 UTG 构造，面板（b）概括任务整理，面板（c）展示以视频为据的轨迹评测。下面按顺序描述这些组成部分。

图 2：GraceBench 任务整理与评测总览。GraceBench 先通过智能体驱动的探索建立应用级 UTG，整理任务专属子图和指令，再把步骤级视频证据映射为图对齐的执行标签和稳定性指标，从而评测在线智能体轨迹。

3.1 任务整理

图 3：169 项 GraceBench 任务的分布。（a）10 个应用上的功能领域。（b）参考路径长度分布。

#### UTG 构造。

对每个应用，我们构造一张应用级 UTG，作为任务整理和轨迹评测的结构基础。我们把应用级 UTG 记为 \(G=(V,E)\)，其中 \(V\) 是与任务相关的 GUI 状态集合，\(E\) 是状态之间有向动作转移的集合。每个节点 \(v\in V\) 对应一个可经视觉核验的 GUI 状态，每条边 \(e=(v_i,a,v_j)\) 表示在状态 \(v_i\) 执行动作 \(a\) 会到达状态 \(v_j\)。

我们用一个由智能体辅助的探索循环采集界面转移。探索之前，我们设定应用范围，并把支付、提交订单和授权变更等高风险操作当作边界状态。每一步，智能体通过 ADB 观察当前屏幕，包括截图和界面层次，识别可交互元素，选择一个候选动作，再通过 ADB 执行该动作（Android Developers，2026）。每次观察到的界面转移被记录为 UTG 中的一条状态—动作—状态边。自动探索循环的实现细节见附录 D。

探索之后，我们通过去重等价界面状态、过滤不稳定的文本属性，并为每个保留状态保存一张代表性截图，来清洗并规范化采集到的图。在 10 张 UTG 上，GraceBench 把 3,265 条采集到的状态观察规范化为 2,909 个规范 GUI 状态，以及与之对应的观察到的转移。附录 D.1 报告按应用的清单和计数规则。GraceBench 中使用的全部 UTG 在抽取任务前都经过人工复核，以确保状态有效、转移可执行，并覆盖主要功能路径。

#### 任务子图抽取。

从经过人工复核的 UTG 中，我们选择完成语义稳定、且可经视觉核验的终态作为任务目标，排除浅层入口或中间面板状态。对每项任务 \(\tau\)，我们定义自然初始状态 \(v_{\tau}^{\mathrm{start}}\) 和目标状态 \(v_{\tau}^{\mathrm{goal}}\)，然后抽取任务专属子图 \(G_{\tau}=(V_{\tau},E_{\tau})\subseteq G\)，其中包含与任务相关的状态，以及使合法进展朝向目标的可执行转移。该子图包含替代的有效路线，但排除与任务无关的绕路，为轨迹诊断和过程级指标提供多路径结构参照。

#### 指令生成。

对每项任务，GraceBench 从任务子图导出两种指令变体：简洁指令陈述用户目标及必要约束；详细指令沿一条经过人工核验的可行路径，给出步骤级操作。这种成对设计在任务目标保持固定的情况下改变指令粒度，把规划歧义与低层执行稳定性分开。我们进一步把查询词、类别、目标实体和选择器参数化，使任务可扩展，并减少对固定表面形式的过拟合。

3.2 在线执行环境

遵循 ProBench（Yang 等人，2025），GraceBench 在在线循环中于物理 Android 设备上评测智能体。每一步，智能体接收当前截图、任务指令和交互历史，其文本动作被解析为 ADB 命令并执行，直到完成或预算耗尽。每个回合被记录为

\[ T=(o_1,a_1,o_2,a_2,\ldots,o_T,a_T,o_{T+1}), \tag{1} \]

其中 \((o_t,a_t,o_{t+1})\) 表示动作前屏幕、已执行动作，以及用于步骤级评测的稳定后的动作后屏幕。

GraceBench 使用的动作空间为 CLICK、SWIPE、TYPE、ENTER、BACK、COMPLETE 和 WAIT；HOME 被排除，因为任务停留在单个应用内。

视频采集被集成到同一执行循环中。GraceBench 在智能体第一次决策之前开始连续录屏，并在回合终止后停止。录制用 scrcpy 实现（Genymobile，2026），同时运行器为每一步记录动作类型、动作时间戳、动作前截图和动作后截图。这保证视频证据与智能体的实际决策和设备动作时间线同步。

先前基于录屏的 GUI 分析用视频保留从用户操作到视觉反馈的时间过程（Liu 等人，2025）。GraceBench 则把视频用作动态 GUI 效果的时间证据，例如加载、弹窗、动画和内容变化，这推动了下面的图对齐诊断。

3.3 以视频为据的轨迹评测

GraceBench 通过把观察到的智能体行为与任务子图对齐来评测每条执行轨迹。评测流程包含四个阶段。第一，回合级视频按动作时间戳切成步骤级片段。这些片段为每个动作之前、期间和之后发生的事情提供视觉证据。第二，GraceBench 从完整的应用 UTG 中取出任务专属子图。子图包含任务初始状态、目标状态、所需转移和替代有效路径，作为判断观察到的动作是否推进任务的参照结构。第三，一个基于视频的评测器使用对应的步骤级视频片段和已执行动作，分析每次局部转移 \((o_t,a_t,o_{t+1})\)。评测器把动作前和动作后的观察映射到图状态。对每个观察，匹配到的图状态定义为

\[ \hat{v}_{t}= \begin{cases} v_i, & \text{若 } o_t \text{ 匹配状态 } v_i\in V,\\ v_{\mathrm{out}}, & \text{否则}, \end{cases} \tag{2} \]

其中 \(v_{\mathrm{out}}\) 表示应用级 UTG 之外的状态。这一映射把每次局部转移转换成图对齐转移：

\[ (o_t,a_t,o_{t+1})\mapsto(\hat{v}_t,a_t,\hat{v}_{t+1}). \tag{3} \]

基于对齐后的转移，评测器赋予四种步骤级标签之一：\(\mathit{on\ path}\)（在路径上）、\(\mathit{stagnation}\)（停滞）、\(\mathit{deviation}\)（偏离）或 \(\mathit{recovery}\)（恢复）。若一步遵循 \(G_{\tau}\) 中的有效转移，则标为 \(\mathit{on\ path}\)；若它没有造成有意义的状态变化，则标为 \(\mathit{stagnation}\)；若它离开任务子图或进入 \(v_{\mathrm{out}}\)，则标为 \(\mathit{deviation}\)；若它从路径外状态回到 \(G_{\tau}\) 中的有效状态或转移，则标为 \(\mathit{recovery}\)。得到的带标签序列就是图对齐的诊断轨迹：

\[ T'=[(\hat{v}_1,a_1,\hat{v}_2,\ell_1),\ldots,(\hat{v}_T,a_T,\hat{v}_{T+1},\ell_T)]. \tag{4} \]

GraceBench 使用 \(T'\) 识别轨迹级行为，例如缺失的必要转移、持续偏离、重复的无进展动作、循环、偏离后的成功恢复，以及未匹配的 \(v_{\mathrm{out}}\) 状态应如何被赋予行为标签。步骤级诊断标签先由专家智能体生成，再在预注册的、分层抽取的 10% 样本上，对照盲法人类专家标签加以核验（附录 E）。该审计估计生成标签与人类专家判断在抽样转移上的一致性；它并不替换全数据集中的每一个生成标签。图 4 说明图对齐如何定位偏离、恢复和循环事件，并把它们连接到对应的过程指标。

图 4：任务专属 UTG 上的轨迹诊断示例。（a）第 2–3 步离开任务子图，第 4 步恢复，提供用于计算 DR、ARL、RA 和 RSR 的标签。（b）同一局部状态对之间的重复转移形成一个循环事件，并决定 LBR。虚线边表示可行但未执行的任务子图转移；为清晰起见省略停滞。

3.4 评测指标

#### 任务评测指标。

在任务层，我们报告任务成功和图对齐的执行质量。（1）SR 衡量在逐轨迹评测摘要中被标为成功的轨迹比例；这些标签在全部报告的分析中予以保留。（2）CR 衡量任务所要求的子图已完成多少，在最终任务失败时提供更细的进展视图。（3）偏离率（DR）衡量智能体多么经常移动到任务子图之外，捕捉路径不稳定。（4）循环负担率（LBR）衡量一旦发生循环，有多少执行被重复的无进展行为消耗。（5）恢复成功率（RSR）衡量智能体在偏离后能否回到任务子图。（6）平均恢复时延（ARL）衡量成功恢复需要多少步。（7）恢复能力（RA）把恢复成功和恢复速度合成一个稳健性分数。详细计算规则见附录 B。

4 实验

我们的实验处理三个问题：GUI 智能体如何失败？任务结果是否充分刻画执行稳定性？最后，稳定性指标是否捕捉到跨任务可复现的智能体差异？设置之后，每一小节用按结果分层的统计、结果受控的比较，或跨任务复现，回答其中一个问题。表 2 概括跨智能体、指令条件和稳定性指标的主要实验结果。

4.1 实验设置

#### 基线智能体。

我们评测有代表性的仅截图 GUI 智能体，包括 GUI 专用模型，以及来自 DeepSeek、Gemini、GPT、Qwen 和 GLM 系列的通用模型，并在可用时使用每个模型的官方提示和工具调用设置。每个模型都在由子图导出的详细指令和简洁的用户级目标下测试，温度设为 0，最大预算为 15 个动作。表 2 包含来自 11 个已完成模型、两种指令条件和 169 项任务的 3,718 条轨迹。所有轨迹级分析都使用这套完整的十一模型数据集；成对的指令分析包含 1,859 个模型—任务对。两个 GUI 专用模型使用 8-bit MLX 检查点（Apple，2026），并在另一台主机上采集；它们的评测记录被纳入每一项适用分析。除 SR 和 CR 外，我们报告 DR、LBR、RSR、ARL 和 RA，以评测 GUI 智能体的执行稳定性；详细定义和汇总规则见附录 B。

表 2：全部 3,718 条轨迹的结果：11 个模型、169 项任务和两种指令条件。所有行都使用所提供的逐轨迹评测摘要，保留所报告的 SR 标签和过程分数。数据来源详见附录 C。比率为小数；ARL 以步计。在每个指令块内，最佳值加粗，次佳值加下划线。

译注：原文表格用排版标记最佳与次佳。下表保留全部数值，不另加粗或下划线，以免 Markdown 改变单元格。表中每一格都是该模型在该指令条件下的原始指标，列序固定为成功率、完成率、偏离率、循环负担率、恢复能力、恢复成功率和以步计的平均恢复时延。详细指令块先列两个图形界面专用模型，再列五个通用开源模型，最后列四个专有模型；简洁指令块以同样的类型顺序和同样的十一行重复一遍，数值不合并、不四舍五入。两个指令块都保留所提供摘要里的成功率标签和过程分数。比率以小数记录，平均恢复时延以步记录，最佳与次佳只存在于原文排版，不改任何小数。阅读时先看详细指令，再看简洁指令，同行模型一一对应，两块之间不要跨行比较数值。

4.2 GUI 智能体因不稳定执行而失败

#### 失败把不完整进展与不稳定执行结合在一起。

表 2 表明，GPT-5.6 Sol 和 GLM-5.3-Flash 是总体上最强的智能体：GPT-5.6 Sol 在两种指令设定下都取得最高 SR（0.6391），而 GLM-5.3-Flash 在两种设定下都取得最低 DR（详细指令 0.0743，简洁指令 0.1303），并取得最高的简洁指令 CR（0.6676）。然而强结果并不意味着执行一律稳定。即便 GPT-5.6 Sol，在两种指令设定下，于其观察到的恢复机会上所报告的 RA 也最低，表明高最终成功可以与犯错后的弱恢复并存。其他智能体暴露出不同的失败画像：UI-TARS-1.5-7B 以偏离为主（详细指令 DR 0.5149，简洁指令 0.5088），而 Qwen3.8-27B 表现出尤其高的循环负担（详细指令 LBR 0.7412，简洁指令 0.7532）。

#### 失败的执行在整条轨迹上都不那么稳定。

在全部 3,718 条轨迹上，失败具有更高的 DR（详细指令 0.3067 对 0.0889；简洁指令 0.3618 对 0.1412）、更高的循环发生率（0.6525 对 0.2066；0.6520 对 0.2748）、循环开始后更高的 LBR（0.6390 对 0.4257；0.6142 对 0.4840），以及更低的 RA（0.5668 对 0.7285；0.5918 对 0.6394）。因此任务失败与持续的路径外行为和重复的无进展行为密切相关；完整的按结果分层比较见附录表 4。

图 5：任务结果掩盖执行不稳定。（a）成功轨迹中互斥的过程模式比例。（b）精确 CR 匹配、且过程差距至少为 0.2000 的配对；柱区分成功配对与失败配对，须线表示任务聚类的 95% 区间。

4.3 稳定性指标揭示任务结果之外的差异

#### 成功结果中仍然包含不稳定执行。

虽然失败轨迹平均更不稳定，不稳定并不限于不成功的运行。在 1,294 条成功轨迹中，51.24%（663/1,294）至少包含一次偏离或循环。在详细指令下，36.78% 的成功轨迹包含偏离，20.66% 包含循环；在简洁指令下，对应比率上升到 46.11% 和 27.48%。图 5（a）在这些成功轨迹内部区分仅偏离、仅循环和组合模式。此外，126 条成功轨迹的 DR 为零，但仍包含循环，说明即便沿路径执行，也可能因重复的无进展行为浪费动作。这些结果表明，成功结果仍可能掩盖偏离和循环，因此仅凭最终成功并不能确立稳定的任务执行；偏离后及时恢复与结果的相关性在附录 C.4 中另行考察。

#### 等价的任务表现掩盖巨大的稳定性差异。

成功只是结果等价最粗糙的形式。因此我们比较在相同指令条件下执行同一任务、且 SR 相同、所存储 CR 相等的模型。在合格的成功配对中，DR、LBR 和 RA 相差至少 0.2000 的比例分别为 0.2305、0.4158 和 0.5331。图 5（b）表明，这些大的过程差距也出现在失败配对中：在精确 CR 匹配的失败配对里，RA 相差至少 0.2000 的比例为 0.5956。匹配敏感性以及部分重叠的指标相关，为这一区分提供了额外支持（附录图 8）。因此，即便匹配后的任务结果，也不足以决定执行不稳定的程度和形式。

4.4 稳定性指标捕捉一致的智能体差异

#### 模型行为画像在任务之间保持。

我们检验过程指标是否捕捉可复现的模型行为：把 169 项任务反复分成分层的两半，在每一半上按每个指标对全部 11 个模型排序，并用 Spearman \(\rho\) 衡量排序一致性。最强的一致性出现在 DR 和 LBR 上：详细指令排序达到 \(\rho=0.9516\) 和 \(0.9284\)，简洁指令排序仍高达 \(\rho=0.9228\) 和 \(0.8381\)。RSR 在划分之间也稳定（详细指令 \(\rho=0.8100\)；简洁指令 \(0.8269\)），而 ARL 较弱（\(\rho\approx 0.58\)），RA 则取决于条件。全部指标—条件相关在 Bonferroni 校正后仍然显著（\(p<0.05\)）；完整表格和置换细节见附录表 9。

5 结论

我们提出了 GraceBench。它把视频记录的轨迹与任务专属界面转移图对齐，以诊断真实移动执行中的偏离、循环和恢复。在 11 个模型和 3,718 条轨迹上，GraceBench 揭示了被 SR 和 CR 隐藏的执行弱点：表现较低的智能体更常偏离和循环，而即使 SR 最高的模型，在观察到的恢复机会上恢复也有限。成功轨迹，以及 SR 和 CR 相同的轨迹，在 DR、LBR 和 RA 上仍可能相差很大，说明可靠的 GUI 自动化所需要的不只是任务完成。通过提供图对齐证据和过程级诊断，GraceBench 支持今后在更强的状态跟踪、循环检测和恢复策略上研究 GUI 智能体。

人工智能使用声明

在本工作中，我们使用生成式人工智能工具协助基准构造，包括起草候选任务指令、扩展参数化任务变体，以及为 GUI 轨迹诊断生成辅助转移标注。所有人工智能协助的输出都被当作候选产物，而不是真值。作者人工复核了所保留的 UTG、任务定义、任务指令和截图，以确保状态有效、转移可执行、任务可行，并与基准协议一致。对于步骤级诊断标签，并不假定专家智能体的输出已被完全人工标注；相反，我们进行了预注册的分层审计，把抽样的转移标签对照盲法人类专家判断加以核验，如附录 E 所述。所报告的定量结果由有文档的评测记录和指标定义计算得出，生成式人工智能工具未被用于在未经作者核验的情况下作出最终科学论断。作者对本工作的最终内容负全部责任，包括在生成式人工智能协助下产生的文本、论断、数据和产物。

伦理声明

GraceBench 旨在受控移动环境中诊断 GUI 智能体的执行稳定性。该基准不涉及人类受试者实验。因为 GUI 智能体可能与真实应用交互，我们把任务约束为避免不可逆或高风险操作，例如支付、提交订单、购买、账户变更或授权变更。在 UTG 构造和评测期间，这类操作被当作边界状态，并不执行。截图、视频和轨迹从受控设备和基准账户采集，发布的产物将在必要时复核，以移除或匿名化敏感信息。该基准用于可靠性诊断和面向安全的分析，而不是用于促成有害自动化。

可复现性声明

为支持可复现性，我们将发布基准任务定义、指令变体、UTG 元数据、评测代码、指标定义，以及轨迹与评测的模式；详细的指标计算规则见附录。对每次评测运行，GraceBench 存储动作轨迹、动作前和动作后截图、动作元数据、计时信息，以及同步的视频证据，并记录评测环境，以便尽管移动应用、应用版本、账户、设备和在线内容会变化，轨迹判断仍可被审计。当前分析包包含全部 11 个模型的逐轨迹评测记录；两个 GUI 专用模型在另一台主机上采集，其视频和截图文件不包含在该包中。

译注：参考文献与附录 A 至附录 E 见续篇 gracebench-execution-stability-rest-zh。