我们团队最近在折腾 Android 真机测试自动化的时候发现了 Google 开源的 ARTEMIS。这个项目全称有点拗口叫 Advanced Robotic Test Enhancement / Management Intelligence System本质上就是一个用 AI Agent 接管真机测试的智能体框架。拆开来看Google、ARTEMIS、AI Agent、Android、真机测试这几个关键词组合在一起解决的正是传统自动化测试脚本维护成本高、UI 变化就崩、真机适配难搞的痛点。这篇文章我想从整体设计、核心组件、实操落地、常见坑几个方面把 ARTEMIS 怎么接管安卓真机测试这件事讲透适合正在做客户端测试自动化、想引入 AI Agent 的团队也适合对 LLM 落地感兴趣的个人开发者。1. ARTEMIS 到底是什么为什么 Google 要把它开源1.1 一个能“看懂”屏幕的测试 Agent先说结论ARTEMIS 不是一个普通的自动化测试框架它是一个结合了大语言模型和计算机视觉的智能体专门跑在 Android 真机上。和传统框架最大的区别是你不用再写死 UI 元素的定位表达式也不用为每个页面状态维护一堆 check 逻辑ARTEMIS 通过截图直接理解屏幕内容然后自主决定下一步操作。官方仓库里写得很清楚ARTEMIS 面向的是“非编程式”的使用方式。什么意思就是你给这个 Agent 一个自然语言指令比如“打开设置把屏幕亮度调到 50%”它会自己在真机上找到设置入口、定位亮度条、执行滑动操作然后验证结果。整个过程不需要你写一行测试代码也不需要你事先录制脚本。这个能力背后是三大核心组件配合工作Widget Capturer 负责从真机屏幕截图里捕获和描述 UI 组件LLM Agent 负责理解自然语言指令并推理操作步骤Action Executor 负责把推理结果变成真实的触摸和手势动作。三者就像一个人的眼睛、大脑和手。Google 把这个项目开源本质上是在推动一个测试领域的范式转变。传统 UI 自动化测试的花费大头不在用例编写而在于维护。App 每改一次 UI测试脚本就要跟着改一遍定位路径这对任何团队都是持续的隐性成本。ARTEMIS 的思路是用模型能力去对抗这种变化UI 改了Agent 重新看一眼屏幕就能继续工作。1.2 不是又一个测试框架而是一次范式切换市面上做 Android 自动化的框架不少Appium、UIAutomator、Espresso 都是成熟方案。这些方案的核心逻辑都是“找到元素执行操作”问题在于元素定位的脆弱性以及脚本对页面结构的强依赖。ARTEMIS 的切入点完全不同。它把测试过程拆成了“观察 — 推理 — 行动”的循环而不是“定位 — 操作 — 断言”的线性执行。观察环节是纯视觉的不依赖 View 层级推理环节是大模型驱动的能理解模糊意图行动环节则直接模拟用户手势。从架构角度看这个设计想解决的问题其实有两个。第一个问题是代码级定位的脆弱性第二个问题是测试用例表达能力的上限。传统脚本很难描述“拖动页面直到看到某个内容”这种模糊操作但大模型天然擅长处理这种开放式指令。Google 把 ARTEMIS 开源还有一个现实动因Android 生态太碎片化。不同厂商的系统 UI 定制差异极大同一操作在不同机型上的入口路径可能完全不同。传统脚本很难覆盖这种差异而一个基于视觉理解的智能体天然具备跨设备迁移的能力。你在 Pixel 上学会了操作设置页到了小米手机上只要重新看一眼屏幕就能举一反三。2. 三大组件的设计拆解从截图到动作的完整链路2.1 Widget Capturer把像素变成结构化语言Widget Capturer 是 ARTEMIS 的视觉基础层负责从真机屏幕截图里识别 UI 组件并把它们用自然语言描述出来。这里用的是目标检测模型不是 OCR也不是简单地调用 Accessibility 服务拿布局树而是真正在图像层面识别按钮、输入框、滑块等组件。我一开始有点疑惑为什么不用现成的 View 层级信息统框架拿 UI 树不是更精确吗细看设计才发现Google 是有意去掉这条路线的。依赖 View 层级意味着又要回到“绑定某个框架”的老路上而纯视觉方案可以工作在任意应用上不需要应用侧做任何接入。Widget Capturer 输出的内容很有意思它不只是给出“这是什么类型的组件”还会附加“组件在哪里”“组件上的文字是什么”“组件的可见状态如何”这些属性。整体看下来它就是像素和语言之间的翻译器把一张截图变成一段结构化的 UI 描述文本。这里有一个技术细节值得展开组件间的层级关系。屏幕上不可能只有一个按钮所以 Widget Capturer 需要在同一张截图里输出多个组件的完整列表包括组件类型、坐标区域、文本内容、层级关系。这些信息最终会拼接成一个类似 HTML 结构的 UI 描述交给 LLM 去推理。在实践角度这个组件的效果直接决定整条链路的上限。如果识别结果漏掉了关键组件后面模型推理得再准也没用。根据 UIUCTX 数据集的相关资料Widget Capturer 经过专门数据集的训练对常见 Android 原生控件和主流第三方控件都有较好覆盖。2.2 LLM Agent用语言模型替代测试用例LLM Agent 是 ARTEMIS 的决策中枢它的任务是“读懂意图拆解动作”。用户给的指令可能是“打开飞行模式”这样的单一操作也可能是“帮我设置一个明天早上 8 点的闹钟”这样的复合任务。Agent 需要把复合任务拆解成多个单步操作然后逐步执行。ARTEMIS 在这里用了分层推理的模式。简单任务走 Vision-only 模式只靠屏幕截图就能完成复杂任务走 Vision Text 模式会额外的文字描述信息参与推理。这个设计我一直觉得是 ARTEMIS 最聪明的地方因为它没有一股脑地把所有计算量都堆到大模型上而是根据任务复杂度动态选择推理路径兼顾速度和准确率。指令理解和拆解这一块LLM Agent 表现出的能力远超传统脚本的边界。它能理解“把亮度调低一点”这种相对模糊的表达能结合当前屏幕状态推测“调低一点”具体对应多大的滑动距离。传统脚本只能执行精确指令而 Agent 可以在不确定中做出合理推断。细看 Prompt 设计ARTEMIS 给 LLM 的输入包括了任务描述、UI 结构和历史操作记录。换句话说Agent 不是每一步都盲猜它知道之前做过什么、当前屏幕是什么状态然后基于这些上下文决策下一步动作。这种带记忆的推理机制是避免 Agent 在原地打转的关键。2.3 Action Executor让动作真正落在屏幕上Action Executor 是最终手的角色负责把 LLM 的输出变成真机上的真实操作。LLM 给出的不是一个坐标点而是携带完整语义的动作标签和位置描述Action Executor 再把这些标签映射成真正的点击、滑动、输入等手势。这里有一个容易被忽略的设计位置不是用绝对像素坐标而是用相对描述。搜索引擎里经常看到“左侧”“右侧”“上方”“中心”这些词实际上 LLM 输出的位置描述就是这种语义化的形式。这样的好处是屏幕分辨率或布局发生变化时Agent 不需要重新计算坐标只要语义描述依然成立动作就能正确执行。动作类型方面ARTEMIS 支持点击、滑动、键盘输入、返回、等待、全局导航这些常见操作。值得注意的是它考虑了等待操作因为真实应用中很多时候需要等待页面加载或动画完成没有等待机制的自动化测试会疯狂失败。从手感的体会上讲Action Executor 做的一个比较重要的取舍是它不做像素级的精细触控而是做语义级的粗粒度操作。这个取舍很务实因为多数测试场景不需要像素级精度用户看到的是一个按钮就点那个按钮而不是精确到某个坐标点。2.4 分层推理什么时候只看图什么时候图文结合ARTEMIS 的分层推理是理解这个项目设计哲学的一把钥匙。Vision-only 模式只依赖屏幕截图推理速度快、token 消耗少Vision Text 模式则额外引入文本信息理解更充分但延迟更高。实际场景中哪种任务适合哪种模式从设计意图看简单且目标明确的单步操作比如“点击登录按钮”“返回到上一页”走 Vision-only 就足够了。这类任务只涉及当前屏幕的视觉信息不需要额外的文字背景。而像“按步骤完成注册流程”这类任务每一步之间存在逻辑关联需要理解完整的指令文本就必须走 Vision Text 模式。这个设计对实际部署的启发是如果业务场景相对固定且操作偏单步可以强制用 Vision-only 模式来降低延迟和成本。如果场景复杂、需要多步协同就得接受 Vision Text 模式的性能开销。从我自己了解的情况来看分层推理还有一个好处是系统可控可降级。哪天大模型 API 出问题或者响应太慢管理员可以临时把复杂任务降级为单步指令至少保证重要路径还能跑。这个容灾设计是生产环境里很务实的一点。3. 实操要点怎么把 ARTEMIS 跑起来并让它干活3.1 环境准备与真机连接先把环境配置讲清楚。ARTEMIS 依赖 Android 开发环境adb 是必须的建议使用最新版 Android Studio 附带的 platform-tools。真机连接要注意开启开发者模式和 USB 调试部分机型还要关闭“USB 安装监控”避免调试过程中频繁弹窗影响自动化。连接真机后先用 adb devices 验证设备是否在线。这里有个细节如果设备状态显示 unauthorized说明 USB 调试授权弹窗没确认或者被拒绝了需要重新插拔并手动确认。ARTEMIS 执行动作依赖 adb 的 input 命令和 screencap 命令这两个命令在 shell 里可用是硬性条件。接下来是模型环境。ARTEMIS 的视觉部分需要部署目标检测模型这部分需要 GPU 资源LLM Agent 则依赖大模型推理服务。官方支持本地部署也可以调用云端的推理 API。部署时要注意性能瓶颈大概率出现在视觉理解和 LLM 推理上如果你发现整个流程跑起来非常慢先查这两块的耗时再决定要不要升级硬件。3.2 浏览模式让 Agent 自由探索ARTEMIS 支持两种工作模式。浏览模式是探索式的Agent 不会预先设定目标而是在真机上自由操作观察不同的 UI 状态把这些经验沉积到模型里让它对应用有更全面的“手感”。这种模式比较适合冷启动阶段。比如一个新的 App 第一次接入 ARTEMIS可以让它在浏览模式下溜达几圈熟悉常见页面的 UI 布局之后再切到指令执行模式跑具体用例效率会高不少。本质上就是让模型先做一轮预热学习。实际操作中我个人体会是浏览模式还有另外一个价值用来自动生成页面状态列表。Agent 逛过的页面、见过的组件、遇到过的弹窗这些信息都能沉淀下来后续测试设计时可以直接参考哪些页面需要覆盖、哪些弹窗需要处理。浏览模式要注意给 Agent 设定迭代轮次上限避免它在一个页面上无限点击。实现层面需要控制 Agent 的动作频次和单轮迭代数实际测试中我会先跑 30 到 50 步观察轨迹是否符合预期再逐步放开。3.3 指令执行模式写清操作提示词的四个要素指令执行模式才是把 ARTEMIS 用起来的核心场景。在这个模式下你给 Agent 一段自然语言任务描述它会自动拆解步骤并执行。但这里有个新人很容易踩的坑提示词写得太随意Agent 只能在模糊的起点上摸索。根据 ARTEMIS 的实践建议好的操作指令应该包含四个要素明确的操作目标、可验证的完成条件或结果预期、涉及的关键操作对象、需要规避的约束比如不要点击广告位。举例“打开设置里的 Wi-Fi 并连接指定的测试热点”比“帮我连个 Wi-Fi”清晰得多后者 Agent 连连哪个热点都不知道。官方给出的操作提示词形式是先定义任务背景再给具体的指令内容。如果任务涉及多个连续步骤最好拆分成有序列表让 Agent 按序执行。ARTEMIS 的 LLM Agent 理解和处理自然语言指令的能力是强项但清晰、具体、有约束条件的指令仍比模糊表达可靠得多。执行反馈这块也值得说。每步执行后Agent 会截取新屏幕并更新状态如果动作没有产生预期变化它会尝试换一种操作方式。这里有一个容错机制如果连续多次尝试都没有效果Agent 会停止并上报失败原因而不是无限重试把手机弄到卡死。3.4 数据集与训练资源想自训该去哪里找数据如果你想在 ARTEMIS 的框架基础上做二次开发或领域微调得先了解它背后的数据。Google 使用了 UIUCTX 数据集进行训练包含 12,754 条人工标注指令和 15,421 个动作序列。这个数据集覆盖了大量真实 Android 应用场景是理解“指令 — 动作”映射关系的关键素材。这里需要说明Google 开源 ARTEMIS 的定位是把整个技术方案开放出来但部分说明文档和思路仍见诸于论文、技术博客和 AI 新闻头条。直接拿来数据集用的前提是遵守相应的使用许可。如果你的业务是垂直领域的 App比如只做金融类或只做视频类建议基于业务场景补充一些自定义数据再做微调。纯通用数据集在通用 App 上表现好但到特殊领域专业术语和交互模式可能会让 Agent 理解有偏差。微调的时候还需要注意平衡只做视觉模型的微调而不动语言模型Agent 可能看得懂界面但推理跟不上两头都调成本又很高。比较稳妥的做法是先固定 LLM只调 Widget Capturer让 UI 识别准确率上来之后再考虑端到端联合调优。4. 常见问题与排查技巧实录4.1 真机连接不上或执行器报错常见的第一个坑是 adb devices 能看到设备但 Action Executor 执行时报错比如 “Cant find service: window” 或者 “Could not read input events”。这类问题的根源通常是设备上的 shell 权限不完整或者系统 UI 有定制导致 input/screencap 行为异常。排查思路是分两步先确认 adb shell input keyevent KEYCODE_HOME 能不能让手机回桌面再确认 adb shell screencap -p /sdcard/screen.png 能不能正常保存截图。这两个命令是 ARTEMIS 动作执行和状态观察的基础依赖任何一个失败都说明设备状态有问题。还有一个容易忽视的问题部分 Android 12 及以上机型默认启用了“隐私保护”里的“屏幕内容保护”第三方截图命令会被限制导致 Agent 拿不到真实屏幕内容。这种情况需要在开发者选项里检查“模拟显示”或者关闭相关的屏幕内容保护选项。如果排查完确认设备没问题问题是偶发性的考虑是 adb 服务异常跑一个 adb kill-server 再 adb start-server 重启 adb 服务基本能解决。4.2 模型推理太慢Agent 操作卡顿接上 ARTEMIS 跑起来之后新团队最容易吐槽的就是慢。Agent 每走一步都可能涉及截图、视觉推理、LLM 推理三个环节每个环节都是几百毫秒到几秒量级整个流程跑下来一个用例分分钟钟几分钟就没了。优化要抓大头。视觉模型推理和 LLM 推理是主要瓶颈优先看这两块有没有走 GPU 加速。本地部署的话检查 CUDA 或 ROCm 环境是否生效走 API 的话换更快的模型服务或者升级模型规格会有明显改善。其次可以检查截图分辨率。ARTEMIS 默认截图是设备原始分辨率2K 屏幕截图即便是压缩后也会拖慢推理速度。如果业务场景不需要超高精度识别可以考虑在环境层面把截图缩放同时保证文本清晰可读。实际操作中把分辨率压到 720p 档位对速度提升非常明显。还有一个比较隐蔽的优化点浏览模式下 Agent 频繁空转。它在当前页面反复点击相同区域每次都触发完整的推理链路白白消耗时间。解决方法是给 Agent 的每一步都加操作结果验证如果上一步操作没有引起 UI 变化就跳过后续推理直接换策略。4.3 UI 识别不准点击位置偏了UI 识别不准这个问题遇到概率挺高特别是遇到相对复杂的自定义控件。常见的有搜索框里弹出的联想列表直播间里移动的礼物组件还有各种不规则形状的悬浮按钮。传统方法都难搞定纯视觉方案也一样会翻车。遇到这种情况第一反应不应该是责怪训练数据而是先尝试调整 Widget Capturer 的最低置信度阈值。同一个组件模型可能给了多个候选框置信度低了会多识别、高了会漏识别。调阈值是最快见效的手段。如果阈值调到合理范围后问题还在就要考虑数据层面的差距了。你的 App 如果是深度定制的渲染方式比如自研的 Canvas 绘制、游戏引擎 UI那通用模型确实很难识别。这种场景只能积累真实截图做专门的模型微调。还有一个容易踩的细节动态界面导致位置错位。比如列表在下拉刷新时组件位置整体偏移Action Executor 拿到的还是刷新前的位置点击就会错。这种问题需要在执行动作前重新截屏并再做一次 Widget Capturer 推理让 Agent 基于最新屏幕状态决策。从实现角度说就是设置一个最小的状态同步间隔避免用陈旧的状态去执行新动作。4.4 复杂任务失败的排查先看指令拆分是否合理多步任务在 ARTEMIS 里经常出现“中途跑偏”的现象。比如让它完成一个注册流程走到第二步就开始乱点或者直接卡住不动。这时候不要急着怪模型先用“拆解链路”的思路排查。第一步检查输入指令是否有歧义。如果任务描述里包含了可被多种理解的词Agent 很可能走错方向。比如“填写表单”这种表达在 Agent 眼里是模糊的到底是哪些字段、顺序如何、哪些可以留空这些细节都要显式给出。第二步检查 Agent 的中间决策。ARTEMIS 支持输出推理日志能看到每一步的想法建议跑一个失败用例时认真翻日志。常见的情况是 Agent 在第二步误判了页面状态或者它对某个组件的语义理解错了比如把“退出登录”的按钮当成“返回上一页”的按钮。如果前两步排查下来指令清晰、推理合理但操作还是失败问题大概率在执行的时序上。很多 Android 应用有交互动画Agent 在动画未结束时执行点击事件会被吞掉。这种情况下要检查 Action Executor 有没有在动作之间加入合理的等待时间或者尝试增强状态观察确保前一个动作的效果完全呈现之后再执行下一步。5. 一个人在折腾 ARTEMIS 时的几点体会ARTEMIS 让我比较感慨的一点是Google 把“让测试用例从代码变成对话”这件事真正落到了工程可实现的程度。它能跑起来而且不是实验室里的 demo是真的连上真机就能干活的完整工具链。我自己搭环境时最大的感受是这个项目收敛了太多复杂度把测试过程抽象成了看屏幕、思考、动手极大降低了自动化的心智负担。对于团队引入 AI Agent 做端到端测试我比较建议先拿一周时间做小范围试点选一条高频且稳定的业务路径跑出效果再逐步推广。别一开始就指望 Agent 接管全部测试目前它在复杂场景下还是会迷路需要人工兜底和策略调优。但话说回来当它跑通的那一瞬间你确实能感受到“测试脚本维护”这件事已经变得不再可怕了。如果你正在打磨 Android 真机测试方案我建议把 ARTEMIS 的代码和论文都翻出来细看。这个项目融合了视觉和理解两条线的成熟技术再加上系统级执行框架整体的工程完成度很高的。哪怕不直接落地用它也会极大影响你设计下一代测试平台时的思路。