蚂蚁集团把GUI智能体做到了手机、网页、电脑三端全能 Chinese original
你有没有想过这样一个场景：你对着手机说一句话,"帮我在淘宝上找一件蓝色牛仔裤,价格在24到52美元之间,女装S码"，然后手机自己打开APP、自己搜索、自己筛选、自己下单，全程你只是在旁边看着。
这不是科幻电影，这是蚂蚁集团刚刚发布的UI-Venus-2想要做到的事情。但真正让我停下来多看两眼的，不是这个愿景本身（这个愿景大家都想要），而是他们在解决这件事的过程中，撞上的一堵墙——一堵几乎所有做GUI智能体的团队都撞过的墙。
这堵墙是什么？先说个反直觉的事实：让AI在电脑上"点点点"完成任务，听起来是个纯技术问题，模型越强、参数越大，效果应该越好。但UI-Venus-2团队发现，真正卡住他们的不是模型不够聪明，而是训练数据本身就是脏的、假的、不可信的。你拿垃圾数据喂再聪明的大脑，它也学不出真本事。
这篇论文最有意思的地方，就是它把大部分篇幅花在了"怎么让数据变得可信"这件事上，而不是"怎么把模型调得更大"。这和大多数AI论文的叙事逻辑完全相反。
这件事到底难在哪里
*GUI智能体*：能够像人一样看懂屏幕、点击按钮、输入文字、完成任务的AI系统，全称Graphical User Interface Agent。
先说说这个领域已经卡在哪儿了。在UI-Venus-2之前，蚂蚁自己的UI-Venus和UI-Venus-1.5已经做出了不错的成绩，但那套框架主要局限在手机和网页两个场景，桌面操作系统基本没有覆盖。而且更麻烦的是，用来训练和评测这些智能体的任务，很多是"攒"出来的，用几十个固定的APP、固定的任务模板反复刷分。
这就好比你想考验一个新司机的驾驶水平，但你只让他在同一条封闭测试跑道上开了一千次。他确实能把这条路开得又快又稳，可是一旦上了真实的城市道路，遇到没见过的路口、突然窜出来的行人，他立刻就露怯了。UI-Venus-2团队引用的VenusBench-Mobile和OSWorld这两个"真实场景"评测集恰恰证明了这一点：那些在传统封闭benchmark上表现漂亮的模型，一到用户真实使用场景就现了原形。
论文里给出了具体数字。在VenusBench-Mobile这个更贴近真实用户使用习惯的评测上，当时公认最强的通用大模型Claude-Opus-4.6也只能拿到36.5分，Kimi-K2.6是31.2分，Qwen3.6-27B更是只有28分。这些都是业界顶尖的大模型，成绩却普遍在30分上下徘徊，说明这条赛道远没有到"卷不动了"的地步，反而问题堆积如山。
那问题到底出在哪三个地方？论文把它归纳得很清楚：环境覆盖不够广、任务生成不靠谱、验证机制不可信。这三件事互相咬合，缺一不可。你环境不够多，模型见识就窄；任务造得随便，模型学的就是错的经验；验证机制一松懈，强化学习的奖励信号就成了空中楼阁，模型很可能学会了"糊弄评委"而不是"真正做对事情"。
环境扩容：让智能体见更大的世面
*多语言移动端环境*：指覆盖不同语言、不同地区应用生态的手机APP集合，而不是只测试单一语言市场的软件。
UI-Venus-2做的第一件事，是把可交互的环境池子从几十个APP扩大到170多个多语言移动应用，同时首次把桌面操作系统也纳入进来。中文APP覆盖100多个，英文APP覆盖70多个，网页环境更是超过4000个域名，横跨19个类别。
这里有个细节值得琢磨。团队没有随便抓一堆网站就往里塞，而是先用自动化的可访问性检查筛掉打不开、加载慢的网站，再用Kimi 2.6模型给每个网站打分,考察它的动态性、可交互性、内容丰富度和视觉质量。这就跟招聘一样，你不能来者不拒把简历投递箱里所有人都叫来面试，得先筛掉明显不合适的，再针对性地深入考察。如果不这么做会怎样？答案很直接：模型会在大量低质量、几乎没有交互性的静态网页上"练废"，学到的是一堆没用的模式，反而稀释了真正有价值的训练信号。
桌面端的建设则是从零开始的。之前的UI-Venus系列压根没碰过操作系统级别的任务，这次团队专门构建了TaskSpec这套机制,把每个桌面任务打包成包含系统快照、初始化操作、依赖文件和结果检验器的完整包裹。
*TaskSpec*：一种任务规格描述，把桌面操作任务需要的初始状态、执行步骤、判定标准都打包成一个可重复执行、可验证的单元。
为什么要这么较真？因为桌面环境比手机复杂太多了。手机上你点开一个APP，状态基本是干净的；但电脑桌面上，你可能需要先打开PPT、再打开浏览器查资料、中途还要切到Excel整理数据，任务链条一长，环境状态就变得极其复杂，出错的地方也多得多。论文里专门提到，针对长任务他们做了"分层切割"，把一个大任务拆成几个子目标，每个子目标独立验证，通过了才把这个"验证过的状态"传给下一段继续执行，跳过之前失败的部分。这就好比接力跑，每一棒都要交接顺畅、确认无误，而不是等到最后冲线才发现前面某一棒早就掉了棒。
任务生成：deep-research式的能力挖掘
光有环境还不够，你得给这些环境里塞进靠谱的任务。这是第二个大问题。
UI-Venus-2用了一套叫做"深度研究"的任务生成管线,核心思路是先搞清楚一个APP到底能做什么，再据此生成任务，而不是拍脑袋想任务。
具体来说，团队会先从官方文档、帮助中心、用户论坛、历史任务记录里搜集证据，整理出一份"能力目录"，里面记录着每个功能的调用方式、所需前提条件、兼容的其他功能，以及当前的任务覆盖情况。这份目录不是写完就束之高阁的静态文件,它会随着实际执行结果不断更新。模型跑任务的时候，无论成功还是失败，反馈信息都会写回这份目录，下一轮任务生成就会根据这些真实反馈调整采样策略，主动去覆盖那些还没探索过的功能和之前失败过的场景。
这套逻辑其实很像一个新入职的产品经理熟悉公司产品的过程。他不会一上来就凭空想需求，而是先啃说明书、看用户反馈、翻历史工单，搞清楚产品到底能干什么、用户常在哪里卡壳，然后才有针对性地设计新功能测试。如果反过来，产品经理凭空拍脑袋设计任务，那大概率会出现两种情况:要么任务压根实现不了(功能根本不存在)，要么任务模糊到没法判断对错。论文里专门提到了"validity gate"这道关卡，会直接拒绝那些涉及不支持的功能、目标模糊、缺少依赖或者结果无法验证的任务，只有真正靠谱的任务才能进入下一阶段的执行采集环节。
验证机制:让强化学习的奖励信号不再骗人
这是我读这篇论文时觉得最有意思的部分，因为它触及了一个所有做强化学习的人都要面对的根本难题:你的奖励信号靠不靠谱，直接决定了你训练出来的模型是真聪明还是假聪明。
*强化学习(RL)*：一种让模型通过"试错+反馈"来自我优化的训练方式，模型做对了给奖励，做错了给惩罚，反复调整策略。
传统做法是看任务最后有没有成功,一个二元的对错判断。但这种方式对GUI智能体来说太粗糙了。想象一个任务是"在指定群组里发布一条内容"，模型如果进错了群、发错了内容，但至少尝试进入了正确流程，这和它压根没有任何有效动作,难道应该给一样的差评吗？显然不该。
UI-Venus-2设计了两层验证体系。第一层叫轨迹级验证(SGV,Semantic Guided Verification)，第二层叫样本级验证。
*语义引导验证(SGV)*：一种用视觉语言模型充当"裁判"，判断整个执行轨迹是否语义上完成了任务目标的评估方法，而不是简单看最终画面对不对。
SGV是怎么工作的？它先从任务目标里提取几个"关键检查点"。还是拿刚才发群消息的例子来说，关键点可能是:进入正确的群、填写指定标题和正文、确认发布成功。SGV会把整条轨迹切成固定大小的窗口，逐个窗口判断哪些关键点被满足了，最后综合判断给出四种结论之一:完成、部分完成、任务本身不可行、彻底失败。如果一个轨迹完成了前两个关键点但在最后一步耗尽了步数预算，它会被标记成"部分完成"而不是"失败"，因为这确实证明了模型有实质性的进展，不该一棍子打死。
这套分级机制带来的好处是数据能被更精细地"分诊"。完成的轨迹进入高质量样本池，部分完成的进入复查队列做截断或续写修复，不可行的用来完善任务可行性规则，失败的则帮助团队分辨到底是任务设计有问题、环境不稳定，还是模型能力真的不行。
如果不做这种分级会怎样？后果是显而易见的:所有失败案例被一刀切地当成负样本，模型学不到"我做对了一半"这种细腻的信号,强化学习的效率会大打折扣，甚至可能让模型学会一些投机取巧的行为,比如故意在最后一步卡住来"回避"被判定为彻底失败(这就是论文反复提到的reward hacking，也就是奖励作弊)。
样本级验证则更进一步，它在动作执行之前就做判断,只根据当前截图、模型声明要执行的动作类型和目标、模型的推理文字、任务目标本身来评估这个动作对不对。这样设计的好处是能实现实时干预，而且不会把动作质量和"这个页面后续跳转是否受外部因素影响"这类无关变量混在一起。
每一步动作会被分成四类:正确、探索性尝试、无效、错误。这个分类逻辑也很讲究,比如一个模型明确表达了"我不太确定这里对不对,但我先试试"，然后这个尝试确实改变了页面状态,那这属于有理有据的探索性尝试,不该和瞎点乱按的"无效"动作混为一谈,也不该和逻辑明显不通的"错误"动作画等号。
三阶段训练管线：从打基础到融会贯通
搞定了环境、任务和验证之后，接下来才是真正的模型训练。UI-Venus-2的训练分成三个阶段。
第一阶段是大规模多模态中期训练(mid-training)，用海量的手机、网页、操作系统导航数据给模型打底子，让它先具备基本的GUI理解能力。
第二阶段是离线强化学习，针对不同任务类型分别优化。手机、操作系统、网页这类导航任务用步骤级别的RL轨迹来训练，让模型学会在每一步做出符合当前状态的正确决策。CAPTCHA和视觉定位(grounding)这两类任务则用另一套思路,团队开发了一个程序化合成框架,把验证过的验证码实例和定位目标嵌入到逼真的网页和APP背景界面里，这样就能拿到可控难度、精确标注的训练数据，而这种密集监督是自然采集的真实交互数据很难提供的。
*视觉定位(Grounding)*：指模型准确找到屏幕上某个特定按钮、图标或文字区域的能力，是GUI智能体最基础也最容易出错的技能之一。
第三阶段叫多教师在线策略蒸馏(MOPD,Multi-teacher On-policy Distillation)，这是整篇论文里技术含量最高、也是最值得细讲的一部分。
MOPD：把散装专家拧成一股绳
经过前两个阶段，团队实际上得到了好几个"专才模型"：一个擅长视觉定位，一个擅长验证码，几个分别擅长手机、网页、电脑操作。但真正要交付使用的是一个统一模型，它得同时具备这些能力，而且相互之间不能打架。
直接把这些专才模型的参数粗暴合并，往往效果很差,这就跟把几个各有所长的专家硬凑成一个团队，却不给他们磨合的机会，结果反而互相拖后腿。MOPD的做法是让这些教师模型给学生模型自己生成的轨迹打分,而不是让教师们各说各话、互不相干地生成答案再拼接。
但即便如此，普通的蒸馏方式还有个问题:它对整个回答的每个字都一视同仁地施加监督，不管这段文字是模型的思考过程还是最终要执行的具体动作。这对GUI智能体来说很不合理，因为真正决定环境会不会发生变化的，只有那个具体的动作，模型前面写了再多分析推理，如果最后一步的动作坐标点错了、动作类型选错了，整个尝试照样白费。
*动作类型与参数*：GUI智能体输出的每个动作都由"做什么"(比如点击、拖拽、输入文字)和"具体怎么做"(比如点击哪个坐标、输入什么内容)两部分组成，前者错了后者就没有意义。
所以团队设计了一套"结构化动作感知蒸馏"。逻辑是这样的:如果模型预测的完整动作是对的，就不需要额外纠正，蒸馏信号可以减弱;如果动作类型对了但具体参数错了(比如知道要点击，但点错了坐标)，就加强对参数部分的监督;如果连动作类型都错了(比如该滑动却点击了)，那这条动作后面的参数部分讨论已经没有意义了，直接屏蔽掉,只重点纠正动作类型本身。
这就像老师批改作文，如果学生审题正确、论点正确，只是某个细节表达不够精准，老师会在那个细节上多花笔墨修改;但如果学生一开始就跑题了,写的是完全不相关的内容,老师根本不会去纠结这篇跑题作文里的用词是否优美,而是直接把重点放在"你审题错了"这件事上。
除此之外，教师模型在打分时还会额外拿到一个"提示"，告诉它正确的动作类型是什么(注意这个提示只给教师，不给学生，学生在推理阶段完全看不到)，这样教师能更精准地评判学生生成的每个token。这个设计挺巧妙的:相当于给阅卷老师一份标准答案参考，但考生本人是看不到这份参考的,考试的公平性没有被破坏，但评分的精准度提升了。
实测数据：全平台碾压式表现
说了这么多设计理念，最终还是要看数字说话。
在手机端，UI-Venus-2-27B在VenusBench-Mobile上拿到48.7分，把之前最强的Claude-Opus-4.6(36.5分)甩开了12.2分。在AndroidWorld这个相对成熟、已经接近饱和的评测上，27B模型也拿下84.0分，比之前最好的UI-Venus-1.5-30B-A3B高出6.4分。
网页端的表现更为亮眼。在WebVoyager上，27B模型拿到93.4分，超过GPT-5(SoM)的90.6分;在长程跨网站任务Odysseys上，27B模型的平均评分达到80.4，比Claude-Opus-4.6的68.9分高出11.5分之多，"完美完成率"更是66.3对44.5，几乎是碾压级别的领先。
桌面端方面，UI-Venus-2-27B在DeskCraft上拿到55.5分，比Kimi-K2.6的41.4分高出14.1个百分点。不过在OSWorld-Verified上，27B模型的80.5分略低于Claude-Opus-4.8的83.4分,这也说明桌面操作系统这个战场依然是个硬骨头，即便是顶级模型也还有明显提升空间。
CAPTCHA解决能力上，差距最为惊人。在自建的VenusBench-CAPTCHA评测上，27B模型拿到79.9分，而最强的通用模型Qwen3.6-27B只有53.0分，差了将近27个百分点。在专门考察多重视觉推理能力的NextGen-CAPTCHAs上,差距更是拉大到34.1个百分点。这说明通用大模型在处理需要计数、旋转、遮挡判断这类组合式视觉推理任务时，天然就有短板，而专门针对这类任务优化过的模型能明显吃到红利。
安全性方面的数据同样值得关注。在OSBlind这个专门测试"看似无害指令暗藏风险"的评测上，所有通用大模型的攻击成功率都高达79.4%到93.6%,意味着这些模型绝大多数情况下会被表面无害的指令误导去执行有害操作。而UI-Venus-2把这个数字压到了47.9%左右，几乎减半。这提醒我们一件事:模型越能干，越需要有意识地训练它识别"看起来没问题、实际藏着坑"的场景，能力和安全性从来不是天然正相关的。
写在后面
读完这篇论文，最让我意外的一点是,它花了大量篇幅在讲"怎么造靠谱的数据"和"怎么设计不会骗自己的验证机制"，而不是炫耀模型架构本身有多花哨。这其实透露了一个信号:GUI智能体这个赛道走到现在，纯粹堆参数、堆算力的边际收益已经不明显了，真正卡脖子的是数据质量和验证信任度。
论文里有个细节我反复看了好几遍,就是那个"trace-level"和"sample-level"两层验证的设计。它本质上是在解决一个哲学味很浓的问题:当一个AI说"我完成了"的时候，你凭什么相信它?人类社会处理这个问题的方式,靠制度、靠第三方审计、靠交叉验证,而这篇论文其实是把类似的逻辑搬到了AI训练里,用多个模型投票、用视觉关键点比对来防止"自说自话"。这种思路未来大概率会延伸到更多需要AI自我报告结果的场景里,不只是GUI操作。
还有一点值得琢磨:VenusBench-CAPTCHA上27B和9B模型只差1.8分，但在OSWorld 2.0这种极端长程复杂任务上，两者的二元准确率差距是0和2.8,看起来很小,但考虑到这个基准的整体成功率都极低(最强的GPT-5.5也只有13.0%)，这说明当任务链条足够长、足够复杂时，参数量的边际效应会重新变得重要。小模型能在短任务上追平大模型，但长程任务依然是真正的分水岭。
这大概也是这个领域接下来最值得追问的问题:当任务从"点几下鼠标"进化到"完成一整套需要几十上百步、跨越多个软件的工作流"时，我们现在这套验证和训练体系，还能撑多久？
Q&A
Q1：UI-Venus-2支持哪些使用环境？
A：UI-Venus-2覆盖移动端、网页端和桌面操作系统三大场景，其中移动端支持170多个多语言应用(100多个中文APP和70多个英文APP)，网页端覆盖4000多个域名，桌面端首次纳入了40多个应用的操作系统级任务。
Q2：UI-Venus-2和之前的UI-Venus有什么区别？
A：最大的区别是新增了桌面操作系统能力，UI-Venus和UI-Venus-1.5只专注手机和网页场景。同时UI-Venus-2引入了更严谨的两层验证机制(轨迹级和样本级)以及多教师蒸馏训练法，让强化学习的奖励信号更可信，模型能力也更全面。
Q3：UI-Venus-2在解决验证码方面表现如何？
A：表现非常突出。在自建的VenusBench-CAPTCHA评测上，27B版本拿到79.9分，比最强的通用大模型Qwen3.6-27B(53.0分)高出近27个百分点，尤其在需要计数、旋转、遮挡判断等复杂视觉推理的验证码类型上优势更加明显。