为智能体手机使用训练开放模型 Training Open Models for Agentic Phone Use
结合真实与模拟应用环境的手机代理训练方法，大幅提升任务成功率
前置知识
强化学习
强化学习是一种机器学习方法，智能体通过与环境的交互获得奖励信号来优化其策略。在每一步，智能体根据当前状态选择动作，环境反馈下一个状态和奖励。目标是通过最大化长期累积奖励来学习最优策略。常用算法包括PPO、DPO等，训练过程涉及exploration-exploitation平衡和reward shaping。
本文的核心就是比较不同环境（真实vs模拟）下的强化学习效果，理解RL的基本原理有助于理解作者为什么选择混合训练策略以及如何设计reward函数。
监督微调
监督微调是指在预训练模型的基础上，使用标注好的数据进行进一步的训练。训练数据通常是输入-输出对，模型通过最小化预测输出与真实标签之间的差异（如交叉熵损失）来学习特定任务。在本文中，SFT阶段使用从真实和模拟环境中收集的手机操作轨迹数据，让模型学习基本的动作预测能力。
SFT是PhoneBuddy训练流程的第一阶段，所有后续的RL分支都从这个共享的SFT检查点开始。理解SFT的作用有助于理解作者如何控制变量来隔离RL阶段的影响。
GUI代理
GUI（图形用户界面）代理是能够通过视觉观察和结构化动作空间操作真实软件的AI系统。它需要理解屏幕内容、规划操作步骤、执行触控或键盘动作，并验证任务完成。与传统的基于API的工具调用不同，GUI代理直接面对用户界面，面临更大的状态空间、不确定性以及平台差异。
本文研究的是手机GUI代理的训练问题，与Web和桌面代理相比，手机环境有独特的挑战：触摸交互、权限管理、小程序生态、跨应用工作流等。理解这些特殊性有助于理解为什么作者要专门针对手机环境设计训练方法。
状态重置与自动验证
在强化学习中，状态重置是指将环境恢复到初始状态的能力，这对于重复训练和数据收集至关重要。自动验证是指通过规则或模型判断来判断任务是否完成，而不是依赖人工检查。在模拟环境中，这两个功能容易实现，但在真实应用中则非常困难，因为真实应用有持久化状态、不可逆的副作用和服务器端逻辑。
这是本文的核心方法论基石。作者正是因为认识到真实应用环境难以重置和验证，才构建了PhoneWorld模拟环境，而论文的核心贡献就是研究如何结合这两种环境的优势。
研究动机
现有手机代理研究主要聚焦于GUI感知和动作预测，但缺乏针对真实手机任务完成度的系统性训练方法。真实手机环境具有慢速、有状态、有副作用、难以重置和验证的特点，这使得在真实设备上收集训练轨迹、重置状态和验证任务完成变得极其昂贵。例如，账户依赖的行为、应用特定的业务逻辑、通知状态、设备设置、用户历史数据以及不透明的服务器端逻辑都增加了任务复杂性。虽然可扩展的模拟环境可以降低成本，但只能近似真实行为，存在与现实设备的分布偏移。现有数据集和基准（如AndroidWorld、MobileBench）虽然在屏幕理解和动作预测上有进展，但未解决如何训练模型以提升真实手机任务完成度这一核心问题。
本文的目标是本文的目标是研究如何训练开源手机使用模型，使其能够在真实手机上可靠地完成任务，而不仅仅是改善局部动作模仿或基准特定的交互模式。具体来说，作者想要回答：真实应用环境训练和模拟应用训练应该如何结合，才能最大化真实手机任务的成功率？作者提出了一个三阶段训练流程：共享监督微调、真实应用RL、混合RL，并在150个真实手机任务上评估任务成功率。
与已有工作不同的是，现有工作往往将真实环境和模拟环境视为二选一的选项，要么完全依赖真实环境（成本高但真实），要么完全依赖模拟环境（成本低但可能有分布偏移）。本文的独特切入角度是：这两种环境不是替代关系，而是互补关系。真实应用环境提供真实性，模拟应用环境（PhoneWorld）提供可重置性、可重复性和自动验证能力。作者不声称PhoneWorld可以替代真实应用，也不声称真实应用让模拟应用变得不必要，而是主张将真实应用RL和模拟应用RL结合起来：真实应用RL将模型锚定到真实设备行为和真实副作用，而模拟应用训练从可以重复和可靠检查的任务中提供更广泛、更便宜的交互信号。
核心方法
PhoneBuddy的训练方法包含三个阶段，所有检查点都从相同的Qwen3.5-4B骨干网络开始，并共享相同的SFT初始化、动作接口和评估协议，仅在最终训练分支上有所不同。第一阶段是共享监督微调（SFT），使用从真实应用环境和模拟应用环境中收集的手机使用轨迹数据，建立共同的任务完成起点。第二阶段是强化学习分支，作者比较了两种策略：仅在真实应用环境中进行RL，以及在真实应用和模拟应用混合环境中进行RL。真实应用环境让智能体在物理设备上操作真实应用，暴露账户依赖行为、应用特定不稳定性、权限流程以及表面进展与真实任务完成之间的差距。模拟应用环境PhoneWorld从真实GUI轨迹重建可运行的模拟Android应用，支持状态变化和基于规则的任务完成检查。第三阶段是在真实手机任务上的评估，作者使用统一动作空间、提示模板、步数预算和评估控制装置，仅改变训练配方来比较不同检查点的性能。
核心创新点在于认识到真实应用训练和模拟应用训练解决的是同一问题的不同部分，因此应该结合而不是二选一。真实应用RL锚定模型到真实设备行为、真实应用逻辑和真实副作用，而模拟应用训练PhoneWorld提供规模、重置能力和自动验证。具体来说，真实应用RL主要在部署后期优化真实手机执行，而PhoneWorld从可以重复和可靠检查的任务中添加更广泛、更便宜的交互信号。这种互补性使得模型既能从真实环境的复杂性中学习，又能从模拟环境的规模化和可验证性中受益。另一个关键创新是使用rubric-based模型判断作为真实环境中任务完成的代理，因为许多任务结果依赖于账户特定的或专有的服务器端状态，无法直接从设备接口访问。
方法步骤详情
第一步是共享监督微调阶段。作者从真实应用环境和PhoneWorld模拟环境中收集手机使用轨迹，构建包含950,758个动作步的共享SFT数据集。从Qwen3.5-4B开始，进行全参数微调1,115个优化器步，批大小为512。训练使用打包的8,192-token序列，较短的示例通过注意力掩码连接以提高利用率。学习率从$1 imes 10^{-5}$衰减到$1 imes 10^{-6}$。第二步是强化学习分支。从共享SFT检查点开始，两个RL分支都运行50个在线RL步。在真实应用环境中，使用rubric-based模型判断作为任务完成的代理：对于每条指令，先用Gemini-3.1-Pro-Preview生成特定任务的rubric，然后用Qwen3.5-122B-A10B根据每个rubric项目对轨迹进行评分，只有当所有rubric项目都通过时才认为 rollout 成功。在PhoneWorld环境中，使用内置的基于规则的状态验证器实现自动完成检查，无需模型判断。两种信号都归一化为相同的二元奖励用于策略优化。第三步是评估。作者使用统一动作空间（坐标在[0, 1000]范围内标准化）、提示模板、步数预算（训练时30步，评估时50步）和评估控制装置，在150个真实手机任务和AndroidWorld上评估任务成功率。
技术新颖性
技术新颖性体现在三个方面：首先，这是首个系统性地研究如何在真实和模拟手机环境中训练开放模型以提升真实手机任务完成度的工作。作者不仅构建了PhoneWorld模拟环境，更重要的是实证研究了混合RL的有效性。其次，作者提出的rubric-based模型判断方法巧妙地解决了真实环境中任务完成验证的难题，通过让强大的闭源模型评估轨迹来获得可靠的奖励信号。第三，作者严格控制的实验设计（所有检查点共享骨干网络、SFT初始化、动作接口和评估协议）使得任何任务成功率的差异都可以归因于最终训练阶段的选择，这为理解不同RL环境的价值提供了清晰的证据。此外，作者在AndroidWorld这一外部基准上的结果（从60.3%提升到83.2%）表明该训练配方具有良好的泛化能力，不仅仅在内部benchmark上有效。
实验结果
在150个真实手机人工评估任务中，PhoneBuddy-4B-SFT的平均任务成功率为42.6%（单应用34.0%、跨应用22.0%、微信小程序54.0%、AndroidWorld 60.3%）。PhoneBuddy-4B-Real（真实应用RL后）提升到49.8%（单应用54.0%、跨应用20.0%、微信小程序48.0%、AndroidWorld 77.2%）。PhoneBuddy-4B-Real+Mock（混合RL后）进一步达到54.8%（单应用62.0%、跨应用18.0%、微信小程序56.0%、AndroidWorld 83.2%）。在真实手机评估中，整体成功率从SFT的36.67%提升到真实应用RL的40.67%，再到混合RL的45.33%，总体提升8.66个百分点。在AndroidWorld上，从60.3%提升到77.2%再到83.2%，总体提升22.9个百分点。最显著的提升出现在单应用任务上，从34.0%到54.0%再到62.0%，这是所有比较模型中最好的性能。微信小程序任务显示出不同的模式：真实应用RL单独没有帮助（从54.0%下降到48.0%），但混合RL将分数提升到56.0%，略高于SFT基线。跨应用任务仍然是一个主要弱点，三个检查点的性能都很低（22.0%、20.0%、18.0%），没有观察到当前训练配方的有意义的改进。与闭源模型相比，PhoneBuddy-4B-Real+Mock的平均性能（54.8%）超过了GPT-5.4（48.2%）和Seed 2.0 Pro（51.4%），但仍低于Gemini 3.1 Pro（59.1%）。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 单应用任务 | 任务成功率 | 62.0% | PhoneBuddy-4B-SFT 34.0% | +28.0个百分点 |
| 跨应用任务 | 任务成功率 | 18.0% | PhoneBuddy-4B-SFT 22.0% | -4.0个百分点 |
| 微信小程序任务 | 任务成功率 | 56.0% | PhoneBuddy-4B-SFT 54.0% | +2.0个百分点 |
| AndroidWorld | 任务成功率 | 83.2% | PhoneBuddy-4B-SFT 60.3% | +22.9个百分点 |
| 真实手机整体评估 | 任务成功率 | 45.33% | SFT 36.67% | +8.66个百分点 |
局限与改进
作者承认的主要局限性是跨应用执行仍然是一个明显的弱点。可能的一个因素是任务覆盖：当前的PhoneWorld任务池主要是单应用的，虽然一些结果交互模式似乎可以转移到小程序设置，但它还没有提供对多应用信息传递、artifact转移或持久跨应用状态依赖的直接支持。跨应用任务也可能因为它们更强调长期记忆和运行时协调而仍然具有挑战性，即使有更广泛的环境覆盖，这些任务也可能继续困难。此外，作者明确指出本文有意专注于训练，而可部署的手机代理还需要强大的运行时系统和围绕隐私和安全的清晰部署边界，这些部分对于实际使用很重要，但故意不是本实证报告的中心。我观察到另一个潜在的局限性是训练数据规模相对较小：共享SFT数据集包含950,758个动作步，对于现代大模型训练来说这可能不够大。此外，RL阶段只运行了50个在线步骤，这可能没有充分利用模拟环境的规模化潜力。
独立分析的弱点
首先，跨应用任务的性能下降表明当前的训练配方没有解决信息在不同应用间传递的核心挑战。改进方向是扩展PhoneWorld以明确建模跨应用工作流，包括artifact转移、状态依赖和应用间协调。其次，真实应用RL使用了rubric-based模型判断作为任务完成的代理，这可能引入评估噪声或偏差。改进方向是开发更可靠的自动验证方法或收集更多人类标注的完成度标签。第三，RL阶段的训练规模相对较小（50个在线步骤），可能没有充分利用模拟环境的规模化潜力。改进方向是增加RL步数或使用离线RL方法从历史轨迹中学习。第四，当前的训练配方使用的是4B模型，虽然结果有竞争力，但更大的模型可能带来更好的性能。改进方向是扩展到更大的模型（如7B、14B）来研究scaling law。最后，作者没有评估不同真实/模拟rollout混合比例的影响，当前使用的是50%/50%混合，这可能不是最优的。
未来方向
作者提出的未来工作方向包括：扩展PhoneWorld以覆盖跨应用工作流，提供对多应用信息传递、artifact转移和持久跨应用状态依赖的直接支持；结合更强的执行控制装置、中间验证和安全感知的部署边界；研究更强大的长期状态跟踪、应用间信息传递和运行时验证。基于成果可以延伸的方向包括：研究不同真实/模拟rollout混合比例的影响，找到最优的混合策略；探索curriculum learning，先在模拟环境中训练基础技能，再在真实环境中微调；开发更好的reward shaping方法，特别是在真实应用环境中更准确地捕捉任务完成度；研究在线适应，让模型在部署过程中继续学习和改进；扩展到更多平台（如iOS）和更多任务类型（如游戏、社交应用）；探索与其他GUI代理技术（如视觉语言模型、工具使用框架）的结合。
复现评估
论文提供了项目页面（https://phonebuddyai.github.io/），但未明确说明代码、数据和模型的开源情况。从论文中可以知道训练使用的是Qwen3.5-4B骨干网络，SFT数据集包含950,758个动作步，使用全参数微调1,115个优化器步，批大小为512，序列长度为8,192 tokens，学习率从$1 imes 10^{-5}$衰减到$1 imes 10^{-6}$。RL阶段运行50个在线步骤，真实/模拟rollout混合比例为50%/50%。这些训练细节相对完整，但没有明确说明使用的硬件资源和训练时间。评估协议相对详细：动作空间使用标准化的[0, 1000]坐标，步数预算训练时30步评估时50步，使用固定提示模板和结构化工具调用格式。总体来说，论文提供了足够的技术细节来理解方法，但要完全复现结果可能需要作者释放更多代码和数据。考虑到真实应用环境的复杂性（需要物理设备和真实应用），完全复现整个训练流程可能具有挑战性，但复现模拟环境部分应该相对容易。
论文图表