JarvisGUI：面向跨设备GUI智能体的动态任务组合评测基准

JarvisGUI：面向跨设备GUI智能体的动态任务组合评测基准

论文arXiv原文：https://arxiv.org/html/2609.10451v1

摘要

真实场景下的图形界面（GUI）任务经常跨多设备、多操作系统完成，需要在异构环境之间传递中间结果、维护共享状态、跨平台协同操作。但现有的GUI智能体评测基准几乎全部限定在单设备、静态预设任务，无法考察跨设备协同能力，导致对智能体落地能力的评估结果过度乐观。

本文提出 JarvisGUI，一套支持动态任务组合的跨设备GUI智能体评测基准。JarvisGUI将GUI任务建模为轻量类型系统下的输入输出变换，能够自动组合多步骤、跨设备工作流，在统一框架内动态评估智能体性能。评测环境包含Android、Windows、Ubuntu多套虚拟机。

在该基准上的大量实验表明：当前主流开源GUI智能体普遍存在短板，缺少状态传递感知能力、跨平台上下文推理能力、长时序依赖管理能力 ；这些缺陷在传统单设备基准上无法暴露，揭示了现有GUI智能体在真实场景下的关键能力缺口。

1 引言

GUI智能体目标是利用多模态大模型直接操作图形界面，自动完成用户任务，例如在电脑、手机上操作软件、处理文件。目前主流基准如AndroidWorld、MobileWorld、UI-Venus均只在单一操作系统内设计任务。

然而真实用户工作流经常跨设备：例如在Ubuntu上下载文件，传到Windows做表格处理，再将结果发送到Android手机的聊天软件。这类任务要求：

1. 跨设备传递中间数据与状态；
2. 感知不同系统之间的上下文依赖；
3. 在长流程中维护任务依赖关系。

静态单设备任务无法评估上述能力，导致模型在基准上表现很好，落地到跨设备场景时大量失败。

本文核心贡献

1. 提出JarvisGUI跨设备GUI评测基准，支持自动动态任务组合，覆盖Ubuntu、Windows、Android三类虚拟机环境；
2. 设计轻量类型系统，将GUI任务抽象为IO变换，自动生成大量复合跨设备工作流；
3. 在150条复合任务上评估主流SOTA GUI智能体，发现现有模型在跨设备状态迁移与长依赖任务上存在显著性能断崖；
4. 开源环境、任务生成脚本、虚拟机评测流水线，可复现全部实验。

2 相关工作

2.1 GUI智能体与单设备评测基准

AndroidWorld、MobileWorld、UI-Venus、OSWorld等基准专注于单操作系统GUI自动化。任务预先人工编写，属于静态任务集，不支持自动组合跨平台依赖任务。模型主要评估截图理解、界面元素定位、单系统内动作规划。

2.2 跨系统/具身智能体

跨设备多模态智能体、Web+桌面混合Agent研究，大多聚焦于模型架构改进，缺少标准化跨设备评测集。JarvisGUI的创新在于任务自动组合+跨操作系统虚拟沙箱，可批量生成带有状态传递依赖的任务。

2.3 任务组合与合成评测

使用类型系统、程序合成自动生成评测任务，多用于代码、推理领域。JarvisGUI将该思路引入GUI领域，自动组装子任务并建立跨设备数据依赖。

3 JarvisGUI方法

3.1 任务抽象：基于轻量类型系统的IO变换

JarvisGUI将每一个基础GUI原子子任务定义为输入→输出变换：

T : τ i n → τ o u t T: \tau_{in} \rightarrow \tau_{out} T:τin→τout

τ \tau τ为数据类型（文本、图片、文件、表格、链接等）。

子任务示例：

• Ubuntu：下载PDF文件（输入URL，输出本地文件）
• Windows：Excel读取PDF提取文字，输出csv
• Android：微信发送csv文件，输入文件，输出发送成功标记

当子任务输出类型与下一个子任务输入类型匹配，系统可以自动串联组合 ，生成跨设备长工作流。任务之间可以携带状态依赖，前一步结果作为后一步输入。

3.2 任务分类

JarvisGUI包含150条复合任务，442个原子子任务，分为三大类别：

1. 单平台带依赖任务：全部操作在同一个OS，多步骤存在内部依赖；
2. 跨平台无依赖任务：操作跨多个设备，但子任务之间无数据传递；
3. 跨平台带依赖任务：跨操作系统，前一个设备产出文件/文本，传给下一设备作为输入（核心难点）。

子任务平台分布：

• Ubuntu：187个子任务
• Windows：138个子任务
• Android：52个子任务
• 文件传输辅助任务：65个子任务

3.3 虚拟沙箱环境架构

• 多台独立虚拟机：Ubuntu、Windows、Android模拟器；
• 沙箱隔离：每个任务启动全新快照，执行结束销毁，保证环境干净；
• 跨机文件通道：受控共享目录，用于模拟设备间文件传输；
• 观测接口：屏幕截图、UI DOM树、设备文件列表、进程状态；
• 动作接口：点击、输入文本、滚动、文件上传下载、启动程序。

评测时智能体只能通过统一API发送动作，不能直接ssh访问底层系统。

3.4 评估指标

1. TSR（任务整体成功率 Task Success Rate）：最终任务目标达成的任务占比；终端环境状态完全匹配用户目标才算成功；
2. SSR（子任务成功率 Subtask Success Rate）：工作流内部中间子步骤的平均完成率，衡量长时序规划可靠性。

4 实验设置

4.1 评测智能体基线

• GUI-Owl
• UI-TARS-1.5
• UI-Venus_Ground
• MAI-UI
• Qwen3-VL-Instruct

4.2 环境与执行参数

• 虚拟机快照：每个任务独立重置，避免状态污染；
• 单任务最大动作步数上限：100步；
• 每一步动作超时：15秒；
• 判定器：自动化状态校验脚本 + 屏幕视觉校验，双重校验子任务输出类型与内容。

4.3 实验分组

• 原子单平台任务
• 跨平台无依赖任务
• 跨平台带状态依赖任务

5 实验结果

5.1 整体任务成功率TSR

Agent	原子单平台任务	跨平台无依赖	跨平台带依赖
GUI-Owl	39.0%	27.2%	8.4%
UI-TARS-1.5	37.3%	25.1%	7.1%
UI-Venus_Ground	37.3%	24.8%	6.7%
MAI-UI	28.8%	18.5%	4.2%
Qwen3-VL-Instruct	35.6%	22.7%	6.3%

核心结论：跨平台带依赖任务性能出现断崖下跌 。在需要把A设备产出的文件作为B设备输入时，几乎所有主流GUI智能体成功率都低于10%。

模型在单设备上表现尚可，但很难识别"跨设备传递中间产物"这一全局依赖。

5.2 子任务成功率SSR

• 单平台任务SSR普遍>65%；
• 跨平台无依赖SSR下降至45%~55%；
• 跨平台带依赖SSR仅20%~30%；
  失败主要原因：

1. 忘记导出/保存前序结果；
2. 无法识别跨设备之间需要传递的文件；
3. 丢失全局任务规划，只在当前屏幕做局部操作；
4. 无法验证前一步输出是否满足下一个子任务输入类型。

5.3 消融实验

1. 移除类型校验：自动组合任务时不再检查IO类型匹配，生成大量无效任务；TSR评估噪声大幅上升；证明轻量类型系统是可靠任务生成的关键；
2. 关闭跨设备文件通道：跨依赖任务全部失败，验证基准环境通道正确性；
3. 单设备 vs 跨设备prompt消融：给模型显式提示"任务跨多台机器，需要保存文件用于后续设备"，仅小幅提升性能，说明缺陷不只是提示词问题，而是模型原生规划能力不足。

5.4 错误定性分析

大量失败案例显示：GUI智能体擅长"当前屏幕上的点击操作"，但缺少全局状态图。智能体只能看到当前设备截图，不会维护跨设备的中间产物清单，不知道哪些文件需要保留并传递到下一台机器。

6 讨论

6.1 核心发现

现有GUI智能体本质上是局部屏幕视觉动作器，不是跨设备全局任务规划器。传统单设备基准无法暴露这个短板。JarvisGUI证明，想要评估真实可用的GUI Agent，必须引入跨设备、带状态传递的复合任务。

6.2 基准局限性

1. 仅模拟虚拟机环境，未接入真实物理手机/电脑；
2. 当前任务以文件、文本类IO为主，复杂多媒体跨设备工作流偏少；
3. 任务类型由类型系统自动生成，真实用户的自然语言意图多样性仍有差距。

7 结论

本文提出JarvisGUI，面向跨设备GUI智能体的动态任务组合评测基准，包含Ubuntu、Windows、Android多虚拟机沙箱，利用轻量类型系统自动合成带跨设备数据依赖的GUI工作流。

实验表明，当前SOTA GUI智能体在单设备任务表现尚可，但跨设备状态传递与长依赖任务能力严重不足。JarvisGUI可以作为新的评测工具，用来跟踪GUI智能体向真实多设备场景落地的进展。未来工作将扩展更多设备类型、丰富多媒体IO任务，同时研究增强跨设备全局状态记忆的GUI智能体架构。

资源清单

1. HTML原文：https://arxiv.org/html/2609.10451v1
2. PDF论文：https://arxiv.org/pdf/2609.10451
3. 开源仓库：论文配套虚拟机环境、任务生成脚本、自动化评测判定代码
4. 评测数据集：JarvisGUI Benchmark（150复合任务，442原子子任务）
5. 依赖环境：QEMU/KVM虚拟机、Android模拟器、GUI动作API、状态校验脚本

附录

附录A 任务生成伪代码

# JarvisGUI 动态任务组合核心脚本
from typing import Type

class Task:
    def __init__(self, name, in_type: Type, out_type: Type, os_platform):
        self.name = name
        self.in_type = in_type
        self.out_type = out_type
        self.os = os_platform

def compose_tasks(task_list, max_depth=5):
    """基于类型匹配自动串联子任务，生成跨设备工作流"""
    composite_workflows = []
    # 广度搜索拼接子任务
    from collections import deque
    queue = deque()
    for t in task_list:
        queue.append( ([t], t.out_type) )
    while queue:
        chain, last_out = queue.popleft()
        if len(chain) >= max_depth:
            composite_workflows.append(chain)
            continue
        for next_task in task_list:
            if next_task.in_type == last_out:
                new_chain = chain + [next_task]
                queue.append( (new_chain, next_task.out_type) )
    return composite_workflows

# 原子任务库示例
atomic_tasks = [
    Task("download_pdf", in_type=str, out_type="file", os_platform="Ubuntu"),
    Task("pdf2csv", in_type="file", out_type="file", os_platform="Windows"),
    Task("send_file_im", in_type="file", out_type="bool", os_platform="Android")
]

workflows = compose_tasks(atomic_tasks, max_depth=3)

附录B 虚拟机沙箱启动脚本（简化版）

# 启动任务独立虚拟机快照
qemu-system-x86_64 -loadvm clean_snapshot ubuntu.qcow2 &
# Android模拟器
emulator -avd jarvis_android -no-snapshot-load &
# 启动动作API服务
python3 jarvis_api_server.py --sandbox

附录C 自动化任务校验脚本逻辑

1. 执行全部子任务后，扫描所有虚拟机的文件系统；
2. 校验输出产物类型、内容哈希；
3. 验证目标GUI状态（窗口、消息、文件是否存在）；
4. 输出TSR、SSR指标。

附录D 基线模型调用Prompt模板

你是GUI智能体，可以操作屏幕，完成跨设备任务。
任务工作流跨Ubuntu、Windows、Android多台机器。
注意：前一个设备生成的文件，需要保存并传递到下一台设备作为输入。
你可以调用点击、输入、保存文件、传输文件等动作。
每次动作前观察当前屏幕，维护全局任务状态。