移动端 on KnightLi的博客

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

Fri, 29 May 2026 21:47:24 +0800

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

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

基本信息对比

项目	站内文章	GitHub	主要定位	设备/平台	开源协议	更适合谁
MobiAgent	站内介绍	IPADS-SAI/MobiAgent	可定制手机 GUI 智能体系统，包含模型、runner、记忆、加速和评测	主要面向 Android/Harmony 手机	Apache-2.0	研究者、移动智能体实验团队
Mobile-Agent	站内介绍	X-PLUG/MobileAgent	通义实验室 GUI 智能体家族，覆盖移动端、桌面、浏览器和工具调用	手机、PC、网页、云手机/云桌面	MIT	关注 GUI agent 技术路线的人
Mobilerun	站内介绍	droidrun/mobilerun	LLM 无关的移动设备 agent 框架，支持 CLI、Python API 和云端设备工作流	Android、iOS、本地设备、云端设备	MIT	开发者、QA、自动化工作流团队
mobile-use	站内介绍	minitap-ai/mobile-use	用自然语言操作真实移动 App，强调任务分解、结构化抽取和 AndroidWorld	Android 实机/模拟器、iOS 模拟器	Apache-2.0	做移动 App agent、数据抽取和评测的人

MobiAgent

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

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

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

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 基础模型路线，而不是单个移动自动化项目。

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

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 当成工程组件接入的人。

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 场景能否被当前执行通道覆盖。

功能对比

功能维度	MobiAgent	Mobile-Agent	Mobilerun	mobile-use
自然语言任务	支持	支持	支持	支持
真实手机操作	强，偏 Android/Harmony	强，含移动端与云手机	强，Android/iOS	强，Android；iOS 偏模拟器
桌面/浏览器扩展	不是重点	强，含 PC-Agent、GUI-Owl、ToolCUA	不是主要定位	不是主要定位
模型层	自带 MobiMind 系列	GUI-Owl、Mobile-Agent 系列	LLM 无关，接多家模型	可配置多种 LLM
执行器/runner	强，含 ADB runner、多任务 runner	子项目各自提供	强，CLI/TUI/Python API/Docker	有源码、Docker 和平台入口
记忆能力	用户画像、经验、动作记忆	v3/v3.5 路线中强调记忆与反思	更偏轨迹、日志和工程调试	更偏任务分解与状态执行
评测	MobiFlow	多个论文/基准方向	有 benchmark 结果入口	AndroidWorld 表现突出
云端设备	不是主要卖点	支持云手机/云桌面体验	Mobilerun Cloud 是重点	有平台入口
结构化输出	可通过工程流程实现	视子项目而定	明确支持	明确支持

优缺点对比

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 助手。

mobile-use 看点：让 AI 操作真实 App，还能提取数据

Fri, 29 May 2026 21:43:46 +0800

mobile-use 是 minitap-ai 开源的移动端 AI agent 框架，目标是让智能体像人一样使用真实 Android 和 iOS App。用户用自然语言描述任务，框架负责理解界面、操作 App，并把结果返回给调用方。

从 README 看，mobile-use 的重点不只是“能点手机”，还强调 UI-aware automation、数据抽取、可配置模型，以及在 AndroidWorld 基准上的表现。项目还提供云平台、文档和论文入口，说明它既是开源框架，也是一个围绕移动端智能体搭建的产品与研究体系。

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

传统手机自动化通常依赖脚本、坐标、控件 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 的可行性，它提供了一个很好的开源起点。

我的判断

mobile-use 的亮点在于把真实 App 操作、结构化数据抽取和基准评测放在同一个项目里。它不是只做“自然语言点手机”的包装，而是在尝试把移动端任务拆解成可执行、可评估、可复现的智能体流程。

移动端会是 GUI agent 的重要战场，因为大量个人和业务任务发生在 App 里，而不是网页或 API 里。mobile-use 这类项目的意义，就是让智能体从聊天窗口走进真实应用界面。它还没有把设备、权限和风险问题全部抹平，但已经给开发者提供了一个足够具体的实验平台。

项目链接：minitap-ai/mobile-use

想让 AI 自动点手机？Mobilerun 支持 Android 和 iOS

Fri, 29 May 2026 21:43:45 +0800

Mobilerun 是 droidrun 开源的移动设备自动化框架，目标是让 LLM agent 可以用自然语言控制 Android 和 iOS 设备。它提供移动端原生工具，让智能体能够检查 UI 状态、理解截图、点击、滑动、输入、规划多步任务，并通过 CLI 或 Python API 返回结果。

这个项目的定位很清楚：它不绑定某一家模型，而是做移动设备与智能体之间的执行层。README 中列出的模型来源包括 OpenAI、Anthropic、Gemini、Ollama、DeepSeek、OpenRouter 以及 OpenAI-compatible providers。对开发者来说，这比“只支持一个模型的演示项目”更实用。

它解决什么问题

移动端自动化最麻烦的地方，是自然语言任务和真实设备操作之间隔着很多层。模型需要知道当前打开了什么 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 侧也有自己的接入流程。真正跑稳定，还要处理模型配置、设备状态、权限弹窗和任务失败恢复。

我的判断

Mobilerun 的价值在于把移动设备控制做成了可编程、可观测、可替换模型的 agent 框架。它承认移动自动化不是一个模型问题，而是模型、设备、执行器、日志、工具和云端基础设施共同组成的系统问题。

短期看，它适合开发者搭建移动端自动化原型和内部工具；长期看，这类框架可能会成为“手机上的 AI 工作流引擎”。如果 GUI agent 要进入真实业务，像 Mobilerun 这样把本地运行、云端设备、结构化输出和追踪能力放在一起的项目会越来越重要。

项目链接：droidrun/mobilerun

AI 能自己点手机、用电脑了吗？Mobile-Agent 项目解读

Fri, 29 May 2026 21:42:41 +0800

X-PLUG 开源的 Mobile-Agent 已经不只是一个手机自动化项目。按照仓库当前的定位，它更像是通义实验室围绕 GUI 智能体持续沉淀的一组工作：Mobile-Agent-v1/v2/v3/v3.5、Mobile-Agent-E、PC-Agent、GUI-Critic-R1、UI-S1、GUI-Owl 以及 ToolCUA 等，都被放在同一个项目体系里展示。

这条线索值得关注。过去谈 GUI agent，常见问题是“模型能不能看懂截图并点对位置”；而 Mobile-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 系统集成。

我的判断

Mobile-Agent 的价值不在于某一个版本的指标，而在于它把 GUI 智能体从“手机截图点按”推进到了一个更大的系统问题：模型、执行环境、评测、工具调用、错误诊断和跨平台任务如何协同。

短期看，它更适合研究者和开发者观察 GUI agent 的技术路线；长期看，这类项目可能会影响个人 AI 助手和企业自动化工具的形态。真正的难点不只是让智能体会操作界面，而是让它在真实应用里稳定、可控、可追踪地完成任务。

项目链接：X-PLUG/MobileAgent

MobiAgent 是什么？一个能操作手机 App 的开源 AI 智能体

Fri, 29 May 2026 21:36:58 +0800

IPADS-SAI 开源了 MobiAgent，定位是一个面向手机 GUI 的可定制智能体框架。它不是单一模型仓库，而是把模型、执行器、加速机制、评测基准和移动端应用放在同一个体系里，目标是让智能体能在真实手机环境中完成跨应用、多步骤任务。

从项目结构看，MobiAgent 主要由三部分组成：MobiMind 系列智能体模型、AgentRR 记录与回放加速框架，以及 MobiFlow 评测基准。论文摘要中也强调，现有移动智能体在真实任务里的准确率和效率仍然是主要瓶颈，MobiAgent 的设计就是围绕这两个问题展开。

它解决什么问题

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

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

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

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

记忆系统是关键补丁

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

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

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

适合谁关注

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

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

我的判断

MobiAgent 的意义不在于又发布了一个 GUI agent，而在于它把手机智能体从“看截图点按钮”的单点能力，推进到一个可训练、可执行、可评测、可加速的系统框架。

移动端是智能体很难绕开的场景。大量个人任务发生在 App 里，而不是标准化网页或 API 中。谁能稳定理解手机界面、跨应用执行任务、复用经验并控制隐私风险，谁就更接近真正可用的个人智能体。

MobiAgent 还没有把这些问题全部解决，但它提供了一个比较完整的开源起点。短期看，它适合用于移动智能体研究和实验；长期看，这类框架可能会成为手机操作系统、个人助理和自动化工具之间的重要连接层。

项目链接：IPADS-SAI/MobiAgent
论文链接：MobiAgent: A Systematic Framework for Customizable Mobile Agents

移动端 on KnightLi的博客

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

基本信息对比

MobiAgent

Mobile-Agent

Mobilerun

mobile-use

功能对比

优缺点对比

适用范围建议

我的判断

mobile-use 看点：让 AI 操作真实 App，还能提取数据

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

AndroidWorld 结果值得注意

数据抽取是实用入口

部署门槛和限制

适合谁关注

我的判断

想让 AI 自动点手机？Mobilerun 支持 Android 和 iOS

它解决什么问题

本地框架和云端服务

为什么 LLM 无关很关键

适合哪些场景

我的判断

AI 能自己点手机、用电脑了吗？Mobile-Agent 项目解读

它解决什么问题

v3.5 的重点

GUI-Owl 是底层变化

ToolCUA 暗示的新方向

适合谁关注

我的判断

MobiAgent 是什么？一个能操作手机 App 的开源 AI 智能体

它解决什么问题

最近更新值得关注

记忆系统是关键补丁

适合谁关注

我的判断