mobile-mcp:用原生无障碍树驱动真机的移动自动化 MCP 服务器

一句话定位

mobile-mcp(mobile-next/mobile-mcp, 8,216★ / 712 fork, TypeScript, Apache-2.0, 官网 mobilenext.ai)是一个 MCP server, 让 AI agent 与 LLM 通过一套平台无关的接口去操作原生 iOS / Android 应用与设备——模拟器、仿真器、真机都算。README 的副标题写得很直白: 不再需要分别懂 iOS 和 Android。它明确列出可用客户端: Claude Code、Codex、Gemini、GitHub Copilot、Antigravity, 或任何支持 MCP 的客户端。

用户问「这个应该采集到 agientry 的哪个板块」——答案是 AI 编程(code)域为主, agents 域为辅。理由不是它跟代码有关, 而是它的消费者是编码 harness: 它本身不训模型、不做 agent 循环, 它做的事是把「一台手机」变成编码 agent 工具面上的一个工具组。你在 Claude Code 或 Codex 里 mcp add 一行, 那个编码 agent 立刻就能开真机、点界面、读崩溃日志。同时它跑的是长程多步跨应用任务, 这天然是 agents 域(多步工具调用、操作系统任务、长程自主执行)的证据, 所以两个域都挂。

数据面

项	值
仓库	mobile-next/mobile-mcp
Stars / Forks	8,216 / 712
语言 / 协议	TypeScript / Apache-2.0
形态	MCP server(stdio)+ Streamable HTTP server(--listen)
目标设备	iOS 模拟器、iOS 真机(USB 且已信任)、Android 仿真器、Android 真机(adb + USB 调试已授权)
依赖	Xcode command line tools、Android Platform Tools、Node.js v20+
安装	npx -y @mobilenext/mobile-mcp@latest; 各客户端一行命令: claude mcp add / codex mcp add / gemini mcp add / amp mcp add, Cursor 有 deeplink 一键装, VS Code 与 Goose 有安装徽章
topics	agent, android, emulator, ios, mcp, mobile, physical, real, simulator

核心设计: accessibility-first, 而不是「让视觉模型看截图」

这是整个项目最要紧的一个决定, README 把它放在特性列表第一条: 从原生无障碍树(accessibility tree)驱动应用, 不用视觉模型, 不花图像 token, 只在必要时才回落到「截图 + 坐标点击」。配套的一句是结构化、确定性输出: 它读的是真实 UI 元素, 带坐标与属性, 因此消掉了纯截图方案的歧义。

为什么这件事在成本上是决定性的:

路线	每一步的代价	元素身份	失败模式
纯截图 GUI agent	每步都要喂一张图, 图像 token 随步数线性累积	靠视觉推断, 同一个按钮两次识别可能不同	坐标漂移、误点、长任务里 token 成本失控
mobile-mcp(无障碍树优先)	结构化文本, 便宜; 只有必要时才截图	平台给出的真实元素与其属性、坐标	依赖应用自身的无障碍标注质量; 标注差时才需要视觉回落

与本站已有条目对照着看会更清楚: zai-org/Open-AutoGLM(26,321★)是「手机 agent 模型」路线——训一个会看屏幕的模型; zai-org/CogAgent 是 VLM 做 GUI agent 的早期同类; joshhhhhan/VISTA 更极端, 直接从原始像素玩 ARC-AGI-3。mobile-mcp 走的是相反方向: 它一个模型都不训, 而是让操作系统把界面结构直接交出来。三条路线并不互斥, 现实里的强弱取决于目标应用的无障碍标注有多完整; 但在「每一步的成本」这把尺子上, 结构化路线是压倒性便宜的, 这也是它能被写进日常编码 harness 而不是只待在实验室的前提。

工具面: 约 30 个 MCP 工具, 七组

组	工具
设备管理	mobile_list_available_devices(列模拟器/仿真器/真机)、mobile_get_screen_size、mobile_get_orientation / mobile_set_orientation、mobile_set_location(覆盖或清除 GPS)、mobile_clipboard(读或替换剪贴板)
远程设备(Mobile Next Cloud)	mobile_login_to_cloud_provider(浏览器 device-code 登录)、mobile_list_remote_devices(列可预约机型)、mobile_allocate_remote_device(独占预约一台云真机)、mobile_release_remote_device(归还)
应用管理	mobile_list_apps、mobile_get_foreground_app、mobile_launch_app(按包名)、mobile_terminate_app、mobile_install_app(.apk / .ipa / .app / .zip)、mobile_uninstall_app
屏幕交互	mobile_take_screenshot、mobile_save_screenshot、mobile_list_elements_on_screen(带坐标与属性的元素列表)、mobile_click_on_screen_at_coordinates、mobile_double_tap_on_screen、mobile_long_press_on_screen_at_coordinates、mobile_swipe_on_screen(四向)、mobile_start_screen_recording / mobile_stop_screen_recording(录成视频文件)
输入与导航	mobile_type_keys(向焦点元素输入, 可选自动提交)、mobile_press_button(HOME / BACK / VOLUME_UP / VOLUME_DOWN / ENTER 等硬件键)、mobile_open_url(在设备浏览器打开 URL, 即 deep link 入口)
日志与崩溃	mobile_get_device_logs(Android logcat / iOS unified log, 可落文件)、mobile_list_crashes、mobile_get_crash(按 id 取完整崩溃报告)
批处理	mobile_batch_commands(一次调用里顺序跑多个工具, 例如 click → type → click, 并可在结束时顺带列出屏幕元素)

两个最容易被忽略但最影响体验的工具: mobile_batch_commands 把 N 次 agent 往返压成 1 次, 对「点一下、输入、再点一下」这种固定序列, 省的是每步一轮模型推理的延迟; mobile_get_crash / mobile_get_device_logs 才是它属于「开发」而不只是「自动化」的原因——agent 改完移动端代码、装包、跑一遍、崩了、直接把崩溃报告读回来继续修, 这条闭环在同一个工具面里就能走完。

实际被拿来做什么: 跨应用长程任务

README 给的示例 prompt 不是「点这个按钮」, 而是多应用、多步、带验证回路的完整旅程, 摘几条原文场景:

• 找到一个叫「Beginner Recipe for Tonkotsu Ramen」的视频, 点赞, 写评论「this was delicious, will make it next Friday」, 再分享给 WhatsApp 通讯录里的第一个联系人。
• 找一个 1k+ 星的免费 Pomodoro 应用并下载, 用我的邮箱注册, 注册后找到怎么启动番茄钟, 计时开始后回到应用商店给它打 5 星并留言。
• 打开 Substack 搜「Latest trends in AI automation 2025」, 开第一篇, 高亮「Emerging AI trends」那一节, 存进稍后读, 再对随机一段写摘要评论。
• 打开 ClassPass, 搜 2 英里内明早的瑜伽课, 订 7 点评分最高的那节, 确认预约, 再在手机上给这个时段建一个计时器。
• 打开 Eventbrite, 搜本周末 Austin, TX 的 AI startup meetup, 选最热门的那个报名并 RSVP yes, 建日历事件做提醒。
• 查柏林明天的天气, 把摘要经 WhatsApp / Telegram / Slack 发给指定联系人, 并给对方的回复点个赞。
• 在 Zoom 里排一个明天 10 点、时长 1 小时、标题「AI Hackathon」的会议, 复制邀请链接, 用 Gmail 发给指定收件人。

这些例子的共同形状是: 跨多个应用 + 每步都要确认上一步成功了 + 中间有搜索与筛选判断。恰好是「每步一张截图」的路线最烧钱的形状, 也恰好是结构化元素输出能把它变便宜的形状——这不是巧合, 是 accessibility-first 这个决定选出来的用例分布。

工程与安全旋钮

环境变量	作用	为什么它重要
MOBILEMCP_AUTH	给 Streamable HTTP server(--listen)加 Bearer token, 之后每个请求都必须带 Authorization: Bearer <token>	一旦以 HTTP 方式暴露, 就等于把「操作一台真机」的能力放到网络上; 没有鉴权不能开
MOBILEMCP_DISABLE_TELEMETRY	关闭匿名遥测(PostHog + Scarf)	企业内网与合规环境的硬要求
MOBILEMCP_ALLOW_UNSAFE_URLS	允许 mobile_open_url 打开非标准 URL scheme, 默认拦截	agent 驱动的设备上, deep link 是一条真实的攻击面(拉起任意应用与私有 scheme); 默认拒绝是对的
MOBILEMCP_LEGACY_ROBOT	Android 设备与 iOS 真机改用旧的平台专用 robot 实现, iOS 模拟器仍走 mobilecli	兼容逃生口, 说明底层已经统一到 mobilecli

隐私口径写得很干净: mobile-mcp 在本地运行, 只与你连接的设备通信。没有真机时可以在后台跑模拟器/仿真器(headless): Android 用 avdmanager 或 emulator 起一个, iOS 先 xcrun simctl list 再 xcrun simctl boot "iPhone 16"。

它在 Mobile Next 这套工具链里的位置

• mobilecli: 通用设备 CLI, mobile-mcp 就是建在它上面的。命令行或 JSON-RPC API 都能控设备、模拟器与仿真器——也就是说 MCP 只是它的一个前端, 底层能力不依赖 MCP 存在。
• mobilewright: 自称「Playwright for mobile」。官方给的路径很明确: 用 agent 探索完之后, 当你需要把这套流程变成可重复、确定性的 iOS/Android 测试时, 升级到 mobilewright。探索用 mobile-mcp, 固化用 mobilewright。
• Mobile Next Cloud: 同一套栈的云租版本, 按需拿真机。有意思的是接入方式——你直接对 agent 说「log in to mobile next cloud and then show me which remote devices are available to me」, 由 agent 自己调那四个 remote 工具完成登录与列机型。工具面本身变成了产品的入口。

本站判断

三条:

• 它是「工具面」而不是「模型」, 所以该进 code / agents 域, 不该进 llm 域。判据与本站 llm 域那句「换掉它, 模型的智力或每 token 成本会变」对照: 换掉 mobile-mcp, 模型一点没变, 变的是模型能够到哪些设备。
• 它的杠杆来自「让平台交出结构」, 这是移动端 agent 目前最被低估的一条路。视觉路线的进展会持续压低它的重要性, 但只要无障碍树在, 结构化路线在成本与确定性上就一直占优, 而成本决定了它能不能进日常 CI 而不是只进 demo。
• 它与本站 code 域已有的 GLips/Figma-Context-MCP 是同一类资产的两个方向: 一个把设计上下文交给编码 agent, 一个把移动设备交给编码 agent。两者都不是 agent, 都是给 agent 加一条新的现实接口——这类 MCP 工具面正在成为 AI 编程赛道里增长最快的一层, 值得作为独立小节持续跟。