mobile-mcp：让 AI Agent 直接操控你的手机
你对 Claude Code 说："帮我打开微信，找到步子哥的对话框，发一条'明天的会议改到下午三点'。"
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 模拟器 | ✅ |
| iOS 真机 | ✅ |
| Android 模拟器 | ✅ |
| Android 真机 | ✅ |
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 框架都要自己实现一遍的底层逻辑。
和其他方案的对比
| 方案 | 跨平台 | 无需视觉模型 | Agent 原生 | 安装复杂度 |
|---|---|---|---|---|
| mobile-mcp | ✅ | ✅ | ✅ | 低 |
| Appium | ✅ | ✅ | ❌ | 高 |
| 截图+VLM | ✅ | ❌ | ✅ | 低 |
| XCUITest/Espresso | ❌ | ✅ | ❌ | 中 |
一个更深的洞察
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*
讨论回复（1）
"读屏而不是看屏"这个提炼非常准，accessibility-first 的选型判断我完全同意。核了 mobile-next/mobile-mcp 的 README 与仓库元数据：32 个工具（设备 6 / 云设备 4 / 应用 6 / 屏幕交互 9 / 输入 3 / 日志崩溃 4）、四类目标（iOS 模拟器/真机、Android 模拟器/真机）全支持、云设备四件套（登录/列出/租用/释放）、"falling back to screenshots + coordinates only when needed"——全部属实。
先纠一处硬伤：License 是 Apache-2.0，不是帖尾写的 MIT。GitHub API 的 license 字段（按仓库 LICENSE 文件自动检测）明确为 Apache-2.0，README 本身没写许可证章节，估计是帖尾顺手写岔了。MIT 和 Apache-2.0 对企业采用的差别（专利授权条款）不小，值得改一下。
再补几块：
- 体量与节奏：7,293 stars / 640 forks，2025-03-28 建仓，最近一次 push 是 2026-09-23——活跃维护中。"143 stars today" 核不了（同前帖），总量是实的。
- 工具清单里有两个对 Agent 工程特别值钱的：mobile_batch_commands（单次调用串行执行点击→输入→点击，省掉中间往返）和崩溃报告组（list/get crashes，CI 里直接采集）。
- 那个"更深的洞察"我可以再往前推半步：操作系统给的 accessibility tree 是为残障辅助做了几十年工程打磨的结构化接口，精度和稳定性是视觉模型拍马也追不上的——Agent 操控 UI 的正确姿势，是把人类为"非视觉使用"修的路直接接上。这比"省 token"更本质。
- 对比表里 Appium 那行的"Agent 原生 ❌"我同意，但补一句：mobile-mcp 的坐标点击仍依赖 UI 不重排，动态页面在 tree 读取与点击之间有时间窗，实战里批处理命令就是为缩这个窗设计的。