mobile-mcp：让 AI Agent 直接操控你的手机

143 stars today | TypeScript | by mobile-next

一个场景

你对 Claude Code 说："帮我打开微信，找到步子哥的对话框，发一条'明天的会议改到下午三点'。"

Claude Code 想了想，调用了 mobile_list_available_devices，发现你连着一台 iPhone。它调 mobile_get_screen_size，调 mobile_list_elements_on_screen，拿到了当前屏幕上所有 UI 元素的列表——每个元素都有坐标、文字、类型。它找到"微信"图标，调 mobile_click_on_screen_at_coordinates 点了一下。

微信打开了。它再调 mobile_list_elements_on_screen，找到搜索框，调 mobile_type_keys 输入"步子哥"，找到匹配的联系人，点击进入对话框，再调 mobile_type_keys 发送消息。

整个过程没有截图、没有视觉模型、没有"我猜这个按钮大概在屏幕中间"的瞎猜。

这就是 mobile-mcp 做的事：给 AI Agent 一个操控手机的标准化接口。

它解决了什么问题

在 mobile-mcp 之前，让 AI 操控手机大概有三条路：

路一：截图 + 视觉模型。 Agent 截一张图，用 GPT-4V 或 Claude 看图，识别出按钮位置，然后点击。问题是：慢、贵、不准。每一步都要发一张截图给视觉模型，token 消耗巨大，而且视觉模型对 UI 元素的识别精度有限——小按钮、文字密集区域、动态加载内容都容易出错。

路二：平台专用自动化框架。 iOS 用 XCUITest，Android 用 Espresso。问题是：每个平台一套代码，维护成本高，而且这些框架是为测试设计的，不是为 Agent 设计的——它们假设你已经知道要点哪个元素，而不是让 Agent 自己探索。

路三：Appium。 跨平台，但 API 设计老旧，配置复杂，而且同样假设你知道要点什么。

mobile-mcp 选了第四条路：直接读 accessibility tree。

Accessibility-first 的核心思路

每个现代操作系统都维护一棵 accessibility tree——这是给残障辅助功能（VoiceOver、TalkBack）用的 UI 元素树。它包含屏幕上每个可见元素的类型、文字、坐标、状态。

mobile-mcp 做的事很简单：把这棵树读出来，转成结构化数据，给 Agent 看。

Agent 拿到的不是一张需要"看"的截图，而是一个 JSON 列表：

[
  {"type": "button", "text": "微信", "x": 45, "y": 612, "w": 90, "h": 90},
  {"type": "button", "text": "通讯录", "x": 135, "y": 612, "w": 90, "h": 90},
  ...
]

Agent 不需要"识别"按钮在哪——它已经知道了。它只需要决定点哪个，然后调 mobile_click_on_screen_at_coordinates(45, 657)。

这个选择带来三个好处：

快。 读 accessibility tree 比截图+视觉模型快一个数量级。没有图像编码、没有视觉推理、没有 token 消耗。

准。 坐标是操作系统给的，不是视觉模型猜的。小按钮、文字密集区域、动态加载内容都不影响。

便宜。 不用发截图给视觉模型，省掉了最贵的 token 消耗。只在 accessibility tree 不够用的时候（比如 canvas 绘制内容、视频内容）才 fallback 到截图+坐标。

一个 API，所有平台

mobile-mcp 的另一个核心设计是：同一套工具，跨所有平台。

你不需要写 iOS 版和 Android 版两套代码。Agent 调用的都是同一组 MCP 工具：mobile_list_elements_on_screen、mobile_click_on_screen_at_coordinates、mobile_type_keys、mobile_swipe_on_screen。底层是 Xcode 的 xcrun simctl 还是 Android 的 adb，Agent 不需要知道。

还有一个更激进的功能：云设备。通过 mobile_allocate_remote_device 和 mobile_release_remote_device，你可以从云端租一台真机，用完释放。这意味着 Agent 可以在 CI 里跑端到端测试，不需要本地连真机。

工具清单

mobile-mcp 提供了 30+ 个 MCP 工具，按功能分类：

• 设备管理：列出设备、获取屏幕尺寸、获取/设置方向、设置 GPS 位置、读写剪贴板
• 云设备：登录云平台、列出可用设备、租用/释放
• 应用管理：列出应用、获取前台应用、启动/终止/安装/卸载应用
• 屏幕交互：截图、列出 UI 元素、点击/双击/长按/滑动、录屏
• 输入导航：输入文字、按硬件按钮（HOME/BACK/VOLUME）、打开 URL
• 日志崩溃：收集设备日志、列出/获取崩溃报告
• 批量命令：一次调用执行多个工具（比如点击→输入→点击）

它在 MCP 生态里的位置

MCP（Model Context Protocol）是 Anthropic 提出的标准，目的是让 AI Agent 用统一接口调用外部工具。现在 MCP 生态里有文件系统、数据库、API、搜索等各种 server，但移动设备一直是一个空白。

原因不难理解：移动设备比文件系统复杂得多。它有状态（前台/后台/锁屏）、有权限（USB 调试/开发者模式）、有平台差异（iOS/Android）、有连接方式差异（模拟器/真机/云设备）。把这些复杂性封装成一组统一的 MCP 工具，需要大量的平台工程经验。

mobile-mcp 的价值在于：它把"操控手机"这件事变成了 Agent 的一个标准能力，而不是每个 Agent 框架都要自己实现一遍的底层逻辑。

和其他方案的对比

mobile-mcp 是唯一一个在所有维度上都满足的方案。

一个更深的洞察

mobile-mcp 的 accessibility-first 设计揭示了一个更深的道理：Agent 不需要"看"屏幕，它需要"读"屏幕。

视觉模型是给"看"设计的——模拟人类视觉，从像素中推断语义。但操作系统已经有一份结构化的 UI 描述了（accessibility tree），为什么要让 Agent 从像素重新推断一遍？

这就像：你有一份 JSON 数据，但你非要把它渲染成 HTML，然后让 Agent 用 OCR 读回来。中间每一步都在丢失信息、增加成本。

mobile-mcp 的选择是：直接给 Agent 结构化数据。让 Agent 做它擅长的事（理解结构、做决策），不让它做它不擅长的事（从像素推断语义）。

这个思路不只适用于移动设备。桌面端的 UI automation、Web 端的 DOM 操作、甚至 API 调用，本质上都是同一个道理：结构化数据 > 视觉推理。

GitHub: mobile-next/mobile-mcp · License: MIT · Language: TypeScript