★ FEATURED ARTICLE 1. 移动端自动化的痛点与 mobile-mcp 的切入点做过移动端自动化的人都有一个共同感受环境搭建比写用例还累。Appium 要装 Node、配 JDK、下 Android SDK、搞 WebDriverAgent 签名一套流程走下来半天没了。更别提 iOS 真机调试时那些证书、开发者模式、设备信任的连环坑。我身边不少测试工程师光是让脚本在 iOS 上跑起来就折腾了整整一周。mobile-mcp这个项目本质上是在解决一个很具体的问题让 AI Agent 或者自动化脚本用统一的方式去操控 iOS 和 Android 设备。它基于 MCPModel Context Protocol协议把移动设备的操作能力封装成标准化的工具接口上层无论是 Claude、Cursor 还是自己写的 Agent都能通过这套接口去点击、滑动、输入、截图、获取页面结构。MCP 是什么简单说它是让大模型能够调用外部工具的一套协议规范。你可以把它理解成AI 世界的 USB 接口——以前每个工具都要单独适配每个 AI 平台现在大家都按 MCP 标准来插上就能用。mobile-mcp就是把这个标准应用到了移动端设备控制上。这个项目适合谁三类人值得关注一是做移动端自动化测试的工程师想摆脱 Appium 那套重环境的束缚二是搞 AI Agent 开发的需要让 Agent 具备操控手机的能力三是做跨端兼容性验证的想用一套脚本同时覆盖 iOS 和 Android。哪怕你之前没接触过 MCP只要会用命令行、能看懂基本的配置这篇文章的内容都能直接上手。2. 核心架构拆解mobile-mcp 到底怎么工作的2.1 MCP 协议层的角色定位要理解mobile-mcp先得搞清楚 MCP 的三层结构。最底层是设备控制层负责跟 iOS 的 WebDriverAgent 或者 Android 的 ADB/UIAutomator 打交道中间是MCP Server 层把设备操作抽象成标准工具tool比如tap、swipe、screenshot、get_page_source最上层是MCP Client 层也就是 AI 应用或者你的脚本通过 stdio 或 SSE 跟 Server 通信。这种分层的好处很明显。设备控制层换了实现方式上层完全不用改。比如你原来用 Appium 驱动 Android现在想换成直接调 ADB只要 MCP Server 的接口不变Agent 那边的代码一行都不用动。这就是协议标准化的价值。实际部署时mobile-mcp通常以本地进程方式运行通过 stdio 跟 Client 通信。配置大概长这样{ mcpServers: { mobile-mcp: { command: npx, args: [-y, mobile-mcp/server], env: { ANDROID_HOME: /Users/yourname/Library/Android/sdk, IOS_DEVICE_ID: auto } } } }这段配置放在 Claude Desktop 或者 Cursor 的 MCP 设置里重启后就能在对话中直接调用移动设备操作了。2.2 iOS 与 Android 双端适配的差异处理iOS 和 Android 的自动化底层机制完全不同这是mobile-mcp最需要花心思的地方。Android 这边相对成熟。通过 ADB 可以完成大部分操作adb shell input tap x y点击、adb shell input swipe滑动、adb shell uiautomator dump获取页面结构、adb exec-out screencap截图。这些命令稳定、延迟低几乎不需要额外依赖。mobile-mcp在 Android 侧主要就是对这些 ADB 命令的封装和结果解析。iOS 就麻烦得多。苹果不允许直接通过 USB 发送触摸事件必须依赖 WebDriverAgentWDA这个中间层。WDA 是一个运行在设备上的 HTTP 服务通过 XCUITest 框架来操控 UI。mobile-mcp需要先在你的 Mac 上编译并部署 WDA 到 iOS 设备然后通过 HTTP 请求跟它通信。这里有个关键细节WDA 的签名问题。免费开发者账号签的 WDA 只有 7 天有效期过期后需要重新签名部署。很多团队用个人账号调试每周一早上第一件事就是重新签 WDA非常影响效率。我的建议是如果项目长期做 iOS 自动化花 99 美元买个开发者账号签名有效期延长到一年省心太多。对比维度Android 侧iOS 侧底层驱动ADB UIAutomatorWebDriverAgent XCUITest部署难度低装好 SDK 即可高需编译签名 WDA签名有效期无限制免费账号 7 天付费账号 1 年截图方式adb exec-out screencapWDA HTTP 接口页面结构获取uiautomator dumpWDA source 接口输入法处理需切换 ADB Keyboard直接 sendKeys2.3 工具接口设计的取舍逻辑mobile-mcp暴露给上层的工具接口设计上做了不少取舍。比如截图这个操作它没有返回图片文件路径而是直接返回 base64 编码的图片数据。为什么因为 MCP Client 可能是运行在另一台机器上的 AI 服务返回路径它读不到返回 base64 才能让模型直接看到屏幕内容。再比如页面结构获取它返回的是精简后的元素树而不是完整的 XML。完整的 UIAutomator dump 动辄几万行直接塞给大模型会爆 token。mobile-mcp会过滤掉不可见元素、合并嵌套层级、只保留可交互节点把数据量压缩到原来的十分之一左右。这个处理非常关键直接决定了 Agent 能不能在合理的 token 预算内理解页面。还有一个细节是操作等待策略。移动端 UI 有动画、有网络加载点完一个按钮立刻获取页面结构很可能拿到的是过渡态。mobile-mcp在每次操作后默认等待 500ms并且提供了wait_for_element工具让上层显式等待某个元素出现。这个默认值是可以配的实测下来 500ms 对大部分 App 够用但如果是重动画的页面建议调到 1000ms 以上。3. 从零搭建 mobile-mcp 实操环境3.1 Android 侧环境准备与验证先说 Android因为简单先跑通它能建立信心。第一步装 Android SDK。如果你已经装了 Android StudioSDK 一般在~/Library/Android/sdkMac或者%LOCALAPPDATA%\Android\SdkWindows。没装的话单独下 command line tools 也行不需要完整的 IDE。第二步配置环境变量。把platform-tools和emulator目录加到 PATH 里export ANDROID_HOME$HOME/Library/Android/sdk export PATH$PATH:$ANDROID_HOME/platform-tools export PATH$PATH:$ANDROID_HOME/emulator第三步验证设备连接。手机开启开发者模式连续点击版本号7 次打开 USB 调试插上电脑adb devices正常应该输出类似emulator-5554 device或者ABCD1234 device的内容。如果显示unauthorized在手机上确认那个允许 USB 调试的弹窗就行。第四步验证核心命令。手动跑一遍点击和截图确认 ADB 本身没问题adb shell input tap 500 1000 adb exec-out screencap -p /tmp/screen.png截图能正常打开说明 Android 侧基础环境 OK。注意部分国产手机小米、OPPO、vivo需要额外开启USB 调试安全设置才能模拟点击只开普通 USB 调试的话input tap会静默失败不报错但也没效果。这个坑我踩过排查了半天以为是坐标算错了。3.2 iOS 侧 WebDriverAgent 部署要点iOS 侧是重头戏。你需要一台 MacWindows 做不了 iOS 自动化、一个 Apple ID、一台 iOS 设备。第一步装 Xcode从 App Store 下就行装完打开一次同意协议。第二步获取 WebDriverAgent 源码。Appium 项目里带了 WDA路径在appium-webdriveragent目录下。或者直接用 Appium 的appium driver install xcuitest命令它会自动把 WDA 拉下来。第三步用 Xcode 打开WebDriverAgent.xcodeproj配置签名。在 Signing Capabilities 里Team 选你的 Apple IDBundle Identifier 改成一个唯一的字符串比如com.yourname.wda。然后选中 WebDriverAgentRunner target同样配置一遍。第四步部署到设备。选中 WebDriverAgentRunner scheme目标设备选你的 iPhone按 CmdU 运行测试。Xcode 会把 WDA 装到手机上并启动。第五步验证。手机上会看到一个无图标的 App 在运行Mac 上执行curl http://localhost:8100/status返回 JSON 里有state: success就说明 WDA 跑起来了。如果连不上先检查端口转发iproxy 8100 8100这个命令把设备的 8100 端口映射到 Mac 本地WDA 默认监听这个端口。提示iOS 16 以上版本需要在设置-隐私与安全性-开发者模式里手动开启开发者模式然后重启设备。这个开关藏得很深很多人卡在这一步WDA 装上了但连不上就是因为它。3.3 MCP Server 接入 AI 客户端设备侧跑通后把mobile-mcp接进 AI 客户端。以 Claude Desktop 为例编辑配置文件Mac 在~/Library/Application Support/Claude/claude_desktop_config.jsonWindows 在%APPDATA%\Claude\claude_desktop_config.json{ mcpServers: { mobile-mcp: { command: npx, args: [-y, mobile-mcp/server], env: { ANDROID_HOME: /Users/yourname/Library/Android/sdk, IOS_WDA_URL: http://localhost:8100 } } } }重启 Claude Desktop在对话框里输入列出当前连接的移动设备如果配置正确它会调用mobile-mcp的list_devices工具并返回设备列表。Cursor 的配置类似在 Settings 里找到 MCP 配置入口粘贴同样的 JSON 即可。不同客户端的配置路径不一样但核心就是command、args、env这三项。4. 典型自动化场景的落地实现4.1 跨端 UI 回归测试脚本假设你要验证一个登录流程在 iOS 和 Android 上都能正常走通。用mobile-mcp配合 Agent可以写一套逻辑同时跑两端。核心思路是Agent 拿到页面结构后根据元素的文本或 accessibility id 来定位而不是写死坐标。这样同一套逻辑在两端都能用因为两端元素的文本通常是一致的。实际操作时我会先让 Agent 做一次探索打开 App获取页面结构把可交互元素列出来。然后基于这份结构写操作序列。比如登录流程调用get_page_source获取当前页面找到文本为手机号的输入框调用tap聚焦调用input_text输入手机号同样方式输入密码找到登录按钮tap等待 2 秒get_page_source验证是否进入首页这套流程在 Android 和 iOS 上唯一的差异是输入框的定位方式。Android 上 UIAutomator 的 resource-id 通常比较规范iOS 上则更依赖 accessibility identifier。如果开发没加 accessibility id就只能靠文本定位稳定性会差一些。实操心得推动开发给关键元素加 accessibility identifier这是移动端自动化稳定性提升最明显的一招。加一个 id 的成本对开发来说几乎为零但对自动化脚本来说定位从猜变成了确定。4.2 结合 AI 的异常页面识别传统自动化脚本最怕遇到预期外的弹窗——广告、更新提示、权限申请。脚本按固定流程走遇到弹窗就卡死。mobile-mcp配合 AI 可以很好地解决这个问题。思路是每次操作前先截图把截图交给多模态模型判断当前页面是否有阻断性弹窗。如果有让模型决定点哪个按钮关闭它。这个判断逻辑用自然语言描述就行不需要写复杂的规则。实际配置时可以在 Agent 的系统提示里加一段每次执行操作前先调用 screenshot 工具获取当前屏幕。 如果屏幕上有弹窗、广告、权限申请等阻断性元素 优先找到关闭按钮通常是跳过、关闭、以后再说、允许并点击 然后再继续原定操作流程。这段提示词实测下来对常见的开屏广告、版本更新弹窗识别率很高。模型能理解跳过和立即更新的区别知道该点哪个。4.3 批量设备并行操作做兼容性测试时经常需要同时在多台设备上跑同样的操作。mobile-mcp支持通过device_id参数指定目标设备所以可以起多个 Agent 实例每个绑定一台设备。设备多了之后ADB 的端口管理要注意。每台 Android 设备通过adb devices拿到的序列号是唯一的直接用序列号指定即可。iOS 设备则要注意 WDA 端口冲突每台设备需要独立的 iproxy 端口映射iproxy 8101 8100 -u device1_udid iproxy 8102 8100 -u device2_udid然后配置里对应IOS_WDA_URL分别指向 8101 和 8102。设备数量建议方案注意事项1-2 台单机直连无需额外配置3-5 台多端口映射注意 USB 供电建议用带电源的 Hub5 台以上分布式部署每台 Mac 挂 2-3 台设备通过网络汇总结果5. 踩坑记录与问题速查5.1 高频问题排查表现象可能原因排查方向adb devices 显示 unauthorized手机未确认调试授权重新插拔确认手机弹窗input tap 无效果未开启安全调试/坐标错误检查开发者选项用截图验证坐标WDA 启动后 curl 无响应端口未转发/开发者模式未开检查 iproxy确认设备开发者模式截图返回黑屏视频版权保护/DRM 页面换普通页面测试DRM 页面无法截图元素定位失败accessibility id 缺失用文本定位兜底推动开发加 id操作后页面结构未更新动画未结束增加等待时间或显式等待元素iOS 输入中文乱码WDA 输入法问题改用粘贴方式或切换输入法5.2 那些文档里不会写的经验坐标系的坑。Android 的input tap用的是屏幕绝对坐标但不同分辨率设备坐标完全不同。iPhone 的 WDA 用的是点point而不是像素pixelRetina 屏上 1 点等于 2 或 3 像素。如果你从截图上量像素坐标直接传给 WDA位置会偏。正确做法是用页面结构里元素的坐标那是已经换算好的点坐标。输入法的坑。Android 上用input text输入中文会失败因为 ADB 的 input 命令不支持非 ASCII 字符。解决方案是装 ADB Keyboard通过广播的方式输入adb shell am broadcast -a ADB_INPUT_TEXT --es msg 你好iOS 上 WDA 的 sendKeys 对中文支持还行但遇到 emoji 偶尔会出问题。后台进程的坑。WDA 跑久了会内存泄漏连续跑几个小时可能就无响应了。我的做法是每跑 100 个用例重启一次 WDA虽然麻烦但稳定。Android 的 UIAutomator 相对稳定但 ADB 连接偶尔会断加个心跳检测断了自动重连。权限弹窗的坑。iOS 首次安装 App 后的权限弹窗通知、定位、相机WDA 默认处理不了因为那些弹窗属于系统层不在 App 的 UI 树里。需要用autoAcceptAlerts能力或者提前用xcrun simctl privacy预授权模拟器才行真机得手动点一次。6. 扩展玩法与个人体会mobile-mcp的价值不止于测试。我最近在用它做一些有意思的事情比如让 Agent 自动整理手机相册根据截图内容分类比如监控某个 App 的特定页面变化有更新就通知我比如批量处理手机上的重复操作像每天签到这类事情完全交给 Agent。还有一个方向是结合其他 MCP Server 做联动。比如mobile-mcp负责操控手机playwright-mcp负责操控浏览器两个配合可以做跨端的流程验证——手机上操作后去网页端确认数据同步是否正确。这种跨端联动的场景以前要写大量胶水代码现在通过 MCP 协议组合几个 Server 就能实现。我个人在实际操作中的体会是移动端自动化的核心难点从来不是怎么点而是怎么稳定地点。mobile-mcp把底层差异屏蔽掉之后稳定性问题就集中到了元素定位和等待策略上。把这两件事做好脚本的可靠性会有质的提升。另外别指望 AI 能完全替代人工判断它更适合做那些重复、规则明确的操作遇到复杂业务逻辑还是需要人来设计流程。把 AI 当成一个执行力很强但需要明确指令的助手这个定位比较准确。
阅读完成 · 觉得有帮助？
