苹果这次没发模型，发的是一套训练流水线：一个 8B 的规划模型被丢进 512 台并发的虚拟 iOS 设备里在线跑强化学习，交出来的成绩单是——在真实 iOS 应用基准 UINavBench 上拿到 32.4%，与 Gemini-3.1-Pro 持平。

论文自己的评测摆在这里（arXiv:2610.39264）：PPO 训到第 336 步（对应两个 epoch）时，UINavBench 32.4%、iOSWorld 2.3%、AndroidWorld 32.8%；同一架构的 SFT 基线分别是 16.7%、4.5%、4.7%。数字很硬，但同一张表里还藏着论文自己写出的坏消息。

训练环境：把真机做成可回滚的沙盒

在线 RL 的瓶颈从来不是算法，而是环境要能并发、要能回滚。论文把 iOS 设备跑在云端虚拟机上：装好应用、用 Apple ID 登录后存成快照，一个 episode 结束就回滚快照而不是销毁会话，重启延迟压到约 10 秒。设备通过 VNC 通道用类型化动作接口驱动（tap、swipe、type、long press、home、wait）。训练时能同时跑 512 条轨迹，每条独占一台设备。

拆成规划与定位两半

架构上最直接的一步是解耦：规划智能体只负责想，定位模型只负责把意图翻译成屏幕上的 x,y 坐标。规划智能体从 Qwen3-VL-8B-Instruct 起步，先用人工标注轨迹做 SFT，数据来自三份：两份自建的 iOS 应用数据（一方应用与三方应用各一），加上公开的 GUIOdyssey——后者是 Android 数据，论文只取它的多应用轨迹，补上自建数据缺失的"切应用"行为。三份数据都不带思维链标注，CoT 和剩余计划由 Gemini 生成。

定位侧是自研的 3B dense 模型，留出测试集准确率超过 90%，但只支持方向性滑动，滑动指令被路由给 Gemini-3.5-Flash。动作原语七个：Tap、Swipe、Text_Entry、Navigate_Home、Long_Press、Ask_User、Task_Complete。

奖励：两个裁判，和一次反作弊

奖励全部由 LLM 当裁判产生，这个 LLM-as-a-Judge 机制分两层。密集裁判是 Gemini-3.5-Flash，每步都调用，看动作前后的截图，判断是 success、fail 还是 overcomplete——前后截图必须显示真的在推进任务，且推理和动作都要与界面状态对得上，靠幻觉推理蒙对进度按失败算，重复失败动作的空转循环也会被罚，任务已完成还在动手则记 overcomplete。终局裁判是 Gemini-3.1-Pro，看最后三张截图加完整动作历史，输出 success、fail 或 blocked_complete；第三种专门保护"撞上付费墙或 CAPTCHA 这种外部屏障"的情况，避免智能体为无法执行的状态背锅。

奖励函数还防了一手：密集奖励按 γ=1/2 折扣，终局奖励不折扣。步级奖励会让智能体人为拉长轨迹来刷分，不折扣的终局奖励保证"任务真的完成"这个目标不被稀释。

GiGPPO：把"长得像的屏幕"喂给 critic

这篇的一个技术增量叫 GiGPPO。起点是 GRPO 和 GiGPO：拿同一任务的多条 rollout 互相比较来估价值。但 GiGPO 依赖状态精确重复，UI 场景里几乎不存在——每个任务只采 4 条或 8 条 rollout，按状态相等分组基本退化成单点样本；放宽成"屏幕相似"又会把偏差直接灌进 critic。

GiGPPO 的做法是绕开平均：每个状态在同任务的兄弟轨迹里找 64 位感知哈希汉明距离最近的屏幕作为邻居，再用一个多层感知机从状态与邻居的隐层表示、邻居的折扣密集奖励加不折扣终局奖励、以及两屏之间的汉明距离，直接预测 V。效果是收敛更快：在 UINavBench 上，GiGPPO 训到第 75 步和第 168 步，已接近普通 PPO 训到第 168 步和第 336 步。

跑分表：赢在哪，输在哪

先看赢的部分。UINavBench 包含 36 个真实 iOS 应用、116 个任务，是三个基准里跟训练环境最接近的：PPO 第 336 步 32.4%，跟 Gemini-3.1-Pro 的 32.4% 持平，高于 Gemini-3.5-Flash 的 28.4% 和 Qwen3.8-27B 的 19.6%，比 SFT 基线 16.7% 高出近一倍。AndroidWorld 是域外泛化测试（20 个真实应用、116 个任务），PPO 第 336 步 32.8%，相对 SFT 的 4.7% 接近七倍——论文强调这说明学到的是可迁移的导航策略，不是死记 iOS 轨迹。

再看输的部分。iOSWorld 有 133 个任务、26 个合成应用，其中 46 个专门考个性化偏好。PPO 第 336 步在这个基准上只有 2.3%，比自家 SFT 基线的 4.5% 还低——真实应用上训练得越久，合成应用上反而越差。论文给了个失败样貌：智能体按名字搜索某个合成应用时撞上与真实 iOS 应用重名，于是跑去 App Store 试图安装它；或者认定它是网页服务，去 Safari 里搜。这是把训练出来的先验拧到了错误方向上。

另一处落差来自定位模型的替换。附录拿 SFT 训出的规划智能体做对照：UINavBench 上纯 3B 定位是 12.7%，换成 Gemini-3.5-Flash 是 14.7%，3B 主力加 Gemini 只接滑动是 16.7%；iOSWorld 上混合配置只有 1.5%，比纯 3B 的 3.0% 还差。被讨论的"这个智能体"其实是三件东西叠出来的，换一个组件成绩就动。

我的判断

第一，"追平 Gemini-3.1-Pro"只在真实应用基准上成立，代价是合成应用基准的塌方。这不是实现瑕疵，而是训练分布直接决定了泛化边界：真实 iOS 数据教会了它 iOS 的样子，合成应用长得不像。

第二，这套赛制里，对手还在当裁判。密集裁判是 Gemini-3.5-Flash，终局裁判是 Gemini-3.1-Pro，滑动定位交给 Gemini-3.5-Flash，模拟用户也是 Gemini-3.5-Flash。所以"8B 追平 Gemini-3.1-Pro"在方法上不算错——它是在同一个解码-执行框架里比较——但它是论文自测，没有第三方复现，评分还大量依赖闭源模型。

第三，真正可迁移的大概不是那 32.4%，而是那份配方：规划与定位解耦、密集加终局双层奖励配不对称折扣、设备农场用快照回滚换取并发、GiGPPO 用感知哈希邻居替代精确重复状态。另一条同期路线来自开源框架 ClawGUI，其 ClawGUI-2B 在 MobileWorld GUI-Only 上是 17.1%（arXiv:2604.11784）。两条路线都在使劲：让 GUI 智能体在真实交互里学会犯错后怎么爬起来。