我们延续着 Agentic RL 的话题, 之前的博客 中我们已经介绍了 Agentic RL 的一些基本概念和方法, 以及一些相关的论文. 由于 Agentic RL 的应用领域非常广泛, 包括了很多不同的任务和环境, 这里围绕综述 [] Unknown-material 着重讨论一下 GUI Agent.
UI-TARS
字节的 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 优化:
$$ \mathcal{L}_{DPO}=-\log \sigma \left[ \beta \left( \log \frac{\pi_\theta(a_t^+\mid s_t)}{\pi_{\mathrm{ref}}(a_t^+\mid s_t)}- \log \frac{\pi_\theta(a_t^-\mid s_t)}{\pi_{\mathrm{ref}}(a_t^-\mid s_t)}\right)\right] $$
DigiRL
DigiRL 是一个基于 evaluator 和 value-based filtering 训练能持续改进的设备控制 agent, 主要面向安卓系统.
DigiRL 把 Android 设备控制建模成有限时长 MDP:
$$ \mathcal{M}=(\mathcal{S},\mathcal{A},P,R,H) $$- State: Android 当前界面状态, 通常由截图表示.
- Observation: 当前截图, 论文实现中还会用最近两张截图.
- Action: Tap / Swipe / Type / Back / Home / Enter 等 GUI 操作.
- Reward: episode 结束后由 evaluator 判断任务是否成功. 成功为 1, 失败为 0.
- H: 最大交互步数.
DigiRL 分成 Offline RL initialization 和 Offline-to-Online RL 两个训练阶段.

rollout 阶段和一般的 Agentic RL 别无二致, 在此省去.
对于 Offline RL initialization, 用旧 policy 先跑出一批离线 GUI 轨迹, 用 evaluator 标成功/失败, 再主要模仿成功轨迹中的动作, 把 agent 初始化到一个能做 Android 操作控制的起点, 之后才进入真正的 offline-to-online RL. 我们这里更关注 Offline-to-Online RL 阶段.
算法DigiRL: Offline-to-Online Training
输入 > 任务集合 $\mathcal{I}$, Android 环境 $\mathcal{E}$, 初始 VLM policy $\pi_\theta$, 离线轨迹数据 $\mathcal{D}_{off}$, 自动 evaluator $\mathrm{Eval}$, 最大步数 $H$, 训练轮数 $N$, instruction-level value $V_{\phi}^{inst}$, step-level value $V_{\psi}^{step}$.
输出 > 训练后的 device-control policy $\pi_{\theta'}$.
- 初始化 replay buffer: $$ \mathcal{B}\leftarrow \mathcal{D}_{off} $$
- 使用离线成功轨迹初始化 actor 参数 $\theta$.
- 对 $n=1,\dots,N$, 执行 online 训练循环.
- 从任务集合中采样一批 instruction $I_1,\dots,I_B\sim \mathcal{I}$, 并在多个 Android 模拟器中并行 rollout: $$ \tau_i=\mathrm{Rollout}(\pi_\theta,\mathcal{E},I_i,H) $$
- 使用自动 evaluator 判断每条轨迹是否成功: $$ R_i=\mathrm{Eval}(I_i,\tau_i) $$
- 将新轨迹加入 replay buffer: $$ \mathcal{B} \leftarrow \mathcal{B}\cup{(\tau_i,R_i)}_{i=1}^B $$
- 训练 instruction-level value: $$ V_{\phi}^{inst}(I)\approx \mathbb{E}[R\mid I] $$
- 训练 step-level value: $$ V_{\psi}^{step}(s_t,I)\approx \mathbb{E}[R\mid s_t,I] $$
- 对每条轨迹计算 instruction-level 学习信号, 并只保留高学习信号的轨迹: $$ u(\tau,I)=R(\tau)-V_{\phi}^{inst}(I) $$ $$ \mathcal{B}_{inst} = \mathrm{TopK}_{\tau\in\mathcal{B}} \left(u(\tau,I)\right) $$
- 对轨迹中的每个动作计算 step-level advantage: $$ A^{step}(s_t,a_t,I) = Q(s_t,a_t,I)-V_{\psi}^{step}(s_t,I) $$ 这里 $Q$ 就是蒙特卡洛得到的 Q 函数.
- 用 doubly-robust 得到更稳定的 advantage 替代 10 中的结果: $$ \widehat{A}^{step}(s_t,a_t,I) = \lambda^{H-t}r(s_H,a_H,I) + \\ (1-\lambda^{H-t}r(s_H,a_H,I))\left(V_{\psi}^{step}(s_{t+1},I)+r(s_t,a_t,I)-V_{\psi}^{step}(s_t,I)\right) $$
- 根据阈值保留 advantage 动作: $$ \mathcal{D}_{filter} = \{(s_t,a_t,I)\mid \widehat{A}^{step}(s_t,a_t,I) \gt 1/H\} $$
- 用过滤后的动作更新 actor: $$ \theta \leftarrow \arg\max_\theta \sum_{(s_t,a_t,I)\in\mathcal{D}_{filter}} \log \pi_\theta(a_t\mid s_t,I) $$
- 返回最终 policy $\pi_{\theta'}$.

UI-R1
UI-R1 是首个通过 DeepSeek R1 风格的强化学习, 在 GUI 动作预测任务上提升 MLLM 推理能力的框架.
UI-R1-3B 的 RL 训练方案还是 GRPO. 公式这里略去. 其奖励设计为:
$$ R = R_T + R_C + R_F $$- 第一个代表动作类型奖励(click,scroll 等), 二元奖励[0,1]
- 第二个代表动作坐标奖励, 命中 grounding 奖励, 二元奖励[0,1]
- 第三个代表模型回复格式奖励, 论文没有提到奖励值如何计算
后面作者又追加了个 UI-R1-E-3B, 加入了两个额外的训练阶段: DAST 和 NOTHINK.
DAST 中, 考虑了模型 Token 预算限制.
$$ R = R_T + R_C + R_F + R_L $$这里 $R_L$ 是一个长度奖励:
$$ R_L = \begin{cases} \max(-0.5 \lambda + 0.5, 0.1) & \text{if correct} \\ \min(0.9 \lambda - 0.1, -0.1) & \text{if incorrect} \end{cases} $$其中 $\lambda$ 由期望 Token 预算 $L_{bugdet}$ 得到:
$$ \lambda = \frac{L_{i} - L_{budget}}{L_{budget}} $$$$ L_{budget} = p L_r + (1-p) L_{\max}, ~ p = c/N $$
- $c$: 某个问题得到正确答案的数量
- $N$: 该问题的总回答数量
- $L_r$: 该问题正确回答的平均长度
- $L_{\max}$: 该问题的最大回答长度
NOTHINK 是去除掉 think 标签, 在任务回答中去除显式思考.

GTA1
论文 [] Unknown-material (2026 ICLR) 提出每一步用 test-time scaling 选更好的 GUI 动作规划, 再用 RL 训练出的定位模型把它落到精确坐标.
测试时 scaling
算法GTA1: Test-Time Scaling Rollout
输入 > 用户任务 $I$, GUI 环境 $\mathcal{E}$, planner $\pi_P$, judge $\pi_J$, grounding model $g_\theta$, 每步候选数 $K$, 最大步数 $T$.
输出 > 最终 GUI 状态 $s_T$, 执行轨迹 $\tau$, 任务成功标记 $r$.
- 初始化环境 $s_0$, 初始截图 $x_0$, 轨迹 $\tau = \emptyset$.
- 对每一步 $t=0,1,\dots,T-1$:
- 构造 planner 上下文$h_t$, 包括用户指令 $I$、历史动作、历史观察 $\tau$ 和当前截图 $x_t$.
- planner 并行采样 $K$ 个候选动作: $$ p_t^1,\dots,p_t^K \sim \pi_P(\cdot \mid h_t) $$
- judge 根据用户目标、当前截图和历史轨迹选择最合适候选: $$ j^\star = \arg\max_j \pi_J(p_t^j \mid I,\tau,x_t) $$ $$ p_t^\star = p_t^{j^\star} $$
- 如果 $p_t^\star$ 是坐标型动作, 由定位模型预测点击坐标: $$ c_t = g_\theta(x_t,p_t^\star) $$ 之后构造真实可执行动作: $$ a_t = \mathrm{BindCoordinate}(p_t^\star,c_t) $$ 否则直接执行.
- 在 GUI 环境中执行动作: $$ s_{t+1} = \mathcal{E}.\mathrm{step}(s_t,a_t) $$
- 获取新截图: $$ x_{t+1} = \mathcal{E}.\mathrm{observe}(s_{t+1}) $$
- 更新轨迹: $$ \tau \leftarrow \tau \cup {p_t^\star,a_t,x_{t+1}} $$
- 如果 planner / judge 判定为结束, 或任务达到终止条件, 停止执行.
- 返回 $(s_T,\tau,r)$
算法的关键是每一步做局部多候选选择.
定位模型
GTA1 的定位部分和 UI-R1 很像.
算法GTA1: Grounding GRPO
输入 > GUI 定位数据集 $\mathcal{D}={(x_i,p_i,b_i)}$, 其中 $x_i$ 是截图, $p_i$ 是动作, $b_i=(x_{\min},y_{\min},x_{\max},y_{\max})$ 是目标 UI 元素 bbox. 定位策略 $g_\theta$, 每个样本采样数 $N$.
输出 > 训练后的定位模型 $g_{\theta'}$.
- 对每个样本 $(x_i,p_i,b_i)$, 由于 HTML parser 得到的 bbox 有时会因为 UI 动画、渲染延迟等原因和真实视觉元素错位, 先用 OmniParser 检测截图中的 UI 元素框, 然后丢弃和检测框最大 IoU 低于阈值的样本.
- 策略直接采样 $N$ 个坐标预测: $$ o_i^1,\dots,o_i^N \sim g_\theta(\cdot \mid h_i) $$ 其中: $$ o_i^n=(\hat{x}_i^n,\hat{y}_i^n) $$
- 对每个预测计算 click reward: $$ r_i^n = \mathbf{1} [ x_{\min}\leq \hat{x}_i^n \leq x_{\max} \land y_{\min}\leq \hat{y}_i^n \leq y_{\max} ] $$
- 对同一组采样结果, 得到 advantage: $$ A_i^n = \frac{ r_i^n-\mathrm{mean}(r_i^1,\dots,r_i^N) }{ \mathrm{std}(r_i^1,\dots,r_i^N) } $$
- 用 GRPO 更新定位策略: $$ \theta \leftarrow \mathrm{GRPO}(\theta, A) $$
- 返回训练后的定位模型 $g_{\theta'}$.

实验表明 scale 的 $K$ 越大, 任务成功率越高.

GTA1 特意提到不提示模型先生成 CoT, 而是直接输出预测坐标. reward 则检查预测坐标是否落在标注 bbox 内, 而非使用 bbox 的 IoU, 具体这里参看消融实验:

AutoWebWorld
论文 [] Unknown-material (IMCL 2026) 讨论的是 Web GUI agent 的数据合成问题. agent 只能看到渲染后的页面截图或 DOM 片段, 看不到网站内部状态. 页面看起来可能更新了, 但是否真的达到了预期的状态, 外部观察并不总是可靠. 因此网站数据管线通常需要人工标注或 LLM judge 判断轨迹是否正确. 这就是论文说的验证瓶颈: 成本高, 判断不稳定, 而且每多生成一条轨迹都要验证成本.
这篇论文反过来: 不从真实网站里猜测内部状态, 而是先显式定义网站的有限状态机 (Finite State Machine, FSM), 再让 coding agent 把 FSM 翻译成可运行的合成网站. 这样任务是否成功不再依赖外部 judge, 而是由 FSM 的状态转移和终止状态直接判定.

状态建模
论文把 Web GUI 交互建模成:
$$ \mathcal{M}=\langle S,A,T,O\rangle $$其中 $S$ 是环境内部语义状态, $A$ 是可执行动作空间, $T:S\times A\rightarrow S$ 是确定性状态转移, $O$ 把内部状态渲染成 agent 可见观察, 例如网页截图.
关键是区分内部状态 $s_t$ 和观察 $o_t$:
$$ o_t=O(s_t) $$之前很多 GUI 数据只记录 $o_t$ 和动作 $a_t$, 但 AutoWebWorld 要显式维护 $s_t$. 论文定义一个状态为:
$$ s_t=(p_t,\sigma_t) $$$p_t$ 是当前页面 id, $\sigma_t$ 是页面签名 (page signature), 由一组结构化变量构成:
$$ \sigma_t=\{v_1^{(p_t)},v_2^{(p_t)},\ldots,v_{K(p_t)}^{(p_t)}\} $$这些变量只记录会影响任务成功或后续可达性的关键信息, 例如搜索词、筛选条件、排序方式、分页位置、表单输入值、购物车内容、选中的 item 等.
对页内动作, 页面 id 不变, 只更新 signature; 对跨页面动作, 切换到目标页面并初始化/继承部分状态:
$$ T(s,a)= \begin{cases} (p,\mathrm{Apply}(\sigma,\mathrm{eff}(s,a))), & \text{in-page} \\ (p',\mathrm{Init}(p')\oplus \mathrm{Carry}(\sigma')), & \text{cross-page} \end{cases} $$生成流程
AutoWebWorld 的 pipeline 有四步:
- FSM 生成. 给定参考网站, 多 agent 框架生成 FSM, 包含页面集合、每页签名、动作、动作影响、终止状态.
- Web 环境生成. 用 coding agent 把 FSM 翻译成 Vue 前端项目, 并用参考网站作为 style anchor.
- 轨迹搜索. 在 FSM 状态图上用 BFS 枚举到达目标状态的最短路径.
- 轨迹过滤. 将 BFS 得到的语义动作展开为 GUI atomic operation, 用 Playwright 在生成网站中回放, 只保留能完整执行且到达目标状态的轨迹.
算法AutoWebWorld: FSM 到可验证轨迹
输入 > Web 主题 $w$, 参考网站名称 $r$, FSM 生成器 $\mathcal{G}_{fsm}$, coding agent $\mathcal{G}_{code}$, 最大 BFS 深度 $L$.
输出 > 合成网站 $\mathcal{W}$, 验证轨迹集合 $\mathcal{D}$.
- 根据主题生成候选 FSM: $$ F_0=\mathcal{G}_{fsm}(w,r) $$
- 用验证器检查 $F_i$ 的页面、动作、动作影响和终止状态.
- 如果检查失败, improver 根据错误位置生成新 FSM: $$ F_{i+1}=\mathrm{Improve}(F_i,\mathrm{Issues}(F_i)) $$ 重复直到得到有效 FSM $F^\star$.
- coding agent 根据 $F^\star$ 生成可运行前端: $$ \mathcal{W}=\mathcal{G}_{code}(F^\star,r) $$ 如果 build 或运行失败, 将错误日志返回 coding agent 自修, 直到网站可执行.
- 从初始状态 $s_0$ 开始, 在 FSM 图上 BFS. 对每个状态 $s=(p,\sigma)$, 只扩展满足 $pre(s,a)=1$ 的动作: $$ s'=T(s,a) $$
- 当目标谓词 $G(s)$ 成立时, 保存语义轨迹: $$ (s_0,a_1,s_1,\ldots,a_T,s_T) $$
- 将每个语义动作 $a_t$ 展开成预定义 GUI procedure, 例如 click / type / hover / scroll.
- 用 Playwright 在 $\mathcal{W}$ 中回放 GUI procedure, 通过 selector 获取元素 bbox 并执行原子操作.
- 如果任一步无法定位元素、无法执行或最终没有到达目标状态, 丢弃该轨迹.
- 返回所有通过执行过滤的轨迹 $\mathcal{D}$.
这里最关键的设计是两层轨迹:
正确性的来源是 FSM, GUI procedure 只是实现方式. 这点和真实网站采样不同.

训练
论文用 AutoWebWorld 轨迹训练 Qwen2.5-VL-3B 和 Qwen2.5-VL-7B. 为了避免同一任务下大量相似轨迹造成过拟合, 作者对同一任务的平行轨迹只采样一条.
GRPO reward 包含三部分:
$$ R(y,y^\star)=R_{\mathrm{act}}(y,y^\star)+R_{\mathrm{coord}}(y,y^\star)+R_{\mathrm{fmt}}(y) $$第一项是动作类型是否匹配. 第二项是坐标定位 reward. 对 click / hover 这类动作, 需要预测点落在目标 bbox 内. 第三项是格式 reward.
和 UI-R1、GTA1 的定位奖励接近, 只是 AutoWebWorld 的 bbox 来自可执行前端中的元素 selector 和 Playwright 回放, 不需要人工标注.
Trifuse
论文 [] Unknown-material 讨论的是 GUI 定位. 主流 GUI 定位方法通常是训练式的: 用大量 GUI 标注数据微调 MLLM, 让模型直接预测目标元素坐标. 这类方法效果强, 但需要昂贵标注, 对新应用、新布局、新系统也未必泛化. 另一条路线是 attention-based 定位: 不训练, 直接利用 MLLM 内部 attention map 作为定位信号. TAG 就是这类代表, 但单看注意力往往噪声大, 精度不够.

Trifuse 的观点是: 注意力本身是有语义理解的, 问题在于 GUI 里缺少明确的空间锚点. 所以它把三种互补信号 attention, OCR, caption 融合起来.
Attention 提取
论文 MLLM 选取 Qwen2.5-VL, 设 GUI 截图经过视觉编码器后得到 patch token:
$$ V=[v_1,\ldots,v_{|V|}] $$用户指令 token 为:
$$ Q=[q_1,\ldots,q_{|Q|}] $$在第 $l$ 层第 $h$ 个注意力头中, token $q_i$ 对视觉 patch 的注意力向量记为:
$$ a^{l,h}_{q_i}\in\mathbb{R}^{|V|} $$直接聚合所有 token 和所有 head 不好, 因为指令里有很多无关词, MLLM 里也有很多 head 并不负责空间定位. Trifuse 因此做两级过滤.
第一步是 token filtering. 对每个文本 token $q_i$, 计算它和视觉 patch 的相关性:
$$ S(q_i)=\sum_{v_j\in V}\mathbf{1}[\cos(q_i,v_j)>\tau_v]\cdot \cos(q_i,v_j) $$然后保留得分最高的 top-k token. 论文实验中取 k=1.
第二步是 head filtering. 对每个 head 的 attention map, 先用连通组分分析得到若干空间连通区域 $R=\{r_1,\ldots,r_{|R|}\}$, 再计算空间熵:
$$ H(a^{l,h}_{q_i})=-\sum_{r_j\in R} R_j\log R_j $$其中 $R_j$ 是落在第 $j$ 个连通区域上的归一化注意力质量. 熵越低, 说明这个 head 的注意力越集中, 越可能适合 grounding. Trifuse 保留空间熵最低的 top-k head, 实验中取 k=6.
最后对过滤后的 token 和 head 加权聚合:
$$ a_{\mathrm{attn}}= \sum_{q_i\in Q_{\mathrm{filter}}} \mathrm{softmax}(S(q_i)) \sum_{(l,h)\in H_{\mathrm{filter}}(q_i)} \mathrm{softmax}(-H(a^{l,h}_{q_i}))a^{l,h}_{q_i} $$得到 attention heatmap.
OCR 和 Caption 热力图
OCR 模态 (论文中用 PaddleOCR v4) 先用现成 OCR 引擎抽取文本实例:
$$ T=\{t_1,\ldots,t_{|T|}\} $$每个文本实例 $t_k=\{b_k,s_k,c_k\}$, 其中 $b_k$ 是 bbox, $s_k$ 是识别出的文本, $c_k$ 是检测置信度. 它和指令 token 的相关性定义为:
$$ r_k^{ocr}=\cos(e(s_k),Q_{\mathrm{filter}})\cdot c_k $$再把这个分数投影到视觉 patch 网格上:
$$ a_j^{ocr}=\sum_{k:v_j\cap b_k\ne\emptyset} r_k^{ocr} $$Caption 模态 (论文中用 OmniParser) 类似, 只是对象从 OCR 文本变成图标检测和图标 caption. 每个 icon 实例 $g_k=\{b_k,d_k,c_k\}$, 其中 $d_k$ 是图标语义描述:
$$ r_k^{cap}=\cos(e(d_k),Q_{\mathrm{filter}})\cdot c_k $$然后同样投影为 patch-level caption 热图:
$$ a_j^{cap}=\sum_{k:v_j\cap b_k\ne\emptyset} r_k^{cap} $$CS 融合
有了三张热力图之后, 简单平均并不好. OCR 对文本强但对图标弱; caption 对图标有帮助但质量不稳定; attention 覆盖广但定位粗. 固定权重也很难适配不同任务.
Trifuse 提出 Consensus-SinglePeak (CS) fusion, 进行元素平均融合:
$$ M_{\mathrm{final}}=M_{\mathrm{cons}}\oplus M_{\mathrm{single}} $$其中 consensus 项强调三种模态共同支持的区域:
$$ M_j^{cons}=a_j^{attn}\odot a_j^{ocr}\odot a_j^{cap} $$这里 $\odot$ 指逐元素相乘. single-peak 项则保留某个模态特别强、但其他模态不一定同时强的峰值. 对每个模态 $s\in\{attn,ocr,cap\}$, 先选出超过阈值的峰:
$$ P_s=\{j\mid a_j^s>\tau_s\} $$再用其他模态对这个峰的支持估计置信度:
$$ conf_{s,j}=\sigma\left(\alpha\cdot \frac{\sum_{s'\ne s}a_j^{s'}}{a_j^s+\epsilon} -\beta\right) $$也就是说希望其他模态也有支持, 如果没有那就很有可能是噪声.
$$ W_{s,j}=1+\lambda(2conf_{s,j}-1) $$最后:
$$ M_j^{single}=\sum_s \mathbf{1}(j\in P_s)W_{s,j}a_j^s $$我的理解是, consensus 负责稳健性, single-peak 负责不要错过某个模态独有的强证据. 比如目标是文字按钮时, OCR 可能最可靠; 目标是无文字图标时, caption 或 attention 可能更可靠.
两阶段定位
由于 MLLM 输入通常会把高分辨率截图下采样, patch 粒度较粗, 直接从 fused heatmap 取最大点会损失小元素定位精度. Trifuse 因此使用两阶段 zoom-in, 细节略去.
这个技巧和 GUI agent 里常见的 crop-then-ground 思路一致, 不需要额外训练.
算法Trifuse
输入 > GUI 截图 $V$, 用户指令 $Q$, MLLM $\mathcal{M}$, OCR 引擎 $\mathcal{O}$, 图标解析器 $\mathcal{C}$.
输出 > 目标元素坐标 $\hat{p}$.
- 用 $\mathcal{M}$ 提取文本 token 到视觉 patch 的 attention.
- 根据 token-image relevance 选择 $Q_{\mathrm{filter}}$.
- 对每个候选 head 计算空间熵, 保留 $H_{\mathrm{filter}}$.
- 聚合得到 attention heatmap $a_{\mathrm{attn}}$.
- 用 $\mathcal{O}$ 检测文本 bbox 和文本内容, 计算 OCR relevance 并投影成 $a_{\mathrm{ocr}}$.
- 用 $\mathcal{C}$ 检测图标 bbox 和 caption, 计算 caption relevance 并投影成 $a_{\mathrm{cap}}$.
- 计算 consensus heatmap: $$ M_{\mathrm{cons}}=a_{\mathrm{attn}}\odot a_{\mathrm{ocr}}\odot a_{\mathrm{cap}} $$
- 对每个模态选择高响应峰值, 用其他模态支持度动态放大或削弱, 得到 $M_{\mathrm{single}}$.
- 融合: $$ M_{\mathrm{final}}=M_{\mathrm{cons}}\oplus M_{\mathrm{single}} $$
- 从 $M_{\mathrm{final}}$ 中找到粗定位区域, 裁剪原图并放大.
- 在裁剪图上重复 1-9, 输出最终坐标 $\hat{p}$.

HyMEM
与前面主要讨论的定位方法不同, 论文 [] Unknown-material 讨论的是 GUI agent 的外部记忆.
已有 memory 方法通常比较扁平. HyMEM 的思路是把文本经验和 embeddings 合起来: 离散记忆负责高层策略, 连续记忆负责保留多模态轨迹细节, 再用图结构把相关经验连接起来:
$$ G=(V,E) $$每个节点 $v_i\in V$ 表示一条成功 GUI 交互轨迹, 节点内部是一个混合表示:
$$ v_i=(c_i,A_i,m_i) $$- $c_i$: 高层策略摘要, 例如“先按价格从低到高筛选”.
- $A_i$: 中层语义标签, 例如
#search,#filter,$price. - $m_i$: 底层连续轨迹 embedding, 用来保留截图、动作、UI 细节.
节点编码时, 论文用 Qwen2.5-VL-7B 生成 strategy 和 attribute. 连续轨迹 embedding 则沿用 CoMEM, 把整条轨迹压成 8 个 embedding, 推理时可以拼到 GUI agent 的 embedding layer 里.
图的边主要根据中层属性建立. 如果两个轨迹节点共享相同或相近的 attribute, 就建立连接.
全局自演化
新成功轨迹到来时, HyMEM 先检索相似节点, 再用 VLM 判断信息增益.
对新轨迹:
$$ \tau=[q,o_1,a_1,\ldots] $$先用 CLIP 文本编码任务 $q$, 用 CLIP 图像编码初始观察 $o_1$, 拼成检索向量:
$$ v=[\mathrm{CLIP}_{txt}(q);\mathrm{CLIP}_{img}(o_1)] $$然后用 FAISS 找 top-K 相似轨迹节点及其相连 strategy / attribute 节点. 接着 VLM judge 根据新轨迹和邻居节点判断三种更新操作:
- ADD: 新轨迹包含已有图里没有的策略或属性, 新建节点.
- MERGE: 新轨迹和已有策略相同, 但提供了补充证据, 合并进已有节点并更新属性.
- REPLACE: 新轨迹是同一策略下更好的执行版本, 例如步数更少、风险更低, 替换旧证据.
这个机制解决的是 memory bank 规模失控问题.
算法HyMEM
输入 > 当前记忆图 $G=(V,E)$, 新成功轨迹 $\tau=(q,o_1,a_1,\ldots)$, 检索器 $\mathrm{Retrieve}$, VLM judge $J$.
输出 > 更新后的记忆图 $G'$.
- 构造新轨迹检索向量: $$ v=[\mathrm{CLIP}_{txt}(q);\mathrm{CLIP}_{img}(o_1)] $$
- 在已有轨迹节点中检索相似邻居: $$ \mathcal{N}=\mathrm{Retrieve}(v,G) $$
- 将新轨迹、相似轨迹、对应截图和已有 strategy / attribute 输入 VLM judge.
- judge 输出结构化决策: $$ d=J(\tau,\mathcal{N})\in\{\mathrm{ADD},\mathrm{MERGE},\mathrm{REPLACE}\} $$
- 如果 $d=\mathrm{ADD}$, 则新建 strategy / attribute / trajectory 节点并连边.
- 如果 $d=\mathrm{MERGE}$, 则把新轨迹作为补充证据接入已有节点, 并合并新属性.
- 如果 $d=\mathrm{REPLACE}$, 则用新轨迹替换旧轨迹证据, 更新 attribute 连接.
- 根据新共现关系增强 strategy 和 attribute 之间的边.
- 返回更新后的图 $G'$.
推理方法
推理时 HyMEM 不是只在任务开始检索一次, 而是维护动态工作记忆.
首先根据当前任务和初始截图构造多模态查询 embedding, 找到若干种子 nodes. 然后对每个种子 node, 收集 1-hop 邻居, 重新按相似度排序, 加入 top-k 邻居. 多轮扩展并排序后得到更丰富的节点集合.
之后 HyMEM 把这些节点转成两种上下文:
- 离散 Guidance Instructions: 用 VLM 把相关 strategy / attribute 消化成简短可执行建议, 注入 system prompt.
- 连续 trajectory embeddings: 把相关轨迹 embedding 拼入 VLM 输入, 提供难以文本化的视觉和动作细节.
此外, GUI 长程任务会发生阶段切换. 比如一开始在搜索页面, 后来进入筛选页面, 再进入 checkout 页面. 如果一直使用初始检索的记忆, 很快会过期. 因此 HyMEM 在每一步后比较 $o_t\rightarrow o_{t+1}$, 判断是否发生阶段切换. 如果发生, 就保留长期目标和仍然相关的指令, 丢弃过期部分, 再基于新状态重新检索并刷新 working memory.
