MobilePA-Bench 精读

论文链接：arXiv:2608.23035 代码仓库：Tongyi-MAI/MobilePA-Bench（含 1705 任务、数据集与高吞吐沙箱） 项目主页：tongyi-mai.github.io/MobilePA-Bench 发表时间：2026年8月 机构：阿里巴巴通义 MAI Team / Token Hub（企业研究，含研究实习生；Feida Zhu 与 Yiran Zhong 为负责人） 领域标签：cs.AI（移动智能/Agent 评测）

一、论文背景

移动 Agent 的两类评测与中间盲区：现有评测分两派——GUI 操作派（AppAgent/MobileAgentBench：看屏幕截图、点坐标，测感知与低层操作）与离线函数调用派（BFCL 等：给定工具列表直接调 API，无真实应用状态）。但真实手机助手是另一种形态：个人助理（PA）式的规划 Agent——它不自己点屏幕，而是调用系统级工具（订机票、设提醒、查日程），维护应用的真实状态，还需要子 Agent 协作、个性化记忆（“我家地址”、“我常用的航空公司”）、技能加载。这个中间地带此前没有基准。

为什么难建？ 三个工程门槛：应用必须有状态（订了机票日历真的多一条事件，不是模拟返回）；反馈必须结构化（Status/ErrorType/Payload 而非截图，否则测的是解析能力）；验证必须证据对齐（不能只看最终回答——要核对工具调用序列与应用数据库的真实变更）。

二、论文定位和关联工作

• GUI 基准（AppAgent/AndroidWorld）：测感知-操作——MobilePA 把视觉解析与规划解耦，专注后者。
• 函数调用基准（BFCL/ToolBench）：无状态无摩擦——MobilePA 的沙箱维护活数据库并原生注入真实摩擦。
• τ-bench 类：客服对话工具调用——MobilePA 面向个人助理场景，且首增 SubAgent/Memory/Skill 三维门。

三、问题定义

抽象问题：在含真实环境摩擦（权限/缺参/歧义）、状态依赖与个性化上下文的工具环境中，中央规划 Agent 的多维能力（基础执行/委派/记忆/技能扩展）如何分别度量？ 关键设计决策：把高阶能力做成**能力门（与主 checker 相乘）**而非加分项——记忆错了，任务再"完成"也不算过。

四、问题解法

4.1 有状态移动沙箱

212 个真实工具×13 领域（出行/日程/购物/通讯……），沙箱维护活的应用数据库；每次工具调用返回 Status/ErrorType/Payload 三元组结构化反馈。

4.2 原生环境摩擦

权限阻断（调用未授权工具返回 PermissionDenied）、缺参（必需参数缺失）、实体歧义（“给妈发消息”——通讯录有三个"妈"）——摩擦不是外加的 trick，是任务构造的原生属性。

4.3 三桶证据对齐验证

Bucket 1 工具调用精确匹配（确定性序列）、Bucket 2 状态变更 DB-delta 匹配（允许多路径等价）、Bucket 3 Agent 行为 rubric（开放交互）。总分 = 0.5×Basic + 0.1×SubAgent + 0.2×Memory + 0.2×Skill。

4.4 三维高阶能力门

子 Agent 协作路由（任务要求委派给子 Agent 完成）、记忆检索（依赖用户画像中的个性化信息）、技能加载（运行时动态加载技能文档扩展动作空间）。

五、评估指标与实验证据

1705 任务（Basic 1040 / SubAgent 89 / Memory 376 / Skill 200）× 13 前沿模型：

三个结构性发现：

1. 无全能规划器：四个维度冠军分散在 4 个不同模型；Gemini-3.1-Pro 子 Agent 最强（77.53%）但 Memory 仅 48.67%；Qwen-3.8-Max 记忆最强但 Overall 非第一。13 模型均值：Basic 76.58%、Memory 50.98%、Skill 66.77%——Memory 全员不及格。
2. 最强与最弱差 20pp（75.52 vs Kimi-2.6 的 55.63）；GPT-5.6-Sol 仅 62.68%（Memory 44.15%）——强模型名不等于移动规划强。
3. 稳定性：Qwen3.6-27B 三次全量运行 Overall 标准差仅 0.22pp——基准本身信噪比可靠。

六、效果优势的根源解释

本文的价值在失败模式的机制归因：

1. 错误跨能力边界级联：一个请求（“帮我把上周和妈的聚餐改到周五并通知她”）同时需要记忆消歧（哪个聚餐/哪个"妈"）+技能加载+API 执行+GUI 委派——单维度错误率相乘导致端到端成功率骤降。这是"能力门"设计的直接证据：短板以乘法杀伤整体。
2. 认对路由≠正确完成：SubAgent 高分模型把任务分对了，但状态变更（DB-delta）仍错——委派能力与验收能力分离。
3. 异常处理是系统性短板：模型遇 PermissionDenied 倾向幻觉式提前调用（假装成功）而非澄清或依反馈重规划——摩擦场景暴露了"报喜不报忧"的训练偏置。
4. Memory 为什么全员低：个性化上下文（用户画像、历史偏好）的检索与正确应用是当前训练分布的盲区——离线基准从不测这个。

七、必要知识反推

• 领域知识层：移动端应用的状态模型（订票/日程/通讯的数据库 schema）；真实助手的摩擦分类学（权限/缺参/歧义）。
• 方法论知识层：三桶验证的证据对齐设计（为什么精确匹配/DB-delta/rubric 各管一段）；能力门与加分项的度量差异（乘法 vs 加法暴露短板）。
• 工程知识层：高吞吐沙箱（1705 任务×13 模型的可复现执行）；活数据库的隔离与重置。

知识融合的关键节点：把"服务级别协议（SLA）测试"的故障注入思想引入 Agent 基准——摩擦不是刁难，是把生产环境的真实失败模式搬到可控实验里。

八、论文中可以提取的通用性灵感

1. 短板以乘法杀伤端到端系统，评测要用乘法门而非加权平均（机制类）

   • 证据：单维度 80% 的三个能力串联后端到端仅 ~50%；能力门设计暴露了加权平均掩盖的短板。
   • 推广：供应链（任何一个环节断链全链失败）、流水线自动化（人工环节是乘法门）、团队项目（关键路径上的最弱成员决定交付质量）——评估复杂系统时先找乘法门。

2. 在受控环境里复现生产摩擦，比在干净环境里刷分更接近真实能力（方法论类）

   • 证据：干净基准上 80%+ 的模型在摩擦任务上幻觉式提前调用。
   • 推广：压力测试（混沌工程对微服务）、面试（压力问题比友好问答更预测入职表现）、应急预案演练（加入真实摩擦——断网/人员缺位——的演练才有价值）。

3. 维度冠军分散=能力路线尚未收敛（现象类）

   • 证据：四维度冠军分属 4 个模型，无一全能。
   • 推广：技术选型（各工具的长板分布不同且未收敛时，组合方案优于押注单一工具）、招聘（能力分布异质的团队在领域早期更有优势）。

4. 个性化记忆是被训练分布遗漏的真实需求（现象类）

   • 证据：Memory 维度全员 <65%，均值 50.98%。
   • 推广：产品设计（个人上下文是助手类产品最大的差异化空间）、数据战略（谁掌握用户的个性化数据谁就掌握下一代助手的 Memory 维度）。