手机 Agent 的真实水平有多差?MobilePA-Bench 用交互式沙箱给出了答案:最强模型总分仅 75.52%
核心摘要:手机正在变成 LLM 智能体的下一个主战场,但现有的评测体系跟实际使用严重脱节——GUI 类基准只考"点屏幕",函数调用类基准只考"字符串匹配"。阿里通义 MAI 团队这篇 MobilePA-Bench(arXiv:2608.23035)的思路是:既然要考,就把整个手机后端搬进沙箱,维护一份实时数据库,让 Agent 在一个有状态、会报错、有权限限制的环境里真刀真枪地干。覆盖 13 个功能域、212 个工具、1705 个任务,还单列了子 Agent 协作、记忆使用、技能复用三个进阶维度。结果挺扎心:13 个前沿模型里最强的 Claude-Opus-5 总分也只有 75.52%,Memory 维度全员崩盘,最好的也只有 64.63%。这不是一篇"刷榜"论文,而是一面照妖镜——它告诉你,移动智能体距离"可靠"还隔着一条叫做"复合可靠性"的鸿沟。如果你在做端侧 Agent,这个基准值得放进你的评测栈。
📖 论文信息
- 标题:MobilePA-Bench: Benchmarking Mobile Planner Agents on Complex Real-World Tasks
- 作者:Yi Zhu、Xiongwei Wu、Qiyi Wang、Tingyu Qu、Jiajun Liu、Sihan Cao、Long Chen、Weigao Sun、Feida Zhu、Yiran Zhong、Steven Hoi
- 机构:MAI Team, Alibaba Token Hub, Alibaba Group
- 链接:https://arxiv.org/abs/2608.23035
- 代码:https://github.com/Tongyi-MAI/MobilePA-Bench
🎯 一个被忽略的评测盲区
你有没有想过一个问题:手机上的 AI 助手,到底该怎么考?
现在的评测体系分成了两派,而这两派各自有一块明显的盲区。
第一派是 GUI 中心基准,代表选手是 AndroidWorld、OSWorld、MobiBench 这一挂。它们的做法是给 Agent 一个安卓模拟器,让它看屏幕截图、点按钮、滑页面,最后检查任务完成没。这条路测的是"像素级感知 + 界面操作",挺直观的,但问题在于——真实手机助理的大量工作根本不在屏幕上发生。订机票、查日历、发短信、开关勿扰模式,这些事的本质是一连串后台工具调用和状态变更。把算力全花在解析 UI 布局上,是拿错了尺子。
顺带提一句背景:AndroidWorld 这条线的竞争已经很激烈了。Google 发布的这个基准包含 116 个手工任务,2026 年 8 月的公开快照里 Qwen3.8-Max 已经刷到了 85.3%,开源的 GUI-Owl 系模型也在 70 分上下徘徊。分数涨得飞快,但这恰恰说明 GUI 自动化这个子问题正在被快速收敛,它不是当前 Agent 能力的真正瓶颈。
第二派是静态函数调用基准,BFCL、ToolBench、DroidCall、TAU-Bench 这类。它们考的是模型能不能把一句自然语言翻译成正确的 API 调用,评测方式是离线字符串匹配。问题在于,真实环境是有状态的——你调用 add_contact,数据库里就多了一条联系人;你忘了传必填参数,系统会返回 Missing field;你没权限,系统会甩回来 PermissionDenied。静态基准里这些全都不存在,模型在"无反馈的真空中"做题,测不出运行时纠错能力。
这篇论文的判断很干脆:真实的用户意图——比如"帮我规划下周三去上海三日游,机票酒店景点全搞定"——单靠 API 调用或 GUI 自动化都搞不定,它需要记忆检索、技能执行、基础工具使用、子 Agent 委派四种能力的统一编排。于是 MobilePA-Bench 应运而生。
图1:一个三日游规划任务的完整交互过程。左侧是用户与 Agent 的多轮对话,右侧拆解了 Agent 实际动用的四种能力——先检索记忆(用户偏好短航班、住希尔顿、家在北京),再执行订票技能包,然后调用扫码工具,最后把"填参观人信息、完成预约"委派给 GUI 子 Agent。这才是真实手机助理该有的样子,也是这个基准要测的东西。
🏗️ 核心设计:把手机后端整个搬进沙箱
MobilePA-Bench 最重要的设计决策,是放弃了视觉渲染,转而构建一个有状态仿真沙箱。一句话讲:不画界面了,直接操作数据库。
沙箱由三个紧耦合的层级构成:
- Tool Schema:定义结构化函数接口。比如
add_contact明确要求name和phoneNumber两个必填参数,并标注所属域。 - Tool Implementation Code:真正的执行逻辑。它会校验参数、检查联系人是否已存在、生成动态 ID(如
contact_002),而不是简单地"假装成功"。 - Shared Stateful Database:维护实时应用状态,同时记录运行审计日志。
形式化一点,环境状态定义为 \(\mathcal{S}_t = \langle \mathcal{D}_t, \mathcal{O}_t \rangle\)(实时数据库 + 操作日志),每次执行返回结构化反馈 \(f_t = \langle Status, ErrorType, Payload \rangle\)。Planner 每步执行动作 \(a_t = \pi(q, \mathcal{H}_t, \mathcal{A}_t)\),直到发出 Finish 或达到步数上限 \(T_{max} = 15\)。
关键的一点是环境摩擦注入:沙箱在初始配置里故意埋了缺失参数、权限阻断、实体歧义这些坑,逼着 planner 根据动态反馈实时修计划。你不能指望一次把参数填对,你得学会看错误信息、追问用户、调整策略。
图2:架构总览。上层是 Mobile Planner Agent,掌握四类能力(基础工具、记忆、子 Agent 协作、技能);中层是 Tool Executor,执行"工具调用→参数校验→执行→返回结果"的闭环,同时环境反馈"状态更新→观察→事件触发→执行状态";底层是 Mobile Environment,包含可执行工具、可变状态、领域数据库和运行时日志,最终由三类 Checker 判定成功。整个链路是一个真闭环,不是静态问答。
为什么这个设计重要?因为操作直接写结构化后端数据库,不需要视觉渲染,沙箱支持高吞吐、确定性执行和轨迹回放——这让它天然适合做 Agentic RL 的训练环境,而不只是一个评测集。说实话,我觉得这一点比基准本身更有长期价值。
图3:以 add_contact 为例的三层结构。上方是 Tool Schema(JSON 格式的函数定义);左下是 Tool Database,存着现有联系人和操作日志;右下是 Tool Code 的真实 Python 实现——校验必填字段、检查重复、生成 contact_002 这样的动态 ID。Tool Executor 调用后返回 {"success": true, "data": {...}} 这样的结构化结果。每一步都会留下审计痕迹。
13 个功能域、212 个工具
任务覆盖的广度是这样的:
| 功能域 | 工具数 | 典型能力 |
|---|---|---|
| Audio & Entertainment | 25 | 媒体控制、相机、录屏、音乐识别 |
| Apps & Storage | 23 | 应用生命周期、权限、通知、存储清理 |
| Display & Sound | 22 | 亮度、音量、深色模式、勿扰 |
| System Settings | 22 | 控制中心、语言、系统更新 |
| Time Management | 16 | 日历、任务、闹钟、自动化规则 |
| AI Assistant | 16 | GUI 子 Agent 路由、记忆搜索、智能感知 |
| Calls & Communication | 15 | 联系人、通话、短信、骚扰拦截 |
| Network & Connectivity | 14 | WLAN、蓝牙、热点、NFC |
| Travel & Lifestyle | 13 | 天气、导航、支付码、票务 |
| Devices & Cross-device | 13 | 投屏、多屏共享、设备迁移 |
| Input & Interaction | 12 | 截图、扫码、隔空手势 |
| Utilities & Productivity | 11 | 浏览器、计算器、翻译 |
| Security & Privacy | 10 | 屏幕锁、生物识别、密码库 |
总共 1705 个真实用户任务:Basic Tool Use 占 1040 个,Memory Usage 376 个,Skill Usage 200 个,Sub-agent Collaboration 89 个。
🧠 三个进阶维度:真正拉开差距的地方
如果说基础工具调用是"送分题",那三个进阶维度就是这篇论文真正想拷问的东西。
① Sub-agent Collaboration:考的是"委派质量"
89 个任务专门隔离出那些超出结构化 API 能力边界的活——GUI 视觉操作、条件监控、视觉问答、交互式练习。架构里有六个专门的子 Agent,其中 GUI Sub-agent 负责视觉 grounding 和底层界面交互。
评测口径很聪明:它不考下游子 Agent 执行得好不好,只考 planner 的委派质量——路由选对了没有?交接负载里给的上下文够不够完整?指令清不清晰?这就像考一个项目经理,不是考他会不会写代码,而是考他会不会派活。
② Memory Usage:门控式端到端判定
376 个任务建立在一个连贯的用户画像世界上:用户有个秘书叫 Maya,通勤时习惯静音且媒体音量 20%,导航偏好高对比度路线……请求刻意省略这些显式偏好,要求 planner 在动手之前主动去查持久记忆。
评测用了个挺狠的门控机制。设 \(\hat{M}_T\) 为轨迹中所有 search_user_memory 调用返回的记忆 ID 并集,记忆门控:
最终判定:
翻译成人话:必须检索到全部金标记忆 ID,并且任务主检查器也通过,才算成功。少查一条记忆,或者查了记忆但事没办对,都是零分。376 个任务还沿三个诊断轴做了标注:记忆推理类型(单记录 grounding / 冲突记录消解 / 多记录组合)、目标操作(增/替/删)、应用域。
③ Skill Usage:技能包的动态加载
200 个任务把复合型多步手机例程打包成可复用技能。调用技能加载器会返回程序化指令,并动态扩展候选动作集:
也就是说,加载技能之后,planner 才能看到技能内部绑定的具体工具 schema。评测在 Skill-Only Routing(SOR)和 Mixed Tool-Skill Routing(MTSR)两种设置下分别跑,取平均。同样要求金标技能被加载且主检查器通过才算成功。
证据对齐的三个 Query Bucket
验证机制与能力维度是正交的,按证据类型分三类:
图4:三个 Bucket 的判定逻辑。Bucket 1(Tool Call)要求确定性规范步骤,精确匹配工具名、调用顺序、参数字段与归一化值,不允许多余的副作用调用;Bucket 2(State Change)允许多条有效路径,只比对终态数据库差量 \(\mathcal{D}_T - \mathcal{D}_0\) 与标注目标,拒绝破坏性写入;Bucket 3(Agent Behavior)针对开放式任务,按 rubric 评估可观察轨迹——子 Agent 调用是否恰当、追问行为是否连贯。
总分的聚合公式:
这个权重设计值得注意:Memory 和 Skill 各占 20%,比 Sub-agent 的 10% 高一倍。作者显然认为"记住用户"和"复用经验"比"会派活"更接近日常使用的核心痛点。
📊 实验:13 个前沿模型,没人及格(如果及格线是 90 分)
评测配置:动态工具选择召回 N = 15,多轮函数调用,标准化系统提示,最大步数 \(T_{max} = 15\),不可变全分母计分(缺失或无效预测直接计失败)。
主结果这张表我建议你多看两眼:
| 模型 | Overall | Basic | Sub-agent | Memory | Skills | 平均输出 token |
|---|---|---|---|---|---|---|
| Claude-Opus-5 | 75.52 | 83.85 | 62.92 | 58.51 | 78.00 | 262 |
| Claude-Fable-5 | 75.31 | 83.37 | 70.79 | 62.50 | 70.25 | 269 |
| Kimi-K3 | 73.01 | 77.40 | 62.92 | 63.56 | 76.50 | 270 |
| Qwen-3.8-Max | 72.51 | 77.88 | 53.93 | 64.63 | 76.25 | 304 |
| Gemini-3.6-Flash | 71.21 | 78.65 | 66.29 | 62.77 | 63.50 | 221 |
| Gemini-3.1-Pro | 71.18 | 80.58 | 77.53 | 48.67 | 67.00 | 194 |
| GLM-5.2 | 67.71 | 76.06 | 61.80 | 49.73 | 67.75 | 372 |
| Claude-Opus-4.8 | 65.52 | 79.04 | 50.56 | 37.23 | 67.50 | 283 |
| Qwen-3.7-Max | 64.71 | 76.54 | 50.56 | 53.19 | 53.75 | 303 |
| Seed-2.1-Pro | 63.65 | 72.98 | 59.55 | 42.29 | 63.75 | 288 |
| GPT-5.6-Sol | 62.68 | 69.81 | 49.44 | 44.15 | 70.00 | 221 |
| GPT-5.5 | 61.44 | 68.94 | 51.69 | 41.76 | 67.25 | 243 |
| Kimi-2.6 | 55.63 | 70.38 | 43.82 | 33.78 | 46.50 | 223 |
(单位:%,加粗为每列最佳)
几个让我停下来的观察。
第一,天花板比想象中低。 最强的 Claude-Opus-5 总分 75.52%,意味着四分之一的任务失败。13 个模型里 7 个低于 70%。要知道这些可都是各家当前最能打的旗舰模型。
第二,维度之间的断层非常大。 Basic Tool Use 的峰值是 83.85%,但 Memory 只有 64.63%,Sub-agent 跨度从 43.82% 到 77.53%。基础工具调用快收敛了,记忆和委派还是重灾区。尤其是 Memory——最强模型也要挂掉超过三分之一的任务。
第三,不存在全能冠军。 这是个挺反直觉的发现:Claude-Opus-5 领先 Basic(83.85%)和 Skills(78.00%),但 Memory 只有 58.51%;Qwen-3.8-Max 在 Memory 上拔得头筹(64.63%);Gemini-3.1-Pro 拿下 Sub-agent(77.53%)却在 Memory 上只有 48.67%。你没法闭眼选一个模型打天下,不同模型的能力画像差异显著。
第四,技能复用确实有用。 Skills 峰值 78.00%,而且多数模型的 Skills 成绩高于自己的 Memory 成绩。把长程例程打包成技能,能有效缓解逐步规划的错误累积——这跟之前 Agent 领域"工作流压缩"的经验是一致的。
评测稳定性:这个基准本身靠不靠谱?
基准类工作最怕的就是"测不准"。作者用 Qwen3.6-27B 在相同设置下跑了 3 次完整评测:
| Run | Basic | Sub-agent | Memory | Skills | Overall |
|---|---|---|---|---|---|
| 1 | 73.37 | 46.07 | 31.91 | 47.75 | 57.22 |
| 2 | 74.33 | 43.82 | 32.18 | 48.25 | 57.63 |
| 3 | 74.04 | 43.82 | 32.71 | 46.75 | 57.29 |
| Std. | 0.49 | 1.30 | 0.41 | 0.76 | 0.22 |
Overall 的波动范围在 57.22%–57.63%,误差带不到 0.5 个点。Sub-agent 波动最大(峰谷差 2.25 点),但也就对应 89 个样本里 2 个任务的判定差异,乘以 10% 权重后对总分影响至多 0.23 点。这个稳定性是相当扎实的。
失败模式:不会"认怂"的模型
论文里有个观察我觉得特别值钱:遇到能力边界、歧义约束或执行异常(比如 PermissionDenied)时,模型倾向于过早发出幻觉工具调用,而不是追问澄清或根据反馈 \(f_t\) 调整策略。
翻译过来就是——这些模型缺乏"校准的克制"。它们宁可瞎编一个看似合理的调用,也不愿意说"这个我做不到"或者"你能再说清楚一点吗"。以 GPT-5.6-Sol 的错误分析为例:Skills 表现最强(70.00%,结构化程序有助于稳定长程执行),但 Sub-agent(49.44%)和 Memory(44.15%)暴露了它在委派交接质量、个性化检索、以及"把检索到的上下文转化为正确动作"上的持续弱点。检索到了记忆但没用对,这种 grounding 失败比"没检索到"更隐蔽,也更难修。
🤔 我的判断
这篇论文最值钱的地方,不是又造了一个榜单,而是它把移动 Agent 的评测从"单点能力"拉到了"复合可靠性"的视角。真实工作流需要记忆消歧、技能加载、有状态 API 执行、GUI 委派串联成一条链,每个环节 90% 的准确率乘起来,端到端就是不及格的。它用 1705 个任务把这个残酷事实量化了。
设计上有几个我很认可的决策。一是放弃视觉渲染、直接操作数据库,评测吞吐量高、可复现、还能回放轨迹,这为后续的 Agentic RL 铺了路——论文也明确说这个沙箱就是奔着"交互式 RL 训练场"去的。二是 Memory 的门控判定,避免了"任务碰巧做对但记忆根本没查"的虚假成功。三是三个 Bucket 的证据对齐设计,把"过程对不对""结果对不对""行为像不像样"分开考,诊断粒度足够细。
但也有几个地方我会打个问号。Sub-agent 维度只有 89 个任务,样本量偏小,单次运行 2 个任务的判定差异就是 2.25 个点的波动——虽然权重低不影响总分,但如果你想拿这个维度做模型选型,噪声得小心。另外,整个沙箱是模拟环境而非真机,工具实现是作者手写的 Python 逻辑,它和真实手机系统(权限弹窗、后台杀进程、跨应用数据同步延迟)之间的 gap 有多大,论文没有展开讨论。Memory 世界的用户画像是合成的,合成画像的分布是否贴近真实用户的混乱记忆,也存疑。
还有个小瑕疵:Sub-agent 维度的评测只考委派质量不考下游执行,这是合理的简化,但也意味着"委派对了但子 Agent 执行翻车"的情况不会被扣分——真实场景里这种失败是算在 Agent 头上的。
对工程实践的启发其实很直接。如果你在做端侧 Agent,这篇论文给出了一张清晰的能力体检表:基础工具调用已经不是瓶颈,优先去补记忆检索后的 grounding、错误恢复时的"该追问就追问"、以及把高频长程流程沉淀成技能包。特别是最后一点,Skills 维度的数据已经证明了这是性价比最高的提升路径。
📝 收尾
移动智能体的竞争,正在从"能不能做"转向"做得稳不稳"。MobilePA-Bench 给出的答案是:连最强的模型,稳定性都还没及格。但这个基准本身——有状态、可回放、面向 RL——可能比那 75.52 分的头条数字更有生命力。如果后续真有人用它做 Agentic RL 把 Memory 维度的 64.63 刷上去,那才是这个故事的下一章。
觉得有启发的话,欢迎点赞、在看、转发。跟进最新AI前沿,关注我