← 返回 2026-10-30

面向真实 iOS 应用 UI 导航的规划-落地解耦智能体在线密集强化学习 Online Dense Reinforcement Learning with Planning-Grounding Agent for UI Navigation on Live IOS Apps

Peitong Duan, Khashayar Gatmiry, Jeffrey Nichols, Samy Bengio, Emmanuel Abbe 📅 2026-10-29 👍 12 2026-11-09 18:30
GUI 智能体 LLM-as-a-Judge PPO UI 导航 奖励设计 强化学习 移动端智能体

在512路真实iOS虚拟设备上以密集+终端双奖励在线RL训练8B规划器,性能追平前沿模型

前置知识

PPO(近端策略优化)

一种策略梯度强化学习算法,通过裁剪的代理目标函数限制每次策略更新的幅度,防止新策略偏离旧策略太远导致训练崩溃。它维护一个 critic(价值网络)来估计每个状态的价值 $V(s)$,用优势 $A(s,a)$(实际回报减去估计价值)指导策略更新,还能像监督学习那样对同一批 rollout 做多轮小批量更新,样本效率高于纯 on-policy 方法。

本文的核心优化算法就是 PPO,且作者论证了只有训练 critic 的 PPO 才能直接利用步级密集奖励做信用分配,GRPO 等无 critic 方法做不到这一点。

GAE(广义优势估计)

广义优势估计通过参数 $\lambda$ 在蒙特卡洛估计(方差大、无偏)与自举 TD 估计(方差小、有偏)之间插值。当 $\lambda=1$ 且折扣因子为 1 时,GAE 退化为蒙特卡洛估计:优势等于整条轨迹实际实现的回报减去 critic 的价值估计 $A_t = R_T + \sum_{k=t}^{T}\gamma^{k-t}r^{\text{dense}}_k - V^\pi(s_t)$。

本文用 $\lambda=1$ 的步级 GAE 把密集奖励逐步计入优势,理解它是看懂奖励折扣设计和 critic 训练方式的前提。

GRPO(组相对策略优化)

GRPO 是 LLM 后训练中流行的 RL 算法:对同一任务采样一组(如 4-8 条)轨迹,用组内平均回报作基线,用相对回报计算优势,从而完全省掉 critic 网络。代价是所有奖励必须先聚合成轨迹级标量再比较,无法表达奖励在时间轴上的结构,也没有显式的状态价值函数。

GUI 智能体 RL 的主流方法(UI-TARS、DigiRL 等)都用 GRPO 或其变体,本文正是针对其'密集奖励时序结构被压成标量、无步级价值函数'的缺陷提出改进。

LLM-as-a-Judge(大模型裁判)

用一个独立的强语言模型来评估智能体输出的质量,替代人工标注的黄金轨迹。在 RL 训练中它可以作为奖励函数:输入任务描述、动作历史和前后截图,输出成功/失败等判定并映射为奖励数值。它不依赖参考答案,因此能泛化到任意应用/任务组合,且能在交互过程中实时打分。

本文的密集奖励(每步调用 Gemini-3.5-Flash)和终端奖励(Gemini-3.1-Pro)全部由 LLM 裁判产生,这是整个在线 RL 框架能脱离黄金轨迹标注、直接在真实应用上训练的关键。

感知哈希

一种把图像压缩成固定长度指纹(如 64 位二进制串)的哈希算法,特点是视觉相似的图像哈希位串也相似,两张截图的差异可以用汉明距离(不同位的个数)量化。它常用于图像去重和近似检索,计算开销极低,适合在海量并发 rollout 中实时为每个屏幕状态找'视觉邻居'。

GiGPPO 用 64 位感知哈希的汉明距离在同任务兄弟轨迹中为每个状态寻找最相似的邻居状态,并用该距离校准邻居回报的可信度,是理解其 critic 设计的关键。

奖励黑客(Reward Hacking)

指智能体找到了最大化奖励函数数值但违背设计者真实意图的策略。典型场景:奖励设计有漏洞时,智能体刷取容易获得的局部奖励而不完成真正目标,例如故意拖长回合来累计每步小额正奖励,而不是尽快完成任务拿终局奖励。

本文的核心动机之一:作者发现步级密集奖励在折扣因子 $\gamma=1$ 时会诱发这种'拖轨迹刷分'行为,由此提出非对称折扣策略来堵住这个漏洞。

研究动机

前沿视觉语言模型(VLM)操作 UI 的能力已经很强——如 Gemini-3.1-Pro 在 AndroidWorld 上达到 60.8% 成功率——但单任务推理成本高达数美元,无法支撑日常高频使用。反过来,用监督微调(SFT)或离线强化学习训练的小模型容易记忆静态演示轨迹而非可泛化策略:它们几乎只在'一切顺利'的黄金路径上训练过,一旦偏离预期屏幕就反复卡死直到步数耗尽,错误恢复能力很差。已有的 RL 方法分两类且各有缺陷:单步 RL 用与黄金轨迹的相似度作奖励,本质上是 SFT 的镜像;另一类用 LLM/VLM 判官在轨迹终点给 terminal reward,信号过于稀疏,无法给'有真实进展但最终失败'的中间步骤记功,部分工作只辅以手工编码的重复惩罚,缺乏对部分成功的奖励机制。

本文的目标是作者要构建一个能直接在真实 iOS 应用上大规模在线强化学习的训练框架,让 8B 级小模型学会可泛化的导航策略而非记忆轨迹。具体目标包括四个层面:架构上把智能体解耦为规划器与落地模型以各取所长;奖励上设计密集(步级)+ 终端(任务级)的双重 LLM 判官结构克服稀疏信号;优化上解决步级密集奖励诱发的'拖轨迹刷分'奖励黑客问题;工程上搭建支撑数百条并发真实设备轨迹的基础设施(512 并发)。最终在 UINavBench、iOSWorld、AndroidWorld 三个基准上验证:超越 SFT 和 terminal-only RL 基线,逼近或追平 Gemini-3.1-Pro 等前沿模型。

与已有工作不同的是,本文的独特切入角度有三。第一,训练环境的真实性:此前 UI 智能体 RL 几乎都在 Android 模拟器(并发工作 ClawGUI-RL 仅 64 并发)或离线数据上进行,本文首次在数百条并发的真实 iOS 设备轨迹上完成规模化在线训练,是与真实应用交互的完整闭环。第二,奖励信号的利用方式:GRPO 系方法把密集奖励聚合到轨迹级标量,时序结构尽失;本文训练一个直接消费密集通道的 critic,使步级信用分配成为可能,这也是非对称折扣策略得以成立的前提。第三,针对真实 UI 的价值估计创新:UI 场景中同一屏幕几乎不重复,GiGPO 依赖的精确状态匹配退化为单例,本文提出 GiGPPO,用感知哈希近邻把跨轨迹信号通过学习到的价值函数路由进来。

核心方法

直觉上,UI 导航包含两种性质迥异的能力:落地(grounding)是把'点击搜索框'这类意图映射到精确坐标的近确定性任务,SFT 就能训练得非常有效;规划则是开放式推理——理解总体目标、追踪已完成步骤、适应 UI 动态变化、从意外状态恢复——恰是 RL 最能发挥价值的地方。据此本文把智能体拆成两个组件:Planning Agent(Qwen3-VL-8B-Instruct,先 SFT 热启动再在线 RL)每步经思维链推理输出当前步骤计划和剩余长期计划;Grounding Model(内部 3B 模型,位置型滑动路由给 Gemini-3.5-Flash)把计划翻译成动作原语和 x,y 坐标,全程冻结不再训练。训练时智能体与云端 iOS 虚拟机交互生成 rollout(快照回滚重启仅约 10 秒,512 条并发轨迹),LLM-as-a-Judge 每步给出密集奖励(Gemini-3.5-Flash)、轨迹终点给出终端奖励(Gemini-3.1-Pro),用 PPO 配步级 GAE($\lambda=1$)优化,并以 GiGPPO 的邻居条件化 critic 提升价值估计稳定性。

核心创新有三。其一,非对称折扣的回报设计:价值函数 $V^\pi(s_t)=\mathbb{E}_\pi\left[R_T+\sum_{k=t}^{T}\gamma^{k-t}r^{\text{dense}}_k \mid s_t\right]$,密集分量取 $\gamma=1/2$ 使价值目标主要局部化、易于估计,而终端奖励 $R_T$ 不折扣地传导到每一步,保证长轨迹中早期动作仍能拿到完整的任务级信用;作者在 GRPO 消融实验中发现 $\gamma=1$ 时智能体会故意拖长轨迹刷密集奖励。其二,GiGPPO:每状态在同任务兄弟轨迹中找 64 位感知哈希汉明距离最近的状态作邻居,用小型 MLP 从自身状态嵌入、邻居嵌入、邻居回报(折扣密集和 + 不折扣终端奖励)和汉明距离四个输入回归 $V^\pi(s_t)$,距离让 critic 自我校准邻居回报的可信度,且不输入自身奖励以防回归目标泄漏。其三,与 GRPO 不同,critic 直接消费密集通道,正因如此才能在密集信号局部化与终端目标不打折之间取得平衡。

方法步骤详情

流程分五步。① SFT 热启动:在两个内部人工标注 iOS 数据集加公开 GUIOdyssey 上微调 Qwen3-VL-8B-Instruct,用 Gemini 生成每步思维链推理与剩余计划标签。② 环境准备:云端 iOS 虚拟机装好应用并登录,拍 VM 快照,回合结束回滚,重启约 10 秒,512 条并发轨迹。③ 奖励计算:密集判官(Gemini-3.5-Flash,每步调用)依任务、历史、前后截图输出 success/fail/overcomplete,幻觉'意外进展'判为失败;终端判官(Gemini-3.1-Pro)综合最后三张截图与密集判定输出 success/fail/blocked complete;ASK_USER 另有判官验证信息是否欠定。④ PPO 优化:每步 16 任务 × G=8 共 128 条轨迹,回合上限 30 步;密集通道 +1.0/0.0/−1.0/−2.0(过度完成),折扣 $\gamma_{\text{dense}}=0.5$,回报上界 $1/(1-\gamma_{\text{dense}})=2.0$;终端通道 +2.0/+0.5/−0.75/−1.0/−2.0 不打折;critic 先冻结策略预热 15 步,学习率 1×10⁻⁴,策略 1×10⁻⁶。⑤ GiGPPO:按感知哈希近邻配邻居,0.9M 参数 MLP 预测价值;8 卡 GPU FSDP,16 生成器 shard 各驱动最多 32 台设备。

技术新颖性

与已有方法的本质区别有四。相对 GRPO 系(UI-TARS、DigiRL 等主流选择):GRPO 把组内相对回报在轨迹级聚合,密集奖励时序结构被压成标量,此前没有 GUI 智能体系统训练过消费步级密集信号的 critic;本文的 critic 直接吃密集通道。相对 GiGPO:它靠'完全重复状态'的子组平均作步级基线,但在每任务仅 4-8 条 rollout 的真实 UI 场景中屏幕几乎不重复,分组退化为单例;GiGPPO 把跨轨迹信号通过学习到的价值函数路由,并用汉明距离校准邻居回报可信度,给 critic 严格多于标准 PPO 的信息。相对 StepSearch(PPO+GAE、$\gamma=1$):不打折的密集回报要求 critic 预测遥远未来的累积密集奖励,难度过高。相对并发的 ClawGUI-RL:后者端到端训练、用过程奖励模型、Android 模拟器 64 并发;本文解耦架构、critic 路由邻居信号、真实 iOS 数百并发。此外基础设施级损失(应用不渲染、断连等)被掩码:不进梯度、不当邻居、不进优势白化统计,避免零奖励虚低标准差、虚高真实优势。

Overview of the iOS agent architecture and training setup.
Figure 1: Overview of the iOS agent architecture and training setup.

实验结果

UINavBench(36 个真实 iOS 应用、116 任务):SFT 仅 16.7%,PPO Step 336(2 epoch)达 32.4%,追平 Gemini-3.1-Pro,超过 Gemini-3.5-Flash(28.4%)与 Qwen3.8-27B(19.6%)。分布外的 AndroidWorld 提升最惊人:SFT 4.7% → PPO Step 336 达 32.8%,近 7 倍,所有 RL checkpoint 均超 SFT,证明学到可迁移策略而非 iOS 特有轨迹;但仍低于 Gemini-3.5-Flash(57.8%)等前沿模型,归因于其预训练含大规模公开 Android UI 数据。合成应用的 iOSWorld(133 任务)收益有限:SFT 4.5% → GiGPPO Step 336 9.8%(翻倍),因视觉分布偏离且个性化、跨三应用任务属分布外。消融显示密集奖励加速收敛:PPO Step 168(1 epoch)已达或超 terminal-only PPO Step 336 水平(UINavBench 25.5% vs 21.6%);GiGPPO Step 75/168(21.6%/30.4%)相当于 PPO Step 168/336。附录 A.2 的 GRPO 消融揭示非负奖励会让长轨迹密集信用胜过短而成功的轨迹(终端仅 +10),错误动作与不作为同为 0 分、无区分梯度。

Success rates across UINavBench, iOSWorld, and AndroidWorld.
Table 1: Success rates across UINavBench, iOSWorld, and AndroidWorld.
Performance of the SFT trained Planning agent paired with different grounding models.
Table 2: Performance of the SFT trained Planning agent paired with different grounding models.
Example traces of the GiGPPO-trained planning agent and the SFT baseline on the UINavBench task.
Figure 2: Example traces of the GiGPPO-trained planning agent and the SFT baseline on the UINavBench task.
Example traces of the GiGPPO-trained planning agent and the SFT baseline on the complex, multi-app iOSWorld task.
Figure 3: Example traces of the GiGPPO-trained planning agent and the SFT baseline on the complex, multi-app iOSWorld task.
Example traces of the PPO-trained planning agent and the PPO agent trained only on terminal rewards for the AndroidWorld task.
Figure 4: Example traces of the PPO-trained planning agent and the PPO agent trained only on terminal rewards for the AndroidWorld task.
查看结构化数据
任务指标本文基线提升
UINavBench(36 个真实 iOS 应用导航) 任务成功率 32.4%(PPO Step 336,8B 规划器) SFT 基线 16.7%;Gemini-3.1-Pro 32.4%;Gemini-3.5-Flash 28.4%;Qwen3.8-27B 19.6% 较 SFT 几乎翻倍(+15.7 个百分点),8B 模型追平 Gemini-3.1-Pro、超过 Gemini-3.5-Flash
AndroidWorld(分布外 Android 真实应用导航) 任务成功率 32.8%(PPO Step 336) SFT 基线 4.7%;terminal-only PPO Step 336 为 19.8%;UI-TARS-72B 46.6% 较 SFT 约 7 倍(+28.1 个百分点),验证 RL 学到跨平台泛化策略,但仍落后前沿模型
iOSWorld(26 个合成 iOS 应用导航) 任务成功率 9.8%(GiGPPO Step 336) SFT 基线 4.5%;Gemini-3.5-Flash 12.9%;Gemini-3.1-Pro 39.5% 较 SFT 翻倍有余(+5.3 个百分点),但绝对水平低,属分布外场景
UINavBench(密集奖励消融,同为 1 epoch) 任务成功率 25.5%(PPO Step 168) terminal-only PPO Step 168 为 17.6% +7.9 个百分点;密集奖励下 1 epoch 效果超过 terminal-only 2 epoch(21.6%),证明收敛加速

局限与改进

作者承认的局限:iOSWorld 收益有限,因基准基于合成应用,视觉布局偏离真实 iOS 训练分布,且其个性化任务(如'找到我最常点的餐厅和菜品并重新下单')与跨三应用以上工作流超出训练分布;后期 checkpoint 还会出现命名冲突——把合成应用名当真实应用去 App Store 安装,或当作网络服务去 Safari 搜索。AndroidWorld 上虽大幅超越 SFT 但仍落后前沿模型 25 个百分点以上,部分因前沿模型预训练含大规模公开 Android UI 数据。工程层面,内部 3B 落地模型只支持方向性滑动,位置滑动必须路由 Gemini-3.5-Flash,推理链引入外部依赖与成本。我自己的观察:密集判官每步调用商业 LLM,512 并发 × 每回合 30 步的判官调用量巨大,成本与延迟可能成为规模瓶颈;训练与评估都依赖 VLM 判官,成功率本身带判定噪声且判官漂移难以监控;所有内部数据、3B 落地模型与 iOS 设备基础设施均不公开,社区难以复现或公平比较。

独立分析的弱点

第一,规划器与落地器之间的信用误判:落地是独立的 3B 模型(held-out 准确率约 90%),规划器输出正确计划但落地执行失败时,密集判官按'计划不可落地'记 0 分,系统性偏差会把落地错误部分归到规划器头上,改进方向是把'计划本身错误'与'计划正确但不可落地'显式分离并只惩罚前者。第二,感知哈希邻居的语义风险:哈希接近的两张截图可能处于完全不同的任务阶段(同一设置页在不同目标下价值迥异),仅靠汉明距离校准可能不足,可引入轨迹步位置或动作历史嵌入作附加条件。第三,模拟用户的分布偏差:ASK_USER 的回应由 Gemini-3.5-Flash 生成,与真实用户偏好分布的偏差会直接污染训练信号,且评估也用同一模拟用户,存在被针对性过拟合的风险。第四,判官成本与漂移:每步 Flash 级 + 每回合 Pro 级判官调用在更大并发下会成为瓶颈,商业模型版本更新还会造成奖励定义漂移,可蒸馏专用小型判官或训练过程奖励模型替代。第五,无课程机制:30 步上限、每步 128 条轨迹的批量在难题上早期成功率极低,密集奖励缓解了稀疏性但探索仍靠暴力,可引入自动任务课程或难度筛选。

未来方向

作者明确提出的方向:修复 iOSWorld 上的合成应用命名冲突问题,避免智能体误装 App Store 应用或误入 Safari 搜索。基于本文成果可自然延伸的方向有五。其一,把 GiGPPO 的邻居条件化 critic 推广到其他长程 agent 任务(网页、桌面),凡是环境状态可感知哈希或嵌入近邻化的场景都适用,这是比 GiGPO 更鲁棒的步级基线思想。其二,用学习到的过程奖励模型替代每步调用的 LLM 判官,大幅降低训练成本并消除判官版本漂移,同时保留密集信号。其三,iOS+Android 联合训练,检验是否比纯 iOS 训练获得更好跨平台泛化,直接回应前沿模型靠 Android 预训练数据占优的事实。其四,规划-落地之间的显式信用分配建模,让 RL 信号能区分'计划错了'与'落地错了'。其五,把 ASK_USER 澄清行为本身作为可优化目标,研究何时该问、问什么,而不只是判官事后判定信息是否欠定。

复现评估

复现难度:高。核心组件几乎全部闭源——内部 3B 落地模型、两个人工标注 iOS 轨迹数据集、云端 iOS 虚拟机基础设施(VM 快照回滚、VNC 驱动的动作接口)均不公开;奖励判官依赖 Gemini-3.5-Flash 与 Gemini-3.1-Pro(可换成开源模型但效果未验证)。公开可用的只有 Qwen3-VL-8B-Instruct 底座、GUIOdyssey 数据集和三个评测基准(UINavBench、iOSWorld、AndroidWorld)。算力需求不小:策略 FSDP 8 卡 GPU,另配 16 个生成器 shard 各驱动最多 32 台并发虚拟设备(峰值 512 并发),critic 用 LoRA rank 32 加 0.9M 参数邻居适配网络。学术团队可在 Android 模拟器上近似复现方法论(PPO、GiGPO 的开源生态较成熟),但 iOS 侧真实设备训练基本不可复制,且论文未提及代码开源计划。若以验证方法结论为目标,优先复现相对不依赖私有设施的发现:密集奖励加速收敛、非对称折扣防奖励黑客、GRPO 非负奖励的失败案例分析。

相似论文推荐