MobilePA-Bench:当AI助手要在真实手机系统里"跑腿",到底行不行？

你有没有想过，让手机里的AI助手帮你订一次三天两夜的上海之旅，它到底要经历多少步骤才能真正把事情办成？

不是简单地回答"好的，我帮你查一下机票"，而是真的要记住你喜欢住希尔顿、喜欢短途航班、喜欢逛博物馆，然后去调用订票系统，处理订票失败的异常，扫描二维码填写游客信息，最后还要在没有现成接口的地方切换到"手动点屏幕"模式完成一次场馆预约。

这听起来像是任何一个称职的助理都能做到的基本功。但现实是,目前最强的大模型在这套完整流程里,整体只能做到75.52%的成功率。这意味着即便是表现最好的AI系统,每四个任务里也有一个会出岔子。这个数字,来自阿里巴巴MAI团队最新发布的评测基准MobilePA-Bench。

这篇论文有意思的地方在于,它没有简单地说"现在的AI手机助手不够好",而是把"不够好"这件事拆解得非常具体:哪里不好、差在哪个环节、差多少个百分点。这种颗粒度的诚实,恰恰是这个领域目前最缺的东西。

两条评测老路,为什么都走不通

先说说过去大家是怎么测试手机AI助手的。

第一条路叫GUI导向评测,像AndroidWorld、OSWorld这类基准,做法是让AI看手机截图,然后判断该点屏幕哪个位置、该滑动哪个方向。这条路的问题在哪?它把AI变成了一个"看图点按钮"的机器,却忽略了一个事实:真正复杂的任务,往往不是靠点屏幕解决的,而是要调用后台的系统接口。

打个比方,你去银行办理业务,一个只会在柜台前排队等号的助理,和一个能直接打电话给后台系统查账、改密码、办转账的助理,效率完全不是一个量级的。如果一个手机AI助手只会模拟手指点击,那意味着每一次操作都要经历"识别界面元素、计算坐标、模拟点击、等待渲染"这一整套视觉解析流程,既慢又费电,还容易因为界面稍微改版就彻底失灵。

第二条路叫静态函数调用评测,像伯克利函数调用排行榜（BFCL）*：一个专门评测大模型能否正确选择并调用API函数的基准测试,通过检查模型输出的JSON格式是否和标准答案匹配来打分。

这类评测的问题更隐蔽。它只看AI"说了什么",却不管AI说的这些话放到真实系统里执行会发生什么。举个例子,如果你让AI订一张机票,静态评测只关心AI是否调用了"book_flight"这个函数、参数格式对不对,但它根本不会去检查:这趟航班到底存不存在?账户余额够不够?这个订票请求提交后,数据库里的座位库存到底有没有真的减少一个?

如果不引入真实的运行环境反馈,AI永远学不会处理"权限不足""参数缺失""系统报错"这些真实世界里天天发生的意外情况。这就好像让一个厨师只在纸上写菜谱,从不进厨房试做,他写出来的步骤可能逻辑完美,但真到了火候把控、食材临时缺货的时候,照样手忙脚乱。

MobilePA-Bench要解决的,正是这两条路都没顾及到的中间地带:一个真正活着的、会给出真实反馈的手机操作系统模拟环境。

四种能力,拼出一个真正靠谱的手机管家

论文提出,一个称职的手机规划智能体(论文里管它叫"中央规划agent"),需要同时具备四种能力,缺一不可。

第一种叫基础工具使用(Basic Tool Use)*：指AI能否正确选择该调用哪个系统接口、填对参数、处理好接口之间的依赖顺序,并且在遇到系统报错(比如权限被拒绝)时能够合理应对,而不是硬着头皮乱操作。

这是最基本的功夫,相当于一个新员工要先学会怎么正确填表格、走流程,不能连基本操作都出错。

第二种叫子智能体协作(Sub-agent Collaboration)*：当结构化的API接口无法满足需求时(比如某个APP没有开放接口,只能靠手动点屏幕操作),中央规划者要懂得把这部分工作外包给专门的GUI子智能体去完成,并且要给出清晰完整的任务交接信息。

这里有个设计思路特别聪明。论文的作者们意识到,如果让中央大脑事事亲力亲为,包括去识别屏幕上每一个像素、判断按钮在哪里,那这个大脑的算力和注意力全被这些琐碎的视觉解析占满了,根本没有精力去做真正需要智慧的高层决策。所以他们的方案是把"看屏幕点按钮"这件体力活外包出去,中央规划者只需要负责"决定要不要外包、外包给谁、外包的任务说清楚没有"。

这就像一个公司的CEO,不会自己去跑腿送快递,但他必须清楚什么时候该把这件事交给快递员,交代任务的时候要把地址、收件人、注意事项讲清楚。如果CEO什么都要自己上手做,公司效率反而会更低,因为决策的时间被琐事挤占了。如果CEO完全不管细节交接,把一句"帮我把东西送过去"甩给快递员就不闻不问,那货物很可能送错地方。

第三种叫记忆使用(Memory Usage)*：指AI能否主动去查询用户过去存下来的偏好、身份信息、习惯记录,来补全那些用户没有明说、但其实早就存在系统里的隐含信息。

这一点特别贴近真实生活场景。你跟人类助理说"按我平常的通勤专注模式来设置手机",一个称职的助理会立刻想起来,"哦,你说的是静音加媒体音量调到20%那套设置",而不会反问你"什么是通勤专注模式"。AI要做到这一点,必须先主动查询记忆库,再把查到的信息用到具体操作里。

第四种叫技能使用(Skill Usage)*：指的是那些被打包成"套餐"的复合型多步骤流程,AI可以直接调用整套流程,而不需要每次都从零开始一步步规划。

这个设计的巧妙之处在于降低了出错概率。假设订一次机票加酒店需要十个步骤,如果AI每次都要自己现场规划这十步该怎么排列,那么每一步都有可能出错,十步累积下来错误率会指数级上升。但如果这十步被打包成一个"预训练好的套路",AI只需要识别出"这是一次标准的机票加酒店预订任务",然后调用这个套路,出错的机会就大大减少了。

这跟你去一家熟悉的餐厅点"今日套餐"是类似的道理。如果你每次点餐都要重新告诉服务员每个菜怎么做、放多少盐,不仅麻烦,还容易漏掉某个步骤;而直接说"来一份A套餐",厨房早就有一套标准流程等着你,出错率自然更低。

一个"活的"手机沙盒,而不是纸上谈兵

要测试这四种能力,光靠嘴上说说是不够的,必须要有一个真正会运行、会给反馈的环境。

论文团队搭建了一个交互式、有状态的手机模拟沙盒*：一个模拟手机操作系统的软件环境,里面有真实的联系人数据库、日历数据库等各种应用数据,AI发出的每一个操作指令都会真正修改这些数据,并返回结构化的执行结果反馈,而不是简单地打个对错分。

这套沙盒里塞进了212个真实手机工具*：涵盖通讯、日程管理、系统设置、娱乐媒体等13个功能领域的具体接口,比如添加联系人、调整屏幕亮度、播放音乐这类具体功能,涉及1705个真实的用户任务场景。

论文里给了一个非常具体的例子:添加联系人这个操作。AI调用add_contact这个工具,传入姓名和电话号码,系统的执行代码会先检查这两个参数是否为空,检查这个联系人是否已经存在,然后生成一个新的联系人ID编号,把数据写进联系人数据库,同时在操作日志里记一笔,最后把执行结果(成功还是失败,新联系人的ID是什么)返回给AI。这整个过程都是"活的",数据库真的会改变,日志真的会留痕,不是纸面上的模拟。

沙盒还故意制造麻烦。论文里提到,系统会主动注入缺参数、权限被拒绝、指代信息模糊这类真实世界常见的"绊脚石",逼着AI在遇到报错反馈之后,能够根据反馈信息重新调整计划,而不是死板地按照原计划一条路走到底,撞墙也不改。

这个设计背后的思路值得琢磨。如果测试环境永远是一片坦途,从不出岔子,那AI学到的能力永远是"理想状态下怎么做",一旦部署到真实世界,遇到第一个意外就可能直接崩溃。这就好比开车考试,如果驾校的考场永远都是空荡荡的马路,从没模拟过突然窜出来的行人或者突发的爆胎,那学员拿到驾照后第一次遇到真实路况的突发情况,大概率会手忙脚乱。真正有效的训练,必须把意外也设计进去。

评测不是一刀切,而是分了三个"证据类型"

这篇论文另一个我觉得挺讲究的地方,是它没有用一套死板的评分标准去套所有任务。

作者们意识到,不同类型的任务,判断"做对了"的标准根本不一样。有些任务必须严格按照固定顺序调用固定的工具,一步都不能差;有些任务允许用不同的路径达到目的,只要最后系统里的数据状态是对的就算成功;还有一些开放性任务,比如帮用户推荐附近的餐厅,压根没有唯一正确答案,只能看AI的行为是否合理。

于是论文把所有任务分成了三个证据对齐的查询桶*：论文称之为Query Bucket,分别针对"工具调用是否精确匹配""最终数据库状态是否正确""AI的行为表现是否合理"这三种不同的判断标准。

第一个桶叫工具调用桶,针对那些必须严格按顺序执行的任务,比对的是AI调用的工具名称、顺序、参数是否和标准答案完全一致。

第二个桶叫状态变化桶,针对那些允许多条路径但结果状态唯一确定的任务,比对的是执行完毕后数据库里到底发生了什么改变,而不纠结AI具体走了哪条路。

第三个桶叫智能体行为桶,针对那些开放式、需要交互判断的任务,比对的是AI有没有在该找子智能体帮忙的时候找对了人,有没有在该询问用户澄清意图的时候恰当地提问。

如果只用第一种标准去卡所有任务,那些走了不同但同样正确路径的AI会被冤枉判错,这就是过于严苛;但如果只看最终状态,完全不管过程,那些开放式、需要互动判断的任务又根本无法评判优劣,这就是过于宽松。三桶分类的意义在于,让每种任务都用最贴合它本质的标准去衡量,而不是用一把尺子量所有东西。

实测结果:没有一个AI是全能选手

论文测试了13个当下主流的大模型,包括Claude系列、Gemini系列、GPT系列、Qwen系列等等。结果显示出一个挺有意思的现象:没有任何一个模型能在四项能力上都拿第一。

| 模型 | 综合得分 | 基础工具使用 | 子智能体协作 | 记忆使用 | 技能使用 |

| Claude-Opus-5 | **75.52** | **83.85** | 62.92 | 58.51 | **78.00** |

| Claude-Fable-5 | 75.31 | 83.37 | 70.79 | 62.50 | 70.25 |

| Kimi-K3 | 73.01 | 77.40 | 62.92 | 63.56 | 76.50 |

| Qwen-3.8-Max | 72.51 | 77.88 | 53.93 | **64.63** | 76.25 |

| Gemini-3.6-Flash | 71.21 | 78.65 | 66.29 | 62.77 | 63.50 |

| Gemini-3.1-Pro | 71.18 | 80.58 | **77.53** | 48.67 | 67.00 |

| Kimi-2.6 | 55.63 | 70.38 | 43.82 | 33.78 | 46.50 |

Claude-Opus-5在综合得分和基础工具使用、技能使用上排名第一,但它的记忆使用只有58.51%;Gemini-3.1-Pro在子智能体协作上遥遥领先,拿下77.53%,但它的记忆使用只有可怜的48.67%;而Qwen-3.8-Max恰恰在记忆使用上反超所有对手,拿到64.63%的最高分,但它的子智能体协作能力只有53.93%,是全场倒数。

这个现象说明什么?它说明当下的大模型学到的能力是碎片化的,某个模型可能特别擅长精确执行指令,但在"记住用户过去说过的偏好"这件事上却很笨拙。这就像一个员工业务能力很强,执行任务一丝不苟,但完全记不住客户上次交代过什么特殊要求,每次都要客户重新解释一遍。这种割裂在实际使用中会带来很糟糕的体验,因为用户期待的是一个统一、稳定的助手,而不是一个"某些方面很聪明、某些方面很健忘"的拼盘。

论文的稳定性测试也值得一提。他们用同一个模型Qwen3.6-27B跑了三次完整评测,发现基础工具使用、记忆使用、技能使用这三项的标准差都在1个百分点以内,说明评测结果是稳定可信的,不是随机波动出来的巧合。唯一波动稍大的是子智能体协作这一项,但那是因为这个维度的题量本身只有89道,少数几道题的判定差异就会带来相对更大的比例波动,这属于统计学上正常的样本量效应。

记忆这道题,为什么这么难

四项能力里,记忆使用的整体表现是最惨的,13个模型的平均分只有50.98%,最高分也只有64.63%。这意味着即便是表现最好的模型,在需要调用用户历史记忆的任务上,依然有超过三分之一会翻车。

为什么记忆这么难?论文分析指出,记忆任务的难点不只在于"找到"正确的记忆条目,更在于"找到之后怎么正确地用"。

举个例子,用户的记忆库里存着"我的秘书叫Maya"这条信息,当用户说"给我秘书发个消息说火车延误了"的时候,AI必须先意识到这句话里藏着一个需要查询的隐含信息,主动去调用记忆搜索工具,查到"Maya"这个名字,然后才能正确地把消息发给正确的联系人。这中间任何一步掉链子,比如AI压根没想到要去查记忆,或者查到了记忆但没有正确使用查到的信息,整个任务就算失败。

这其实揭示了一个更深层的问题:记住信息和用好信息,是两种完全不同的能力。就像人类的记忆一样,你可能记得某个朋友喜欢喝美式咖啡不加糖,但如果你在帮他点单的那一刻,压根没想起要去调取这条记忆,那记住了也是白记。AI系统同样面临这种"检索时机"的挑战,不是记忆库里没有答案,而是AI在需要用到答案的那一刻,没有触发去查找答案的动作。

技能打包,确实管用

相比记忆使用的普遍低分,技能使用这一项的表现明显好很多,13个模型平均达到66.77%,最高的Claude-Opus-5拿到78%。

这个数据支撑了前面提到的设计思路:把多步骤流程打包成现成的套路,确实能减少长链条任务里的错误累积。论文原文里提到一个细节,技能使用的得分在多数模型身上都超过了记忆使用的得分,这说明"给AI一套现成的操作手册"比"让AI自己一步步现场规划"更靠得住。

但这不意味着技能打包是万能药。论文特别区分了两种技能调用场景,一种叫纯技能路由,另一种叫混合工具技能路由,也就是任务里既要用现成的技能包,又要穿插一些临时的单独工具调用。数据显示,在这种混合场景里,即便是表现最好的模型依然有相当比例的失误,这说明技能包解决的是"重复性长流程"的问题,但一旦任务需要灵活穿插临时决策,考验依然存在。

错误是会传染的

论文最后总结的一个洞察,我觉得特别值得拿出来单独说一说:现实世界里的任务,很少是单一能力维度的孤立测试,而当一个任务同时牵涉记忆查询、技能调用、工具执行、子智能体协作这好几个环节的时候,每个环节各自的一点点误差,会像滚雪球一样叠加放大,最终导致整体任务失败率远高于任何单项能力的失败率。

拿论文里举的那个"发送通勤专注日程给秘书"的例子来说,这个任务需要AI先查记忆知道秘书是谁,再查记忆知道通勤专注模式具体设置是什么,然后可能还要加载一个专门的技能包去批量执行设置,最后再调用发消息的工具把结果告诉秘书。假设AI在每一个环节上都有百分之十几的犯错概率,那么这四个环节串联起来,整体成功率会被这些独立的小失误层层削减,最终远低于任何一个单项能力测出来的分数。

这就跟工厂流水线的次品率是一样的道理。如果每道工序的良品率是95%,单独看每一道工序都相当不错,但如果一件产品需要经过五道这样的工序才能出厂,最终的整体良品率会跌到大约77%左右,因为每一道工序的瑕疵都在往下传递、叠加。手机AI助手面临的正是这种多环节串联的考验,单项能力再强,只要有一环掉链子,整个任务照样黄了。

论文里还提到一个耐人寻味的细节:当AI遇到权限被拒绝这类系统报错时,它更倾向于硬着头皮继续瞎猜、编造一个看似合理的操作,而不是停下来向用户提问澄清,或者根据报错信息调整策略。这说明当下的大模型缺乏一种"知道自己不知道"的克制感,遇到障碍时的第一反应是硬闯,而不是求助或退一步重新评估。这种倾向放在真实的手机使用场景里是相当危险的,想象一下AI在没有权限的情况下,依然"想办法"绕过去执行了某个本该被拦下的操作,这带来的可能不只是任务失败,还可能是隐私或安全上的隐患。

写在后面

读完这篇论文,让我印象最深的不是那个75.52%的最高分,而是那个"没有一个模型全能"的现象。

四个能力维度,四个不同的冠军,这说明现阶段的大模型进步路径可能是碎片化的:研发团队优化了工具调用能力,记忆能力可能没跟上;某个模型的多智能体协作特别强,可能是因为专门做了针对性训练,但这种针对性训练没有覆盖到记忆这一块。这跟我们想象中"越大越强的模型天然什么都好"的直觉,其实是有出入的。

另一个让我多想了一层的地方是关于"技能打包"这个设计。它本质上是在用结构化的经验去弥补模型临场推理的不稳定性,这跟人类专家依赖"套路"和"肌肉记忆"来减少现场决策负担是同一个道理。但这也意味着,一个系统如果太依赖预设的技能包,遇到真正需要灵活应变的新情况时,反而可能显得更僵化。这中间的平衡,论文没有给出答案,留下的是一个值得继续追问的方向:多少比例的任务应该交给固定套路,多少比例应该保留给临场推理?这个比例,恐怕才是决定一个手机AI助手到底好不好用的真正分水岭。

Q&A

Q1：MobilePA-Bench是什么?

A：MobilePA-Bench是阿里巴巴MAI团队发布的一个手机AI智能体评测基准,它通过一个真实运行、会返回状态反馈的手机系统模拟沙盒,测试AI在工具使用、记忆调用、技能执行、子智能体协作四个维度上的综合能力,包含1705个真实任务和212个手机工具接口。

Q2：目前最强的AI模型在手机任务上表现怎么样?

A：论文测试的13个主流大模型里,表现最好的Claude-Opus-5综合得分只有75.52%,这意味着即便是最强的模型,平均每四个任务也会做错一个,说明当前AI距离真正可靠地自主操作手机还有明显差距。

Q3：为什么记忆使用这项能力对AI来说特别难?

A：因为记忆使用不仅要求AI主动查询用户过去存下的偏好信息,还要求它把查到的信息正确用到后续操作里。论文数据显示13个模型在这一项上平均只有50.98%,最高分也只有64.63%,是四项能力里表现最差的一项。