🎯 问题
跨平台 GUI agent 面临三重障碍：高质量可执行轨迹稀缺、平台交互规范相互干扰（桌面的“返回“是关窗，移动端是按钮）、以及灾难性遗忘。现有方案——混合 SFT 或模型合并——本质上是把两套交互语言平均化，结果是哪个平台都做不好。
GUI agent 的演进路径是：单平台任务执行 → 跨平台交互。但跨平台训练面临三个本质性挑战：
1. 数据稀缺：高质量、可执行的跨平台交互轨迹仍然稀缺，现有数据集的平台覆盖也不均衡。
2. 行为规范混淆：桌面和移动端有根本性不同的交互语义。「返回」在桌面意味着关闭窗口，在移动端意味着点击 Back 按钮。「双击」在桌面打开文件，在移动端缩放。平台之间的 action space 本身也不相同（computer_use vs mobile_use）。
3. 灾难性遗忘：在连续学习或联合训练中，学习新平台会系统性地降低已有平台的能力。
作者将问题本质归结为：如何让共享 GUI agent 持续适应新平台的同时，保留已有平台的特定交互行为？
实验结果印证了这一分析的严重性：8B 模型在 OSWorld 上进行 SFT，MobileWorld 性能直接跌到 0%；TIES 模型合并在 MobileWorld 上同样跌到 0%。
为什么「平均化」是这个问题的核心？
混合 SFT 和模型合并的共同缺陷是产生一个“平均策略“（averaged policy）：当桌面数据要求 left_click 而移动数据要求 tap 时，联合训练的梯度相互抵消，导致两种行为都变弱。
这不只是数据量的问题。即使两个平台的数据量完全均衡，只要两套交互规范存在语义冲突，混合训练的损失函数就会把它们拉向同一个低质量均衡点。
MIXED-SFT 的问题在于：它假设所有平台的行为都应该被统一表示，而实际上需要统一的是执行基础设施（单一推理模型），需要保留区分的是行为先验（what actions fit which context）。
模型合并（TIES/Weight Averaging）的问题：静态权重插值在训练后进行，无法保证合并后的权重在任何平台上都是最优的。TIES 在 MobileWorld 上的崩溃（0%）表明权重空间里桌面和移动端的“方向“根本不兼容——强行插值只会破坏两者。
对比：UI-MOPD 的切入点
UI-MOPD 不去“合并“两套行为，而是在 RL 训练的在线 rollout 中，根据当前数据来自哪个平台，分别向对应的平台专家教师看齐。学生模型是单一共享策略，但其训练信号在 token 级别就已经按平台区分开了。
🗃️ Uni-GUI 数据集
论文构建了 Uni-GUI：约 1.1 万条高质量跨平台交互轨迹（~16 万步）。关键设计是四阶段收集流水线——环境感知的 query 生成、教师模型执行采集、多层清洗（子任务分解判断成功率）、以及 Qwen3-VL 兼容的 chain-of-thought 格式化。
Uni-GUI 的设计哲学：不是聚合现有公开数据，而是构建统一的跨平台数据采集框架（Unified Cross-Platform Data Collection Harness），保证数据质量从源头可控。
四阶段流水线：
1. Query 生成：桌面用 Kimi-K2.6 辅助从 OSWorld 环境中提取功能点，移动端用 Gemini-3.1-Pro 从 MobileWorld/AndroidWorld 环境中提取。环境感知的生成避免了不可行任务。
2. 轨迹采集：教师模型与 GUI 环境交互，记录观察、动作、中间推理和任务状态，在归一化前保留平台原生 action 格式。
3. 轨迹清洗（多阶段）： - 去除结构异常（非连续索引、重复步骤） - 过滤不在学生 action space 内的动作 - 去除超过 40 步的轨迹 - 去除与环境不一致的 query - 子任务分解判断：用 Gemini-3.1-Pro 把每个 query 拆成有序子任务列表，只保留所有子任务都被完成的轨迹
4. 后处理：推理链归一化为 Qwen3-VL 兼容的 CoT 格式；UI 元素动作重新标注 bounding box。
数据集构成（约 1.15 万条轨迹，~16 万步）： - 桌面：自采集 ~7K + OpenCUA 清洗 ~0.8K - 移动：自采集 ~1K + OpenMobile 清洗 ~2.7K
经过过滤后最终高质量子集约 1 万条。
子任务分解判断为什么关键？
传统轨迹质量过滤依赖最终任务成功/失败，但 GUI 任务往往是多步骤的——即使整体失败，前半段可能是高质量的正确步骤。反之，即使整体「成功」（达到了终止条件），中间步骤可能走了弯路。
子任务分解把一个复杂任务显式拆成 n 个有序子目标，让 Gemini-3.1-Pro 判断每个子目标是否都被轨迹执行。这样过滤出的轨迹不只是「最终到达了目标」，而是「沿着正确路径，以正确方式到达的」。这对蒸馏学生模型的行为先验尤其重要——错误的示范路径会直接污染先验学习。
数据量的局限：Uni-GUI 的总量并不大（~1.1 万条），这反映了高质量交互轨迹的收集成本。作者选择质量而非数量，这与 UI-MOPD 的设计取向一致——MOPD 的在线 RL 本身也是数据效率更高的方法，不像 SFT 那样完全依赖静态数据规模。
🔬 方法：UI-MOPD
UI-MOPD 是两阶段训练：Stage 1 分别用 Uni-GUI 数据对 Qwen3-VL-32B 做平台专属 SFT，得到桌面教师 π^d 和移动教师 π^m。Stage 2 用 Qwen3-VL-8B 作为共享学生，在在线 rollout 中根据平台来源路由到对应教师，通过 K3 估计量计算 token 级 KL 蒸馏损失 + 任务奖励联合优化。
核心设计原则：宿主无关的行为路由
学生是单一共享策略，推理时不需要额外模型。但训练时，每一个 rollout 根据其来自哪个平台，配对到对应的平台专属教师。
Stage 1 — 平台专属教师 SFT - 基座：Qwen3-VL-32B-Thinking - 分别在 Uni-GUI 桌面数据和移动数据上独立 SFT - 产出：桌面教师 π^d_ref 和移动教师 π^m_ref
Stage 2 — 多教师在线蒸馏（MOPD） - 学生：Qwen3-VL-8B-Thinking - 混合平台 prompts 送入学生采样 rollouts - Mini-batch 按平台分组，分别计算对应教师的 log 概率 - 合并后用 K3 估计量计算 token 级 KL 散度
在线（on-policy）蒸馏 vs 离线模仿：学生仅在自己实际访问过的 token 状态上接受教师监督，而不是对所有教师行为进行离线模仿。这避免了 covariate shift：学生不会在自己从未采样过的状态上被惩罚。
K3 估计量（避免全词表 KL 计算的开销）： - δ_t = log π_ref(y_t|h_t) − log π_θ(y_t|h_t) - ρ_t = exp(δ_t) - D̂_KL^(t) = ρ_t − δ_t − 1 - 性质：非负、在学生样本下无偏、方差低于直接 log-ratio 估计量
自适应 KL 掩码：当组内平均奖励 > 阈值 τ_KL 时，关闭该 rollout 的 KL 损失——高奖励时允许学生自由探索，低奖励时才引入教师约束。
奖励设计：按 action JSON 正确性评分：全对 = +1.0，部分匹配 = −0.5，不可解析 = −1.0。
联合目标：L(θ) = L_PG(θ) + β · L_MOPD(θ)，其中 β = 0.01。
为什么选 K3 而不是标准 KL？
精确 KL 散度需要对整个词表（32K-128K tokens）计算 softmax 概率，每个 token 位置都要一次前向传播，计算成本极高。在 RL 训练的 rollout 循环中，需要对每个采样序列的每个 token 位置计算教师概率，直接计算全词表 KL 是不可行的。
K3 估计量只需要在实际采样到的 token y_t 上计算教师概率 π_ref(y_t|h_t)——这是一个 O(1) 的查表操作而非 O(V) 的全词表 softmax。估计量在学生分布下是无偏的，且非负性保证了 KL 损失不会变为负值（避免梯度方向异常）。
自适应 KL 掩码的微妙之处
在 GRPO 类的 agentic RL 中，奖励信号本身已经承担了“告诉模型做什么“的职责。当某条 rollout 的奖励足够高（模型已经自己找到了正确动作），再强加教师 KL 约束反而会压制有益的探索变化。
自适应掩码把 KL 约束限制在“模型还没学好“的情况下——效果是教师在关键时刻给予指导，而不是对所有 rollout 施加平坦的平均化压力。这与 A-TMA 的“状态感知“有异曲同工之妙：都是在需要时才施加约束。
教师路由的实现细节
路由基于数据来源标签（数据采集时记录），不涉及环境状态的实时分类。两个教师模型在训练时并行运行，每个处理自己平台的 mini-batch，计算 log 概率后按原始顺序合并回批次。学生推理时完全不需要教师——两个 32B 教师仅在 Stage 2 训练时存在，推理时学生以 8B 单模型运行。
训练规模：64 张 H100（8节点×8卡），用 verl + Megatron-Core + SGLang 异步 rollout，1 epoch 完成 Stage 2 训练。
📊 结果
UI-MOPD 在 OSWorld 达到 38.2%（+4.3pp vs 8B base），在 MobileWorld 达到 12.0%（+4.3pp），同时超越了所有对比集成策略。关键发现：TIES 模型合并在 MobileWorld 直接崩溃至 0%，8B 学生在 MobileWorld 上超过了 32B base 模型。
主要结果（OSWorld + MobileWorld）
| 方法 | OSWorld | MobileWorld | |------|---------|-------------| | Qwen3-VL-8B-Thinking（base） | 33.9% | 7.7% | | Qwen3-VL-32B-Thinking（base） | 41.0% | 9.4% | | Qwen3-VL-235B-A22B-Thinking | 38.1% | — | | Mixed-SFT | 35.0% | 6.4% | | Model Merge（Weight Avg） | 36.5% | 6.8% | | Model Merge（TIES） | 36.8% | 0% | | GUI-Owl-7B | 34.9% | 4.5% | | UI-MOPD | 38.2% | 12.0% |
三个关键发现：
1. TIES 合并在 MobileWorld 崩溃：0% 表明桌面和移动端的权重方向根本不兼容，强行插值完全破坏了移动端能力。
2. 8B 学生超越 32B base 的 MobileWorld 性能（12.0% vs 9.4%）：说明提升不来自规模，而来自平台条件化的训练策略。
3. 双平台同时提升 +4.3pp：唯一同时在两个平台都超越 base model 的方法。GUI-Owl-7B 在桌面尚可（34.9%）但移动端只有 4.5%——典型的“跷跷板效应“。
静态 GUI 理解基准：UI-MOPD 在 AndroidControl★ 上也超越 base（80.05% vs 78.73%），而 TIES 合并在所有静态基准上都有退化（AndroidControl★ 74.01%）。
为什么 MOPD 比 SFT 更抗遗忘？
单平台 SFT 导致 MobileWorld 跌至 0% 的根本原因是：SFT 的损失函数对所有 token 施加均等的拟合压力，而桌面和移动端的 action token 分布完全不同。当在 OSWorld 数据上 SFT 时，模型的参数向桌面方向更新，主动“遗忘“了移动端的 action 模式。
MOPD 的抗遗忘机制来自多方面： - 在线 rollout：学生必须在真实环境中采样，自然形成对两个平台的覆盖 - 平台条件化 KL：移动端 rollout 向移动教师看齐，不受桌面梯度干扰 - 自适应掩码：高奖励的 rollout 不受 KL 约束，允许在已掌握任务上自由变化
MobileWorld 超越 32B 的含义
32B base 模型本身没有经过 GUI 专门训练，所以 8B 学生通过两阶段 MOPD 超过它是可能的。但更深层的含义是：8B 学生获得了 32B Mobile 教师的行为先验（35 → 16.2%），而不只是规模优势。8B 从 7.7% 到 12.0%，跨越了“几乎没有移动端能力“到“达到专家教师 74%“的跳跃。这个增益来自平台专属行为的有效转移，而不是规模。
对 agentic RL 的启发：传统 GRPO/PPO 的奖励设计通常只区分对/错，UI-MOPD 的部分匹配奖励（部分正确 = −0.5）创造了更细粒度的学习信号——action 的各个维度（类型、坐标、文本）可以独立评分，这在 GUI agent 这类 structured output 任务中尤为重要。
💡 核心价值
UI-MOPD 的核心洞察是：跨平台 GUI agent 的正确姿态不是“共享所有“，而是“共享执行，区分先验“。这一思路——通过在线蒸馏而非静态合并来维护平台专属知识——对一切需要“保留多种能力“的 agent 训练场景都有参考价值。
为什么这个工作重要
跨平台 GUI agent 是持续 agent 能力扩展的缩影：一个 agent 需要在不失去已有能力的前提下，持续获取新领域的技能。UI-MOPD 提供的答案不是“更多数据“或“更大模型“，而是训练范式的转变：用在线蒸馏替代静态合并。
UIVMOPD 的成功说明：只要两个能力域的表示空间存在语义冲突（桌面 vs 移动），权重级别的合并注定失败，需要在更细粒度的训练信号层面区分处理。
对你领域的直接影响
- Agentic RL 设计：部分匹配奖励 + 自适应 KL 掩码是两个可复用的设计模式
- 多任务 agent 训练：平台路由 → 教师路由的框架可直接迁移到其他能力域（代码/数学/推理联合训练中的“能力跷跷板“问题）
- 数据效率：MOPD 用 1 epoch Stage 2 训练就超越了 235B 模型，说明在线蒸馏的数据效率远高于单纯扩大 SFT 数据规模
局限性 - 教师模型（32B × 2）在训练期间始终需要在线运行，推理显存开销是 8B 学生的 8 倍以上 - Uni-GUI 总量偏小（~1 万条），桌面和移动的数据分布仍不均衡（~7K vs ~3.7K 轨迹） - 实验仅覆盖两个平台；Web（浏览器 agent）等第三个平台的持续扩展尚未验证 - 成功率绝对值仍然偏低（38.2% / 12.0%），说明跨平台 GUI 任务的复杂性远超当前能力边界
与多 agent 训练共识的对比
当前 LLM 后训练的主流做法是“混合 RL“：把所有能力域的奖励混入同一个 RL loop，让模型自己平衡。DeepSeek-V4 用 10+ 教师也是这个路径。UI-MOPD 在 GUI domain 的发现与之形成有趣对比：GUI 的桌面/移动能力冲突比 LLM 的数学/代码/写作冲突更尖锐（action space 级别不同），因此更需要显式的平台区分训练信号。
这提出一个开放问题：能力域的语义距离是否是决定“混合 vs 区分训练“哪种更优的关键变量？ 数学和代码的 token 分布有大量重叠（都用变量、等式、逻辑），而桌面 action JSON 和移动 action JSON 的格式几乎没有重叠。
持续学习框架的定位
UI-MOPD 的 Stage 2 本质上是 Elastic Weight Consolidation（EWC）的 RL 版本：用教师分布作为“重要参数分布“的代理，在学习新能力时惩罚偏离教师太远。K3 估计量是这个框架的工程实现——把 EWC 的参数重要性估计替换为更轻量、更适应在线 RL 场景的 token 级 KL 估计。
未来方向
1. 三平台+：Web agent（浏览器交互）作为第三个平台，测试 MOPD 是否能线性扩展 2. 教师蒸馏 vs 自蒸馏：能否用学生自身早期 checkpoint 作为教师，避免 2×32B 的推理开销 3. 任务级路由 vs 平台级路由：是否可以更细粒度地按任务类型（文件操作 vs 浏览器 vs 设置）路由到专属教师 4. Uni-GUI 开源：若数据集公开，能大幅降低社区进入跨平台 GUI agent 研究的门槛