DeskForge: Dense Supervision From Desktop Environments for Computer-Use Agents
DeskForge: Dense Supervision From Desktop Environments for Computer-Use Agents
发表时间: 2026-10 · arXiv:2610.02320 (ETH Zurich / IBM Research / Microsoft)
原文: https://arxiv.org/abs/2610.02320
A. Said Gurbuz, Ahmed Nassar, Sunghwan Hong, Marc Pollefeys, Peter W. J. Staar
ETH Zurich, IBM Research Zurich, Microsoft
速读
一句话结论 本文提出可控桌面环境 DeskForge,通过组合真实应用生成包含 120 万观测值的密集标注数据集 DeskForge-1M,微调后全面提升了模型在多窗口遮挡场景下的 GUI 定位准确率与长周期任务完成度。
要解决什么问题 现有智能体在复杂的桌面场景中难以准确进行动作定位。真实桌面具有高度组合性,多窗口、对话框和系统控件并存,目标极易与视觉相似元素或跨应用干扰项混淆。原有数据收集卡在两个极端:静态截图语料库无法主动改变场景配置、调整窗口布局或产生交互,且大多只标注孤立应用;而可执行的交互式环境(如 WebArena)主要用于任务评估,无法提供屏幕元素的密集标注。这种卡点导致模型在面对多窗口重叠、部分遮挡的真实桌面时,缺乏高质量监督信号来区分目标与干扰项,进而在长周期任务中因一步点击错误而崩溃。
怎么做的 核心思路是“生成”桌面场景而非单纯“记录”。作者构建了基于 Linux 的可控桌面环境 DeskForge,由场景配置、密集标注流水线和交互记录三个部件构成。首先,场景配置模块在隔离会话中启动真实应用,系统性控制内容、窗口布局、层叠顺序、视觉主题和分辨率,主动制造多应用并存和遮挡等困难场景。其次,密集标注流水线负责解析屏幕,它不单纯依赖不完整的无障碍 API,而是融合无障碍树、截图和窗口几何信息。为处理多窗口重叠,流水线会计算元素可见几何形状,裁剪被遮挡部分。对于保留了原始边界框 $B_e$ 的元素,其可见区域 $V_e$ 的可见性损失定义为 $\rho_e = 1 - \frac{\mathrm{area}(V_e)}{\mathrm{area}(B_e)}$,确保模型学习真实的可见点击区域。同时系统生成 ScreenTag,这是一种保留元素层级的紧凑标记语言。最后,交互记录模块在估计的可见区域内执行点击,记录动作前后的观测值与状态变化。基于此,系统利用 Qwen3.6-27B 根据前后截图和上下文,反向合成自然语言指令。由此构建的 DeskForge-1M 包含 120 万个密集标注观测值和 91.7 万次点击记录。
效果如何 实验在 20 万条 DeskForge-1M 单目标定位数据上微调了 Qwen3.5-4B、Gemma4-E4B、InternVL3.5-8B 和专为 GUI 优化的 UI-R1-3B,使用 8 张 NVIDIA H100 显卡。对比基线包括这四个模型的未微调版本,以及代表原生智能体路线的 UI-TARS-1.5-7B、代表合成经验路线的 EvoCUA-8B、代表强视觉语言模型的 UI-Venus-2-9B 等十个公开基线。结果显示,微调后的四个模型在包含未见场景、应用、主题和分辨率的保留测试集中全面提升,Qwen3.5-4B 平均准确率从 76.26% 升至 87.54%,在应用增多和遮挡加剧时仍保持鲁棒。在外部迁移测试中,模型在未参与训练的 ScreenSpot-Pro 和 OSWorld-G 等五个涵盖多平台的基准上均显著增长,Qwen3.5-4B 分别提升 11.51 和 10.11 个百分点。在长周期任务中,固定 Qwen3.6-27B 为规划器仅替换动作模型,微调后 Qwen3.5-4B 在 WebArena-Infinity 和 OpenApps 上的成功数分别从 31 升至 50、从 3 升至 15。此外,用该数据微调的 RT-DETRv4-L 检测器在 GroundCUA 上超越了 OmniParser v2 和 ScreenParse YOLO11L。局限在于采集依赖 Linux 后端及无障碍支持,且当前微调未充分利用状态转换数据进行动力学联合训练。
1 主要贡献
核心问题:计算机使用代理(Computer-use agents)需要在复杂的桌面场景中可靠地定位操作目标,在这些场景中,多个应用程序、重叠的窗口以及视觉上相似的控件会分散代理的注意力。现有的训练数据很少将此类复杂场景与密集的标注配对,也缺乏以受控方式产生的数据变体。
研究目标:构建一个可控的桌面环境,通过组合和探索真实的应用程序,为计算机使用代理生成大规模的结构化监督数据。
创新点:
- 开发了DeskForge可控桌面环境:该环境能够配置和探索真实的应用程序,通过改变应用程序状态、内容、窗口布局、外观和分辨率,并将截图、辅助功能树(accessibility trees)和窗口几何形状融合为密集的元素标注,同时记录每次执行操作的结果。
- 构建了DeskForge-1M大规模语料库:利用该环境生成了包含120万个带标注的桌面观察结果的数据集,其中包含1.597亿个元素实例和91.7万次记录的点击转换。
- 实现了显著的Grounding与下游任务性能提升:在DeskForge-1M的20万个Grounding示例上微调了四个视觉语言模型(VLM)。所有模型在保留的桌面条件和五个外部GUI Grounding基准上均取得提升;例如,Qwen3.5-4B在ScreenSpot-Pro上的准确率提高了11.51个百分点,在OSWorld-G上提高了10.11个百分点。这些收益还转化为长跨度任务完成度的提升:在固定的规划器(planner)下,微调后的动作模型解决了更多的WebArena-Infinity和OpenApps任务。
2 背景知识与关键Observation
结构化屏幕监督。GUI监督的范围从定位单个目标到恢复屏幕的结构化描述。Rico和WebUI分别将截图与移动视图层次结构和网页元数据配对(【1,Rico: A Mobile App Dataset for Building Data-Driven Design Applications,2017,UIST】;【2,WebUI: A Dataset for Enhancing Visual UI Understanding with Web Semantics,2023,CHI】)。截图到结构(Screenshot-to-structure)的学习建立在此信息之上:Pix2Struct从掩码截图中预测简化的HTML,而ScreenParse提供密集的网页屏幕标注并引入了本文采用的ScreenTag表示(【3,Pix2Struct: Screenshot Parsing as Pretraining for Visual Language Understanding,2023,ICML】;【4,ScreenParse: Moving Beyond Sparse Grounding with Complete Screen Parsing Supervision,2026,ICML】;【5,SmolDocling: An Ultra-Compact Vision-Language Model...,2025,ICCV】)。GroundCUA将密集的、经过人工验证的标注引入专家桌面工作流程(【6,Grounding Computer Use Agents on Human Demonstrations,2026,ICLR】)。这些资源虽然保留了动作目标之外的元素属性和关系,但标注的是独立的网页、移动屏幕或单个应用程序,而不是组合的多应用程序桌面。
自动化收集和界面合成。自动化管道扩展了界面覆盖范围(【7,SeeClick...,2024,ACL】;【8,OS-ATLAS...,2025,ICLR】;【9,ScaleCUA...,2026,ICLR】),而UGround则根据网页结构和视觉内容合成指代表达式(【10,Navigating the Digital World as Humans Do...,2025,ICLR】)。其他管道直接改变界面本身:Jedi将UI分解与合成和增强相结合,而MolmoPoint-GUISyn渲染生成的HTML界面(【11,Scaling Computer-Use Grounding...,2025,NeurIPS】;【12,MolmoPoint-GUISyn dataset,2026】)。GUIrilla通过原生辅助功能API探索运行中的应用程序以构建状态-动作图,但它是单独处理每个应用程序的(【13,GUIrilla: A Scalable Framework...,2025】)。相比之下,DeskForge在共享的桌面场景内配置和探索多个应用程序,改变它们的联合布局和周围上下文。
可控环境和桌面组合。可执行环境将界面操作与任务级结果联系起来,如WebArena和OSWorld(【14,WebArena: A Realistic Web Environment...,2024,ICLR】;【15,OSWorld: Benchmarking Multimodal Agents...,2024,NeurIPS】)。环境控制还支持不同形式的变体:OpenApps改变应用程序的外观和内容以研究可靠性(【16,OpenApps: Simulating Environment Variations...,2026,ICLR】),而CUA-Gym和WebArena-Infinity将环境状态或应用程序与任务和验证器一起构建(【17,CUA-Gym...,2026】;【18,WebArena-Infinity...,2026】)。WinDeskGround组合捕获的窗口图像以改变布局、遮挡和干扰,用于Grounding评估,但其静态组合无法执行进一步的操作(【19,WinDeskGround...,2026,ICML】)。DeskForge在运行的桌面内执行组合和交互,收集密集的标注以及观察到的点击结果。
交互数据和转换监督。交互记录将屏幕观察与任务导向的行为联系起来。Mind2Web和AgentNet提供人类演示,而CUA-Suite中的VideoCUA保留了连续的专家交互(【20,Mind2Web...,2023,NeurIPS】;【21,OpenCUA...,2025,NeurIPS】;【22,CUA-Suite...,2026】)。GUI-360通过自动化任务执行收集轨迹,并保留截图和辅助功能元数据(【23,GUI-360...,2025】)。另一种替代方案颠倒了交互和任务规范的顺序:OS-Genesis首先探索,然后追溯得出任务(【24,OS-Genesis...,2025,ACL】)。DeskForge使用这种交互优先的方法,从记录的点击和之前/之后的观察中构建单步Grounding指令。记录的转换还可以支持联合逆向和正向动力学学习(【25,Scaling GUI Agents with Visual State Transitions,2026】);本语料库保留它们正是用于此类目标。
资源对比总结。在现有的GUI资源中,只有DeskForge结合了密集标签、多应用程序场景、可配置环境、可见性几何形状和记录的转换这五大特性。
3 方法细节
DeskForge环境架构概述。DeskForge将可控的桌面执行与结构化观察相结合,以生成密集的屏幕标注和记录的交互。其工作流程为:首先,各个应用程序在配置好的桌面场景内渲染其自身的界面;接着,标注管道将渲染的内容与底层的界面结构关联起来;最后,系统记录所执行操作的结果。
场景规范与配置机制。每个桌面场景均由一个场景规范(scene specification)定义。该规范负责选择应用程序及其初始状态、准备其内容,并设置窗口的布局和堆栈关系、外观样式以及显示分辨率。采样权重控制了这些设置的普遍性,而布局约束则定义了可行的多窗口排列方式。因为存在这种机制,同一个应用程序可以被放置在不同的上下文中,面临相互竞争的控件、标签和部分重叠的窗口。此外,应用程序的内容也是可配置的,因此变化范围超越了窗口的放置,延伸到了界面内呈现的具体信息。每个配置轴都是可扩展的:外观预设和分辨率作为配置条目存在,而只要一个应用程序的辅助功能树(accessibility tree)暴露了主要界面内容,就可以通过一个指定其启动命令、暂存内容和脚本化初始状态的清单(manifest)将其添加到环境中。
视觉多样性的扩展实现。为了将视觉覆盖范围扩展到单一的Linux桌面风格之外,环境集成了社区开发的应用程序主题、图标集和窗口装饰,并配备了可配置的面板、停靠栏(docks)和背景。系统内置了七种外观预设,涵盖了经典的Linux、类似Ubuntu、受Windows启发和受macOS启发的风格,并且包含了浅色和深色变体。这些资产配置了运行中的桌面和应用程序工具包,从而改变了小部件的外观、图标和桌面布局,而不仅仅是替换背景图像。所有预设都共享一个Linux执行后端;它们通过样式重现特定的视觉约定,而不是真正执行原生的Windows或macOS应用程序。
密集结构化标注的生成。标注管道结合了截图、辅助功能观察以及测量的窗口关系。其输出详细描述了元素类型、文本、几何形状和交互属性,同时保留了父子结构、阅读顺序以及应用程序和窗口的所有权。辅助功能报告的操作和控件状态(例如一个元素是否启用、选定或展开),利用有关捕获界面的底层信息补充了纯视觉的标注。
可见性判定与几何体细化。仅靠辅助功能结构并不能准确决定什么是屏幕上真实可见的。几何体细化和裁剪机制考虑了元素边界、祖先容器、视口限制、重叠窗口以及瞬态覆盖层(transient overlays)。对于部分被覆盖的元素,其可见支撑(visible support)被表示为多个矩形的并集。这种设计保留了控件实际暴露的部分,而不是简单地将其整个范围视为有效的点击区域。辅助功能名称与显示的文本被分开保存:系统通过字符几何形状和像素检查来评估哪些文本是真正暴露在屏幕上的,因此,一个图标的语义名称不会被自动视为屏幕上渲染的文本。此外,从辅助功能树中省略的选定桌面控件会从窗口几何形状中被恢复出来。
视图保留与自动化质量控制。一个可见的、减少冗余的标注视图构成了屏幕解析和ScreenTag序列化的基础,该视图在需要时会保留结构容器节点。环境单独保留了捕获的隐藏元素及其可见性状态,允许保留的界面表示扩展到当前暴露的内容之外。自动审计系统排除了$4.7\%$标注不一致或极其稀疏的捕获样本。针对遗漏和虚假标注的像素级检查指导了整个管道的开发。人工审计进一步确认了标注质量,发现采样的元素标注中有$99.8\%$是正确的。
交互探索与记录机制。DeskForge通过对可操作元素进行采样并在其估计的可见区域内执行点击来探索场景。这种探索由元素选择驱动,而不是由预定义的任务目标驱动,并且会同时记录界面发生改变和未改变的结果。每个转换$( S_t, a_t, S_{t+1} )$将之前和之后的屏幕观察与执行的操作、目标元数据以及聚合的效果摘要链接起来。相关的元素记录还允许系统单独派生出内容、几何形状、可见性和控件状态的变化。
基础指令(Grounding Instructions)的构建。为了构建Grounding示例,系统提示一个视觉语言模型(VLM),为其提供之前和之后的观察结果以及目标上下文,要求其编写一条单步指令。指令经过细化和过滤,以确保描述的目标可以仅从之前的截图中识别出来,而无需引用坐标或标注标记。由此产生的基础示例将该截图和指令与记录的目标配对。后续观察结果仅用于指导指令的构建,但不提供给Grounding模型进行训练。这产生了一套指令Grounding监督数据,同时保留了底层的转换数据以用于其他潜在的学习目标。
DeskForge-1M数据集的规模与构成。DeskForge-1M包含$1.21\mathbf{M}$个带标注的桌面观察结果和$159.7\mathrm{M}$个元素实例,涵盖19个应用程序、7个外观预设和7个显示分辨率。应用程序包括浏览器、编辑器、文件管理器和桌面实用程序,分辨率范围从$1366 \times 768$到$3840 \times 2160$。观察结果被分组为大约324K个场景,包括单独的捕获和交互片段,具有917K个记录的点击转换。元素计数取自可见的、去冗余的标注视图,并在每个观察结果中对每个元素计数一次。
观察结果的密度特征。观察结果密集且杂乱:它们平均包含132个标注元素(中位数为121),$90.9\%$记录了至少两个应用程序,并且$97.7\%$包含被遮挡的元素,在近一半的观察结果中,受影响的元素超过$30\%$。这些统计数据客观描述了桌面上下文的复杂性。
标注内容与监督视图。每个观察结果将截图与密集的元素记录和ScreenTag表示配对。元素记录给出了每个元素的几何形状、文本、类型、窗口所有权和交互属性,并存储了其完整范围和可见区域(即重叠窗口暴露留下的片段);ScreenTag将同一屏幕序列化为保留元素层次结构的紧凑标记。转换记录添加了执行的点击、其目标、后续观察以及改变内容的摘要。为了在Grounding监督中引入语言变化,系统使用Qwen3.6-27B从程序化记录的点击、目标上下文和之前/之后的截图中合成自然语言指令。模型被提示以简洁、标准和更具上下文的公式表达相同的单步用户目标。
评估拆分策略(Evaluation Splits)。训练、验证和测试分区在场景级别进行分配,确保同一场景的交互帧和重新捕获被保持在同一个拆分中。四个测试条件区分了具有代表性桌面属性的新场景(New Scenes)与包含保留应用程序(App)、保留外观预设(Theme)或保留显示分辨率(Resolution)的场景。应用程序拆分保留了GNOME系统监视器、Pluma和Xarchiver;外观拆分保留了Quartz Night Nord预设;分辨率拆分保留了$2880 \times 1800$。这些分区专门用于评估模型对训练中未表示的桌面配置的泛化能力。
4 实验环境
数据集配置:
- 训练集:DeskForge-1M,使用其包含20万个单目标Grounding示例的训练视图进行微调。元素检测任务使用其密集标注屏幕。
- 外部评估基准:ScreenSpot-Pro, ScreenSpot-v2, OSWorld-G, UI-Vision, MMBench-GUI。
- 长跨度任务评估环境:定制的119个任务的WebArena-Infinity面板,以及100个任务的OpenApps longer-horizon集。
- 元素检测评估:GroundCUA。
模型架构与参数:
- 基础VLM模型:Qwen3.5-4B, Gemma4-E4B IT, InternVL3.5-8B,以及GUI特化模型 UI-R1-3B。
- 规划器模型:固定的Qwen3.6-27B规划器。
- 元素检测模型:RT-DETRv4-L。
硬件配置:
- 微调过程使用8张 NVIDIA H100 GPU。
软件与训练配置:
- 微调方法:使用LoRA进行微调(Rank 8, $\alpha=32$)。适配器应用于语言模型路径,视觉编码器和多模态对齐模块保持冻结。
- 训练超参数:有效全局批大小为64,训练1个epoch(3,125次优化器更新)。使用BF16精度,Fused AdamW优化器,学习率$10^{-4}$,余弦衰减调度。
5 实验结果
1. 保留桌面条件下的Grounding准确率评估
- 实验内容:在DeskForge-1M定义的四个场景级保留条件(New Scenes, Theme, App, Resolution)下,评估四个基线/微调模型对的Grounding准确率,并与多个公共检查点进行对比。
- 实验结果:所有四个模型在每个保留条件下均取得显著改善。Qwen的平均准确率从$76.26\%$上升到$87.54\%$,UI-R1从$38.01\%$提高到$84.59\%$。微调后的Gemma和InternVL模型分别达到$85.12\%$和$81.42\%$。
- 分析结论:微调带来的收益不仅适用于新场景,还成功迁移到了保留的应用程序、外观和分辨率上,证明了监督信号能够泛化到训练中未见过的桌面配置。此外,当桌面场景变得更困难时(例如屏幕上的应用程序从1个增加到4个以上,或目标的可见区域损失增加到$35\%$),微调模型展现出极强的鲁棒性,与基线模型的差距进一步扩大。
2. 外部Grounding基准测试的迁移评估
- 实验内容:在不包含在微调数据中的五个外部基准(ScreenSpot-Pro, ScreenSpot-v2, OSWorld-G, UI-Vision, MMBench-GUI)上进行评估。这些基准涵盖了Windows, macOS, Linux, 移动和Web屏幕,并包含DeskForge未运行的专业应用程序。
- 实验结果:所有四个模型在所有五个外部基准上均获得了更高的准确率。Qwen在ScreenSpot-Pro上获得了11.51个百分点的提升,在OSWorld-G上获得了10.11个百分点的提升。Gemma在五个基准上的平均准确率提高了24.9个百分点。UI-R1在ScreenSpot-Pro上从$14.48\%$提高到$27.20\%$,平均准确率从$39.87\%$提高到$47.14\%$。
- 分析结论:通过受控桌面执行生成的监督数据成功迁移到了DeskForge环境之外的GUI集合。特别是对于UI-R1(一个已经为GUI交互特化的模型)的提升表明,DeskForge-1M不仅有利于通用VLM,也有利于进一步改进现有的计算机使用模型。ScreenSpot-v2的细分数据还显示,模型不仅在桌面界面上提升最大,在移动和Web界面上也有所改善。
3. 固定规划器下的长跨度任务完成度评估
- 实验内容:保持Qwen3.6-27B规划器固定(仅输出无坐标的目标描述),仅替换动作模型(基线 vs 微调),在定制的119任务WebArena-Infinity面板和100任务OpenApps集合上测试任务完成数。
- 实验结果:所有四个微调后的动作模型在两个环境中都解决了更多的任务。Qwen在WebArena-Infinity上解决的任务从31个增加到50个,在OpenApps上从3个增加到15个。Gemma在Infinity面板上的增加幅度最大,从5个任务增加到40个任务。
- 分析结论:尽管微调使用的是单个Grounding示例而不是任务轨迹,但微调后的动作模型在连续观察中更成功地执行了固定规划器的决策。这证明了仅改善Grounding能力就能在不训练规划器的情况下提高长跨度任务的完成率。
4. 密集元素检测评估
- 实验内容:使用DeskForge-1M的密集标注微调RT-DETRv4-L检测器,并在外部GroundCUA基准上评估跨数据集的定位性能。
- 实验结果:DeskForge RT-DETRv4-L在所有三个定位指标上均优于OmniParser v2检测器和ScreenParse YOLO11L,Group F1达到$62.17\%$(分别超过后两者3.62和4.58个百分点),Center-hit F1和Mean best IoU也最高。
- 分析结论:在DeskForge密集屏幕标注上训练的检测器能够有效地定位DeskForge之外的屏幕上的元素,证明了该语料库在屏幕解析的定位组件中的补充用途。
6 结论
DeskForge使运行中的桌面应用程序的组合和探索成为结构化监督的可控来源。由此产生的DeskForge-1M包含120万个带标注的观察结果和1.597亿个元素实例,以及记录的点击转换。微调改善了通用模型和GUI特化模型在保留桌面条件和五个外部基准上的Grounding,并在固定规划器下提高了长跨度任务的完成度。密集元素检测展示了同一语料库的补充用途。这些结果表明了可控生成的桌面数据对于学习和应用视觉Grounding的巨大价值。
局限性与未来方向。当前的采集使用Linux后端,并依赖于具有合适辅助功能支持的应用程序。更广泛的应用程序集成、原生平台后端和补充的视觉标注将把覆盖范围扩展到暴露较少结构的界面。本文的VLM训练侧重于单目标Grounding,下一步自然是从界面结构和记录的状态变化中进行联合学习。特别是,保留的转换可以支持正向和逆向动力学目标,以学习有关动作结果的信息。开发具有基于状态验证的目标条件多应用程序任务,将进一步推动DeskForge走向长跨度计算机使用代理的在线训练。
7 附录
A 数据集规范
A.1 观察结果、标注和监督视图。DeskForge-1M包含1,207,368个带标注的观察结果和159,723,780个保留的元素实例。元素总数是在每个观察结果中分别计算可见的、减少冗余的标注视图中的条目得出的,包括交互帧中重复出现的元素。平均和中位数分别为每次观察132.29和121个元素。观察有效载荷包含截图、元素标注、ScreenTag序列化和捕获记录。环境还额外保留了更广泛的提取和非模态记录。由于存储了每一个截图、标注和转换,使用DeskForge-1M不需要执行环境:训练和评估不需要虚拟机、应用程序安装或环境重置。
A.2 场景级拆分。属于同一场景的所有观察和重新捕获共享一个拆分。应用程序分配使用整个场景中记录的应用程序的并集。保留的应用程序是GNOME System Monitor, Pluma, 和 Xarchiver;保留的外观是Quartz Night Nord;保留的分辨率是$2880 \times 1800$。匹配多个保留条件的场景按应用程序、外观、然后分辨率的优先级分配。New Scenes条件保留了具有代表性应用程序、外观和分辨率属性的场景实例。排除标记为近似重复或空操作帧的观察结果后,留下了一个包含1,067,799个观察结果和142,537,053个元素实例的过滤状态视图,人工审计即从中采样。
A.3 应用程序和显示组合。图5和图4显示了应用程序共现和显示分辨率的分布。应用程序共现在单独的捕获中测量,然后在场景级别平均,因此较长的交互片段不会仅仅因为包含更多帧而获得更大的权重。图3中的遮挡比例是进入遮挡通道的元素被该通道裁剪或移除的比例。
B 环境和数据生成
B.1 执行和采集。每个采集工作器使用Xvfb、私有D-Bus会话、xfwm4、MATE面板和Caja桌面组件运行一个隔离的Linux桌面会话。应用程序以暂存内容初始化,并根据场景规范进行排列。应用程序集成需要可靠的启动行为和主要界面内容的辅助功能覆盖。桌面采集是纯CPU的,并在共享集群上作为批处理作业数组运行;会话除了文件系统外不共享任何内容。最大规模的采集活动运行了300个作业,每个作业24个CPU核心(7,200个核心),每个作业5个桌面会话,共1,500个并发会话。测得的吞吐量为每小时84,807次观察。
B.2 外观预设和源资产。七种预设协调应用程序主题、图标、窗口装饰、字体以及面板或停靠栏布局。经典Linux和类似Ubuntu的预设使用具有不同桌面布局的Adwaita和Papirus资产。受Windows启发的预设结合了Win11工具包/窗口主题和图标。四种受macOS启发的变体结合了MacTahoe浅色、玻璃、深色或Nord样式与WhiteSur图标和光标。这些资产为运行的应用程序和周围的桌面设置样式;所有预设都保留了Linux执行后端。
B.3 标注视图和细化。未过滤的表示保留了更广泛的捕获层次结构。可见的、减少冗余的表示支持解析和ScreenTag序列化,在需要时保留结构容器。非模态表示通过保留完全隐藏的元素及其可见性状态来增强可见记录。几何细化处理坐标偏移、窗口边界和弹出坐标系。一个元素的可见支撑$V_e$是轴对齐矩形的并集。如果保留了源范围$B_e$,它描述了初始几何细化后的元素,其保存的可见性损失为:
$ \rho_e = 1 - \frac{\mathrm{area}(V_e)}{\mathrm{area}(B_e)} $
该度量包括裁剪和遮挡。ScreenTag使用0-500标准化坐标网格,具有嵌套结构和文本/状态标记。在1,266,471次源捕获中,有59,103次($4.7\%$)未通过结构审计并被排除在DeskForge-1M之外。
B.4 记录的交互和指令构建。探索选择可操作元素而不是遵循预定义的任务目标。角色优先级和目标大小指导采样,而观察到的交互产出低的元素保持可选择状态。每个执行的点击将之前的观察与后续观察联系起来。在捕获格式中,动作与其产生的观察一起存储;其坐标指的是前一个截图。指令合成和语义细化使用批处理的vLLM推理。指令模型接收之前截图、目标标记副本、目标裁剪、后续截图和无坐标目标上下文。它被提示生成相同单步目标的简洁、标准和详细上下文公式。
C 训练和评估协议
C.1 Grounding微调。Qwen3.5-4B, Gemma4-E4B IT, InternVL3.5-8B 和 UI-R1-3B 使用200K单目标Grounding训练视图通过LoRA进行微调。语言模型参数接收适配器;视觉编码器和多模态对齐模块保持冻结。UI-R1从其发布的GUI特化检查点开始,并保留其原生的动作-答案约定。
C.2 推理和配对比较。评估管道使用批处理的vLLM推理,具有特定于模型的图像处理器、提示和响应解析器。对于每个基线/微调对,评估示例、图像准备、提示、解码设置和评分器都是固定的。表2中的其他公共检查点保留了其特定于模型的推理协议。
C.3 Grounding群体和指标。Grounding准确率计算如下:
$ \mathrm{Acc}_{\mathrm{vis}} = \frac{1}{N} \sum_{i=1}^N \mathbf{1}[\hat{p}_i \in V_{e_i}] $
其中$\hat{p}_i$是预测点,$V_{e_i}$是标注的可见区域。无效输出计为不正确。外部评估使用各基准保留的目标区域和评分约定。
C.4 固定规划器任务评估。固定的Qwen3.6-27B规划器选择动作类型、字面文本或按键,以及无坐标目标描述。动作模型提供所需的屏幕位置。模型观察截图、任务和执行反馈,无法访问辅助功能树或隐藏的应用程序状态。在每次比较中,只有动作模型权重发生变化。WebArena-Infinity使用自定义的119任务面板,OpenApps使用其原始longer_horizon集中的100个任务。
D 标注和指令质量
人工审计根据固定量规评估元素正确性和指令合理性。统一的标注样本包含来自1,067,799次观察过滤状态群体的140个屏幕。统一的指令样本包含180个示例。当元素的存在、类别、几何形状、可见文本和遮挡标注共同满足量规时,该元素是正确的。指令合理性需要合法的请求、匹配且唯一可识别的目标以及足够的目标可见性。审计结果显示,统一采样的元素正确率为$99.84\%$,指令合理率为$97.8\%$。
E 补充评估结果
E.4 密集元素检测指标定义。
分配和符号:令$\mathcal{T}$表示评估图像,令$\mathcal{G}_i$和$\mathcal{P}_i$表示图像$i$在所选置信度阈值下保留的真实框和预测。对于轴对齐框$b$,$|b|$是其面积,$c(b)$是其中心。每个预测被分配给包含其中心的最小真实框:
$ \pi_i(p) = \begin{cases} \arg\min_{g \in \mathcal{G}_i : c(p) \in g} |g|, & \text{如果存在包含框} \\ \bot, & \text{否则} \end{cases} $
Center-hit F1的精度和召回率:
$ P_{\mathrm{ctr}} = \frac{\sum_i |\{p \in \mathcal{P}_i : \pi_i(p) \neq \bot\}|}{\sum_i |\mathcal{P}_i|}, \qquad R_{\mathrm{ctr}} = \frac{\sum_i |\{\pi_i(p) : p \in \mathcal{P}_i\} \setminus \{\bot\}|}{\sum_i |\mathcal{G}_i|} $
Group F1的覆盖率和溢出率:
$ \gamma_i(g) = \frac{|U_i(g) \cap g|}{|g|}, \qquad \sigma_i(g) = 1 - \frac{|U_i(g) \cap g|}{|U_i(g)|} $
$ P_{\mathrm{grp}} = \frac{\sum_i |\{p \in \mathcal{P}_i : \pi_i(p) \in \mathcal{M}_i\}|}{\sum_i |\mathcal{P}_i|}, \qquad R_{\mathrm{grp}} = \frac{\sum_i |\mathcal{M}_i|}{\sum_i |\mathcal{G}_i|} $
Mean best IoU:
$ \overline{\mathrm{IoU}} = \frac{1}{|\mathcal{T}|} \sum_{i \in \mathcal{I}} J_i, \qquad J_i = \begin{cases} \frac{1}{|\mathcal{G}_i|} \sum_{g \in \mathcal{G}_i} \max_{p \in \mathcal{P}_i} \mathrm{IoU}(p, g), & \mathcal{G}_i, \mathcal{P}_i \neq \emptyset, \\ 0, & \text{否则} \end{cases} $
💬 评论讨论
欢迎在这里分享您的想法和见解!