论文阅读 - GUI 智能体

Wed, 13 May 2026 00:00:00 +0000

我们延续着 Agentic RL 的话题, 之前的博客中我们已经介绍了 Agentic RL 的一些基本概念和方法, 以及一些相关的论文. 由于 Agentic RL 的应用领域非常广泛, 包括了很多不同的任务和环境, 这里围绕综述 [] Unknown-material 着重讨论一下 GUI Agent.

Native GUI Agent

字节的 UI-TARS [] Unknown-material 是一个专门针对 GUI 交互的智能体. 作为一个 native 的 GUI Agent, 论文明确强调 UI-TARS 不依赖 HTML、accessibility tree 或人工写的多模块流程. GUI native model 虽然更理想, 但缺少大规模高质量 GUI 数据, 尤其缺少把感知、推理、记忆、动作串起来的完整交互轨迹

核心框架

UI-TARS 的 pipeline 并不特别, 基本上沿用的还是正常 Agentic RL 的框架.

算法UI-TARS-GUI-Rollout 输入 > 任务指令 $I$, GUI 环境 $\mathcal{E}$, UI-TARS policy $\pi_\theta$, 最大交互步数 $T$, 最近截图窗口大小 $m$, 统一动作空间 $\mathcal{A}$. 输出 > 任务完成结果 $r$, 执行轨迹 $\tau$. 初始化 GUI 环境, 截图和交互历史： $$ s_0=\mathcal{E}.\mathrm{reset}(I) $$ $$ o_0=\mathcal{E}.\mathrm{screenshot}(s_0) $$ $$ H_0=\emptyset,\quad \tau=\emptyset $$ 构造模型输入： $$ h_t=\mathrm{Serialize} \left( I, H_t, o_{\max(0,t-m+1):t} \right) $$ 其中 $H_t$ 包含历史 Thought、Action 和必要的状态摘要. UI-TARS 生成下一步： $$ (z_t,a_t)\sim \pi_\theta(\cdot \mid h_t) $$ 其中, $z_t$ 是 thought, $a_t \in \mathcal{A}$ 是 GUI action. 如果 $a_t=\texttt{Finished()} $, 则停止执行, 进入评测阶段. 如果 $a_t=\texttt{CallUser()}$, 则请求用户介入, 当前任务可记为需要人工帮助. 否则, 将动作映射到真实 GUI 操作, 例如点击、输入、滚动、拖拽或快捷键： $$ s_{t+1}=\mathcal{E}.\mathrm{step}(s_t,a_t) $$ 获取新截图： $$ o_{t+1}=\mathcal{E}.\mathrm{screenshot}(s_{t+1}) $$ 更新历史, 记录轨迹： $$ H_{t+1}=H_t\oplus {z_t,a_t} $$ $$ \tau \leftarrow \tau \cup {o_t,z_t,a_t,o_{t+1}} $$ 重复 2-8 步骤, 直到达到最大步数后停止. 用任务评测器判断最终状态是否达成目标 $r=\mathrm{Eval}(s_T,I)$ 返回 $(r,\tau)$

UI-TARS 把不同平台的 GUI 操作统一成一套 action schema. 比如桌面的 click 和移动端的 tap, 在语义上都归为坐标点击.

数据构造

在感知层面, 为了提升截图理解，UI-TARS 构造了大规模 GUI screenshot 数据，并通过解析工具提取元素类型、层级、bounding box、文本内容等 metadata。

论文选择用解析工具提取元素 metadata, 其中每个元素包含： $$ b_i=(\mathrm{type}_i,\mathrm{text}_i,\mathrm{bbox}_i,\mathrm{depth}_i) $$
基于这些数据，论文设计了五类任务：元素描述 (element description)、页面描述 (dense captioning)、状态转移描述 (state transition captioning)、GUI 问答 (GUI QA)、元素标记 (Set-of-Mark)。

在动作层面, UI-TARS 训练模型直接预测元素坐标。做法是用元素 bbox 的中心点作为点击点，并将坐标归一化到屏幕尺寸，从而适配不同分辨率。论文也整合了 SeeClick、GUIAct、MultiUI 等开源数据，并统一到自己的 action space。

显式推理

原始动作轨迹通常只有观察和动作，没有显式推理。UI-TARS 的做法是给轨迹补上 thought，把数据格式扩展一个 thought 字段.

算法UI-TARS-Thought-Augmentation 输入 > 动作轨迹集合 $\mathcal{D}_{trace}$，VLM 标注器 $\mathcal{M}$，早期 UI-TARS checkpoint $\pi_{\theta_0}$. 输出 > 带 thought 的轨迹集合 $\mathcal{D}_{thought}$. 对每条轨迹和对每一步 $t$，构造上下文： $$ \tau=(o_1,a_1,o_2,a_2,\dots,o_T,a_T) $$ $$ c_t=(I,o_{\le t},a_{\lt t}) $$ 使用 ActRe 方式，给定当前上下文和目标动作 $a_t$，反向生成 thought： $$ z_t=\mathcal{M}(c_t,a_t) $$ 约束 thought 覆盖以下 reasoning pattern： task decomposition； long-term consistency； milestone recognition； trial and error； reflection。 为减少“事后合理化”问题, 不提前给定真实动作, 使用 thought bootstrapping, 采样多个候选并选择能导向正确动作的思考-动作对： $$ (z_t^j,a_t^j)\sim \pi_{\theta_0}(\cdot\mid c_t) $$ 得到增强轨迹： $$ \tau^*=(o_1,z_1,a_1,\dots,o_T,z_T,a_T) $$ 返回 $\mathcal{D}_{thought}$

在线轨迹 Bootstrapping

论文认为 GUI agent 的最大瓶颈是缺少真实交互过程数据，所以它让模型在大量虚拟 PC 上执行任务，自动收集 trace, 大致流程是:

构造任务目标集合：$ \mathcal{G}_i=\mathcal{G}_{human}\cup\mathcal{G}_{model}$
在多个虚拟机中并行执行任务, 得到原始轨迹集合 $\mathcal{T}_{raw}={\tau_j}$
使用 rule-based reward 过滤明显异常轨迹，例如重复点击、无效操作.
使用 VLM scoring 对剩余轨迹打质量分并丢弃低质量轨迹.
对部分轨迹进行人工审查, 找到首次错误步骤并丢弃错误之后的部分.

此外, 普通 offline 数据往往是“完美轨迹”，模型学不到如何从错误中恢复。UI-TARS 因此用自己生成的错误轨迹构造两类数据：

错误纠正 (error correction): 指出某一步错了，并标注正确思考/动作;
预先反应 (post-reflection): 假设错误已经发生，标注下一步如何补救.

论文明确提出这里采用 DPO 优化: