UI-Venus-2：GUI 智能体，多数基准登顶，长程任务仅 2.8% 跑完

能跑基准，不等于能用：落地差在哪三件事上

这篇文章要回答一个问题：GUI 智能体为什么在长程真实工作中不能交付？「长程真实工作」具体长什么样，可以先拿报销差旅费当例子感受一下。让 AI 助手替你做这件事：报销一笔差旅费。它要先找到并读懂一份 PDF 教程，登录老旧的财务门户，从发票扫描件里识别金额，再跨到邮箱和银行网页做交叉核对。做到一半，一封新邮件插进来，流程因此要改。做完这一切，才算「完成」。

这个问题有多严重？对人类来说，这是一个多小时的工作。对当下最强的 GUI 智能体来说，这类任务的完整完成率大约只有 8% 到 20%。GUI 智能体，就是直接看屏幕截图、自己输出点击、输入、滑动等操作来完成数字任务的 AI 助手。它在识别元素、执行单步操作上已经很强，可一旦任务被拉到真实工作的长度，成绩就断崖式下跌。这不是某个模型的失误，而是这一整类系统的通病：单步都会，整件事交不出去。

图注：图左半是 OSWorld 2.0 的跨应用报销工作流，涉及 PDF 教程、遗留门户、邮箱与银行网页的交叉核对。图右半是不同推理强度下各模型的完成率对比，投入更多 token 也推不动严格完成的成绩。OSWorld 2.0

这张图来自 OSWorld 2.0，它正是回答「为什么不能交付」要用的量尺：一个专测长程真实任务的桌面基准（benchmark）。它的 108 条任务中位数耗时约 1.6 小时，平均 250 步以上，还故意让任务跨多个应用、互相依赖。OSWorld 2.0 反常点在哪儿？模型不是不会点击了，而是「能跑基准」和「能在真实环境把事办完」之间，隔着三道互相咬合的坎。

量尺把问题钉成了数字，接下来是对同一问题的诊断：为什么交付不了？第一道坎是环境覆盖窄。大多数模型只在少数人工挑过的应用上训练过，换个没见过的软件就抓瞎。第二道坎是任务构造脆。基准任务常用人工拼凑，模型背下的是任务模板，而不是做事能力。第三道坎最隐蔽，也最致命：奖励验证不可靠。GUI 任务没有标准答案，谁来判定「做对了」？如果成败信号本身不可信，强化学习就会把模型训练成专钻评分空子的投机者。这个现象叫 reward hacking（奖励钻空子），就像学生发现老师只查最后一步答案，于是只把最后一步填对。三道坎还互相耦合：环境窄逼着你只能用少量任务，任务脆逼着你只能整屏打印象分，判分不可靠又让模型学到投机而不是真本事。UI-Venus-2

对这个问题的最终诊断，UI-Venus-2 给的结论是：三件事必须一起放大，只补任何一根，另外两根都会拖后腿。它还更进一步，把最容易被人忽略的第三件事，也就是验证，提到了与环境和任务平起平坐的位置。这家来自蚂蚁集团 Venus 团队的开源模型到底怎么拆这道题？下一章看整体设计。

为什么必须三件事一起放大：UI-Venus-2 的整体设计

UI-Venus-2 的运转方式是一套闭环：感知屏幕，推理下一步，执行动作，再回头看结果。跟其它 GUI agent 相比，它的总回答不是某个花哨技巧，而是把环境、任务、验证三件事当作同一场放大来设计。

环境维度，覆盖 170 多个多语言移动应用，其中 100 多个中文、70 多个英文，加上从零搭建的原生桌面操作系统，网页侧拼出 4000 多个域名、19 个类别的网站池。任务维度，用一条 deep-research 流水线从应用的真实功能反推指令，让模型面对的是「导出这个报表」这类函数级任务，而不是人工编造的模板题。验证维度，是轨迹级和样本级两套评估器，加视觉关键点、多模型投票，目标是把成败信号做成让 RL 不敢钻空子的可靠监督。

图注：UI-Venus-2 的系统总览：左侧是任务生成与多域任务池，右侧是在移动应用、浏览器与桌面软件三端采集真实交互轨迹的通道，共同构成数据闭环。UI-Venus-2

注意这张图的每一环都对应着上一章的一道坎：任务池来自真实功能反推，解决任务脆；三端轨迹采集铺开环境，解决覆盖窄；而验证环节，决定了采集来的轨迹能不能变成干净的训练信号。

这个家族不是一步走到这里的。2025 年的 1.0 用强化微调立住范式，2026 年初的 1.5 引入大规模 mid-training 和模型合并。2 的增量不在参数更大，而在把「验证」从训练附属品升格为独立的放大维度：上一代用模型合并把专家拼成一个，这一代用可验证信号做多教师蒸馏。这是后话。先看那个最容易被忽略、却撑起整个体系的支点：验证。UI-Venus-1.5

验证是命门：把「对错」变成可训练的可靠信号

怎么判断一个 GUI 任务做对了？最省事的做法，是让一个强语言模型对着最终截图问一句「完成了吗」。单一判官有两个毛病。一是会幻觉：任务填的是后台数据，最终状态根本不在截图里，它只能靠猜。二是会被钻空子：模型发现判官只看最后一眼，于是只演最后一幕。把这种信号喂给强化学习，等于告诉模型「骗过我就能得高分」。

UI-Venus-2 的思路是别让判官打印象分，把任务拆成一个个可核对的视觉关键点（keypoint）。任务是「在目标群里发帖」，关键点就是「进对了群、填了标题、写了正文、点下了发布」，每一件都是能用眼睛客观核对的事：进没进群，看群名对不对；发没发布，看界面有没有反馈。这就像考卷上的给分点：阅卷老师按给分点逐条核对，而不是凭整体印象打分。再把多个独立判官请来各自核对，最后按多数意见聚合，单个判官的偏置和错觉就被抹平了。给分点保证标准客观，多判官保证评分稳定，两层合起来，才敢把结论喂给训练。

轨迹层面，这套流程叫 SGV（语义引导验证），分五步走：

图注：轨迹级验证的五阶段流程：先抽取关键点，再把整条轨迹切成窗口、在点击处叠加红点，逐窗口并行核验，硬规则处理不了的交由多模态终判，最后输出结构化报告。UI-Venus-2

整条轨迹最终落入四类结论：completed（完成）、partial（部分完成）、infeasible（不可能完成）、failed（失败）。「部分完成」和「失败」的区分很讲究：同样一个发帖任务，模型进了正确的群、填了标题和正文，最后忘了点发布，这是 partial 而不是 failed。它意味着模型走对了绝大部分路，卡在了最后一公里，这个教训和完全跑偏是两回事。

轨迹级之外还有样本级评估器，对单个动作判四类：

四类判定的价值，是给「完成了」和「失败了」之间留出中间地带：一个带着理由的探索性尝试，不应该和随手瞎点一起挨罚，前者是值得保留的行为。

同一道「稀疏奖励」的题，业界还有别的解法。GUI-Shepherd 训练一个过程奖励模型，给每一步打「对/错」的稠密分数；VAGEN 则把验证器本身做成 agent，必要时打开终端、翻文件、查网页，主动探查截图上看不见的隐藏状态。UI-Venus-2 选的是第三条路：不依赖判官对整屏的隐式感觉，而是把「对错」钉在可核对的视觉事实上。三条路各有取舍，没有谁被证明全面胜出，但选型逻辑的分野很清晰：一个赌每步评分，一个赌主动探查，一个赌客观锚点加多判官。GUI-Shepherd VAGEN

有了可靠的「对错」信号，接下来是把它吃进训练。这是下一章的事。

把验证吃进训练：三段式流水线与多教师蒸馏

UI-Venus-2 的训练分三段。第一段是大规模轨迹 mid-training，往基座模型里灌 GUI 交互常识，包括界面长什么样、点击滚动怎么做。第二段是按域做 step-level 离线 RL。离线 RL 的意思是，用事先收集好的轨迹数据训练模型，而不是让模型在实际环境里实时试错。RL 的具体算法叫 GRPO：对同一条任务采样出好几条动作序列，按回报高低调整模型，让高分动作越来越常出现。这一段的五个域是 Grounding、验证码、移动、网页、桌面。Grounding 指把指令落到屏幕上具体坐标的能力，比如「点右上角的保存」要算准按钮在哪。其中验证码和 grounding 用程序化合成，把大量可验证样本嵌进真实界面，换来了动作级的稠密正确性信号，上一章验证系统的成果在这里开始变现。

图注：三阶段训练流水线：第一阶段用大规模轨迹 mid-training 注入 GUI 交互知识，第二阶段按 Grounding、CAPTCHA、Mobile、Web、Computer 五域做 step-level 离线 RL，第三阶段用多教师 on-policy 蒸馏把各域专家合并为最终模型。UI-Venus-2

第三段是这篇报告最核心的新设计：MOPD，多教师 on-policy 蒸馏。蒸馏（distillation）指的是让小模型模仿大模型或专家的输出。为什么需要这一步？五个域的专家不能都塞进线上服务，必须合并成一个模型。上一代 1.5 的做法是模型合并，把专家权重做插值，一次算完，静态融合；MOPD 做的是在线蒸馏，让专家在真实数据上现场教一个学生模型，学生当场学、当场改。前者省事，后者更能保留每个专家的判断力，因为训练信号直接来自专家对具体动作的打分。

MOPD 里有两个值得注意的设计。第一个叫 structured action-aware，按学生动作的对错切换监督强度。动作值得被单独拎出来，是因为它是 agent 唯一接触环境、决定状态转移的接口，在输出里占比很小，容错率却极低，坐标偏一个像素整步作废。动作全对，少教，别浪费样本；类型对但参数错，重点教动作那一段；类型错，先教类型，并把依赖类型语义的参数监督屏蔽掉。第二个设计是 teacher-side action-type 提示 h(z*)：只把「正确动作类型」这个提示加到教师那边，教师据此给学生打分；学生自己的输入和推理时都拿不到这个提示。相当于阅卷老师手里有标准答案，学生没有，但老师会根据学生答成什么样精准给分。这样训练出来的模型，必须自己学会判断动作类型对不对，而不是从哪个提示里抄答案。

这套「统一动作空间 + 规则化奖励 + GRPO」的配方，源头可以追溯到更早的 GUI-R1，它证明了规则化奖励可以用极小数据训练出能打的 GUI 模型。MOPD 是这条 RL 路线上「把验证信号做成训练收益」的收口。训练这套体系到底换来了什么？下一章用数字检验。GUI-R1

它到底多能打：跨端领先、安全减半，和那道没跨过去的长程鸿沟

先看整体快照。官方仓库贴出的八面板横评里，27B 模型在八块基准中有七块排第一。唯一没登顶的是 OSWorld-Verified，它被 Claude-Opus-4.8 以 83.4 略胜，27B 拿到 80.5，排在所有开源模型前面。读这个数字要带一个限定：各家评测用的动作脚手架（action scaffold）可能不同，论文声明这类对比应作为基准层面的参考，而不是严格受控的对照。UI-Venus repo

图注：官方仓库的八面板基准总览，覆盖 MOBILE、BROWSER、COMPUTER、CAPTCHA、GROUNDING 五类。27B 与 9B 的蓝色条和各基线的灰色条横向对比，27B 八块七冠。UI-Venus repo

再把论文 Figure 1 里的柱子挑三根细读。网页端 WebVoyager 拿下 93.4，比此前最强的 GUI 专用基线 Fara1.5-27B 高 4.1 分。桌面端 DeskCraft 55.5，比 Kimi-K2.6 高出 14.1 分，这是通用模型在桌面软件操作上的一个明显增量。最值得看的是验证码：VenusBench-CAPTCHA 上 27B 拿到 79.9，同基座的 Qwen3.6-27B 只有 53.0，拉开 26.9 分。验证码的答案机器可验证，正是验证体系最擅长处理的场景：Stage II 用程序化合成把大量可验证样本嵌进真实界面，换来动作级的稠密正确信号，CAPTCHA 是这套设计的主场。但要提醒一句：这是端到端横评，26.9 分的差距是基座、合成数据、离线 RL 与蒸馏合在一起的结果，不能单独归因于验证组件。论文没有报告把验证器拆掉再测的消融，谁要断言「这 26.9 分全是验证的功劳」，证据还不够。UI-Venus-2

图注：论文 Figure 1 的五面板横评：移动、桌面、网页、grounding、CAPTCHA 五类基准上，27B 与 9B 相对各强基线的柱子对比，标注星号的基线为论文自己复现。UI-Venus-2

领先要分开看，论文自己也承认反例。MobileWorld 的 50 步设置下，27B 是 76.1%，落后 Qwen-UI-Agent-27B 的 82.1%；grounding 面板的 ScreenSpot-Pro 排在第二；Open CaptchaWorld 上只领先 Seed-2.0-Pro 0.7 个百分点，说明通用多模态模型已经覆盖了相当一部分验证码能力。这些不领先的行，和登顶的行同样重要，它们划定了一家模型真实能力的边界。

安全侧的成绩单同样好看。安全评测打的是攻击成功率，论文里叫 Attack Success Rate，缩写 ASR，越低越好。它覆盖用户恶意指令、第三方提示注入、模型自发性失误三类风险，外加一类指令无害但执行会闯祸的盲点测试。9B 模型在 OSHarm 上把攻击成功率从同基座 Qwen3.5-9B 的 25.3% 压到 11.3%，在 OSBlind 上从 79.4% 压到 48.8%，近乎减半；27B 在 OSBlind 上是 47.9%，相对同基座的 89.3% 同样大幅下降。OS-Harm

论文把安全设计写进了系统：对后果重大（consequential）的操作执行受控，动作空间还提供 CallUser，以便必要时请求用户接管。这道设计与表里明显更低的 ASR 是同时出现的，但表本身不能把功劳单独归给某一个机制：哪怕是与同基座 Qwen3.5 的对比，隔离掉的也是整套训练与防护流程，而不是「受控执行」这一项。要证明这道护栏究竟贡献了多少，需要关掉它再测一遍的消融，论文没有公布这一步。

但把视角拉回开篇那张 OSWorld 2.0 的图，鸿沟还在原地。150 步设置下，27B 的完整完成率只有 2.8%，部分完成率 13.2%，这是论文自报的数字，OSWorld 2.0 主表并不包含它；9B 更惨，0.0% 和 7.5%。巧合的是 OSWorld 2.0 主表里 Qwen 3.7-Plus 的 binary 也是 2.8%。比单点数字更扎心的是 OSWorld 2.0 自己的统计：各家模型的 partial 完成率收敛在 41% 到 54%，binary 只有 8% 到 20%。「做了一大半」和「严格做完」之间的最后一公里，是最难的一公里，也是所有模型集体卡住的地方。OSWorld 2.0

分数要分开看，价值也要分开算。既然长程这道鸿沟还在，这家开源模型真正的价值在哪？下一章收口。

为什么值得关注：一个可验证、可复现的开源底座

判断是：它不是又刷高了几个百分点，而是把「可验证」从数据、训练、评估到安全串成了一条完整链路，并以开源方式整体交付。就本文展示的开源资产而言，这份交付是实打实可拿到的：9B 和 27B 双权重全部开放，评测代码、五个域的一键脚本、覆盖 40 多个中文应用的手机端框架，以及浏览器插件，都直接可用。这意味着「可验证信号」不是一个只能写在论文里的抽象口号，而是一个别人能接着往下推的工程底座。UI-Venus repo

同时也得记住它的自限。官方模型卡里明确写：这些结果并不使有害行为风险归零，部署仍需人工确认与上层防护。UI-Venus-2 模型卡 安全和可用性是一对需要持续权衡的轴，不是一道能一次解完的题。

这家团队半年发一版，每版还配套一个新基准：

节奏本身是一种信号：这个家族在持续迭代，并且每走一步都给自己立一块新的标尺，把能力边界变成可测量的数字。UI-Venus repo

开篇那张报销工作流的图，现在还在原地，长程真实任务依然横在所有模型面前。但以本文展示的工程覆盖度看，围绕它的工具已经齐备：数据、训练、评估、安全，每一环都有可验证、可复现的落点。把「可验证」做成训练的基本盘，是迈向可靠 GUI 智能体最可复制的一步；而那 2.8% 被诚实地标出来，恰恰意味着接下来可以精确地朝着它瞄准。一个人工智能助手敢不敢把一小时的工作交出去，答案不在它能跑多少个基准，而在它能不能在每一步都被核验。

想深入可以读原文：UI-Venus-2 Technical Report — arXiv:2609.00028

参考文献

• UI-Venus-2 Technical Report：https://arxiv.org/abs/2609.00028
• UI-Venus-1.5 Technical Report：https://arxiv.org/abs/2602.09082
• UI-Venus Technical Report: Building High-performance UI Agents with RFT：https://arxiv.org/abs/2508.10833
• OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments：https://arxiv.org/abs/2404.07972
• OSWorld 2.0: Benchmarking Computer Use Agents on Long-Horizon Real-World Tasks：https://arxiv.org/abs/2606.29537
• GUI-Shepherd: Reliable Process Reward and Verification for Long-Sequence GUI Tasks：https://arxiv.org/abs/2509.23738
• Agentic Reward Modeling: Verifying GUI Agent via Progressive Trajectory-Grounded Interaction（VAGEN）：https://arxiv.org/abs/2602.00575
• GUI-R1: A Generalist R1-Style Vision-Language Action Model For GUI Agents：https://arxiv.org/abs/2504.10458
• OS-Harm: A Benchmark for Measuring Safety of Computer Use Agents：https://arxiv.org/abs/2506.14866
• UI-Venus official GitHub repository：https://github.com/inclusionAI/UI-Venus