ARTEMIS 落地实录当 AI Agent 接管 Android 真机测试我们该怎么用搞了这么多年移动端测试我见过太多团队困在同一类问题上用例维护成本越来越高、机型碎片化越铺越大、回归测试的时间窗口永远不够用。所以当 Google 把 ARTEMIS 这套基于 AI Agent 的 Android 真机测试方案开源出来时我第一时间就扎进去试了一遍。今天这篇东西就是想把这段时间的实操经验、踩坑记录、架构理解和二次开发思路都摊开来讲清楚。先简单说结论ARTEMIS 不是又一套自动化测试框架它把 AI Agent 的角色从单纯的给你提建议推进到了直接操作真机解决问题。它能在真实设备上完成意图理解 → 目标拆解 → 操作执行 → 结果验证的完整闭环这意味着以往需要人手动维护的繁琐脚本逻辑可以由 Agent 根据当前界面状态动态生成和执行。对于测试工程师、DevOps 团队、以及所有做 Android 系统级和应用级质量保障的人来说这套思路可能会改变你对自动化测试这个词的理解。1. 为什么 AI Agent 会盯上 Android 真机测试在聊 ARTEMIS 的架构之前我们得先想明白一个问题为什么传统自动化测试走到了瓶颈而 AI Agent 恰好能补上这个缺口1.1 传统自动化测试遇到的三个老难题第一是用例维护成本。做过 UI Automator 或者 Espresso 的人都有体会应用每改一次布局测试脚本就要跟着改一轮 ID、XPath 或者坐标碰上动效频繁改版的应用测试代码的维护量能赶上业务代码。第二是场景覆盖的深度。现有框架大多擅长按既定路径走流程但不太擅长处理意外情况。弹窗遮挡、权限请求、网络延迟导致的加载态变化这些在真机上随处可见的干扰因素写脚本时要么直接忽略要么就要写一大堆条件判断把脚本搞得臃肿不堪。第三是真机环境的碎片化。不同厂商的定制 ROM、不同分辨率、不同 Android 版本的控件渲染差异让一套脚本跑遍所有机型基本是奢望。传统做法是为常见机型维护多套配置但这背后的工作量是持续增长的。1.2 AI Agent 的核心能力与测试场景恰好互补AI Agent 在 ARTEMIS 里的定位不是帮你写脚本而是把测试目标交给他让他自己去看、自己去想、自己去动手。底层大模型LLM在这里承担了两个职责一是理解你发出的自然语言指令比如打开设置并切换到飞行模式二是根据当前屏幕截图和界面结构推理出下一步应该点击哪里、输入什么。这种模式的优势在于天然具备跨版本、跨机型的自适应能力。因为 Agent 每次都是基于当前的界面状态来做决策而不是依赖写死的定位表达式所以哪怕应用界面变了驱动的逻辑始终是看屏幕 → 判断 → 操作不需要预埋太多选择器。能够处理长链路、多步骤的复杂任务。像注册一个新账号并完成首次登录引导这种需要十几步交互的流程人可以轻松做但传统脚本会非常繁琐。ARTEMIS 可以直接把任务丢给 Agent他会自己规划步骤并执行。测试结果反映的是真实用户体验。因为 Agent 的操作依据是视觉信息和界面语义它更容易发现那些代码没报错但用户觉得不对劲的问题比如按钮遮挡、文案重叠、状态未刷新等。1.3 ARTEMIS 背后的设计哲学Google 这套方案比较有意思的地方在于它并不追求用一个大模型解决所有问题而是设计了一个多模块协同的架构体系。整个流程类似于真人测试工程师的工作方式先看需求理解用户任务再看屏幕UI 状态感知动手点击动作生成检查结果验证与反思。这个理念我觉得是 ARTEMIS 最值得借鉴的地方它把传统自动化和纯大模型驱动做了个折中既保留了对真实设备的全权控制又引入了大模型的推理能力来应对动态场景。2. ARTEMIS 核心架构与技术拆解把 ARTEMIS 的源码拉下来跑通之后我花了很长时间去梳理它的模块设计。这个项目的代码组织其实非常清晰核心可以拆成四个层次环境交互层、状态感知层、决策规划层、执行验证层。2.1 环境交互层如何拿到真机控制权这一层解决的是最基本的手脚问题。ARTEMIS 通过 Android 官方的UIAutomator和ADBAndroid Debug Bridge来与设备交互。UIAutomator 负责提供界面元素的结构信息比如当前屏幕上所有可点击控件的坐标、文本、资源 ID、类型等。这些信息会以 JSON 格式传给上层作为 Agent 的眼睛。ADB 则负责执行具体的输入指令包括 tap、swipe、输入文本、按键、截屏等操作。实操上需要注意一个细节UIAutomator 拿到的界面层级是 XML 格式的但在传递之前的预处理中ARTEMIS 做了严格的过滤只保留可见且可交互的元素。这个非常关键因为原生 XML 层级里充斥着大量不可见的占位布局、隐藏控件如果一股脑全丢给大模型token 消耗会非常夸张而且会干扰决策。从代码里可以看出ARTEMIS 对 XML 的处理做了一定程度的精简压缩把每个控件映射成一个简短描述例如Button: 保存(Save)或者TextInput: 搜索(Search)。我后面在做二次开发时也沿用了这个思路效果立竿见影决策准确性明显提升。2.2 状态感知层Agent 的眼睛应该怎么长光有 UI 层级还不够很多界面的语义信息难以从 XML 里准确获取比如图片的颜色、布局的疏密、图标的状态变化。所以 ARTEMIS 同时利用了屏幕截图作为视觉信息输入。这里有一些值得注意的实现细节。项目设计了一套视觉编码 Pipeline首先通过 ADB 截取当前屏幕使用screencap命令获取 PNG 格式图片然后对图片做缩放处理适配大模型的视觉输入尺寸避免超大分辨率图导致推理效率低下最后将缩放后的图片与 UI 树信息一起作为 Prompt 的组成部分送入大模型。这套设计模拟了人眼的工作机制——既看整体截图也看细节UI 树。实测下来没有截图只有 UI 树或者只有截图没有 UI 树任务成功率都会显著下降两者缺一不可。2.3 决策规划层Agent 如何思考下一步动作这是 ARTEMIS 最具核心价值的模块。当 Agent 拿到当前状态截图 UI 结构之后它需要做出决策。ARTEMIS 采用了一种类似ReActReasoning and Acting模式的 Prompt Engineering 思路首先让模型对当前任务目标进行内部推理Thought然后输出一个具体的操作Action。决策结果被约束为结构化 JSON 格式包含几个关键字段action 类型点击click、输入input、滑动swipe、等待wait、返回back、启动应用launch等action 参数比如点击的目标元素 ID、输入的文字内容、滑动的方向和距离reason 字段模型需要描述自己为什么做出这个决策方便后续的日志检查和排障。这个先推理、后决策、再行动的模式好处在于大幅减少了误触概率。我在测试一个电商应用的下单流程时观察到 Agent 在遇到是否确认退出弹窗时会先思考几秒钟然后选择点击取消而不是直接确认这是传统脚本很难达到的语义理解水平。2.4 执行验证层从做过了到做对了做自动化测试的人都知道真正难的不是把操作发出去而是确认操作是否真的生效了。ARTEMIS 在这一层做了两件事动作执行后强制重新获取一次 UI 状态和截图用于和操作前的状态做对比判断任务是否已经可以结束如果有多个子目标还要判断哪些已经完成、哪些还卡住了。对比逻辑的实现基于大模型对视觉信息变化的判断力。比如我们执行了点击登录按钮之后Agent 会观察新截图里是否出现了用户头像或者是否跳转到了首页如果没有它会判断为操作失败并尝试重新规划路径。这种闭环验证机制让 ARTEMIS 在长任务执行中的容错性远远好于传统的线性脚本也是它真正能接管测试过程的底气所在。3. 从零搭建ARTEMIS 部署与真机接入实操理论部分说了不少接下来进入实操环节。这里我把整个部署和调试过程整理成了一个可以直接照抄的流程假设你的环境是 Ubuntu 20.04/22.04 LTS 加上 Android Studio 已配置完成。3.1 环境准备清单与版本注意事项先回答一个问题ARTEMIS 需要什么配置的机器才能跑起来我个人的建议是至少 32GB 内存 支持 CUDA 的 Nvidia 显卡显存 8GB 以上。如果没有本地 GPU也可以使用云端的 LLM API但注意看项目的配置支持情况因为很多开源项目默认走的是本地推理。必备组件如下表组件版本要求说明Python3.10 及以上核心运行时Android SDKAPI 30 以上真机调试依赖ADB最新版设备通信UIAutomator22.x 系列界面层级获取PyTorch2.0 以上LLM 推理框架LLM 模型LLaMA-3 8B 或 Qwen 2.5 7B推荐测试稳定的模型真机Android 10 及以上推荐 Pixel 或主流国产机3.2 部署三步走克隆、配置依赖、启动推理服务第一步克隆项目并创建虚拟环境git clone https://github.com/google/artemis.git cd artemis python3 -m venv venv source venv/bin/activate pip install -r requirements.txt这里要注意requirements.txt里对某些底层库的版本有严格绑定如果你本机有其他 Python 项目强烈建议用虚拟环境隔离不然很容易出现 CUDA 版本或torch版本冲突。第二步配置模型与设备信息。项目的配置目录下通常会有一个config.yaml或类似命名的文件核心需要改两个地方模型路径设备和 ADB 设备序列号。model: type: local path: /path/to/your/llama-3-8b-instruct device: serial: your_device_serial获取设备序列号的方式是连接真机后执行adb devices输出中第二列是device的那一行第一列就是序列号。如果是无线调试连接的设备序列号通常是ip:port的格式。第三步启动推理服务并运行首条测试任务。如果你使用的是 vLLM 或 Ollama 作为推理后端需要先确保服务处于监听状态然后再启动 ARTEMIS 的主程序。启动后你可以用自然语言提交任务python run_artemis.py --task 打开相机应用拍摄一张照片然后返回桌面这里跑通后你应该能在终端看到 Agent 的思考日志和每一步的动作输出真机界面上会同步出现点击和滑动的操作。3.3 真机连接时的三个常见配置坑我在不同机器上反复部署过几次有三个真机接入的坑是出现频率极高的。第一个坑UIAutomator 初始化超时。有的真机特别是国产 ROM默认开启了权限悬浮窗或者USB 安装限制导致uiautomator2初始化的时候无法正常推送测试 APK。解决方法是先手动安装一次 ATX Agentuiautomator2 的配套服务并且把USB 调试安全设置打开允许模拟点击。第二个坑不同机型的 ADB 授权弹窗。首次连接真机时手机上会弹出是否允许 USB 调试的对话框如果没点始终允许脚本执行到一半可能断掉。建议连接后第一时间执行adb shell input keyevent 82或直接手动解锁屏幕确保设备处于活跃状态。第三个坑分辨率对视觉模型的影响。很多真机的默认分辨率是 1080p 或者 2K直接截屏喂给视觉模型的 token 消耗会非常大。ARTEMIS 虽然做了缩放处理但建议在系统层面把开发机的模拟显示大小调低或者直接使用分辨率低一些的测试机比如 720p实测下来整体效率会高很多。4. 测试场景拆解从交互事件流到最终测试报告部署跑通之后真正的重头戏在于设计测试任务和解读 Agent 的执行结果。ARTEMIS 能做什么、不能做什么和你怎么给它下指令有非常大的关系。4.1 如何给 Agent 下达一条好任务很多第一次接触 ARTEMIS 的人会犯一个错误把任务描述得跟需求文档一样长觉得写得越详细越准确。但实测下来冗长的描述反而会干扰 Agent 的判断因为大模型的注意力会被无关上下文稀释。好的任务描述应该满足三个条件目标明确把 Wi-Fi 打开比我想上网请帮我配置一下网络设置更高效边界清晰如果不需要登录就明确说不需要登录直接进入首页可验证任务里包含完成的标志比如直到页面显示订单已提交字样。我常用的任务模板是任务完成 [目标功能] 的端到端验证。 前置条件[描述初始状态比如应用已安装未登录]。 操作路径[可选描述关键步骤或者功能入口可以从首页右下角的图标进入]。 通过标准[明确描述什么样的界面状态代表任务成功]。 附加要求[描述需要避开的干扰比如不要点击广告弹窗]。加了最后一条附加要求之后Agent 面对测试过程中突然弹出的广告国内应用很常见时基本都能正确规避这个技巧非常实用。4.2 执行过程和结果验证的观察要点任务执行过程中建议把日志级别调成 DEBUG 模式这样才能看到 Agent 的完整思考链路。我在跑一个复杂任务时——从应用商店下载一款应用并完成首次启动的引导——截取到的核心日志大概长这样[THOUGHT] 用户要求安装应用并完成引导。当前在商店首页需要先点击搜索框。 [ACTION] click(idsearch_box) [OBSERVATION] 搜索框已获焦键盘弹出。 [THOUGHT] 输入应用名称。 [ACTION] input(textexample_app) [OBSERVATION] 搜索结果出现第一条匹配应用。 [THOUGHT] 点击安装按钮注意不要点击广告卡片。 [ACTION] click(text安装) [OBSERVATION] 进入下载安装状态等待完成。 [THOUGHT] 等待安装过程结束。 [ACTION] wait(seconds20) [OBSERVATION] 安装完成出现打开按钮。 [ACTION] click(text打开)这种思路链路的完整记录是 ARTEMIS 最宝贵的东西。排查问题的时候你能精确看到 Agent 在哪一步判断错了、在哪一步被界面误导了而不是像传统脚本那样只有一堆断言失败的堆栈信息。4.3 产出什么样的测试报告才有价值ARTEMIS 本身会输出一份 JSON 格式的任务执行报告包含每个步骤的时间戳、动作类型、状态标记成功/失败/重试、模型推理摘要等。但很多人忽略了一个点这份原始报告还不能直接交给团队或者客户看需要做二次加工。我习惯在 ARTEMIS 输出之上再加一层轻量级的自动化工具生成一份包含以下内容的测试报告步骤截图拼贴把关键步骤的截图按时间线拼接直观展示操作过程延迟分析与异常统计统计每一步的耗时标记出超过阈值的步骤失败分类表如果是多任务并发执行按照失败原因归类界面变更、网络超时、权限拦截、模型误判等。这样一来测试报告就从一个技术工具的输出变成了一个项目沟通的产物价值完全不一样。5. 常见问题与排查技巧实录最后这部分我把自己在 ARTEMIS 实际使用中遇到的问题和对应的排查思路整理成一张速查表希望能帮你少走点弯路。这些问题有些是项目本身的限制有些是环境问题但都很典型。症状可能原因排查与解决Agent 无法获取 UI 层级一直报空页面是原生 Canvas 绘制或 WebView 渲染确认 WebView 调试开关是否打开部分游戏或自绘 UI 场景需要纯视觉驱动模式点击目标经常偏移或失效屏幕分辨率与 UI 树坐标比例不一致检查是否启用了系统级显示大小缩放重置为默认值执行速度很慢单步要好几秒模型推理耗时 UI 刷新等待时间尝试用轻量模型做动作决策或开启并行预加载减少不必要的状态轮询频率任务进行到一半突然中断ADB 连接不稳定或设备锁屏开启充电时屏幕不休眠并设置锁屏为无检查 USB 线是否存在松动模型总是忽略任务的核心要求Prompt 描述里信息过载精简任务描述把核心动作拆成前置条件使用通过标准字段强化目标面对弹窗和广告时容易误点模型任务里缺少规避性指示在 Prompt 中增加拒绝类指令如忽略所有非目标弹窗或者用规则层先过滤掉广告控件5.1 这个坑必须单独说模型幻觉导致的伪成功在众多问题里我想单独拎出来聊一个非常隐蔽的坑模型有时候会假装自己成功了。什么意思就是 Agent 在某个步骤执行后并没有真正验证界面变化却直接给出了操作完成的判断。比如点击了提交按钮但实际上后端返回了校验错误弹出提示框被遮挡了Agent 观察截图后觉得页面变化了应该成功了就草草结束了任务。这个问题的根源在于视觉编码 pipeline 对细微状态变化不敏感。解决思路有两条一是在 Prompt 中明确要求操作完成后必须验证关键文本或关键图标是否出现二是在 ARTEMIS 的验证层增加一个规则引擎对某些关键任务比如支付成功强制校验 UI 树中是否存在特定的文本节点。如果你有代码能力我强烈建议在验证层做这个二次检查它能极大提升测试结果的可靠性。5.2 多设备并发测试的可行性探讨很多人会问ARTEMIS 能不能同时控制多台设备做并行测试直接回答可以但需要改代码。原项目默认是单设备模式不过架构上预留了并发能力的空间。我自己的做法是给每台设备起一个独立进程每个进程绑定不同的 ADB 序列号然后用一个任务调度器去分配用例。这里有个细节要注意多设备并发时模型推理的吞吐量会成为瓶颈。如果本地显卡只有一张 8G 显存的卡同时跑两个 Agent 任务推理时延可能会翻倍导致整体效率反而不如串行。最好的方案是给不同设备分配不同的模型副本或者使用量化模型减少显存占用。5.3 安全与权限配置的合规建议最后说一下权限配置。由于 ARTEMIS 需要模拟点击和输入所以测试机上必须开启USB 调试和模拟点击权限。这里不涉及任何敏感话题但从工程规范的角度我建议团队内部做好两类管理测试设备尽量使用专用测试机不要把开发同事的日常用机拿来跑自动化涉及账号密码等敏感数据的测试任务用一个隔离的测试环境或者测试专用账号避免污染真实数据。6. ARTEMIS 的延伸思考从哪里来到哪里去ARTEMIS 作为一个开源项目的价值其实远超一个工具的范畴。我更愿意把它看作一条路径让大模型从信息处理系统向操作系统代理迈进的参考样本。6.1 不只做测试Agent 操作手机的未来场景测试只是入口ARTEMIS 所建立的这套视觉感知 语义推理 操作执行 闭环验证的通用范式实际上是在重新定义自动化工具的形态。仔细想一下这套范式可以平移的场景其实非常广应用商店的自动化审核自动安装、启动、检查崩溃、手机系统级功能的批量验证飞行模式切换、定位权限调度、辅助功能的可及性测试在大字体、高对比度设置下验证页面是否正常、甚至是用户侧的自动化助手——比如自动帮你完成繁琐的 App 内签到流程。这些场景的共同点在于操作路径多变、界面状态复杂、但目标意图非常明确正是 AI Agent 的优势区间。6.2 对测试团队岗位能力的新要求ARTEMIS 这类工具出来之后很多测试同学会焦虑岗位是不是要被 AI 取代了。从我实际的使用体验来看这种担心至少短期内是多余的但技能结构确实需要升级。以前测试的核心技能是写脚本和搭框架现在 ARTEMIS 把大部分脚本工作替代掉了新的核心技能变成了三样任务拆解能力能把一个复杂的业务验证需求拆解成 Agent 能理解的、边界清晰的原子任务Prompt 工程能力能通过指令设计控制 Agent 的行为边界让它不被无关信息带偏异常归因能力能在 Agent 执行失败时快速判断是界面问题、模型推理问题还是环境问题。换句话说测试工程师的定位正在从手工执行者转变为流程设计者和结果审查者。这个转变早发生早受益。6.3 后续扩展方向给跃跃欲试的实践者一个建议如果你已经跑通了基础的 ARTEMIS想往纵深去挖掘价值我个人建议从下面三个方向里挑一个试试看接入 CI/CD 流水线。把 ARTEMIS 作为回归测试的兜底环节每天晚上自动跑一遍核心业务链路第二天早上把报告发到团队群。别小看这一步它能极大缩短发布前的手工冒烟时间。建立私有 Prompt 库。针对自己产品的常见测试场景沉淀一批高质量的任务模板形成团队内部的测试知识库新人来了直接调用即可。改造状态感知模块。如果你有一个特别擅长的垂直业务可以尝试把它的关键状态做成规则校验器和模型推理做双保险人工审核成本会大幅下降。写在最后ARTEMIS 给我最大的启示不是模型变强了而是工具的使用方式变了。传统自动化测试要求人屈就机器的逻辑写脚本、定规则、维护用例ARTEMIS 则让机器来理解人的意图把我要什么变成交互的核心而不是我怎么一步步点。当然它目前远算不上完美。模型误判、执行效率、多设备协同、复杂业务场景下的稳定性这些都还有很大的优化空间。但也正因为这些不完美才给了从业者参与其中、共同演进的机会。如果你正在做 Android 测试相关的工作我建议你找个周末把它部署起来拿一个真实业务场景跑一遍你一定会对测试这件事产生新的理解。