开源手机 Agent 框架推荐：Open-AutoGLM、Mobilerun 与 Minitap mobile-use 怎么选

先按任务选择框架

选择开源手机 Agent 框架，先看你要解决的是研究、自动化开发，还是日常手机任务。如果目标是研究视觉手机 Agent、ADB 控制和模型服务之间的关系，Open-AutoGLM 更适合先看；如果你想用 CLI 或 Python 写可追踪的移动端自动化流程，Mobilerun Framework 更直接；如果你要用自然语言描述结构化移动任务，并关注 Android 设备、模拟器和可抽取结果，Minitap mobile-use 值得评估。

这里比较的是三个框架，Mobilerun 的本地 Framework 与 Cloud 是其中同一项目的不同部署路线，不是额外一款框架。任务适配度之外，还要看你能否承担设备选择、权限维护、配置迁移和失败检查，而不只是能否跑通一条演示命令。

比较设备、执行、模型和许可证

三个项目都把“手机 Agent”拆成几层：框架运行时负责组织任务，模型负责理解和规划，手机执行层负责点击、输入、观察和回传结果。不要把这几层混成一个能力承诺。仓库开源，不代表模型调用免费、云手机免费、推理全在本地，也不代表所有应用都能稳定完成任务。

许可证应核对你实际采用的代码版本；仓库许可不会自动覆盖模型权重、数据、依赖、设备和托管服务条款。如果核心问题是模型怎么选，可以先看AI 智能体模型推荐：按手机任务选择工具调用模型与 GUI 模型；如果核心问题是执行是否可靠，则要回到设备与任务本身。

什么时候选 Open-AutoGLM

Open-AutoGLM 官方仓库适合需要理解“视觉模型、手机屏幕、ADB 动作和人工确认”如何组合的团队。它的 Android 路线涉及开发者模式、USB 调试、ADB Keyboard 等准备；框架可以使用托管模型服务，也可以连接自建推理服务，因此本地 GPU 不是托管 API 路线的前提。

它的优势是把手机 GUI Agent 的关键环节摆得比较清楚：屏幕观察、动作生成、设备执行、敏感操作确认，以及登录或验证码场景下的人类接管。适合研究、评估和构建自己的执行链路。边界也要讲清：Apache-2.0 是仓库许可证，不自动覆盖模型、数据、设备、依赖和服务条款；官方说明里的能力也不是任意应用的成功保证。

什么时候选 Mobilerun Framework 或 Cloud

Mobilerun 官方仓库适合想用命令行或 Python 组织移动端任务的开发者。它提供移动控制、无障碍树、截图、模型提供商选择和结构化结果；Android 准备包括 ADB、开发者/USB 调试以及 Portal 辅助服务。它还保留了从 DroidRun 更名而来的线索，但选择时应以当前 Mobilerun 仓库为准。

要特别区分 Mobilerun Framework 和 Mobilerun Cloud。Framework 是在你的机器上运行 Agent，并不证明模型推理也在本机；Cloud 则面向连接本地手机、托管虚拟或物理手机、API 工作流等托管场景，运维依赖、成本和数据路径都不同。Mobilerun 记录了 Arize Phoenix、Langfuse 和轨迹保存，适合需要检查失败原因、回看执行过程和比较不同模型行为的团队。

Mobilerun 10 月设备选择与执行变更发布于 2026 年 10 月 14 日 UTC，对应中国时间 10 月 15 日。运行时依次采用显式 -d、环境变量 ANDROID_SERIAL，最后才是唯一在线设备。多台设备连接却未指定目标时，现在会报错停止，不再自动选择设备列表中的第一台。启动前应查看连接列表，把序列号与手里的测试机对应起来，再明确选择目标；旧脚本若依赖“第一台设备”，需要修改。

同次更新还改变了 FastAgent 的调用处理：只执行回复中的第一个 function_calls 块，后续块被忽略；其中一次调用失败后，该块剩余调用会跳过。这不等于已经撤销前面的成功动作。遇到失败，应先停下核对设备实际状态，修复原因后再决定从哪里继续，不能把整段盲目重跑当作恢复方案。

配置迁移则要看Mobilerun 10 月 5 日应用卡片目录变更：当前读取 app_cards_dir/android/app_cards.json 与 app_cards_dir/ios/app_cards.json。直接放在 app_cards_dir 下的旧平铺文件会被忽略。升级时把卡片迁到正确平台目录，并核对 Android 应用标识与 iOS bundle ID，不要混用。设置流程会采用与框架匹配的 Portal，并保留已安装的更新版本，不必自行猜测兼容版本号。

Portal 在运行中可以恢复被关闭的无障碍服务和 Portal 键盘。因此，若你打算撤销授权，应先停止 Agent，再在设备上核对服务、输入法和权限确实处于预期状态；不能只关一次开关就假定运行已结束。不要通过关闭 Play Protect 或绕过安全机制解决问题。Cloud SDK 的 UI 树兼容性，以及点击、输入不再重试的行为变化，也应纳入升级检查，它们不是所有设备都能成功的保证。

什么时候选 Minitap mobile-use

Minitap mobile-use 官方仓库更适合希望用自然语言描述移动 UI 任务，并拿到结构化抽取结果的场景。它支持配置 LLM 提供商，Android 真机和模拟器通过 ADB 连接，Docker 快速开始也明确面向 Android。对想构建“打开应用、读取界面、完成可回退任务、抽取结果”的团队，这条路线可以减少从头编写设备控制层的工作。

iOS 支持要按项目设置说明看，不要被泛化表述带偏。mobile-use 的 README 在手动设备部分列出 macOS 上的 iOS 模拟器，同时明确说明物理 iOS 设备尚不支持。它也提示游戏等缺少无障碍树信息的场景会受限。因此，采用前要把目标设备、目标应用、无障碍树可见性和模型服务一起验证。

用可回退任务检查失败点

评估开源手机 Agent 框架时，不要从付款、删除、发消息开始。一个基于官方说明的起步方案，是在自己拥有并获准使用的测试手机上，只打开预先选定的无敏感内容应用，确认其首页显示正确后停止。三套框架尽量采用同一目标设备、同一任务描述和可比较的模型条件；不兼容的配置应单独记录，不能硬凑成统一成绩。

1. 查看连接设备列表，确认测试机身份和在线状态；Mobilerun 明确指定目标，不依赖列表顺序。
2. 核对模型端点、提供商、密钥及费用条件，区分本机框架与远程推理。
3. 检查截图、无障碍树、输入法和实际授权；使用 Mobilerun 时，额外确认平台应用卡片已被读取。
4. 发出仅打开目标应用的请求，观察任务是否落到正确手机，以及最终可见页面是否符合要求。
5. 出现错误设备、调用失败或意外页面时立即停止，记录最后成功步骤，不继续使用旧观察。
6. 修复原因后先核对现状，再决定恢复或重新开始；测试结束后停止进程，检查权限与辅助服务状态。

基础任务通过后，才在隔离的测试环境中加入页面变化、设备断连或权限撤销等故障条件。特别是 Mobilerun 运行中可能恢复 Portal 服务，撤权检查必须连同停止 Agent 和复查设备状态一起进行。可回退任务也不意味着框架提供事务或自动回滚。

这只是评估计划，不是我们替你跑出的结论。想把任务设计、记录表和风险恢复做得更系统，可以继续读安卓手机 Agent 基准测试指南：2026 年怎样评估可靠性、安全和恢复。是否完成任务，应由目标应用中的真实状态与可定位的执行记录共同判断，而不是只看模型说“完成”。

不想部署框架时的 Android 路线

如果你的目标不是开发框架，而是让 Android 手机完成日常受支持任务，FoneClaw 是另一条路线。我们提供的是面向 Android 用户的现成手机 Agent，不是开源手机 Agent 框架，也不代表与上述三个项目存在原生集成。

这条路线适合不想维护 ADB、云设备、推理服务、追踪系统和执行器的人。配置模型负责理解与规划，已启用工具在实际 Android 权限及工具审批策略下执行受支持动作。手机侧运行不等于全部推理都在本机，也不保证所有应用都能控制、所有动作都能无人值守完成，或每个动作都会再次弹出确认。

想先厘清自然语言请求如何变成可检查的手机动作，可以阅读AI 智能体控制 Android 手机：从自然语言意图到确认、执行和验证。当前产品能力可从FoneClaw 功能页面了解；讨论框架部署与现成产品的取舍，也可以联系我们。最终选择取决于你要掌握多少执行细节，以及愿意承担多少设备与运行环境维护工作。