MobilePA-Bench：屏幕操作全对，后台却是零进展
手机助手在屏幕上点对了，为什么事还是没办成？
想象这样一个下午。你让手机里的助手把周三下午的会议改到周四，再把改动同步给参会的同事。它很熟练地按下屏幕上的一颗颗按钮，通知栏弹出"已完成"。你打开日历一看，会议还停在周三。要办的那件事，在屏幕之下、API 与数据库那边的世界里，没有任何动静。屏幕上的成功会骗人。只盯着屏幕，判断不了一件事有没有真办成，这就是 MobilePA-Bench 存在的理由。
MobilePA-Bench 正是为检验屏幕成功背后的"真实办成"而设的一场新考试：给常驻手机的规划智能体（mobile planning agent）出题，看它能不能不只当"会点屏幕的手指"，而是像贴身管家那样，听懂意图、跨多个 App 规划步骤、调用后台业务工具，把事真正办成。考场是一座会真实执行、真实改变后台数据的活环境，每个动作都在后台真实生效，而不是把戏演完就算数。
这场考试之所以非设不可，是因为旧考场判不出屏幕背后的真实办成。论文把现有的评测划成两派，每派各有一只眼睛是瞎的。看屏幕的考试（GUI-centric benchmark）只考表层屏幕操作，漏掉后台工具调用与长程规划；对答案的考试（静态函数调用 benchmark）靠离线比对 API 调用，与真实运行时约束完全脱节。反常之处就在这里：两派各自都很努力，却恰好把"把后台数据真正改对"和"从运行时错误里恢复"这两件贴身管家最该会的事，都留在了考场之外 MobilePA-Bench。
| 考试 | 看屏幕的考试（GUI-centric） | 对答案的考试（静态函数调用） |
|---|---|---|
| 考什么 | 屏幕上点得对不对 | 工具名、参数填得对不对 |
| 怎么判分 | 读屏幕与设备的最终状态 | 离线比对 API 调用路径 |
| 考场是活的吗 | 模拟器会执行，但动作只有 UI 操作 | 死的，从不真正执行 |
| 看不见什么 | 后台工具调用、跨步长程规划 | 调用顺序、权限拦截、运行时错误 |
一个直觉问题先搁在这里：屏幕上的成功可能是幻觉。那换成对答案的考试，就能看清真相吗？
看屏幕的考试，到底漏掉了什么？
GUI 这一派其实走得很远。AndroidWorld 把它做成了工业级：20 个真实 Android App、116 个程序化任务，每个任务按随机种子动态生成参数，一个任务模板能变出上百万个实例；判分不靠截图匹配，而是用 adb 直接读设备状态，SQLite 里多了一行、文件系统多了个文件都算数。这套考试相当认真 AndroidWorld。
图注：AndroidWorld 的系统总览，展示环境、任务与智能体的闭环，奖励信号由模拟器状态直接读出。它是 GUI 评测范式最成熟的形态，但盲区也藏在它自己的设计里。AndroidWorld
但注意它的动作空间：只有 tap、swipe、long-press 这类手指动作，没有任何对后台 API 的直接调用；20 个 App 还刻意全部免登录。权限弹窗、网络中断这些真实运行时约束被主动请出考场，"从运行时错误里恢复"这一项根本无从考起。成绩也说明这套考试不简单：当时最强的多模态 agent M3A 只拿到 30.6%，人类是 80%。可它考得再难，考的还是"会不会看着屏幕点"。
这个选择从范式源头就定下了。2023 年的 AppAgent 确立了探索、部署两阶段的做法，GUI 智能体的手从此被定义在屏幕上，高层动作就那么几个：tap、swipe、text、back AppAgent。后来的 MobileAgentBench 用无障碍服务判定 UI 终态 MobileAgentBench，Mobile-Bench-v2 把 GUI 与 API 数据混在一套题里 Mobile-Bench-v2，但它们都在"屏幕"这一侧精进，够不到后台。
屏幕考试看不见后台。那换成对答案的考试，会好一些吗？
对答案的考试，考场为什么是死的？
另一派换了思路：贴身管家本质上是"调工具的人"，那就直接考工具调用。ToolBench 从 RapidAPI 收了 16,464 个真实 REST API，用大模型生成指令，用 DFSDT 决策树标注解决路径，再用 ToolEval 打分。规模很大，流程很完整，但整条链路都跑在无状态的 REST 接口上：没有权限层、没有数据库持久化、没有跨调用的副作用，也没有运行时异常恢复 ToolBench。
图注：ToolBench 的整条静态管线：API 收集、指令生成、解决路径标注、检索器与模型训练、推理时多轮 API 调用、ToolEval 打分。从数据到评估，全程没有有状态的运行时：无权限拦截、无数据库持久化、无跨调用副作用。ToolBench
问题出在哪？Pass Rate（通过率）这把尺子把一切失败都折叠成"没找到调用路径"。权限拦截、数据库冲突、顺序敏感的副作用，这些真实运行时里天天发生的事，静态考场一概看不见。ToolBench 自己也很诚实：它允许模型以"放弃"收场，因为离线评估根本描述不了"权限被拒之后怎么恢复"，它只能把失败归因于找不到路。
静态这一派里更接近现实的是 τ-bench：引入了模拟用户、策略文档和数据库，看起来已经很真。但它的考场仍是自建合成 schema 上的模拟交互，不在手机 OS 的真实运行时上。它验证的是"模型知不知道怎么调"，验证不了"模型面对真实运行时约束能不能把事调成" τ-bench。
两场考试，一场像只看手指的面试，一场像对着标准答案批改的笔试。笔试写得再漂亮，也没人知道试卷放进机器里会不会炸。如果让考场本身活起来，真的执行、真的改数据库、真的报错，会怎样？
让考场活起来：一座会执行、会改库、会报错的沙箱
MobilePA-Bench 的回答是：把考场建成一座活沙箱。中央 planner 直接调用业务工具，把专门步骤路由给 sub-agent（子智能体），读取 User Memory（用户记忆），装载可复用的 Skills（技能包）；右边是一个有状态的移动环境，每一次动作都被真实执行、真实记录、真实反馈。
图注：MobilePA-Bench 评测范式总览：中央 planning agent 调用业务工具、向 Sub-agents 路由专门步骤、读取 User Memory、装载 Skills；stateful Mobile Env 在 Domain Databases 上执行每个动作，并回传关于状态变更与系统错误的可观察反馈。MobilePA-Bench
"活"落到机制上是三层：Tool Schema 定义参数与领域归属，Tool Code 做校验和执行逻辑，Tool Database 持久记录状态变更与执行日志。每次调用都由 Tool Executor 处理，更新后台状态，再返回动态的结构化反馈。用 add_contact（添加联系人）走一遍：planner 发起调用，沙箱校验参数，往 Contacts 表写入一行，把"写成功"连同状态变更返回给 planner。这个回路看起来普通，但注意这正是它与 AndroidWorld 式确定性模拟器的分水岭：这里不是回放，数据库会冲突、权限会拦截、错误会真实发生并被返回，planner 必须看着错误信息调下一手。
图注：以 add_contact 工具为例的沙箱三层：Tool Schema 定义参数，Tool Code 承担校验与执行，Tool Database 记录实时状态变更（Contacts）与执行日志（Operation_logs），Tool Executor 处理调用并返回结构化执行反馈。MobilePA-Bench
如果说上一章那座对答案的考场像笔试，只审纸面正确，这座沙箱就是实操考核：设备会真出故障，错误后果被原样摆在面前，考的是修不修得回来。考场的规模也配得上"活"字：13 个功能域、212 个贴近现实的移动工具、1,705 个任务，一次给 planner 15 个候选工具，最多 15 步。
环境活了，新的问题跟着冒出来：光会调工具，就够当贴身管家了吗？
光会调工具就够吗？——四门能力考试，三种判卷方式
新考场不止考调用。它把"贴身管家"拆成四样本领，任务分布一眼可见：Basic Tool Use 占 1,040 个，Sub-agent Collaboration 89 个，Memory Usage 376 个，Skill Usage 200 个。加权公式是 50/10/20/20，基础工具调用拿走一半权重，因为它是所有能力的地基。
| 能力维度 | 任务数 | 考什么 |
|---|---|---|
| Basic Tool Use | 1,040 | 选对工具、填对参数、按顺序调用、从错误恢复 |
| Sub-agent Collaboration | 89 | 何时委派、委派给谁、handoff 质量 |
| Memory Usage | 376 | 解析隐含请求、调用用户画像与历史偏好 |
| Skill Usage | 200 | 调用预打包组合技能并完成下游执行 |
Basic Tool Use 内部再分五个互斥类目。参数接地，从一句"把上次说的那家店订了"里推出该填哪些参数；条件依赖规划，前置步骤不完成就不许跳步；引用与状态追踪，"那个""这家"指什么、跨轮状态怎么变；意图修订，用户中途改主意怎么办；边界检测与错误恢复，撞上 PermissionDenied（权限拒绝）这类系统错误，能不能活着回来。
分数凭什么可信？判卷设计是最讲究的一环。每个查询在标注阶段就被路由到三个不可互换的证据桶（evidence bucket，判分所依据的证据来源）。有确定性标准步骤的任务进 Bucket 1，逐字核对工具名、参数与调用顺序；多条路径等价、成败由数据库终态唯一决定的任务进 Bucket 2，比对终端数据增量；开放或交互型的任务进 Bucket 3，按任务专属的 rubric 看行为轨迹。Memory 检索和 gold-skill 装载只是叠加在主证据上的附加门控，不替代主证据。为什么必须不可互换？因为确定性操作看轨迹会冤枉模型，开放式任务对答案会漏判，混用哪个桶都会引入噪声。
图注：三大证据桶的分类：Bucket 1 以精确工具与参数校验，Bucket 2 以数据库终态增量校验，Bucket 3 以可观察行为校验；Memory retrieval 与 gold-skill loading 作为附加能力门控叠加其上。MobilePA-Bench
有了这道判卷的门，才能认真问下一个问题：把最严的考试发给最强的模型，它能考几分？
最强的模型也只答对 75.52%——这份成绩单告诉我们什么？
成绩单先亮出来：最强模型 Claude-Opus-5 总分 75.52%，13 个被测模型里 7 个低于 70% MobilePA-Bench。这已经不是"刷榜"能解释的差距。
| 维度 | Claude-Opus-5 |
|---|---|
| 总分 | 75.52% |
| Basic Tool Use | 83.85% |
| Sub-agent Collaboration | 62.92% |
| Memory Usage | 58.51% |
| Skill Usage | 78.00% |
数字本身不稀奇，稀奇的是失败模式长得很有规律。第一类是参数接地：最强模型在最基础的行为类目上仍然有 16.15% 的任务失败，选错工具名、填错参数值。第二类是委派时机：Sub-agent 一项多数模型低于 65%，什么时候该委派、委派出去怎么接回来，成了普遍瓶颈。第三类最反直觉：个性化上下文。Memory 检索成功不等于会用，即使把所有该记的记忆都检索到，下游执行照样在 7.30% 到 24.28% 的案例里失败。检索到画像是一回事，把画像用进决策是另一回事。还有一条稳定性证据：Qwen3.6-27B 三遍测试总分 57.22% 到 57.63%，波动不到 0.5 个百分点，这些结论不靠随机性。需要说明的是，这篇论文是 2026 年 8 月刚挂上 arXiv 的预印本，尚未经过同行评审，以上都是论文主张的结论。
这份成绩单的正确读法不是"模型太差"，而是"考试终于能把差在哪测出来"。参数接地、委派时机、个性化上下文，三处病灶清清楚楚。能做到这一点的考试，本身就是一件工具：诊断仪。
作者群还给这座沙箱安排了第二重身份：agentic RL 的训练场。沙箱天然就是一个状态、动作、奖励（state, action, reward）的闭环，结构化反馈就是观察，证据桶判定直接提供 reward 信号，RL 智能体可以直接在这个环境里滚动训练。诊断仪和训练场共用同一套地基，这是全篇最耐人寻味的落点。要注意的是，"是训练地基"是定位声明而非已验证的训练结果，reward 函数如何从证据桶映射、训练是否收敛，论文没有给出实验。
边界也同样清楚。同一作者群在另一条路线上押了注：MobileWorld 走 GUI 操作加 MCP 标准化工具加用户交互，与 MobilePA-Bench 的业务 API 加活沙箱路线互为补充 MobileWorld。论文自述的边界也摆在那里：纯 GUI 操作不设为核心考察、而是委派给 GUI sub-agent（论文明确）；此外 MCP 标准化工具、特定商业应用均未进入其 212 工具/13 域评测范围——这些恰好是下一轮考试的候选题目。
图注：MobileWorld 的系统架构：左侧宿主机上，GUI agent 在屏幕动作与 MCP 工具调用之间选择；右侧容器化 Android 生态里运行模拟器、自托管应用后端与多重验证器。它与 MobilePA-Bench 的活沙箱路线形成互补。MobileWorld
75.52% 不是一份糟糕的成绩单，而是一张终于看得清病灶的体检单。看清楚病在哪，训练才有着力点。手机智能体要从"看着像在干活"走向"真的把事办成"，这场能看到真相的考试，是第一块台阶。
想深入可以读原文：MobilePA-Bench: Benchmarking Mobile Planner Agents on Complex Real-World Tasks — arXiv:2608.23035
参考文献
- MobilePA-Bench: Benchmarking Mobile Planner Agents on Complex Real-World Tasks（arXiv:2608.23035）：https://arxiv.org/abs/2608.23035
- AndroidWorld: A Dynamic Benchmarking Environment for Autonomous Agents（arXiv:2405.14573）：https://arxiv.org/abs/2405.14573
- Mobile-Bench-v2: A More Realistic and Comprehensive Benchmark for VLM-based Mobile Agents（arXiv:2505.11891）：https://arxiv.org/abs/2505.11891
- MobileWorld: Benchmarking Autonomous Mobile Agents in Agent-User Interactive and MCP-Augmented Environments（arXiv:2512.19432）：https://arxiv.org/abs/2512.19432
- AppAgent: Multimodal Agents as Smartphone Users（arXiv:2312.13771）：https://arxiv.org/abs/2312.13771
- MobileAgentBench: An Efficient and User-Friendly Benchmark for Mobile LLM Agents（arXiv:2406.08184）：https://arxiv.org/abs/2406.08184
- τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains（arXiv:2406.12045）：https://arxiv.org/abs/2406.12045
- ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs（arXiv:2307.16789）：https://arxiv.org/abs/2307.16789