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

在Android测试圈子里大家应该都有一个共同的感受UI自动化脚本写得再好也扛不住需求迭代和机型碎片化的双重打击。我前前后后维护过几套基于Appium和UIAutomator的用例库最痛苦的不是写脚本而是脚本跑不稳定的那几天——不是弹窗挡了按钮就是控件id变了再不然就是某个千元机上的渲染延迟让元素定位直接超时。这也是我一开始看到Google开源ARTEMIS这个项目时会特别留意的原因它和我熟悉的传统测试框架思路完全不一样不再是脚本驱动设备而是让一个AI Agent自己理解界面、拆解任务、在真机上执行操作。ARTEMIS全称是“AI-driven Testing and Evaluation for Mobile Interaction Systems”面向移动交互系统的AI驱动测试与评估框架核心是一件挺反直觉的事——Google把一台Android真机直接交给了大语言模型让模型通过截图和布局信息“看”屏幕再像人一样用点击、滑动、输入这些动作去完成测试任务。它适应的场景很明确功能验收、探索性测试、回归验证、多机型兼容性巡检。对测试工程师、质量保障团队、移动开发团队乃至想用AI Agent落地真实业务的人来说这都是一个值得花时间搞清楚的新方向。这篇文章我会从ARTEMIS的项目定位、核心机制、本地部署、真机实战经验以及它给现有测试体系可能带来的变化这几个方面把我上手过程和踩过的坑都摊开来讲。1. ARTEMIS到底解决了什么问题传统Android自动化测试的三座大山先说清楚了ARTEMIS不是又一个测试框架它更像是一个“测试执行的大脑”。要理解它的价值得先回头看传统Android UI自动化为什么做到今天依然费劲。1.1 传统自动化脚本的脆弱根源过去我们做Android自动化主流路线基本是Appium UIAutomator2或者纯UIAutomator、Espresso。这套东西的核心逻辑是先给控件起名字id、content-desc、xpath再写操作步骤最后断言结果。问题恰恰出在这个逻辑上。控件定位依赖UI结构稳定。但App每次版本迭代布局重排、id重命名、第三方组件升级都会让选择器失效。我经历过一次只改了启动页倒计时实现方式整个用例库里有30%的case因为引导页的“跳过”按钮content-desc变了而集体挂掉。机型碎片化导致特征不一致。同一个按钮在华为、小米、三星上可能因为系统自带UI规范不同渲染出来的层级结构都不一样。真机池里几十台设备每台都得单独调定位参数维护成本随机型数量线性上涨。异常处理基本靠“猜”和“堆”。权限弹窗、更新弹窗、天气提醒、广告插屏每个都要预先写好分支逻辑。但Android系统的弹窗来源太杂了有的来自app自己有的来自系统应用有的来自厂商定制UI你永远堵不完。ARTEMIS的出发点就是绕开这套“脚本与UI结构强绑定”的死结。它不预先定义控件定位器而是让AI Agent实时看屏幕、理解当前状态、决定下一步动作。1.2 ARTEMIS的范式转变从“脚本驱动设备”到“意图驱动测试”ARTEMIS工作方式很直白你用自然语言给一个任务比如“把购物车里的商品数量改成3然后去结算页截图”Agent会自己规划步骤、执行操作、观察结果并在遇到问题时自我修正。它不太Care控件的id是什么因为它通过两个通道感知界面一个是视觉通道屏幕截图一个是结构通道当前界面的视图层级信息。两个通道一起喂给大模型让模型在不依赖固定选择器的情况下也能定位需要操作的控件。这个转变带来的实际好处我举一个具体的例子。传统脚本里处理系统权限弹窗通常要写一个全局的“点击允许”兜底逻辑但在Android 12之后精确定位授权弹窗的控件已经变得很麻烦ARTEMIS遇到权限弹窗时会自己从截图和布局信息里认出“这是系统授权弹窗”然后判断该不该点“Allow”根本不需要测试人员为这个场景提前写分支。换句话说ARTEMIS把测试人员从“为每种意外情况写处理逻辑”中解放出来改为“用规则和预期结果约束Agent行为”。测试关注点从“怎么点”上移到“验证什么”这才是它最核心的价值。1.3 适合谁用不是替代Appium而是补上它缺的那块得说清楚ARTEMIS在现阶段不是让你把已有的Appium用例全部扔掉。它真正擅长的是传统自动化最头疼的几个场景探索性测试你没空把每条业务路径都写成脚本让Agent自己去点、去试、去发现崩溃。多机型冒烟巡检同一套自然语言任务下发到几十台不同型号的设备上要求全部执行完成并回报结果。业务逻辑快速验收开发提测后用几个自然语言描述的验收点快速判断主流程是否可用。自动化用例的自愈式执行脚本跑到一半因弹窗挂掉时Agent有能力识别并绕过弹窗继续跑而不是直接失败。如果你现在的项目是那种UI结构一天三变的快速迭代型AppARTEMIS这种思路可能比维护Appium脚本更划算。当然如果你追求的是每个版本毫秒级稳定的精确回归传统框架的确定性优势还是不可替代的。二者更适合配合使用而不是二选一。2. Agent的工作机制拆解LLM是怎么“看懂”Android屏幕并操作的如果你以为ARTEMIS只是给Gemini接了个ADB命令接口那就把这件事想简单了。它实际做的事情要扎实得多从设备管理、界面感知、任务规划到动作执行每一层都有明确设计。2.1 设备层ADB连接与设备代理它凭什么能“操作”真机ARTEMIS底层通过ADB与Android设备通信ADB大家都知道安装调试、截屏、模拟点击这些能力它都具备。但ARTEMIS在上面封装了一层“UI代理”机制这层代理负责将ADB的底层指令翻译成高层的UI操作比如“点击坐标(540, 1200)”“滑动从(300, 800)到(300, 200)”“输入文本xxx”。它还用到了一个关键的自动化基础设施——能够通过Android的辅助功能API获取当前界面的视图树信息View Hierarchy。这就是上面说的“结构通道”。普通开发者对于辅助功能的理解大概停留在无障碍服务层面但ARTEMIS把它用成了App的“眼睛”每次动作之后它都会拉取新的布局XML配合新的截图作为模型观察下一轮状态的基础。一个值得注意的设计是ARTEMIS的UI代理层里还实现了一个“崩溃恢复”机制。如果App在测试过程中crash了ADB层会捕捉到进程消失的事件然后通过Shell指令尝试重启App恢复到一个可继续测试的状态。这个机制虽然不能保证所有崩溃都能自动恢复但至少能避免整个任务因为一次偶发崩溃就彻底中断。2.2 感知层截图与布局信息的双通道模型如何判断该点什么ARTEMIS的核心循环是“观察-思考-行动-再观察”。模型每一步都要回答两个问题“当前屏幕是什么状态”“我应该执行什么操作来接近任务目标”为了回答这两个问题模型需要拿到两个输入。一是屏幕截图经过缩放和压缩后传给大模型让模型以视觉方式理解界面布局二是视图层级信息以XML形式存在包含当前所有可见控件的类型、文本、位置边界bounds和资源id。两者结合模型可以相当精准地指出下一步操作的目标。这里有一个实操中我觉得很重要的细节ARTEMIS支持“裁剪候选点击区域”。模型不一定非要精确到某个像素它只要指出要点击的位置或元素描述系统就会在布局XML里找到匹配的控件坐标再用ADB执行点击。换句话说模型的输出被约束到“合法可点击的控件”上这大大减少了乱点的概率。2.3 动作空间与执行边界Agent能控制哪些操作又要遵守什么纪律ARTEMIS定义了一套动作集合包括点击Tap基于元素定位或坐标点击。长按Long Press适合触发上下文菜单或图标编辑模式。输入文本Input Text在输入框中键入内容支持清空和逐字符输入。滑动Swipe支持四方向滑动适合浏览列表和翻页。按键Key Event包括返回键、Home键、最近任务键等系统级按键。等待Wait等待界面稳定或特定元素出现。结账/截图Screenshot/Report记录当前状态作为证据。这看起来就是一个常规自动化框架的动作集但ARTEMIS的特殊之处在于“纪律约束”。它会在系统提示词里约定哪些事情不能做比如不允许点击与任务无关的广告、不允许修改系统设置等。这些规则虽然大量依赖模型的遵循能力但配合任务拆解和反思循环在多数情况下能保证Agent的行为保持在测试边界内。一个我试过并且效果不错的小技巧是在写任务描述时把“不要做什么”也写清楚比如“不要点击任何广告区域只完成结算流程”。模型在规划步骤时会更谨慎。这本质上是把系统约束融入到任务提示词里。2.4 核心引擎LLM驱动的任务规划与整个工作流串联ARTEMIS完整的执行流程可以这么概括任务接收后Agent首先启动一个“任务理解”阶段将自然语言任务拆解成一系列子目标接着进入一个“执行循环”阶段每一步都基于观察结果决策动作执行完成后检查状态如果中途出错Agent会进入“反思阶段”对比实际观察与预期状态重新规划下一步最后任务完成或超时Agent会生成一份执行报告包含操作轨迹和截图证据。这里有一个它做得比较有特点的机制SCRATCHPAD草稿本。它记录Agent在每一步的推理过程和中间状态让模型能回溯自己之前做过什么、推理过什么。你可以简单理解成“思考日志”这比单轮无状态的模型调用更可靠。我在实测中明显感觉到有了SCRATCHPAD之后模型在执行长任务时的连贯性会好很多至少不会频繁忘记自己正在做哪一步。模型为什么能做到这种“拆解-执行-反思”的能力核心还是因为它基于Gemini这类多模态大模型既理解视觉输入又能做工具调用function calling。这一幕对做过AI Agent开发的人来说应该很眼熟——它其实就是把Android设备封装成了一个大模型工具箱调用工具的方式是“屏幕截图布局信息”。3. 本地部署与第一个Demo从环境准备到跑通首个测试任务要上手ARTEMIS老实说门槛不高但需要具备一定Android开发和Python基础。我是在一台Ubuntu服务器上跑的Android设备通过USB连线下面把完整步骤和几个容易出问题的地方都写出来。3.1 环境准备清单一台Linux或macOS机器Windows也能跑但ADB在Windows上的稳定性我持保留态度推荐Linux。Python 3.9以及PIP包管理。Android SDK至少包含ADB和平台工具。一台Android真机推荐Pixel或原生系统非原生系统的兼容性会稍差开启开发者选项和USB调试。一个大模型API的访问权限ARTEMIS默认适配Gemini系列模型同时也有方案适配其他OpenAI兼容协议模型。这些依赖本身没什么坑真正容易出问题的是设备连接很多Linux机器默认没有udev规则插上手机之后adb devices会显示unauthorized或找不到设备。解决办法是先给手机授权弹窗点“允许USB调试”然后在 /etc/udev/rules.d/ 下添加对应厂商的USB规则并重启服务。3.2 安装ARTEMIS项目ARTEMIS以Python项目形式发布安装方式很常规。我建议用虚拟环境避免依赖冲突到本机的其他项目。git clone https://github.com/google/artemis.git cd artemis python3 -m venv .venv source .venv/bin/activate pip install -e .然后配置模型API密钥在环境变量里设置export GOOGLE_API_KEY你的API_KEY接着验证设备是否被识别adb devices -l输出里能看到设备序列号和型号信息就说明连接正常。这一步如果卡住了90%的问题出在USB调试授权或者udev规则上和ARTEMIS本身没关系。3.3 写第一个测试任务自然语言定义的验收流程ARTEMIS有一套任务描述格式支持你定义任务、目标以及成功条件。我用一个典型的电商App测试场景来演示。任务描述大概是这样的打开App在首页找到搜索框输入“无线耳机”点击搜索 在搜索结果列表里点击第一个商品的详情页 在详情页点击“加入购物车”然后进入购物车页面 确认购物车中有一个商品截图保存结果。 全程不能点击任何广告区域如果出现系统弹窗非App自身弹窗选择拒绝或关闭。把它写成一个任务文件比如task.mdARTEMIS运行时就会加载它。需要注意的是任务的描述质量直接影响执行成功率。如果你只说“测一下购物流程”模型虽然能理解大方向但具体步骤可能会和你们业务的实际路径有出入把路径写清楚之后成功率会显著上升。这跟你在团队里给新人测试工程师派活的道理是一样的。3.4 运行任务并解读执行报告运行命令大概是这样python -m artemis.run --config path/to/device.yaml --task path/to/task.md执行过程中ARTEMIS会持续输出日志你可以在终端看到Agent的每一步思考、执行动作和观察结果很方便观察它在干嘛。任务跑完后会在输出目录生成一组文件包括执行日志按时间顺序记录每一步操作和模型推理内容关键步骤截图最终结果摘要包括任务完成状态和操作统计我第一次跑通时挺激动的因为整个过程中我没有写任何一行UI定位代码Agent自己就从首页逛到了搜索、再到详情页和购物车。虽然中间有一次点错了商品卡片模型误判了一个推荐位但它在之后一步自己纠正了——“反思循环”在这个场景里是真实有效的。3.5 多设备并发执行与结果汇总ARTEMIS还支持同时管理多台设备。你可以在设备配置文件中注册多个设备信息然后一次性下发同一个任务它会在每台设备上独立执行并在最后汇总结果。这个能力我强烈建议做移动测试的朋友利用起来。传统自动化多机并发要解决用例切分、数据隔离、报告聚合一堆问题ARTEMIS的模型层本身是无状态的每个设备跑自己的任务记录天然就适合横向扩展。唯一要注意的是多台手机同时执行时USB Hub供电要稳否则某些设备会出现瞬间掉线。4. 真机实战中的关键经验那些不跑一遍根本不会注意到的坑常年在真机上跑自动化的人都知道模拟器里的绿灯和真机的红灯之间差了一万个“系统弹窗”。ARTEMIS在真机上的表现和模拟器比至少有下面这几点是我实测后印象很深的。4.1 权限弹窗与系统UI差异Agent会遇到你也会遇到的问题真机环境最大的变量是厂商定制UI尤其国内ROM比如MIUI、ColorOS、HarmonyOS NEXT这些不仅要处理App自身的权限请求还会遇到各种系统级提示和默认浏览器/应用选择器。ARTEMIS处理这类弹窗的能力上限取决于模型对截图的识别能力。在原生Android的授权弹窗上表现很好Agent能准确识别“允许”和“仅在使用中允许”的差异但在某些国产ROM自定义的弹窗上有时候模型会犹豫不决把弹窗误判成App内容然后尝试去关掉它而不是做出选择。针对这个问题我的经验是两条路。一是在任务描述里明确“系统弹窗统一关掉或点击允许”给它一个明确的决策方向二是在设备配置里写好预设的弹窗处理策略让UI代理在检测到系统级窗口时自动选择约定动作不经过模型。4.2 长任务执行中的漂移与自修正它不是脚本它有一定的“容错率”传统脚本一旦执行步骤偏离预期后面就全错了。ARTEMIS不一样它有观察-反思循环能容忍一些偏差。但它不是万能的任务步骤太长比如超过30步时模型仍然可能出现“漂移”——即在某个中间步骤上绕了远路或者漏掉了一个关键子目标但自己没意识到。我测试过一个比较长的流程登录→首页→搜索→筛选→商品详情→加购→结算→填地址→确认订单→支付。ARTEMIS跑到第7步左右时偶尔会忽略“筛选”步骤直接进详情页。这种情况下任务不会失败但它执行的不是我们预期的路径。应对办法是加中间检查点checkpoint。可以在任务描述里把关键子目标明确写成“在移动下一步之前确认当前页面是筛选结果页”或者设置每一步之间的最大超时时间。这样Agent在漂移时会被“拽”回来。4.3 输入框的兼容性中文输入比英文输入更容易暴露问题ARTEMIS的文本输入依赖ADB注入或剪贴板方案。在英文输入场景下基本没问题但中文输入在部分真机上会触发输入法切换延迟或候选词遮挡导致输入结果不完整。我实测的建议是如果任务里有中文输入尽量让设备安装一个稳定的输入法如Gboard并且在执行输入前先等待片刻或者指定输入后做一个“验证文本是否完整”的子步骤。ARTEMIS虽然不是专业输入法测试工具但这些细节直接影响任务成功率。4.4 网络波动与弱网环境Agent也需要时间等待页面加载真机上执行任务时App的网络请求可能忽快忽慢。ARTEMIS每一步操作后都会刷新状态但如果页面因弱网下一步操作超时它可能会误以为页面没反应而重复点击。这里需要设置合理的时间等待参数。ARTEMIS执行动作之间的默认等待间隔可以根据网络环境调大。另外在任务描述里可以写上“如果页面加载超过5秒请等待而不是重复点击”让模型在决策时有更明确的耐心阈值。5. ARTEMIS对现有测试工程体系的影响CI/CD集成与团队落地思考如果你和我一样日常工作离不开Jenkins、GitLab CI这些持续集成设施你肯定会问ARTEMIS能不能接进CI流水线替代或补充现有的自动化测试环节答案是能但它不是简单地用命令行替换而是要重新设计任务下发逻辑和结果判定规则。5.1 把ARTEMIS接进Jenkins流水线的思路一个典型的接入方式是在每次夜间构建完成后触发一批ARTEMIS冒烟任务下发到真机池执行并把执行报告回传到CI系统。这里要解决的一个问题是超时管理。ARTEMIS任务不像传统自动化用例有明确的几十秒级别超时预期一个探索性任务可能跑3到10分钟。构建流水线需要预留足够的时间窗并且对执行结果设置合理的“重试策略”。我建议把ARTEMIS任务当成“模糊回归巡检”来用而不是阶段性的门禁。如果它跑出问题再触发一个传统的精确自动化用例集去复现和确认这种“先AI粗筛、再脚本精验”的组合效果最好。5.2 与现有用例库的关系AI测试和传统自动化不是替代是分层很多人一看到ARTEMIS就问“以后写脚本是不是没用了”。我的观点恰恰相反传统脚本的价值会沉淀成“精确回归层”ARTEMIS这类Agent补充的是“智能探索层”。打个比方传统自动化是你请了一位严格执行力极强的员工必须把流程背得一字不差ARTEMIS是你请了一位有判断力的实习生大致知道流程但需要理解和临场发挥。真正成熟的测试体系两者都要有版本提测后的核心回归用例、支付链路、登录鉴权还是脚本更可靠而UI频繁变化的活动页、多机型兼容性检查、异常弹窗吸收测试则是Agent的强项。5.3 任务管理的结构化成功率、失败原因、模型干扰因素在使用ARTEMIS一段时间之后你会发现它产出的不光是测试结果还有一个很有价值的副产品执行轨迹和失败原因分析。传统自动化失败后你要去翻日志逐帧排查而ARTEMIS的轨迹是自然语言化的——模型会说“我尝试点击了商品卡片但进入了错误页面因此我返回了搜索页重新尝试”。这种可读性对于跨团队协作特别友好即使不懂代码的产品经理也能看懂哪一步出了问题。当然拿到执行轨迹之后也需要一些聚合分析比如按失败阶段分类启动失败、登录失败、搜索失败、结算失败按机型分组统计成功率。这些分析可以辅助你持续优化任务描述和系统提示词形成一套随着Agent一起进化的“测试知识库”。我个人的经验是给ARTEMIS配置一个固定的“系统提示词模板”把项目业务常识、常用控件描述、常见弹窗处理规则都固化进去。这样每次下发新任务时Agent都能从同一个知识基础上进行推理效果稳定得多。这个提示词模板就是团队长期沉淀的高价值资产。6. 我对ARTEMIS前景的真实看法与一段个人体会ARTEMIS在外界看来可能只是Google开源了一个AI测试工具但在我这种天天跟App质量问题打交道的人眼里它给了我们一种重新思考测试方式的契机——测试人员的工作重心从写脚本维护脚本逐渐转移到定义测试意图、设计Agent的行为边界、分析智能执行的结果。它目前还不完美长任务漂移、厂商ROM弹窗适应、中文输入兼容这些问题都客观存在模型推理耗时和Token成本也比传统脚本执行高得多。但方向是对的AI不是取代测试工程师而是把我们从最枯燥的“界面操作”层面解放出来去做更有挑战的测试设计与质量分析工作。ARTEMIS就像是给测试行业的一份来自未来的参考实现看完之后你对“AI Agent如何实用化”的理解也会更深一层。最后分享一个我在实际使用中最满意的小场景前一天凌晨我们的提测包出了一个启动页广告弹窗问题第二天早上同事让我去复现验证我直接在ARTEMIS里下了一个自然语言任务——“打开App等待5秒如果出现全屏广告弹窗就截图并点击关闭按钮”几分钟后设备端返回了截图证据问题水落石出。整个过程我没碰过一行脚本。这种感觉对测试工程师来说确实既新鲜又踏实。