一句话讲清楚👉🏻 腾讯混元提出 PhoneBuddy ，用真实手机 App 强化学习加 PhoneWorld 模拟 App 训练，把 4B 开源手机 Agent 的 AndroidWorld 成功率推到 83.2%，同时暴露出跨 App 任务仍然很难。
论文标题：PhoneBuddy: Training Open Models for Agentic Phone Use
论文链接：https://arxiv.org/abs/2606.23049
Github 链接：https://github.com/PhoneBuddyAI/phonebuddy
项目链接：https://phonebuddyai.github.io/
模型链接：https://huggingface.co/PhoneBuddyAI/PhoneBuddy-4B
让手机 Agent 真正替你办事，难点往往不在“看懂按钮”这一层。订酒店、填文档、在小程序里查信息，这些任务会遇到弹窗、登录态、旧剪贴板、真实 App 副作用，模型必须在这些干扰里把事情办完。
手机是一个带状态的执行环境。账号是否登录、 App 是否弹权限、服务端返回什么、剪贴板里有没有旧内容、某个操作会不会真的下单或付款，都会影响最终结果。一个 Agent 在截图上点对位置，并不等于它完成了任务。
PhoneBuddy 这篇论文把问题压到一个更具体的位置：开源手机 Agent 到底该怎么训练，才能在真实手机上更会做事？ 它给出的答案是，把真实 App 环境和可自动验证的模拟 App 环境结合起来。
真实 App 给模型现实感， PhoneWorld 给模型规模、重置和自动验收。两者合起来， PhoneBuddy-4B-Real+Mock 在四个评测维度的平均成功率达到 54.8%，比只做真实 App RL 的版本高 5.0 个百分点；在 AndroidWorld 上，成功率从 SFT 的 60.3% 一路涨到 83.2%。
但这篇论文的价值不止体现在漂亮数字上。它把手机 Agent 训练里最尴尬的矛盾讲清楚了：越真实的环境越难规模化，越可规模化的环境又越容易失真。
PhoneBuddy 的整体训练流程：共享 SFT 阶段之后，模型分成真实 App RL 与真实+模拟混合 RL 两条路线。
手机 Agent 的训练，卡在“真”和“多”之间
论文开头先点出一个现实：大模型已经不满足于回答问题，它们正在被要求直接操作软件界面。网页、桌面、工具调用、移动端 GUI 都在往这个方向走。
手机端更特殊。它是很多真实任务的主入口：聊天、支付、本地生活、出行、办公、小程序、跨 App 信息流转，都在手机上发生。对一个手机 Agent 来说，任务成功的标准不是“识别出按钮”，最终要看它能否在真实设备状态下把事情完整办完。
这里有几个麻烦点。
第一，手机任务高度状态化。同一个 App ，登录状态不同、历史记录不同、会员权限不同，屏幕行为都会不一样。训练时很难把环境恢复到完全一致的状态。
第二，手机操作有副作用。点错一个按钮，可能发出消息、改掉文档、触发订单，甚至影响真实账号数据。真实 App 环境越接近部署场景，探索成本越高。
第三，验证结果很难自动化。网页或合成环境里，常常可以直接检查 DOM 、数据库状态或环境变量。真实手机 App 里，很多结果藏在服务端或账号私有状态里，系统很难直接读取。
第四，任务形态差异很大。单 App 任务、小程序任务、跨 App 任务看起来都叫“手机 Agent”，训练难度不是一个量级。尤其跨 App 场景，需要在多个界面之间搬运信息，前一步的中间结果会影响后一步。
所以 PhoneBuddy 研究的是训练配方：在真实环境成本高、模拟环境容易失真的前提下，怎样训练一个开源模型，让它在真实手机上更稳。
PhoneBuddy 怎么做：先统一动作，再比较训练分支
PhoneBuddy 的实验设计有一个好处：它尽量把变量压少。
所有对比模型都从同一个 Qwen3.5-4B backbone 出发，共享同一套动作接口、提示模板、评测协议和 SFT 初始化。论文重点比较最后的强化学习环境选择，刻意避开模型架构花活。
三条模型路线可以概括成这样：
共享 SFT 阶段使用真实 App 和模拟 App 轨迹，总共 950,758 个 action steps 。训练是全参数微调，跑 1,115 个 optimizer steps ， batch size 为 512 ，序列长度打包到 8,192 tokens ，学习率从 ＄1\times10^{-5}。
这个 SFT 阶段先让模型学会统一的手机动作格式：看到用户任务、当前屏幕和历史动作后，输出下一步操作。动作空间包括 click 、 double click 、 long press 、 type 、 scroll 、 drag 、 back/home/menu/enter 、 open app 、 close app 、 wait 等。
之后进入 RL 。两个 RL 分支都跑 50 个 online RL steps ，优化目标都是二值任务完成奖励：完成就是 1 ，没完成就是 0 。但真实环境和模拟环境的奖励来源不同。
真实 App 环境里，很多任务结果依赖账号状态和服务端逻辑，不能直接读内部状态。论文采用 rubric-based model judging ：先用 Gemini-3.1-Pro-Preview 为每个任务生成验收 rubric ，再用 Qwen3.5-122B-A10B 按 UI 轨迹和证据逐项打分，所有 rubric 项通过才算成功。
模拟 App 环境用的是 PhoneWorld 。这里的 mock app 指从真实 GUI 轨迹和截图中重建出来的可运行 Android App ，并非静态玩具页面。它有屏幕连接关系、可写状态、任务目标和规则验收器，因此可以自动重置、自动跑、自动判断是否完成。
混合 RL 分支里，真实 App 和模拟 App rollout 比例是 50%/50%。这一步的核心是让模型在真实反馈之外，多获得可重复、可验证、成本更低的交互经验，而不是让模拟环境替代真实手机。
真实 App 与 PhoneWorld 的互补关系：前者提供真实设备行为和副作用，后者提供可重置、可自动验证的大规模交互。
PhoneWorld 扮演的角色：把“可练习”这件事补上
很多手机 Agent 的训练困境，和人类练车有点像。
真实 App 像真实路况：一个按钮点错，可能真的发消息、改文档、触发订单。 PhoneWorld 更像训练场，允许模型反复练搜索、填写、筛选、确认这些动作，而不必每次都冒真实账号的风险。
PhoneWorld 在 PhoneBuddy 里就是这个训练场。它从真实 GUI 使用结构里恢复屏幕、动作、状态变化和任务验收规则，生成可运行的模拟手机环境。它的优势不在于百分百复刻真实 App ，而在于让模型能反复练一批可检查的任务。
这对 RL 很关键。强化学习怕奖励噪声，也怕环境不可复现。真实手机环境里，任务失败可能是模型点错了，也可能是 App 弹窗变了、网络卡了、账号状态不同、服务端返回不同。 PhoneWorld 至少能把一部分变量固定住，让模型从更清晰的成功/失败信号里学习。
当然， PhoneWorld 也有边界。它目前更偏单 App 和结构稳定的任务，对跨 App 信息交接覆盖不足。后面的实验结果正好印证了这一点：单 App 和 AndroidWorld 涨得明显，跨 App 任务反而没有改善。
这让 PhoneBuddy 的结论更可信。论文没有把模拟环境包装成万能方案，而是给它放在一个明确位置：补规模、补重置、补自动验证；真实行为和复杂副作用仍要靠真实 App 环境兜住。
评测怎么做： 150 个真实手机任务，加 AndroidWorld
PhoneBuddy 的主评测包含四类任务。
前三类来自真实手机人工评测，每类 50 个任务，总计 150 个： Single-App Tasks 、 Cross-App Tasks 、 WeChat Mini-App Tasks 。第四类是 AndroidWorld 。所有指标都用 task success rate ，也就是任务成功率。
真实手机任务的判定很严格：只有任务完全完成，才算成功。论文没有用局部动作准确率来替代任务结果，这一点很重要。因为手机 Agent 的实际价值就在“办成事”，不是“下一步动作看起来合理”。
评测时，所有模型使用固定的动作空间、 prompt 模板、 step budget 和执行 harness 。训练阶段最大步数是 30 ，评测阶段最大步数放宽到 50 ，给长任务更多机会。
论文还把 PhoneBuddy 的三个内部模型和若干闭源系统放在一起比较，包括 Gemini 3.1 Pro 、 GPT-5.4 、 Claude Opus 4.7 、 Seed 2.0 Pro 。
为了适配手机端阅读，我把主表拆成两张小表。先看开源 PhoneBuddy 三个阶段：
再看平均成功率和跨 App ：
最直接的变化出现在真实 App RL 之后：单 App 从 34.0% 跳到 54.0%， AndroidWorld 也从 60.3% 到 77.2%。真实执行反馈确实让模型学到了一些手机环境里的操作规律。
混合 RL 又把这条曲线往上推了一段。 Real+Mock 在单 App 达到 62.0%， AndroidWorld 达到 83.2%，平均成功率 54.8%，比 Real 高 5.0 个百分点。
刺眼的地方也在表里：跨 App 没涨。 PhoneBuddy 三个阶段在跨 App 上分别是 22.0%、 20.0%、 18.0%。这个结果很有信息量，当前 PhoneWorld 的训练覆盖更适合单 App 和结构稳定任务，跨 App 信息传递还缺专门设计。
论文评测覆盖单 App 、跨 App 、微信小程序和 AndroidWorld ，真实手机部分每类 50 个任务。
最亮的结果： AndroidWorld 83.2%，单 App 超过闭源模型
PhoneBuddy-4B-Real+Mock 的最好成绩出现在 AndroidWorld 和单 App 任务。
AndroidWorld 上，三阶段变化非常干净： 60.3% → 77.2% → 83.2%。这个递增很有说服力，因为 AndroidWorld 不属于论文自建的真实手机 150 任务套件。换句话说，混合训练带来的收益没有停在内部评测里，还迁移到了外部手机任务环境。
单 App 任务上， PhoneBuddy-4B-Real+Mock 达到 62.0%，超过论文中列出的 Gemini 3.1 Pro 和 GPT-5.4 的 50.0%，也超过 Seed 2.0 Pro 的 44.0%。在这个切片里，一个 4B 开源模型靠训练 recipe 打出了很强的性价比。
微信小程序任务更微妙。 SFT 是 54.0%， Real 掉到 48.0%， Real+Mock 又回升到 56.0%。我的理解是，小程序任务通常多步骤但结构相对稳定，正好能从 PhoneWorld 这种可重复练习里获益；而只做真实 App RL ，可能在有限 rollout 下没覆盖到足够多的小程序模式。
跨 App 任务则完全不同。它要求模型把一个 App 里的中间信息带到另一个 App ，还要在多个界面间保持目标一致。比如从一个助手里生成请假条，再复制到腾讯文档保存；或者在一个小程序里查到结果，再去另一个 App 里继续操作。这里考验的是长程状态跟踪、信息暂存、跨界面校验，单纯增加可重置单 App 练习不够。
RL 增量图显示：真实 App RL 与模拟 App RL 的收益主要集中在单 App 、小程序和 AndroidWorld ，跨 App 仍然困难。
成功案例说明了什么：约束跟随和信息搬运
论文给了两个定性案例，都很贴近日常手机使用。
第一个是约束跟随。任务要求在微信小程序“同程旅行”里搜索上海迪士尼附近的经济型酒店。 SFT 模型能走到看起来合理的酒店搜索页，但没有真正应用预算约束。 Real+Mock 版本继续进入筛选界面，把酒店预算压到 150 元。
这个差别不是“多点了一下按钮”这么简单。它说明模型开始把用户约束当成任务状态持续维护，而不是只按屏幕上最显眼的控件往前走。
第二个是信息转移。任务要求用元宝生成请假条，再保存到腾讯文档。 SFT 模型没能复制元宝生成的内容，创建文档时插入了旧剪贴板内容。 Real+Mock 版本则正确复制生成文本，并粘贴到新建文档里。
这个案例更接近跨 App 能力，但论文把它放在成功轨迹里，是因为 Real+Mock 至少在某些结构化流程上改善了信息传递。真正大规模跨 App 任务仍然没涨，说明这类能力还不稳定。
成功轨迹展示了两个典型改进：预算约束没有丢失，以及从元宝到腾讯文档的信息复制更可靠。
和闭源模型相比， PhoneBuddy 赢在哪里、输在哪里
如果只看平均成功率， PhoneBuddy-4B-Real+Mock 是 54.8%，低于 Gemini 3.1 Pro 的 59.1%，高于 Seed 2.0 Pro 的 51.4% 和 GPT-5.4 的 48.2%。
这个位置挺有意思。 PhoneBuddy 不是全场第一，但它是一个 4B 开源模型线，靠训练环境组合在多个切片上追近甚至超过大模型系统。
分项看更清楚：
这组对比说明， PhoneBuddy 的优势不是“全能”，而是“把单 App 流程练得很熟”。一旦任务需要跨 App 保存、搬运和校验信息，它和闭源系统的差距就立刻拉开。 Gemini 3.1 Pro 的跨 App 是 48.0%， PhoneBuddy Real+Mock 只有 18.0%。
这不是简单的模型大小问题。跨 App 需要更强的运行时系统和记忆机制：什么时候保存中间信息，保存到哪里，下一步如何校验，遇到错误如何回滚，是否需要向用户确认。训练环境当然重要，但执行 harness 、任务分解、短期记忆、权限边界也会一起决定结果。
从产品角度看， PhoneBuddy 更像是在告诉我们：手机 Agent 的第一阶段突破可能先发生在“单 App 内的高频流程”和“结构稳定的小程序任务”。跨 App 办公、跨 App 生活服务、涉及隐私和支付的复杂链路，还需要更完整的系统工程。
我怎么看这篇论文的价值
我更看重的是， PhoneBuddy 没有把问题简单归因到模型大小。
过去很多 GUI Agent 工作会强调更强的视觉理解、更大的模型、更复杂的 prompt 。但 PhoneBuddy 把焦点放在环境：手机 Agent 到底应该在哪里练、谁来判定它做对了、模拟环境和真实环境各自该承担什么。
这条路线很实际。手机 Agent 的难点一半在“智能”，另一半在“训练场”。真实手机太贵、太慢、太难自动评估；纯模拟又怕学到假动作。 PhoneBuddy 的混合训练至少给出了一套可验证的折中方案。
我也觉得它的跨 App 失败结果很有价值。很多论文会弱化这种短板，但这里的数字直接暴露出来：模拟环境如果主要覆盖单 App ，跨 App 就不会自然变好。这个结论对后续研究有指导意义。下一步要提升跨 App ，不应该只把单 App 任务继续堆大，而要专门构造信息交接、长程依赖、剪贴板/文件/文档状态、跨应用验收器。
还有一个容易被忽略的点：真实 App RL 的奖励本身用了模型裁判。 Gemini 生成 rubric ， Qwen 大模型判断轨迹是否满足 rubric 。这个设计解决了真实手机难验收的问题，但也引入了评判模型偏差。未来如果要把这套训练路线用于更敏感的任务，奖励系统需要更强的可审计性，尤其涉及支付、个人信息、社交发送时，不能只依赖黑盒裁判。
对开源手机 Agent 的启发
PhoneBuddy 给开源社区的启发可以拆成三条。
第一， 4B 模型并非没有机会。只要训练环境和奖励设计得足够贴近任务，一个小模型也能在部分手机 Agent 场景里打出强表现。模型规模不是唯一杠杆。
第二，模拟环境要从真实结构里来。 PhoneWorld 的关键不在“合成 App”这个名字，而在它从真实 GUI 轨迹里恢复屏幕、动作和状态。如果模拟环境只靠人工想象，很容易练出和真实世界脱节的策略。
第三，手机 Agent 需要分层推进。单 App 、小程序、跨 App 、隐私任务、安全任务，不该混成一个总分。不同任务考的能力差异很大，训练环境也要对应扩展。
在我看来， PhoneBuddy 代表的是手机 Agent 的一个务实阶段：先用真实执行守住真实性，再用模拟环境扩大可训练规模。它不会直接解决所有手机自动化问题，但它把“训练场怎么建”这个核心问题往前推了一步。
结语
PhoneBuddy 的主结论很清楚：真实 App RL 提供现实反馈， PhoneWorld 这类模拟环境提供可重置、可自动验证的规模化练习。两者组合后， 4B 开源手机 Agent 在多个任务切片上明显提升， AndroidWorld 达到 83.2%，单 App 任务甚至超过论文中对比的几个闭源系统。
同时，它也把边界摆在桌面上：跨 App 任务依然很弱。手机 Agent 真正进入日常生活前，还需要更强的长程记忆、信息交接、运行时校验、隐私保护和安全边界。
这篇论文最像一个信号：下一轮手机 Agent 竞争，会从模型大小延伸到训练环境，谁能搭出更真实、更可扩展、更可验证的训练场，谁就更有机会跑出来。
