目录

一、基于 ADB 的成熟安卓自动化方式概览

二、传统（工程实践成熟）的自动化测试框架

Appium（主流首选，强依赖 ADB）

AndroidViewClient / Culebra（纯 Python + ADB，适合脚本党）

Airtest（图像识别 + ADB，适合游戏和 GUI 复杂场景）

Nico（基于 ADB 命令的跨平台自动化框架）

UiAutomator2 / Espresso / Selendroid / Playwright(Android Web)

三、面向 AI / Agent 的安卓自动化开源项目（含“会用手机的 AI”）

智谱 Open-AutoGLM / Phone Agent（强烈相关）

DroidRun（LLM 中立、Android+iOS 的智能 Agent）

Android-MCP（把 Android 变成 LLM 可用的“工具箱”）

AndroidViewClient 的 MCP 集成

其他相关 AI 自动化项目

四、如果你要“现在”落地，怎么选？

只做传统自动化测试（脚本为主）

想要“类似智谱 AutoGLM 的 AI 自动化手机能力”

渐进式升级路径（从 ADB 到 AI）

五、总结（直给）

References

以下均基于目前（2026-02）信息：

一、基于 ADB 的成熟安卓自动化方式概览

从实现路径上，大致可以分三类：

  1. 传统 UI 自动化框架：以 Appium、Espresso、UiAutomator2 等为代表，多数底层仍依赖 ADB 驱动设备

  2. 轻量/脚本化 ADB 封装框架：AndroidViewClient、Nico、Airtest 等，直接或间接封装 ADB 命令

  3. 面向 AI Agent / MCP 的新一代 ADB 网关：Android-MCP、AndroidViewClient MCP 版等，为 LLM/Agent 提供“会用手机”的能力

下面分层展开。

二、传统（工程实践成熟）的自动化测试框架

  1. Appium（主流首选，强依赖 ADB）

  • 定位：跨平台 UI 自动化框架，支持 Android / iOS / 桌面，基于 W3C WebDriver 协议。[1]

  • Android 底层：通过 UiAutomator2 驱动 Android 设备，本质上是在 ADB+UiAutomator2 基础上的一层服务。[2]

  • 特点：

    • 支持原生 / 混合 / WebView 应用测试

    • 客户端语言丰富：Java / Python / JS / C# 等

    • 生态完善：云真机平台、报告、CI 集成都有成熟方案

  • 典型适用场景：

    • 企业级 E2E 自动化回归

    • 需要同时支持 Android + iOS 的团队

  • 与 ADB 的关系：

    • ADB 不直接出现在脚本代码里，但设备连接、安装、日志、截图等都依赖 ADB 侧服务

  • 什么时候优先选 Appium：

    • 你是传统 QA 团队，希望“少折腾底层 ADB，多用现成生态”

    • 需要稳定的跨平台方案，AI 仅作为辅助，而非主角

  1. AndroidViewClient / Culebra（纯 Python + ADB，适合脚本党）

  • 定位：基于 ViewServer 和 ADB 的纯 Python UI 自动化库与工具，曾作为 monkeyrunner 的增强版发展而来。[3]

  • 主要能力：[3]

    • 通过 ADB 获取 View 层级，做“设备无关”的视图级交互

    • 自动导航、脚本录制与回放

    • 多设备并发控制

  • 新趋势：

    • 提供 MCP 服务器 模式，可让 LLM 通过自然语言操控 Android（“Launch the Calculator app”, “Tap button with text Submit” 这类指令）。

  • 适用场景：

    • Python 技术栈，期望直控 ADB、做一些自定义工具 / CI 脚本

    • 想给 LLM 接一个轻量的“手机控制工具箱”

  1. Airtest（图像识别 + ADB，适合游戏和 GUI 复杂场景）

  • 定位：网易开源的“跨平台 UI 自动化框架”，对游戏和图像驱动场景很友好。[4]

  • 关键特性：

    • 图像识别驱动：通过截图+模板匹配定位 UI 元素，不依赖控件树

    • Poco 组件：可以访问 UI 结构（适配各大游戏引擎和 App）

    • 自带 AirtestIDE，可录制脚本、运行、生成 HTML 报告

  • 与 ADB 的关系：

    • Android 连接和操作（安装、启动、触控、键盘等）依赖 ADB

  • 适用场景：

    • 游戏 UI / 非标准控件（OpenGL 渲染）自动化

    • 需要“所见即所得”录制、图像断言的项目

  1. Nico（基于 ADB 命令的跨平台自动化框架）

  • 定位：基于 ADB（Android）与 IDB（iOS）构建的跨平台移动自动化框架，Python 实现。[5]

  • 特点：

    • 直接封装 ADB 命令，提供 NicoAndroid 对象进行元素查找和操作

    • 支持 text/resource_id/class_name/xpath 等多种定位方式

    • 内置 UI Inspector，方便调试元素树

  • 适用场景：

    • 不想折腾 Appium，全 Python，希望通过更轻量的方式用 ADB 控制设备

    • 需要同时兼顾 Android+iOS，但允许后端使用两种不同机制（ADB+IDB）

  1. UiAutomator2 / Espresso / Selendroid / Playwright(Android Web)

这几个不是直接“做 ADB 的库”，但在实际工程中常被与 ADB 组合使用：

  • UiAutomator2：Google 原生 UI 自动化框架，常作为 Appium 的 Android driver。[2]

  • Espresso：白盒 UI 测试框架，在 app 进程内执行，适合快速单 App UI 测试。[6]

  • Selendroid：早期“Android 的 Selenium”，面向老版本 Android 和 WebView 场景，现在更多用于维护历史项目。[7]

  • Playwright：对移动端主要用于 移动 Web 自动化，对 Android 原生 App 支持还是“实验性”。[8]

如果你的关注点是“纯基于 ADB 的黑盒/UI 级控制”，上面这些原生框架更多是作为参考或被上层工具（如 Appium）封装使用。

三、面向 AI / Agent 的安卓自动化开源项目（含“会用手机的 AI”）

“类似智谱 AutoGLM 的基于 AI 的安卓自动化项目”。整体看下来，大致有两种代表路线：

  1. 视觉语言模型（VLM）+ ADB 的“Phone Agent”路线

  2. LLM + MCP/工具调用 的“通用 Agent 控制手机”路线

  1. 智谱 Open-AutoGLM / Phone Agent（强烈相关）

  • 核心概念：[9]

    • Phone Agent：基于 AutoGLM 的手机端智能助手框架

    • 多模态理解手机屏幕（视觉+文字），结合自然语言指令规划点击/滑动/输入

    • 通过 ADB（Android）或 HDC（HarmonyOS）执行操作

  • 架构：[9]

    • Agent 代码（PC 端）：负责调用模型、解析动作、通过 ADB 控制手机

    • Vision Model Service：可远程 API，也可本地 vLLM/SGlang 部署

    • 流程：

      • ADB 截图

      • 送入视觉语言模型 → 得到界面理解 & 下一步操作

      • 通过 ADB 执行（Tap / Swipe / Type 等）

      • 循环直到任务完成

  • 能力：

    • 直接支持“自然语言 → 手机完整操作链路”（例如“打开微信给张三发消息”）

    • 支持敏感操作人工确认 / 接管（登录、验证码场景）

    • 支持远程 ADB 连接（WiFi / 网络）

    • 已适配 50+ 高频中文 App 场景

  • 与传统自动化的关系：

    • 可以完全不用写测试脚本，把测试步骤交给 Agent 自己规划

    • 也可以作为一个“强大的自动化执行器”，由你的测试平台生成高层自然语言指令

  • 如果你想“直接用智谱方案做 AI 安卓自动化”：

    • 可以直接基于 GitHub 的 zai-org/Open-AutoGLM 项目，按 README 步骤部署

    • 模型可使用 AutoGLM-Phone-9B / -Multilingual，通过 API 或本地部署

  1. DroidRun（LLM 中立、Android+iOS 的智能 Agent）

  • 定位：通过 LLM Agent 控制 Android / iOS 设备，使用自然语言自动化各种操作。[10]

  • 特点：

    • LLM 无关：支持 OpenAI / Anthropic / Gemini / Ollama / DeepSeek 等

    • 同样采用“截图分析 + UI 结构抽取”方式理解屏幕

    • 有 CLI 和 Python API，可集成到 CI、测试平台或你自己的 Agent 系统

    • 集成执行追踪（Arize Phoenix），适合调试长链路任务

  • 适用场景：

    • 国际化或多模型环境，不希望绑定某一家模型供应商

    • 想要一个“手机 Agent”框架，但更习惯用 GPT/Claude 等大模型

  1. Android-MCP（把 Android 变成 LLM 可用的“工具箱”）

  • 定位：一个轻量的 MCP 服务器，把 Android 设备能力以标准工具形式暴露给 LLM。[11]

  • 技术路线：

    • 底层通过 ADB + Android Accessibility API 操作设备（点击、滑动、输入、读取视图树、执行 shell 等）

    • 上层是标准的 Model Context Protocol（MCP）接口，和任何支持 MCP 的 Agent/IDE/助手兼容

  • 特征：

    • “Bring Your Own LLM/VLM”：任何支持 MCP 的大模型都能调用这套工具

    • 提供丰富工具集：Click / LongClick / Type / Swipe / Drag / Press / Wait / Notification / Shell 等

    • 延迟在 2–4 秒每轮交互，对交互式自动化足够

  • 适用场景：

    • 你已经有一个自研 AI Agent 平台（或用现成 Agent 框架），只需要一个“安卓能力插件”

    • 希望统一所有外部工具接入方式（数据库 / HTTP / Android / 云服务等都用 MCP）

  1. AndroidViewClient 的 MCP 集成

  • 在 AndroidViewClient 的最新版本中，作者提供了一个 CulebraTester2 MCP Server：[3][12]

    • 特点：

      • 使用 AndroidViewClient + CulebraTester2 采集 UI 信息

      • 通过 MCP 方式提供“基于文本/资源ID查找元素并点击、长按、输入、截屏等 20 多种工具”

    • 这基本是“老牌 ADB 框架 + 新标准 MCP + LLM”的组合，平滑过渡到 AI 驱动测试

  1. 其他相关 AI 自动化项目

这些不是都以 ADB 为核心，但思路类似“AI 控制手机”：

  • minitap-ai/mobile-use[13]

    • 开源 AI Agent，通过自然语言控制 Android / iOS

    • 能在任意应用中执行 UI 操作、抓取数据，并按描述输出 JSON 等结构化结果

    • LLM 可配置，适合做“APP 级信息抽取 + 自动操作”

  • FIRERPA / lamda[14]

    • 自称“最强 Android RPA Agent 框架”，重心在企业级 RPA/监控/取证

    • 纯设备端服务，无外部依赖，兼容 Android 6–16，远程桌面延迟 <80ms

    • 提供 160+ API，通过 Python SDK 能与 AI 模型集成，更多偏安全自动化、数据自动化

  • DroidWright[15]

    • 在设备上运行的 JS 自动化框架，使用 Accessibility Service，而非 PC 侧 ADB

    • 虽然“不需要 ADB”，但与很多 ADB 思路相通：脚本控制 +（可选）AI 生成脚本

四、如果你要“现在”落地，怎么选？

  1. 只做传统自动化测试（脚本为主）

  • 想要稳定、团队协作好：Appium 4.x + UiAutomator2

  • Python 技术栈，喜欢直接用 ADB：

    • 中小项目：AndroidViewClient 或 Nico

    • 游戏 / 图像复杂：Airtest + Poco

  1. 想要“类似智谱 AutoGLM 的 AI 自动化手机能力”

  • 重点路线 A：直接用智谱 Open-AutoGLM / Phone Agent

    • 你的主要业务是中文、国内 App 场景

    • 接受 AutoGLM 体系（或已在用 GLM 模型）

    • 需要快速验证“AI 能帮我自动操作手机完成任务/测试”

  • 重点路线 B：DroidRun + 你现有的 LLM（GPT/Claude 等）

    • 想用海外大模型或多模型对比

    • 希望 Android + iOS 都有统一的 Agent 管理

  • 重点路线 C：Android-MCP / AndroidViewClient MCP + 自建 Agent

    • 你已经有一个 Agent 编排框架，只缺“安卓能力插件”

    • 希望工具接入接口统一（HTTP、DB、Android 都用 MCP）

  1. 渐进式升级路径（从 ADB 到 AI）

  1. Phase 1：用 AndroidViewClient / Nico / Airtest 把传统脚本整理好

  2. Phase 2：接入 MCP 服务器（Android-MCP 或 CulebraTester2 MCP）

    1. 用 LLM 先从“帮你生成脚本”进化到“直接通过 MCP 工具操作设备”

  3. Phase 3：引入视觉语言模型（如 AutoGLM-Phone-9B 或其他 VLM）

    1. 把复杂 UI 理解/点击规划交给模型

    2. 对难测场景（跨 App、复杂流程）使用 AI Agent 自动回归

五、总结（直给）

  • 基于 ADB 的成熟自动化框架：

    • 工程界主流：Appium（+UiAutomator2）

    • 轻量脚本化：AndroidViewClient / Culebra、Nico、Airtest

  • 基于 AI 的安卓自动化（类似智谱 AutoGLM）代表项目：

    • 智谱 Open-AutoGLM / Phone Agent（VLM+ADB，中文场景极佳）

    • DroidRun（LLM 中立，支持 Android+iOS）

    • Android-MCP、AndroidViewClient MCP（把安卓能力以 MCP 工具形式暴露给各种 Agent）

    • 辅助/相关：minitap-ai/mobile-use、FIRERPA/lamda、DroidWright 等

  • 选型方向建议：

    • 要成熟稳定测试：先用 Appium / AndroidViewClient / Airtest

    • 要“会用手机的 AI”：选 Open-AutoGLM 或 DroidRun

    • 要自研 Agent 平台：优先看 Android-MCP / CulebraTester2 MCP，把安卓封装成 MCP 工具

References

[1] appium/appium. https://github.com/appium/appium [2] appium/appium-uiautomator2-driver. https://github.com/appium/appium-uiautomator2-driver [3] dtmilano/AndroidViewClient. https://github.com/dtmilano/AndroidViewClient [4] AirtestProject/Airtest. https://github.com/AirtestProject/Airtest [5] letmeNo1/Nico. https://github.com/letmeNo1/Nico [6] Espresso | Test your app on Android. https://developer.android.com/training/testing/espresso [7] selendroid/selendroid. https://github.com/selendroid/selendroid [8] Android class in Playwright docs. https://playwright.dev/docs/api/class-android [9] zai-org/Open-AutoGLM. https://github.com/zai-org/Open-AutoGLM [10] droidrun/droidrun. https://github.com/droidrun/droidrun [11] CursorTouch/Android-MCP. https://github.com/CursorTouch/Android-MCP [12] CulebraTester2 MCP Configuration Guide. https://github.com/dtmilano/AndroidViewClient/blob/master/docs/MCP_CONFIGURATION.md [13] minitap-ai/mobile-use. https://github.com/minitap-ai/mobile-use [14] firerpa/lamda. https://github.com/firerpa/lamda [15] tas33n/DroidWright. https://github.com/tas33n/DroidWright

# 功能测试 # 人工智能 # adb
Logo
2048 AI社区

有“AI”的1024 = 2048，欢迎大家加入2048 AI社区

更多推荐

为 Zensical 添加多语言翻译

本文介绍了如何为Zensical网站添加客户端多语言翻译功能。主要内容包括： 功能特点： 基于硅基流动Qwen3-8B模型的实时翻译 支持中/英/日等多语言切换 提供页面级和全站翻译两种模式 具备翻译缓存和本地存储功能 实现步骤： 引入翻译核心脚本(glm-config.js和glm-translate.js) 通过GitHub Actions注入API密钥 配置zensical.toml中的多语

avatar 2048 AI社区
cover

【Linux】free 命令查看内存使用情况

avatar 2048 AI社区

从C到C++入门：C++有而C语言没有的基础知识总结

namespace用法：命名空间需要用到namespace关键字，后面跟命名空间的名字，然后接一对{}即可，{} 中即为命名空间的成员。前面提到C语言将所有的变量、函数都放在全局作用域中，从而造成冲突。C++允许程序员通过namespace关键字自定义命名空间（作用域），自定义的命名空间同全局作用域一样，也可以以命名空间中可以定义变量/函数/类型。如：代码语言：javascriptAI代码解释re

avatar 2048 AI社区