← 返回 2026-05-05

WindowsWorld：面向专业跨应用环境的、以流程为中心的自主 GUI 智能体基准 WindowsWorld: A Process-Centric Benchmark of Autonomous GUI Agents in Professional Cross-Application Environments

Jinchao Li, Yunxin Li, Chenrui Zhao, Zhenran Xu, Baotian Hu, Min Zhang 📅 2026-04-30 👍 15 2026-07-13 08:36
Benchmark Computer-Use Cross-Application GUI Agent Process Evaluation Windows
arXiv HuggingFace PDF

首个面向 Windows 跨应用专业工作流的、以流程中间态检查为核心的 GUI 智能体基准，揭示当前最强模型在多应用协同任务上仅约 20% 成功率。

前置知识

GUI Agent / Computer-Use Agent (CUA)

GUI 智能体是一类通过直接操控图形用户界面（点击、键入、拖拽）来执行数字任务的大模型系统。与传统 API Agent 不同，CUA 仅依赖屏幕截图或辅助树作为观察，通过'看到屏幕 → 推理 → 输出动作 → 接收新截图'的循环完成跨应用任务。OSWorld、Agent-S3、UI-TARS 都属于这一范式。

本文正是评估当前最强 GUI 智能体在真实工作流中的能力上限，所有指标都围绕 GUI 动作的轨迹展开，不理解 POMDP 形式的轨迹 τ=(o1,a1,...,oT,aT) 就读不懂本文的奖励函数设计与检查点机制。

Partially Observable Markov Decision Process (POMDP)

POMDP 用元组 (S,O,A,T,R) 描述决策过程，其中 S 是真实状态空间、O 是部分观察空间、A 是动作空间、T 是状态转移函数、R 是奖励函数。在 GUI 任务里，智能体无法直接看到系统底层状态，只能从截图中推断，因此天然是一个 POMDP。

论文 §3.1 显式把 GUI 交互形式化为 POMDP，并据此定义奖励 R:S×A→[0,1]，提出 Sint（中间检查点分）和 Sfinal（终态分）两个互补指标。理解 POMDP 是看懂评测设计的前提。

多应用协同工作流 (Cross-Application Workflow)

指一个真实办公任务需要跨越多个软件（如 Excel→Outlook→Chrome）才能完成，数据或操作需要在应用边界之间迁移、转换和同步。典型例子：'把 Excel 里的销售数据算增长率，写到 Word 报告，再邮件发给老板'。

本文的核心论点是：现有基准几乎都聚焦单应用任务，而真实工作流 78% 以上是多应用的；这正是 GUI 智能体在工业场景落地的最大鸿沟，也是 WindowsWorld 想要填补的关键空白。

可执行基准 (Execution-Based Benchmark) 与 VM 评测

不同于离线轨迹预测，可执行基准在真实的虚拟机或容器里运行智能体动作，通过最终状态匹配来判定任务成败。OSWorld、Windows Agent Arena 都基于 Virtual Machine 镜像做端到端评测。

WindowsWorld 沿用并扩展 OSWorld 的 VM 基础设施，确保动作是真实 GUI 操作而非模拟，从而避免'刷榜式'轨迹预测。理解 VM 评测范式才能体会其评测结果的可靠性。

Process-aware / 流程感知评估

传统成功率 (SR) 是二元 'all-or-nothing' 判分，掩盖了智能体到底在哪一步失败。流程感知评估则额外定义若干中间检查点 C={ck}，通过 Sint=(1/|C|)Σk J(τ,ck) 给出部分进度分，从而分辨'完全失败'与'差一点点就成功'。

本文最核心的方法贡献就是这个评分协议，平均每任务 4.97 个检查点，所有实验结果都是围绕它展开的；不懂 Sint/Sfinal 双指标，就无法解释 Figure 5(a) 中 L3 任务的散点图分布。

研究动机

现有 GUI 智能体基准存在三大明显短板。首先是跨应用覆盖严重不足：OSWorld、Windows Agent Arena 中跨应用任务占比仅 27.4% 和 26.8%，AndroidWorld、ProBench 更是低于 12%；而现实办公场景里从 Excel 拷数据到 Word、再用 Thunderbird 发邮件这类跨应用流水线占比远超 70%。Figure 1(a) 显示多应用任务在主流基准中均不足 28%，与之形成鲜明对比的是真实工作中'打开 2-3 个应用协同'才是常态。Figure 1(b) 进一步证明，智能体一旦需要协调 2 个以上应用，成功率会从单应用的 50–90% 暴跌到 21% 以下。其次是评估粒度过粗：传统 SR 把'走完全流程把文件存好'与'第一步就卡死'都判为 0 分，无法分辨有意义的中间进展。第三是构建成本高且生态失真：OSWorld 这类基准依赖论坛爬取加大量人工编辑，难以扩展；同时它们不会自动合成评测所需的多格式文件依赖 (.xlsx、.docx、.py 等)，导致模拟环境与真实生产环境差距明显。

本文的目标是本文旨在打造一个面向 Windows 桌面、聚焦跨应用专业工作流的'流程感知'评测基准 WindowsWorld，包含 181 个任务、覆盖 17 个常用桌面应用、横跨 16 个专业角色，按 L1–L4 四级难度递进；其中 L4 是'故意不可行'任务，专门考察智能体的自我放弃能力。同时提供一种'人机协作的多智能体自动生成管线'，把每个任务的平均构建成本压到工业可用水平。

与已有工作不同的是，与 OSWorld 注重单应用广度、Windows Agent Arena 注重吞吐量、ProBench 仅做流程信息收集不同，WindowsWorld 的独特切入角度是：(1) 首次把 78% 的任务设计为多应用流水线，强制评估应用切换与状态同步能力；(2) 把'检查点密度'本身作为难度信号 (L3 任务平均 6 个以上检查点 vs L1 仅 2-3 个)，把'全局终态正确'拆解为'若干语义节点的局部正确'；(3) 设计专门的 L4 infeasible 任务，检验模型是否能识别并报告'该任务做不了'，而不是硬着头皮编造结果；(4) 通过 Persona 驱动的多智能体框架，把任务生成从纯人工模板替换升级为'角色 × 工作流 × 应用依赖'的结构化合成。

核心方法

WindowsWorld 的方法由两大部分组成：任务构建管线与流程感知评测协议。构建侧采用'人机协作多智能体'，包含 Generator (基于 DeepSeek-V3.2 + Web Search，依据 16 个 Persona 草拟任务)、Refiner (由 4 个节点组成 — 语义去重、URL 可达性审计、依赖推理器把'打开文件'翻译成'文件存在'这类可验证声明、指标精炼器把动作描述抽象为语义断言)、Human Reviewer (4 名研究生按 1.5 USD/任务剔除歧义与主观任务)，以及 Environment Generator (基于 Persona 跨任务共享，自动合成 Excel/Word/JSON 等依赖文件，并采用 Smart File Merging 策略保证数据一致性)。评测侧把任务形式化为 POMDP，提出 Sint 和 Sfinal 双指标，由 Qwen3-VL-Plus 作为 VLM Judge 对每条轨迹的每个检查点做二元判定；评测在受控 Windows VM 中执行，智能体只通过标准 GUI 操作 (PyAutoGUI 或 computer_13 动作空间) 交互，不允许调用内部 API。

核心创新是'Persona-conditioned Process-Centric 任务 + 检查点容忍路径的评分协议'。与已有基准的本质区别有三层：第一，任务不是从论坛爬来的开放指令，而是由 16 个职业角色 (会计、项目经理、设计师、HR、客服、开发者等) 驱动的、明确应用依赖与文件前置条件的工程化产物；任务分级 L1–L4 显式建模了认知-操作复杂度梯度，而非随机分布。第二，评估不再只看终态是否匹配，而是把每条任务拆成平均 4.97 个路径必要 (path-essential) 但非轨迹特定 (trajectory-specific) 的语义检查点；这样既能避免'必须点击特定按钮'的僵化，又能捕捉'是否走到关键节点'，使 Sint 在所有 Sfinal≈0 的难任务里仍保持 2–40% 的区分度。第三，构建管线把'角色 × 应用 × 工作流'作为可组合的生成模板，让 LLM 主导语义、人工主导质检，环境文件自动合成，整体成本远低于 OSWorld 的人海战术。

方法步骤详情

完整的方法流程包含以下步骤：(1) Persona 定义：手工定义 16 个角色，分布在 5 个大类 (Administrative/Support、Business/Management、Creative/Content、Technical/IT、General User)，每个角色绑定主用 + 次用应用集以及典型工作流；(2) 任务生成：把 Persona 配置填入 Generator 提示词，由 DeepSeek-V3.2 在允许白名单 (GitHub、Wikipedia、Stack Overflow 等开放平台) 内搜索真实资源，结合 Web Search 输出 L1–L4 任一难度的任务 JSON，包含中英双指令、应用清单、前置条件、评估指标和检查点列表；(3) 四节点精炼：Semantic Deduplicator 计算任务嵌入两两余弦相似度，去掉阈值 τ=0.85 以上的近重复；Validity Auditor 用异步 HTTP 请求核验 URL，并交叉检查指令中提到的文件名是否与定义的环境配置一致；Dependency Reasoner 用 LLM 把'打开 Excel'这类动作型前置条件翻译成'Excel 进程已启动'这类状态型描述；Metric Refiner 删除'点击按钮 X'这类动作特定约束，仅保留语义终态断言；(4) 人工复核：4 名研究生以 1.5 USD/任务的费率筛掉三类问题 — 指令歧义、主观评判、依赖商业软件或不可访问外部服务；(5) 环境生成：对每个通过的任务，Environment Generator 读取 environment_setup 字段，使用 LLM 合成所需的 .xlsx/.docx/.py/.json 文件内容，并通过 Smart File Merging 把同一 Persona 下多个任务共享的数据资源合并，保证一致性；(6) 部署到 Windows VM：每个任务单独实例化到 VM 中执行，智能体接收初始截图 o1，按动作空间 (PyAutoGUI 13 类动作或 computer_13 动作) 输出 at，直到输出 DONE/FAIL 或超过最大步数 (L1=15、L2=25、L3=40、L4=20)；(7) VLM Judge 打分：Qwen3-VL-Plus 读取完整轨迹 τ=(o1,a1,...,oT,aT)，对每个检查点 ck 输出 J(τ,ck)∈{0,1}，按公式 Sint=(1/|C|)Σk J(τ,ck) 和 Sfinal=J(τ,sT) 聚合为最终分。

技术新颖性

从技术新颖性看，本文有三处明显贡献：第一，把'任务难度'从连续变量升级为'检查点密度 + 应用切换次数 + 跨应用结构依赖'的三维组合，并用 L1–L4 显式建模认知复杂度梯度，这在以往基准里只以单维度 (步数) 刻画；第二，构建管线首次把 Persona 这一'软约束'与 Hard Refiner 的'硬过滤'拼装起来，把 LLM 自由生成的不稳定性用 4 节点流水线 + 人工兜底压住，使得自动生成的 181 个任务在 L1–L4 分布上接近手工基准的质量；第三，'路径必要而非轨迹特定'的检查点设计是一处巧妙取舍，既允许智能体通过快捷键、右键菜单、剪贴板等多种合法路径完成任务，又能在关键节点失败时给出非零的 Sint，是一种对 GUI 动作空间异构性的工程化处理。

(Left) Distribution of applications across different categories and their respective task counts. (Right) 16 Personas in WindowsWorld are categorized in 5 major domains, each with fine-grained personal roles.
Figure 2: (Left) Distribution of applications across different categories and their respective task counts. (Right) 16 Personas in WindowsWorld are categorized in 5 major domains, each with fine-grained personal roles.
The overall architecture of the human-in-the-loop multi-agent pipeline.
Figure 3: The overall architecture of the human-in-the-loop multi-agent pipeline.
Benchmark analysis of WindowsWorld. (a) Distribution of tasks across difficulty levels (L1-L4), highlighting the prevalence of non-trivial multi-step workflows. (b) Distribution of the number of applications per task. (c) Cross-application interaction network, with edge weights representing co-occurrence frequency. (d) Distribution of task checkpoints by difficulty (L1-L3), showing increased checkpoint density for complex tasks.
Figure 4: Benchmark analysis of WindowsWorld. (a) Distribution of tasks across difficulty levels (L1-L4), highlighting the prevalence of non-trivial multi-step workflows. (b) Distribution of the number of applications per task. (c) Cross-application interaction network, with edge weights representing co-occurrence frequency. (d) Distribution of task checkpoints by difficulty (L1-L3), showing increased checkpoint density for complex tasks.

实验结果

实验在 5 个通用多模态大模型 (Gemini-3-pro/flash-preview、GPT-5.2、Claude-Sonnet 4.5、Qwen3-VL-Plus) 与 2 个 GUI 专业框架 (UiPath、Agent-S3) 上展开，每个模型分别在 3 种观察模态 (Raw Screenshot、Set-of-Marks、Screenshot+A11y Tree) 下测试。Table 2 是核心结果，三大发现如下。(1) 效率–完成率鸿沟：Gemini-3-flash 在 Hybrid 设置下 Sint=50.32% 看似尚可，但 Sfinal 仅 20.44%，意味着智能体走了将近一半关键节点后无法'收尾'。所有模型都表现出'局部合理、全局跑偏'的 inefficient drift。(2) 复杂度瓶颈：从 L1 到 L3，Sfinal 急剧下滑 — Gemini-3-flash 从 35.90% 跌至 16.67%，Gemini-3-pro 从 41.94% 跌至 9.68%，GPT-5.2 在所有模态下几乎全程接近 0%，说明当前 SOTA 在 ≥3 个应用协同任务上几乎无能力。(3) 失败感知缺失 (L4)：最能识别'任务不可行'的 GPT-5.2 (SoM) 也只有 25% 的 L4 成功率，UiPath 表现出 50% 的高分只是因为它'倾向于报告失败'这种保守策略，并不代表真正理解任务不可行。Figure 5(a) 显示在 L3 上 Sfinal 普遍 <15% 但 Sint 跨度从 2.04% 到 38.63%，证明流程感知指标确有诊断价值。Table 3(a) 显示 Qwen3-VL-Plus 推理最快 (≈6 s/step) 而 Gemini-3-pro+SoM 最慢 (43.69 s/step)，失败–成功步数差 Δ 在 Hybrid 下从 L1 的 4.64 暴涨到 L3 的 14.14，说明复杂任务的失败发生在长尾的中后段。Table 3(b) 还揭示了英语指令在多步执行中比中文更稳定，跨语种仍有 2-6 个百分点的隐性偏差。Table 4 的检查点级错误分布显示，约 30% 的多应用任务在 c1/c2 就首次失败，主要原因是应用切换和中文 IME 输入。Table 8 进一步按 Persona 拆解，发现 Technical/IT 角色 Sint 与 Sfinal 差距最小，而 Administrative/Support、Creative/Content 角色差距最大，表明文档/视觉密集型任务的失败源于'终态一致性维护'而非'初期执行'。

Comparison of execution-based benchmarks. Multi-app indicates tasks with two or more applications; Intermediate Checks indicates tasks with intermediate-state checkpoints rather than result-only end-state evaluation.
Table 1: Comparison of execution-based benchmarks. Multi-app indicates tasks with two or more applications; Intermediate Checks indicates tasks with intermediate-state checkpoints rather than result-only end-state evaluation.
Model and Agents Performance on WindowsWorld. All large models use a unified PyAutoGUI action space, while UiPath employs the Computer_13 action space from OSWorld.
Table 2: Model and Agents Performance on WindowsWorld. All large models use a unified PyAutoGUI action space, while UiPath employs the Computer_13 action space from OSWorld.
Ablation studies on efficiency and instruction language.
Table 3: Ablation studies on efficiency and instruction language.
Action space in WindowsWorld. Actions are grouped into mouse control, keyboard input, and system-level control signals.
Table 5: Action space in WindowsWorld. Actions are grouped into mouse control, keyboard input, and system-level control signals.
Task instances across difficulty levels (L1-L4).
Table 6: Task instances across difficulty levels (L1-L4).
Human validation of the VLM judge on 100 stratified tasks (518 checkpoints).
Table 7: Human validation of the VLM judge on 100 stratified tasks (518 checkpoints).
Main results on WindowsWorld cross input modalities and agent frameworks. Reported by persona category.
Table 8: Main results on WindowsWorld cross input modalities and agent frameworks. Reported by persona category.
Detailed analysis of intermediate checks and persona-dependent difficulty. (a) Scatter plot of intermediate checkpoint score (Sint) versus final task completion score (Sfinal) on L3 tasks under the Screenshot + Accessibility setting. (b) Model performance across different professional tasks.
Figure 5: Detailed analysis of intermediate checks and persona-dependent difficulty. (a) Scatter plot of intermediate checkpoint score (Sint) versus final task completion score (Sfinal) on L3 tasks under the Screenshot + Accessibility setting. (b) Model performance across different professional tasks.
查看结构化数据
任务指标本文基线提升
L1 (Single-App Atomic) — 单应用原子操作 Sfinal Gemini-3-flash (Hybrid) 35.90%；Gemini-3-pro (Hybrid) 41.94% GPT-5.2 (Hybrid) 5.13%；Claude-Sonnet 4.5 (Hybrid) 0.00% Gemini-3-flash 相对 GPT-5.2 在单应用任务上取得约 30 个百分点的绝对提升。
L2 (Multi-App Linear) — 多应用线性工作流 Sfinal Gemini-3-flash (Hybrid) 17.50%；S3 w/ Gemini-3-flash 16.25% Claude-Sonnet 4.5 (Hybrid) 0.00%；GPT-5.2 (Hybrid) 0.00% Gemini-3-flash 在双应用任务上仅 17.5%，相对 L1 几乎腰斩；S3 框架加持下 Gemini 反而没明显增益。
L3 (Dynamic Reasoning) — 动态条件推理 Sfinal Gemini-3-flash (Hybrid) 14.00%；S3 w/ Gemini-3-flash 10.00% GPT-5.2 (Hybrid) 0.00%；Claude-Sonnet 4.5 (Hybrid) 0.00% 最强模型在 L3 上仅 14%，反映 ≥3 应用条件推理仍是巨大挑战；S3 框架在此层级反而拖累 Gemini-3-flash (10% vs 14%)。
L4 (Infeasible) — 不可行任务识别 Sfinal (识别失败) UiPath w/ Gemini-3-flash 50%；GPT-5.2 (SoM) 25% Gemini-3-flash (Hybrid) 16.67%；Gemini-3-pro (Hybrid) 0% UiPath 表现最佳，但部分原因是其工程上倾向于报错；GPT-5.2 在 SoM 下取得 25% 反映 SoM 视觉辅助偶有助益。
All Levels — 流程感知中间进度 Sint (avg) Gemini-3-flash (Hybrid) 50.32%；Gemini-3-pro (Hybrid) 38.80%；S3 w/ Gemini-3-flash 42.42% Claude-Sonnet 4.5 (Hybrid) 5.84%；GPT-5.2 (Hybrid) 6.62% Sint 指标揭示出 Claude/GPT 在多步任务里仍能完成部分子目标，仅以 Sfinal 无法体现此差距。

局限与改进

作者在论文 'Limitations' 一节坦承三点。其一是中间分依赖完整轨迹执行 + 人工审核的检查点，难以直接用于大规模在线 RL 训练，自动化、泛化的奖励建模仍是开放问题。其二是评测环境仅优化了英语 UI，缺乏对中文/其他语种 OS 环境的真实跨语种测试；Table 3(b) 显示即使是 Gemini-3-flash，中英文 Sfinal 在 L3 上分别为 8.00% 和 14.29%，跨语种鸿沟明显。其三是尚未纳入 MCP (Model Context Protocol) 工具评测，未覆盖'GUI 操作 + API 调用'混合范式。我自己的额外观察是：(1) 样本量偏小，181 个任务 × 16 个 Persona 意味着每角色平均仅 11 个任务，难以支撑按角色的细粒度统计显著性；(2) VLM Judge 与人类的一致性虽强 (Pearson 0.91、Cohen's κ 0.87)，但 Appendix C.1 指出仍存在'窗口遮挡导致的假阳性'与'最小化后画面缺失导致的假阴性'，对动态窗口变化敏感；(3) 评测的 5 个模型和 2 个框架里没有开源的 GUI-Specific 7B/8B 模型 (如 UI-TARS-2、Aguvis)，结论是否对'模型规模 + GUI 专项微调'敏感还需进一步验证。

独立分析的弱点

独立分析可看出四处明显弱点。第一，'过程完整性 ≠ 任务完成'的 Δ 鸿沟最严重，Gemini-3-flash 在 L3 上 Sint=38.63% 而 Sfinal=14.00%，提示智能体缺乏'进度停滞时的自我终止机制'；改进方向是引入显式的早停或回溯策略，或在动作空间里加入 'VERIFY_STATE' 元动作。第二，跨应用窗口焦点管理是高频失败源 (Figure 12)，智能体在切换应用后未确认当前活动窗口就直接执行剪贴板/输入动作；改进方向是要求每次跨应用操作前先 'Alt+Tab' 或读取活动窗口标题，并把这写进检查点。第三，混合语种场景 (中文文件 + 英文界面) 下 PyAutoGUI 与 IME 冲突导致输入截断 (Figure 11)，智能体缺乏对 IME 弹窗的感知；改进方向是增加 'IME 状态检测' 动作或允许智能体通过剪贴板绕开 IME。第四，'长尾 Persona 难度'被聚合指标掩盖，Administrative/Support 与 Creative/Content 角色的 Sint-Sfinal 差距远大于 Technical/IT，提示需要在 Persona 维度单独报告性能，或引入 Persona-aware 的任务抽样。

未来方向

作者明确提出了三个未来方向：(1) 把基于完整轨迹的 Sint 抽象成可在线计算的 dense reward，便于在长视野 RL 训练中直接使用；(2) 扩展到非英语 OS 镜像，构建真正的跨语种桌面评测；(3) 把 MCP 工具调用纳入评测，考察 GUI + API 混合范式。基于本文的成果还可以延伸出几条值得探索的方向：(a) 把'Persona'从评测维度升级为'模型身份维度'，让同一智能体在不同 Persona prompt 下测试其角色扮演能力；(b) 把流程检查点做成可交互的'最小可验证子任务集'，支持增量训练与 curriculum learning；(c) 引入'人类示范轨迹'作为参考，定义 'Trajectory-Distance' 指标，衡量智能体走了多少'冤枉路'；(d) 探索专门的跨应用协调模块，例如显式的 Application Context Manager，让智能体在切换应用前先 commit 上一应用的状态。

复现评估

作者在 'Ethical Considerations and Reproducibility' 一节承诺完全开源 (仓库 github.com/HITsz-TMG/WindowsWorld)，含评测环境、181 条任务指令、流程感知评测脚本。数据由 4 名研究生以 1.5 USD/任务的市场价标注，指令经 LLM 辅助生成 + 人工审核，不含 PII 或有害内容。任务构建依赖 DeepSeek-V3.2 作为 Generator，因此完整复现需要 (i) DeepSeek-V3.2 API 调用权限或同等开源替代 (如 Qwen3-235B)，(ii) Web Search 接口 (用于 URL 核验)，(iii) Windows 10/11 VM 镜像 (≥32 GB RAM、SSD)，(iv) 至少一张消费级 GPU 用于 VLM Judge 推理 (Qwen3-VL-Plus 在 RTX 4090 上约 6 s/step，评测 181 任务 × 4 模型 × 3 模态共约 200+ GPU 小时)。整体复现难度中等偏上 — 任务与评测脚本可一键运行，但完整跑表 2 需要按 7 模型 × 3 模态 = 21 个组合 × 181 任务大量 VM 时间，对个人研究者门槛较高；建议优先复现关键发现 (Gemini-3-flash 的 L1/L2/L3 性能曲线、Sint vs Sfinal 差距、L4 失败感知)，其余作为参考。

论文图表

Limitations of current GUI benchmarks in real-world tasks. (a) Distribution of single/cross-application tasks across benchmarks. (b) The task success rate drops with the increase in applications.
Figure 1: Limitations of current GUI benchmarks in real-world tasks. (a) Distribution of single/cross-application tasks across benchmarks. (b) The task success rate drops with the increase in applications.

左图比较了 AndroidWorld、OSWorld、WindowsWorld 三个基准中单应用任务与跨应用任务的占比，OSWorld 多应用仅 13.74%、AndroidWorld 6.57%，而 WindowsWorld 多应用占 72.6%。右图用柱状图展示 GPT-4V、GTA1 w/ GPT 5、Agent-S3 w/ GPT 5、UI-TARS-2 在单应用/多应用设置下的成功率，多应用上从单应用的 50–90% 跌到 21–34%。

这是论文的核心动机图：用 1 张图同时说明'基准覆盖不够'与'模型在跨应用上掉链子'，让读者一眼看到要补的空白在哪里。

Table 4: Checkpoint-wise First-Failure Distribution on WindowsWorld (Screenshot-only). The percentage of trajectories failing first at each checkpoint ck, evaluated on feasible multi-app tasks (L2-L3).

10 个检查点 (c1–c10) 上的首次失败分布。Gemini-3-pro 在 c1 失败率 39.2%，c2 22.4%，到 c6 累计已 96% 以上；Gemini-3-flash 在 c1 23.1%、c2 26.2%；Agent-S3 w/ Gemini-3-flash c1 33.8%、c2 32.3%。

揭示失败的位置分布：绝大多数多应用任务在 c1/c2 (早期) 就失败，说明'应用切换'是首要瓶颈；这是后续设计与诊断的重要数据。