做了两年以上 Android 自动化的人大概率都经历过这种时刻凌晨两点 CI 挂了你爬起来翻日志发现只是登录按钮从resource-id改成了text整个脚本报废。维护成本高、跑起来慢、UI 一动就崩这类痛点逼着测试团队不断在框架层做文章但始终绕不过一个根本问题——脚本是人写出来的它只认死理不认意图。所以当 Google 把 ARTEMIS 开源的消息放出来的时候我第一反应是这次可能真的不一样了。ARTEMIS 走的是另一条路不再由人写清楚每一步点击什么、输入什么而是告诉 AI Agent 一个目标让它像人一样盯着屏幕自己思考下一步做什么操作完再观察反馈错了再改。整个流程跑在真实 Android 设备上用的也是真实 UI、真实网络、真实弹窗。这篇东西我会从传统自动化的死穴开始聊拆解 ARTEMIS 的感知、推理、执行机制再把我在本地复现时踩过的坑和总结出的经验一并放出来最后聊几句这个工具到底适合谁、怎么落进现有测试体系。1. 为什么 LLM 要接管真机测试传统自动化的死穴在哪1.1 脚本式自动化的维护成本是被低估的很多团队上自动化测试目标都是“减少重复劳动”但真实情况往往是自动化刚上线时很爽跑了几周之后一小半时间都花在修脚本上。为什么因为 UI 测试的本质是断言“当前屏幕状态是否符合预期”而传统脚本描述状态的方式极其脆弱——resource-id、xpath、坐标偏移、控件层级任何一个前端改动都可能让这些定位器全部失效。我在一个中型应用上做过统计一次常规的界面改版牵扯到 80 多个用例其中 30 多个需要手工调整定位器。每个用例平均 30 分钟这就是 15 个小时的维护量。这种成本让很多人得出一个结论自动化不适合探索性测试和冒烟测试只适合核心流程的回归保护。这话没错但也说明了一个事实——传统工具链的瓶颈不在执行而在“描述”本身太机械。ARTEMIS 想解决的就是这个描述问题。它不是通过定位器去匹配控件而是通过视觉语言模型去“看”截图理解界面上有什么再根据任务目标决定操作。脚本时代你告诉计算机“点击 id 为 login_btn 的按钮”AI Agent 时代你告诉模型“登录”它自己找到那个按钮。1.2 任务描述取代步骤描述测试用例的范式变化传统用例写的是“行为步骤”每一步都是确定的执行顺序也是确定的。而 AI 驱动的测试用例写的是“目标”从起点到终点的路径由模型自行规划。举一个非常简单的例子传统用例大概是这个写法# 打开设置 driver.find_element(By.XPATH, //android.widget.TextView[text设置]).click() # 点进关于手机 driver.find_element(By.XPATH, //android.widget.TextView[text关于手机]).click() # 读取版本号 version driver.find_element(By.XPATH, //android.widget.TextView[contains(text, Android)]).text如果是 ARTEMIS 风格你写的更像是任务打开设置中的“关于手机”页面读出 Android 版本号并返回。前者是命令后者是意图。意图不需要关心按钮在哪一层、控件叫什么名字只关心最终结果。这意味着同一个任务可以在不同型号、不同分辨率、不同系统版本的真机上运行因为 Agent 每走一步都会“重新看一遍屏幕”再决策而不是盲人摸象式地执行固定步骤。1.3 ARTEMIS 在测试工具链里到底处于什么位置横向对比一下现有的工具能更清楚 ARTEMIS 的定位方案类型代表工具核心依赖主要缺点自动化测试框架Appium、Espresso代码定位控件维护成本高、UI 变更敏感云端真机平台Firebase Test Lab、Sauce Labs预定义脚本同样依赖脚本质量无脚本 RPA 式方案部分商用工具录制回放识别能力弱不稳定LLM 驱动测试代理ARTEMIS、A3、AppAgent视觉语言模型 真机控制推理延迟和 token 成本较高ARTEMIS 属于最下面这一类。它的价值不是替代你需要跑的 1000 个回归用例而是接住那些“脚本写起来不划算、纯手工又太费人”的长尾场景——新功能的探索性测试、覆盖面广但不需要精确断言的冒烟测试、以及真机兼容性验证。2. ARTEMIS 内部机制拆解视觉感知、任务推理与动作执行2.1 感知层截图加布局树的双源输入ARTEMIS 要像人一样操作手机第一件事是“看”。它的感知层会同时拉两个来源的信息一是像素级的屏幕截图这是给视觉语言模型看的模型可以判断按钮位置、图片状态、布局是否错乱。二是 Android 系统的视图层级树类似 UI Automator dump 出来的 XML这相当于给 Agent 一个“辅助线”让它知道页面元素的层级关系、文本内容、控件类型。这两套信息是互补的。纯截图的问题是像素坐标不稳定同一按钮在不同分辨率下坐标完全不一样纯布局树的问题是信息量大且冗余很多节点根本没有视觉意义而且截图里能看出的“图片加载失败”这类问题布局树完全无法表达。ARTEMIS 把两者结合先让视觉模型描述图像内容再用布局树提取可操作的控件结构最终生成带有坐标信息的操作候选列表。我在复现运行的时候发现这类 Agent 对布局树的质量要求其实很高。如果设备开启了某些开发者选项比如“显示布局边界”截图会出现大量额外线条会明显干扰模型的判断。这一点后面实测部分会详细说。2.2 推理层任务拆解与动作空间约束拿到感知结果之后进入 LLM 的推理阶段。ARTEMIS 在推理层做的核心工作是三件事第一把最终任务拆成可执行的子步骤。任务目标是“帮我把壁纸换成默认的”模型需要理解这是“设置 → 壁纸 → 选择默认壁纸”的多步流程而不是一步点击。第二在当前屏幕状态下选择动作。动作空间是受限的模型只能从预定义的动作类型里挑主要包括tap(x, y)点击屏幕坐标long_text/input_text输入文本swipe(x1, y1, x2, y2, duration)滑动back()返回键home()回桌面enter()确认键限制动作空间非常重要。如果不加限制让模型自由输出 Python 代码直接调 API理论上很强但实际会变得完全不可控——模型生成代码的错误率太高了而且你没法直观地跟踪它在干什么。反而是这种简洁的坐标动作集配合“观察-行动-反馈”循环每一步都可追踪、可复现出了错也能排查。第三判断任务是否完成。模型每一步之后都会问自己“任务达到目标了吗”这个判断不是靠比对预期结果而是靠视觉和布局信息比对当前状态比如“是否已经进入了关于手机页面”“版本号是否已经出现”。2.3 执行层ADB 链路与真机控制推理层只是“想”真正“做”要通过 Android 的底层控制链路。ARTEMIS 在真机上执行的本质还是 ADB 指令加系统事件注入这也是它能跑真实设备的原因。典型的执行链路是LLM 推理出动作 → 生成 ADB 或 ViewServer 指令 → 注入触摸/文本事件 → 等待页面刷新 → 重新截图并获取布局树 → 反馈给模型这里有个细节一些类似的 Agent 项目会选择用无障碍服务AccessibilityService注入事件因为无障碍事件可以拿到更多系统级别的反馈而且能处理一些普通 ADB 注入搞不定的场景比如输入中文。ARTEMIS 的好处是它的抽象层做得比较干净无论底层走 ADB 还是无障碍对外动作格式是一致的。对于像我这样的测试工程师这意味着不用去深入 Android 注入机制的细节把精力放在任务设计和结果验证上。2.4 反射机制错了能回头才是 Agent 和脚本的本质区别如果 Agent 点了某个按钮页面没有如期变化怎么办脚本的做法是直接报错人去看日志。ARTEMIS 的做法是触发一轮反思当前页面状态和预期不符是点击没生效还是点错了位置它会把新截图和布局树再喂给模型让模型重新判断并换一种操作方式继续尝试。这个“反射机制”是整个系统最关键的设计。任务越复杂、界面越动态第一次尝试就越容易失败。ARTEMIS 之所以能跑通多步任务靠的不是模型每一步都判断正确而是它允许出错、并能在错之后自我修正。在配置里能看到一个类似max_steps的参数控制单个任务的最大执行步数。设置太大任务会陷入无意义的重复操作设置太小稍微绕一点的任务就跑不完。我在实测中习惯先给目标任务设一个预计步数再乘以 1.5比如预计 5 步的任务设 8 步宁可给了余量再观察实际执行情况。3. 从零跑通 ARTEMIS环境准备与首个 Agent 驱动用例3.1 环境准备清单ARTEMIS 这类 LLM 驱动的测试工具环境要求大体分三块模型侧、设备侧、运行环境侧。下面这个清单是基于我在复现中的通用实践整理的不同版本可能略有差异项目推荐配置说明Python3.10 或更高依赖较多太老的版本容易出包冲突Android 设备真机优先Android 10 以上模拟器也可以但部分场景模拟器行为不真实ADBAndroid SDK Platform-Tools 最新版必须能通过adb devices看到设备视觉语言模型支持图像输入的 LLM 接口截图理解依赖 VLM 能力运行环境本地命令行或 CI Runner只需要 Python 环境不需要安装 AS这里要特别强调一句真机比模拟器重要。ARTEMIS 的卖点就是跑真实设备如果你一直在模拟器上试会错过很多真机特有的问题——系统弹窗、网络切换、性能波动、厂商定制 UI这些才是真机测试的价值所在。3.2 设备侧准备与 ADB 前置检查连接设备之前先做几项准备能省掉后面一大堆麻烦开启开发者选项和 USB 调试。把“屏幕常亮”打开锁屏时间设为“无”或很久。否则 Agent 跑到一半屏幕灭了感知层的截图就是一整块黑模型直接蒙圈。关闭所有可能干扰的浮窗和引导层。建议先关掉“显示触摸操作”“显示布局边界”这类开发者选项它们会在截图上叠加视觉噪音影响模型判断。adb devices确认设备已被识别状态是device而不是unauthorized。在手机上弹窗确认 USB 调试授权。如果你是第一次连这台设备插上 USB 之后手机会弹出“允许 USB 调试吗”一定要点确认并且勾选“始终允许”否则后面 Agent 启动时拿不到设备权限很痛苦。3.3 定义任务与首次运行环境没问题之后就可以定义任务了。我建议第一个用例不要选太复杂的选一个 3 到 5 步能完成的界面上操作既能验证链路又不会因为任务太绕而分不清是模型问题还是环境问题。我当时用的第一个任务是{ task: 在设置里找到“关于手机”页面返回 Android 版本号。, app_launch: settings, max_steps: 8 }启动服务等待 Agent 完成。整个过程的日志大概分成几个阶段初始化设备、感知当前界面、模型推理下一步、执行动作、重新感知、循环直到任务完成或者步数用尽。第一次跑的时候我的经验是不要干等打开另一个终端实时adb logcat看设备侧日志因为有些动作看起来执行了但应用内部其实报了错或者跳到了别的页面这些信息设备日志里都有。3.4 任务输出与结果验证Agent 完成任务后除了返回最终结果还会给出执行轨迹。这个轨迹很关键它是一份自动生成的“AI 测试记录”包含每一步的截图、动作、思考理由。你可以拿它来做两件事第一判断 Agent 走的路径是不是合理。AI 往往会找到一条人想不到的路径这很正常只要最终结果正确就可以接受。第二沉淀成回归测试的参考基线。跑一次没问题不算稳定同一个任务跑三次看路径和执行时间波动大不大。验证结果本身也有讲究。比如“返回 Android 版本号”这个任务我一开始只让 Agent 输出文本结果它读出来的值是13我核对了一下真机是 Android 14差点以为模型识别错了。再一查原来应用内显示的是“Android 版本”那一栏的 API Level 对应名称不同厂商的定制系统显示规则完全不同。这个小乌龙提醒我任务目标里依赖的“预期值”最好用视觉模型能直接判断的东西比如“屏幕上出现‘Android 版本’且下方有字母数字”而不是指定一个具体版本号。4. 实测中的坑与边界AI 真机测试真正难在哪4.1 坐标依赖性问题比想象中严重LLM 驱动的 Agent 虽然不用写死 xpath但它输出的动作最终依然是屏幕坐标。这就带来一个新问题同一块屏幕换一台分辨率不同的设备Agent 上一次学到的坐标就完全失效。我实测过两个任务在 Pixel 上跑得好好的换到一台国产定制机上同 Android 版本、不同分辨率点击位置直接偏了点到了隔壁的列表项。ARTEMIS 本身有一定容错因为它每步都重新感知但这种容错上限不高如果首次点击位置偏得太多交互的对象就完全不对了。想彻底解决这个问题目前比较实用的思路是按设备规格建任务基线同一型号同一分辨率的设备共享同一套 Agent 任务配置。不同分辨率的设备单独跑一次任务预热让 Agent 重新适应坐标。分辨率差异特别大的设备考虑有没有必要纳入同一套自动化体系。这个问题的本质是AI 替代了“人和控件的映射”但没有替代“设备和坐标的映射”。它依然是测试链路上的一环工程化时要把设备分组这件事接住。4.2 系统弹窗与权限请求是最大的流程破坏者跑真机自动化的人都知道最烦的不是被测应用本身而是系统弹窗权限请求、系统更新提示、后台应用通知、某厂商的“安全中心”提醒。这些弹窗随机出现脚本时代靠代码预判但弹窗类型和出现时机根本无法穷举。ARTEMIS 对弹窗有天然的容错能力——模型看到弹窗会把它当成页面的一部分然后判断“要不要关掉它”。但这不等于万事大吉。我遇到的最典型场景是Agent 在设置里打开权限管理手机弹出了“允许设置在此设备上通话吗”模型选择了点击“允许”这是对的。但下一次运行同一个任务时弹窗没有出现模型依旧按“上次的经验”去找那个按钮找不到就开始瞎试连点好几个错误位置最后步数耗尽。面对这种情况我现在的处理方式是在任务开始前人为清理弹窗状态或者把“允许/拒绝”这类系统级交互尽量做成前置条件而非任务内步骤。简单说让 Agent 做业务路径的探索不做系统级弹窗的稳定操作因为后者的状态依赖太强。4.3 状态变化的误判按钮置灰与加载等待很多任务卡在同一个地方AI 看到页面有个按钮点了但按钮其实是置灰状态点击没有触发任何效果。模型再观察页面发现“什么都没有变”于是反射机制启动换个位置再点一次又没反应步数耗尽。这种情况在传统脚本里很好处理一条等待条件就搞定了。在 AI 测试里反而不容易因为“等待”不是 Agent 擅长的事它的每个动作间隔是固定的感知到的都是瞬时状态不会主动去等一个元素变成可点击。我的缓解方案是两条在任务描述里明确写出中间判断的等待条件比如“如果页面显示加载中先等待加载完成再继续”。通过设备侧的设置关闭动画缩放窗口动画、过渡动画、动画时长缩放都设为关闭。这能让页面状态切换更干脆减少“更新中”“加载中”这类中间态出现的频率。4.4 任务目标不明确直接导致死循环这里要说一个很反直觉但极其重要的问题AI Agent 对“模棱两可”的容忍度很低。人操作手机时如果任务目标是“打开微信设置”人会快速在杂乱的界面里找到入口但 AI 面对同样模糊的任务会在所有看似相关的位置都试一遍然后陷入循环。有个失败案例让我印象很深任务目标是“把手机亮度调到最低”Agent 进入设置后在“显示”页面点了亮度条没反应又去“屏幕与亮度”里找了一个看似相关的滑动条划了一下又没反应然后回到“显示”页面再点亮度条……如此往复直到步数耗尽。问题不在模型能力而在任务描述缺少明确的终止条件。正确写法应该是“把屏幕亮度调整到系统允许的最低值最终确认亮度条已到最左端且未触发系统调暗保护。”给 Agent 一个可验证的终态它能知道自己什么时候算完成而不是一直在“尝试-观察-再尝试”的循环里空转。任务描述三原则我用下来很管用目标必须可视觉验证而不是“感觉差不多”。路径可以有分支但终态必须有明确画面。不要同时塞多个子任务拆开跑成功率和排查难度都会更好。4.5 Token 成本与执行耗时要揉进方案里AI 真机测试不是免费的。每一步操作都要发一张截图和一份布局树给模型推理跑一个 8 步任务光模型调用就 8 次以上失败重试的话更多。设备越多、任务越复杂成本线性上升。我在本地做过一个粗略估算任务复杂度平均步数预计模型调用次数单个任务耗时分钟级简单3步内35 次左右1-2中等5-8步610 次左右3-5复杂10步以上1220 次以上8-15这个耗时比传统脚本慢得多比人工也快不了太多。所以 ARTEMIS 现阶段不适合做高频回归适合做“少量、高价值、路径灵活”的真机验证比如发布前的关键流程探索、多型号真机的兼容性检查、以及那些脚本维护成本远高于执行成本的长尾用例。5. 把 ARTEMIS 接进现有测试体系的实际建议5.1 先用它补探索性测试的缺口大多数测试团队的传统分工是自动化脚本负责回归手工测试负责探索。探索性测试的问题在于完全依赖人的随机性和经验测过就忘没留下记录。ARTEMIS 在这里是个很好的补充让 Agent 跑一些目标宽泛的探索任务它会留下完整的截图和操作轨迹等于给“探索”装了个回放功能。我在实际团队里推的时候第一个落地的场景是“新版本适配检查”任务描述为“进入应用首页浏览主要功能区尝试打开至少三个不同业务模块记录每个模块是否正常显示”然后让 Agent 在三台不同型号的真机上跑。它跑出来的截图和日志归档后版本适配的置信度比之前手点快了不少而且能复现“当时屏幕上到底发生了什么”。5.2 与现有自动化框架共存不是取代从名字就能看出来ARTEMIS 解决的是“让 Agent 像人一样操作手机”的问题它跟 Espresso、Appium 根本不是同一个层面的东西。Espresso 是应用内白盒测试能直接拿到 Activity、View 的状态执行快、断言强这类场景 ARTEMIS 永远替代不了。Appium 覆盖面广生态成熟适合大量可复用的跨平台脚本。合理的分层是核心高频回归继续用脚本框架跑得快、断言准。长尾探索与适配验证交给 ARTEMIS 这类 AI Agent成本可控且能覆盖脚本写不完的路径。灰盒深度测试仍然需要 instrumentation 类的工具介入。5.3 测试工程师需要补的两项新能力AI Agent 测试普及之后测试工程师的核心技能会从“写定位器”转向“写任务描述和理解 Agent 行为”。我自己体会下来有两项能力最值得刻意练习一是任务设计能力。同一个人任务写得模糊还是精确Agent 的成功率差距是数量级的。学会把业务目标转译成“视觉上可验证的终态”是 AI 测试时代的基本功。二是日志与轨迹的分析能力。Agent 执行出错不会像脚本失败一样甩给你一个AssertionError而是留下一长串“感知—推理—行动”的记录。你需要从这些记录里判断问题出在感知看错了、推理想错了还是执行做了但没生效这种分诊能力在以后会越来越值钱。5.4 给想上手的人一个最低成本路径如果你看完想自己试一把我建议按这个顺序推进先不用管多复杂的功能让 Agent 跑通一个“打开应用 → 进入某个二级页面 → 截图返回”的最短链路验证环境没问题。再试一个带输入动作的任务比如“在搜索框输入关键词并查看搜索结果”锻炼模型对输入框的理解。然后试一个会失败的任务故意让它点一个不存在的按钮亲眼看看反射机制是怎么“犯错—发现—修正”的。最后才上真实的业务用例并且从小任务开始积累自己的任务描述模板。另外一个小提示如果你拿的是高分辨率真机比如 2K 屏截图尺寸会很大发给模型的时候注意接口的图片大小限制必要时先做缩放预处理。这个问题的表现就是小屏设备跑得好好的一上高分辨率设备就频繁超时或报错但日志里没有任何 UI 操作失败的痕迹。ARTEMIS 这类工具的潜力不在于多智能而在于它第一次让测试工作的重心从“描述过程”回归到了“描述结果”。对我来说这种转换带来的最大解放感是我终于不用在凌晨两点因为一个按钮改了 id 而爬起来写补丁了。 
长河君 · 2026/11/2 13:39:56 · 阅读 1.2k ARTEMIS实践指南：用AI Agent驱动Android真机自动化测试
做了两年以上 Android 自动化的人大概率都经历过这种时刻凌晨两点 CI 挂了你爬起来翻日志发现只是登录按钮从resource-id改成了text整个脚本报废。维护成本高、跑起来慢、UI 一动就崩这类痛点逼着测试团队不断在框架层做文章但始终绕不过一个根本问题——脚本是人写出来的它只认死理不认意图。所以当 Google 把 ARTEMIS 开源的消息放出来的时候我第一反应是这次可能真的不一样了。ARTEMIS 走的是另一条路不再由人写清楚每一步点击什么、输入什么而是告诉 AI Agent 一个目标让它像人一样盯着屏幕自己思考下一步做什么操作完再观察反馈错了再改。整个流程跑在真实 Android 设备上用的也是真实 UI、真实网络、真实弹窗。这篇东西我会从传统自动化的死穴开始聊拆解 ARTEMIS 的感知、推理、执行机制再把我在本地复现时踩过的坑和总结出的经验一并放出来最后聊几句这个工具到底适合谁、怎么落进现有测试体系。1. 为什么 LLM 要接管真机测试传统自动化的死穴在哪1.1 脚本式自动化的维护成本是被低估的很多团队上自动化测试目标都是“减少重复劳动”但真实情况往往是自动化刚上线时很爽跑了几周之后一小半时间都花在修脚本上。为什么因为 UI 测试的本质是断言“当前屏幕状态是否符合预期”而传统脚本描述状态的方式极其脆弱——resource-id、xpath、坐标偏移、控件层级任何一个前端改动都可能让这些定位器全部失效。我在一个中型应用上做过统计一次常规的界面改版牵扯到 80 多个用例其中 30 多个需要手工调整定位器。每个用例平均 30 分钟这就是 15 个小时的维护量。这种成本让很多人得出一个结论自动化不适合探索性测试和冒烟测试只适合核心流程的回归保护。这话没错但也说明了一个事实——传统工具链的瓶颈不在执行而在“描述”本身太机械。ARTEMIS 想解决的就是这个描述问题。它不是通过定位器去匹配控件而是通过视觉语言模型去“看”截图理解界面上有什么再根据任务目标决定操作。脚本时代你告诉计算机“点击 id 为 login_btn 的按钮”AI Agent 时代你告诉模型“登录”它自己找到那个按钮。1.2 任务描述取代步骤描述测试用例的范式变化传统用例写的是“行为步骤”每一步都是确定的执行顺序也是确定的。而 AI 驱动的测试用例写的是“目标”从起点到终点的路径由模型自行规划。举一个非常简单的例子传统用例大概是这个写法# 打开设置 driver.find_element(By.XPATH, //android.widget.TextView[text设置]).click() # 点进关于手机 driver.find_element(By.XPATH, //android.widget.TextView[text关于手机]).click() # 读取版本号 version driver.find_element(By.XPATH, //android.widget.TextView[contains(text, Android)]).text如果是 ARTEMIS 风格你写的更像是任务打开设置中的“关于手机”页面读出 Android 版本号并返回。前者是命令后者是意图。意图不需要关心按钮在哪一层、控件叫什么名字只关心最终结果。这意味着同一个任务可以在不同型号、不同分辨率、不同系统版本的真机上运行因为 Agent 每走一步都会“重新看一遍屏幕”再决策而不是盲人摸象式地执行固定步骤。1.3 ARTEMIS 在测试工具链里到底处于什么位置横向对比一下现有的工具能更清楚 ARTEMIS 的定位方案类型代表工具核心依赖主要缺点自动化测试框架Appium、Espresso代码定位控件维护成本高、UI 变更敏感云端真机平台Firebase Test Lab、Sauce Labs预定义脚本同样依赖脚本质量无脚本 RPA 式方案部分商用工具录制回放识别能力弱不稳定LLM 驱动测试代理ARTEMIS、A3、AppAgent视觉语言模型 真机控制推理延迟和 token 成本较高ARTEMIS 属于最下面这一类。它的价值不是替代你需要跑的 1000 个回归用例而是接住那些“脚本写起来不划算、纯手工又太费人”的长尾场景——新功能的探索性测试、覆盖面广但不需要精确断言的冒烟测试、以及真机兼容性验证。2. ARTEMIS 内部机制拆解视觉感知、任务推理与动作执行2.1 感知层截图加布局树的双源输入ARTEMIS 要像人一样操作手机第一件事是“看”。它的感知层会同时拉两个来源的信息一是像素级的屏幕截图这是给视觉语言模型看的模型可以判断按钮位置、图片状态、布局是否错乱。二是 Android 系统的视图层级树类似 UI Automator dump 出来的 XML这相当于给 Agent 一个“辅助线”让它知道页面元素的层级关系、文本内容、控件类型。这两套信息是互补的。纯截图的问题是像素坐标不稳定同一按钮在不同分辨率下坐标完全不一样纯布局树的问题是信息量大且冗余很多节点根本没有视觉意义而且截图里能看出的“图片加载失败”这类问题布局树完全无法表达。ARTEMIS 把两者结合先让视觉模型描述图像内容再用布局树提取可操作的控件结构最终生成带有坐标信息的操作候选列表。我在复现运行的时候发现这类 Agent 对布局树的质量要求其实很高。如果设备开启了某些开发者选项比如“显示布局边界”截图会出现大量额外线条会明显干扰模型的判断。这一点后面实测部分会详细说。2.2 推理层任务拆解与动作空间约束拿到感知结果之后进入 LLM 的推理阶段。ARTEMIS 在推理层做的核心工作是三件事第一把最终任务拆成可执行的子步骤。任务目标是“帮我把壁纸换成默认的”模型需要理解这是“设置 → 壁纸 → 选择默认壁纸”的多步流程而不是一步点击。第二在当前屏幕状态下选择动作。动作空间是受限的模型只能从预定义的动作类型里挑主要包括tap(x, y)点击屏幕坐标long_text/input_text输入文本swipe(x1, y1, x2, y2, duration)滑动back()返回键home()回桌面enter()确认键限制动作空间非常重要。如果不加限制让模型自由输出 Python 代码直接调 API理论上很强但实际会变得完全不可控——模型生成代码的错误率太高了而且你没法直观地跟踪它在干什么。反而是这种简洁的坐标动作集配合“观察-行动-反馈”循环每一步都可追踪、可复现出了错也能排查。第三判断任务是否完成。模型每一步之后都会问自己“任务达到目标了吗”这个判断不是靠比对预期结果而是靠视觉和布局信息比对当前状态比如“是否已经进入了关于手机页面”“版本号是否已经出现”。2.3 执行层ADB 链路与真机控制推理层只是“想”真正“做”要通过 Android 的底层控制链路。ARTEMIS 在真机上执行的本质还是 ADB 指令加系统事件注入这也是它能跑真实设备的原因。典型的执行链路是LLM 推理出动作 → 生成 ADB 或 ViewServer 指令 → 注入触摸/文本事件 → 等待页面刷新 → 重新截图并获取布局树 → 反馈给模型这里有个细节一些类似的 Agent 项目会选择用无障碍服务AccessibilityService注入事件因为无障碍事件可以拿到更多系统级别的反馈而且能处理一些普通 ADB 注入搞不定的场景比如输入中文。ARTEMIS 的好处是它的抽象层做得比较干净无论底层走 ADB 还是无障碍对外动作格式是一致的。对于像我这样的测试工程师这意味着不用去深入 Android 注入机制的细节把精力放在任务设计和结果验证上。2.4 反射机制错了能回头才是 Agent 和脚本的本质区别如果 Agent 点了某个按钮页面没有如期变化怎么办脚本的做法是直接报错人去看日志。ARTEMIS 的做法是触发一轮反思当前页面状态和预期不符是点击没生效还是点错了位置它会把新截图和布局树再喂给模型让模型重新判断并换一种操作方式继续尝试。这个“反射机制”是整个系统最关键的设计。任务越复杂、界面越动态第一次尝试就越容易失败。ARTEMIS 之所以能跑通多步任务靠的不是模型每一步都判断正确而是它允许出错、并能在错之后自我修正。在配置里能看到一个类似max_steps的参数控制单个任务的最大执行步数。设置太大任务会陷入无意义的重复操作设置太小稍微绕一点的任务就跑不完。我在实测中习惯先给目标任务设一个预计步数再乘以 1.5比如预计 5 步的任务设 8 步宁可给了余量再观察实际执行情况。3. 从零跑通 ARTEMIS环境准备与首个 Agent 驱动用例3.1 环境准备清单ARTEMIS 这类 LLM 驱动的测试工具环境要求大体分三块模型侧、设备侧、运行环境侧。下面这个清单是基于我在复现中的通用实践整理的不同版本可能略有差异项目推荐配置说明Python3.10 或更高依赖较多太老的版本容易出包冲突Android 设备真机优先Android 10 以上模拟器也可以但部分场景模拟器行为不真实ADBAndroid SDK Platform-Tools 最新版必须能通过adb devices看到设备视觉语言模型支持图像输入的 LLM 接口截图理解依赖 VLM 能力运行环境本地命令行或 CI Runner只需要 Python 环境不需要安装 AS这里要特别强调一句真机比模拟器重要。ARTEMIS 的卖点就是跑真实设备如果你一直在模拟器上试会错过很多真机特有的问题——系统弹窗、网络切换、性能波动、厂商定制 UI这些才是真机测试的价值所在。3.2 设备侧准备与 ADB 前置检查连接设备之前先做几项准备能省掉后面一大堆麻烦开启开发者选项和 USB 调试。把“屏幕常亮”打开锁屏时间设为“无”或很久。否则 Agent 跑到一半屏幕灭了感知层的截图就是一整块黑模型直接蒙圈。关闭所有可能干扰的浮窗和引导层。建议先关掉“显示触摸操作”“显示布局边界”这类开发者选项它们会在截图上叠加视觉噪音影响模型判断。adb devices确认设备已被识别状态是device而不是unauthorized。在手机上弹窗确认 USB 调试授权。如果你是第一次连这台设备插上 USB 之后手机会弹出“允许 USB 调试吗”一定要点确认并且勾选“始终允许”否则后面 Agent 启动时拿不到设备权限很痛苦。3.3 定义任务与首次运行环境没问题之后就可以定义任务了。我建议第一个用例不要选太复杂的选一个 3 到 5 步能完成的界面上操作既能验证链路又不会因为任务太绕而分不清是模型问题还是环境问题。我当时用的第一个任务是{ task: 在设置里找到“关于手机”页面返回 Android 版本号。, app_launch: settings, max_steps: 8 }启动服务等待 Agent 完成。整个过程的日志大概分成几个阶段初始化设备、感知当前界面、模型推理下一步、执行动作、重新感知、循环直到任务完成或者步数用尽。第一次跑的时候我的经验是不要干等打开另一个终端实时adb logcat看设备侧日志因为有些动作看起来执行了但应用内部其实报了错或者跳到了别的页面这些信息设备日志里都有。3.4 任务输出与结果验证Agent 完成任务后除了返回最终结果还会给出执行轨迹。这个轨迹很关键它是一份自动生成的“AI 测试记录”包含每一步的截图、动作、思考理由。你可以拿它来做两件事第一判断 Agent 走的路径是不是合理。AI 往往会找到一条人想不到的路径这很正常只要最终结果正确就可以接受。第二沉淀成回归测试的参考基线。跑一次没问题不算稳定同一个任务跑三次看路径和执行时间波动大不大。验证结果本身也有讲究。比如“返回 Android 版本号”这个任务我一开始只让 Agent 输出文本结果它读出来的值是13我核对了一下真机是 Android 14差点以为模型识别错了。再一查原来应用内显示的是“Android 版本”那一栏的 API Level 对应名称不同厂商的定制系统显示规则完全不同。这个小乌龙提醒我任务目标里依赖的“预期值”最好用视觉模型能直接判断的东西比如“屏幕上出现‘Android 版本’且下方有字母数字”而不是指定一个具体版本号。4. 实测中的坑与边界AI 真机测试真正难在哪4.1 坐标依赖性问题比想象中严重LLM 驱动的 Agent 虽然不用写死 xpath但它输出的动作最终依然是屏幕坐标。这就带来一个新问题同一块屏幕换一台分辨率不同的设备Agent 上一次学到的坐标就完全失效。我实测过两个任务在 Pixel 上跑得好好的换到一台国产定制机上同 Android 版本、不同分辨率点击位置直接偏了点到了隔壁的列表项。ARTEMIS 本身有一定容错因为它每步都重新感知但这种容错上限不高如果首次点击位置偏得太多交互的对象就完全不对了。想彻底解决这个问题目前比较实用的思路是按设备规格建任务基线同一型号同一分辨率的设备共享同一套 Agent 任务配置。不同分辨率的设备单独跑一次任务预热让 Agent 重新适应坐标。分辨率差异特别大的设备考虑有没有必要纳入同一套自动化体系。这个问题的本质是AI 替代了“人和控件的映射”但没有替代“设备和坐标的映射”。它依然是测试链路上的一环工程化时要把设备分组这件事接住。4.2 系统弹窗与权限请求是最大的流程破坏者跑真机自动化的人都知道最烦的不是被测应用本身而是系统弹窗权限请求、系统更新提示、后台应用通知、某厂商的“安全中心”提醒。这些弹窗随机出现脚本时代靠代码预判但弹窗类型和出现时机根本无法穷举。ARTEMIS 对弹窗有天然的容错能力——模型看到弹窗会把它当成页面的一部分然后判断“要不要关掉它”。但这不等于万事大吉。我遇到的最典型场景是Agent 在设置里打开权限管理手机弹出了“允许设置在此设备上通话吗”模型选择了点击“允许”这是对的。但下一次运行同一个任务时弹窗没有出现模型依旧按“上次的经验”去找那个按钮找不到就开始瞎试连点好几个错误位置最后步数耗尽。面对这种情况我现在的处理方式是在任务开始前人为清理弹窗状态或者把“允许/拒绝”这类系统级交互尽量做成前置条件而非任务内步骤。简单说让 Agent 做业务路径的探索不做系统级弹窗的稳定操作因为后者的状态依赖太强。4.3 状态变化的误判按钮置灰与加载等待很多任务卡在同一个地方AI 看到页面有个按钮点了但按钮其实是置灰状态点击没有触发任何效果。模型再观察页面发现“什么都没有变”于是反射机制启动换个位置再点一次又没反应步数耗尽。这种情况在传统脚本里很好处理一条等待条件就搞定了。在 AI 测试里反而不容易因为“等待”不是 Agent 擅长的事它的每个动作间隔是固定的感知到的都是瞬时状态不会主动去等一个元素变成可点击。我的缓解方案是两条在任务描述里明确写出中间判断的等待条件比如“如果页面显示加载中先等待加载完成再继续”。通过设备侧的设置关闭动画缩放窗口动画、过渡动画、动画时长缩放都设为关闭。这能让页面状态切换更干脆减少“更新中”“加载中”这类中间态出现的频率。4.4 任务目标不明确直接导致死循环这里要说一个很反直觉但极其重要的问题AI Agent 对“模棱两可”的容忍度很低。人操作手机时如果任务目标是“打开微信设置”人会快速在杂乱的界面里找到入口但 AI 面对同样模糊的任务会在所有看似相关的位置都试一遍然后陷入循环。有个失败案例让我印象很深任务目标是“把手机亮度调到最低”Agent 进入设置后在“显示”页面点了亮度条没反应又去“屏幕与亮度”里找了一个看似相关的滑动条划了一下又没反应然后回到“显示”页面再点亮度条……如此往复直到步数耗尽。问题不在模型能力而在任务描述缺少明确的终止条件。正确写法应该是“把屏幕亮度调整到系统允许的最低值最终确认亮度条已到最左端且未触发系统调暗保护。”给 Agent 一个可验证的终态它能知道自己什么时候算完成而不是一直在“尝试-观察-再尝试”的循环里空转。任务描述三原则我用下来很管用目标必须可视觉验证而不是“感觉差不多”。路径可以有分支但终态必须有明确画面。不要同时塞多个子任务拆开跑成功率和排查难度都会更好。4.5 Token 成本与执行耗时要揉进方案里AI 真机测试不是免费的。每一步操作都要发一张截图和一份布局树给模型推理跑一个 8 步任务光模型调用就 8 次以上失败重试的话更多。设备越多、任务越复杂成本线性上升。我在本地做过一个粗略估算任务复杂度平均步数预计模型调用次数单个任务耗时分钟级简单3步内35 次左右1-2中等5-8步610 次左右3-5复杂10步以上1220 次以上8-15这个耗时比传统脚本慢得多比人工也快不了太多。所以 ARTEMIS 现阶段不适合做高频回归适合做“少量、高价值、路径灵活”的真机验证比如发布前的关键流程探索、多型号真机的兼容性检查、以及那些脚本维护成本远高于执行成本的长尾用例。5. 把 ARTEMIS 接进现有测试体系的实际建议5.1 先用它补探索性测试的缺口大多数测试团队的传统分工是自动化脚本负责回归手工测试负责探索。探索性测试的问题在于完全依赖人的随机性和经验测过就忘没留下记录。ARTEMIS 在这里是个很好的补充让 Agent 跑一些目标宽泛的探索任务它会留下完整的截图和操作轨迹等于给“探索”装了个回放功能。我在实际团队里推的时候第一个落地的场景是“新版本适配检查”任务描述为“进入应用首页浏览主要功能区尝试打开至少三个不同业务模块记录每个模块是否正常显示”然后让 Agent 在三台不同型号的真机上跑。它跑出来的截图和日志归档后版本适配的置信度比之前手点快了不少而且能复现“当时屏幕上到底发生了什么”。5.2 与现有自动化框架共存不是取代从名字就能看出来ARTEMIS 解决的是“让 Agent 像人一样操作手机”的问题它跟 Espresso、Appium 根本不是同一个层面的东西。Espresso 是应用内白盒测试能直接拿到 Activity、View 的状态执行快、断言强这类场景 ARTEMIS 永远替代不了。Appium 覆盖面广生态成熟适合大量可复用的跨平台脚本。合理的分层是核心高频回归继续用脚本框架跑得快、断言准。长尾探索与适配验证交给 ARTEMIS 这类 AI Agent成本可控且能覆盖脚本写不完的路径。灰盒深度测试仍然需要 instrumentation 类的工具介入。5.3 测试工程师需要补的两项新能力AI Agent 测试普及之后测试工程师的核心技能会从“写定位器”转向“写任务描述和理解 Agent 行为”。我自己体会下来有两项能力最值得刻意练习一是任务设计能力。同一个人任务写得模糊还是精确Agent 的成功率差距是数量级的。学会把业务目标转译成“视觉上可验证的终态”是 AI 测试时代的基本功。二是日志与轨迹的分析能力。Agent 执行出错不会像脚本失败一样甩给你一个AssertionError而是留下一长串“感知—推理—行动”的记录。你需要从这些记录里判断问题出在感知看错了、推理想错了还是执行做了但没生效这种分诊能力在以后会越来越值钱。5.4 给想上手的人一个最低成本路径如果你看完想自己试一把我建议按这个顺序推进先不用管多复杂的功能让 Agent 跑通一个“打开应用 → 进入某个二级页面 → 截图返回”的最短链路验证环境没问题。再试一个带输入动作的任务比如“在搜索框输入关键词并查看搜索结果”锻炼模型对输入框的理解。然后试一个会失败的任务故意让它点一个不存在的按钮亲眼看看反射机制是怎么“犯错—发现—修正”的。最后才上真实的业务用例并且从小任务开始积累自己的任务描述模板。另外一个小提示如果你拿的是高分辨率真机比如 2K 屏截图尺寸会很大发给模型的时候注意接口的图片大小限制必要时先做缩放预处理。这个问题的表现就是小屏设备跑得好好的一上高分辨率设备就频繁超时或报错但日志里没有任何 UI 操作失败的痕迹。ARTEMIS 这类工具的潜力不在于多智能而在于它第一次让测试工作的重心从“描述过程”回归到了“描述结果”。对我来说这种转换带来的最大解放感是我终于不用在凌晨两点因为一个按钮改了 id 而爬起来写补丁了。