BloomBloom
发起研究

FocusGUI：不训练骨干，全模态 GUI 智能体动作类型准确率翻倍

速览

决定动作的那路信号每一步都在换位，一步误读还会滚成不可逆的轨迹漂移

论文《Focused Omni-Modal GUI Agents》把全模态 GUI 智能体的瓶颈从「模型看不到」重新定义成「每一步该看哪一路信号，这件事本身在变」。做法是逐个移除某个模态，记录真值动作 log-likelihood 的变化：下降的算 useful，上升的算 interfering，跌幅最陡的是 dominant。量出来的结果是主导模态在 45.3% 的相邻步就换位一次，94.0% 的 episode 至少切换过一次，90.1% 的步骤至少含一个干扰模态，而目标元素中位只占屏幕面积的 0.87%。口径要说清：45.3% 出自图注，图中名为 Dominant switch 的那条曲线读数其实是 53.4%，与图注对得上的是 Role change 曲线（45.2%）。FocusGUI

图注：论文 Figure 1 的三张子图。(a) 折线图给出 Dominant switch、Role change、Episode switch 三条切换率曲线；(b) 水平堆叠条形图把各类任务的模态实例拆成 Useful 与 Interfering 两段；(c) 分组统计图给出单步内视频画面变化与目标元素占屏面积的中位数和四分位。图中只有消融结果，不含 FocusGUI 曲线。FocusGUI

相关性的归属因此可以被逐格核对，不再只是一句直觉。

先看每一步喂进了什么。OmniGUI 这个基准把单步观察定义成四元组，包含当前步的静态截图、上一次动作完成到当前步之间的屏幕视频片段、与视频同步的音频流，以及此前所有已执行动作。截图负责定位，音视频负责捕捉「刚刚发生了什么」，动作历史让模型知道已经走到哪一步。OmniGUI

图注：OmniGUI 的框架总览。Step1 到 Step5 五列各自给出 Screenshot、Audio 与 Video 输入，左侧黄色 History 框累积已执行动作与历史图像，每列经 Omni Model 输出一个动作，底部列出 Type Match 与 Exact Match 两项指标，右下角标注 per-step evaluation with GT history。OmniGUI

这些流被一起交给模型，「什么重要」完全交给解码器每一步重新发现。

而这个问题之所以不能靠「再多训一点」修补，是因为它会自我放大。已执行的动作会回灌进下一步的上下文，单步误读于是变成下一步的输入，误差沿轨迹累积。论文给这个现象起名叫 Sequential Distraction，后果是不可逆的轨迹漂移。这也不是作者自说自话：OmniGUI 自己做过跨模态干扰消融，在 AV-Present 任务上喂入完整音视频反而低于只喂静态图像，论文举的例子是 Gemini 2.5 Flash 的 Exact Match 从 49.9% 掉到 40.8%（正文口径；同文表 4 对应单元格为 48.3% → 39.3%）。两条证据测的不是同一件事，OmniGUI 证明多模态上下文会变成干扰，锚论文证明相关性的归属逐步在变。OmniGUI

三条判据一立，「裁剪屏幕看局部」这一派解法就被排除在外

论文把需求收束成 Focused Perception：一个表征必须同时满足步级自适应、动作充分、非侵入。这里有一个结构事实要交代，论文并没有为这三条单列定义节，它们只在摘要里出现一次，排除性论证分散在引言与方法两处，所以下面这张判据表是补出来的。

性质排除掉哪一类解法依据
步级自适应固定权重、固定裁剪策略权重必须按当前这一步的决策参照重算
动作充分需要先重建观察、再拿重建结果决策的套件方案决定性信号可能只在音频或视频上出现
非侵入裁剪屏幕、区域精修、缩短观察论文声明它既不替换也不裁剪观察的任何部分

三条里最硬的是非侵入，它直接判了一条主流路线出局。剪掉屏幕、只放大嫌疑区域，改的是「模型被喂什么」，而论文要求改的是「模型怎么读」。把两件事分开之后，观察保全与决策引导可以同时成立：输入一个字节不动，只在读取环节做引导。这也划清了它和注意力重加权、token pruning 的界线，本文不删输入、不改词表、不加预测头，只加一个条件信号。

这套要求并非孤立主张。把观察压缩到「该看的部分」是当前 GUI 智能体研究的收敛方向之一，2026 年 9 月的一篇效率综述把这类工作归在「选择性阅读取代全量摄入」与「全局到局部的视觉分配」两条趋势下。不过该综述的语料里音频与视频通道零命中，它无法为全模态这一族提供坐标，只能当邻接参照。Efficient GUI Agents

不动一个骨干参数：把七条通道按当前这一步的决策参照重排，压成 64 维残差加在动作边界前

FocusGUI 的全部动作发生在一个 64 维潜变量和 4 个 embedding 位置上。数据流分四段：通道分解、步级优先、紧凑聚焦、残差对齐。原通路一处不动，辅助通路从同一份观察另起一条，最后在动作边界前把结果拼回解码器的输入序列。

图注：论文 Figure 2 的架构总览。上半部是冻结骨干的原通路，从多模态观察到自回归解码器再到输出动作；下半部是 FocusGUI 的并行辅助通路，依次是通道分解与注意力打分、紧凑聚焦投影、标注 z_t 与 R_t 的 K 个残差槽，最终经 Residual Alignment 与 Splicing 汇入解码器。右侧手机界面为示意素材。FocusGUI

通道分解不能省，因为优先级无法在一个已融合的表征内部定义。只有一个整合表示时，没有任何量可以拿来排序。代码里七个通道是有名字的实体：文本与历史、屏幕、音频、视频、交互状态、全模态隐状态、屏幕空间特征，后者是把屏幕 token 重排成 12×12 网格池化出的 144 个格子。FocusGUI

步级优先用每一步由完整观察导出的整合表示当决策参照，与各通道算兼容性分数，再经 softmax 得到权重。关键在于这个参照每步重算、不跨步携带状态：漂移是一步一步产生的，每一步去掉污染就等于去掉累积。

讲解：一步误读如何滚成轨迹漂移

紧凑聚焦把加权后的证据压成 64 维潜变量，再展开成 K=4 个残差位置，加在动作边界前已有的 prompt 位置上，不追加文本提示、不删任何多模态输入。投影层的权重与偏置都用零初始化，训练起点残差为零，注入后的输入与原始冻结模型完全相同，「非侵入」因此是构造性保证而不是近似。训练只用动作 token 的负对数似然，梯度穿过冻结解码器回传到适配器。每个骨干各训一个适配器，可训练参数在 1.15M 到 1.45M 之间。Qwen2.5-Omni 上论文报的是 1.445M 对 8.932B 冻结 Thinker 参数，占 0.0162%。这个分母是整个 Thinker 模块，也就是语言主干加视觉塔与音频塔；仓库那份权重名叫 Qwen2.5-Omni-7B，拿名字里的 7B 当分母会算成 0.0206%。FocusGUI Qwen2.5-Omni

步级自适应不是一句口号，热力图能直接读出它的形态。

图注：论文 Figure 4 的两张并排热力图共享坐标，纵轴为七个通道，横轴为 Initial、Early、Middle、Late 四个交互阶段。左图给出各通道各阶段的绝对优先级并标注均匀分配参照 14.3%，右图给出每格相对该通道全步均值的偏差，每格带数值。论文强调这里的权重只反映辅助通路内部如何组织证据。FocusGUI

交互状态开局拿到 30.9%，超过均匀份额的两倍，到收尾掉到 7.7%，从最高优先级通道变成最低；音频与视频反向从 13.4% 与 11.3% 升到 18.8% 与 18.3%；屏幕通道始终在 10.9% 到 12.8% 之间，每个阶段都低于均匀的 14.3%。论文据此判断：没有任何一组固定权重能同时复现这两端。

还剩一个读者一定会追问的问题，64 维的残差凭什么改得动坐标和文本。论文在附录 G 用一段数学论证把它拆成两条通路。内容通路是残差作为新内容被解码器读到，这足以翻转动作原语，因为选 TAP 还是 SWIPE_UP 只是一个类别选择。注意力重路由是残差改变查询的位移，于是解码器把注意力质量重新分配到已有的证据位置上，坐标与文本这两类参数只能靠这条路修正，原因是注入窗口之前的证据位置，其内容在因果掩码下与残差强度无关，改写内容改不动它们。

图注：教程依据论文附录 G 的论证重画的因果链，非论文原图。残差先在第 1 层内部重分配注意力，从第 2 层起通过查询位移把注意力质量摊到整个观察；动作原语靠内容通路翻转，坐标与文本参数靠重路由通路修正。论文没有做这两条通路的隔离消融，此处是理论论证而非实验结论。

也正因为如此，注入只能是加性的。用残差替换最近那几个被关注最多的位置，会把它们的证据价值一并抹掉。论文对应的消融里，把加性残差换成 prompt embedding 替换后，Exact Match 掉 5.30 分、Goal Progress 掉 5.38 分，而 Type Match 只动 1.20 分。

四个骨干上动作类型准确率从 31% 抬到 64%，而且越到任务后段差距越大

四个骨干上的平均结果是 Type Match 从 31.0% 升到 64.2%，Exact Match 从 11.2% 升到 33.5%（约 3.0 倍），Goal Progress 升 6.6 分；相对每个骨干上 Overall Type Match 最强的已有方法，三项还能多出 30.1、23.6、8.0 分。口径要说明：论文先在每个骨干挑出 Overall TM 最强的基线，再逐项相减；若改成每个指标各挑最强基线，Exact Match 会变成 +21.0。

骨干冻结骨干 TM+FocusGUI TM冻结骨干 EM+FocusGUI EM
Qwen2.5-Omni49.6171.6512.6040.16
VITA-1.513.9858.669.6526.38
MiniCPM-o-4.536.0267.7213.5841.54
Baichuan-Omni-1.524.4158.868.8625.98

数字出自论文 Table 1 的 Overall 列。四个骨干的架构与多模态表征各不相同，有双轨式的，也有把全模态输入输出对齐到同一条时间轴的流式骨干，因此这套对比本来就是在检验跨骨干家族的可迁移性。冻结骨干之间原本差距很大，Type Match 最高与最低相差 35.6 分，加上适配器之后收窄到 13.0 分，弱骨干拿到的提升相对更大。FocusGUI MiniCPM-o 4.5

读数之前先交底协议。全部结果来自 OmniGUI 一个基准的离步打分，每一步喂入真值历史再预测这一步的动作，作用是把单步感知能力与自主 rollout 里典型的级联复合误差隔离开。切分按 episode 做，训练、验证、测试为 495、71、142 条轨迹，官方仓库用同一个随机种子可以复算出来。指标层次也要分清，Type Match 与 Exact Match 是步级的，Goal Progress 是「首次失败前正确步数占比」的步级代理，不是端到端任务成功率。规模上还有一处口径差，基准论文标称 709 回合、2579 步，而锚论文与排行榜用的是过滤后的 708 回合、2572 步，两个数字不合并。FocusGUI OmniGUI

分任务看，Temporal Reasoning 上的 Type Match 增益最大，37.3 分，Instant Response 上最小，27.8 分。

真正有信息量的是随交互深度的变化。冻结的 Qwen2.5-Omni 从首步 64.79 的 Type Match 掉到第 4 步及以后只剩 32.79，几乎砍半；FocusGUI 在同一区间保留 86.8%，Exact Match 还从 38.73 升到 46.72。Exact Match 的增益随深度从 +22.54 放大到 +35.25，各分箱的 bootstrap 区间都不含 0。Temporal 任务最能说明问题，冻结骨干在第 3 步之后 Exact Match 归零，FocusGUI 还有 39.39。负对照也齐全，Instant 任务的前两步累积历史很少，FocusGUI 与冻结骨干在统计上无法区分，两个差值是 −8.70 与 −17.39，区间都含 0，到深度 2 与 3 以上同一个任务上的增益变成 +28.57 与 +46.67。另外三个骨干上也复现了同样的形态。这条曲线是判断这套方法值不值得用的关键证据，它说明增益不是只出现在容易的第一步，而恰好出现在漂移开始累积的地方。

讲解：增益为什么越到后段越大

给屏幕做减法的三个基线动作类型几乎没动，坐标却倒退两成以上，这套证据也还缺两格

最能说明「改读取」与「改输入」差别的，是同一张表里的三个屏幕精修基线。DRS-GUI 用 MCTS 在三种感知动作之间搜索候选区域，OmniParser 把截图解析成带编号框与语义清单的结构化表示，RegionFocus 在触发条件满足时放大可疑区域重做一次预测，三者都在推理期改动模型看到的画面。DRS-GUI OmniParser RegionFocus

合起来的结果是：Type Match 上几乎中性，论文报的是三基线平均 +0.9 分，但 Exact Match 相对拉低 28%、Goal Progress 相对拉低 35%，两项指标各在 12 个情形里全部一致。机制解释是，收窄屏幕让动作原语更显著，这正是 Type Match 奖励的，却丢掉了确定坐标与文本所需的周边上下文，而这正是 Exact Match 要求的；同时这三者都够不到音频、视频与设备状态。这些数字全部转录自锚论文的 Table 1，三个方法各自的原文都没有在 OmniGUI 上评测过。

对照组里最讲究的一处是 GUI-Actor。它同样冻结骨干，同样有可训练参数，做法是在骨干的视觉 token 之上学一个 attention action head。它的平均增益只有 Type Match +2.12 分，而 FocusGUI 是 +33.2 分。两者共享「有可训练参数」这一条件，这个差距因此把两种解释分开了：增益不是来自多训了一批参数，而是来自按步自适应地组织证据。GUI-Actor FocusGUI

图注：GUI-Actor 论文的概览图。(a) 给出 action head 如何与 VLM 配合做坐标无关的 grounding，四个输入通道分别经 Text Tokenizer 与 Vision Encoder 进入 LM Backbone，顶部虚线框内是 Self-Attn & MLP-V 与 MLP-T 两个模块，右侧另有独立的 LM Head；(b) 是 multi-patch 监督示意，与真值框重叠的 patch 记为正、其余为负。图中不含 grounding verifier 环节。GUI-Actor

不过这套证据还缺两格，缺口的位置很清楚。第一格是成本，论文全文没有测量任何推理延迟、吞吐、FLOPs 或额外前向开销，「轻量」只是参数量口径，想知道部署代价的人拿不到数字。第二格是在线闭环，全部结果出自离步打分，它不测智能体在自主 rollout 里从复合误差中恢复的能力；在实时交互那一端，另一类基准测的是何时该开口、被打断后能否回到原任务，指标不可比。OmniInteract

对比集的完整性也有边界。这一轮只比了四个基线，2026 年更晚出现的几个空间精修方法没有进入实测；走相反路线的做法是在输入侧给智能体加观察通道，用门控把连续音视频流稀疏化后再喂给模型，而两边都没有验证能否叠加。AOI 复现门槛同样要交底，官方仓库声明不打包数据集、媒体、权重、检查点与第三方基线实现，仓库里没有 LICENSE 文件，也没有 Release，网站模板的 CC BY-SA 许可不能外推到代码，所以现在能读代码、能照着跑，但授权条款尚未明确。FocusGUI

把这些放在一起，这篇论文的贡献可以浓缩成一句判断：它改的是智能体怎么读已有的观察，而不是喂它什么。这恰好解释了为什么同一条路线上给输入做减法反而让坐标倒退，也界定了它的适用范围，当多路信号同时到达、而决定这一步做什么的那一路在不断换位时，值得在解码器的读取环节上加一个轻量引导。要真正把它用起来，下一步需要的是延迟测量、在线闭环验证，以及和更晚的空间精修方法比一场。

想深入可以读原文：Focused Omni-Modal GUI Agents — arXiv:2610.26203

参考文献