PhoneBuddy：4B 小模型在真机上跑赢 GPT-5.4，腾讯混元是怎么做到的

正常人都觉得，能让 AI 替你操作手机，得靠 GPT-5.4 那种百亿参数的大模型。屏幕截图丢进去，它得看懂、得推理、得点对位置。4B 参数的小模型？光 UI 元素识别就应该把显存吃没了。但腾讯混元团队刚开源的 PhoneBuddy，偏不按这个剧本走。

在 150 个真实手机评测任务上，这个 4B 模型单 App 成功率 62%，GPT-5.4 是 50%。微信小程序 56% 对 40%。AndroidWorld 上更是 83.2% 对 70.7%。不是”接近”闭源大模型，是在多项任务上直接超越。

这件事比表面看起来有意思得多。PhoneBuddy 研究的不是怎么把模型做大，而是 RL 训练环境到底该怎么设计，用真实 App、用 Mock App、还是两者混着来。标题里的 “Real+Mock RL” 才是整篇论文最值钱的那三个词。

但环境设计这件事，为什么在 Phone Agent 训练里这么关键？

真手机 vs 假手机：训练环境才是关键

要把 Phone-use Agent 训出来，最直接的办法是在真实手机上跑真实 App。Agent 看到支付页面是真的，发出消息是真的，改设置也是真的。这是最接近最终部署场景的方案。

但问题也很直接。真机交互慢，一次 rollout 成本高。更难搞的是——操作一次就可能改变账号状态或服务端数据，你没法把手机”重置到上一步”。对 RL 来说，环境不能稳定复现等于 reward 信号不可靠，训练效率直接腰斩。

另一种选择是用 Mock App，模拟页面结构但去掉真实服务端。好处是可控、可重置、可以自动化验证——消息是否发出、文档是否创建、筛选条件是否生效，这些都能用规则直接检查。但风险也明显：Mock App 简化了真实世界里弹窗、权限、网络波动这些干扰项，训练出来的策略迁移到真机不一定好用。

PhoneBuddy 的回答是：别二选一，两个都要。

说的轻巧，具体怎么把两种环境塞进同一条训练管线？

Real+Mock 混合 RL：把两个世界拼在一起

PhoneBuddy 的训练方案拆成两个阶段，每个阶段都有明确的职责。

第一阶段是 Shared SFT。模型同时学习真实 App 和 PhoneWorld Mock App 的操作轨迹，学会统一的手机操作格式——看屏幕、理解任务、预测下一步动作。这个阶段不区分环境好坏，目标只有一个：让模型建立基本的手机操作能力。

第二阶段是 RL。从同一个 SFT checkpoint 出发，PhoneBuddy 做了三组对比：

• PhoneBuddy-4B-SFT：只做监督微调，不继续 RL；
• PhoneBuddy-4B-Real：只做真实 App RL；
• PhoneBuddy-4B-Real+Mock：真实 App + PhoneWorld Mock App 混合 RL。

三组对比的结果非常直接。在 150 个真机任务上，SFT 基线平均成功率 36.67%，Real RL 拉到 40.67%，Real+Mock RL 再拉到 45.33%。AndroidWorld 上这个趋势更明显：60.3% → 77.2% → 83.2%。

Mock App RL 不是 Real RL 的替代品。它是补充。真实 App 保证方向对齐，Mock App 提供可规模化、可验证的训练信号。两者合在一起，效果比单独用任一种都好。

训练方法说清楚了，但一个更直接的问题摆在面前：跟闭源大模型比，这套方案到底什么水平？

跟 GPT-5.4 正面刚：小模型凭什么赢

PhoneBuddy-4B-Real+Mock 和几个闭源大模型做了直接对比。结果放一张表就够了：

最容易让人多看两眼的点是：4B 参数打赢了 GPT-5.4。Single-App 62% vs 50%，微信小程序 56% vs 40%，AndroidWorld 83.2% vs 70.7%，平均分 54.8% vs 48.2%。

不需要过度解读。Gemini 3.1 Pro 的整体平均分仍然更高。但这组数字说明了一个被很多人忽略的事实：Phone-use Agent 的能力不只取决于模型有多大，更取决于它是在什么环境里训练出来的。环境设计对了，4B 模型也可以在真实手机场景里表现出强竞争力。

论文里给了两个很有说服力的 case。第一个是约束跟随——任务让 Agent 在微信小程序”同程旅行”里搜索上海迪士尼附近的平价酒店，SFT 模型走到了搜索页但没用预算限制，Real+Mock 模型继续进入筛选界面把预算降到 150 元。第二个是信息转移——任务要求先用元宝生成请假条再用腾讯文档保存，SFT 模型复制了剪贴板里的旧内容，Real+Mock 模型正确复制了新生成的请假条并粘贴到文档里。

这两个 case 揭露的东西比数字更重要：Real+Mock 训练提升的不是点击准确率，是”把任务真正做完整”的能力，记住约束、传递信息、执行到最后一步。

不过 PhoneBuddy 不是一篇孤立的论文。把镜头拉远一点，能看到一个更大的布局。

不止一个模型：混元一次甩出 5 篇论文

如果你只把 PhoneBuddy 当成一个”训练了 4B 手机 Agent 模型”的工作，你可能会低估它。

腾讯混元这次一次性发布了 5 篇互相衔接的 Phone Agent 研究。PhoneWorld 负责构建可运行、可重置、可验证的 Mock App 环境；PhoneBuddy 研究怎么把真实 App 和 Mock App 放进同一条训练闭环；PhoneHarness 解决模型输出怎么变成可控的真实手机操作；PhonePrivacy 和 PhoneSafety 分别评估隐私风险和安全边界。

把这 5 篇放在一起看，逻辑就很清晰了：环境决定能不能大规模训练和评测，训练决定模型能不能学到真实可用的策略，执行层决定能力能不能稳定落到真机，安全与隐私决定系统能不能进入用户场景。PhoneBuddy 是训练层，也是第一次把前面几层能力汇总到真实手机任务结果上的关键一环。

这是 2026 年上半年 Phone Agent 领域最成体系的一次公开发布，没有之一。

研究布局确实大，但回到一个更实际的问题：我现在能用它干什么？

上手，先别急着装

坦白说，PhoneBuddy 目前的代码状态还比较早期。截至 2026 年 6 月，GitHub 仓库只包含论文 PDF、项目素材和评估脚本——训练代码标记为”🚧 Code release”仍未完成。README 明确标注了”No public dataset release planned at this stage”。

所以当下的”上手”主要是用模型，不是训模型。PhoneBuddy 在 HuggingFace 上发布了三个 checkpoint：

PhoneBuddy-4B 是主力模型，采用了 Real+Mock RL 训练。PhoneBuddy-4B-RealApp 是消融对照版本，只用了真实 App RL。PhoneBuddy-0.8B 是轻量版本，留给需要快速实验的场景。

模型使用 Qwen 风格的 XML tool-call 格式，chat_template.jinja 定义了完整的使用规范。推理时输入手机截图和任务描述，模型输出下一步操作，包括点击坐标、输入文本、滑动方向等。

虽然训练代码还未开源，但模型权重可以直接从 HuggingFace 加载：

from transformers import AutoModelForCausalLM, AutoProcessor

model = AutoModelForCausalLM.from_pretrained(
    "PhoneBuddyAI/PhoneBuddy-4B",
    torch_dtype="auto",
    device_map="auto"
)
processor = AutoProcessor.from_pretrained("PhoneBuddyAI/PhoneBuddy-4B")

模型推理本身不复杂，真正的工作量在环境搭建。你需要自行准备 Android 真机或模拟器、接入截屏和操作执行层（建议参考同系列的 PhoneHarness 项目），再把模型输出映射为具体的手机操作指令。没有一键安装，没有 pip install phonebuddy。

这不是一个让你五分钟跑出 Demo 的项目。它是一个还在代码开源路上的研究发布。

但话说回来，现在入手到底值不值？这取决于你是谁。

什么时候值得关注，什么时候可以等等

先说不适合的场景。如果你在找一个能用 pip install 装完就能让 AI 操作手机的成品工具，PhoneBuddy 现在还做不到。它的定位是训练方法和模型权重，不是面向终端用户的产品。如果你对模型训练完全没兴趣，只想要一个现成的手机助手，看 PhoneHarness 那类执行层项目可能更对路。

当下最适合投入精力的人群是这三类：已经在做 Phone Agent 训练的研究者（可以直接用 PhoneBuddy-4B 作为基座模型继续 RL 或做 fine-tune），对 RL 训练环境设计感兴趣的工程师（PhoneWorld + PhoneBuddy 的 Real+Mock 混合训练方案很有参考价值），以及在做手机自动化工具但苦于模型能力的开发者（4B 模型部署成本远低于百亿参数的大模型）。

还有一个值得盯着的人群：关注端侧 AI 的人。4B 参数在一个能跑在手机上的量级。如果后续有人把 PhoneBuddy 蒸馏或量化到 1-2B 甚至更低，端侧离线手机 Agent 就不只是理论可能性了。

不过项目这么新，社区基础到底怎么样？

项目状态：新到发烫

这是你能找到的最年轻的开源项目之一。首次 commit 是 2026 年 6 月 11 日，arXiv 论文 6 月 22 日上线。截至 6 月 27 日，仓库总共只有 11 个 commit。

由于项目太新，目前还没有实质性的社区讨论。GitHub Issues 区基本是空白，Reddit 和 HackerNews 上暂时找不到关于 PhoneBuddy 的独立讨论帖。唯一可以明确的是，这个项目背后是腾讯混元团队一整条研究线（5 篇论文），不是某个工程师周末写了个 Demo 就挂上来。团队规模和研究投入是它的信用背书，但项目能不能持续维护、社区会不会形成，现在没人能回答。

这个量级的研究发布通常有两种走向：一种是后续代码、数据、工具链逐步开源，社区跟上，形成生态；另一种是论文发了、模型放了、然后就停了。PhoneBuddy 现在还卡在这两条路的分叉口，建议持续观察接下来 1-2 个月的代码更新节奏。

说了这么多数据和现状，回到那个最根本的问题。

真正重要的不是那个 4B 模型

回到开头那个问题：PhoneBuddy 的价值是什么。

如果你只是把它当成”又一个开源 4B 模型”，你会错过真正重要的东西。PhoneBuddy 的核心贡献不是在单 App 任务上比 GPT-5.4 高了 12 个百分点——虽然这个数字确实漂亮。核心贡献是它用一套可复现的实验证明了：RL 训练环境的设计，比模型参数规模更能决定 Phone Agent 的上限。

Real App 给你真实感，Mock App 给你可验证性和规模。两个拼在一起，4B 就能在某些场景下跟百亿参数模型掰手腕。这个结论如果被更多团队验证和跟进，Phone Agent 的训练范式可能会发生一次不小的迁移——从”堆更大的模型”转向”设计更好的环境”。

当然，冷静一下。跨 App 长程任务仍然困难，Real+Mock 在 Cross-App 上只有 18% 的成功率。信息在多个 App 之间传递时，中间状态的验证和运行时的协调，都还有很长的路要走。这个方向远没到能”替我操作手机”的阶段。

所以现在的问题是：该不该动手？

跟，但要盯紧两件事

如果你在做手机 Agent 相关的研究或工程，PhoneBuddy 值得现在就装进你的观测列表。不是因为它已经完善，而是因为它提出了一套有说服力的训练方案，并且这次发布的 4B 模型可以直接拿来跑结果。

目前的瓶颈不在模型质量，在配套工具链。盯着两个关键的进展信号：训练代码什么时候从 🚧 变成 ✅，以及社区会不会有人在 PhoneBuddy-4B 上跑出更多手机 App 的实测结果。如果这两个信号在接下来一两个月内变绿了，这个项目的价值会比现在看到的论文数字大得多。

一个 4B 开源模型在多项真机任务上超过 GPT-5.4——这不是营销话术，不是 Table 1 里的 cherry-pick，是腾讯混元团队把环境设计这件事想透了之后的水到渠成。

资源地址