Mobile MCP 移动端自动化：读无障碍树操控 iOS/Android，一套 API 通吃双端

移动端测试这活儿，干过的同行都懂里面的苦。自动化得写 XCUITest（iOS 的 UI 测试框架）或 Espresso（Android 的对应物），双端各整一套；想用 AI agent 操控手机，主流方案是让模型“看”截图再报坐标——又烧 image token，坐标还经常点偏。

上周刷到 mobile-next/mobile-mcp：一个专治这毛病的 MCP 服务器。GitHub API 实测 6,933 Star / 615 Fork，Apache-2.0，TypeScript 写的，维护活跃。项目 2025 年 3 月创建，现在已有中文版 README（README.zh-CN.md）。

我把 README、架构图和官方文档拆了一遍。没实际连真机跑，文中数据全部来自官方 README 并逐一标注。先说结论：它最聪明的地方不是“能操控手机”，而是选对了驱动方式——不靠视觉模型“看”，直接读无障碍树。

一句话定位

Mobile MCP 是一个移动端自动化的 MCP 服务器：装上它，你的 AI agent（Claude Code、Cursor、Codex 等）就能直接操控 iOS/Android 的模拟器、仿真器和 USB 真机——点按钮、填表单、装应用、抓日志、取崩溃报告，做自动化测试和数据抓取。

和传统方案最大的区别：一套 API 通吃所有目标，不用写 XCUITest/Espresso 这些平台专用胶水，也不要求你懂双端差异。

三个核心亮点

能力层面：32 个工具覆盖完整链路。 我按 README 分组实测数了一遍：设备管理 6 个（列设备、屏幕尺寸、GPS 覆盖、剪贴板）、应用管理 6 个（装/卸/启/停）、屏幕交互 9 个（截图、列元素、点击/双击/长按/滑动、录屏）、输入导航 3 个、日志崩溃 4 个、云端真机 4 个，外加批量执行。从点击到崩溃日志，一条链路全包。

架构层面：Accessibility-first，省 token 又防幻觉。 这是全项目最有含金量的设计决策。它优先读原生无障碍树（accessibility tree，操作系统为视障用户维护的界面元素结构，自带每个控件的坐标、文本、类型），拿到的是真实 UI 元素的结构化数据——不是模型看图猜的。只在无障碍树不完整时才回退到“截图 + 坐标点击”。省 image token、响应快，还规避了纯视觉方案的歧义。

团队层面：MCP 客户端全兼容 + 云端真机。 Claude Code、Codex、Gemini、Copilot、Cursor、Cline、Goose、opencode、Windsurf 等 MCP 客户端都能接。本地没设备？官方 Mobile Next Cloud 提供按需租用的云端真机，适合 CI/CD 和规模化场景。生态里还有 mobilewright（把 agent 探索转成确定性测试，“移动版 Playwright”）和 mobilecli（底层通用设备 CLI）。

为什么“读树”比“看图”更可靠

旧方案的路径：让多模态模型看截图 → 模型报坐标 → 脚本去点。三个固有问题：image token 贵、坐标有偏差（分辨率/DPR 换算容易翻车）、模型可能“看图编造”不存在的按钮。

Mobile MCP 的架构反转了这个顺序。看官方架构图：

关键分三层：

设备抽象层：iOS 走 xcrun simctl（macOS 自带的模拟器管理工具）和 WebDriverAgent，Android 走 adb（Android 调试桥）。双端差异被这层吃掉，上层 API 统一。

交互层：优先 mobile_list_elements_on_screen 读无障碍树，拿到结构化元素列表——真实坐标、真实属性、确定性输出。模型面对的是“元素 3：登录按钮”这种明确目标，不是像素猜谜。需要时才调 mobile_click_on_screen_at_coordinates 做坐标兜底。

服务层：stdio 本地模式之外，还支持 Streamable HTTP 模式（--listen 3000），配 Bearer Token 认证。这意味着 MCP 服务器可以集中部署在一台接满设备的机器上，全组远程共用。

一句话总结架构优势：把“AI 看屏幕”变成“AI 查结构化数据”，这是从“猜”到“查”的可靠性跃迁。

单机快速上手

两步跑通，以 Claude Code 为例：

# 1. 注册 MCP 服务器（首次自动经 npx 拉起）
claude mcp add mobile-mcp -- npx -y @mobilenext/mobile-mcp@latest

# 2. 对 agent 说人话就行
# "列出我连接的设备，然后打开设置 App 截个图"

前置条件按平台备好：

iOS 模拟器：macOS + Xcode（xcrun simctl）
Android 模拟器：Android SDK + 运行中的模拟器（adb）
真机：USB 连接 + iOS 信任授权 / Android 开启 USB 调试

高频玩法三个：

# 自动化测试
"打开 App，走一遍登录流程，把每步截图存下来"

# 数据抓取
"读取当前屏幕的列表元素，提取标题和价格存成 JSON"

# 排障
"抓一下这个 App 最近的崩溃日志，总结崩溃原因"

Codex / Gemini CLI 的安装命令在 README 里都有现成的，npx -y @mobilenext/mobile-mcp@latest 这条命令是通用的——任何 MCP 客户端都能用这行配置。

企业团队落地方案

1）团队改造思路。 定位是“移动端自动化基础设施”，不是测试平台本身。推荐姿势：测试团队把重复手测场景（回归清单、多步用户旅程）交给 agent + mobile-mcp 起草执行，人工看结果。边界要想清楚——它管“功能链路通不通”，不管性能测试和像素级视觉回归。

2）部署方案。 两条路：个人开发者走 stdio 模式（npx 拉起，各用各的）；团队走 HTTP 模式集中部署——一台 Mac 接 iOS 真机、一台 Linux 挂 Android 设备，MOBILEMCP_AUTH 配 Bearer Token，全组 MCP 客户端远程连。设备资源集中管理，不用每人插一堆手机。

3）集成方案。 CI/CD 里两个选择：云端真机（Mobile Next Cloud，按需租用，适合多机型矩阵）或本地模拟器 headless 模式（README 有专门章节）。跑完的录屏、崩溃日志直接进构建产物。更进一步的打法是用官方 mobilewright 把 agent 的探索性测试固化成确定性测试用例，进常规回归。

4）团队规范定制。 环境变量裁剪行为：MOBILEMCP_DISABLE_TELEMETRY=1 关遥测（合规团队必开）、MOBILEMCP_ALLOW_UNSAFE_URLS 控制深链白名单、MOBILEMCP_LEGACY_ROBOT 切换旧版平台驱动。仓库还带了 skills/mobile-automation 技能包，可以往里沉淀团队自己的测试规范。

真实适用场景

• 移动端自动化测试——回归清单交给 agent 跑，人只看结果
• App 数据抓取——读无障碍树拿结构化数据，比截图 OCR 靠谱
• 数据录入与表单自动化——批量填单、多步用户旅程
• 排障辅助——崩溃日志 + 设备日志一条命令抓全
• Agent 间协作——给上层 agent 框架提供“手”的能力

优缺点与避坑

优势：Accessibility-first 省 token、防幻觉；一套 API 通吃 iOS/Android 与模拟器/真机；32 个工具链路完整；Apache-2.0；有云端真机和 mobilewright 生态配套；中文 README 对国内团队友好。

局限：受众偏移动开发/测试这个细分方向，不做移动的基本用不上；“确定性输出”依赖 App 的无障碍标注质量——无障碍树不完整的 App 会回退到截图方案，成本和不确定性都会上升；云端真机是商业服务，本地真机需要 USB + 授权这两道物理门槛。

避坑三条：

• iOS 真机首次连接要在手机上点“信任”，CI 机器要提前做好配对授权，别等流水线跑一半卡在弹窗
• Android 模拟器支持 Linux/Windows/macOS，但 iOS 模拟器只有 macOS/Linux 能跑，Windows 团队只能测 Android 或走云端
• 无障碍质量差的 App（游戏、自绘 UI 居多）效果打折，接入前先用 mobile_list_elements_on_screen 试探目标 App 的树完不完整

写在最后

Browser-use 治好了 AI 操作网页，Mobile MCP 在试着治好 AI 操作手机。同一个思路的移动端版本：别让模型猜像素，让模型查结构。对移动开发者和测试工程师，这是把重复手测交出去的一把钥匙；对不做移动的读者，“Accessibility-first 优于视觉方案”这个架构判断，值得记住——它在很多自动化场景里都成立。

开源地址：https://github.com/mobile-next/mobile-mcp