编程 Mobile-Agent-v3.5 解读：让 AI 通过 ADB 直接操作 Android 手机

2026-09-05 16:08:31

Mobile-Agent-v3.5 解读：让 AI 通过 ADB 直接操作 Android 手机

让 AI 直接操作手机，这件事正在从 Demo 走向可用。阿里 X-PLUG 团队开源的 Mobile-Agent-v3.5（其中的 mobile_use 模块）就是一个典型代表：它通过 ADB（Android Debug Bridge）截取手机屏幕，并执行点击、滑动、长按、输入和打开应用等操作，把自然语言任务转换成手机上的连续动作。

项目地址：https://github.com/X-PLUG/MobileAgent

说明：Mobile-Agent-v3.5 也支持电脑和浏览器操作，本文聚焦于 Android 手机部分。

一、它是什么

mobile_use 的主要功能是让用户通过语言操作手机。例如，可以直接说：

"帮我在小红书、抖音看一下'魔搭 ModelScope 社区'账号"
"帮我打开设置并开启深色模式"

收到指令后，系统会持续观察当前屏幕，选择下一步操作，并根据界面变化继续执行，直到任务完成或需要用户介入。

目标模型是 GUI-Owl-1.5。 项目的视觉上下文和动作输出格式主要围绕该模型设计；同时，模型调用层采用 OpenAI 兼容的 Chat Completions 接口，因此也可以接入其他支持多模态输入的模型——前提是模型能够理解手机截图，并稳定输出项目约定的动作格式。

二、第一次跑通需要准备什么

1. 准备 Android 设备

当前代码只支持 Android。设备需要开启开发者选项和 USB 调试；部分系统（如 MIUI、ColorOS）还要求额外开启"USB 调试（安全设置）"，否则点击和输入可能不生效。

安装 Android Platform Tools 后，先确认电脑能识别设备：

/path/to/adb devices

多台设备同时连接时，需要在启动参数中增加 --device，明确指定设备序列号。

文本输入依赖 ADB Keyboard。脚本会在输入时临时启用该输入法，发送文本后再关闭它——因此输入过程中手机输入法会短暂切换，这是正常现象。

2. 安装 Python 依赖

目标目录没有独立的 requirements.txt 或版本锁定文件。仓库 README 列出了 qwen_agent、qwen_vl_utils 和 numpy，当前源码还直接导入 OpenAI Python SDK 与 Pillow。建议在虚拟环境中安装：

pip install qwen_agent qwen_vl_utils numpy openai Pillow

qwen_agent 在当前这条执行路径中没有被直接导入，但保留它与仓库说明一致。

3. 准备模型服务

执行器通过 OpenAI 兼容的 Chat Completions 接口调用模型。服务不仅要支持图片输入，还需要让模型按约定输出 XML 包裹的动作 JSON。GUI-Owl 1.5 是这套 Prompt 和动作协议的目标模型。

启动命令如下：

cd Mobile-Agent-v3.5/mobile_use

python run_gui_owl_1_5_for_mobile.py \
  --adb_path "/path/to/adb" \
  --api_key "YOUR_API_KEY" \
  --base_url "http://YOUR_VLLM_HOST:8000/v1" \
  --model "YOUR_MODEL_NAME" \
  --instruction "打开系统设置并开启深色模式" \
  --add_info ""

如果任务可能触发"打开应用"，还要留意辅助模型配置。应用解析器默认使用 qwen-plus，但 API 地址和密钥默认继承主模型。如果该地址只部署了 GUI-Owl，需要通过 --app_resolver_model 指定实际存在的模型，或者单独提供解析器的 API 地址和密钥。

4. 运行前的两个注意事项

工作目录：运行后，当前目录会出现两个以任务指令命名的文件夹，分别保存原始截图和标注截图。再次使用相同指令时，脚本会先删除旧目录；目录名又几乎直接来自用户指令，因此更适合在专用工作目录中运行。
API 密钥安全：密钥通过命令行参数传入，可能出现在 Shell 历史和进程列表中。正式部署前应改为环境变量或密钥管理服务。

三、核心架构：围绕截图循环执行

mobile_use 的核心是一个由 max_steps 控制的循环。它不会预先生成完整操作计划，而是每次只根据当前屏幕决定下一步：

截取屏幕：通过 ADB 获取手机当前截图。
组装上下文：将任务指令、当前截图、最近 4 个历史截图及模型输出发送给多模态模型；更早的操作压缩为文字记录。
生成动作：模型返回点击、滑动、输入、打开应用、等待或结束任务等动作，以及需要使用的坐标和参数。
执行动作：程序把 0～1000 的相对坐标换算到手机屏幕，通过 ADB 完成实际操作；打开应用时会结合内置包名表解析应用名称。
观察结果：程序保存本轮截图和动作，等待界面变化，然后重新截图并进入下一轮。

下一张截图既是新输入，也是对上一步操作结果的验证。如果模型返回 terminate 或 answer，循环结束；返回 interact 时，程序暂停等待用户处理。默认最多执行 50 步，任务规划、错误恢复和完成判断主要由模型根据连续截图完成。

四、经典流程：开启深色模式如何穿过整个系统

以"打开系统设置并开启深色模式"为代表任务，可以完整观察 mobile_use 的工作方式。

1. 任务从一条指令开始

脚本将补充信息附加到原始指令，按指令生成轨迹目录，并初始化内存中的历史列表。这一阶段不会主动验证 ADB 连接、模型服务或输入法状态——使用者需要提前通过 adb devices 和模型接口测试排除环境问题。

2. 第一张截图建立当前状态

执行器调用 ADB 的 screencap 获取屏幕。如果目标文件没有生成，会短暂等待后重试，最多尝试 3 次。

截图成功后，系统不会提取文字、控件树或应用状态。GUI-Owl 获得的是完整屏幕图像，因此弹窗、页面跳转和视觉布局都由模型自行理解。

3. 模型选择"打开设置"或点击入口

上下文构造器把当前截图、任务和工具协议发给 GUI-Owl。首轮没有历史动作，模型可能返回 open 打开 Settings，也可能直接点击桌面上的设置图标。

如果返回 open，应用路由先查包名表，再根据已安装应用调用解析器。找不到候选时，脚本不会自动安装应用，而是暂停并要求用户处理。

这里体现了系统的分工：模型决定"应该进入设置"，代码负责把自然语言中的应用名称转换为设备可执行的包名。

4. 动作落到真实设备

点击、滑动等动作使用 0～1000 的相对坐标。代码将坐标换算后发送给 ADB；文本输入则通过 ADB Keyboard 广播完成。

动作协议只限制可用动作类型，没有针对账户、支付、删除数据等敏感操作设置程序级确认。interact 可以暂停并请求用户介入，但它是模型可以选择的动作，不是强制权限门。

因此，这套执行器不是沙箱。 它获得的是连接设备上的 ADB 操作能力，测试时应使用专用设备或隔离账号，避免在主力机上执行可能修改数据的任务。

5. 下一帧截图承担反馈与验证

动作执行后，系统记录模型输出，在动作前的截图上标记点击位置或滑动方向，等待两秒，再进入下一轮截图。

新截图既是环境反馈，也是唯一的结果验证来源。如果上一轮没有成功打开设置，GUI-Owl 可以从画面发现状态未变化，改用返回、再次点击或等待等动作恢复。

这种反馈机制简洁，但没有独立验证器。模型既负责执行，也负责判断自己的操作是否奏效；一旦视觉判断连续出错，程序层没有额外规则纠正它。

6. 历史逐步压缩，直到模型宣布结束

最近 4 个历史回合会以完整截图和模型回复保留。超过窗口的旧回合只留下动作描述，例如"打开设置""点击显示选项"。

当模型在截图中确认深色模式已经开启时，它返回 terminate 和成功状态，主循环结束。如果始终无法完成，循环最多执行 50 步，之后同样打印执行结束，但不会生成一个明确区分"成功、失败、步数耗尽"的结构化结果。

模型接口失败有重试机制，截图也有有限重试；动作 JSON 解析失败、图像处理异常等路径则可能直接终止程序。目标目录没有自动化测试覆盖这些边界。

五、与传统手机自动化方案的区别

维度	Appium / Auto.js 等传统方案	Mobile-Agent-v3.5
定位方式	控件 ID / XPath / 坐标	纯视觉截图，模型理解界面
脚本编写	需要为每个页面写操作逻辑	自然语言描述任务，模型自行决策
适用场景	回归测试、固定流程	开放式任务、跨应用操作
稳定性	高（确定性流程）	依赖模型视觉理解能力
可维护性	页面改版需改脚本	理论上无需改脚本，但模型可能误判

简单说，传统方案是"写死流程"，Mobile-Agent-v3.5 是"让模型看屏幕自己决定下一步"。两者不是替代关系，而是适用于不同场景。

六、价值与局限

价值：mobile_use 把 GUI-Owl 的原生界面理解能力接到了真实 Android 设备上。截图、视觉历史、文本动作协议和 ADB 构成了一个足够短的闭环，开发者可以很快理解每一步发生了什么，也容易替换模型服务或设备控制方式。

局限：

项目效果与模型的界面理解、坐标定位和动作生成能力高度相关。接入非 GUI-Owl 多模态模型时，响应较慢、操作出错的概率明显上升；现阶段要获得稳定体验，优先使用 GUI-Owl-1.5。
从代码范围看，mobile_use 更像是用于展示 GUI-Owl 能力的配套项目。它没有引入独立的任务规划、结果验证、风险控制等常见 Agent 模块。
它的工作逻辑很像人使用手机：先看当前屏幕，再决定下一步做什么。区别在于，"看"由模型识别截图完成，"操作"由 ADB 执行。面对模型没有见过的界面、交互方式或任务组合时，理解和操作的失败率会明显上升。

若要用于商业场景，还需要补充：任务拆解、操作校验、异常恢复、敏感动作确认、状态持久化和运行审计等能力。

七、适合谁

想探索"AI 操作手机"的开发者和研究者
需要做开放式、跨应用手机自动化的团队（如 UI 自动化测试、辅助操作）
对 GUI-Agent 视觉闭环感兴趣、想快速跑通一个可观察的最小实现的人

如果对这个项目感兴趣，可以借助 AI Coding 工具进一步阅读源码、梳理调用链，并在测试设备上实际运行，验证不同模型和任务下的表现。

项目地址：https://github.com/X-PLUG/MobileAgent