📌 项目地址：mobile-next/mobile-mcp | ⭐ 7,223 颗星 | 🔧 TypeScript | 📜 未标注
移动端自动化的老问题：iOS 写 XCUITest，Android 写 Espresso，两套栈、两套环境，模拟器和真机的接入方式还各不相同。mobile-mcp（7,223 star，TypeScript）把这件事收拢到一个 MCP Server 里。你在 Claude Code、Codex、Gemini、GitHub Copilot 或任何 MCP 兼容客户端里描述目标，Agent 就直接去操作 iOS/Android 原生应用。
先说它最关键的技术选择
市面上很多“AI 操作手机”的方案走截图路线：每一步截屏、传图、让视觉模型猜该点哪。慢，贵，而且结果不确定。
mobile-mcp 反过来：从原生无障碍树驱动应用，直接读真实的 UI 元素，拿到的是结构化文本数据，不消耗图像 token。只有必要时才回退到截图加坐标点击。
这个设计带来两个直接后果：
- 便宜。无障碍快照是文本，比图像便宜得多，跑一个几十步的流程成本差距很明显。
- 确定。读到的是真实的元素属性，不是模型对截图的猜测，Agent 判断“按钮在不在、文案是什么”不会靠猜。
支持哪些设备
| 目标 | 前置条件 |
|---|---|
| iOS 模拟器 | Xcode + 已启动的模拟器（xcrun simctl） |
| iOS 真机 | USB 连接并已信任 |
| Android 模拟器 | Android SDK + 运行中的模拟器（adb） |
| Android 真机 | adb + 已授权的 USB 调试 |
同一套工具 API 覆盖全部四种目标，不用写平台特定的胶水代码。
能做什么
设备层面：点击、滑动、手势，应用安装/启动/终止，录屏，硬件按键，深链，屏幕旋转。这些是原子操作，真正有意思的是拿 LLM 驱动多步骤用户旅程，比如让 Agent 在真机上跑完一整个注册或下单流程，自己处理每一步的表单和弹窗。
README 里列出的 MCP 工具：
mobile_list_available_devices：列出所有可用设备（模拟器、仿真器、真机）mobile_get_screen_size：获取设备屏幕像素尺寸
具体安装配置命令看官方 README，有简体中文版（README.zh-CN.md）。
几个要泼冷水的地方
它不是装完即用。本地跑 iOS 依然要装 Xcode，Android 依然要 SDK 和 adb。它省掉的是写两套平台测试脚本的工作，不是开发环境本身。
项目方同时推 Mobile Next Cloud，付费的云端真机服务，用同一套工具操作，免本地环境。这是商业部分，开源仓库本身不受影响。
另外，Agent 驱动的自动化天然不如脚本稳定。如果你的场景是每天跑几千次的回归测试，传统方案可能仍更合适；它的优势在需求多变、写脚本不划算的场景，比如探索性测试、数据录入、从 App 里抽取结构化数据。
我的判断
如果你已经在用 Claude Code 这类 Agent 做开发工作流，又需要覆盖移动端，mobile-mcp 值得直接试。最有说服力的用法是：让 Agent 在真机上走一遍新用户的完整流程，然后告诉你卡在哪一步、界面上实际显示的是什么。这种事以前要么手动点一遍，要么花几天写测试脚本。
觉得 Appium 维护两套平台脚本太重的团队，也可以拿它评估替代方案。