AI 自动用手机哪家强？MobiAgent、Mobile-Agent、Mobilerun 和 mobile-use 对比

最近连续整理了四个移动端 GUI 智能体项目：MobiAgent、Mobile-Agent、Mobilerun 和 mobile-use。它们都和“让 AI 操作手机或移动 App”有关，但定位并不一样。

简单说：MobiAgent 更像可定制手机智能体研究系统；Mobile-Agent 是通义实验室围绕 GUI agent 的系列工作集合；Mobilerun 更偏可落地的本地/云端移动设备控制框架；mobile-use 则强调真实 App 操作、任务分解、数据抽取和 AndroidWorld 评测。

基本信息对比

MobiAgent

MobiAgent 来自 IPADS-SAI，定位是一个可定制的手机智能体系统。它不是只提供一个执行脚本，而是把 MobiMind 模型家族、AgentRR 动作记录与回放、MobiFlow 评测基准、手机 runner、数据采集和 Android app 放到同一套体系里。

它的特点是研究系统比较完整。MobiAgent 关注真实手机任务中的准确率、效率、记忆和可复用动作序列。README 中提到的用户画像记忆、经验记忆、动作记忆，以及多任务执行，都说明它在尝试处理长期任务和重复任务。

它的门槛也相对高。完整运行需要设备、ADB、模型部署、依赖环境、可选的向量数据库和图数据库配置。更适合研究或工程实验，不太像面向普通用户的“安装即用”手机助手。

它解决什么问题

手机 GUI 智能体比网页或桌面自动化更麻烦。它需要理解截图、识别控件、决定下一步操作，还要通过 ADB 或移动端运行环境执行点击、输入、返回、切换应用等动作。真实任务往往不是单 App 内的一次操作，而是跨越搜索、购物、社交、支付、地图等多个应用的连续流程。

MobiAgent 的价值在于把这些环节系统化：

• 用 MobiMind 承担任务规划、决策和界面定位等能力。
• 用 runner 连接手机，通过 ADB 执行预定义任务并记录轨迹。
• 用 AgentRR 复用成功动作序列，减少重复任务的推理与操作成本。
• 用 MobiFlow 评测真实移动场景中的任务完成情况。
• 通过数据采集、标注和处理工具，降低移动 GUI 任务数据构建成本。

这让它更像一个移动智能体实验平台，而不是只能跑演示的模型项目。

最近更新值得关注

项目 README 显示，MobiAgent 在 2025 年 8 月开源，之后持续补齐模型、Runner、记忆系统和端侧运行能力。2025 年 12 月开始，项目支持在手机上进行纯端侧推理，并发布了统一 GUI agent runner，可配置 MobiAgent、UI-TARS、AutoGLM、Qwen-VL、Gemini 等多种模型。

到 2026 年 3 月，项目又发布了 GUI-based mobile “claw” MobiClaw，以及新的 MobiMind-1.5-4B 模型。这说明它的方向不只是论文复现，而是在继续把移动端执行、模型能力和操作工具链往产品化方向推进。

记忆系统是关键补丁

MobiAgent 支持用户画像记忆、经验记忆和动作记忆。用户画像记忆用于给规划提供偏好上下文；经验记忆用于检索类似任务的执行经验；动作记忆则通过 AgentRR 缓存和复用成功动作序列。

这很重要，因为手机任务天然带有重复性。比如用户常用某个 App 搜索商品、打开固定联系人、在特定页面填写信息。如果每次都从零开始看图、规划和点击，成本高且容易出错。记忆模块可以把一部分“已经学会的流程”沉淀下来，让后续任务更快、更稳定。

不过，记忆也会带来新的治理问题。用户偏好、历史任务、应用路径和操作轨迹都可能包含敏感信息。真正落地时，项目需要明确哪些内容进入记忆、保存多久、如何删除，以及是否允许模型在不同任务之间复用这些上下文。

适合谁关注

如果你只想找一个现成的手机自动化 App，MobiAgent 目前仍更偏研究和工程框架。它需要配置模型服务、移动设备、ADB、依赖环境和任务文件，完整跑起来有一定门槛。

但如果你关注移动 GUI agent、端侧智能体、多模型 runner、任务轨迹复用或智能体评测，MobiAgent 很值得跟踪。它把模型、执行、评测和数据流水线放在一起，能帮助研究者和开发者更完整地观察移动智能体的真实短板。

Mobile-Agent

Mobile-Agent 来自 X-PLUG/通义实验室。这个仓库已经从早期手机操作智能体，扩展成一个 GUI 智能体家族：Mobile-Agent-v1/v2/v3/v3.5、Mobile-Agent-E、PC-Agent、GUI-Critic-R1、UI-S1、GUI-Owl、ToolCUA 等都在同一条技术线上。

它的特点是跨度大。Mobile-Agent 不只关心手机，还覆盖桌面、浏览器、云手机、云桌面、GUI 感知、grounding、错误诊断、强化学习和 GUI/工具路径编排。GUI-Owl 系列模型让它更像一个跨平台 GUI agent 基础模型路线，而不是单个移动自动化项目。

它的不足也来自这个跨度：仓库更像研究成果集合，使用者需要先判断自己要跑哪个子项目、哪个模型和哪个场景。它适合跟踪技术演进和复现实验，不一定是最快接入业务流程的选择。

它解决什么问题

GUI 智能体面对的不是标准 API，而是应用界面。它需要看懂屏幕、定位控件、规划步骤、执行点击或输入，并在失败时修正路径。移动端场景尤其复杂，因为任务往往跨多个 App，界面状态也会随着登录、权限、弹窗、网络和个性化推荐变化。

Mobile-Agent 系列把这个问题拆成了几个方向：

• 用 Mobile-Agent-v1/v2 探索手机 GUI 的视觉感知与多智能体协作。
• 用 PC-Agent 把多智能体操作扩展到 PC 场景。
• 用 Mobile-Agent-v3 和 v3.5 推进多平台 GUI 智能体框架。
• 用 GUI-Owl 系列模型提供跨平台 GUI 感知、定位和端到端操作能力。
• 用 GUI-Critic-R1、UI-S1、ToolCUA 等工作补足错误诊断、强化学习和 GUI/工具路径编排。

这让它不像一个单点 demo，而更像一条围绕“计算机使用智能体”的研究和工程路线。

v3.5 的重点

仓库 README 显示，Mobile-Agent-v3.5 已经可以通过 ModelScope 在线 Demo 和阿里云百炼在线 Demo 体验，百炼上也提供了 v3.5 API。2026 年 3 月，v3.5 还上线了阿里云无影云手机，面向云端 Android 环境提供移动使用体验。

这说明项目正在把“本地跑实验”之外的使用方式也补上。对于 GUI 智能体来说，云手机和云桌面很重要：它们能提供更稳定、更可复现的运行环境，减少本地设备、系统版本、分辨率和 App 状态带来的差异。

如果你想评估这类智能体，稳定环境往往比模型本身更容易被低估。没有可控的执行环境，就很难判断一次失败是模型能力不足、界面变化、设备问题，还是任务定义不清。

GUI-Owl 是底层变化

Mobile-Agent-v3 之后，GUI-Owl 成了这条路线里的关键模型层。README 中把 GUI-Owl 描述为具备 GUI 感知、grounding 和端到端操作能力的多模态跨平台 GUI VLM。到 GUI-Owl-1.5，模型系列已经覆盖 2B、4B、8B、32B、235B，并支持桌面、移动端和浏览器自动化。

这类模型的意义在于，它不只是回答“屏幕里有什么”，还要把自然语言目标、截图内容、界面元素位置和下一步操作连起来。对 GUI agent 来说，视觉理解、坐标定位、操作规划和状态记忆缺一不可。

当然，模型越通用，工程边界也越重要。真实部署时仍然需要执行器、权限控制、任务日志、回滚机制和人工确认。尤其是涉及支付、账号、文件、消息发送等高风险操作时，GUI agent 不能只追求自动完成，还要能清楚说明自己准备做什么。

ToolCUA 暗示的新方向

2026 年 5 月，项目新闻里提到 ToolCUA，定位是面向 GUI 与工具最优路径编排的端到端 Computer Use Agent。这个方向很有意思，因为它承认了一个现实：不是所有任务都应该靠点屏幕完成。

有些事情适合 GUI 操作，比如登录后台、处理复杂表单、读取没有 API 的应用状态；有些事情更适合调用工具，比如检索、计算、解析文件、访问结构化接口。真正可用的计算机使用智能体，需要学会在两者之间切换。

这也是 Mobile-Agent 系列比早期手机自动化项目更值得看的地方。它不再只问“智能体能不能像人一样点 App”，而是在问“智能体什么时候该看屏幕，什么时候该用工具，什么时候该停下来确认”。

适合谁关注

如果你只是想找一个开箱即用的手机自动化助手，Mobile-Agent 仍然偏研究和工程框架。它涉及模型、运行环境、评测任务和具体执行器，完整跑通通常需要一定配置成本。

但如果你关注下面几类问题，它很值得跟踪：

• 移动端 GUI agent 如何从演示走向稳定执行。
• 桌面、浏览器和手机自动化能否统一到同一套智能体框架里。
• GUI 模型如何处理 grounding、反思、记忆和错误诊断。
• 智能体如何在 GUI 操作与工具调用之间选择路径。
• 云手机、云桌面是否会成为 GUI agent 的重要运行环境。

这些问题会直接影响个人助理、企业流程自动化、远程桌面操作、应用测试和无 API 系统集成。

Mobilerun

Mobilerun 来自 droidrun，定位更工程化：让 LLM agent 通过自然语言控制 Android 和 iOS 设备。它提供 CLI、TUI、Docker、Python API、Portal-based control、vision mode、reasoning mode、结构化输出、自定义工具、app cards、执行轨迹和云端设备服务。

它最突出的地方是模型无关和部署形态清楚。开发者可以接 OpenAI、Anthropic、Gemini、Ollama、DeepSeek、OpenRouter 或 OpenAI-compatible providers；也可以选择本地框架或 Mobilerun Cloud。对真实团队来说，这种“设备控制层和模型层解耦”的设计很重要。

它也有移动端自动化常见的门槛：Android 需要开发者选项、USB 调试和 Portal app；iOS 需要单独流程；复杂任务还要处理权限弹窗、页面变化、失败重试和日志排查。它更适合愿意把 mobile agent 当成工程组件接入的人。

它解决什么问题

移动端自动化最麻烦的地方，是自然语言任务和真实设备操作之间隔着很多层。模型需要知道当前打开了什么 App、页面有哪些控件、是否需要截图补充视觉信息、下一步该点哪里，以及执行失败后如何继续。

Mobilerun 把这些能力整理成一套框架：

• 通过 CLI 和 TUI 运行一次性自然语言任务、检查设备、回放宏和调试流程。
• 通过 Python API 构建自定义移动自动化工作流。
• 支持 Android 和 iOS，Android 通过 Portal app 和无障碍能力控制设备，iOS 走单独的 Portal 流程。
• 同时使用 accessibility tree 和截图，让模型既能读结构化 UI，也能看视觉画面。
• 支持 --vision、--vision-only 和 --reasoning 等模式，应对不同复杂度的任务。
• 支持结构化输出、app cards、自定义工具、凭据和执行轨迹追踪。

这让 Mobilerun 更像一个“移动端 agent runtime”，而不是单纯把截图发给大模型再模拟点击。

本地框架和云端服务

Mobilerun 把本地框架和 Mobilerun Cloud 分得比较清楚。本地框架适合开发者在自己的机器和设备上运行 agent，拿到更强的代码级控制；Cloud 则面向托管设备、REST API、SDK 和规模化工作流。

这个分层很重要。很多移动自动化场景开始时只是“帮我在手机上跑一个任务”，但一旦进入团队使用，就会遇到设备管理、并发、日志、失败重试、权限和 API 调用的问题。Cloud 不是替代本地框架，而是把设备运维和工作流接入往后端服务方向推进。

README 中还区分了几类云端设备：用户自己的硬件、托管云手机、托管实体手机。这里的差别不只是成本，也涉及应用风控、身份可信度和任务稳定性。对电商、社交、金融或本地生活类 App 来说，真实设备和虚拟设备的表现可能完全不同。

为什么 LLM 无关很关键

移动 GUI agent 还处在快速变化阶段，很难说哪一家模型长期最好。不同任务对模型的要求也不一样：有的更依赖视觉理解，有的更依赖长链路规划，有的更看重工具调用，有的则需要低成本批量执行。

Mobilerun 选择模型无关的框架路线，价值在于把设备控制、任务执行、日志追踪和模型选择拆开。开发者可以先稳定设备侧流程，再根据任务成本、准确率和延迟切换模型。

这对实际落地很有帮助。企业不会只因为一个模型演示效果好就重写设备控制层；更合理的方式是保留统一执行框架，把模型当成可替换组件。

适合哪些场景

Mobilerun 当前适合几类需求：

• 移动 App QA 和回归测试。
• 从原生 App 中抽取数据并返回结构化结果。
• 自动执行重复性的手机任务。
• 为非技术用户封装自然语言移动操作流程。
• 在多台设备上运行自动化任务。
• 把日程、通知或自定义触发器接入移动端工作流。

不过，它也不是“安装后立刻替你管手机”的消费级助手。Android 侧需要 ADB、开发者选项、USB 调试和 Portal app；iOS 侧也有自己的接入流程。真正跑稳定，还要处理模型配置、设备状态、权限弹窗和任务失败恢复。

mobile-use

mobile-use 来自 minitap-ai，目标是让 AI agent 使用真实 Android 和 iOS App。它支持自然语言控制、UI-aware automation、数据抽取、不同 LLM 配置，并强调 AndroidWorld 基准表现。README 中还提到项目是首个在 AndroidWorld benchmark 上达到 100% 的 agentic framework。

它的亮点是任务分解和结构化抽取。比如从 Gmail 中找未读邮件，并按指定 JSON 格式返回发件人和主题，这类任务比“打开设置看看电量”更接近真实生产需求。它把移动 GUI agent 从“会操作”推进到“能把 App 里的信息整理出来”。

它的限制主要在设备支持和运行环境。Android 可以用实体手机或模拟器；iOS 目前主要支持 macOS 上的模拟器，物理 iOS 设备还不支持。Docker 快速启动也主要面向 Android。评估它时，要先确认目标设备和 App 场景能否被当前执行通道覆盖。

它和普通手机自动化有什么不同

传统手机自动化通常依赖脚本、坐标、控件 ID 或固定流程。它适合稳定页面，但遇到界面变化、弹窗、搜索结果、列表滚动和跨 App 操作时，很容易失效。

mobile-use 的路线是让 AI agent 直接处理自然语言目标和 UI 状态：

• 用户用自然语言描述任务，不必预先写死每一步。
• 框架读取移动端界面，并结合模型判断下一步操作。
• 可以从 App 中抽取信息，并按指定格式返回，比如 JSON。
• 支持不同 LLM 配置，包括 OpenAI API compatible providers。
• Android 可以通过实体手机或模拟器运行，iOS 目前主要面向 macOS 上的模拟器。

这类框架更适合“半结构化”的移动任务：目标明确，但每次页面状态、数据内容和路径不完全一样。

AndroidWorld 结果值得注意

mobile-use README 中提到，项目在 AndroidWorld benchmark 上达到 100% 完成表现，并链接了对应论文。无论具体评测细节如何，这都说明项目团队把“任务分解”和“可评测执行”放在了很高的位置。

这点比单纯演示更关键。GUI agent 最容易出现的问题是：一个视频里看起来很聪明，但换一个任务、设备或初始状态就不稳定。基准测试不能完全代表真实使用，却能逼迫系统面对一组标准化任务，并暴露规划、定位、恢复和状态理解能力。

README 中的论文题目也点出了方向：通过任务分解提升 AndroidWorld 准确率。对移动端智能体来说，复杂任务往往不能靠一个大提示词直接完成，而需要拆成可执行子任务，并在每一步检查状态。

数据抽取是实用入口

mobile-use 的一个现实场景是从原生 App 中抽取数据。很多信息并不暴露在 API 中，只能在 App 界面里查看，比如邮件列表、订单状态、社交内容、运营后台、消息通知等。

README 给出的示例是打开 Gmail，找到未读邮件，并把发件人和主题整理成 JSON。这个方向很实用，因为它把移动 GUI agent 从“帮我操作一下”推进到“帮我把 App 里的信息结构化拿出来”。

不过，这也带来边界问题。数据抽取涉及账号、隐私、平台条款和访问权限。真正使用时，应该明确设备归属、任务授权、数据保存方式和输出范围，不能把手机界面当成无限制的数据源。

部署门槛和限制

mobile-use 支持从平台快速开始，也支持从源码运行。源码方式需要配置 .env、LLM 配置和依赖环境；Android 侧可以使用实体手机或模拟器，Docker 快速启动目前主要面向 Android；iOS 侧需要 macOS、Xcode 和 Facebook 的 iOS Development Bridge，README 也说明物理 iOS 设备暂不支持。

这些限制并不意外。移动端自动化比浏览器自动化更依赖设备、系统权限和调试通道。尤其是 iOS，系统封闭性更强，能稳定接入模拟器已经有价值，但离“任意真实 iPhone 自动化”还有距离。

因此，评估 mobile-use 时不要只看模型效果，还要看自己的目标设备、App 类型、运行环境和合规边界是否匹配。

适合谁关注

mobile-use 适合几类人关注：

• 想研究 AndroidWorld、移动 GUI agent 和任务分解方法的研究者。
• 想把自然语言移动操作接入内部工具的开发者。
• 需要从原生 App 抽取结构化数据的团队。
• 做移动 App QA、回归测试或探索式测试的人。
• 想比较 mobile-use、Mobilerun、Mobile-Agent 等不同移动端智能体路线的人。

如果目标是一个面向普通用户的手机助手，它目前还偏工程和研究框架；如果目标是验证移动端 agent 的可行性，它提供了一个很好的开源起点。

功能对比

优缺点对比

MobiAgent 的优点是系统完整，适合研究手机 GUI agent 的模型、记忆、加速和评测闭环；缺点是部署链路长，工程配置重，普通开发者上手成本较高。

Mobile-Agent 的优点是技术路线最宽，能看到 GUI agent 从手机走向桌面、浏览器、工具调用和基础模型的演进；缺点是项目族复杂，想直接落地某个具体场景时，需要先做较多筛选。

Mobilerun 的优点是工程接口清晰，模型无关，本地框架和云服务分层明确，适合把移动设备自动化接入产品或内部工具；缺点是仍然要面对移动设备权限、环境、App 状态和云端成本问题。

mobile-use 的优点是聚焦真实 App 使用、任务分解和结构化数据抽取，AndroidWorld 方向也让它更容易评估；缺点是 iOS 物理设备支持有限，完整使用仍然需要配置模型、设备和运行环境。

适用范围建议

如果你要做移动智能体研究，优先看 MobiAgent 和 Mobile-Agent。前者更聚焦手机端系统闭环，后者更适合观察 GUI agent 的跨平台演进。

如果你要做移动 App 自动化、QA、数据抽取或内部工作流，优先看 Mobilerun 和 mobile-use。Mobilerun 更像可接入工程系统的运行框架，mobile-use 更适合验证自然语言 App 操作和结构化抽取。

如果你关注未来个人助手形态，四个都值得跟踪。MobiAgent 代表手机 agent 的系统化研究，Mobile-Agent 代表跨平台 GUI agent 路线，Mobilerun 代表设备控制基础设施，mobile-use 代表真实 App 任务分解和评测驱动路线。

我的判断

这四个项目的差异说明，移动端 GUI agent 已经不只是“让模型看截图点按钮”。真正的问题变成了：模型如何理解界面，执行器如何稳定控制设备，任务如何拆解和评估，云端设备如何管理，结果如何结构化返回，风险如何被限制。

短期内，最现实的落地场景会是 QA、数据抽取、内部流程自动化和受控设备池。长期看，谁能把设备控制、模型能力、权限边界、日志追踪和用户确认机制做稳，谁就更接近真正可用的移动端 AI 助手。