一个 GUI Agent 打开了 Chrome，随后什么也没做。它的推理记录却声称，文件已经传到 Android，并在那里尝试打开。这个案例来自 9 月 9 日提交 arXiv、被 EMNLP 2026 主会接收的 JarvisGUI 论文：研究者把 Android、Windows 和 Ubuntu 放进同一评测，让 Agent 在不同系统之间传文件、保留中间结果并继续操作。
结果把“会点按钮”和“能完成工作”分开了。表现最好的 HOLO2 组合在 118 个单平台原子任务上完成 50 个，成功率为 42.4%；面对 150 个组合任务，只完成 12 个，成功率降至 8.0%。论文进一步观察到，当任务包含四个或更多子任务时，六套受测系统的端到端成功率都接近零。
三组任务把切换设备与传递状态拆开测试
JarvisGUI 先定义 118 个原子任务，覆盖 Android、Windows 和 Ubuntu 上的 31 个应用，再用一套轻量类型系统把原子任务组合起来。每个任务都声明输入、输出、目标平台和状态检查器；只有前一步输出与下一步输入类型兼容，任务图才会继续扩展。跨平台组合还会插入文件传输步骤。
由此生成的 150 个组合任务平均分成三组：50 个在同一平台内前后依赖，50 个跨平台但彼此独立，50 个既跨平台又存在状态依赖。它们共包含 442 个子任务，其中 65 个是文件传输辅助任务。这样的分组让评测可以区分三类失败：原子动作本身没做对、切换屏幕和平台时走错路、以及前一步产物没有正确交给下一步。
评测运行在可重置的虚拟环境中，不是静态截图回放。环境统一提供截图和无障碍树接口；主实验的规划器读取三套平台截图，Grounder 再把计划变成点击、输入、滚动等动作，最后由程序检查系统状态。动态参数还会改变文件名、文本或任务对象，降低只记住固定轨迹就拿分的可能。
这延续了 AndroidWorld 和 OSWorld 的方向。AndroidWorld 已经用系统状态检查 20 个 Android 应用中的 116 类动态任务；OSWorld 则在 Ubuntu、Windows 和 macOS 的真实应用环境中执行开放式电脑任务。JarvisGUI 新增的变量不是“动态”本身，而是让多个操作系统在同一条任务链中共享中间状态。
每个子任务做成一部分，不等于整条链完成
主实验不是六个 GUI 模型各自独立规划。研究者固定使用 Qwen3-VL-Plus 读取三块屏幕、保存历史并决定下一步在哪个平台执行，再让 UI-Venus、UI-TARS-1.5、MAI-UI、GUI-Owl、Qwen3-VL 和 HOLO2 六种 Grounder 把计划落成坐标动作。因此，表里的差异反映“共同规划器加不同执行器”的整套系统，不能直接解释成六个基础模型的跨端能力排名。
HOLO2 组合的差距最直观。在原子任务上，它的总体成功率为 42.4%，其中 Ubuntu 为 60.7%，Windows 只有 15.8%。进入组合任务后，同平台依赖任务成功率为 16%，跨平台独立任务为 6%，跨平台且有依赖的任务只剩 2%。后一个数字意味着 50 条状态依赖链中只完整完成一条。
端到端失败也不代表系统全程没有进展。HOLO2 在 150 个组合任务中只完成 8%，但按每条工作流已完成子任务比例计算的 SSR 为 19.0%。这说明 Agent 经常能做成链条的一部分，却会漏掉重命名、传输或后续处理，然后把未完成的步骤误认为已经完成。JarvisGUI 的总任务成功率要求终态满足全部目标，任一关键状态缺失都会让整条任务记为失败。
更换规划器改善了数值，没有解开依赖。研究者保持 HOLO2 为 Grounder，把 Qwen3-VL-Plus 换成 Kimi K2.6 后，原子任务成功率从 42.4% 升至 48.3%，组合任务从 8.0% 升至 11.3%；跨平台状态依赖任务仍为 2%。这组对照支持“瓶颈不只来自一个规划器”，但只比较了同一评测框架下的两种有效规划器，不能证明所有架构都会停在相同水平。
JarvisGUI 扩大了跨端对照，不是第一个跨设备基准
跨设备评测此前并非空白。2025 年 ACL Findings 收录的 CRAB 已在 Android 模拟器和 Ubuntu 虚拟机之间构建跨环境任务，并用任务图检查中间状态。其 120 个任务中有 18 个跨平台任务。JarvisGUI 论文也承认 CRAB 的存在，因此更准确的增量是规模和变量控制：它加入 Windows，把跨平台任务扩到 100 个，并将“仅切换平台”和“还要传递状态”各设 50 个样本。
这个对照揭示了一个容易被总榜掩盖的事实。多设备独立任务已经会因三块屏幕、平台路由和不同控件而退化；状态依赖任务再增加一条严格关键路径。Agent 不仅要记住上一台设备发生了什么，还要确认文件真的上传、路径真的存在、下一台设备看到的是正确版本。论文案例中“没有传文件，却在推理里当作已经传完”，正是这种状态验证缺口。
虚拟机结果还不能直接代表真实办公环境
JarvisGUI 的 150 条组合任务并不等于 150 条经过逐一人工实测的生产流程。研究者对原子任务做了人工静态检查，又从自动组合任务中随机抽查 50 条；其中 92% 被评为完全正确，另有 4 条描述不够精确。其余组合任务经过模型过滤和程序检查，但论文没有报告逐条人工复核。
环境也主动舍弃了若干现实摩擦。Android、Windows 和 Ubuntu 都运行在 Docker/KVM 虚拟化体系内；文件通过始终开启的私有 AList 网络盘传输，而不是 USB、蓝牙或真实云盘；轨迹最多 50 步，不包含 macOS 和 iOS。实验使用两台各有 128GB 内存并启用 KVM 的 Linux 服务器，论文没有报告每个任务的重复运行次数。
复现仍是最直接的发布门槛。论文称将公开完整数据、评测代码、Docker 编排和模型配置，但截至目标发布日期，GitHub 仓库只有 README，并写着代码和数据“即将开源”。因此，42.4%、8.0% 和四步后接近零都还是论文团队在自建环境中的结果，尚没有独立复现。
JarvisGUI 真正改变的不是又给 GUI Agent 增加一张总榜，而是把交付标准从“这一步点对了吗”推到“跨设备终态真的成立吗”。下一步应观察的不只是仓库何时开放，还包括复现者能否在不同规划器、真实文件服务和多次运行下重现同一条断崖。只有这三项站住，跨端 Agent 的能力讨论才会从演示中的连续动作，转向可验证的完整工作流。
