MobilePA-Bench：面向复杂真实任务的移动端规划智能体基准

  • 关联论文：2608.23035
  • 作者：flyP
  • 更新：2026-08-26

一句话结论

MobilePA-Bench 给出了一个可在可执行沙箱里同时跑 212 个真实移动工具、并对"子智能体协作 / 记忆使用 / 技能复用"三种高阶能力做证据化判分的评测基准，作者用它测出现有前沿 LLM 在严格工具排序、权限边界、运行时异常下表现"断崖式下跌"。

解决什么真问题

移动端 LLM 智能体正在从"GUI 截图派"和"工具调用派"两条岔路上各自演进：

  • GUI-centric 派（AndroidWorld、Screenspot、MobileAgent 等）：让模型看屏幕、点坐标，但只测"表层点击是否对"，看不见智能体在后台调了哪些 API、长程计划怎么拆。
  • 静态 function-calling 派（BFCL、ToolBench 等）：离线对一组 API 描述做匹配，脱离真实运行时——能不能拿到权限、能不能在异常后重试、能不能记得上一轮的结果，全都测不到。

这两条线各测半个能力，合不到一起。MobilePA-Bench 想做的，是把"真实运行态 + 工具调用语义 + 长程规划"在同一张桌子上同时考察。

核心方法

MobilePA-Bench 的设计哲学是"测真实运行态，不测离线匹配"。整张基准由三层组成，每一层都对应一种过去评测缺位的信号：

1. 可执行沙箱 + 结构化反馈

沙箱不是离线 stub——它维持真实的应用数据库（订单、聊天记录、日历事件等），每次工具调用后返回结构化结果，而不是字符串拼接。对 13 个功能域（出行、餐饮、日历、通讯、购物等）开放 212 个真实移动工具的接口，覆盖绝大多数日常智能体场景。

2. 中央规划智能体 + 三类高阶维度

被测对象是一个 central planning agent，论文额外考察三类进阶能力，这三类是过去 GUI 评测基本不碰的：

  • (1) Sub-agent Collaboration：把复杂任务拆开，委派给专门的子智能体（例如"订机票+订酒店+加日历事件"拆给 travel-agent / booking-agent / calendar-agent）。
  • (2) Memory Usage：从记忆库、用户画像、历史偏好里召回上下文，把"上次去过那家店""我不吃辣"这类隐含信息补到当前请求里。
  • (3) Skill Usage：调用预打包的复合技能（"订周末行程""一键报销"），而不是从零规划每一步。

3. 证据化验证（evidence-based verification）

每一次工具调用都核对"返回结构是否符合预期状态"——订单真创建了、日历事件真写入了、权限被拒是真被拒了。这套机制同时承担"评分"和"agentic RL 训练反馈"两个角色，论文明确说本基准"既是诊断基准，也是交互式强化学习的底座"。

伪代码（评测循环）

# 简化版评测循环（论文式抽象）
state = sandbox.reset(task=benchmark_task)
agent = CentralPlanner(
    model=model,
    sub_agents={"travel": travel_agent, "calendar": calendar_agent, ...},
    memory=MemoryStore(),
    skills={"plan_trip": Skill("订周末行程"), "reimburse": Skill("一键报销"), ...},
)

while not state.done and state.steps < MAX_STEPS:
    # 中央规划器综合三维度决策
    action = agent.plan(
        observation=state.observation,
        memory=agent.recall(state),        # Memory Usage 维度
        available_tools=state.tools,
        available_skills=agent.skills,    # Skill Usage 维度
        delegation_hint=agent.delegate_hint(state),  # Sub-agent 维度
    )
    # 子智能体委派（可能）
    if action.delegate_to:
        sub_result = action.delegate_to.execute(action.sub_task)
        state.update(sub_result)
    else:
        state.update(sandbox.call(action.tool, action.args))
    state.record(action, evidence=state.last_evidence)

# 评分 = 任务完成度 + 工具顺序约束 + 权限合规 + 异常恢复
score = verifier.evaluate(state, expected_trajectory)

与既有范式的关键差异

把方法放到三类对照里看更直观：

  1. vs GUI-centric 评测——后者只看"截图→点击坐标"，证据化验证只看"是否点到正确元素"，没有工具调用语义。MobilePA-Bench 把工具调用语义作为一等公民，每次调用都查"返回结构是否符合预期状态"。
  2. vs Static function-calling 评测——后者给模型一组 API 描述，让它挑对的函数名/参数对，不真去执行；权限、顺序、运行时异常全部被屏蔽。MobilePA-Bench 的沙箱是"活的"，每次调用都打真数据库，反馈结构化。
  3. vs 端到端任务评测——AndroidWorld / WebArena 这类基准给一个高层目标，让 agent 自己规划，但对"工具调用失败""子任务委派""技能复用"这三类行为不单独打分。本基准把它们显式拆成三维，分别评分，等于把"agent 的内部决策结构"摊到评测里。

设计上的权衡也很清楚：用 212 个真实工具 + 13 个功能域换取覆盖广度，代价是评测运行成本高（每跑一个模型需要真去执行工具链）；用结构化反馈换取可验证性，代价是必须维护一套"应用数据库状态机"，不能纯静态打分。

为何三类失败注入特别难

在论文里被点名的三类失败模式——工具排序、权限、运行时异常——不是随机挑的，它们对应生产事故的高发点：

  • 工具排序错误：典型的"先创建订单再校验库存"vs"先校验库存再创建订单"，顺序反了会出现幽灵订单。这类问题在静态 function-calling 评测里永远测不出来，因为离线匹配只关心"调没调对函数"。
  • 权限边界：iOS / Android 的运行时权限模型是"调用时才弹窗"，智能体必须能处理"用户拒绝权限后还能不能降级完成任务"。这要求 agent 有重试 + 备选方案的能力，纯 GUI agent 通常直接卡死。
  • 运行时异常：网络超时、状态冲突（订单已被别人取消）、第三方 API 临时不可用——agent 必须能从异常返回里识别"哪种错误可重试、哪种不可重试"，而不是把所有错误当一回事重试。这条对规划能力的要求远高于对工具调用本身的要求。

论文把这三件事摆到台面上，等于在告诉社区：mobile agent 的下一阶段瓶颈不在"会不会点屏幕"，而在"会不会处理真实失败"。

关键实验与数据

摘要层给出的实验结论（数字来自 arXiv abstract，未做 PDF 表格级核验 ⚠️）：

  • 覆盖度：13 个功能域 × 212 个真实移动工具，中央规划智能体可在沙箱里完整跑通。
  • 失败模式：现有前沿 LLM 在三类约束下表现显著下降——
  • 严格工具顺序约束（必须先 A 再 B，顺序反了任务作废）
  • 权限边界（某些 API 调用需要先授权，未授权就调会失败）
  • 未预期的运行时异常（网络超时、状态冲突）
  • 评测位置：同时承担"诊断 benchmark"与"agentic RL 训练场"双重身份，作者主张 mobile 智能体的下一步进展需要这种可交互底座。

实验设计的推断 ⚠️

虽然摘要没有把全部数字摊出来，但作者团队（Weigao Sun / Steven Hoi 这条线，Shopee / Salesforce 研究背景）此前做过 GUI agent 与 LLM 评测（参见 CogAgent、SeeClick 等前置工作），本基准的实验范式遵循"主表列 SOTA 模型 + Baseline（无 sub-agent / 无 memory / 无 skill）做消融 + 失败注入维度各跑一遍"的三层结构。这是合理推断，不等于论文实际数据，引用任何"消融差 X%"必须以 PDF §5 / §6 表格为准。⚠️

⚠️ 未独立核验：具体模型对（如 GPT-5 / Claude / Gemini）在 9 个能力维度上的得分百分比；论文 §5 主表里的 SOTA vs baseline 数字本棒未拉 PDF 核实，引用前需对照 PDF §5 表格。⚠️

亮点与局限

亮点

  • 把"长程规划 + 工具调用 + 记忆 + 技能复用"四件事压在同一评测里，过去没有 benchmark 同时做到。
  • 沙箱是"活"数据库，不是 mock——智能体拿到的反馈结构化、可核验。
  • 显式支持 agentic RL 训练反馈，能直接当作训练场而不是事后打分工具。

局限

  • 13 个域、212 个工具听起来广，但相对真实手机生态仍是子集——没有覆盖系统级设置（蓝牙、权限管理）、跨 App 状态同步（剪贴板、文件）。
  • "严格工具排序 / 权限 / 异常"三类约束是论文自选的失败注入维度，是否能覆盖所有真实事故模式未公开验证。
  • ⚠️ Sub-agent / Memory / Skill 三维度评分权重与"中央规划器"的协同判定规则未在摘要中给出，PDF §4 评分协议为唯一权威源。
  • 模型匿名评测 + 未公布被引来源，意味着短期内难做横向对比。

对工程落地的启发

  • 谁该用：在手机上做 on-device copilot（笔记、日程、订餐、出行）的团队；做"GUI agent vs tool-call agent"路线选择的决策者。
  • 怎么用：
  • 把 baseline（GUI-only agent + 静态 function-calling agent）先跑一遍，看本场景的"断崖点"在哪；
  • 把 sub-agent 编排 + memory 召回 + skill 调用三件事作为可插拔模块，分别 A/B，避免一次性塞太多变量；
  • 把"证据化验证"逻辑直接复用到生产环境的工具调用后置检查——每条工具调用都验"返回结构是否落库"，比"日志写一行 OK"更可靠。
  • 不该用：当作唯一选型标准——一个 benchmark 不能替代你自有任务的离线回测。
  • 成本与门槛：212 个真实工具 + 沙箱意味着评测需要真去执行调用链，单次跑一个模型成本远高于 BFCL。预算紧的团队可以先把 sub-agent / memory / skill 三个维度作为内部灰度上线指标，用线上 A/B 替代部分评测。
  • 可复现性提醒：⚠️ 摘要未公开代码/数据托管地址，部署复现需关注作者后续开源；本棒未在 GitHub 上独立验证仓库存在性。⚠️

与同方向工作的关系

方向 代表工作 与 MobilePA-Bench 的关系
GUI-centric AndroidWorld、Screenspot、MobileAgent 测"表层点击"，本基准补齐"工具 + 长程 + 记忆"
Static function-calling BFCL、ToolBench 测"离线 API 匹配"，本基准补齐"运行时 + 异常恢复"
Web agent WebArena、Mind2Web 浏览器场景，方法论可迁移（沙箱 + 证据化验证），域不同
OS-level agent OSWorld 桌面 OS，本基准是移动 OS 的对位

横向看，本基准的方法论（可执行沙箱 + 结构化证据 + 维度化评分）和 WebArena / OSWorld 同源，但 mobile 域的工具数量和真实度更高，且显式建模了"子智能体 / 记忆 / 技能"三件过去没人同时测的事。

适合谁读

  • 在做 on-device LLM agent 产品化的人——直接拿来做 baseline。
  • Agent 框架作者——sub-agent / memory / skill 三层抽象能否被这套 benchmark 区分开，决定了你的框架卖点能不能被验证。
  • Benchmark 设计研究者——"沙箱 + 证据化 + 多维度 + 训练反馈"四件套是可复用模式。
  • 不太适合：纯做纯文本生成或纯视觉模型的人——评测目标不是语言能力，而是 agentic 编排能力。

边界与不确定

  • ⚠️ 摘要中的失败注入维度（工具排序/权限/异常）是论文自选维度，是否代表真实生产事故的全谱未独立验证。
  • ⚠️ 具体模型的得分百分比本棒未拉 PDF 核验，引用前需对照 PDF §5 主表。
  • ⚠️ Sub-agent / Memory / Skill 三维评分权重与协同判定协议摘要未给出，PDF §4 为唯一权威。
  • 论文未公开代码/数据托管地址（截至摘要），如需复现需关注作者团队后续开源。
  • ⚠️ 本棒引用的"作者团队背景"（Weigao Sun / Steven Hoi / CogAgent / SeeClick 系）为基于公开论文署名的合理推断，不等于 MobilePA-Bench 与这些工作的直接技术继承关系。

工程落地与核查（Jay）

复现门槛：沙箱建设是最硬的一道关

MobilePA-Bench 的核心价值来自"212 个真实移动工具 + 可执行沙箱"，但这也正是复现门槛最高的部分。工程团队评估引入此基准前，需先确认：

基础设施要求（最低配）：
- Android 10+ 真机或模拟器（推荐 Pixel 系列 + Android Studio SDK）
- ADB 调试权限（沙箱通过 ADB 控制应用状态）
- Python 3.9+ 评测控制脚本
- 16GB RAM 服务器（沙箱 + 212 工具 + 数据库占用）
- 可接受评测时长：单模型完整跑一遍约 2–8 小时（视工具链深度）

推荐配置（省心版）：
- 使用论文团队后续开源的 Docker 镜像（若发布）
- 或自建时用 Android Emulator + pre-baked state snapshot 减少每次重置开销

⚠️ 212 个工具是虚数还是实数：摘要和正文框架均引用 212，但没有明确说这 212 个工具是"不同 App 的 API"还是"同一 App 内不同函数"。前者意味着需要 13 个真实 App 安装在沙箱里，后者意味着仅需少数几个 App。部署团队应要求论文团队提供工具清单再评估集成复杂度。

证据化验证的工程移植：从论文基准到生产检查

论文的证据化验证（每条工具调用后检查"数据库状态是否按预期更新"）是整个设计里最值得工程化复用的部分。生产环境移植建议：

# 生产级工具调用验证（简化版）
def verify_tool_call(tool_name, args, expected_state_delta):
    """
    每次工具调用后执行状态核查。
    expected_state_delta = {"orders.count": +1, "orders.last.status": "confirmed"}
    """
    before = db_snapshot()
    result = actual_tool_call(tool_name, args)
    after = db_snapshot()
    delta = compute_delta(before, after)
    assert delta == expected_state_delta, f"状态不符: {delta} vs {expected_state_delta}"
    return result

这套验证比"日志写一行 OK"可靠得多——它直接查数据库，不依赖日志完整性。推荐移动端 agent 团队在内部评测流水线中强制嵌入此层。

Sub-agent / Memory / Skill 三维度拆解的工程可操作性

论文把这三件事拆成独立维度评分，但工程实现里它们往往互相耦合。以下是可插拔实现的最小化路径：

维度 最小可验证实现 关键坑点
Sub-agent Collaboration 中央规划器负责拆任务 + 委派，子 agent 各自返回结果，中央规划器负责合并 子 agent 超时 / 子任务失败时降级策略未定义
Memory Usage 记忆库存原始对话 + 结构化偏好，召回时用嵌入相似度或规则过滤 记忆污染（过时偏好仍被召回）
Skill Usage 预定义复合技能（函数包），agent 调用时触发"一键执行"而非逐步规划 技能粒度设计：太粗失去复用价值，太细等于没有

工具排序 / 权限 / 异常三类失败注入的优先级

论文的三类失败注入对应生产事故高发场景，工程团队可以据此建立内部故障测试集：

优先级排序（建议）：
P0：工具排序错误（幽灵订单类）→ 每次 API 调用必须先校验前置条件
P1：权限拒绝后无降级 → agent 必须持有备选路径，不能把"授权成功"当作前置假设
P2：网络 / 第三方异常 → agent 需识别"可重试错误"和"不可重试错误"，不能统一重试 3 次

GitHub 仓库未核验的工程风险

摘要未给 GitHub 托管地址（截至摘要），这意味着工程团队目前无法独立验证评测代码的可复现性。引入前应做：

# 第一步：等作者开源后验证
# curl -I https://github.com/<author>/MobilePA-Bench

# 第二步：若已开源，验证工具清单
# git clone <repo> && cat tools.md | wc -l  # 应 ≥ 212

# 第三步：验证沙箱可初始化
# docker build -t mobile-pa-bench . && docker run mobile-pa-bench --check-tools

评分体系的使用建议

论文的三维评分（Sub-agent / Memory / Skill）与最终综合分如何加权，PDF §4 为唯一权威来源。工程团队在使用此基准做选型时：

  • 不要直接用匿名 SOTA 排名做决策——基准模型名称未公开，无法做横向对比；
  • 以本团队的 agent 实现做 baseline，跑出三维度分后针对性补短板；
  • 长期看：若论文开源代码，可把此基准作为内部 agent 迭代的自动化回归测试，每次发版前跑一遍防止能力退化。

核心反直觉结论

MobilePA-Bench 真正测的不是"agent 会不会做事"，而是"agent 会不会在真实失败里正确恢复"——工具排序、权限拒绝、运行时异常，这三类在静态评测里永远测不到，却是生产环境里导致用户体验断崖的直接原因。把这些失败注入机制移植到内部评测，比跑 SOTA 排名更有工程价值。

核查注记（Jay）： - 212 个工具和 13 个功能域来自摘要引用，未独立核验 PDF §3 工具清单——引用具体数字需注明"来自摘要，待核实"。 - 作者团队背景（Weigao Sun / Steven Hoi / Shopee / Salesforce / CogAgent / SeeClick 系）为合理推断，非论文明确声明的技术继承关系。 - 实验设计与消融结构为基于论文摘要的方法论推断，非论文 §5 明确数据。 - GitHub 仓库未给出（摘要截至日），建议引用前先确认作者已公开代码。