Google开源ARTEMIS：AI Agent驱动Android真机UI测试的新范式

1. ARTEMIS 到底是什么Google 为什么要把 Agent 塞进真机测试做 Android 测试的人应该都有过这种体验UI 自动化测试写了几个月维护脚本的时间比写脚本还长真机兼容性测试拖了好几天就因为某个机型弹了个权限框没点到好不容易集成了 Appium 或 UIAutomator换个页面结构又要改选择器。说白了传统 UI 自动化一直在跟元素定位和脚本维护这两座大山较劲。Google 开源 ARTEMIS 的思路本质上是把这个问题彻底换了条路不再用固定脚本去描述怎么点而是让 Agent 自己理解要做什么然后自己去看屏幕、点按钮、验证结果。它不再依赖 resource-id、content-desc 这种元素定位方式而是靠视觉加语义理解驱动整个测试过程。这个方向如果跑通意味着 UI 测试从写代码逐步转向下指令维护成本能降一个量级。ARTEMIS 由 Google 内部 Model Factory 团队研发落地场景主要是真机测试。它采用 Gemma 作为基础视觉语言模型在真机上直接扩展模型上下文通过一种叫 Semantic Action Tree语义动作树的结构把自然语言指令解析成 UI 操作序列。整套系统开源后你可以在自己的测试机群里把整套流程跑起来让 Agent 替代一部分原本需要人肉操作或者脚本操作的活。这篇文章适合正在做 Android 测试、想引入 AI 能力但不知道从哪下手的人。我会把 ARTEMIS 的架构逻辑、搭建步骤、实测表现和局限性一次讲透包括我在本地环境跑通它之后踩到的一堆坑。看到网上很多讨论把 ARTEMIS 捧得很高但实际用起来它跟 Appium 这类工具不是替代关系而是互补关系这一点放到后面详细聊。2. 核心架构拆解视觉驱动、语义动作树与真机上的模型部署2.1 为什么是视觉语义而不是XML 布局传统 UI 自动化的痛点做过的人都懂。UIAutomator 靠 resource-id 定位Appium 靠 XPath 或 accessibility 属性定位一旦开发改了布局、换了 ID脚本立刻失效。而 ARTEMIS 的判断依据是截图画面本身——UI 长什么样Agent 就按什么样去理解页面重构对 Agent 来说只是长了个新样子不影响它的操作逻辑。这背后的技术路线是视觉语言模型VLM。ARTEMIS 没有在 PC 端做模型推理而是把 Gemma 模型直接跑在手机上。这听起来很重但实际落地时 Google 做了不少针对性压缩和推理优化手机端侧可以承载。模型吃进去的是屏幕截图输出的是可执行的动作。中间那层依靠的就是所谓的语义动作树。2.2 语义动作树从点这个按钮到完成这个任务的桥梁语义动作树这个名字听起来抽象我拆开讲。ARTEMIS 收到一条任务比如打开设置把亮度调到 50%它不会直接去找亮度这个词对应的控件而是把这个任务分解成一棵动作树先找入口再进二级页面识别滑块拖拽到目标位置。每个节点都对应一个 UI 元素和一个动作树的结构则体现了任务之间的前后依赖关系。这套机制的价值在于它允许 Agent 在执行过程中不断观察和反馈。模型根据当前屏幕内容决定下一步动作动作完成后重新截图、再决策形成观察-决策-动作-再观察的闭环。遇到弹窗、权限请求、页面加载延迟等意外情况Agent 也能根据视觉内容临时调整路径而不是像传统脚本那样直接报错罢工。2.3 在真机上部署模型如何扩展上下文手机端侧运行大模型绕不开内存和功耗问题。ARTEMIS 的做法很有意思它并没有把整个任务上下文全塞进一个小小的端侧模型里而是利用了一套上下文扩展机制。简单说Agent 不记忆长对话只关注当前屏幕的信息。每截一张图模型基于新的屏幕状态重新规划历史动作则以结构化的方式暂存在语义动作树里而不是用自然语言重复喂给模型。这么做带来的直接优势是推理速度快适合真机实时操作。手机上的 Gemma 是量化版本参数规模不是最大的那档但配合精简的上下文策略响应延迟能控制在秒级以内。这对实际执行体验很关键如果模型每步卡顿十秒钟Agent 在真机上的表现会非常人工智障压根没法用。2.4 ARTEMIS 的系统分层与模块职责从代码组织上看ARTEMIS 并不是一个单体应用而是分成了几个核心模块语义动作树生成器把用户指令转成结构化的节点序列。UI 状态解析器识别截图中的可交互元素比如按钮、列表项、输入框。动作执行器把模型输出的动作解析成安卓系统可执行的触摸、滑动、输入事件。结果验证器对比预期状态和实际状态判断任务是否完成。拿验证器来说它最容易被低估。很多跑过 ARTEMIS 的人在第一步就发现模型动作执行得很好但任务到底有没有成功需要一套独立的反馈机制。ARTEMIS 的实现思路是让模型对执行前后的截图做状态比对再结合系统日志输出任务已完成或执行失败的信号。这一层做不好整套系统就成了能跑但不知道对不对的黑箱。3. 自己动手跑一遍从环境准备到真机自动执行任务3.1 前置依赖与真机选择ARTEMIS 对硬件有明确要求。官方推荐的是支持 Google Play 服务的 Pixel 系列机型系统版本建议 Android 10 以上。我在实测中发现8GB 内存的机型能跑但流畅度一般12GB 内存以上的机型体验明显更好。手机端侧推理对内存带宽和算力要求都比较高如果你的测试机群里有一批低端机建议先拿一台配置较高的做 Pilot 验证再评估是否铺到全量设备。除了真机PC 端还需要准备 Android SDK 环境以及 Python 3.10。ARTEMIS 的控制端是基于 Python 写的手机与电脑之间通过 adb 或无线调试连接。如果你的网络环境不支持直接拉取 Hugging Face 的模型权重需要提前配置好镜像或离线模型包这一步卡住的人最多。3.2 模型权重下载与量化版本选择ARTEMIS 默认使用 Gemma 3 的 4B 量化版本作为推理模型文件大小在 3GB 左右。Google 开放了不同精度版本我建议优先选 Q4_K_M 这种中等压缩的版本精度损失可控内存占用也压得下来。如果你在手机上跑出现频繁卡死或闪退可以考虑更小的 Q3 版本但识别精度会有所下降特别是在复杂列表页面上。下载模型权重后需要把文件放到手机指定的目录下。ARTEMIS 的首次启动会把模型加载进内存这个过程耗时较长甚至可能超过一分钟。我遇到过好几次看起来像死机的情况其实只是模型还没加载完建议首次跑的时候多等一会儿再操作。3.3 安装与启动一条命令跑通 Agent环境就绪之后启动流程比想象中简单。ARTEMIS 提供了一个命令行入口大致逻辑是连接真机确保adb devices能识别到设备。启动 ARTEMIS 服务端指定模型路径和任务参数。在终端输入任务指令Agent 开始在真机上自动执行操作序列。通过日志或录屏观察执行过程最终输出任务完成状态。这里有个很重要的点ARTEMIS 默认不是一个任务跑完就退出的模式。它像是一个可以连续接指令的 Agent 进程跑完一个任务会等待下一条指令。这跟传统测试框架一次运行定生死的模式完全不同更接近一个真机操作员的角色。3.4 第一个任务让 Agent 自动完成一个完整的用户流程我建议你的第一个 ARTEMIS 任务不要选太复杂的可以从打开计算器计算 123456验证结果是 579开始。这个流程涉及的页面和动作都不多但能完整覆盖识别输入框、点击数字、点击运算符、读取结果这几类核心能力。实际操作时指令可以这样写artemis --task 打开计算器依次点击 1 2 3 4 5 6 确认结果显示为 579ARTEMIS 的 Agent 会调用系统 Intent 打开计算器应用然后根据屏幕截图逐一点击数字。你会发现它不像脚本那样按固定坐标点按而是每次截图后重新识别计算器按钮的位置——这意味着如果屏幕上出现了一个弹窗遮挡它也能绕开或先关掉弹窗再继续。第一次跑通的感觉还是很奇妙的。我在旁边看着它自己一顿操作最后弹出了正确结果那一下真的有未来已来的感觉。但从这之后真正的挑战才开始。4. 真机测试专项原生的AI 接管意外清单与绕过方案4.1 权限弹窗最容易让 Agent 翻车的第一关Android 真机测试里权限弹窗是最大的路人杀手。传统脚本好歹能通过固定的 UI 层级去识别允许按钮但 ARTEMIS 依赖视觉识别在弹窗出现的一瞬间模型需要判断这是个弹窗而且得点击允许。大多数情况下它能做到但也有翻车的时候比如部分国产 ROM 的授权弹窗文案跟 AOSP 差异很大按钮样式也不是标准的 Material Design模型偶尔会识别不出来直接卡在当前页面。我实操中的应对办法是在任务的初始指令里预设处理弹窗的意图比如如果出现任何权限请求点击允许。ARTEMIS 的模型对这类带如果的逻辑理解得还行但不够稳定所以更稳妥的办法是先用传统的 adb 命令预先授权再让 Agent 进入业务流adb shell pm grant com.example.app android.permission.CAMERA这套组合拳可以覆盖大部分需要临时弹窗的测试场景。我的经验是Agent 更适合处理业务内部的意外系统级弹窗最好还是提前通过环境预处理消掉不要全指望模型。4.2 Compose 语义树 vs 传统 View 体系识别逻辑的差异ARTEMIS 在识别 UI 时部分逻辑依赖 Android 的语义节点。对传统的 View 体系它通过 Accessibility 信息辅助判断控件类型对 Compose 界面它读取 Compose 语义树。但这个过程和开发者平时用的 AS 布局查看器不一样——Agent 拿到的语义信息不一定包含精确的 bounds 坐标更多是这个区域是什么控件的置信度判断。这里就出现了一个很有趣的偏差有些页面在视觉上很清楚但语义节点缺失严重模型只能猜着找反过来有些页面视觉混杂但语义结构很干净模型反而表现很好。我测试过几个用 Compose 写的页面只要开发规范地设置了contentDescription和testTagARTEMIS 的识别成功率会大幅提升。所以如果你打算引入 ARTEMIS提前规范开发团队的语义属性命名性价比非常高。4.3 滚动判定列表页无限下滑的边界问题另一个很容易出问题的场景是无限列表。以刷抖音或微博这种全屏滑动产品为例ARTEMIS 执行滑动找到某条内容这种任务时它靠的是截图画面里的视觉连续性来判断是否滑到了底部。如果内容加载速度跟不上滑动速度模型可能误判为已经到底了然后停止滑动。解决思路有两个方向。一是给任务指令加上更明确的终止条件比如持续下滑直到出现包含 XX 关键词的内容如果超过 10 次还没找到停下来报告失败。二是在动作执行器层面对滑动动作做节流每次滑动后等待画面稳定再截图确认内容加载完成后再做下一次滑动。后者对真实机型的网络环境要求比较高毕竟 5G 和弱网下的表现差异会非常大。我实测下来纯视觉滚动判定在弱网环境下特别不可靠。如果你负责的 App 对弱网测试场景有要求建议在 ARTEMIS 外层套一个网络控制逻辑或者干脆把弱网场景回归给传统脚本别让 Agent 去挑战不可能完成的任务。4.4 系统 UI 与第三方 ROM 的适配问题ARTEMIS 的原生实现默认是针对 AOSP 系统的。AOSP 上的设置应用、通知栏、系统弹窗模型都能正确识别。但你把它放到 MIUI、ColorOS、OriginOS 这类国产 ROM 上系统的设置页面结构完全不同部分系统组件名称也变了模型经常找不到入口。我在 Pixel 原生系统上跑得很顺的任务换到某主流国产旗舰上第一步打开设置就卡住了。不是说模型不聪明而是训练数据里大概率没怎么见过这类 ROM 的 UI。目前真的想在全量设备上铺 ARTEMIS 的话建议先按 ROM 品牌做一轮人工引导让 Agent 学习一下当前设备的界面特征或者针对目标 ROM 做少量微调。Google 后续会不会提供更通用的适配层还不好说现阶段只能自己动手。5. ARTEMIS 与传统自动化测试的真实对比不是替代是新赛道5.1 与 Appium、UIAutomator、Maestro 的差异很多做测试的人看到 ARTEMIS 的第一反应是这东西能不能替代 Appium我的判断是短期内不会两者解决问题的维度完全不同。传统自动化工具的核心假设是UI 结构是可预期的脚本描述了预期路径。Appium 和 UIAutomator 的优势在于精确、可控、回归成本低适合 CI 里跑大量重复的冒烟测试和回归测试。但它们的致命伤是页面一改脚本就得跟着改维护成本跟 UI 迭代频率成正比。ARTEMIS 换了个思路不再描述怎么操作而是描述做什么。它牺牲了精确性换来了对 UI 变化的鲁棒性。同一个任务指令页面换了十次布局Agent 每次都能根据当时的屏幕状态自己想办法完成。这才是真机测试现阶段最稀缺的能力——自适应。我做了个简单对比方便你判断各自的使用场景维度AppiumUIAutomatorMaestroARTEMIS定位方式XML/XPathResource-id文本/ID视觉语义维护成本高高中低对 UI 变化的鲁棒性弱弱中强执行速度快快中中偏慢适合场景回归测试系统级测试快速流程验证探索性测试、复杂交互5.2 探索性测试ARTEMIS 的主战场所谓探索性测试就是让测试人员不按既定脚本凭经验和直觉在应用里到处乱点看看能不能发现非预期的问题。这一类测试最能体现人的价值但也最耗人力。ARTEMIS 首次让 AI 具备了在真机上乱点的能力而且是有逻辑地乱点。举一个我实际跑过的场景。我给它下达了一个非常开放的任务检查这个应用的个人中心页面找出所有可能崩溃的入口。ARTEMIS 会自行进入个人中心遍历每个菜单项遇到界面跳转会返回到上一页遇到非预期页面会在日志里标注。整个过程像是一个不知疲倦的初级测试员在帮你做冒烟巡检虽然它不会像资深测试那样提前预判风险但至少能帮你把低级的页面崩溃问题筛掉一轮。5.3 哪些场景不建议用 ARTEMISARTEMIS 现阶段的能力边界也很明显。凡是对操作精度和速度有硬性要求的场景都不适合它。比如支付流程的回归测试每次点击的坐标必须严格精确ARTEMIS 的视觉定位偶尔会有像素级偏差这种场景下我压根不敢用它。再比如需要大量设备并行执行的自动化任务ARTEMIS 在每台设备上都要占用几百 MB 内存做模型推理对测试机群配置要求很高而且并行规模一上来PC 控制端的任务调度压力也会陡增。所以我的建议是把 ARTEMIS 定位成一个新的测试能力补充而不是替代现有自动化体系。Appium 继续负责你的回归保障ARTEMIS 负责那些连脚本都不知道怎么写的探索性测试和复杂真实用户路径验证。一条腿走路的人走不快两条腿才行。6. 真实反射回来的经验ARTEMIS 能落地的三个最佳场景6.1 真机兼容性测试的前置筛选手真机兼容性测试最烦的不是测而是机型太多测不过来。我之前一直是一台一台手动操作或者让开发配合修脚本效率极低。有了 ARTEMIS 之后我可以把核心用户路径巡检这种任务派给它去做下载 App、打开、注册、登录、浏览首页、进入详情页、加购、退出。所有操作以自然语言描述不需要为不同机型写不同脚本因为它靠视觉理解 UI不同机型上同一功能的不同布局对它来说只是长的不一样而已。这为你省掉的不是一两个小时而是每个机型一两个小时的重复劳作。我拿它跑了十几台不同品牌机型整体识别成功率能达到 80% 以上剩下的失败点主要集中在国产 ROM 的系统弹窗和异常引导页上。6.2 用诡异指令发现产品逻辑漏洞这个用法是我最惊喜的部分。把 ARTEMIS 当成一个听话但不太懂事的用户给它下达一些不符合常理的操作指令比如先点登录再退回再点登录重复五次观察是否出现异常或在弱网环境下反复切换页面看会不会出现崩溃。传统脚本很难写这种逻辑因为你自己都不知道预期结果是什么但 ARTEMIS 能执行。我靠这种方式发现过两个比较隐蔽的问题一个是快速重复点击登录按钮时出现了重复提交订单的 Bug另一个是从 A 页面极速跳 B 页面时出现了白屏。这些场景写自动化脚本的话要花不少精力而 ARTEMIS 几分钟就能帮你跑完一条路径效率上的优势是肉眼可见的。6.3 回归测试的冒烟先行哨兵如果你担心 ARTEMIS 的稳定性无法承担完整回归可以拿它做冒烟测试的先遣队。每次发版前先让 ARTEMIS 把核心用户路径快速走一遍发现问题后人工确认再把稳定的路径固化成 Appium 脚本放进 CI。这个逻辑本质上是让 AI 当排雷兵让人力去处理真正有价值的部分。我使用了几周后的感受是ARTEMIS 的定位不是替代测试人员而是把测试人员从重复劳动里解放出来。以前我们花在机械操作上的时间至少占一半现在这部分可以交给它我们腾出精力去设计更复杂的测试策略、去分析更深层的质量隐患。这可能是 AI Agent 在测试领域最值得期待的方向。6.4 几个值得留意的后续扩展思路最后分享几个我还在探索的方向。第一个思路是把 ARTEMIS 跟自动化发布流水线结合起来用它做灰度包上线的健康检查跑通了再走全量发布。第二个思路是干脆让它按预设的 Prompt 模板自动执行崩溃回归测试比如多次冷启动、后台切换、音视频打断这些场景传统脚本不太容易覆盖。第三个思路则是把多机型的 ARTEMIS 结果汇总起来按失败模式聚类分析反推出哪些页面设计对模型不友好——这个信息其实也能侧面反映真实用户的理解成本。只要你的诉求是减少纯手工操作、提升真机测试的效率上限ARTEMIS 就值得一试。我第一次跑通它时的惊喜感到现在都还记得虽然审计一下问题也不少但方向是对的。测试这个行业苦脚本维护久矣现在终于有了一种不那么脆弱的解法我当然愿意继续在这个方向上多花时间。