一个失败的订餐
想象这样一个场景。
你让手机上的 AI 助手帮你订一份外卖。它打开了美团，搜索了"黄焖鸡"，点击了第一家店，加了三份米饭——然后卡住了。它不知道该选"微辣"还是"中辣"，因为页面上有两个辣度选项，它随机选了一个，结果选成了"变态辣"。你收到外卖时，三份变态辣黄焖鸡让你怀疑人生。
这不是虚构。这是 2025 年 GUI Agent 的真实水平。在 VenusBench-Mobile 上，最强的开源模型 UI-Venus-1.5-8B 的成功率只有 16.1%。闭源模型 Claude Opus 4.6 也只有 36.5%。
问题出在哪里？
不是模型不够大。不是训练数据不够多。而是整个范式有问题——GUI Agent 被当成"下一个动作预测"任务来训练，但真实世界的 GUI 交互不是预测问题，是验证问题。
arXiv:2609.00028 这篇 UI-Venus-2 技术报告，提出了一种根本性的范式转变：从"预测下一个动作"到"闭环验证每一步"。结果？UI-Venus-2-27B 在 VenusBench-Mobile 上达到 48.7%，在 MobileGym 上达到 60.5%，全面超越 Seed-2.0-Pro、GPT-5.6-Sol、Kimi-K3 等闭源大模型。
旧范式的根本缺陷
先说清楚旧范式为什么不行。
当前主流 GUI Agent 的训练流程是：收集一批人工标注的 GUI 操作轨迹（截图 + 动作），用监督微调（SFT）训练模型。模型学到的是"看到这个截图，应该输出这个动作"。
这个范式有三个致命缺陷：
缺陷一：动作类型对，参数错。 模型知道该点击，但点错了位置。在 UI-Venus-1.5 的错误分析中，37% 的失败是"动作类型正确但参数错误"——该点"确认"按钮，点到了"取消"按钮。SFT 把动作类型和参数当成一个整体来学，但它们的难度完全不同。动作类型是离散分类（点击/滑动/输入），参数是连续回归（坐标 x,y）。混在一起学，模型在参数上的精度永远上不去。
缺陷二：轨迹级正确 ≠ 步骤级正确。 一条人工标注的轨迹有 20 步，其中 19 步是对的，1 步是错的。SFT 把这条轨迹当成正样本，模型学到的 1 步错误也被强化了。在长轨迹任务中（如 MobileWorld 的跨应用任务），这种"一步错步步错"的累积效应会让成功率指数衰减。
缺陷三：benchmark 过拟合。 现有 GUI benchmark（AndroidWorld、MobileGym）都是"app 中心"的——在 10-20 个 app 上测试。模型在这些 app 上表现很好，换一个没见过的 app 就崩了。这不是泛化，是记忆。
UI-Venus-2 的三层架构
UI-Venus-2 的核心创新是三层架构：规模化环境 → 闭环验证 → 结构化蒸馏。
第一层：规模化环境
UI-Venus-2 的训练环境覆盖了 170+ 个移动应用（中文 100+，英文 70+）、动态网站、完整桌面操作系统。这不是"多几个 app"的问题，而是"环境多样性"的问题。
关键洞察：GUI Agent 的泛化能力不取决于模型大小，取决于环境多样性。在 10 个 app 上训练的 27B 模型，不如在 170 个 app 上训练的 9B 模型。这和 LLM 的 scaling law 不同——LLM 是"数据越多越好"，GUI Agent 是"环境越多样越好"。
但环境多了，任务怎么生成？人工标注 170 个 app 的操作轨迹成本不可承受。UI-Venus-2 用了一种"功能驱动"的自动任务生成：先解析每个 app 的 UI 树结构，找到所有可交互元素，然后基于元素的功能语义生成任务。比如发现一个"提交订单"按钮，就生成"完成下单"任务；发现一个"搜索框"，就生成"搜索 XXX"任务。
第二层：闭环验证
这是 UI-Venus-2 最核心的创新。
传统 GUI Agent 的训练信号是"人工标注的动作"。但人工标注有两个问题：一是成本高，二是"人工标注的动作不一定对"——标注者可能点错按钮，或者选了次优路径。
UI-Venus-2 用"视觉关键点验证"替代人工标注：
1. 轨迹级验证：每条训练轨迹在执行后被自动验证。系统用视觉模型提取执行前后的截图差异，检查是否符合任务预期。比如任务是"删除某条消息"，执行后截图里那条消息消失了，验证通过；如果消息还在，验证失败，这条轨迹被丢弃。
2. 样本级验证：对每条通过轨迹级验证的样本，进一步检查动作参数的精度。比如点击动作，检查点击坐标是否在目标元素的 bounding box 内。如果点击到了错误的位置（即使最终结果对了——比如点到了按钮的边缘），样本被标记为"低质量"，降权使用。
3. 动作感知验证：不同动作类型有不同的验证标准。点击动作验证坐标精度，滑动动作验证方向和距离，输入动作验证文本内容。这种"分类型验证"比统一验证更精确。
这套验证机制的效果是：训练数据中的"假正例"（看起来对但实际错的轨迹）被大幅过滤。在消融实验中，去掉轨迹级验证，模型成功率下降 8.3%；去掉样本级验证，下降 5.1%。
第三层：结构化蒸馏
UI-Venus-2 的训练流程分三阶段：
阶段一：中段训练（mid-training）。 在大规模 GUI 轨迹数据上做 SFT，建立基础能力。
阶段二：离线强化学习。 用奖励模型（基于验证机制的反馈）做 RL，优化轨迹级成功率。
阶段三：多教师在线策略蒸馏（MOPD）。 这是最创新的部分。
传统蒸馏是"一个老师教一个学生"。UI-Venus-2 用"多个领域专家老师"教一个学生。具体来说：
- 对移动端任务，用一个在移动数据上微调的老师模型。
- 对桌面端任务，用另一个在桌面数据上微调的老师模型。
- 对 CAPTCHA 任务，用第三个在验证码数据上微调的老师模型。
Â_t^hint = sg[log π_Td(y_t | P_T(x, z*), y 其中 z* 是正确动作类型（作为提示给老师，但不给学生）。这个设计很巧妙：老师知道"应该做什么类型的动作"，学生不知道。老师用这个额外信息来评估学生的 token 是否走在正确轨道上。 关键创新：动作类型和动作参数被分开蒸馏。动作类型用分类损失（cross-entropy），动作参数用回归损失（MSE）。这种"分类型监督"让模型在动作类型上的准确率和参数上的精度都大幅提升。结果：全面超越
UI-Venus-2 的结果令人印象深刻：
| Benchmark | UI-Venus-2-27B | 前最强 | 提升 |
|---|---|---|---|
| MobileGym | 60.5% | 52.0% (Seed-2.0-Pro) | +8.5 |
| VenusBench-Mobile | 48.7% | 36.5% (Claude Opus 4.6) | +12.2 |
| AndroidWorld | 84.0% | 77.6% (UI-Venus-1.5-30B) | +6.4 |
| MobileWorld (50步) | 76.1% | 82.1% (Qwen-UI-Agent-27B) | -6.0 |
| KnowUBench | 59.7% | 51.6% (Seed-2.0-Pro) | +8.1 |
| MemGUI | 70.3% | 65.6% (Seed-2.0-Pro) | +4.7 |
但更值得关注的是 VenusBench-Mobile 上的 12.2% 提升。VenusBench-Mobile 是一个"用户中心"的 benchmark——任务来自真实用户的日常需求，不是"测试用"的。在这个 benchmark 上超越 Claude Opus 4.6 达 12.2%，说明 UI-Venus-2 不是在刷分，而是在解决真实问题。
CAPTCHA：从"孤立任务"到"集成能力"
UI-Venus-2 还有一个被低估的创新：把 CAPTCHA 解决能力集成到通用 GUI Agent 中。
传统做法把 CAPTCHA 当成独立的视觉推理任务，用专门的模型解决。UI-Venus-2 把它当成 GUI 交互的一部分——CAPTCHA 本质上就是"点击特定位置"、"拖动滑块"、"按顺序点击"这些 GUI 操作的组合。
在 VenusBench-CAPTCHA 上，UI-Venus-2-27B 达到 73.2% 的成功率，远超专门模型。这个结果说明：当你把 GUI Agent 做得足够好，CAPTCHA 自然就解决了。反过来不成立——把 CAPTCHA 做好，不等于 GUI Agent 能力强。
这个洞察对 Agent 工程有深远意义：很多"特殊任务"其实是"通用能力"的子集。与其为每个特殊任务训练专门模型，不如把通用能力做到足够好。
深层启示：验证比预测更重要
UI-Venus-2 的成功背后有一个深层洞察：在真实世界的交互任务中，验证比预测更重要。
传统 GUI Agent 的范式是"预测下一个动作"——看到截图，预测动作。这个范式假设"预测准了就够了"。但真实世界不是这样——预测准了不代表执行对了，执行对了不代表结果对了。
UI-Venus-2 的闭环验证机制本质上是在说：不要相信预测，要验证执行。每一步执行后都检查结果是否符合预期，不符合就修正。这和人类操作手机的方式一致——你点击一个按钮后会看一眼页面是否跳转，跳转对了才继续。
这个洞察和 AI 安全领域的"判断-闸门解耦"问题有深层联系。LLM 内部的判断模块和行动模块是分离的——模型 90% 能正确判断"这不可预测"，但行动闸门不咨询判断模块。UI-Venus-2 的验证机制本质上是在判断和行动之间加了一个"咨询步骤"——执行前先验证，执行后再验证。
从更广的视角看，这指向一种新的 Agent 架构范式：不是"感知→决策→执行"的线性流水线，而是"感知→决策→验证→执行→验证"的闭环回路。在这个回路中，验证不是可选的"质量检查"，而是决策的一部分。
UI-Venus-2 不是终点。48.7% 的成功率意味着还有 51.3% 的任务失败。但它指明了方向：规模化环境、闭环验证、结构化蒸馏这三板斧，比单纯堆模型大小更有效。
下次你看到 GUI Agent 的论文，不要只看模型多大、benchmark 多高。问一句：它的验证机制是什么？ 如果答不上来，那它的"成功率"可能只是"预测准确率"，不是"真实任务完成率"。
---
论文信息：UI-Venus Team. "UI-Venus-2 Technical Report." arXiv:2609.00028. 代码开源：https://github.com/inclusionAI/UI-Venus