UI-TARS-2: Advancing GUI Agent with Multi-Turn Reinforcement Learning

1 · 背景:UI-TARS-1 → UI-TARS-2 → 和 ClawGUI 的关系

1.1 UI-TARS 一代的定位

UI-TARS 一代 (arXiv:2501.12326, 2025-01) 已经把"native GUI agent"这件事打了第一锤 — 直接吃截图,直接吐 pyautogui 风格 action,不依赖 a11y tree。1.5 (2025-04) 在此之上加了 RL 后训练,7B 版本权重开源 (HF, Apache 2.0)。一代的核心痛点是:

• cold-start 后 SFT 数据天花板低 — agent-specific 数据稀缺,而通用 vision-language 数据对"长程任务规划"几乎没用。
• 单轮 grounding 收益接近饱和 — ScreenSpot-V2 已经 94.2%,继续推数字意义不大。
• RL 还是后训练阶段,不进入数据回路 — RL 出来的 trajectory 没被回灌进 SFT/CT,形成 one-shot 训练而非持续进化。

1.2 UI-TARS-2 想做什么

UI-TARS-2 的核心论点:GUI agent 应该是"训练 → rollout → 数据回灌 → 再训练"的一个闭环,而不是一次性 finetune 出来的静态模型。它把这套闭环命名为 data flywheel,并配套地把 multi-turn RL 训练 / hybrid GUI+SDK 环境 / 千机级沙箱 三件事补齐 — 这才是 paper 70+ 页的内容。

四个核心声明 (摘自 abstract):

(1) a data flywheel for scalable data generation, (2) a stabilized multi-turn RL framework, (3) a hybrid GUI environment that integrates file systems and terminals, and (4) a unified sandbox platform for large-scale rollouts.

1.3 与 ClawGUI (本系列 #14) 的演化关系

两篇放在一起看非常有意思:

结论:ClawGUI 解决"开源社区谁都能从头训一个 GUI agent",UI-TARS-2 解决"大厂如何把 GUI agent 训到 frontier 水准并产品化";它俩不是竞品,是同一个生态在不同 scale 上的两个切片。ClawGUI 在 §1 的 1.2 表里也把 UI-TARS-2 列为"报数字但 infra 不开源"的代表 — 正是本篇要承认的现实。

2 · 核心方法 · 4 大柱子总览

2.1 柱子 1 · Data Flywheel (可持续数据生成)

这是 UI-TARS-2 最具系统性的贡献,论文 §2.3 + §2.4 专门讲。下面把流程图、各阶段细节、ablation 都补全。

2.1.1 全景流程图

2.1.2 各阶段细节

2.1.3 Validator V(s) 是怎么打分的 — 三类 reward 分类

这是飞轮的核心 — 验证器不通用,三类任务用三种判分 (论文 §2.5.2 / §3.4):

"模型给自己打分"这条路 (用法 #3) 在 paper 里只用了一句"despite imperfection, RL training proved effective"带过 — 这是个值得警惕的循环依赖,但作者强调实测可用。

2.1.4 飞轮的两个聪明点

2.1.5 飞轮效果 ablation — paper 公开了什么、藏了什么

用户最关心的"每个阶段涨了多少"。残酷的真相:paper 没做严格的 stage-by-stage ablation。下面把能找到的所有数字都列出来,以及缺失的部分。

(1) 整套飞轮 vs UI-TARS-1.5(累积收益,非 ablation):

这些是整条流水线 (CT + SFT + RL + flywheel) 的合力,paper 没拆出"如果不用 flywheel 还有几分"。

(2) 唯一一处明确的 stage delta:SFT → RL 的最后一跳

(3) Hybrid GUI+SDK 通道 ablation (这倒是公开了):

(4) Value Pretraining ablation (Figure 10b):

• 有 value pretraining vs 没有,GUI-Browsing 训练过程中 reward持续更高
• 具体数字未给,只有曲线图

(5) ORM (自评判 reward) ablation:

• ORM 本身在 300 条 trace 上 F1 = 83.8
• 没报"如果换 rule-based 或人工 reward 会差多少"

(6) Paper 明确没有报告的:

整体评价:paper 把flywheel 是什么讲得很清楚,把每个组件值多少藏起来不讲。这是大厂 system paper 的常见风格 — 给社区看到"有这件事 + 整体管用",但不给完整的 recipe 让人能精确复现各部分的边际收益。对比 ClawGUI(#14)那种把 PRM ablation、curriculum ablation 都公开报数字的开源风格,UI-TARS-2 这块是闭源更深一层。

2.2 柱子 2 · Stabilized Multi-Turn RL Framework

主体见 §3,这里只点四件关键事:

1. 用 PPO 而不是 GRPO — paper 实证 "PPO consistently outperforms GRPO by a clear margin" 在多轮长 trajectory 下。
2. Decoupled GAE:policy 和 critic 用不同 λ。
3. Length-Adaptive GAE:λpolicy = 1 − 1/(α·l),α=0.05,把长 trajectory 的 advantage 估计误差压下来。
4. Asymmetric Clipping (clip-higher):ε_low 小、ε_high 大,鼓励探索而不压抑梯度。

2.3 柱子 3 · Hybrid GUI Environment (GUI + 文件系统 + 终端)

这是 UI-TARS-2 在概念上最像"agentic computer use"的一步 — agent 不再被锁在屏幕里:

实证收益:同一个模型挂上 SDK 通道,在 BrowseComp-zh 从 32.1% 跳到 50.5%(GUI-only → GUI+SDK),在 BrowseComp-en 从 7.0% 跳到 29.6%。这个 delta 直接说明"不该让 agent 用鼠标做本该 shell 做的事"。

2.4 柱子 4 · Unified Sandbox Platform (统一沙箱)

分两套实现:

这个"重写 timing API 把游戏时间加速"的 trick 我个人觉得很关键 — 游戏 RL 训练的 wall-clock 瓶颈往往不是 GPU forward 而是 env step latency,这一手解决了游戏类 RL 训练的根本问题。

3 · 训练 recipe 细节 — 怎么让 PPO 在多轮长 trajectory 下不崩

3.1 base model 与初始化

对比 1.5-7B 量级的开源版本,UI-TARS-2 主线是大约 33× active params 的跨代跳跃(7B → 23B active),且换成 MoE。

3.2 PPO 主公式 (论文 verbatim)

其中 r_t(θ) = π_θ(o_t|q,o_<t) / π_θold(o_t|q,o_<t) — 标准 importance ratio。关键创新在ε_low ≠ ε_high。

3.3 四件稳定性 trick 详解

(a) Decoupled GAE

传统 GAE 用同一个 λ 估 policy advantage 和 value target;论文把 λ_policy 和 λ_critic 解耦 — policy 那边可以大 λ (低 bias)保探索质量,critic 这边可以小 λ (低 variance)保 value 学得稳。

(b) Length-Adaptive GAE

l 是 trajectory 长度。trajectory 越长 → λ 越接近 1 (越依赖未来 reward);trajectory 越短 → λ 越接近 0 (退化成 TD)。直觉:长 horizon 任务需要更"远视"的 credit assignment。

(c) Value Pretraining

在固定的 policy 输出上预训 value head 直到收敛,再开始联合训练 — 解决"critic 还没学好就被 noisy policy 带偏"的问题。这个 trick 也在 PPO+LLM 的若干工作 (e.g., DeepSeek-R1 路线的反思) 里反复出现。

(d) Asymmetric Clipping (clip-higher)

ε_high > ε_low,允许 policy 在"这一步比 old 更倾向于做对的事"时获得更大的梯度,但在"否定 old 行为"时被限制。和 DAPO 系列 clip-higher 思想一致。

3.4 Reward 设计:可验证 vs 不可验证

3.5 训练 infra (生产侧)

• 异步 server-based inference: rollout 服务独立于 training framework,不互相阻塞。
• Streaming training with partially-filled rollout pools: 不等一个完整 batch,部分到位就开始 update — 避免 long-tail trajectory 拖累整 batch。
• Stateful environments: 跨 tool 调用保留执行上下文,这是和"无状态 web sandbox"最大的区别。

3.6 paper 未公开的部分

• 具体 GPU 数 / 训练 wall-clock / 总 token 数 — 未披露
• data flywheel 跑了几轮 (iteration count) — paper 未公开
• SFT 数据总规模 — paper 未公开,只说 "690 websites for GUI-General"
• Seed-thinking-1.6 详细架构 — 未公开
• RLHF / 安全对齐流程 — paper 没专门章节

4 · 🔍 开源现状 — repo 实地清点

到 2026-05 为止盘点情况(对应 paper 已发布 ~8 个月)。直接 curl 看 repo:

4.1 主仓库 bytedance/UI-TARS

UI-TARS/
├── LICENSE                  # Apache 2.0
├── README.md                # 14.6 KB,主推 1.5,顶部加了一句 UI-TARS-2 发布公告
├── README_v1.md             # 29.3 KB,UI-TARS-1 历史 README
├── README_deploy.md         # deployment guide(主要面向 1.5-7B)
├── README_coordinates.md    # 坐标处理教学(Qwen2.5-VL 绝对坐标的兼容)
├── UI_TARS_paper.pdf        # 35.3 MB,1 代论文
├── UI_TARS_paper_preview.pdf
├── codes/
│   ├── ui_tars/             # 一个 pip 可装的小工具包 (`pip install ui-tars`)
│   │   ├── action_parser.py    # 解析 "Action: click(start_box=...)" 字符串
│   │   ├── prompt.py           # COMPUTER_USE / MOBILE_USE / GROUNDING 三套 prompt 模板
│   │   └── ...
│   └── tests/
├── data/                    # 几个示例图(不是训练数据集)
└── figures/

关键事实:

• ✓ License: Apache 2.0 — 干净,商用 OK。
• ✗ 训练代码 — repo 里没有任何训练 / RL trainer / 沙箱代码。
• ✗ 沙箱 / VM Manager — paper §4 那套千机集群、QPS 调度、生命周期管理 — 完全没开源。
• ✗ Data flywheel pipeline — V(s) 验证器、回灌脚本、数据筛选 — 完全没开源。
• ✓ 推理工具 — ui-tars pip 包提供 action 字符串 ↔ pyautogui code 的双向转换,对接 deploy 实际有用。

4.2 bytedance/UI-TARS-desktop

这是一个独立的 desktop harness 项目,主要是 TypeScript / Electron 前端:

UI-TARS-desktop/
├── multimodal/        # 多模态 client SDK (TS),配合任意 UI-TARS 模型 backend
├── packages/          # monorepo,electron app / agent runtime / utils
├── apps/              # demo apps
├── .changeset / .husky / .lintstagedrc.mjs  # 标准 JS 工程化
└── ...

这套是"把 UI-TARS 跑在本地电脑上的 desktop 客户端",和 paper 描述的训练侧沙箱完全是两件事 — 不要混淆。

4.3 HuggingFace 模型清单 (ByteDance-Seed)

查询 HF org 现存 UI-TARS 系列模型:

HF 上有一个 公开 issue #213 由 HuggingFace 的 Niels Rogge 提交,请求 ByteDance 把 1.5 完整版和 UI-TARS-2 放到 HF — issue 至本笔记写作时仍 open,未获官方回应。

4.4 数据集 / 沙箱 / Flywheel 数据

• ✗ Cold-start CT 数据 — 内部 + 抓取数据混合,未释放。
• ✗ SFT 标注集 (690 网站) — 未释放。
• ✗ RL trajectory 数据 — 未释放。
• ✗ 沙箱镜像 / Dockerfile — 未释放。
• ✗ Game environment 15 款 HTML5 游戏的 wrapper — 未释放(其中部分是 poki.com 第三方游戏,license 上也无法直接重发)。

4.5 "开源度"评分表

综合评分: 三件大事(权重 / 训练代码 / 沙箱)主线版本均未开源 — 把 UI-TARS-2 当 "可复现 baseline" 是 不现实 的;只能当 SOTA 数字参照系 和 架构 / 方法借鉴对象。要在自己环境下复现 multi-turn RL on GUI,目前更现实的选择仍是ClawGUI / AgentGym-RL / verl-agent。

5 · 实验结果与 baseline 对比

5.1 Computer Use (桌面操作)

SWE-Bench Verified 上 Opus 仍领先 3.8 个绝对点 — paper 老实承认这一点没让数字"看起来更漂亮"。Terminal-Bench 评估了 80 个任务中的 75 个(5 个因兼容性跳过)。

5.2 Browser Use (浏览器)

BrowseComp-en 上 OpenAI o3 仍领先(49.7 vs 29.6) — 但 o3 是纯文本 deep-research路径,UI-TARS-2 是真正用浏览器。两条路径的对照本身就是看点。

5.3 Mobile Use

5.4 Game (15 款 HTML5 + LMGame-Bench)

5.5 Grounding (沿用 1.5 的强势)

Grounding capability 在 paper 中没占大篇幅 — 1.5-7B 已经在 ScreenSpot-V2 报到 94.2,在 ScreenSpotPro 61.6;UI-TARS-2 没刻意推这一项,显示研发重心已经从 grounding 转向 multi-step planning。

5.6 量化 (W4A8)

对生产部署关键 — paper 唯一公开的量化对照。

6 · 局限 / 未解决问题

6.1 Paper 自己承认的

• BrowseComp-en 仍落后 o3 20 个点 — GUI-based 路径在纯检索类任务上对纯文本 o3 仍处下风。
• SWE-Bench Verified 落后 Claude-4-Opus 3.8 点 — 复杂软件工程任务上仍未追平专门的 coding agent。
• 样本效率 / training cost — paper 没披露 GPU 数 / 训练 wall-clock,我们无从评估"这套 recipe 在 100 卡 / 10 卡 集群上是否还 work"。

6.2 笔者(我)的额外质疑

• "PPO 打败 GRPO" 的结论可推广吗? — paper 报的是千机沙箱 + 230B MoE + 多轮长 trajectory 这个非常具体的设置。换到 7B / 单卡 / 短 trajectory 的学术环境,结论可能反向(ClawGUI / MAI-UI 等用 GRPO 系一族仍跑得很好)。不要把 "use PPO" 当成普适建议。
• F1 = 83.8 的 generative ORM 怎么训的? — paper 提了一句结果,但训练数据 / loss / 监督信号没展开。这一手如果工作,意味着"同一个 base model 既当 actor 又当 reward model" 是可行的,潜在影响很大,但目前细节缺失。
• data flywheel 的稳定性 — V(s)=1 的数据被回灌进 SFT,V(s)=0 的回灌进 CT;但 paper 没分析"iteration t 时 V 的精度漂移会不会让数据 quality 单调劣化"。这是 self-distill 类方法的经典陷阱。
• 无 safety / RLHF 章节 — 一个能跨 OS / 共享文件系统 / 执行 shell 命令的 agent,paper 完全没讨论权限边界、CAPTCHA bypass、prompt injection。1 代 README 提过 "extensive internal safety evaluations are underway",但本篇没把对应章节放进 paper。

7 · 与 ClawGUI (#14) 的并排对比

两篇放一起读最大的收获是看清"RL 算法的选择强烈依赖 scale 和 trajectory 长度"。同样训 GUI agent,2B 量级 + 短 mobile trajectory 时 GRPO 系赢,230B + 长多轮 trajectory 时 PPO 系赢 — 这和 RL 框架横评 (#19 in models/) 里观察到的"algorithm choice depends on infra constraints"完全一致。

8 · 记忆点

1. "GUI agent" 的研发重心已经从 grounding 转移到 multi-turn planning + tool integration。ScreenSpot-V2 已经 94.2,grounding 不再是瓶颈。
2. 多轮长 trajectory 下 PPO 反胜 GRPO — 这个观察值得被 RL 框架 paper 反复引用,前提是"多轮 + 大 scale + 状态化环境"。
3. GUI + SDK 混合通道带来巨大收益 (BrowseComp-en 7.0 → 29.6,4× 提升)。"不要让 agent 用鼠标做本该 shell 做的事"。
4. 用 actor 自己当 generative ORM 是 paper 里一个被低调处理但非常有意思的点 — F1 = 83.8 已经接近可用,但训练细节未公开,值得追踪。
5. 千机级沙箱的 timing API 重写 让游戏 RL 训练的 wall-clock 可控 — 这是 system 侧最实用的一个 idea。
6. 开源 ≠ system paper 必备 — UI-TARS-2 把 paper 写得比代码还细,但代码/权重没放,这是大厂 system report 的常见姿态。读者要明白"论文里的 4 大柱子是工艺指南,不是开箱即用的工具箱"。