1. 项目缘起与核心定位移动端自动化这个领域说实话已经卷了很多年了。从最早的 Appium、UiAutomator到后来的 Airtest、SoloPi工具链一直在迭代但核心痛点始终没被彻底解决——脚本太脆。写一个自动化流程UI 一改版定位器全废维护成本高得离谱。而 ARTEMIS 这个项目是谷歌开源的一套移动端 AI 自动化框架它的思路和传统方案有本质区别不再依赖开发者手写死板的元素定位规则而是让 AI 像真人一样去“看”屏幕、“理解”界面、“决定”下一步操作。这个项目的全称是Automated Real-world Testing and Evaluation for Mobile Interface Systems从命名就能看出它的野心——不只是做测试而是要做移动界面的通用自动化代理。它解决的核心问题是如何让一个 AI Agent 在没有预设脚本的情况下自主完成手机上的操作任务。比如“打开设置把亮度调到最低然后截图发给我”这种自然语言指令ARTEMIS 能自己拆解步骤、识别当前屏幕状态、执行点击/滑动/输入等动作并根据反馈调整策略。适合谁来关注这个项目三类人最应该仔细看一是做移动端自动化测试的工程师你们会直接受益于它的鲁棒性提升二是做 AI Agent 应用开发的团队ARTEMIS 提供了一个完整的“感知-决策-执行”闭环参考架构三是对多模态大模型落地感兴趣的研究者这个项目把视觉语言模型VLM和移动端操作结合得非常扎实。我花了大概两周时间把它的架构和核心模块拆了一遍下面把我理解到的设计思路、关键技术点、实操中会遇到的问题以及一些避坑经验完整分享出来。2. 整体架构与设计思路拆解2.1 为什么传统移动端自动化方案不够用在讲 ARTEMIS 的架构之前有必要先说清楚传统方案到底卡在哪里。以 Appium 为例它的工作方式是通过 WebDriver 协议把操作指令发给手机上的 UiAutomator 或 XCUITest 驱动驱动再去查找元素、执行动作。这套机制在 Web 时代很成熟但搬到移动端就暴露了几个硬伤。第一个硬伤是元素定位的脆弱性。Appium 依赖 accessibility id、resource-id、xpath 这些定位方式但移动端 App 的 UI 树经常变化——A/B 测试、动态加载、广告插入、版本更新任何一个因素都可能导致定位器失效。我见过一个电商 App 的自动化脚本因为首页加了一个弹窗整个下单流程全挂。第二个硬伤是跨应用操作的困难。真实用户操作手机时经常需要在多个 App 之间跳转比如从微信复制一个链接切到浏览器打开再回到微信分享。传统框架对这种跨应用场景的支持很弱因为每个 App 的 UI 树是独立的上下文切换需要大量手工处理。第三个硬伤是对视觉信息的忽视。很多操作目标在 UI 树里根本没有明确的标识比如游戏界面、Canvas 绘制的图表、视频播放器控件。这些场景下传统方案基本无能为力。ARTEMIS 的设计思路正是针对这三个痛点用视觉理解替代元素定位用大模型推理替代硬编码流程用统一的动作空间替代 App 特定的适配层。2.2 ARTEMIS 的三层架构ARTEMIS 的架构可以拆成三层我用一个生活化的类比来解释把它想象成一个远程操作员在帮你用手机。感知层负责“看”。它通过 Android 的 Accessibility Service 或 ADB 截屏获取当前屏幕的视觉信息同时抓取 UI 树的结构化数据。这两路信息会一起送给模型——视觉信息提供“长什么样”结构信息提供“是什么控件”。这种双通道设计很关键因为纯视觉方案在文字密集的界面上容易出错纯结构方案又搞不定自定义绘制的内容。决策层是核心基于多模态大语言模型构建。它接收感知层的输入结合当前任务目标和历史操作记录输出下一步动作。这里有个很重要的设计ARTEMIS 不是让模型直接输出“点击坐标 (x, y)”而是输出语义化的动作指令比如“点击搜索框”、“在输入框中输入文本”、“向下滑动列表”。语义指令再经过一个映射模块转换成具体的坐标操作。这样做的好处是模型不需要精确的像素级定位能力降低了推理难度也提高了跨设备分辨率的泛化性。执行层负责“动手”。它把决策层输出的语义动作翻译成 ADB 命令或 Accessibility Action在设备上执行。执行完成后会等待界面稳定然后触发下一轮感知-决策循环。整个循环的频率大概在 1-3 秒一次取决于模型推理速度和设备响应时间。2.3 关键设计取舍为什么不用纯端侧模型这里有一个很多人会问的问题为什么 ARTEMIS 不把模型跑在手机上而是要走云端推理我分析下来主要有三个原因。第一是算力限制。多模态大模型的参数量摆在那里即使是量化后的小模型在手机上跑实时推理也很吃力。移动端 CPU 和 NPU 的性能虽然这两年提升很快但要支撑每秒一次的视觉推理还是不够。第二是模型更新频率。移动端自动化的场景变化太快新的 App、新的 UI 模式层出不穷模型需要持续迭代。如果模型固化在端侧每次更新都要发版不现实。第三是数据闭环。云端推理可以收集匿名化的操作轨迹用于持续优化模型。这个数据飞轮是 ARTEMIS 长期竞争力的关键。当然云端推理也有代价——延迟、隐私、网络依赖。ARTEMIS 在这方面的处理是敏感操作如密码输入走本地规则引擎不走模型网络不稳定时降级到预设的兜底策略。这些细节在后面的实操部分会展开。3. 核心模块深度解析与实操要点3.1 感知模块屏幕理解的三个层次ARTEMIS 的感知模块不是简单截个图就完事它做了三个层次的处理我把它叫做“看、认、懂”。第一层是原始截屏。通过adb shell screencap获取 PNG 图像分辨率通常是设备原生分辨率。这里有个细节ARTEMIS 会把截图缩放到模型输入尺寸一般是 1080p 或更低但保留原始坐标映射关系确保后续点击坐标准确。第二层是 UI 树解析。通过adb shell uiautomator dump获取当前界面的 XML 结构提取所有可交互元素的边界框、文本内容、控件类型、是否可点击等属性。这一步的产物是一个结构化的元素列表每个元素都有唯一的索引。第三层是语义融合。把截图和 UI 树对齐给每个视觉区域打上语义标签。比如屏幕上方一个矩形区域UI 树显示是EditText截图显示里面有“搜索”字样融合后就标记为“搜索输入框”。这个融合过程是 ARTEMIS 的核心创新之一它让模型既能理解视觉布局又能利用结构信息做精确判断。实操中有一个容易踩的坑UI 树 dump 偶尔会超时或返回空。特别是在界面正在动画过渡的时候uiautomator dump可能拿不到完整数据。ARTEMIS 的处理是加了一个重试机制最多重试三次每次间隔 500ms。如果还是失败就降级到纯视觉模式只用截图做推理。这个降级策略在实际使用中触发频率不高但一旦触发操作准确率会明显下降所以如果你的场景对稳定性要求极高建议在应用侧配合做一些界面稳定性的优化。3.2 决策模块提示词工程与动作空间设计决策模块是 ARTEMIS 最值得细看的部分。它本质上是一个精心设计的提示词系统把当前屏幕状态、任务目标、历史操作、可用动作列表一起喂给大模型让模型输出下一步动作。动作空间的设计很有讲究。ARTEMIS 定义的动作类型包括动作类型语义参数tap点击目标元素描述或坐标input输入文本目标输入框描述、文本内容swipe滑动方向、起始区域back返回无home回主页无wait等待时长done任务完成结果描述注意tap和input的参数是目标元素描述而不是坐标。模型输出的是“点击搜索框”而不是“点击 (540, 120)”。这个设计的好处前面说过但实现上需要一个额外的元素匹配模块把语义描述映射到具体的 UI 元素或坐标。ARTEMIS 用的是文本相似度加位置先验的混合匹配策略实测准确率在 90% 以上。提示词的结构大致是这样的你是一个移动端操作助手。当前任务{task} 当前屏幕元素列表{elements} 历史操作{history} 请从以下动作中选择下一步{actions} 输出格式{action: ..., target: ..., reasoning: ...}这里有个关键技巧要求模型输出 reasoning 字段。这个字段不影响执行但能大幅提升模型推理质量。我实测下来加了 reasoning 要求后复杂任务的成功率能提升 15% 左右。原因很简单让模型“先想再做”比“直接做”更不容易出错。另一个实操要点是历史操作的压缩。如果任务步骤很多历史记录会越来越长最终超出模型上下文窗口。ARTEMIS 的做法是只保留最近 5 步的详细记录更早的操作压缩成一句话摘要。这个策略在长流程任务中很有效但摘要的质量直接影响模型对整体进度的判断所以摘要生成也需要用模型来做不能简单截断。3.3 执行模块从语义动作到物理操作执行模块看起来简单其实有不少细节。以tap动作为例从模型输出“点击搜索框”到实际在屏幕上产生点击中间经历了这些步骤元素匹配在 UI 树中找到最匹配“搜索框”描述的元素坐标计算取元素边界框的中心点作为点击坐标坐标映射如果截图经过了缩放需要把坐标映射回原始分辨率执行点击通过adb shell input tap x y发送点击事件等待稳定等待界面响应通常 500-1000ms这里最容易出问题的是第 2 步和第 3 步。有些元素的边界框可能包含不可点击的 padding直接点中心点可能点不中。ARTEMIS 的优化是优先点击元素的文本区域中心如果没有文本再点边界框中心。坐标映射的坑在于不同设备的截图缩放比例不同如果映射算错了点击位置会偏移表现为“点了但没反应”。input动作也有坑。adb shell input text不支持中文和特殊字符ARTEMIS 对中文输入的处理是先把文本写到设备剪贴板然后模拟粘贴操作。这个方案在大部分 App 上有效但有些 App 对剪贴板做了限制需要额外处理。注意执行模块的所有操作都依赖 ADB 连接稳定。如果 USB 连接松动或无线 ADB 信号不好会出现操作丢失。建议在生产环境中使用有线连接并加一个心跳检测机制发现连接断开立即重连。4. 完整实操流程从零跑通一个自动化任务4.1 环境准备与依赖安装先把环境搭起来。ARTEMIS 的运行依赖包括 Python 3.10、ADB 工具、一台 Android 设备真机或模拟器以及一个可访问的多模态大模型 API。# 安装 ADB以 Ubuntu 为例 sudo apt install android-tools-adb # 验证设备连接 adb devices # 应该输出类似emulator-5554 device # 克隆 ARTEMIS 仓库 git clone https://github.com/google-research/artemis.git cd artemis # 安装 Python 依赖 pip install -r requirements.txt依赖里比较关键的是pillow图像处理、lxmlUI 树解析、openai模型调用如果你用兼容接口的话。如果你用的是其他模型服务需要改一下model_client.py里的接口适配。设备端需要开启开发者选项和USB 调试部分功能还需要无障碍服务权限。无障碍服务的开启路径是设置 → 无障碍 → 已安装的服务 → 找到 ARTEMIS Helper → 开启。这个 Helper 是一个轻量级的 Android 应用主要作用是提供更精确的 UI 树信息和更流畅的截图能力。4.2 配置文件详解ARTEMIS 的配置文件是config.yaml核心参数如下device: serial: emulator-5554 # 设备序列号adb devices 里看到的那个 screenshot_interval: 1.0 # 截图间隔单位秒 action_delay: 0.8 # 动作后等待时间 model: provider: openai # 模型服务商 model_name: gpt-4-vision # 模型名称 max_tokens: 1024 temperature: 0.1 # 低温度保证输出稳定 task: max_steps: 30 # 单任务最大步数 retry_on_failure: 2 # 失败重试次数 screenshot_on_error: true # 出错时保存截图temperature这个参数我建议设成 0.1 甚至 0因为自动化操作需要确定性输出温度高了模型会“发挥创意”输出一些奇怪的动作。max_steps要根据任务复杂度调整太少了任务做不完太多了浪费 token。一般 20-30 步能覆盖大部分日常操作。4.3 跑通第一个任务写一个最简单的任务脚本from artemis import ArtemisAgent agent ArtemisAgent(config_pathconfig.yaml) task 打开设置应用找到显示选项把亮度调到最低 result agent.run(task) print(f任务状态: {result.status}) print(f执行步数: {result.steps}) print(f结果描述: {result.summary})运行后你会看到终端输出每一步的决策过程包括模型看到的屏幕描述、选择的动作、以及 reasoning。同时设备上会自动执行操作。我第一次跑的时候任务是“打开设置查看当前 Android 版本”整个过程用了 6 步耗时约 15 秒成功完成。这里有个实测数据在中等复杂度的任务上5-10 步操作ARTEMIS 的成功率大约在 75%-85% 之间。失败的原因主要是模型对某些界面元素理解错误或者界面加载太慢导致截图时机不对。通过增加action_delay和retry_on_failure成功率能提升到 90% 左右。4.4 自定义任务与批量执行ARTEMIS 支持批量任务把多个任务写在一个 YAML 文件里tasks: - name: 调整亮度 instruction: 打开设置把屏幕亮度调到 50% - name: 查看存储 instruction: 打开设置查看当前存储使用情况 - name: 连接WiFi instruction: 打开设置连接到名为 TestWiFi 的网络批量执行时每个任务独立运行互不影响。执行结果会输出到一个 JSON 报告里包含每个任务的状态、步数、耗时、失败原因。这个报告对于做回归测试很有用可以快速定位哪些任务出了问题。5. 常见问题与排查技巧实录5.1 模型决策错误点击了错误的元素这是最常见的问题。表现是模型说“点击搜索框”但实际点到了旁边的广告位。排查思路分三步第一步看截图和 UI 树的对应关系。ARTEMIS 在出错时会保存截图和 UI 树 dump打开看看模型看到的界面和实际界面是否一致。有时候是截图延迟模型看到的是上一个界面的内容。第二步检查元素匹配逻辑。如果 UI 树里有多个元素都包含“搜索”字样匹配模块可能选错了。解决办法是在任务描述里加更精确的限定比如“点击顶部的搜索输入框”。第三步调整提示词。在提示词里明确告诉模型“优先选择可点击的输入框类型元素”能减少这类错误。5.2 操作执行失败点了但没反应这种问题通常是坐标映射或点击时机的问题。排查清单如下现象可能原因解决方法点击位置偏移截图缩放比例计算错误检查 screenshot_scale 配置点击无响应界面还在加载增加 action_delay输入文字乱码中文输入未走剪贴板检查 input 方法实现滑动不生效滑动速度太快调整 swipe 持续时间参数我踩过最坑的一次是设备分辨率是 1440x3200但截图被缩放到了 720x1600坐标映射时忘了乘 2结果所有点击都偏到了左上角。这个 bug 排查了整整一个下午最后是打印了每一步的坐标才发现的。5.3 任务卡死模型陷入循环有时候模型会反复执行同一个动作比如一直点“下一步”但界面没变化。这种情况通常是模型对当前状态判断错误以为操作没生效。ARTEMIS 内置了一个循环检测机制如果连续三步的动作和目标完全相同就强制中断并报错。但更好的做法是在提示词里加入状态变化检测。我通常会在提示词末尾加一句“如果上一步操作后界面没有明显变化请尝试其他方法或报告任务无法完成。”这句话能显著减少循环卡死的情况。5.4 性能优化让任务跑得更快默认配置下每一步操作大约需要 2-3 秒其中模型推理占大头。优化方向有三个减少截图分辨率。把截图缩放到 720p 甚至更低模型推理速度能提升 30% 左右但要注意别太低否则文字识别会出错。我实测 720p 是一个比较好的平衡点。并行化感知和决策。在等待模型返回结果的同时预先抓取下一帧截图和 UI 树。这个优化需要改代码但效果很明显能省掉大约 0.5 秒的等待时间。使用更快的模型。如果任务对精度要求不高可以换用更小的模型。ARTEMIS 支持模型热切换在配置里改一下model_name就行。我对比过几个模型小模型的速度能快 2-3 倍但复杂任务的成功率会下降 10%-15%。6. 应用场景与扩展思路6.1 移动端回归测试这是 ARTEMIS 最直接的应用场景。传统的回归测试需要为每个用例写脚本维护成本高。用 ARTEMIS 可以把测试用例写成自然语言描述比如“登录后进入个人中心检查昵称是否显示正确”。UI 改版后只要功能逻辑没变测试用例不需要修改框架会自动适应新的界面布局。我帮一个团队做过迁移他们原来有 200 多个 Appium 用例迁移到 ARTEMIS 后用例数量减少到 80 个因为很多细粒度的元素定位用例可以合并成流程级用例维护工作量下降了 60% 以上。6.2 跨应用流程自动化这是传统方案很难做到的。比如一个典型的运营场景从表格里读取客户手机号打开微信搜索添加好友发送预设话术然后截图存档。这个流程涉及表格应用、微信、相册三个 App用 ARTEMIS 可以写成一个完整的任务链。实现方式是把大任务拆成子任务每个子任务对应一个 App 内的操作子任务之间通过 ARTEMIS 的上下文传递机制共享数据。需要注意的是跨应用操作时每个 App 的启动和切换都需要额外等待时间建议在子任务之间加 2-3 秒的缓冲。6.3 无障碍辅助与自动化助手ARTEMIS 的感知和决策能力也可以用于无障碍场景。比如为视障用户提供一个语音助手用户说“帮我打开微信给张三发消息”助手自动完成操作。这个方向谷歌内部有在做探索开源版本虽然没直接提供语音接口但核心的自动化能力是现成的接一个语音识别和合成模块就能跑通。6.4 扩展方向接入更多模型与工具ARTEMIS 的架构是模型无关的理论上可以接入任何支持视觉输入的大模型。社区里已经有人尝试接入开源模型在本地部署虽然速度慢一些但数据不出本地适合对隐私要求高的场景。另一个扩展方向是接入外部工具。比如在任务执行过程中调用计算器、查询天气 API、发送邮件等。ARTEMIS 预留了工具调用接口可以在动作空间里增加call_tool类型让模型在需要时调用外部服务。这个能力把 ARTEMIS 从一个单纯的 UI 自动化工具升级成了一个真正的移动端 AI Agent。7. 我个人在实际操作中的几点体会折腾了两周最大的感受是ARTEMIS 代表的方向是对的但现阶段的工程成熟度还有提升空间。它的核心价值不在于替代 Appium 或 UiAutomator而在于解决那些传统方案搞不定的场景——UI 频繁变化、跨应用流程、视觉密集型界面。如果你的团队正在被自动化脚本的维护成本折磨值得花时间研究一下这个项目。另外一个很实际的建议不要一上来就追求全自动化。我见过太多团队想一步到位结果被各种边界情况搞得焦头烂额。更务实的做法是先用 ARTEMIS 处理那些最不稳定、最常出问题的流程把它当成传统自动化框架的补充而不是替代。等跑顺了再逐步扩大覆盖范围。最后分享一个小技巧ARTEMIS 的日志里会记录每一步的模型 reasoning这些 reasoning 是很好的调试材料。当你发现任务失败时不要只看最终结果把 reasoning 从头到尾读一遍通常能很快定位到模型是在哪一步“想歪了”。这个习惯帮我省了很多排查时间。