你的手机以后可以自己动了：实测 4 种 AI 控制方案

• 先说结论
• 一、ADB：最底层、最可控的方案
• 二、uiautomator2：Python 圈的自动化神器
• 三、多模态 Mobile Agent：最接近"自动驾驶"的路
  • AppAgent（2023.12）— 多模态 Agent 开创性工作
• 四、最成熟可用的开源方案：mobilerun
• 五、新路线：MCP + Android AppFunctions
  • Android AppFunctions：OS 级别的 MCP
  • 社区 MCP Server 生态
  • 与 DMA 的关系
  • 这条路的局限性
• 六、实际踩坑：为什么你的 AI 手机控制总是翻车
  • 1. 截图质量决定一切
  • 2. 界面动态内容让 LLM 困惑
  • 3. 隐私数据脱敏
  • 4. 国产定制系统的兼容性问题
• 七、我的判断
• 参考文献

本文首发地址 https://h89.cn/archives/580.html

上周我把公司项目跑在 AI 手机控制上，结果有点意外——不是惊喜，是意外。

说白了，现在 AI 控制手机这事，概念很火，但真刀真枪跑起来，要么是玩具，要么是半成品。本文把目前所有主流技术路线摸了一遍，从 ADB 脚本到 Android 原生 MCP，逐一说清楚谁能用、谁好用、谁在吹牛。

先说结论

目前 AI 控制安卓手机有五条路：

没有银弹。不同场景选不同方案，下面详细说。

一、ADB：最底层、最可控的方案

ADB（Android Debug Bridge）是 Google 官方提供的调试工具，所有其他方案的底层都离不开它。

它能做什么：

• adb shell input tap x y — 模拟点击坐标
• adb shell input swipe x1 y1 x2 y2 — 模拟滑动
• adb shell input text "hello" — 输入文本
• adb shell screencap — 截图
• adb shell uiautomator dump — 导出当前界面 XML

典型工作流程：

用户指令 → LLM 解析意图 → 生成 ADB 命令序列 → 执行 → 截图验证 → 循环

核心问题： ADB 本身不"懂"界面。你告诉它"点微信"，它不知道微信在哪，得靠坐标或者额外的图像识别来定位元素。

推荐项目：

Appium — 业界最成熟的移动端自动化框架，底层通过 ADB 操作 UiAutomator，支持多语言客户端。适合需要长期维护测试用例的团队。

二、uiautomator2：Python 圈的自动化神器

uiautomator2 是国内团队维护的 Python 库，封装了 Google 的 UiAutomator2，比 Appium 更轻量。

import uiautomator2 as u2

d = u2.connect()
d(text="微信").click()           # 通过文本定位元素
d(resourceId="com.tencent.mm:id/abc").click()  # 通过资源ID
d.screenshot("screen.png")        # 截图

优点：

• Python 上手，生态丰富
• 可以配合 OpenCV / YOLO 做视觉定位
• 社区活跃，中文文档齐全

缺点：

• 元素定位依赖 XML 层级，界面一改就挂
• 需要真机或模拟器，不能云端运行

进阶玩法： 用 YOLO 或 SAM（Segment Anything）识别 UI 元素，配合 uiautomator2 执行动作。这种"视觉+自动化"的组合是目前国内 AI 手机控制最常见的技术选型。

三、多模态 Mobile Agent：最接近"自动驾驶"的路

这是 2024 年最火的研究方向。核心思路是：给 LLM 截一张手机截图，让它自己理解界面、规划动作、执行任务。

AppAgent（2023.12）— 多模态 Agent 开创性工作

AppAgent 是这个领域的开创性工作，来自南洋理工大学团队，发表在 arXiv:2312.13771，GitHub 仓库已下线，但论文仍有参考价值。

原理：

1. 截图 → Base64 编码 → 发送给 GPT-4V（或同类多模态模型）
2. 模型输出动作（点击、滑动、输入等）
3. 通过 ADB 执行动作
4. 循环直到任务完成

论文验证过的任务：

• 打开并操作任意 App
• 图片编辑（调整亮度、滤镜）
• 发送邮件
• 地图导航

局限： 每个动作都要调用 LLM，成本高；复杂任务容易走偏。

这些论文目前更多是研究验证，离产品化还有距离。实际落地的主要是 AppAgent 的思路——截图喂给视觉 LLM，执行 ADB 动作。

四、最成熟可用的开源方案：mobilerun

droidrun/mobilerun 是目前 GitHub 上最活跃的移动端 AI 控制框架，v0.6.12，MIT 许可证，持续活跃更新。

确认支持的功能：

• Android + iOS 双平台
• 多 LLM：OpenAI、Anthropic、Gemini、Ollama、DeepSeek 任选
• 截图视觉理解 + 自然语言指令
• CLI 三步上手 + Python API 扩展
• 支持复杂多步任务规划
• 云端设备控制 + OAuth 2.0 登录
• 有独立 benchmark

pip install mobilerun
mobilerun setup            # 安装 portal 到手机
mobilerun configure        # 配置 LLM provider
mobilerun login            # OAuth 登录（云端设备）
mobilerun run "打开微信，给朋友发消息说hello"

自 4 月本文初版以来，mobilerun 从 v0.3.x 快速迭代到 v0.6.x，新增了云端设备控制、OAuth 登录体系、iOS 视觉坐标 unmask、多驱动重构等能力。社区活跃度持续增长。

如果你想快速体验 AI 控制手机，这是目前最推荐的起点。

五、新路线：MCP + Android AppFunctions

2026 年 Q2 最大的变化：MCP（Model Context Protocol）进入手机控制领域。Google 在 I/O 2026 上正式发布了 Android AppFunctions，加上社区涌现的一批移动端 MCP Server，形成了全新的技术路线。

Android AppFunctions：OS 级别的 MCP

AppFunctions 是 Android 官方提供的平台 API + Jetpack 库，让 App 通过注解暴露功能给 AI Agent。本质上它是 Android 内置的 MCP 协议实现。

@AppFunction(isDescribedByKDoc = true)
suspend fun createTask(
    title: String,
    dueDateTime: LocalDateTime? = null,
): Task = TODO()

关键特性：

• 无需 ADB、无需截图，直接调用 App 内部功能
• Kotlin 注解声明，编译期自动生成 XML schema
• 本地执行，无网络延迟
• Android 16+ 原生支持，EXECUTE_APP_FUNCTIONS 权限管控

当前状态： EAP（Early Access Program）阶段，仅限受邀开发者。Gemini 集成尚在 private preview。

社区 MCP Server 生态

除了 Google 官方方案，社区也快速跟进：

与 DMA 的关系

2026 年 7 月，欧盟 DMA 裁决要求 Google 在 Android 18（2027 年 8 月前）向第三方 AI 助手开放摄像头、麦克风、屏幕、通知等 11 项 Gemini 独占能力。这意味着未来第三方 AI Agent 可以直接调用手机底层能力，无需 ADB 代理。

这条路的局限性

• AppFunctions 仅 Android 16+，生态碎片化问题严重
• 国产 ROM（华为、小米等）大概率不会跟进 Google 的 MCP 标准
• EAP 阶段，普通开发者暂时用不上

六、实际踩坑：为什么你的 AI 手机控制总是翻车

1. 截图质量决定一切

国内 App 大量使用自定义控件，UiAutomator 的 XML dump 经常拿不到正确的元素信息。这时候只能靠截图 + 视觉识别，但低分辨率截图会导致模型误判。

建议： 截图用 adb shell screencap -p 输出原始 RGB，不要压缩。

2. 界面动态内容让 LLM 困惑

通知栏、广告弹窗、实时聊天界面——这些变化剧烈的界面会让 Agent 陷入循环。

建议： 动作执行前先做页面稳定性检测，界面剧烈变化时等待或重试。

3. 隐私数据脱敏

如果要长期运行自动化流程，相册、聊天记录、密码等隐私数据的处理是个坑。截图会带着这些信息上传给 LLM，要有意识地做区域遮挡。

4. 国产定制系统的兼容性问题

华为、小米、OPPO 的定制系统对后台进程有不同的管控策略。uiautomator2 在某些机型上需要额外权限配置。

七、我的判断

短期内（1-2年）最实用的方案：

视觉 LLM + ADB + 规则护栏

用视觉 LLM 理解界面，用 ADB 执行动作，用规则引擎兜底防止失控。这套组合适合有技术能力的团队做垂直场景自动化，比如：自动发布内容、自动测试 App、自动填表。

MCP 路线是中长期方向，值得押注。 Android AppFunctions + DMA 强制开放，意味着 Google 自己在从 OS 层面解决"AI 控制手机"的问题。如果 Android 18 按计划落地，2027 年后第三方 AI 助手可原生调用系统能力，届时 ADB 方案会被逐步替代。

纯 AI Agent 方案（Mobile Agent 类）目前还不够可靠，主要问题是幻觉导致的错误动作累积。但它是未来的方向，值得持续关注。

最不推荐： 直接买所谓"AI 手机助手"的商业产品。除非它能接入 AppFunctions 或 Android 18 的原生 AI 能力，否则大多是把 GPT-4V API 包装了一下，性价比极低。

参考文献

• AppAgent: Multimodal Agents as Smartphone Users — https://arxiv.org/abs/2312.13771
• mobilerun GitHub — https://github.com/droidrun/mobilerun
• uiautomator2 GitHub — https://github.com/openatx/uiautomator2
• Appium Official — https://github.com/appium/appium
• Android AppFunctions 官方文档 — https://developer.android.com/ai/appfunctions
• Mobile Next — https://mobilenext.ai/docs
• Maestro MCP — https://github.com/mobile-dev-inc/Maestro
• Appium MCP — https://github.com/appium/appium-mcp