人工智能AI AgentMCP 服务GUI 自动化移动开发测试【免费下载链接】mobile-mcpModel Context Protocol Server for Mobile Automation and Scraping (iOS, Android, Emulators, Simulators and Real Devices)项目地址https://gitcode.com/GitHub_Trending/mo/mobile-mcp点击查看免费下载mobile-mcp是一个面向移动自动化与数据采集的 Model Context ProtocolMCPServer它让 LLM/Agent 通过统一的mobile_*工具集直接驱动 iOS/Android 模拟器、模拟器和真机。本篇文章以仓库中 test/prompt-android-emulator.md 这份**验收测试 PromptAcceptance Test Prompt**为主体逐行拆解它如何对一个 Android 模拟器上的完整用户旅程进行端到端验证并对照 src/server.ts、src/mobile-device.ts、test/validate-response.js 等源码说明每一步背后对应的 MCP 工具、底层调用链与 Agent 应遵循的操作范式。读完本文你将掌握如何读懂并复现这类全流程 Agent 验收测试、如何约定严格的 JSON 输出契约、以及如何用 accessibility-first 的思维方式在真实设备上完成启动应用 → 断言前台 → 导航 → 输入 → 滑动 → 校验的自动化闭环。一、这份文档是什么一份驱动 Agent 执行设备测试的验收 Prompttest/prompt-android-emulator.md是一份完整的验收测试指令它的读者不是人类工程师而是一个正在接受测试的 AI Agent。其结构非常典型分为两个部分输出契约Output Contract前 6 行严格规定了 Agent 的最终响应格式要求返回一个 JSON 对象包含pass、error可选、steps三个字段并且整段响应只能是该 JSON——不允许前置摘要、不允许后置评论、不允许 Markdown 代码围栏要求响应的第一个字符是{最后一个字符是}。测试场景test块第 831 行以命令式自然语言描述了 15 个环环相扣的验收步骤覆盖设备唯一性断言、应用安装/启动/终止、前台应用断言、HOME 键导航、截图落盘与校验、屏幕元素断言、文本输入、滑动操作等。这份文档与同目录的 test/prompt-ios-simulator.md 构成一对平台对称的验收用例后者针对 iOS 模拟器维基百科取词、备忘录 App 添加提醒、NASA 每日一图截图讲解前者针对 Android 模拟器。二者共享完全相同的 JSON 输出契约说明这是项目为Agent 能否正确、稳定地操控移动设备设计的一套可机检的自动化评估体系。二、JSON 输出契约为什么 Agent 的回答必须只含一个 JSON文档前 6 行是整个测试能否被机器判定的基石。Agent 的最终响应必须满足顶层是一个 JSON 对象pass布尔值测试全部通过为true失败为falseerror仅当失败时给出的人类可读问题描述steps字符串数组记录 Agent 为达成任务所执行的每一步并且必须在步骤中提及使用了哪些 MCP 工具。这个契约并非空话仓库里 test/validate-response.js 就是它的裁判。该脚本读取标准输入fs.readFileSync(0, utf8)然后用findMatchingBrace做带字符串转义感知的花括号配对找出文本中所有候选 JSON 对象test/validate-response.js用findLastJsonObject取最后一个能够成功解析的 JSON 对象——这样设计是因为Agent 偶尔会把结论包在散文或代码围栏里脚本会宽容地只取最后的合法 JSONtest/validate-response.js最后校验response.pass true且steps是数组否则以非零退出码报错test/validate-response.js。从源码可见只输出 JSON这条纪律是为了让验证逻辑足够简单、无歧义、可自动化而宽容解析则是为了在实际运行中减少因格式小瑕疵导致的误判。这一点对任何想要构建LLM 作为测试执行者流水线的团队都有直接借鉴价值。三、测试前置为什么必须只有一个 Android 模拟器测试第 1 步要求断言当前只连接了一个 Android 模拟器。这是一个环境不变量environment invariant后续所有操作都基于唯一设备这一前提避免 Agent 因多设备而选错deviceId。在 mobile-mcp 中这一步对应mobile_list_available_devices工具。从 src/server.ts 起注册了该工具其底层经由Mobilecli类的getDevices()执行mobilecli devices命令src/mobilecli.ts返回结构化的设备列表其中每个设备包含id、name、platformandroid/ios、typereal/emulator/simulator、version、stateonline/offline。getDevices还支持--platform、--type、--include-offline过滤参数Agent 可以用它们精确筛选唯一的、android、emulator、online的设备。与之呼应仓库的 Playwright 设备测试在 test/android.ts 中做了完全相同的环境前置AndroidDeviceManager.getConnectedDevices()得到设备列表devices.length 1才运行测试否则test.skip跳过。这印证了单设备前置是 Android 设备自动化测试的一致约定。四、应用管理链路list → terminate → launch → foreground 断言测试第 26 步构成一条完整的应用生命周期验证链列出已安装应用断言com.mobilenext.playground已安装若该应用正在运行先终止它启动com.mobilenext.playground断言该应用位于前台按 HOME 键断言它不再位于前台而是回到了桌面启动器。4.1 对应 MCP 工具这条链路在 mobile-mcp 中一一对应四个工具测试步骤MCP 工具参数底层命令列出已安装应用mobile_list_appsdeviceapps list终止运行中的应用mobile_terminate_appdevice,packageNameapps terminate启动应用mobile_launch_appdevice,packageName,locale?apps launch查询前台应用mobile_get_foreground_appdeviceapps foreground其中mobile_launch_app支持可选locale参数逗号分隔的 BCP 47 标签如fr-FR,en-GB用于以指定语言环境启动应用src/server.ts。4.2 源码级验证这些工具最终都由MobileDevice类实现Robot接口转发给 mobilecli 二进制listApps()调用mobilecli apps list --device id并把响应中appName || packageName统一成InstalledAppsrc/mobile-device.tslaunchApp()构造apps launch package [--locale locale]src/mobile-device.tsterminateApp()构造apps terminate packagesrc/mobile-device.tsgetForegroundApp()解析apps foreground的 JSON 响应返回packageName与appNamesrc/mobile-device.ts。MobileDevice.runCommand会把--device deviceId追加到每个命令尾部src/mobile-device.ts所以 MCP 工具层的device参数贯穿了所有调用。HOME 键操作对应mobile_press_button工具button支持BACK仅 Android、HOME、VOLUME_UP/DOWN、ENTER以及一组 Android TV 专用按键src/server.ts底层由pressButton()调用io button buttonsrc/mobile-device.ts。同源测试 test/android.ts 也做了同样的 launch/terminate 断言launchApp(com.android.chrome)后listRunningProcesses()应包含该包名terminateApp后应不再包含。这证明启动 → 校验进程存在 → 终止 → 校验进程消失是仓库自带的官方验证范式。五、截图链路落盘、PNG 有效性、分辨率与文件体积校验测试第 79 步要求再次启动应用并保存截图到delete-me.png断言delete-me.png在本地磁盘上创建成功且是合法的 PNG尺寸至少 512×512 像素、体积至少 50KB删除delete-me.png。5.1 工具与参数落盘截图对应mobile_save_screenshot核心参数saveTo必须以.png、.jpg或.jpeg结尾、maxSize最长边像素上限等比缩放、scale0.0~1.0 缩放系数与maxSize互斥maxSize优先。saveTo的扩展名决定了输出格式.png输出 PNG其余输出 JPEGsrc/server.ts。调用前会经validateFileExtension与validateOutputPath双重校验src/server.ts。内存截图对应mobile_take_screenshot它默认以 JPEG质量 75返回默认maxSize为 1024DEFAULT_SCREENSHOT_MAX_SIZEsrc/server.ts并会额外返回一段截图尺寸 → 屏幕坐标的映射说明文本帮助 Agent 把截图里看到的坐标换算成可点击的屏幕坐标src/server.ts。5.2 底层实现MobileDevice.getScreenshot()构造mobilecli screenshot --device id --format fmt --output -支持--qualityJPEG 质量、--max-size、--scale通过executeCommandBuffer以 Buffer 方式接收二进制数据src/mobile-device.tssrc/mobilecli.ts。PNG 合法性校验在本仓库中有专门实现测试 test/android.ts 用new PNG(screenshot)解析截图断言其getDimensions()恰好等于getScreenSize()返回的屏幕尺寸——即截图必须是合法且与屏幕同尺寸的 PNG。仓库根目录还有对应的 src/png.ts 与 src/jpeg.ts 模块分别负责 PNG 尺寸解析与 JPEG 尺寸解析正是mobile_take_screenshot校验返回图片尺寸的依据src/server.ts。对于删除文件这类本地文件操作MCP 工具集没有提供专门的删除工具Agent 通常通过宿主环境的文件系统能力完成这与文档中delete-me.png 是临时产物、测试后应清理的意图一致。六、视觉断言用截图确认一红一绿两部手机的界面测试第 10 步要求截取一张截图并断言屏幕顶部有一张看起来像两部手机、一红一绿的图片。这是典型的视觉内容断言场景——普通的 accessibility tree 无法表达图片的视觉语义颜色、图形必须回退到mobile_take_screenshot。仓库 skills/mobile-automation/SKILL.md 对这一点有明确指引优先调用mobile_list_elements_on_screen返回带标签与坐标的 accessibility tree更快、更便宜、更可靠只有当元素缺失或需要视觉确认游戏、Canvas 绘制的 UI、图片内容时才回退到mobile_take_screenshot。这与 README 中Accessibility-first——从原生 accessibility tree 驱动应用无视觉模型、无图像 token仅在必要时回退截图坐标的设计哲学完全一致README.md。因此第 10 步恰好示范了何时必须用视觉而非结构的边界条件涉及图片色彩与形状的内容mobile_list_elements_on_screen无法回答Agent 必须读取截图并描述画面。七、元素交互链路Basic UI、Toggle、BACK 导航与输入框测试第 1115 步是最核心的 UI 交互验证点击Basic UI按钮断言屏幕上出现名为Toggle的元素按 BACK 返回主菜单再次点击Basic UI断言可见标签为Text Field的文本输入框、Password密码框、Multiline text多行文本框点击第一个文本输入框并输入Hello World重新列出元素并断言输入已生效向上滑动断言Text Field不再可见但出现了一个日期选择器date selector。7.1 工具映射测试步骤MCP 工具关键参数点击 Basic UImobile_click_on_screen_at_coordinatesx,y或ref断言元素存在mobile_list_elements_on_screenformattext/json按 BACKmobile_press_buttonbutton: BACK输入文字mobile_type_keystext,submit向上滑动mobile_swipe_on_screendirection: up, 可选x/y/distance7.2 点击ref 优先于坐标mobile_click_on_screen_at_coordinates支持两种目标元素 ref来自最近一次mobile_list_elements_on_screen形如e5或绝对坐标x/y。文档语义上ref优先于坐标——传入ref时直接调用tapByRef否则要求x、y必须同时提供src/server.ts。底层tap()会把坐标Math.round成整数因为 mobilecli 拒绝小数坐标src/mobile-device.ts。SKILL.md 还专门提醒点击元素包围盒的中心而不是左上角skills/mobile-automation/SKILL.md。7.3 元素列表与断言mobile_list_elements_on_screen返回带ref、坐标、显示文本或无障碍标签的元素列表format参数支持 text默认每元素一行紧凑输出与 json 两种格式src/server.ts。底层getElementsOnScreen()解析mobilecli dump ui的 JSON并通过flattenUIElement把嵌套的 accessibility tree递归扁平化为平面元素数组src/mobile-device.tssrc/mobile-device.ts。每个ScreenElement携带type、label、text、name、value、identifier、rect、ref、focused、selected、checked、enabled等字段足以为标签为 Text Field / Password / Multiline text 的输入框这类断言提供结构化依据。注意工具描述中的一条纪律ref 与坐标只要屏幕不变就保持有效仅在导航或布局变化后重新列出元素src/server.ts。这正好对应第 11 步点击 Basic UI 后必须重新 list 元素才能断言 Toggle的流程——每次界面变化后都要刷新元素快照。7.4 文本输入先聚焦再输入后验证第 14 步点击第一个文本输入框 → 输入 Hello World → 重新列出元素断言已输入完整遵循了 SKILL.md 的输入范式先点击输入框、确认其获得焦点再mobile_type_keysskills/mobile-automation/SKILL.md。mobile_type_keys的text参数传入待输入文本submit为布尔值置true时输入后自动追加 ENTER 键src/server.ts。输入框元素本身带有focused字段可用于确认焦点状态。7.5 滑动与元素不再可见的断言第 15 步要求向上滑动后Text Field 不再可见、取而代之出现日期选择器。mobile_swipe_on_screen的direction支持up/down/left/right若不传起点坐标则默认从屏幕中心开始distance默认为 400 像素iOS或屏幕短边的 30%Androidsrc/server.ts。底层MobileDevice.swipe()以屏幕中心为中点、400 像素为默认距离计算起止点并调用io swipe x1,y1,x2,y2src/mobile-device.ts带起点的swipeFromCoordinate()则从给定坐标沿方向移动指定距离src/mobile-device.ts。向上滑动 → 断言旧元素消失、新元素出现是一个经典的滚动校验模式Agent 必须在滑动后再次mobile_list_elements_on_screen通过重新抓取元素快照来证明界面确实发生了变化——这正是 SKILL.md 强调的每次操作后都要验证Verify after every action原则移动端 UI 有动画期望元素未出现时应短暂等待再检查而不是盲目点击skills/mobile-automation/SKILL.md。八、批量编排mobile_batch_commands 与多步流程加速值得注意的是本仓库为填表、多步流程提供了专门的批量工具mobile_batch_commands一次调用内按顺序执行多个工具如 click、type、click、typesteps数组中每个元素包含name与argumentsdevice参数自动应用到每个步骤除非该步骤自带stopOnError默认true失败即停listElementsAtEnd可在最后自动追加一次元素列举并附上结果src/server.ts。从实现看批量执行直接调用注册在toolCallbacksMap 里的回调函数绕过 MCP 传输层src/server.ts并且禁止嵌套mobile_batch_commands、禁止在批量内使用mobile_take_screenshot因为它的返回是图片无法在批量文本输出中呈现须改用mobile_save_screenshotsrc/server.ts。这套设计在验收测试文档所描述的场景中非常实用——例如第 1115 步的点击 → 断言 → 返回 → 点击 → 输入序列Agent 完全可以在条件允许时用一次mobile_batch_commands完成编排再单独用listElementsAtEnd: true拿到最终界面快照。九、在本地复现与运行测试基础设施虽然test/prompt-android-emulator.md是给 Agent 的 Prompt但仓库提供了完整的本地测试骨架帮助你理解这套验收测试的运行环境playwright.config.ts 把 Playwright 仅用作测试运行器不启动浏览器testDir指向./test、testMatch: *.tsworkers: 1且fullyParallel: false——因为设备测试会真实改变设备状态必须串行执行timeout: 60_000是因为设备操作包含多处数秒等待playwright.config.ts。test/android.ts 是同一能力的 Playwright 断言实现屏幕尺寸、截图 PNG 校验、列应用、打开 URL、列元素、sendKeys 与 tap、启动/终止、横竖屏切换均要求恰好一台 Android 设备test.skip(!hasOneAndroidDevice, ...)。test/validate-response.js 负责对 Agent 的 JSON 响应做机检。对照可见文档描述的验收流程与test/android.ts的测试矩阵高度同构——getScreenSize/getScreenshot/listApps/getElementsOnScreen/sendKeys/tap/launchApp/terminateApp正是验收 Prompt 每一步所依赖的能力。换句话说这份 Prompt 是用自然语言包装起来的、由 LLM 驱动的端到端测试而 Playwright 测试是同一份验收标准的过程式实现两者互为镜像。十、对 Agent 开发者的实战启示综合全文从这份验收测试文档中可以提炼出在移动自动化 Agent 开发中直接可复用的四条规范输出契约先行凡是Agent 作为测试执行者的场景都应像本文档一样先定义严格的 JSON 契约pass/error/steps并配套 test/validate-response.js 这类宽容但严谨的解析校验器做到失败可定位、步骤可追溯。环境不变量前置所有操作开始前先断言设备唯一性mobile_list_available_devices从根源上消除多设备歧义这与 test/android.ts 的devices.length 1检查一致。Accessibility-first视觉兜底默认用mobile_list_elements_on_screen获取结构化的 accessibility tree带 ref 与坐标只有遇到图片色彩/形状等结构无法表达的内容如一红一绿两部手机才切换mobile_take_screenshot。操作后必验证每一次点击、滑动、输入之后都要重新 list 元素或截图确认界面如预期变化后再进入下一步App 生命周期操作launch/terminate/前台断言/HOME 返回要与 UI 断言穿插进行构成完整的闭环。这份验收测试文档本身就是移动自动化 Agent 能力的一次全链路体检而 mobile-mcp 的工具集与源码让这份体检的每一个环节都有了可查证、可复现的实现支撑。赞分享人工智能AI AgentMCP 服务GUI 自动化移动开发测试【免费下载链接】mobile-mcpModel Context Protocol Server for Mobile Automation and Scraping (iOS, Android, Emulators, Simulators and Real Devices)项目地址https://gitcode.com/GitHub_Trending/mo/mobile-mcp点击查看免费下载相关推荐Baserow MCP 端点手动测试全指南从连接客户端到验证工具清单Baserow MCP 端点手动测试全指南从连接客户端到验证工具清单 Baserow 通过 Model Context ProtocolMCP向 Clau后端前端数据库低代码工作流自动化浏览器自动化测试革命AI驱动的一站式端到端验证平台浏览器自动化测试革命AI驱动的一站式端到端验证平台 还在为繁琐的浏览器测试而烦恼每次发布前都要手动检查性能、SEO、可访问性browser tools m人工智能AI Agent浏览器控制开发工具最完整MCP客户端测试指南从手动验证到自动化全流程实践最完整MCP客户端测试指南从手动验证到自动化全流程实践 你还在为MCP客户端测试效率低下而烦恼本文将系统介绍MCPModel Context Protoc教程文档人工智能创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考