我们团队最近在折腾 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 执行时报错，比如 “Can't 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 的代码和论文都翻出来细看。这个项目融合了视觉和理解两条线的成熟技术，再加上系统级执行框架，整体的工程完成度很高的。哪怕不直接落地用，它也会极大影响你设计下一代测试平台时的思路。
