1. 当UI自动化脚本还在修定位ARTEMIS已经看懂了屏幕做了几年移动端测试的同学应该都有过这种体验Appium脚本写得再顺换了台真机就莫名点不到元素UI Automator的定位方式一套再套vivo和Pixel的渲染差异照样让脚本一夜报废。维护成本比手工点点点还高遇到弹窗、权限对话框、热修复提示脚本直接原地去世。真机测试这件事本质上一直是靠人肉盯着屏幕堆设备写死路径硬扛的。Google在2025年开源了ARTEMIS把AI Agent塞进了Android真机测试这条链路。它的思路和我上面说的写脚本模拟点击完全不是一回事ARTEMIS不通过xpath、resource-id定位控件而是让一个多Agent系统自己看屏幕截图、读布局信息、理解当前界面状态然后用自然语言描述测试目标让Agent自主决定下一步点哪里、滑哪里、输入什么。这意味着测试不再是被写死的线性脚本而是一个具备上下文感知能力的数字测试员。这篇文章我会从ARTEMIS的实际架构、部署流程、真实测试效果和踩坑体验几个维度展开适合正在做Android测试、想尝试AI Agent落地或者纯粹对移动端自动化新范式感兴趣的开发者。里面涉及的所有编译命令、配置参数、Agent交互逻辑都是基于我在本地环境实际跑过的经验整理出来的。2. 为什么说ARTEMIS不是又一个自动化测试框架聊ARTEMIS之前得先把老一代自动化测试方案的底摸清。不然你体会不到它换赛道的地方在哪。2.1 现有框架的底层矛盾脚本是盲操作不管用Appium还是UIAutomator核心逻辑都是先通过uiautomator dump拿到当前界面的控件树然后按resource-id、class、text属性去找目标控件找不到就滑动重试。这套东西在稳定环境下能用但有两个致命缺陷。第一控件树和真实渲染经常不一致。很多App的界面是Compose、Flutter或者混合WebView渲染的控件树的粒度、时机、内容都和控制台对不上。尤其Compose的语义树和View体系差异很大老一套定位方式在全新界面上经常拿到一堆没有resource-id的节点脚本无从下手。第二脚本本身是无状态的。它不关心屏幕上发生了什么只按预设路径走。一旦出现意外弹窗、网络异常、文案变更脚本就崩。所谓的智能等待、动态重试都是在给这个盲操作打补丁补丁叠多了脚本维护成本就失控了。2.2 ARTEMIS的范式切换从执行脚本到理解任务ARTEMIS全称是Android Real-Test Environment for Multi-agent Interaction and Supervision核心思路是把测试过程改造成一个大语言模型驱动的多Agent协作系统。你给它一个自然语言测试目标比如检查登录页面在输入错误密码时的报错表现它自己拆解出子步骤打开App、定位输入框、输入错误密码、点击登录、截图观察报错弹窗、记录结果。整个过程由一个LLM Controller统一调度它不是预先写好的指令序列而是每走一步都重新观察屏幕、重新决策。在这个架构下真机测试第一次变成了有视觉、有理解力、有自主行动能力的过程和人类测试员的逻辑天然对齐。这才叫Agent接管。3. ARTEMIS多Agent架构拆解四个角色如何协同ARTEMIS内部不是单一大模型硬撑着干完全部活而是一个多Agent系统。每个Agent各司其职像一个小团队在跑业务。理解这套分工方式对后续你自己部署、调试、甚至二次开发都很关键。3.1 核心角色一览Agent职责关键交互方式LLM Controller总调度解析目标、拆解任务、评估结果与所有Agent直连Android Agent实际操作Android真机执行点击、输入、滑动等通过adb与设备通信Desktop Agent操作测试电脑端完成文件备份、日志抓取、模拟数据准备等本地命令执行FileSystem Agent管理测试产物归档截图和日志维护文件索引桌面环境文件操作整套系统里LLM Controller是大脑Android Agent是手Desktop Agent是后勤FileSystem Agent是档案室。它们周期性向Controller汇报状态Controller根据汇报决定下一步指令。3.2 Android Agent的真机操控原理Android Agent是整个ARTEMIS里离设备最近的一层它的工作依赖几个关键技术点安卓布局的层级化序列化每做一次决策前Agent会抓取当前界面的View层级结构序列化成层级化的文本或结构化信息喂给LLM做阅读理解。基于adb shell的输入指令通过input tap、input text、input swipe等命令直接操作设备不走UIAutomator那套控件查找天然绕开了元素定位的兼容性问题。多模态输入截图是必须的但ARTEMIS还会把截图和布局信息一起送给LLM让模型同时看图像长什么样和结构是怎么组织的决策准确度比纯文本高很多。提示部署时Android Agent有两套工作模式一套基于Android的AccessibilityService采集UI层级另一套基于截图OCR。前者信息更结构化后者对动态渲染内容更鲁棒实际项目里建议按App类型做切换。3.3 LLM Controller的任务拆解逻辑Controller拿到自然语言目标后不是一股脑丢给Android Agent去执行而是做两件事。第一是子任务分解。比如测试注册流程的异常输入校验Controller会拆成打开注册页输入非法邮箱输入弱密码提交表单检查错误提示截图留存等多个原子步骤。每个步骤都有明确的验收条件。第二是上下文管理。Agent每执行一步Controller会把历史截图、之前执行的动作、当前界面状态拼成一个有结构的Prompt让LLM决定下一步动作。这个上下文窗口是流水式更新的不会无限膨胀避免长任务跑着跑着就把前面的信息忘了。4. 从零跑通ARTEMIS源码编译、环境配置与真机连接这部分是纯实操内容我按自己实际走过的流程来写尽量把容易卡住的点标出来。4.1 机器与系统要求先看硬件和系统底子。ARTEMIS官方仓库建议在Ubuntu 20.04/22.04上跑Python版本要求3.10及以上内存建议16GB起步。我实际测试时用的是32GB内存的机器开两个Agent实例并发跑整体压力不大。Android设备侧要求Android版本建议Android 8.0及以上ARTEMIS依赖一些较新的UI自动化接口。需开启USB调试和**不锁定屏幕**选项防止测试过程中息屏卡住。建议关闭系统自动更新弹窗、厂商自定义管家类弹窗否则会持续打断Agent的判断。4.2 环境准备与依赖安装先建一个干净的虚拟环境然后拉源码git clone https://github.com/google/artemis.git cd artemis python3.10 -m venv venv source venv/bin/activate pip install --upgrade pip按仓库的requirements清单装依赖。有个小坑如果有机器同时存在多个Python版本建议直接用python3.10指明版本创建虚拟环境否则后续有些LLM相关依赖会把环境搞得很乱。ARTEMIS本身需要对接一个大语言模型作为Controller的推理引擎支持OpenAI格式的API通道也支持本地部署的推理服务。按仓库说明把API Key和Base URL填到配置里就行。如果本地有条件跑一个量化版的开源模型也可以只是智能度和速度都会有一些差距。4.3 adb多设备连接与配置ARTEMIS是通过adb与Android设备通信的所以先把adb环境弄通。adb devices同一时间连多个设备的话需要给每个设备配置单独的serial。ARTEMIS配置里支持指定设备列表每个Agent实例绑定一个device_serial否则Controller不知道该指挥哪台设备干活。注意如果你要在同一台机器上并行跑多台真机务必给每台设备设置不同的Agent实例ID和日志目录不然FileSystem Agent归档时会把多个设备的结果写到同一个文件里最后做报表时会发现混成一团。4.4 启动与首次运行配置好之后启动指令大致结构如下python main.py --agent-config configs/agent_config.yaml --task 打开计算器应用输入 123456截图保存计算结果首次启动时ARTEMIS会自动拉起一个状态监测循环先确认adb在线再截图看当前设备界面然后由Controller判断人在哪里。如果设备当前停在桌面Controller会先通过Intent或应用列表找到计算器并启动。这就是一个完整的自主感知-决策-执行闭环和传统脚本adb shell am start的机械程度完全不一样。成功跑通后ARTEMIS会把每一步的截图、动作记录、任务完成情况一并归档这些都是后续分析和调试的一手材料。5. 真实项目中ARTEMIS的接管边界执行的盲区与翻车现场说是AI Agent接管但别期待它无所不能。我在实际项目里跑了各种类型用例把它的能力边界摸得差不多清楚。5.1 擅长的场景自然语言驱动的功能性验证ARTEMIS在以下场景里表现得非常稳冒烟测试给一句从首页进入商品详情再加入购物车返回首页确认购物车角标变化它可以连续跨页面操作稳定完成。权限弹窗处理App首次启动时的存储权限、通知权限弹窗传统脚本常常因为弹窗出现时机不确定而挂起ARTEMIS每次截图后都会重新判断当前有没有弹窗然后自动点允许或拒绝完全不需要预设。跨应用跳转验证比如微信拉起支付、分享到第三方App这类场景Agent会自然地在不同App之间来回切换不需要写死包名和Activity路径。5.2 翻车场景一内容类App的随机加载给我上了一课信息流、短视频类App有一个特点每次打开推荐内容都不一样布局还会动态变化。我拿一个短视频App做测试任务目标是浏览首页10个视频并检查是否有明显卡顿。理论上人来做很轻松但ARTEMIS在第一版执行时频繁滑过头——因为它的滑动指令依赖上一帧截图里视频卡片的坐标而推荐流每次渲染的卡片尺寸、间距都可能不同。模型计算出坐标之后input swipe的落点和幅度并不稳定。后来我改了个思路配合Android Agent的布局层级信息先定位当前屏幕里视频卡片的中心点坐标再围绕这个坐标计算上滑距离。效果明显改善但这也说明一个问题——纯视觉方案在动态布局下依然有天花板得靠结构信息去兜底。5.3 翻车场景二OOM与ANR弹窗改变了App状态机还有一次测试某个大图浏览App任务执行过程中设备弹出了**App isnt responding**的ANR对话框。ARTEMIS的Controller一开始没识别出这是一个系统级异常弹窗而是把它当成了App正常界面的一部分差点继续在上面乱点。我断掉任务手动干预后在配置里补了一条Prompt规则——如果截图中出现isnt responding或keeps stopping字样视为异常状态先点击Wait或Close再截图确认恢复。加上这类系统异常判定规则后后续再遇到类似状态Agent就能自己收敛了。经验ARTEMIS是一个框架它的智能程度高度依赖你喂给它的世界规则。不要指望它第一次跑就能处理你App里所有奇奇怪怪的状态弹窗把它当成一个可以接收经验的Agent来调教收益会大得多。6. 让ARTEMIS在企业CI/CD里跑起来Jenkins集成与多设备调度如果你所在的团队已经有自动化测试流水线那下面这部分肯定对你有用。ARTEMIS适配CI/CD并没有想象中那么复杂关键在任务编排和产物汇总这两环。6.1 Jenkins Pipeline中集成ARTEMIS任务在Jenkins里加一个阶段本质上就是跑ARTEMIS命令并收集退出码。如果Agent在执行过程中检测到任务失败退出时返回非0状态码Pipeline就能自动标记该次构建为失败。下面是我在Jenkinsfile里写的一个参考片段stage(ARTEMIS AI Agent Test) { steps { sh cd ${WORKSPACE}/artemis python main.py --task 验证登录流程 --device-serial ${ANDROID_SERIAL} --output-dir ${WORKSPACE}/artemis_report } post { failure { archiveArtifacts artifacts: artemis_report/** } } }这里有个细节ARTEMIS任务时长波动很大同一个任务在不同机器上跑快则两三分钟慢则十几分钟和LLM推理速度、设备响应速度都有关。对应的Jenkins里的timeout要给足超时后不要简单kill掉进程要留出收集当前日志的时间否则排查问题会非常痛苦。6.2 多设备并发的调度策略真机测试的核心价值之一就是不同机型覆盖。ARTEMIS支持多设备并发但并发量不是无脑往上加的。控制变量有两个一是单设备Agent独享一个Python进程多个Agent实例之间不要共享Controller实例否则上下文会串二是设备的系统差异需要单独配置预期。比如同样一个设置页面在MIUI和ColorOS上的入口位置、文案都不同如果给所有设备同一个测试目标成功率一定参差不齐。我在团队里用了一套折中方案同一台服务器最多挂4台设备每台设备单独一个Agent进程测试目标按机型分组保证同一组的系统风格和Android版本接近。这样子任务并发整体效率翻倍成功率也稳定得多。6.3 测试产物的归档与观测ARTEMIS默认会在输出目录写出一系列文件每步动作前的截图、最终结果截图、Agent决策日志、执行时间线。我建议把这些数据统一归档成两类截图序列按任务ID建目录每张截图按step_序号.png命名方便事后按时间线回放。决策轨迹把每次Agent动作和LLM选择的理由合并成一个JSONL文件这一步对调试很有价值——某一步为什么点错、模型是基于什么上下文做出的选择都可以追溯。这部分数据沉淀出来后还能反哺另一个方向用真实执行轨迹构造更精准的Prompt示例库定期回灌给Controller让Agent在迭代后越来越懂你的App。7. ARTEMIS的进攻型测试玩法Shield模式下对抗性测试除了常规功能性验证ARTEMIS还有一个我很看重的模块叫Shield这名字就挺有攻击性——它的定位不是测功能而是想办法搞坏你的App。7.1 Shield是什么思路普通测试是按正常用户路径走Shield反其道而行它会主动注入异常和压力状态观察App能不能扛住随机状态扰动在Agent操作过程中随机触发系统级事件比如切换网络、调整系统时间、修改系统字体大小、模拟来电看App界面是否错乱。针对性演进提示LLM Controller会基于当前页面内容持续生成恶意变体操作指令。比如页面里有一个提交按钮它不只点一次还会在输入极端长度内容、快速连点、清空内容后提交等边界状态下反复尝试。这套能力对企业级App来说尤其有价值特别是涉及支付、表单、账户信息的场景。传统测试团队想覆盖这类健壮性用例通常靠手工写很多脚本成本高且思路固定。Shield利用LLM的泛化能力做探索覆盖的边界组合会广得多。7.2 实测iPhoneX高清壁纸OCR识别项目里的Shield用法我拿一个内部做OCR识别的App需要拍照识别文档试过Shield。任务定义为拍照页面的上传与识别流程。Shield在跑了三轮后真的发现了一个低频Bug——当系统时间被修改到前一天时拍摄照片的EXIF时间戳显示正常但上传后服务端因为时间校验不通过直接丢弃请求界面还显示上传中状态永久卡死。这个用例换传统脚本测试思路几乎不可能被覆盖到因为脚本根本不会想到去改系统时间。ARTEMIS结合LLM的联想能力在对抗性测试里确实打开了新的空间。7.3 Shield的局限与风险控制Shield虽好用但别直接放到无监督的流水线里。它能对App做的事情太野了有可能触发不可逆的状态比如修改系统设置后忘记还原、产生脏数据等。我的建议是Shield任务独立标记跑在专门的真机池上不占用常规回归设备任务执行前先通过Desktop Agent备份重要数据并在结束后adb执行系统设置的恢复脚本。另外Shield任务必须设置执行轮次上限我一般限制单任务最多10轮超过就强制停止并归档防止Agent在异常状态里无限循环。8. 关于Agent测试的一些延伸思考ARTEMIS这套方案能释放出来背后其实是一个趋势测试工程的核心思考正在从怎么写定位器转向怎么描述清楚一个目标。以前我们花大量时间维护脚本、适配控件树本质上是在跟描述和实现之间的鸿沟作斗争。ARTEMIS通过LLM把这个鸿沟填掉了一大截但它也把新的难题抛到了我们面前——Prompt的质量、上下文的管理、异常状态的规则沉淀这些成了新的脚本维护成本。我自己在实际用下来的体会是短期里ARTEMIS不会替代传统自动化但它非常适合作为探索性测试的补充力量尤其适合那些人手工做很繁琐、脚本写起来又太脆的场景。而且随着本地大模型推理效率的提升把ARTEMIS部署成团队内部一个7x24小时运行的自动化测试实习生这件事的成本会越来越低。最后分享一个小技巧刚开始接触ARTEMIS时不要一上来就让它做复杂业务链路先挑5条最简单的冒烟用例跑透。把截图-布局信息-动作日志的闭环看明白再逐步叠加任务复杂度。测试这件事多数时候我们缺的不是聪明工具而是理解工具边界的过程。