Google 开源 ARTEMISAI Agent 如何接管 Android 真机测试上周在群里看到 Google 把 ARTEMIS 开源的消息第一反应是——终于有人把“AI Agent 跑真机测试”这件事从论文搬到了仓库里。这两年在移动端测试圈摸爬滚打最深的体会就是脚本越写越多维护成本越滚越大UI 一改、控件 id 一变整个冒烟测试就红成一片。ARTEMIS 的思路和传统框架完全不是一个路子它不让测试工程师去写定位表达式而是让大模型驱动的 Agent 自己看屏幕、自己找控件、自己决定下一步点哪里相当于给每个测试任务派了一个带脑子的“实习生”。这篇文章我会从它解决的问题、核心决策链路、本地部署实操、与传统框架的对比以及我实测踩过的坑这几个维度展开写给正在做 Android 自动化测试的团队负责人、移动端 QA还有对 AI Agent 落地方式感兴趣的朋友。1. ARTEMIS 到底想解决什么问题一个维护过测试脚本的人最懂1.1 传统 UI 自动化的三大痛点先说说我自己的背景。我所在的团队维护着一套基于 Appium 的 Android 自动化用例规模大概一千条左右。听起来很多但真正能稳定跑完的不到六成。问题从来不在“写用例”上而在于三个长期无解的死结。第一个死结是脚本和 UI 强绑定。Android 碎片化导致同一个控件在不同厂商 ROM 上有不同的资源 id同一个功能在刘海屏和折叠屏上的布局完全不一样。你为了适配三台设备写的条件分支下个版本 UI 一改就全部作废。第二个死结是断言能力太弱。传统脚本的断言基本停留在“元素存在”“文本相等”这种层面稍微涉及“这个页面是否符合预期布局”“用户走完流程后是否有正确反馈”写起来极其痛苦。第三个死结是环境噪音。弹窗、网络延迟、权限请求、系统升级提示每一个都能让精心编排的用例瞬间失效而排错的时间往往比写用例的时间还长。这些痛点让我意识到一件事UI 自动化真正缺的不是执行力而是“理解力”。脚本只能执行预设步骤但测试的本质是“带着意图去探索未知”。ARTEMIS 切入的正是这个缝隙。1.2 ARTEMIS 的解法不录脚本而是派一个能看会想的 AgentARTEMIS 的全称是 Automated Robust Testing and Exploration via Multi-modal Intelligence System翻译过来就是“基于多模态智能的自动化稳健测试与探索系统”。它没有沿用“录制回放”或“脚本驱动”的老路而是把整个测试任务交给一个 LLM 驱动的 Agent你告诉它“打开应用注册一个新账号然后回到首页”它会自己去理解这个意图调用工具获取屏幕信息分析当前界面上有哪些可操作元素再决定下一步点击、输入还是滑动。这里的关键词是“理解意图”和“自主决策”这也是它敢叫 Agent 的原因。传统框架里的每个步骤都是确定性指令而 ARTEMIS 的每一步都带着一个推理动作——屏幕上有三个按钮注册入口到底在哪里右上角那个图标是不是菜单这些问题靠 XPATH 回答不了但靠大模型的常识和上下文推理可以做到。它不是替代测试工程师而是把测试工程师从“写死步骤”中解放出来去关注“测什么”而不是“怎么点”。1.3 它适合谁从移动端 QA 到独立开发者从我有限的实测经验看ARTEMIS 最香的场景有这几类人。第一类是移动端 QA 团队尤其是那些被脚本维护逼疯的中大型应用团队可以用它做冒烟测试、主流程探索和版本回归的辅助排查。第二类是独立开发者和小团队没有专门测试人力但又想在上架前对核心链路做一轮自动化验证ARTEMIS 的低门槛和高适应性会很受用。第三类是对 AI Agent 技术栈感兴趣的人ARTEMIS 本身就是个极佳的学习样本它把 ReAct 模式、工具调用、多模态感知整合进了一个真实可落地的项目中看完源码比读十篇 Agent 教程都管用。2. 从“看屏幕”到“做操作”LLM 驱动 Agent 的完整决策链路2.1 第一步把手机屏幕变成机器可读的“文本剧本”要让大模型理解手机屏幕上有什么最直观的方式是给它截图但直接丢截图存在很多问题。ARTEMIS 的做法更接近“把界面翻译成文本”通过 Android 的 UIAutomator 框架拿到当前界面的视图层级 XML然后对 XML 做清洗和结构化把每个控件的类型、文本、资源 id、坐标边界、可点击性等信息提取出来组装成一段模型能直接阅读的“屏幕描述文本”。这一步是整套系统的地基。为什么不用纯截图因为即便是最强多模态模型直接理解一张 UI 截图也经常犯糊涂弹窗遮住了底层内容、动态加载的列表项未渲染、深色模式下对比度不够、小手图标根本看不清楚。而视图层级 XML 包含的是控件的语义属性而不是像素特征比如“一个文本为‘登录’、可点击、坐标为(100, 800)的按钮”这种结构化描述天然比像素更适合做精确操作决策。但 XML 也有它的坏处——冗余。一个复杂页面可能有几十层的嵌套布局、大量不可见节点和装饰性 View直接全量丢给大模型既费 token 又影响判断质量。ARTEMIS 在清洗阶段做两件事去掉不可见节点过滤掉没有文本也没有内容描述且不可点击的纯布局容器再把剩余节点做扁平化合并。这一步处理完屏幕上的有效元素往往能从几百个骤减到二三十个任务瞬间清爽。2.2 第二步Agent 的“思考-行动-观察”循环拿到屏幕描述后Agent 就进入了核心循环。这个循环在 AI Agent 领域有个标准名字叫 ReActReasoning Acting思路是让模型交替进行“推理”和“行动”。每轮循环里模型先阅读当前状态——包括用户给它下达的任务目标、历史操作记录、当前的屏幕描述——然后输出一段推理说明“我为什么这样做”再输出一个具体的行动指令比如“点击坐标(540, 1700)上的‘确认支付’按钮”。行动执行后Agent 会再次抓取屏幕信息把新界面作为下一轮的“观察”结果继续喂给模型。这样一轮一轮滚下去Agent 就形成了一条完整的决策链根据观察理解现状根据理解制定行动通过行动改变状态再观察新状态。这套机制之所以适合真机测试是因为它天然容忍环境变化。屏幕上多了一个弹窗没关系下一轮观察里模型会看到这个弹窗并决定先点“我知道了”。某个按钮因为动画延迟没显示出来模型会基于历史经验选择等待一轮或者向下滑动看看。它不依赖任何固定定位路径所以面对 UI 变化时比传统脚本从容得多。2.3 第三步操作执行与错误反馈当 Agent 决定执行某个操作后ARTEMIS 通过内部封装的 adb 指令和 UiAutomation API 去驱动真机。在 Android 端它需要开启无障碍服务来模拟点击、滚动、长按等手势这和很多自动抢红包脚本用的是同一套底层机制只是 ARTEMIS 把它封装成了标准的工具接口。这里有一个容易被忽略的关键设计操作不是“下达完就结束”的。ARTEMIS 会把每次操作前后的屏幕状态都保存下来并且记录这个动作是否导致了界面变化。比如 Agent 点击了一个按钮但前后两帧屏幕完全一样系统就会标记一个“动作未生效”的反馈把这个异常情况写进上下文让模型在下一轮决策时知道“刚才那次点击可能失败了需要换一种方式再试一次”。这种闭环反馈机制大大提升了实测中的容错率也是它和那些“录一段脚本然后硬跑”的工具最本质的区别。2.4 为什么不用纯视觉模型直接看截图看到这里可能有人会问既然大模型都支持多模态了为什么 ARTEMIS 不直接用视觉模型截图识别我在实际测试中也试过类似的思路让 GPT-4o 直接看截屏做操作效果确实惊艳但到了规模化落地的环节就出了三个硬伤。第一是成本。一张 1080p 截屏的 token 消耗是纯文本屏幕描述的几十倍跑一轮完整测试几百次迭代API 费用轻松破百美元这在 CI 环境里基本不可接受。第二是精度。视觉识别能认出“这里有个红色按钮”但按钮的精确坐标往往靠猜而 UIAutomator 拿到的坐标是像素级准确的点击误差为零。第三是可解释性。文本形式的操作日志和每一步的推理记录方便人去做审计复盘纯视觉决策则像黑盒出了问题很难定位。ARTEMIS 采用的“结构化 UI 文本 必要截图辅助”的混合方案是在实测效果、成本和稳定性三个维度之间做出的折中我更愿意把它理解为一种务实的工程选择。3. 本地部署与真机接入的完整实操记录3.1 环境准备清单把依赖一次性装齐上手 ARTEMIS 的过程不算复杂但有几个坑在官方文档里只是轻轻带过我在这里把当时的操作记录完整还原出来。我用的系统是 Ubuntu 22.04Python 3.11Android 真机是一台 Pixel 6Android 13。机器连接方面没有太多意外但有几个关键点需要留意。首先是 Python 环境和依赖安装。ARTEMIS 的核心依赖包括 plyvel 作为 LevelDB 的 Python 绑定、grpcio 作为 RPC 通信库、pandas 处理数据、Pillow 处理截图、requests 调用 LLM API。用 pip 安装 plyvel 的时候我踩了个小坑它会默认去拉取 LevelDB 的本地库如果系统缺少 libleveldb-dev编译会直接失败需要先跑一条 apt install libleveldb-dev。其他依赖基本是纯 Python 包没有碰到什么障碍。依赖用途备注plyvelLevelDB 存储测试数据需先安装 libleveldb-devgrpcio内部服务通信版本冲突时先建虚拟环境pandas测试数据整理与分析用于生成结构化日志和报告Pillow截图处理与压缩减少存储开销requests调用 LLM API支持 OpenAI 协议或本地模型adb控制 Android 真机需单独安装绑定平台工具3.2 连接真机与授权解锁、开发者选项与无障碍权限连接真机这件事硬件连接很简单授权链路才是真正容易卡住的地方。我把步骤拆成这样三步。第一步开启开发者模式和 USB 调试。进入设置 - 关于手机连点版本号七次然后到开发者选项里打开 USB 调试。这里有个细节需要注意部分国产 ROM 还会多一层“USB 安装权限”或“USB 调试安全设置”建议一并打开否则后续 Agent 安装被测应用时会弹系统级授权框把整个流程卡死。第二步连接后执行 adb devices 确认设备在线。设备名称后面如果显示 unauthorized说明手机上的授权弹窗没有确认需要看手机屏幕手工点一下“允许 USB 调试”。这一步没有什么绕过技巧只能人工完成。接着我推荐执行 adb install 预装被测应用并顺手处理掉首次启动时的隐私协议弹窗——不然 Agent 第一轮就会被一个“同意并继续”的弹窗绊住。第三步开启无障碍服务权限。ARTEMIS 的执行引擎依赖 Android 无障碍服务来做点击和滚动操作但无障碍服务权限必须由用户手动在系统设置里开启没有任何 adb 命令能绕过。Android 12 以上设备需要到“无障碍 - 已下载的应用 - 选择 ARTEMIS 对应服务”里手动打开这一点第一次用的时候容易被漏掉。如果不开这个权限Agent 的点击操作会一直失败但报错信息又不够明显排查起来比较费劲。3.3 配置 LLM 接入与任务下发从注册流程到核心购买链路ARTEMIS 的模型接入层支持 OpenAI 兼容协议这意味着既可以直接用 GPT-4 系列也可以把模型服务替换成本地部署的 Qwen、DeepSeek 或者 vLLM 托管的开源模型。我测试时使用的是 GPT-4o-mini整体效果不错成本控制得也很好。实际的测试任务下发方式有三种。最简单的是通过配置文件指定任务的文本描述例如打开应用之后注册一个新用户填写邮箱为xxx密码为xxx然后验证是否跳转到首页。或者用它的 Python SDK 编写一小段脚本把任务描述和历史上下文传给接口适合做成自动化流水线。更灵活的方式是启动它的交互式控制台在命令行里动态修改任务目标适合调试阶段快速试错。我实测的第一个完整任务是注册流程。给 Agent 下达的描述比较口语化打开 App 后进入注册页面用邮箱 testexample.com 和密码 Test1234 注册一个新账号如果出现短信验证码弹窗点击跳过注册成功后回到首页并截图。这个任务大概走了十几轮决策过程中它正确识别了“获取验证码”按钮需要点击也正确处理了首次弹出的通知权限请求最终成功截图。整体耗时两分钟出头API 成本不到一毛钱这个性价比对于探索性测试场景来说是很能打的。3.4 跑通第一个任务的四个要点如果说这次实操有什么经验能直接复制我会总结成四条。第一任务描述写得越像交代给真人实习生的话Agent 的表现越好。笼统的“测一下登录”远不如“打开应用用已注册账号登录登录成功后确认首页显示个人头像”有效。第二首次连接真机务必手动跑一遍完整流程确认没有遗留的系统弹窗干扰后才交给 Agent。第三建议把屏幕超时设置调长至少 10 分钟以上否则 Agent 思考期间屏幕自动熄灭抓屏工具会一直拿到黑屏。第四Android 的动画缩放设置里把窗口动画、过渡动画、动画程序时长调整这三项全部关掉能显著减少 UI 不稳定带来的决策噪音这一招对任何 UI 自动化方案都通用。4. 和 Appium、Espresso 摆在一起比ARTEMIS 到底插在哪一档4.1 四类方案的横向对比ARTEMIS 出现后最常被问到的一个问题是它是不是要取代 Appium我的判断是短期内不太可能但它的确打开了另一条路。为了把定位说清楚我把自己用过的四类方案放在一起做了个对比。方案驱动方式脚本复杂度对 UI 变化的适应性适用场景Espresso应用内测试框架高低单元级 UI 测试、白盒验证Appium黑盒自动化中高中跨端回归、固定流程自动化MaestroYAML 描述低中轻量流程验证、团队协作ARTEMISLLM Agent极低高探索性测试、冒烟辅助、用例生成Espresso 的优势是快和稳因为它在应用进程内运行定位控件自带同步机制但这也意味着它必须和应用一起编译对集成测试场景极不友好。Appium 是当前工业界的主流选择跨端能力强生态成熟但脚本维护成本高且它对“动态弹窗”这类环境噪音的抵抗力很弱。Maestro 是个轻量派把测试写成纯 YAML 流程上手极快但依然摆脱不了“固定流程驱动”的本质。ARTEMIS 在对比中最突出的差异是前三个方案都要求用例作者预先知道界面长什么样、控件在哪个位置而 ARTEMIS 完全不需要它本身就在探索界面。4.2 不是替代品是互补品回归靠脚本探索靠 Agent我认为 ARTEMIS 和传统框架不是替代关系而是分工关系。回归测试追求确定性和速度核心高频用例必须可重复、可量化、可预期这仍然是脚本类框架的主场。而 ARTEMIS 的主场是那类“说不清楚到底会发生什么”的场景新功能首次接入时的冒烟探索、版本升级后的全核心链路走查、不同语言的本地化界面验证、以及辅助生成初始测试用例的人工智能加速器。我在实际工作里总结出一个稳妥的混合模式用传统的 Appium/Espresso 守住固定回归基线用 ARTEMIS 作为“探索哨兵”在新版本发布前跑一遍全功能域的自主走查把 Agent 发现的可疑路径和截图整理成人工审查清单。这就像给团队配了一个不知疲倦的实习生它的产出不是“测试结论”而是“需要你确认的问题”而且它确认问题的方式是真人操作式的逐层探索比脚本跑出来的报错信息直观很多。4.3 引入 ARTEMIS 的成本收益分析API 费用、稳定性和团队接受度任何技术落地都绕不开成本账。ARTEMIS 的收益很诱人但它也有实打实的支出风险这里把三个方面的账摊开来算算。API 费用是最直接的。实测下来一个中型的探索任务比如注册 - 登录 - 购买 - 退单大约消耗 20~40 万 token换成 GPT-4o-mini 的定价在 0.1 ~ 0.3 美元之间。如果一天跑五十次月成本大约几百美元对大多数团队来说完全可接受。但如果强行上最强的推理模型做同样的任务成本会直接飙升一个数量级所以选模型时要警惕“性能焦虑”。稳定性是我更担心的问题。即便是大模型驱动的 Agent也会出现“想岔了路径”的情况该点确认的时候点了返回该滚动的时候选择了点击。我观察到的经验是将任务拆分成更小的独立描述比一次性下发超长任务的成功率高出不少。假设一条完整链路变成“先注册”、“再登录”、“最后查看订单页”三个独立任务每个任务的上下文干扰就小很多。团队接受度是最后一个隐性成本。测试工程师从“写脚本”转型为“下任务、审报告”工作方式变化很大初期会有明显的适应期。我个人的建议是不要一步到位先在非核心模块跑两周把团队对 Agent 的信任感和对输出报告质量的判断力建立起来再逐步扩大范围。5. 实测中的翻车现场与应对方案没有一路顺风的 Agent5.1 权限弹窗和系统 UI 干扰怎么让 Agent 别在第一步栽跟头真机测试最烦的东西就是系统弹窗ARTEMIS 在面对弹窗时表现得比传统脚本聪明但也并非无懈可击。我跑第一轮完整流程时就翻过车Agent 准备点击“注册”按钮却被底部弹出的“要允许此应用访问设备上的照片和媒体内容吗”拦住。它确实识别出了这个弹窗但给出的决策竟然是直接点了拒绝然后继续找注册入口结果注册功能需要上传头像头像选不了整个流程断了。这类问题的本质是权限策略属于业务常识而不是界面识别能力。后来我在任务描述里显式加上了规则除非用户明确要求否则所有权限弹窗一律允许所有隐私协议弹窗一律点击同意所有推荐内容弹窗一律跳过。加了这一段前置指令后Agent 遇到弹窗的决策准确率有了质的提升。这说明一个问题Agent 的“常识”不等于你的业务预期把关键策略写清楚它才能像个熟悉你业务的实习生而不是第一次进城的旅客。5.2 内容描述缺失导致 Agent 看不懂屏幕如何处理“什么都不知道”的控件Android 应用质量参差不齐很多第三方应用只顾功能不顾无障碍规范控件既没有文本也没有 contentDescription屏幕上只剩一个不可点击但能看见的图形按钮。ARTEMIS 拿到这颗按钮的结构化描述时只能看到“View{...}没有文本、没有描述、没有角色模型根本无从推断这是个什么东西。我在测一个本地生活类 App 时遇到的情况非常典型底部的四个 Tab 全部是无文本图标Agent 尝试了三次都没能找到“我的”入口一直在首页打转。后来我手动打开了屏幕下方的“重试机制”选项让 Agent 在连续两轮观察无变化时允许结合视觉信息辅助决策。ARTEMIS 在后续版本中提供了截图补盲功能当 UI 文本信息不充分时会把局部截图以图片形式附加给多模态模型。开了这个混合模式以后这类“无文本图标”的识别成功率提升非常明显。所以我的建议是被测应用的无障碍规范很差的团队务必把“文本不足时启用视觉辅助”这个选项打开。5.3 长链路任务的“反悔与绕路”拆分任务比万能 Agent 更可靠一次性的长链路任务我踩过最惨的坑是一次连续 47 步的购买流程测试包括了选商品、加购物车、改赠品、选优惠券、改地址、提交订单六个子模块。Agent 前三步非常顺利然而在选优惠券的环节开始“绕路”它点开了一张不满足使用条件的券看到系统提示“未达到使用门槛”后竟然选择返回然后再次点开那张券形成一个死循环。排查后发现问题的根源在于长链路的每一步都在改变页面状态上下文窗口里积累了太多与当前子任务无关的历史信息模型被这些噪音干扰后做出的局部决策开始失真。我的解决思路非常简单——把长链路拆成短链路。把上面那条 47 步的任务拆成六个独立子任务每个子任务都是一个短循环上一个任务完成时的最终截图作为下一个任务的初始观察状态。拆分之后每个子任务的上下文都只有 5 到 10 轮交互模型的决策质量明显改善。这个经验后来被我总结成了一条团队内部的铁律单次任务描述控制在三步操作以内复杂业务流程必须拆分子任务串行执行。5.4 模型幻觉造成无效操作日志审计和重试机制缺一不可最后一个大类问题是模型幻觉。有一次 Agent 在一张完全没有“删除”按钮的详情页上坚持认为“右上角的更多菜单里有删除选项”接连四次点击菜单都没找到最终因为重试次数耗尽而判定任务失败。这种幻觉在视觉模型上尤为常见因为大模型对常见 UI 模式有先验认知看到类似布局就容易脑补出根本不存在的入口。应对幻觉我试下来最有效的手段是三重保险。第一层是重试限制给单次无效操作设置超时和重试次数上限避免 Agent 在同一个坑里反复试探。第二层是动作审计日志每轮循环都把“看到的屏幕摘要、做出的推理、执行的动作、动作后的结果”完整记录下来跑完任务后一键导出。第三层是人工抽查对失败任务按照日志逐条复盘把幻觉案例收集起来反哺给提示词模板比如加上“如果屏幕上没有目标入口明确报告找不到不要反复尝试”。把这三层都做到位Agent 的无效操作率能下降好几成。6. 它能扛什么、不能扛什么我的使用边界总结6.1 最适合 ARTEMIS 的应用场景探索、冒烟、兼容与用例生成从我的实测感受来看ARTEMIS 的第一主场是探索性冒烟测试。新版本提测后不需要再人工花半小时把核心链路全点一遍直接把任务丢给 Agent让它自己走完注册、登录、首页浏览、下单、支付全流程然后把每一步的截图汇总成一份图文报告。这种报告和传统脚本日志完全不同每一张图上有明确的点击红点标记管理者可以在几分钟内判断功能是否正常。第二主场是兼容性测试的辅助增效。Android 生态碎片化严重一家厂商一套行为传统自动化脚本在每台新设备上都要重新踩一遍坑。ARTEMIS 因为是探索式的天然适应不同的屏幕尺寸、分辨率和系统版本在设备池里并发跑多个 Agent 实例做基础流程冒烟是效率极高的兼容性筛查方案。第三主场是测试用例的自动生成。Agent 探索完一遍应用后它的完整操作轨迹可以直接转成结构化步骤作为人工确认后沉淀为传统脚本用例的初稿。我团队里已经有同事靠这个方式把新模块用例的编写时间压缩了大概一半这个用法对既有测试资产同样是一种增值。6.2 不适合的场景高频、强断言和严格可复现性ARTEMIS 不能扛的场景我也碰过几次值得大家冷静对待。首先是高频回归测试比如每次代码提交后都要跑的核心冒烟集合。这类任务追求速度和确定性Agent 每一步都有推理延迟跑一条用例的耗时是传统脚本的五到十倍而且单次决策存在随机性不同轮次的路径可能不同这在严格要求的 CI 主链路里很难接受。其次是强断言场景。Agent 擅长发现“哪里有东西出现在不该出现的地方”但它不擅长做数值断言比如“列表必须恰好展示 18 条数据”或“金额计算误差不能超过 0.01 元”。这类精确验证还是得交给脚本拿到数据后去对比ArtEMIS 无法替代。最后是严格可复现的场景。如果某个 bug 需要精确复现每一步操作序列Agent 每次决策的随机性会让复现变得困难。尽管可以记录日志后手动回放但效率不如传统脚本直接重跑固定序列来得干脆。总结起来一句话ARTEMIS 是发现问题的哨兵不是负责把每个问题精确钉死的锤子。6.3 后续的可能演进多 Agent 协作、云端设备池与强化学习ARTEMIS 目前的形态已经能落地使用但站在开发者角度看它还有很多值得期待的演进方向。多 Agent 协作是第一个明显趋势不同 Agent 分管不同功能域在测试时互相传递状态和发现能覆盖更大范围的应用场景。第二个趋势是和云端真机设备池打通让 Agent 自动在多台远程设备上批量执行测试任务把目前人均一台真机的模式扩展成“一个任务跑满一批设备”。第三个方向是把强化学习引入测试策略调优用历史测试结果作为反馈信号逐步优化 Agent 的探索优先级把资源集中在最容易出问题的模块上。这些方向如果落地Agent 在质量保障体系里的位置就不是“辅助工具”了而是真正参与版本质量决策的基础设施。当然路要一步一步走眼下先把 ARTEMIS 接进来跑一轮冒烟已经比多数团队的测试手段领先一步了。我在实际使用中最大的体会是不要把它和 Appium 放在对立面去比较而是当作一个补充力量接入现有体系。先拿一个小应用跑两周让它帮你做冒烟、生成探索报告、甚至发现一两个漏网 bug团队自然会对 Agent 建立信任。再往后你可能会惊讶地发现维护脚本的时间真的省下来了而那些时间花在“设计更有质量的测试任务”上比花在修改 XPATH 上有价值得多。 
长河君 · 2026/11/2 9:08:13 · 阅读 1.2k Google开源ARTEMIS：AI Agent如何接管Android真机测试？
Google 开源 ARTEMISAI Agent 如何接管 Android 真机测试上周在群里看到 Google 把 ARTEMIS 开源的消息第一反应是——终于有人把“AI Agent 跑真机测试”这件事从论文搬到了仓库里。这两年在移动端测试圈摸爬滚打最深的体会就是脚本越写越多维护成本越滚越大UI 一改、控件 id 一变整个冒烟测试就红成一片。ARTEMIS 的思路和传统框架完全不是一个路子它不让测试工程师去写定位表达式而是让大模型驱动的 Agent 自己看屏幕、自己找控件、自己决定下一步点哪里相当于给每个测试任务派了一个带脑子的“实习生”。这篇文章我会从它解决的问题、核心决策链路、本地部署实操、与传统框架的对比以及我实测踩过的坑这几个维度展开写给正在做 Android 自动化测试的团队负责人、移动端 QA还有对 AI Agent 落地方式感兴趣的朋友。1. ARTEMIS 到底想解决什么问题一个维护过测试脚本的人最懂1.1 传统 UI 自动化的三大痛点先说说我自己的背景。我所在的团队维护着一套基于 Appium 的 Android 自动化用例规模大概一千条左右。听起来很多但真正能稳定跑完的不到六成。问题从来不在“写用例”上而在于三个长期无解的死结。第一个死结是脚本和 UI 强绑定。Android 碎片化导致同一个控件在不同厂商 ROM 上有不同的资源 id同一个功能在刘海屏和折叠屏上的布局完全不一样。你为了适配三台设备写的条件分支下个版本 UI 一改就全部作废。第二个死结是断言能力太弱。传统脚本的断言基本停留在“元素存在”“文本相等”这种层面稍微涉及“这个页面是否符合预期布局”“用户走完流程后是否有正确反馈”写起来极其痛苦。第三个死结是环境噪音。弹窗、网络延迟、权限请求、系统升级提示每一个都能让精心编排的用例瞬间失效而排错的时间往往比写用例的时间还长。这些痛点让我意识到一件事UI 自动化真正缺的不是执行力而是“理解力”。脚本只能执行预设步骤但测试的本质是“带着意图去探索未知”。ARTEMIS 切入的正是这个缝隙。1.2 ARTEMIS 的解法不录脚本而是派一个能看会想的 AgentARTEMIS 的全称是 Automated Robust Testing and Exploration via Multi-modal Intelligence System翻译过来就是“基于多模态智能的自动化稳健测试与探索系统”。它没有沿用“录制回放”或“脚本驱动”的老路而是把整个测试任务交给一个 LLM 驱动的 Agent你告诉它“打开应用注册一个新账号然后回到首页”它会自己去理解这个意图调用工具获取屏幕信息分析当前界面上有哪些可操作元素再决定下一步点击、输入还是滑动。这里的关键词是“理解意图”和“自主决策”这也是它敢叫 Agent 的原因。传统框架里的每个步骤都是确定性指令而 ARTEMIS 的每一步都带着一个推理动作——屏幕上有三个按钮注册入口到底在哪里右上角那个图标是不是菜单这些问题靠 XPATH 回答不了但靠大模型的常识和上下文推理可以做到。它不是替代测试工程师而是把测试工程师从“写死步骤”中解放出来去关注“测什么”而不是“怎么点”。1.3 它适合谁从移动端 QA 到独立开发者从我有限的实测经验看ARTEMIS 最香的场景有这几类人。第一类是移动端 QA 团队尤其是那些被脚本维护逼疯的中大型应用团队可以用它做冒烟测试、主流程探索和版本回归的辅助排查。第二类是独立开发者和小团队没有专门测试人力但又想在上架前对核心链路做一轮自动化验证ARTEMIS 的低门槛和高适应性会很受用。第三类是对 AI Agent 技术栈感兴趣的人ARTEMIS 本身就是个极佳的学习样本它把 ReAct 模式、工具调用、多模态感知整合进了一个真实可落地的项目中看完源码比读十篇 Agent 教程都管用。2. 从“看屏幕”到“做操作”LLM 驱动 Agent 的完整决策链路2.1 第一步把手机屏幕变成机器可读的“文本剧本”要让大模型理解手机屏幕上有什么最直观的方式是给它截图但直接丢截图存在很多问题。ARTEMIS 的做法更接近“把界面翻译成文本”通过 Android 的 UIAutomator 框架拿到当前界面的视图层级 XML然后对 XML 做清洗和结构化把每个控件的类型、文本、资源 id、坐标边界、可点击性等信息提取出来组装成一段模型能直接阅读的“屏幕描述文本”。这一步是整套系统的地基。为什么不用纯截图因为即便是最强多模态模型直接理解一张 UI 截图也经常犯糊涂弹窗遮住了底层内容、动态加载的列表项未渲染、深色模式下对比度不够、小手图标根本看不清楚。而视图层级 XML 包含的是控件的语义属性而不是像素特征比如“一个文本为‘登录’、可点击、坐标为(100, 800)的按钮”这种结构化描述天然比像素更适合做精确操作决策。但 XML 也有它的坏处——冗余。一个复杂页面可能有几十层的嵌套布局、大量不可见节点和装饰性 View直接全量丢给大模型既费 token 又影响判断质量。ARTEMIS 在清洗阶段做两件事去掉不可见节点过滤掉没有文本也没有内容描述且不可点击的纯布局容器再把剩余节点做扁平化合并。这一步处理完屏幕上的有效元素往往能从几百个骤减到二三十个任务瞬间清爽。2.2 第二步Agent 的“思考-行动-观察”循环拿到屏幕描述后Agent 就进入了核心循环。这个循环在 AI Agent 领域有个标准名字叫 ReActReasoning Acting思路是让模型交替进行“推理”和“行动”。每轮循环里模型先阅读当前状态——包括用户给它下达的任务目标、历史操作记录、当前的屏幕描述——然后输出一段推理说明“我为什么这样做”再输出一个具体的行动指令比如“点击坐标(540, 1700)上的‘确认支付’按钮”。行动执行后Agent 会再次抓取屏幕信息把新界面作为下一轮的“观察”结果继续喂给模型。这样一轮一轮滚下去Agent 就形成了一条完整的决策链根据观察理解现状根据理解制定行动通过行动改变状态再观察新状态。这套机制之所以适合真机测试是因为它天然容忍环境变化。屏幕上多了一个弹窗没关系下一轮观察里模型会看到这个弹窗并决定先点“我知道了”。某个按钮因为动画延迟没显示出来模型会基于历史经验选择等待一轮或者向下滑动看看。它不依赖任何固定定位路径所以面对 UI 变化时比传统脚本从容得多。2.3 第三步操作执行与错误反馈当 Agent 决定执行某个操作后ARTEMIS 通过内部封装的 adb 指令和 UiAutomation API 去驱动真机。在 Android 端它需要开启无障碍服务来模拟点击、滚动、长按等手势这和很多自动抢红包脚本用的是同一套底层机制只是 ARTEMIS 把它封装成了标准的工具接口。这里有一个容易被忽略的关键设计操作不是“下达完就结束”的。ARTEMIS 会把每次操作前后的屏幕状态都保存下来并且记录这个动作是否导致了界面变化。比如 Agent 点击了一个按钮但前后两帧屏幕完全一样系统就会标记一个“动作未生效”的反馈把这个异常情况写进上下文让模型在下一轮决策时知道“刚才那次点击可能失败了需要换一种方式再试一次”。这种闭环反馈机制大大提升了实测中的容错率也是它和那些“录一段脚本然后硬跑”的工具最本质的区别。2.4 为什么不用纯视觉模型直接看截图看到这里可能有人会问既然大模型都支持多模态了为什么 ARTEMIS 不直接用视觉模型截图识别我在实际测试中也试过类似的思路让 GPT-4o 直接看截屏做操作效果确实惊艳但到了规模化落地的环节就出了三个硬伤。第一是成本。一张 1080p 截屏的 token 消耗是纯文本屏幕描述的几十倍跑一轮完整测试几百次迭代API 费用轻松破百美元这在 CI 环境里基本不可接受。第二是精度。视觉识别能认出“这里有个红色按钮”但按钮的精确坐标往往靠猜而 UIAutomator 拿到的坐标是像素级准确的点击误差为零。第三是可解释性。文本形式的操作日志和每一步的推理记录方便人去做审计复盘纯视觉决策则像黑盒出了问题很难定位。ARTEMIS 采用的“结构化 UI 文本 必要截图辅助”的混合方案是在实测效果、成本和稳定性三个维度之间做出的折中我更愿意把它理解为一种务实的工程选择。3. 本地部署与真机接入的完整实操记录3.1 环境准备清单把依赖一次性装齐上手 ARTEMIS 的过程不算复杂但有几个坑在官方文档里只是轻轻带过我在这里把当时的操作记录完整还原出来。我用的系统是 Ubuntu 22.04Python 3.11Android 真机是一台 Pixel 6Android 13。机器连接方面没有太多意外但有几个关键点需要留意。首先是 Python 环境和依赖安装。ARTEMIS 的核心依赖包括 plyvel 作为 LevelDB 的 Python 绑定、grpcio 作为 RPC 通信库、pandas 处理数据、Pillow 处理截图、requests 调用 LLM API。用 pip 安装 plyvel 的时候我踩了个小坑它会默认去拉取 LevelDB 的本地库如果系统缺少 libleveldb-dev编译会直接失败需要先跑一条 apt install libleveldb-dev。其他依赖基本是纯 Python 包没有碰到什么障碍。依赖用途备注plyvelLevelDB 存储测试数据需先安装 libleveldb-devgrpcio内部服务通信版本冲突时先建虚拟环境pandas测试数据整理与分析用于生成结构化日志和报告Pillow截图处理与压缩减少存储开销requests调用 LLM API支持 OpenAI 协议或本地模型adb控制 Android 真机需单独安装绑定平台工具3.2 连接真机与授权解锁、开发者选项与无障碍权限连接真机这件事硬件连接很简单授权链路才是真正容易卡住的地方。我把步骤拆成这样三步。第一步开启开发者模式和 USB 调试。进入设置 - 关于手机连点版本号七次然后到开发者选项里打开 USB 调试。这里有个细节需要注意部分国产 ROM 还会多一层“USB 安装权限”或“USB 调试安全设置”建议一并打开否则后续 Agent 安装被测应用时会弹系统级授权框把整个流程卡死。第二步连接后执行 adb devices 确认设备在线。设备名称后面如果显示 unauthorized说明手机上的授权弹窗没有确认需要看手机屏幕手工点一下“允许 USB 调试”。这一步没有什么绕过技巧只能人工完成。接着我推荐执行 adb install 预装被测应用并顺手处理掉首次启动时的隐私协议弹窗——不然 Agent 第一轮就会被一个“同意并继续”的弹窗绊住。第三步开启无障碍服务权限。ARTEMIS 的执行引擎依赖 Android 无障碍服务来做点击和滚动操作但无障碍服务权限必须由用户手动在系统设置里开启没有任何 adb 命令能绕过。Android 12 以上设备需要到“无障碍 - 已下载的应用 - 选择 ARTEMIS 对应服务”里手动打开这一点第一次用的时候容易被漏掉。如果不开这个权限Agent 的点击操作会一直失败但报错信息又不够明显排查起来比较费劲。3.3 配置 LLM 接入与任务下发从注册流程到核心购买链路ARTEMIS 的模型接入层支持 OpenAI 兼容协议这意味着既可以直接用 GPT-4 系列也可以把模型服务替换成本地部署的 Qwen、DeepSeek 或者 vLLM 托管的开源模型。我测试时使用的是 GPT-4o-mini整体效果不错成本控制得也很好。实际的测试任务下发方式有三种。最简单的是通过配置文件指定任务的文本描述例如打开应用之后注册一个新用户填写邮箱为xxx密码为xxx然后验证是否跳转到首页。或者用它的 Python SDK 编写一小段脚本把任务描述和历史上下文传给接口适合做成自动化流水线。更灵活的方式是启动它的交互式控制台在命令行里动态修改任务目标适合调试阶段快速试错。我实测的第一个完整任务是注册流程。给 Agent 下达的描述比较口语化打开 App 后进入注册页面用邮箱 testexample.com 和密码 Test1234 注册一个新账号如果出现短信验证码弹窗点击跳过注册成功后回到首页并截图。这个任务大概走了十几轮决策过程中它正确识别了“获取验证码”按钮需要点击也正确处理了首次弹出的通知权限请求最终成功截图。整体耗时两分钟出头API 成本不到一毛钱这个性价比对于探索性测试场景来说是很能打的。3.4 跑通第一个任务的四个要点如果说这次实操有什么经验能直接复制我会总结成四条。第一任务描述写得越像交代给真人实习生的话Agent 的表现越好。笼统的“测一下登录”远不如“打开应用用已注册账号登录登录成功后确认首页显示个人头像”有效。第二首次连接真机务必手动跑一遍完整流程确认没有遗留的系统弹窗干扰后才交给 Agent。第三建议把屏幕超时设置调长至少 10 分钟以上否则 Agent 思考期间屏幕自动熄灭抓屏工具会一直拿到黑屏。第四Android 的动画缩放设置里把窗口动画、过渡动画、动画程序时长调整这三项全部关掉能显著减少 UI 不稳定带来的决策噪音这一招对任何 UI 自动化方案都通用。4. 和 Appium、Espresso 摆在一起比ARTEMIS 到底插在哪一档4.1 四类方案的横向对比ARTEMIS 出现后最常被问到的一个问题是它是不是要取代 Appium我的判断是短期内不太可能但它的确打开了另一条路。为了把定位说清楚我把自己用过的四类方案放在一起做了个对比。方案驱动方式脚本复杂度对 UI 变化的适应性适用场景Espresso应用内测试框架高低单元级 UI 测试、白盒验证Appium黑盒自动化中高中跨端回归、固定流程自动化MaestroYAML 描述低中轻量流程验证、团队协作ARTEMISLLM Agent极低高探索性测试、冒烟辅助、用例生成Espresso 的优势是快和稳因为它在应用进程内运行定位控件自带同步机制但这也意味着它必须和应用一起编译对集成测试场景极不友好。Appium 是当前工业界的主流选择跨端能力强生态成熟但脚本维护成本高且它对“动态弹窗”这类环境噪音的抵抗力很弱。Maestro 是个轻量派把测试写成纯 YAML 流程上手极快但依然摆脱不了“固定流程驱动”的本质。ARTEMIS 在对比中最突出的差异是前三个方案都要求用例作者预先知道界面长什么样、控件在哪个位置而 ARTEMIS 完全不需要它本身就在探索界面。4.2 不是替代品是互补品回归靠脚本探索靠 Agent我认为 ARTEMIS 和传统框架不是替代关系而是分工关系。回归测试追求确定性和速度核心高频用例必须可重复、可量化、可预期这仍然是脚本类框架的主场。而 ARTEMIS 的主场是那类“说不清楚到底会发生什么”的场景新功能首次接入时的冒烟探索、版本升级后的全核心链路走查、不同语言的本地化界面验证、以及辅助生成初始测试用例的人工智能加速器。我在实际工作里总结出一个稳妥的混合模式用传统的 Appium/Espresso 守住固定回归基线用 ARTEMIS 作为“探索哨兵”在新版本发布前跑一遍全功能域的自主走查把 Agent 发现的可疑路径和截图整理成人工审查清单。这就像给团队配了一个不知疲倦的实习生它的产出不是“测试结论”而是“需要你确认的问题”而且它确认问题的方式是真人操作式的逐层探索比脚本跑出来的报错信息直观很多。4.3 引入 ARTEMIS 的成本收益分析API 费用、稳定性和团队接受度任何技术落地都绕不开成本账。ARTEMIS 的收益很诱人但它也有实打实的支出风险这里把三个方面的账摊开来算算。API 费用是最直接的。实测下来一个中型的探索任务比如注册 - 登录 - 购买 - 退单大约消耗 20~40 万 token换成 GPT-4o-mini 的定价在 0.1 ~ 0.3 美元之间。如果一天跑五十次月成本大约几百美元对大多数团队来说完全可接受。但如果强行上最强的推理模型做同样的任务成本会直接飙升一个数量级所以选模型时要警惕“性能焦虑”。稳定性是我更担心的问题。即便是大模型驱动的 Agent也会出现“想岔了路径”的情况该点确认的时候点了返回该滚动的时候选择了点击。我观察到的经验是将任务拆分成更小的独立描述比一次性下发超长任务的成功率高出不少。假设一条完整链路变成“先注册”、“再登录”、“最后查看订单页”三个独立任务每个任务的上下文干扰就小很多。团队接受度是最后一个隐性成本。测试工程师从“写脚本”转型为“下任务、审报告”工作方式变化很大初期会有明显的适应期。我个人的建议是不要一步到位先在非核心模块跑两周把团队对 Agent 的信任感和对输出报告质量的判断力建立起来再逐步扩大范围。5. 实测中的翻车现场与应对方案没有一路顺风的 Agent5.1 权限弹窗和系统 UI 干扰怎么让 Agent 别在第一步栽跟头真机测试最烦的东西就是系统弹窗ARTEMIS 在面对弹窗时表现得比传统脚本聪明但也并非无懈可击。我跑第一轮完整流程时就翻过车Agent 准备点击“注册”按钮却被底部弹出的“要允许此应用访问设备上的照片和媒体内容吗”拦住。它确实识别出了这个弹窗但给出的决策竟然是直接点了拒绝然后继续找注册入口结果注册功能需要上传头像头像选不了整个流程断了。这类问题的本质是权限策略属于业务常识而不是界面识别能力。后来我在任务描述里显式加上了规则除非用户明确要求否则所有权限弹窗一律允许所有隐私协议弹窗一律点击同意所有推荐内容弹窗一律跳过。加了这一段前置指令后Agent 遇到弹窗的决策准确率有了质的提升。这说明一个问题Agent 的“常识”不等于你的业务预期把关键策略写清楚它才能像个熟悉你业务的实习生而不是第一次进城的旅客。5.2 内容描述缺失导致 Agent 看不懂屏幕如何处理“什么都不知道”的控件Android 应用质量参差不齐很多第三方应用只顾功能不顾无障碍规范控件既没有文本也没有 contentDescription屏幕上只剩一个不可点击但能看见的图形按钮。ARTEMIS 拿到这颗按钮的结构化描述时只能看到“View{...}没有文本、没有描述、没有角色模型根本无从推断这是个什么东西。我在测一个本地生活类 App 时遇到的情况非常典型底部的四个 Tab 全部是无文本图标Agent 尝试了三次都没能找到“我的”入口一直在首页打转。后来我手动打开了屏幕下方的“重试机制”选项让 Agent 在连续两轮观察无变化时允许结合视觉信息辅助决策。ARTEMIS 在后续版本中提供了截图补盲功能当 UI 文本信息不充分时会把局部截图以图片形式附加给多模态模型。开了这个混合模式以后这类“无文本图标”的识别成功率提升非常明显。所以我的建议是被测应用的无障碍规范很差的团队务必把“文本不足时启用视觉辅助”这个选项打开。5.3 长链路任务的“反悔与绕路”拆分任务比万能 Agent 更可靠一次性的长链路任务我踩过最惨的坑是一次连续 47 步的购买流程测试包括了选商品、加购物车、改赠品、选优惠券、改地址、提交订单六个子模块。Agent 前三步非常顺利然而在选优惠券的环节开始“绕路”它点开了一张不满足使用条件的券看到系统提示“未达到使用门槛”后竟然选择返回然后再次点开那张券形成一个死循环。排查后发现问题的根源在于长链路的每一步都在改变页面状态上下文窗口里积累了太多与当前子任务无关的历史信息模型被这些噪音干扰后做出的局部决策开始失真。我的解决思路非常简单——把长链路拆成短链路。把上面那条 47 步的任务拆成六个独立子任务每个子任务都是一个短循环上一个任务完成时的最终截图作为下一个任务的初始观察状态。拆分之后每个子任务的上下文都只有 5 到 10 轮交互模型的决策质量明显改善。这个经验后来被我总结成了一条团队内部的铁律单次任务描述控制在三步操作以内复杂业务流程必须拆分子任务串行执行。5.4 模型幻觉造成无效操作日志审计和重试机制缺一不可最后一个大类问题是模型幻觉。有一次 Agent 在一张完全没有“删除”按钮的详情页上坚持认为“右上角的更多菜单里有删除选项”接连四次点击菜单都没找到最终因为重试次数耗尽而判定任务失败。这种幻觉在视觉模型上尤为常见因为大模型对常见 UI 模式有先验认知看到类似布局就容易脑补出根本不存在的入口。应对幻觉我试下来最有效的手段是三重保险。第一层是重试限制给单次无效操作设置超时和重试次数上限避免 Agent 在同一个坑里反复试探。第二层是动作审计日志每轮循环都把“看到的屏幕摘要、做出的推理、执行的动作、动作后的结果”完整记录下来跑完任务后一键导出。第三层是人工抽查对失败任务按照日志逐条复盘把幻觉案例收集起来反哺给提示词模板比如加上“如果屏幕上没有目标入口明确报告找不到不要反复尝试”。把这三层都做到位Agent 的无效操作率能下降好几成。6. 它能扛什么、不能扛什么我的使用边界总结6.1 最适合 ARTEMIS 的应用场景探索、冒烟、兼容与用例生成从我的实测感受来看ARTEMIS 的第一主场是探索性冒烟测试。新版本提测后不需要再人工花半小时把核心链路全点一遍直接把任务丢给 Agent让它自己走完注册、登录、首页浏览、下单、支付全流程然后把每一步的截图汇总成一份图文报告。这种报告和传统脚本日志完全不同每一张图上有明确的点击红点标记管理者可以在几分钟内判断功能是否正常。第二主场是兼容性测试的辅助增效。Android 生态碎片化严重一家厂商一套行为传统自动化脚本在每台新设备上都要重新踩一遍坑。ARTEMIS 因为是探索式的天然适应不同的屏幕尺寸、分辨率和系统版本在设备池里并发跑多个 Agent 实例做基础流程冒烟是效率极高的兼容性筛查方案。第三主场是测试用例的自动生成。Agent 探索完一遍应用后它的完整操作轨迹可以直接转成结构化步骤作为人工确认后沉淀为传统脚本用例的初稿。我团队里已经有同事靠这个方式把新模块用例的编写时间压缩了大概一半这个用法对既有测试资产同样是一种增值。6.2 不适合的场景高频、强断言和严格可复现性ARTEMIS 不能扛的场景我也碰过几次值得大家冷静对待。首先是高频回归测试比如每次代码提交后都要跑的核心冒烟集合。这类任务追求速度和确定性Agent 每一步都有推理延迟跑一条用例的耗时是传统脚本的五到十倍而且单次决策存在随机性不同轮次的路径可能不同这在严格要求的 CI 主链路里很难接受。其次是强断言场景。Agent 擅长发现“哪里有东西出现在不该出现的地方”但它不擅长做数值断言比如“列表必须恰好展示 18 条数据”或“金额计算误差不能超过 0.01 元”。这类精确验证还是得交给脚本拿到数据后去对比ArtEMIS 无法替代。最后是严格可复现的场景。如果某个 bug 需要精确复现每一步操作序列Agent 每次决策的随机性会让复现变得困难。尽管可以记录日志后手动回放但效率不如传统脚本直接重跑固定序列来得干脆。总结起来一句话ARTEMIS 是发现问题的哨兵不是负责把每个问题精确钉死的锤子。6.3 后续的可能演进多 Agent 协作、云端设备池与强化学习ARTEMIS 目前的形态已经能落地使用但站在开发者角度看它还有很多值得期待的演进方向。多 Agent 协作是第一个明显趋势不同 Agent 分管不同功能域在测试时互相传递状态和发现能覆盖更大范围的应用场景。第二个趋势是和云端真机设备池打通让 Agent 自动在多台远程设备上批量执行测试任务把目前人均一台真机的模式扩展成“一个任务跑满一批设备”。第三个方向是把强化学习引入测试策略调优用历史测试结果作为反馈信号逐步优化 Agent 的探索优先级把资源集中在最容易出问题的模块上。这些方向如果落地Agent 在质量保障体系里的位置就不是“辅助工具”了而是真正参与版本质量决策的基础设施。当然路要一步一步走眼下先把 ARTEMIS 接进来跑一轮冒烟已经比多数团队的测试手段领先一步了。我在实际使用中最大的体会是不要把它和 Appium 放在对立面去比较而是当作一个补充力量接入现有体系。先拿一个小应用跑两周让它帮你做冒烟、生成探索报告、甚至发现一两个漏网 bug团队自然会对 Agent 建立信任。再往后你可能会惊讶地发现维护脚本的时间真的省下来了而那些时间花在“设计更有质量的测试任务”上比花在修改 XPATH 上有价值得多。