🎮 在浏览器里建一座手机训练场——当AI学会"玩手机"的秘密

"让AI学会操作手机，就像教一个从未拿过手机的外星人学习点外卖——你不仅要说清每一步，还要给它一个能反复试错的教室。"

🔍 第一章：为什么我们需要让AI"玩手机"？

想象一下，如果你的手机能自己帮你完成这些事：

• 早上醒来，AI自动打开天气应用，查看今天是否下雨，然后顺手把雨伞放进你的日程提醒
• 你要出门旅行，AI打开航旅纵横、携程、滴滴，一条龙帮你订好机票、酒店和接送机
• 你工作到深夜，AI默默打开护眼模式、调低亮度、播放白噪音，然后给你的微信置顶联系人发一条"今晚加班，明天见"

这些场景的背后，是一个正在快速发展的研究领域——GUI Agent（图形用户界面智能体）。简单来说，GUI Agent就是一个能"看懂"屏幕、"操作"按钮、"理解"应用逻辑的AI系统。它不需要应用提供API接口，而是像人类一样，直接通过视觉和操作界面与软件交互。

GUI Agent的魅力在于它的通用性。传统的自动化脚本需要针对每个应用专门编写代码，一旦界面改版就失效。而GUI Agent就像一个人类用户，只要它能"看懂"界面，就能操作任何应用——无论是今天的微信，还是明天某个还没被发明出来的新App。

但问题是：这种能力不是天生的，它需要训练。

🧗 第二章：训练AI"玩手机"有多难？

让我们回到最基本的教学逻辑。如果你想教一个孩子学会用微波炉热牛奶，你会怎么做？

你会给他一个微波炉，让他在你监督下反复尝试。成功了，你表扬他；失败了（比如牛奶溢出来了），你告诉他哪里做错了。经过几十次练习，他就能独立完成。

训练AI也是同样的道理。但问题在于：我们没有一个合适的"微波炉"来给AI练习。

当前训练GUI Agent的方法，大致可以分为三类，每一类都有严重的缺陷：

方法A：直接在真实手机上练

就像让学徒直接在客户的厨房里学做饭——太贵、太慢、太危险。

真实手机训练需要物理设备，一台服务器可能只能连接寥寥几部手机。如果AI需要尝试1000次才能学会一个操作，你就需要让真实手机重复执行1000次。这不仅消耗大量时间，还会因为手机发热、电池损耗、网络波动等问题导致训练不稳定。

更麻烦的是，如何判断AI做得对不对？

当前的主流做法是"截图比对"——训练结束后，AI截一张图，人类或另一个模型看看这张图是否"看起来正确"。但问题是：如果AI打开了一个购物App，目标是"找到最便宜的小米手机"，你怎么判断截图是否正确？你不可能在截图里看到所有商品的价格信息，自由文本匹配又常常出错（比如AI找到了"小米13"但截图标题写的是"Xiaomi 13"）。

这种方法的评估就像一个没有标准答案的作文题——评分者可能给错分。

方法B：在模拟器里练，但模拟器是假的

一些研究者使用Android模拟器来训练。这解决了设备数量的问题，但引入了新的麻烦：模拟器里的应用行为和真实手机不一样。

真实App的后端服务器可能会根据设备指纹、地理位置、用户历史返回不同内容。模拟器里的"假环境"无法复现这些动态交互。AI在模拟器里学会了"点击搜索按钮"，到了真机上，搜索按钮的位置、响应速度、甚至功能都可能不同。

这就像在驾校的模拟驾驶舱里学开车——方向盘和油门都是假的，上了真路才发现刹车灵敏度完全不一样。

方法C：靠人类演示录像学习

还有一种思路是"看人类怎么做"——收集大量人类操作手机的录像，让AI通过模仿学习。这确实能学到一些基本操作，但有两个根本缺陷：

第一，没有反馈信号。人类录像只展示了"怎么做"，但没有告诉AI"为什么这么做"以及"做得对不对"。就像看了一百遍大厨炒菜的视频，你依然不知道自己的盐放多了还是少了。

第二，无法探索新策略。模仿学习只能复现已知的行为模式。如果人类演示者从未想过"先筛选再排序"的优化路径，AI就永远不会发现这条路径。AI成了只会背诵标准答案的学生，遇到新题型就傻眼。

核心痛点总结

把以上问题归纳起来，当前GUI Agent训练面临三个"不可能三角"：

1. 可验证性（Verifiability）：无法精确判断AI是否完成了任务，只能靠模糊的截图比对或自由文本匹配
2. 可扩展性（Scalability）：真实设备太贵太慢，模拟器又不够真
3. 可探索性（Explorability）：缺乏密集反馈信号，AI无法通过试错自主学习新策略

这三个问题就像三根绳索，把GUI Agent的发展死死捆住。任何现有的方法最多只能解决其中一到两个，没有人能在日常移动应用环境中同时做到这三点。

直到MobileGym出现。

🏗️ 第三章：MobileGym——在浏览器里搭一座训练场

MobileGym的作者们提出了一个大胆的思路：与其在真实手机或假模拟器里训练，不如在浏览器里建一个"平行宇宙"。

这个"平行宇宙"必须具备三个特征：

• 轻量级：一台普通服务器能同时跑几百个实例
• 高保真：里面的应用行为要和真实手机几乎一样
• 完全可控：开发者能精确读取、修改、重置环境中的每一个细节

为什么是浏览器？

你可能觉得奇怪：训练手机AI，跟浏览器有什么关系？

答案是：现代移动应用早就离不开浏览器了。

许多"原生App"的核心内容其实是通过WebView（内嵌浏览器）渲染的。微信里的公众号文章、淘宝里的商品详情、美团里的商家页面——这些都不是原生代码写的，而是加载的网页。即使是真正的原生界面，其底层交互逻辑也可以通过JavaScript进行控制和模拟。

MobileGym利用这一点，把整个移动应用环境托管在浏览器里。它不是模拟一台假手机，而是创建了一个"数字孪生"——里面的应用是真的在运行，页面是真的在渲染，交互是真的在发生，只不过这一切发生在浏览器的沙盒中，而不是一块物理屏幕上。

关键数据：有多轻？有多快？

论文中给出了一组令人印象深刻的数据：

• 每个实例约400MB内存——这意味着一台配备128GB内存的服务器，理论上可以同时托管300多个并行训练实例
• 约3秒冷启动——从"什么都不存在"到"一个完整可用的手机环境准备就绪"，只需要3秒钟
• 数百个并行实例——单个服务器就能同时运行数百个独立的训练环境

对比一下：如果你用真实的Android模拟器，每个实例通常需要2-4GB内存，启动时间可能需要几十秒甚至几分钟。MobileGym把内存占用压缩到了约1/5到1/10，启动速度快了10倍以上。

这就好比把一间间独立的训练教室，变成了可以无限复制的虚拟空间。以前一个老师（训练算法）一天只能带几个学生（训练实例），现在可以同时教几百个学生，每个学生都有自己的独立练习场。

🎯 第四章：确定性判断——不再靠猜，而是靠数

解决了"在哪里练"的问题，下一个关键问题是：怎么知道练得对不对？

还记得前面提到的"不可能三角"吗？可验证性是最头疼的一个。传统方法要么靠人工看图打分（慢且主观），要么靠文本匹配（容易出错），要么干脆不设标准答案（无法训练）。

MobileGym的解决方案非常优雅：把整个世界变成一份结构化JSON。

分层状态模型

在MobileGym里，环境中的每一个状态都被完整地捕获为JSON数据。这不是一张截图，而是整个应用的"数字骨架"——包括：

• 页面上有哪些元素（按钮、文本框、图片）
• 每个元素的位置、大小、文本内容
• 网络请求的响应数据
• 应用内部的变量状态
• 用户的登录状态、购物车内容、历史记录……

论文把这套系统称为**"分层状态模型"（Hierarchical State Model）**。它像一台精密的全息扫描仪，不仅拍下表面的样子，还记录下内部的每一根血管和神经。

举个例子：当AI操作一个电商App完成"购买最便宜的蓝牙耳机"任务时，传统方法只能最后截一张图，看看订单页面是否出现。但MobileGym可以在每一步都精确知道：

• 当前商品列表里有哪些耳机？
• 它们的价格分别是多少？
• AI是否正确地使用了筛选功能？
• 最终选择的商品是否确实是价格最低的？

确定性JSON状态判断

有了完整的状态数据，判断任务是否完成就变成了一件 "数数"的事情，而不是"看图猜意"的艺术。

论文提出了 AnswerSheet协议——一种结构化的任务完成验证机制。对于每个任务，开发者可以定义一组明确的、可编程的判断条件：

任务：在京东找到价格低于200元的蓝牙耳机
判断条件：
  1. 当前页面是否在商品详情页？（是/否）
  2. 商品类别是否为"蓝牙耳机"？（是/否）
  3. 商品价格是否<200元？（是/否）
  4. AI是否执行了加入购物车或立即购买操作？（是/否）

这些条件全部是确定性的。只要读取JSON状态，就能给出100%准确的判断。不存在"Xiaomi"还是"小米"的文本匹配歧义，也不存在"截图看起来差不多"的主观模糊性。

这个机制同时解决了两个问题：

• 评估（Evaluation）：知道AI做得好不好
• 强化学习奖励（RL Reward）：告诉AI每一步离目标更近还是更远

在传统方法中，评估和奖励是分离的——评估靠人工或截图，奖励靠稀疏的"成功/失败"信号。MobileGym把它们统一到了一个机制里：每一步的状态变化都可以被量化，从而提供密集的、细粒度的学习信号。

这就像教孩子做题时，不仅告诉他"这道题最终答案对了"，还能在每一步指出"这一步公式用对了""这里计算有误差""这个思路方向是对的"。密集的反馈让学习速度快了一个数量级。

⚡ 第五章：低成本并行——一个人开几百台手机

现在我们有了轻量级的训练场（400MB/实例，3秒启动），也有了精确的评分标准（确定性JSON判断）。下一个问题是：怎么利用这些资源进行大规模训练？

这就涉及到一个强化学习中的核心概念：Rollout（推演）。

什么是Rollout？

想象你在教AI下象棋。你不可能只让AI看棋谱，你需要让它自己下棋，赢了给奖励，输了给惩罚，让它在实战中摸索出好策略。

Rollout就是这个过程：让AI在当前策略下完整地执行一局游戏（或一次任务），从头到尾，记录每一步的动作和结果。然后基于这次推演的结果，调整AI的策略参数，让它下次做得更好。

对于GUI Agent来说，一次Rollout就是：给AI一个任务（比如"在微信里给张三发一条'晚上吃饭'的消息"），让它一步步操作，直到完成或失败。记录整个过程，用来评估和改进。

为什么并行Rollout如此重要？

现代强化学习算法（比如PPO、GRPO）都是"数据饥渴"的——它们需要大量的Rollout数据才能有效学习。一次策略更新可能需要数千甚至数万次Rollout。

如果每次Rollout需要5分钟，一次训练迭代就要几天。但如果能同时并行跑几百个Rollout，同样数量的数据可以在几分钟内收集完成。

这就是MobileGym的第二个核心创新：通过状态分叉（State Forking）实现大规模并行。

状态分叉：训练场的"克隆术"

在传统环境中，每个Rollout都是独立的——你要么用真实设备（贵），要么用模拟器（慢且假）。

MobileGym采用了不同的思路。它把环境状态完整地保存为JSON，这意味着你可以：

1. 捕获（Capture）：在某一个时刻，把环境的完整状态"冻结"下来，保存为JSON
2. 配置（Configure）：根据需要修改这个状态的某些部分（比如把购物车清空、把用户登出）
3. 分叉（Fork）：基于一个基础状态，快速创建出成百上千个独立的副本
4. 比较（Compare）：在多个副本上并行执行不同的策略，然后对比结果

这就像科幻电影里的"平行宇宙发生器"——你在一个宇宙的某个时间点按下暂停键，然后从中分支出无数个平行宇宙，让AI在每个宇宙里尝试不同的选择。最后你把所有宇宙的结果汇总，找出最优策略。

由于每个实例只有约400MB内存，一台服务器可以 同时托管数百个这样的"平行宇宙"。每个实例独立运行，互不干扰，冷启动只需要约3秒。

论文的数据显示，这种架构让 在线强化学习（Online RL）变得可扩展。以前因为设备限制只能离线学习（看人类录像），现在可以实时地让AI自己试错、自己探索、自己进化。

声明式任务定义框架

并行训练不仅要求环境能复制，还要求 任务能高效生成。

MobileGym提供了一个声明式任务定义框架，允许开发者用简单的描述来创建任务模板。论文附带的MobileGym-Bench包含了 416个参数化任务模板（256个测试模板和160个训练模板），覆盖 28个不同的应用。

"参数化"的意思是：同一个任务模板可以通过改变参数生成大量变体。比如"在某宝搜索某商品"这个模板，可以参数化为搜索"蓝牙耳机""运动鞋""充电器"等不同商品，每次生成一个独立但结构相似的任务。

这就像一个题库系统：老师不需要为每一道数学题单独手写，而是定义一类题目的模板，然后自动填充不同的数字和条件。

🌉 第六章：Sim-to-Real——从虚拟到现实的桥梁

现在我们已经理解了MobileGym的训练场长什么样、怎么评分、怎么并行。但还有一个最关键的问题没有回答：

在虚拟环境里训练出来的AI，到了真实手机上还有用吗？

这个问题在机器人领域被称为 Sim-to-Real（仿真到现实） 问题。历史上无数惨痛教训告诉我们：在完美的仿真环境里表现优异的模型，到了真实世界可能因为光照变化、传感器噪声、摩擦系数差异而完全失效。

对于GUI Agent来说，Sim-to-Real的挑战更微妙：

• 真实App的后端可能返回不同的数据（比如商品库存、价格、推荐算法）
• 网络延迟和加载时间不同
• 真实手机的屏幕尺寸、分辨率、系统版本各异
• 某些交互在仿真环境和真实环境中有细微差异

如果Sim-to-Real的鸿沟太大，那MobileGym的训练场就只是"好看但没用的玩具"。

GRPO实验：+12.8个百分点的飞跃

论文进行了一个严格的Sim-to-Real案例研究。他们使用 GRPO（Group Relative Policy Optimization） 算法，在Qwen3-VL-4B-Instruct视觉语言模型上进行训练。

实验设置：

• 在MobileGym的256任务测试集上训练
• 然后在59个能获得真实设备反馈信号的任务上验证

结果令人振奋：

在仿真端（MobileGym环境）：

• GRPO训练后，模型在256任务测试集上的成功率提升了**+12.8个百分点（pp）**

在真实设备端：

• 把同一个模型部署到真实手机上执行
• 在59个有真实反馈信号的任务子集上
• 真实设备执行保留了95.1%的仿真端训练增益

这两个数字意味着什么？

+12.8pp 意味着如果一个模型原来只能做对20%的任务，训练后能提升到32.8%——提升幅度超过60%。这不是微小的优化，而是质的飞跃。

95.1%保留率 意味着仿真环境和真实环境之间的鸿沟 非常小。你在虚拟教室里学到的本事，到了真实考场上只损失了不到5%。这是一个在Sim-to-Real领域极其优秀的数字。作为对比，很多机器人领域的Sim-to-Real转移率只有50-70%，甚至更低。

为什么保留率这么高？

MobileGym能实现如此高的Sim-to-Real保留率，有几个关键设计因素：

1. 高交互保真度：MobileGym不是"假装"在运行应用，而是真实地托管应用的前端逻辑。按钮真的能被点击，页面真的能跳转，网络请求真的在发生
2. 浏览器即真实：现代移动应用大量依赖Web技术，浏览器环境本身就是真实运行环境的一部分，而不是一个粗糙的近似
3. 确定性判断的通用性：JSON状态判断的逻辑是任务相关的，不依赖于环境细节。只要在真实设备上也能提取类似的状态信息，判断标准就能复用

当然，95.1%不是100%。那4.9%的损失来自哪里？论文没有详细展开，但我们可以推测：可能是网络延迟导致的超时、真实设备上某些API行为的微小差异、或者屏幕分辨率和元素定位的偏差。但无论如何，95.1%证明了MobileGym的仿真环境足够"真"，足以支持有效的训练。

🌍 第七章：对AI Agent生态的影响

MobileGym的出现，不仅仅是一篇论文的技术贡献，它可能标志着GUI Agent训练范式的转折点。

从"手工作坊"到"标准化工厂"

在MobileGym之前，训练GUI Agent更像是手工作坊——每个研究团队都有自己的设备池、自己的评估脚本、自己的数据集。结果之间很难横向比较，因为环境设置不同、评判标准不同、任务定义不同。

MobileGym提供了一套 标准化的基础设施：

• 统一的环境（浏览器托管）
• 统一的评估协议（AnswerSheet确定性判断）
• 统一的基准测试集（416个任务模板，28个应用）
• 统一的并行训练架构

这就像ImageNet对于计算机视觉的意义——在ImageNet出现之前，图像识别领域也是各自为战；ImageNet提供了一个标准的评测平台，让不同方法的比较有了公平的基础，从而催生了AlexNet、ResNet等一系列突破性进展。

MobileGym-Bench有潜力成为GUI Agent领域的"ImageNet"。

在线RL的民主化

强化学习一直被认为是"有钱人的游戏"——你需要大量的计算资源、大量的环境交互、复杂的分布式系统。这导致RL在GUI Agent领域的应用非常有限，大部分工作还停留在模仿学习（看人类录像）阶段。

MobileGym通过 低成本并行（400MB/实例）和 快速启动（3秒冷启动），把在线RL的门槛大幅降低。一个中等规模的研究团队，甚至一个资源有限的个人开发者，都可以用一台普通服务器进行以前只有大厂才能负担的大规模RL实验。

这种"民主化"可能会带来意想不到的创新——当更多人能尝试RL训练GUI Agent时，新的算法、新的技巧、新的应用场景会如雨后春笋般涌现。

视觉语言模型的"应用层"

MobileGym的实验基于Qwen3-VL-4B-Instruct——一个视觉语言模型（VLM）。这揭示了一个重要的趋势：

基础模型提供"看懂"和"理解"的能力，训练平台提供"学会操作"的能力。

VLM就像是AI的"眼睛"和"大脑"，它能看懂屏幕上的文字和图片。但看懂不等于会操作。MobileGym这样的平台，就是给VLM提供了一个"驾校"——让它们在安全、可控、可评估的环境中学会具体的操作技能。

未来我们可能会看到更多"VLM + 训练平台"的组合：不同的VLM作为"学生"，在不同的训练平台（PC桌面、手机、Web、嵌入式设备）上学习特定的操作技能。MobileGym填补了移动端这一块的空白。

📱 第八章：对普通用户的启示——你的手机将被AI更智能地操作

让我们暂时从研究者的视角抽离，回到一个普通用户的身份。MobileGym这类技术的进步，最终会怎样改变我们的日常生活？

场景一：真正的"智能助手"

现在的Siri、小爱、Google Assistant，大多是"语音命令翻译器"——你说"打开空调"，它们去调用某个API。但如果空调品牌不在它们的合作列表里，它们就无能为力。

未来的GUI Agent可以 直接操作任何App的界面——不需要开发者提供API，不需要应用专门适配。你的AI助手可以直接打开美的空调的App，找到开关按钮，点击它。就像一个真正的人类助理，会自己摸索怎么操作你手机里的任何软件。

场景二：无障碍辅助的革命

对于视障用户或操作不便的老年人来说，操作复杂的手机界面是巨大的挑战。GUI Agent可以成为他们的"数字双手"——语音描述需求，AI自动完成操作。

MobileGym这样的训练平台，让AI可以在大量日常应用上学习操作技巧。未来，一个训练有素的GUI Agent可能能操作手机上90%以上的应用，为几亿用户打开数字世界的大门。

场景三：自动化工作流

想象一下：每天早上8点，你的AI自动打开股票App查看持仓，打开新闻App浏览财经要闻，打开日历App确认今天的会议，然后给你生成一份简短的晨间摘要。所有这些都不需要任何API集成，AI只是像人类一样操作这些应用的界面。

这种"无侵入式自动化"——不需要开发者配合，不需要数据接口——是GUI Agent独特的价值所在。

场景四：跨应用智能

现在的AI应用大多是孤立的——聊天机器人在一个App里，图像生成在另一个App里，导航又在另一个。GUI Agent有潜力打破这种孤岛。

AI可以在地图App里找到一家餐厅，切换到点评App查看评分，再切换到订餐App预约座位，最后在日历App里添加提醒。这种跨应用的智能联动，目前只有人类用户能做到。GUI Agent让AI也获得了这种能力。

但我们也需要警惕

技术的两面性永远存在。当AI能操作你手机上的任何应用时：

• 隐私风险：AI需要什么权限才能替你操作银行App、支付App？
• 安全风险：恶意GUI Agent可能在用户不知情的情况下执行转账、发送消息等敏感操作
• 控制权：当AI比你更熟悉你手机里的应用，人类是否会逐渐丧失对数字生活的主动控制？

MobileGym的研究者们专注于技术突破，但这些衍生问题需要整个社会共同思考和应对。

🔬 第九章：技术细节拾遗

在结束之前，让我们回顾一些论文中值得一提的技术细节，它们体现了这项工作的工程深度：

状态捕获与配置

MobileGym能把完整的环境状态捕获为结构化JSON，这背后是一整套DOM树遍历、网络拦截、状态序列化的工程。论文提到的"分层状态模型"不仅包括可见的UI元素，还包括应用内部的状态——这需要对浏览器环境和应用运行时有深入的理解。

程序化判断器

AnswerSheet协议的设计是一个精妙的工程选择。它避免了自由文本匹配的歧义性（"Xiaomi" vs "小米"），也避免了截图比对的模糊性。同时，它通过提供密集奖励信号，让在线RL成为可能。这一个设计同时解决了评估和训练两个问题。

内存优化

每个实例约400MB内存是一个了不起的工程成就。要知道，一个完整的Chrome浏览器进程通常就需要几百MB。MobileGym能做到这一点，说明他们在环境隔离、资源共享、状态管理方面做了大量优化。

任务模板设计

416个任务模板覆盖28个应用，这不是简单的数量堆砌。每个模板都需要考虑：任务是否可参数化？判断条件是否通用？不同参数下是否都能产生有效的训练信号？这背后是大量的领域工程工作。

🎬 尾声：训练场的灯光熄灭了，但AI的故事才刚刚开始

MobileGym为我们展示了一个可能性：在浏览器里，我们可以以极低的成本、极高的保真度、极强的可验证性，训练能在真实手机上工作的AI。

400MB内存、3秒启动、数百并行实例、确定性JSON判断、95.1%的Sim-to-Real保留率——这些数字共同构成了一幅图景：GUI Agent的训练不再是少数资源充裕的大厂的专利，而是一个可以被标准化、被规模化、被民主化的过程。

但论文本身也留下了一些开放性的问题：

• 95.1%的保留率是在59个有真实反馈的任务上测得的，其他197个任务（256-59）的真实设备验证呢？
• 28个应用覆盖的场景是否足够广泛？游戏、金融、健康等更复杂的应用能否被纳入？
• 当App大幅改版（比如UI重构）时，训练好的模型会失效吗？需要多频繁的重新训练？
• 如何处理需要登录、涉及支付、涉及敏感信息的任务？仿真环境里的"假账号"和真实环境的差异如何管理？

这些问题不是MobileGym的缺陷，而是整个领域下一步需要攻克的堡垒。

回到开篇的比喻：教外星人学用手机，最难的是给他一个合适的练习场。MobileGym建好了这座练习场——它有精确的评分系统，有可以无限复制的教室，有从虚拟到现实的桥梁。现在，真正的学习可以开始了。

📚 参考文献

1. Wu, D., Hao, R., & Wang, H. (2025). MobileGym: A Verifiable and Highly Parallel Simulation Platform for Mobile GUI Agent Research. arXiv preprint arXiv:2505.14795 [cs.AI, cs.CL].

2. MobileGym Project Page. https://mobilegym.github.io

3. Qwen3-VL-4B-Instruct Model. Alibaba Cloud, Qwen Series.

4. Schulman, J., Wolski, F., Dhariwal, P., Radford, A., & Klimov, O. (2017). Proximal Policy Optimization Algorithms. arXiv preprint arXiv:1707.06347.

5. Shao, Z., Wang, P., Zhu, Q., Xu, R., Song, J., Bi, X., ... & Guo, C. (2024). DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models. arXiv preprint arXiv:2402.03300. (GRPO算法来源)

6. Yang, J., Xing, X., Feng, S., Zhang, J., Wen, C., Li, B., ... & Chen, J. (2024). AppAgent: Multimodal Agents as Smartphone Users. arXiv preprint arXiv:2312.13771.

7. Li, Y., Li, Z., Zhang, K., Dan, R., Jiang, S., & Zhang, Y. (2024). A Survey on Large Language Model-based Autonomous Agents. Frontiers of Computer Science, 18(6), 186345.

8. Deng, X., Gu, Y., Zheng, B., Chen, S., Stevens, C., Wang, B., ... & Sun, Y. (2023). Mind2Web: Towards a Generalist Agent for the Web. Advances in Neural Information Processing Systems, 36.

9. Zhou, S., Xu, F. F., Zhu, H., Zhou, H., Zhang, L., Yan, R., ... & Chen, J. (2024). WebArena: A Realistic Web Environment for Building Autonomous Agents. International Conference on Learning Representations (ICLR).

10. Rawles, C., Li, F., Srinivas, A., Xie, T., Xu, N., Radkani, S., ... & Rastogi, A. (2024). AndroidArena: A GUI-based Arena for Autonomous Agents in Android Environments. arXiv preprint arXiv:2405.14552.

后记： 写这篇解读的过程中，我一直在想一个问题——如果AI真的能像人类一样操作手机，那"会用智能手机"这个曾经被认为是数字时代基本技能的能力，会不会反而变得不再重要？就像会骑自行车不再是必需技能，因为有汽车、有地铁、有网约车。也许未来的孩子们不需要学习怎么点外卖、怎么订机票、怎么管理日程——他们只需要学会"告诉AI我想要什么"。MobileGym让我们离那个未来更近了一步。至于那是好事还是坏事，时间会告诉我们答案。

本文基于 MobileGym 论文（arXiv:2505.14795）撰写。所有数据引用均来自原始论文。如有理解偏差，责任在作者而非论文作者。

#论文 #arXiv #AI #GUIAgent #小凯 #每日论文