移动端自动化这个方向过去几年一直有个尴尬的瓶颈脚本能点、能滑、能截图但一旦界面稍有变化整套流程就崩。传统方案靠控件树和固定坐标吃饭遇到动态渲染、自定义绘制、跨应用跳转就抓瞎。ARTEMIS 是谷歌开源的一套移动端 AI 自动化框架核心思路是把看屏幕、理解界面、决定下一步动作这件事交给多模态模型来做让 AI 助手像真人一样操作手机。它跟 MCPModel Context Protocol这套协议配合使用能把手机端的操作能力暴露给上层 AI 客户端。这篇内容适合三类人看正在做移动端自动化测试的工程师、想给自己的 AI Agent 接上操作手机能力的开发者、以及单纯好奇AI 到底怎么点手机的技术爱好者。我会从它解决什么问题讲起拆到架构、环境搭建、核心 API、实测踩坑尽量把能抄的作业都写清楚。1. 为什么控件树自动化在真实手机上越来越不够用1.1 传统移动端自动化的三条老路做移动端自动化的人基本都走过这三条路。第一条是UI Automator / Espresso这类原生框架靠 Accessibility 节点树定位元素稳定但只认自家应用跨应用就断。第二条是Appium本质还是包了一层 WebDriver 协议去驱动原生框架跨平台能力强但底层依然是控件树遇到 Flutter、Unity、游戏引擎自绘的界面节点树里全是空的或者一堆无意义的容器。第三条是图像识别 坐标点击用 OpenCV 模板匹配找按钮位置听起来万能实际上换个分辨率、换个主题色、加个动效就匹配不上。这三条路的共同问题是它们都假设界面是结构化的、可枚举的。可现实里的手机屏幕尤其是第三方 App界面是给人看的不是给机器读的。一个按钮可能是一张图片、一段 Canvas 绘制、一个 WebView 里的 div控件树里根本找不到它。1.2 多模态模型带来的范式转变ARTEMIS 的切入点很直接既然人靠眼睛看屏幕就能操作那让多模态模型也看屏幕不就行了。它把手机截图喂给视觉语言模型模型输出下一步该点哪里、该输入什么框架再把动作翻译成真实的触摸事件执行下去。这个循环不断重复就形成了感知—决策—执行的闭环。这个转变的意义在于定位方式从查节点变成了看画面。模型不需要知道那个按钮的 resource-id 是什么它只需要在截图里认出这是一个登录按钮然后给出坐标。界面改版、换皮肤、换语言只要人还能认出来模型大概率也能认出来。这就是它比传统方案更抗变化的地方。1.3 ARTEMIS 在谷歌内部要解决的场景从公开信息看这类框架要解决的是跨应用、长流程、需要理解语义的任务。比如打开某个 App搜索一个关键词把前三条结果的标题记下来这种任务横跨多个界面中间还有加载、弹窗、权限请求用固定脚本写会非常脆弱。而用模型驱动遇到弹窗可以判断这是要关掉的广告遇到加载可以判断还没好再等等。这种基于语义的容错能力是它区别于传统脚本的核心价值。2. ARTEMIS 的架构拆解截图、推理、执行三件事怎么串起来2.1 整体数据流ARTEMIS 的运行循环可以概括成一条链路截取当前屏幕 → 把截图和任务上下文一起送给模型 → 模型返回结构化动作 → 框架解析动作并在设备上执行 → 再次截图。这个循环一直跑到任务完成或者达到步数上限。这里有个关键设计模型返回的不是自由文本而是结构化的动作指令。常见动作类型包括点击带坐标、输入文本、滑动、返回、等待、任务完成。框架拿到这些指令后通过底层的设备控制通道Android 上通常是 ADB 或者设备端的自动化服务去执行。结构化输出是必须的否则模型说一句我觉得应该点登录框架没法解析。2.2 截图这一环的坑比想象中多截图看起来简单实际是整个链路里最容易被低估的部分。第一截图频率和延迟要平衡。截太勤设备卡、模型调用贵截太慢界面已经变了模型基于旧图做决策就会点错。第二截图分辨率要处理。手机原生分辨率可能是 1440x3200直接喂给模型既浪费 token 又可能超出模型输入限制通常要等比缩放到一个合理尺寸但缩放后坐标要能映射回真实屏幕坐标这个映射关系必须严格维护。第三敏感信息。截图里可能有通知、聊天内容、账号信息如果要把截图传到远端模型隐私处理是绕不开的问题。提示坐标映射是新手最容易翻车的地方。缩放比例、状态栏高度、导航栏高度、屏幕旋转任何一个没算对点击就会偏。建议在框架里单独写一个坐标转换模块所有点击都走它不要在各处手写换算。2.3 模型这一环提示词工程决定成败模型不是随便问就能干活的。ARTEMIS 这类框架的提示词通常包含几块任务描述你要干什么、当前截图现在屏幕上是什么、历史动作之前做过什么避免重复、可用动作列表你只能从这些动作里选、输出格式要求必须是 JSON 之类。历史动作这块特别重要。没有历史模型容易陷入死循环比如反复点同一个没反应的按钮。把我已经点过这个位置三次了告诉模型它就会换策略。另外动作空间要收窄。如果你告诉模型你可以做任何事它可能输出一些框架不支持的动作。明确列出可用动作能大幅降低解析失败率。2.4 执行这一环设备控制通道的选择Android 上执行触摸事件常见方案有几种。一是ADB 的 input 命令简单但延迟高不适合高频操作。二是设备端的 instrumentation 服务速度快但要装东西。三是Accessibility Service能拿到更丰富的信息但权限和合规要处理好。ARTEMIS 作为框架通常会抽象出一个设备控制层让上层不关心底层用哪种通道。选型时要考虑你的设备是模拟器还是真机、是否 root、是否允许装辅助服务。3. 把 ARTEMIS 跑起来环境准备与最小可运行示例3.1 前置条件清单在动手之前先把这些东西备齐缺一个都跑不起来一台 Android 设备或模拟器开启开发者模式和 USB 调试。模拟器推荐用带 Google API 的镜像兼容性好一些。ADB 工具能正常adb devices看到设备。Python 环境3.9 以上这类框架多数是 Python 写的依赖管理用 venv 或 conda 都行。一个可用的多模态模型接口可以是云端 API也可以是本地部署的模型。注意模型必须支持图像输入。网络能正常访问模型服务如果是云端接口注意调用配额和费用。3.2 安装与依赖处理假设框架以 Python 包形式提供典型安装流程是这样# 创建独立环境避免污染系统 Python python -m venv artemis-env source artemis-env/bin/activate # Windows 用 artemis-env\Scripts\activate # 安装框架本体 pip install artemis-framework # 安装设备控制相关依赖 pip install adbutils pillow装完之后先验证 ADB 连接adb devices # 应该看到类似 # List of devices attached # emulator-5554 device如果显示unauthorized去手机上确认 USB 调试授权弹窗。如果显示offline重启 ADB 服务adb kill-server adb start-server。3.3 一个最小任务让 AI 打开设置并进入关于页面下面这段是概念性的最小示例展示框架的典型调用方式。实际 API 名称以官方文档为准这里重点看结构from artemis import Agent, AndroidDevice from artemis.models import MultimodalModel # 1. 连接设备 device AndroidDevice(serialemulator-5554) # 2. 初始化模型客户端 model MultimodalModel( provideryour-provider, model_nameyour-vision-model, api_keyYOUR_KEY ) # 3. 创建 Agent绑定设备和模型 agent Agent( devicedevice, modelmodel, max_steps15, # 最多执行 15 步防止死循环 screenshot_scale0.5, # 截图缩放到 50%省 token ) # 4. 下发任务 result agent.run(打开系统设置找到关于手机页面读出系统版本号) print(result.summary) print(result.steps) # 打印每一步的动作方便调试跑起来之后你会看到终端里不断打印截图 → 模型返回动作 → 执行的日志。如果任务成功result.summary里会有模型总结的结果。3.4 第一次跑最容易卡在哪根据这类框架的通用经验第一次跑通常卡在三个地方。第一是模型接口报错多半是 API Key 没配好、模型名写错、或者模型不支持图像输入。第二是截图拿不到可能是 ADB 权限问题也可能是设备锁屏了记得先解锁。第三是动作执行没反应通常是坐标映射错了点到了屏幕外面。调试时建议把每一步的截图存下来人工看一眼模型到底看到了什么、点到了哪里比盯着日志猜快得多。4. 和 MCP 结合把手机操作能力暴露给上层 AI 客户端4.1 MCP 到底解决了什么问题MCP 是一套让 AI 客户端和外部工具/数据源对接的协议。你可以把它理解成AI 世界的 USB 接口只要工具按 MCP 规范实现任何支持 MCP 的客户端都能直接调用它不用为每个客户端单独写适配。ARTEMIS 如果实现了 MCP Server那么手机操作能力就变成了一个标准工具可以被各种 AI 助手调用。这个组合的价值在于解耦。以前你要做一个AI 帮我操作手机的产品得把模型调用、设备控制、任务编排全写在一起。现在 ARTEMIS 负责设备控制和视觉推理MCP 负责把能力标准化暴露出去上层客户端只负责决定要做什么。各层职责清晰替换任何一层都不影响其他层。4.2 MCP Server 的典型工具设计一个移动端自动化的 MCP Server通常会暴露这几类工具工具名作用关键参数screenshot获取当前屏幕截图设备 ID、是否缩放tap在指定坐标点击x、y、设备 IDswipe滑动操作起点、终点、时长input_text输入文本文本内容run_task下发一个自然语言任务由 Agent 自主完成任务描述、最大步数get_ui_tree获取控件树辅助用设备 ID注意run_task和tap的区别前者是高层任务把决策权交给 Agent后者是底层动作由上层客户端自己决定点哪里。两种模式各有用途高层适合复杂任务底层适合精确控制。4.3 配置 MCP 连接的实操要点在支持 MCP 的客户端里配置 ARTEMIS Server一般要填两块信息启动命令和环境变量。启动命令告诉客户端怎么把 Server 拉起来环境变量里放设备序列号、模型 API Key 这些敏感信息。{ mcpServers: { artemis-mobile: { command: python, args: [-m, artemis.mcp_server], env: { ARTEMIS_DEVICE_SERIAL: emulator-5554, ARTEMIS_MODEL_API_KEY: YOUR_KEY, ARTEMIS_MAX_STEPS: 20 } } } }配置完重启客户端如果连接成功工具列表里应该能看到上面那些工具。连不上时先手动在终端跑一遍启动命令看有没有报错比在客户端里瞎猜高效。4.4 什么时候该用 MCP什么时候不该用MCP 不是万能的。如果你的场景是固定流程、高频执行比如每天定时跑一遍回归测试那用传统脚本更稳更省。MCP 模型的方案适合流程不固定、需要语义理解、界面经常变的场景。另外模型调用有延迟和成本如果任务对响应时间敏感也要慎重。我的经验是把 MCP 方案用在探索性任务和容错要求高的长流程上把传统脚本用在确定性任务上两者混用往往是最优解。5. 实测中那些文档不会写的坑5.1 模型看错和幻觉点击多模态模型不是万能的它会看错。常见表现是把相似的图标认错、把灰色不可点的按钮当成可点、在复杂界面里找不到目标。更麻烦的是幻觉点击——模型信誓旦旦地说我看到了登录按钮在 (500, 1200)但那个位置其实是空白。应对办法有几个。一是让模型输出置信度和理由比如我认为这是登录按钮因为上面有登录两个字理由不合理就人工介入。二是动作后验证点完之后再截一张图对比界面是否如预期变化没变化就重试或换策略。三是设置重试上限同一个动作连续失败三次就放弃并报错别让它无限循环烧钱。5.2 动态界面和动画的干扰手机界面大量存在动画页面切换动画、加载转圈、下拉刷新回弹。如果在动画进行中截图模型看到的是模糊的中间态决策就会错。解决办法是截图前等待界面稳定。简单做法是连续截两张图如果两张几乎一样认为界面稳定了再送模型。这个稳定检测逻辑很值得写能省掉大量莫名其妙的失败。5.3 输入法这个老大难输入文本是移动端自动化的经典坑。用 ADB 的input text命令输入中文经常乱码因为 ADB 对非 ASCII 字符支持不好。常见绕法有用 ADBKeyBoard 这类第三方输入法、通过剪贴板粘贴、或者用设备端的 instrumentation 直接 setText。ARTEMIS 这类框架通常会封装一个可靠的输入方法但你要知道底层可能踩过这些坑遇到输入失败时往这个方向排查。5.4 成本和速度的现实考量模型调用是要花钱的而且有延迟。一个稍微复杂的任务跑几十步很正常每步一次模型调用成本累积起来不低。优化方向降低截图分辨率token 少、精简提示词别塞无关上下文、用更小的模型做简单判断比如判断界面是否加载完不需要大模型、缓存不变的部分。实测下来截图缩放和提示词精简这两项能省掉相当一部分开销。6. 从能跑到好用几个提升稳定性的工程手段6.1 动作空间的设计要克制给模型的动作越多它越容易选错。建议只暴露当前任务真正需要的动作。比如一个填表单的任务可能只需要 tap、input_text、scroll 三个动作那就别把 swipe、long_press 都给它。动作空间小模型决策更聚焦解析失败率也低。6.2 用检查点拆分长任务一个长任务跑几十步中间任何一步出错都会导致整体失败而且很难定位是哪一步的问题。更好的做法是把长任务拆成若干检查点每个检查点有明确的成功判据。比如打开 App 并登录可以拆成App 启动成功、进入登录页、输入账号、输入密码、点击登录、进入首页。每个检查点单独验证失败了只重跑这一段不用从头来。6.3 日志和回放机制调试 AI 自动化日志是命根子。每一步至少要记录截图文件路径、模型输入、模型输出、执行的动作、执行后的截图。有了这些出问题时可以完整回放整个决策过程一眼看出是模型看错了还是执行错了。建议把日志按任务 ID 分目录存方便事后分析。6.4 人工兜底通道再好的自动化也有搞不定的时候。设计时留一个人工介入的接口当 Agent 连续失败、或者遇到需要验证码/生物识别的环节暂停并通知人工处理处理完再继续。这个设计在真实业务里几乎是必须的纯自动化的方案在遇到风控和验证环节时很容易卡死。7. 这类框架适合谁以及我对它的判断7.1 三类典型适用人群第一类是移动端测试工程师尤其是做跨应用、长流程测试的。传统脚本维护成本高用模型驱动能显著降低因界面改版导致的脚本失效。第二类是AI Agent 开发者想给自己的助手加上操作手机这个能力ARTEMIS MCP 是一条现成的路。第三类是做 RPA 的团队移动端 RPA 一直是个难点视觉方案提供了新思路。7.2 它现在还不太适合的场景如果你的需求是毫秒级响应、超高频执行、对成本极度敏感那模型驱动的方案目前还不划算。另外涉及金融支付、敏感数据的场景把屏幕截图传给远端模型有合规风险要谨慎评估。还有纯游戏操作这类对时序要求极高的场景模型推理的延迟也扛不住。7.3 我个人的使用体会我用下来最大的感受是这类框架的价值不在于替代脚本而在于处理脚本处理不了的那部分。把确定性的、高频的部分留给传统脚本把需要理解、需要容错的部分交给 AI两者配合整体稳定性反而比纯 AI 或纯脚本都高。另外提示词的质量对结果影响极大同一个任务提示词写得好和写得差成功率能差出一大截。这块值得花时间打磨比换模型带来的提升还明显。最后分享一个实用的小技巧调试阶段把max_steps设小一点比如 5 到 8 步先确认前几步的决策是对的再逐步放开。一上来就设 50 步跑飞了你都不知道从哪一步开始错的。等前几步稳定了再让它跑完整流程这样排查效率高很多。