1. 移动端 AI 自动化的破局点ARTEMIS 到底解决了什么问题移动端自动化测试和操作一直是个让人又爱又恨的领域。爱的是它确实能省下大量重复劳动恨的是传统方案的门槛实在不低——Appium、UiAutomator、XCUITest 这些工具光是环境搭建就能劝退一大半人更别提跨平台适配、元素定位不稳定、脚本维护成本高这些老生常谈的痛点了。而 ARTEMIS 这个项目是谷歌开源的一套移动端 AI 自动化框架它的核心思路跟传统方案有本质区别不再依赖开发者手写定位规则和操作序列而是让 AI 像人一样“看懂”屏幕然后自主决定点哪里、输入什么、怎么滑动。这个框架最直接的价值在于它把移动端自动化的门槛从“会写代码、懂元素定位”拉低到了“会用自然语言描述任务”。你告诉它“帮我在设置里把蓝牙打开”它就能自己完成识别界面、找到蓝牙开关、点击切换这一整套动作。适合谁来参考移动端测试工程师、做 RPA 的开发者、想给自己的 App 加自动化能力的团队以及那些对 AI Agent 落地移动端感兴趣的技术爱好者。ARTEMIS 跟 MCPModel Context Protocol的结合是它的一大亮点MCP 在这里扮演的是“AI 与设备之间的通信协议”角色让模型能够标准化地调用设备操作能力而不是每个项目都自己造一套轮子。我最初关注到这个项目是因为在折腾移动端自动化时反复被元素定位的脆弱性折磨——UI 一改脚本全废。ARTEMIS 的思路让我看到了另一种可能让 AI 去适应界面变化而不是让脚本去追着界面跑。下面我会从整体设计、核心细节、实操流程、问题排查几个维度把这个框架拆开讲清楚。2. 整体架构与设计思路拆解2.1 为什么是“AI 看屏幕”而不是“代码找元素”传统移动端自动化的底层逻辑是通过 accessibility tree 或 UI hierarchy 拿到界面结构然后用 XPath、ID、class name 等选择器定位元素再执行点击、输入等操作。这套逻辑的问题在于它假设界面结构是稳定的、可预测的。但现实是同一个 App 在不同版本、不同机型、不同系统上界面结构可能完全不同。更麻烦的是很多现代 App 用的是自绘引擎或混合渲染accessibility 信息残缺不全选择器根本找不到目标。ARTEMIS 的做法是引入视觉理解能力。它把设备屏幕截图作为输入交给多模态模型去理解当前界面上有什么、每个元素大概在什么位置、当前处于什么状态。模型输出的是“我要点击坐标 (x, y)”或者“我要在某个输入框里输入文本”这样的动作指令再由框架层转换成实际的设备操作。这个转变的意义在于自动化脚本不再依赖界面结构的稳定性而是依赖视觉呈现的稳定性——只要按钮还在屏幕上、还长得差不多AI 就能找到它。注意视觉方案并不是要完全取代传统的 accessibility 方案。在实际项目中两者往往是互补的。ARTEMIS 的设计也保留了接入 accessibility 信息的可能性视觉理解作为兜底和增强手段。2.2 MCP 在框架中的角色定位MCP 全称 Model Context Protocol是一套让 AI 模型与外部工具、数据源进行标准化交互的协议。在 ARTEMIS 的语境下MCP 充当的是“AI 模型”和“移动设备操作能力”之间的中间层。具体来说框架会把设备操作封装成 MCP 工具比如tap、swipe、input_text、screenshot、get_ui_tree等模型通过 MCP 协议来调用这些工具而不需要直接跟 ADB 或 WebDriver 打交道。这样做的好处有几个。第一是解耦模型侧不需要知道底层是 Android 还是 iOS也不需要知道用的是 ADB 还是其他通道它只需要按照 MCP 定义的接口发指令就行。第二是可扩展新增一种设备操作能力只需要注册一个新的 MCP 工具模型侧通过工具描述就能知道怎么用。第三是标准化MCP 正在成为 AI Agent 领域的一个通用协议支持 MCP 意味着 ARTEMIS 可以跟其他支持 MCP 的系统和工具链无缝衔接。从实际使用角度看你不需要深入理解 MCP 的协议细节就能用 ARTEMIS但理解它的存在有助于你在出问题时知道该往哪个方向排查——是模型理解错了还是工具调用失败了还是设备连接断了。2.3 跨平台适配的取舍移动端自动化绕不开 Android 和 iOS 两大平台。ARTEMIS 作为谷歌开源的项目对 Android 的支持自然更成熟一些底层可以通过 ADB 直接发送触摸事件、截取屏幕、读取 UI 层级。iOS 侧则通常需要依赖 WebDriverAgent 或类似的桥接方案部署门槛相对高一些。框架在设计上做了一层抽象把平台相关的操作封装在统一的接口后面。这意味着上层的 AI 决策逻辑和任务编排逻辑是平台无关的你写一个“打开设置并开启蓝牙”的任务描述在 Android 和 iOS 上都能跑只要对应的平台适配层实现了必要的工具。当然实际落地时 iOS 的权限限制和签名问题会更折腾一些这是平台本身的特性决定的不是框架能完全抹平的。2.4 任务编排从单步操作到多步流程ARTEMIS 不只是单步操作的工具它支持多步任务的编排。你可以定义一个任务序列比如“打开微信 - 搜索某个联系人 - 发送一条消息”框架会把这个任务拆解成一系列子目标每一步都通过“截图 - 理解 - 决策 - 执行”的循环来推进。这个循环的频率和节奏是可以调的比如截图间隔、操作后的等待时间、失败重试次数等。这里有一个关键设计状态管理。框架需要记住当前执行到哪一步了、上一步的结果是什么、有没有出现意外弹窗需要处理。这些状态信息会作为上下文喂给模型帮助它做出更准确的决策。如果没有状态管理模型每次看到的都是孤立的截图很容易在复杂流程中迷失。3. 核心细节解析与实操要点3.1 环境准备你需要哪些东西在动手之前先把基础环境搭好。以下以 Android 平台为例因为这是最容易跑通的路径。必备组件清单组件作用备注Python 3.10运行框架主体建议用 3.11 或 3.12兼容性更好ADB与 Android 设备通信需要把设备加入 PATHAndroid 设备或模拟器被控目标真机更稳模拟器方便调试多模态模型 API理解屏幕内容需要支持视觉输入的模型ARTEMIS 框架代码核心逻辑从官方仓库获取ADB 的安装这里不展开网上教程很多。重点说一下设备连接用adb devices确认设备已经识别如果显示unauthorized需要在设备上确认 USB 调试授权弹窗。模拟器的话确保 ADB 能连上模拟器的端口常见的是adb connect 127.0.0.1:5555这种形式。模型 API 这块你需要一个能接受图片输入、输出结构化动作指令的模型。ARTEMIS 的 prompt 设计会要求模型输出特定格式的 JSON包含动作类型和参数。如果你用的模型输出格式不稳定可能需要在框架层加一层解析和容错。3.2 设备操作工具的封装逻辑框架把设备操作封装成一组工具函数每个工具对应一个具体的动作。核心工具大概包括这些screenshot()截取当前屏幕返回图片数据tap(x, y)在指定坐标点击swipe(x1, y1, x2, y2, duration)从一点滑动到另一点input_text(text)在当前焦点输入文本press_key(keycode)按下物理或虚拟按键比如返回键、Home 键get_ui_tree()获取当前界面的 UI 层级结构辅助用这些工具通过 MCP 协议暴露给模型。模型在决策时会看到这些工具的描述和参数要求然后根据当前屏幕内容选择调用哪个工具、传什么参数。实操心得tap的坐标是屏幕绝对坐标不是相对坐标。模型在输出坐标时需要基于截图的尺寸来推算。如果截图被缩放过了坐标映射就会出错。建议在框架层统一截图尺寸和坐标系的换算逻辑避免模型直接输出原始像素坐标。3.3 提示词工程让模型输出可执行的动作ARTEMIS 的效果很大程度上取决于提示词的质量。框架需要告诉模型你现在是一个手机操作助手你看到的是一张手机屏幕截图你的任务是完成用户指定的目标你可以使用以下工具请输出 JSON 格式的动作指令。提示词里通常需要包含这些要素角色定义明确模型的身份和职责边界当前任务用户想要完成什么历史动作之前已经执行了哪些操作结果如何可用工具列表每个工具的名称、参数、用途说明输出格式要求严格的 JSON schema包括动作类型和参数字段约束条件比如“不要点击广告”“如果目标不存在则报告失败”一个常见的坑是模型输出格式不稳定有时候多包了一层 markdown 代码块有时候字段名拼错有时候坐标是字符串而不是数字。框架层需要做健壮的解析和校验解析失败时要么重试要么把错误信息反馈给模型让它重新输出。3.4 动作执行与反馈闭环模型输出动作指令后框架执行实际操作然后进入下一轮循环。这个闭环的节奏很关键。如果操作后立刻截图可能界面还没刷新完模型看到的是旧状态容易做出错误决策。所以需要在操作后加一个等待时间或者更智能地等待界面稳定。等待策略有几种常见做法固定等待简单粗暴比如每次操作后等 1 秒。缺点是慢而且不同操作需要的等待时间不一样。条件等待轮询截图直到界面不再变化或出现预期元素。更智能但实现复杂。混合策略默认固定等待一个较短时间如果检测到界面还在变化则继续等。ARTEMIS 默认可能用的是固定等待加可配置的超时实际项目中可以根据 App 的响应速度调整。我一般会先把等待时间设大一点跑通流程后再逐步压缩找到稳定性和速度的平衡点。4. 实操过程与核心环节实现4.1 从零跑通一个“打开设置并开启蓝牙”的任务下面以这个具体任务为例把整个流程串一遍。假设你已经装好了 Python 环境、ADB 能识别设备、拿到了模型 API 的访问凭证。第一步获取框架代码并安装依赖git clone artemis-repo-url cd artemis pip install -r requirements.txt依赖里通常包括 ADB 的 Python 封装、图像处理库、HTTP 客户端等。如果遇到某个包版本冲突优先用虚拟环境隔离。第二步配置模型接入框架一般会有一个配置文件或环境变量来设置模型 API 的地址和密钥。以环境变量为例export ARTEMIS_MODEL_API_KEYyour-api-key export ARTEMIS_MODEL_ENDPOINThttps://your-model-endpoint/v1/chat/completions export ARTEMIS_MODEL_NAMEyour-vision-model模型需要支持图片输入。如果你用的模型只支持文本那这套方案跑不起来因为核心的屏幕理解依赖视觉能力。第三步连接设备并验证adb devices确认设备列表里有你的设备状态是device而不是unauthorized或offline。然后可以手动截个图测试adb exec-out screencap -p test.png打开test.png看看是不是当前手机屏幕。如果这一步有问题后面都不用试了先把 ADB 连接搞定。第四步定义任务并启动框架通常会提供一个入口脚本或 CLI。你输入任务描述比如“打开设置应用找到蓝牙选项如果蓝牙是关闭状态则开启它”。框架开始循环执行截图 - 发给模型 - 解析动作 - 执行 - 再截图。第一轮截图可能是手机桌面模型识别到“设置”图标输出点击坐标。框架执行点击等待再截图。第二轮看到设置界面模型找到“蓝牙”条目点击进入。第三轮看到蓝牙开关判断当前状态如果是关的就点击开启。任务完成。第五步观察日志和中间截图跑的过程中一定要看日志。框架一般会打印每一轮的模型输入、模型输出、执行结果。如果发现模型理解错了比如把“蓝牙”识别成了“飞行模式”就要考虑是不是截图分辨率太低、或者提示词里对目标的描述不够清晰。4.2 参数调优截图质量、等待时间、重试策略这几个参数直接决定任务的成功率和执行速度。截图质量分辨率太高会增加模型处理时间和 token 消耗太低会导致小图标看不清。建议把截图缩放到宽度 720 到 1080 像素之间。具体数值可以测试如果模型经常认错小图标就提高分辨率如果只是慢但准确率够就降低分辨率。等待时间操作后的等待时间建议从 1.5 秒起步。对于启动 App 这种耗时操作可能需要 3 到 5 秒。可以在框架里针对不同动作类型设置不同的等待时间比如tap后等 1 秒launch_app后等 3 秒。重试策略模型输出解析失败、或者执行后界面没有按预期变化时需要重试。重试不是简单重复上一次动作而是把失败信息加入上下文让模型重新决策。比如“上一次点击 (500, 1200) 后界面没有变化请重新观察屏幕并选择其他操作”。重试次数建议设 3 次超过就报错终止避免无限循环。4.3 多步任务的编排与状态传递对于复杂任务比如“打开微信搜索联系人张三发送消息你好”需要把任务拆解成子目标并且维护状态。一种做法是在提示词里维护一个任务清单每完成一步就标记完成模型每次决策时都看到当前进度。另一种做法是在框架层做任务分解把大任务拆成小任务依次执行每个小任务独立跑一个闭环。我个人更倾向于第二种因为每个小任务的目标更明确模型不容易迷失。缺点是任务之间的衔接需要额外处理比如上一步的结果如何传递给下一步。但总体来说可控性更强。状态传递的一个关键是把上一步的关键信息提取出来作为下一步的输入。比如搜索联系人后需要知道搜索结果里哪个是目标联系人这个信息要传递给“点击联系人”这一步。可以在框架层做一个简单的上下文对象存储每一步的输出摘要。4.4 与现有测试框架的集成思路如果你已经有基于 Appium 或 UiAutomator 的测试体系ARTEMIS 可以作为补充而不是替代。比如在关键流程中用 ARTEMIS 做视觉校验和兜底操作在稳定的页面用传统选择器做精确控制。集成方式可以是把 ARTEMIS 封装成一个独立的服务通过 HTTP 或 MCP 对外提供“执行任务”的接口。测试框架在需要的时候调用这个接口传入任务描述拿到执行结果。这样两边解耦各自演进。5. 常见问题与排查技巧实录5.1 模型识别不准截图、提示词、模型能力三方面排查模型认错元素是最常见的问题。排查顺序建议从简到繁先看截图把模型看到的截图保存下来自己看一眼。如果人都看不清模型肯定也看不清。常见问题是截图分辨率太低、界面有遮挡、或者截图时机不对比如动画还没结束。再看提示词任务描述是否足够具体比如“打开蓝牙”不如“在设置界面中找到蓝牙选项并点击然后在蓝牙页面中开启蓝牙开关”来得明确。提示词里可以加入一些领域知识比如“蓝牙开关通常在设置的一级或二级菜单中”。最后看模型能力不同模型对 UI 截图的识别能力差异很大。有些模型对图标识别好有些对文字识别好。如果当前模型在某个场景下持续表现差可以考虑换模型或者对截图做预处理比如放大特定区域。5.2 操作执行失败坐标偏移、权限不足、界面未响应坐标偏移通常是因为截图尺寸和实际屏幕尺寸不一致。比如截图被缩放了但点击时用的还是缩放后的坐标。解决办法是在框架层统一坐标系所有坐标都基于原始屏幕尺寸截图缩放只影响模型输入不影响动作执行。权限不足在 Android 上主要表现为无法模拟点击。普通 ADB 点击在某些系统版本或某些 App 上会被拦截。可以尝试用adb shell input tap替代或者检查是否需要额外的权限声明。iOS 上则是 WebDriverAgent 的签名和信任问题。界面未响应可能是 App 卡顿或网络请求慢。这时候固定等待不够用需要加条件等待轮询截图直到界面变化或超时。5.3 任务循环卡死如何设置合理的终止条件没有终止条件的循环是灾难。必须设置最大步数限制比如 50 步。超过就强制终止并报告失败。另外如果连续多步截图完全一样说明界面没变化也应该触发终止或重试。还有一个隐蔽的坑模型可能陷入“点击 - 没反应 - 再点击”的死循环。解决办法是在上下文里记录最近几次动作如果发现重复动作且界面无变化就提示模型“你已经在同一个位置点击了 3 次请尝试其他操作或报告失败”。5.4 常见问题速查表问题现象可能原因排查方向解决建议模型输出格式错误提示词不够严格检查输出 schema 定义加 few-shot 示例强化格式约束点击无效果坐标偏移或权限问题对比截图坐标和实际坐标统一坐标系检查 ADB 权限界面识别错误截图质量差或模型能力不足保存截图人工检查提高分辨率换模型加提示任务中途卡死无终止条件或死循环查看日志最后几步加最大步数加重复动作检测执行速度太慢等待时间过长或模型响应慢统计每步耗时压缩等待时间换更快的模型跨平台不兼容平台适配层缺失确认目标平台支持情况Android 优先iOS 需额外配置避坑技巧在开发阶段把每一轮的截图和模型输出都保存到本地文件按时间戳命名。出问题时回看这些记录比看日志直观得多。我一般会保留最近 10 轮的数据方便复现问题。5.5 性能优化的几个实用手段如果任务执行太慢可以从这几个方向优化。一是降低截图频率不是每一步都需要截图有些连续操作可以合并。二是用更小的模型做初步筛选只在复杂场景调用大模型。三是缓存界面理解结果如果连续两轮截图相似度高可以复用上一轮的理解。四是并行化比如在等待界面加载的时候预取下一轮可能需要的资源。但要注意优化不能牺牲稳定性。我见过为了提速把等待时间压到 0.3 秒结果十次有三次失败反而更慢。先保证成功率再逐步压缩时间。6. 这个框架适合什么场景不适合什么场景ARTEMIS 这类方案最适合的场景是界面变化频繁、传统选择器维护成本高的自动化任务需要快速验证想法、不想写大量定位代码的探索性任务以及作为人工操作的辅助比如自动填写表单、批量处理重复操作。不太适合的场景是对执行速度和精度要求极高的场景比如高频交易类的操作界面元素极小、视觉区分度低的场景以及设备性能极差、截图和操作延迟很大的场景。另外涉及敏感权限或用户隐私的操作用 AI 自动化要格外谨慎。模型看到的截图可能包含个人信息这些数据在传输和处理过程中需要做好保护。我个人在实际操作中的体会是ARTEMIS 这类框架的价值不在于完全替代传统自动化而在于提供了一种更灵活的补充手段。在传统方案搞不定的地方用它兜底在它不擅长的精确控制场景用传统方案两者结合往往能覆盖更广的测试和操作需求。最后分享一个小技巧如果你在调试时发现模型总是差一点点才点对位置可以在提示词里加一句“点击目标元素的中心位置”有时候能明显提升点击准确率。
