做移动端测试的朋友应该都体会过这种循环写脚本、跑脚本、改脚本。几百行的 UI 自动化用例产品改个按钮位置就全红模拟器上点点点都没问题一接真机就开始迷之卡顿版本迭代一多回归测试的重复劳动基本可以把人钉在工位上。Google 开源的 ARTEMIS核心就是干这件事——用 AI Agent 去接管 Android 真机测试让测试人员从维护脚本的泥潭里抽身出来。这个项目解决的是“测试脚本扛不住变化”的痛点。传统自动化把操作步骤写死UI 一改步骤就失效了ARTEMIS 的思路是让大模型直接理解测试目标自己看屏幕、自己决定点哪里、自己判断结果对不对。对测试从业者、移动开发、以及正在了解 AI Agent 应用落地的人来说它把“Agent 规划”和“真机设备控制”这两个原本割裂的技术栈连在一起算是一个非常典型的实操范本。下面我会从项目思路、架构拆解、实操流程、问题排查、经验心得几个方面展开聊内容以常见实践为补充希望能给你一个可以直接参考的落地路径。1. ARTEMIS 到底在解决什么问题1.1 传统自动化测试的尴尬先聊一个很现实的场景。你现在要给一个购物 App 写一条测试用例登录、搜索商品、加购、下单。用传统的 UI 自动化框架你需要定位登录按钮的 id输入框的 resource-id搜索框的坐标下单页的控件树节点。要是开发顺手改了布局把 LinearLayout 换成了 Compose 实现id 全变了你的脚本注定要重写。这种模式的问题在于测试脚本本质上是在“跟 UI 结构的实现细节绑定”。你维护的不是业务逻辑而是一堆控件的物理位置。移动端版本迭代又快两周一个版本每次改版都是一轮“找新控件、改定位符、修等待条件”的循环。如果你的项目里自动化用例超过几百条维护成本是很恐怖的。还有一个痛点模拟器和真机的差异。模拟器里 CPU 架构、系统版本、屏幕尺寸相对可控但真机有厂商深度定制的 ROM有各种诡异的权限弹窗有弱网、有通知栏干扰。同一套脚本模拟器上跑得好好的真机上可能第一步就被一个“允许获取设备信息”的弹窗卡住了。传统自动化框架处理这种不确定情况只能靠“如果出现弹窗点击允许”这种笨办法弹窗一变就又失效了。所以测试圈一直在找一条新路能不能让测试工具自己理解“当前屏幕上发生了什么”然后根据任务目标去做决策。这正好撞上了大模型的风口。1.2 AI Agent 相比脚本的核心价值ARTEMIS 的出发点就是把“测试任务”抽象成一段自然语言描述而不是一段代码。你告诉 Agent“帮我把商品加入购物车并截图返回”Agent 自己会拆解步骤先找搜索入口、输入关键词、点击第一个商品、找到加购按钮、点击、截图。这个“拆解步骤-执行-验证-调整”的过程在 AI Agent 领域叫“任务规划Planning”和“工具调用Tool Use”。ARTEMIS 让 Agent 拥有的工具就是 Android 真机上的各种操作能力点击、滑动、输入文本、截图、返回按键、读取界面元素树。大模型负责思考工具负责动手。它的核心价值在于适应性。因为 Agent 不是靠固定坐标操作而是靠“看”屏幕截一张图读一下界面结构再决定往哪点。UI 改了按钮位置变了它重新看一眼就知道新按钮在哪。这打破了过去“脚本必须跟着 UI 结构走”的死结。当然这里要说得直白点AI Agent 不是魔法它不可能 100% 替代人工测试但它能把“重复的、确定性的、需要视觉理解的”那部分工作自动化掉。比如版本回归、多机型兼容性验证、冒烟测试这几个场景非常适合。1.3 为什么必须用真机有的朋友可能会问既然 Agent 能看屏幕那用 Android 模拟器不行吗行但不够。ARTEMIS 强调真机测试背后有几层原因。第一真机上才能暴露真实交互问题。模拟器的触摸事件、传感器数据、网络环境都是虚拟的无法模拟真实的物理设备和网络环境下的表现。真机上的 GPU 渲染性能、系统通知、不同品牌的 ROM 行为才是用户实际遇到的体验。你用模拟器测出一堆绿色通过用例不代表用户在真机上不出问题。第二很多业务功能在模拟器里根本没法完整跑通。比如扫码、NFC、蓝牙、电话状态、应用间跳转。这些操作依赖真实硬件和系统服务模拟器只能给你一个残缺版本。你让 Agent 测试一个“微信授权登录”流程模拟器上可能第一步就卡住因为它跳不出真实的授权环境。第三真机测试的最终目标是一套用例跑在几十台不同品牌、不同系统版本的设备上验证兼容性。ARTEMIS 的架构天然适合多设备管理每台设备是一个独立执行环境Agent 可以像人一样逐台操作也可以并行调度。这是模拟器体系很难做到的。2. 架构拆解ARTEMIS 是怎么“接管”真机的2.1 感知层让 Agent 看到手机屏幕AI Agent 要接管一台真机第一步是解决“感知”问题。它得知道当前屏幕上是什么、有哪些可操作区域、这些区域代表什么功能。ARTEMIS 在感知层面主要拉了两个数据通道屏幕截图和 UI 层级树。屏幕截图好理解通过 adb 命令执行 screencap 就能拿到一张 PNG 图片交给多模态大模型进行视觉理解。这种方式对视觉类问题非常直观按钮重叠、图标错位、颜色异常模型一眼就能看出来。但只有截图还不够因为截图像素再高对文字内容、控件边界、可点击区域的判断还是不如结构数据准确。UI 层级树是从 Android 的 Accessibility 服务或者 uiautomator dump 获取的 XML 文件里面记录了当前页面上每个控件的位置、大小、文本、resource-id 等信息。你可以把它理解为“给手机屏幕做了一份带坐标的说明书”。Agent 结合截图和 XML 两份数据既能理解页面的视觉样式又能精确知道“这个按钮的点击中心点在哪”。这里有个实践细节拿到 XML 后建议做一次裁剪和清洗。原始 dump 文件往往包含大量重复的、无意义的布局节点直接塞给大模型会浪费 token 还会干扰判断。ARTEMIS 的做法是把 XML 简化成“控件列表”只保留关键字段text、resource-id、bounds、enabled、clickable。这样模型看到的信息密度更高决策准确率也会明显提升。2.2 决策层LLM 如何规划操作路径有了屏幕信息下一步就是“下一步做什么”。这一层是 ARTEMIS 的灵魂也是它跟过去“规则自动化”最大的分水岭。ARTEMIS 的 Agent 核心是一个大语言模型但跟你在网页端聊天不一样的是它运行在一个“循环”里。大致流程是接收任务目标比如“测试登录功能”。获取当前页面截图和控件列表。模型根据目标、当前页面状态输出一个行动决策点击某个按钮、输入文字、滑动、返回等。执行这个行动。重新获取页面状态验证上一步是否生效。如果页面状态符合预期继续下一步如果不符合模型会重新思考并尝试别的操作。这个循环在 AI Agent 领域叫“ReAct 范式”推理Reasoning和行动Action交替进行。大模型在这次循环里同时扮演“大脑”和“眼睛”把不完整的信息补进去做出最合理的下一步动作。关键点是模型不应该被允许自由地“随便点”。ARTEMIS 会给模型设定一套约束规则。比如一次只能输出一个动作动作必须从预定义的工具集中选择如果同一个动作连续执行多次都没变化就要停止并转交给人工处理。这就像你给实习生下任务你可以自己想办法但不可以乱来遇到卡住超过三次就要上报。2.3 执行层从“想”到“做”的关键一跳Agent 想好了要点击某个坐标怎么真正让手机“动”起来这里靠的是 Android 生态里一套已经很成熟的自动化工具链adb 和 Appium/uiautomator2。ARTEMIS 在执行层把大模型输出的行动指令翻译成具体的 adb shell 命令或者通过 uiautomator2 的 Python/RPC 接口下发操作。核心工具包括input tap x y模拟手指点击某个坐标点。input swipe x1 y1 x2 y2 duration模拟滑动轨迹。input text 内容输入文本。adb shell am start启动或唤醒应用。adb shell am force-stop强制停止应用。adb shell wm size获取屏幕分辨率用于坐标换算。一个很容易踩坑的地方是大模型从 XML 里读到的 bounds 是“物理像素坐标”但某些设备上还需要考虑屏幕密度和显示缩放。如果用 uiautomator2 定位控件它内部会做坐标换算问题不大但如果让模型直接输出坐标并调 adb 执行必须统一都换算成同一套坐标体系。建议在接入层做一次坐标归一化而不是把这个问题抛给大模型。执行层还要解决“操作可靠性”问题。比如输入文本时如果输入框有前置焦点要求必须先点击输入框再等待键盘弹出再输入。ARTEMIS 的做法是把这些常见的“前置条件”固化在工具定义里大模型不需要知道 Android 输入框的焦点机制它只要说“在输入框中输入用户名”工具层自动处理点击焦点和输入动作。这样做的好处很明显模型决策更稳定工具执行更可靠两端各做自己擅长的事。2.4 验证层怎么判断测试到底过没过Agent 执行完一系列操作后怎么判断测试是通过还是失败这是 ARTEMIS 里容易被低估的一部分。验证分两个层次。第一个层次是“过程验证”步骤执行后页面有没有发生预期变化。比如点击“搜索”后界面应该出现搜索结果列表点击“登录”后应该跳转到主页或出现登录成功提示。ARTEMIS 在每一步执行后会重新截图和抓取控件列表让模型对比前后差异判断上一步操作是否真正生效。第二个层次是“结果验证”整个任务完成后用一个明确的标准去判断测试是否通过。ARTEMIS 支持两种方式。一种是让大模型基于最终截图和业务逻辑做多维度判断比如“登录后个人信息区域是否显示正确用户名”。另一种是写硬断言用脚本检查某个关键控件是否存在、某个页面元素文本是否匹配。实际项目里两种方式都在用关键路径用硬断言保底视觉体验方面用大模型判断。我个人强烈建议不要把大模型判断当成唯一标准。模型有幻觉有状态不稳定它说“通过”不代表真的没问题。正确做法是把大模型判断作为“第一道筛选器”把可疑用例标记出来再交给人工复核。ARTEMIS 会把整个操作过程录屏、截图、记录操作日志人工复核时基本不用复现一遍看日志和截图就够了。3. 从零开始跑一次 ARTEMIS 测试3.1 环境准备与设备接入先说环境。跑 ARTEMIS 需要准备的东西比较常规一台能跑 Python 的开发机、一台 Android 真机建议先拿一台容易调试的比如 Pixel 或主流国产机、开启开发者选项和 USB 调试模式、安装 adb 工具。如果要用 Android Studio 看资源文件或处理日志也可以装上但核心链路里严格来说不必须。设备接入有个经常出问题的点USB 调试授权弹窗。手机第一次连电脑时屏幕上会弹出一个“允许USB调试吗”的对话框必须手动点允许。命令行用 adb devices 看到设备状态是 device 才说明授权成功如果显示 unauthorized 就是还没允许。这个弹窗很容易被自动化流程忽略我的习惯是接入后先跑一遍 adb devices确认状态再往下走。第二步是准备环境依赖。ARTEMIS 通常用 Python 写核心库包括 uiautomator2、Pillow、openai 或其他大模型 SDK。安装完成后在 Python 里执行 device u2.connect() 连接设备。如果设备列表里有多台需要指定序列号序列号用 adb devices 查看。接着要确认两个信息屏幕分辨率和 Android 版本。分辨率影响坐标换算Android 版本影响部分 adb 命令的兼容性。把它们记下来后面配置 Agent 参数时要用到。3.2 定义测试任务ARTEMIS 的测试任务本质上就是一段“给 Agent 看的需求说明书”。任务描述写得越好Agent 执行越顺。我在实操中总结了一个任务描述模板大概是这样的结构任务目标一句话说清楚要做什么比如“测试从首页搜索商品到加购的完整流程”。关键步骤提示告诉 Agent 大概要经过哪些节点比如“先搜索再点击商品详情再选择规格再加购”。这一步不是强制流程而是给 Agent 的导航防止它跑偏。验收标准明确什么状态算成功比如“加购按钮出现‘已加入购物车’提示购物车角标数字增加”。约束条件比如“不要修改收货地址”“不要生成真实订单”“如果遇到需要登录的情况使用测试账号登录”。任务定义完转换成 Agent 可以理解的指令格式通常是 JSON 结构包含 role、content、priority 等字段。ARTEMIS 会把任务描述和系统预设的工具说明一起喂给大模型让它在给定的行动空间里做决策。值得注意的是首次测试千万不要上来就跑复杂流程。建议从“打开 App-点击某个按钮-截图返回”这种一分钟内能完成的小任务起步确认整条链路通了再逐步增加复杂度。这样排查问题方便也能快速验证 API 调用、设备控制、模型输出这三个环节是否正常。3.3 关键参数与配置跑通一次测试需要关注几个关键参数。第一个是超时时间。Agent 每一步操作后都会等待页面刷新但如果页面卡死或者网络慢模型会一直等不到新状态。ARTEMIS 里一般会设置单步操作超时比如 10 秒和任务总超时比如 5 分钟。超时后进入兜底逻辑——重新截图如果页面没变化就标记为“疑似卡死”并停止。第二个是最大尝试次数。模型不是每次都运气好点错按钮、输入错内容都可能发生。ARTEMIS 允许每个步骤最多重试 N 次超过次数就报错退回人工。这个 N 我建议设成 3太少模型没有纠错机会太多会浪费时间。第三个是模型温度参数。温度控制输出的随机性测试场景需要可复现、稳定所以温度要设低一点比如 0 到 0.2。如果温度太高同一个页面模型可能这次点这个按钮、下次点那个按钮测试结果就不稳定了。第四个是截图压缩和控件列表过滤的最大长度。真机截图分辨率往往很高直接发给多模态模型不仅慢还可能超出模型的输入 token 限制。实操中会把截图先缩放到宽度 720 像素左右再提交控件列表只保留 text 非空的节点。这样既保证模型能看懂又能显著降低接口延迟。3.4 结果产物与人工复核一次 ARTEMIS 测试跑完后应该产出几样东西操作录屏、关键步骤截图、完整操作日志、每个步骤的决策说明、测试结论。实际操作中操作日志的价值最大也是最容易做好的。ARTEMIS 一般会把每次“模型输出动作-工具执行结果-页面状态变化”都记录成结构化的 JSON 日志。这个日志不仅能用来排查问题还能用于后续调优哪一步模型反复犹豫哪个页面经常导致 Agent 卡住看日志比看录屏效率高得多。人工复核环节我推荐抓三个重点。第一个看“Agent 是否做了预期之外的操作”。模型毕竟是模型它可能为了达到目的去点了一些不该点的东西比如退出登录、清缓存。这些操作在日志里必须暴露出来。第二个看“步骤时序是否合理”有没有出现点击没生效、重复滑动等异常。第三个看最终的硬断言结果比如关键控件是否出现数据是否匹配。如果任务失败先把失败原因分类是设备连接问题、控件识别问题、还是模型决策问题。分类之后再针对性修复而不是盲目调 prompt。这部分直接决定 ARTEMIS 能不能从“demo 能跑”走向“真正可用”。4. 常见问题与排查实录4.1 设备连不上与授权异常真机测试第一步就是设备连接这块的问题出现频率超高。最常见的三种情况adb devices 列表为空、设备状态显示 unauthorized、设备状态显示 offline。列表为空通常有三种原因。数据线只支持充电不支持数据传输换一根数据线是最高效的解决方式。没装设备厂商的 USB 驱动Windows 上尤其常见去设备管理器看有没有带感叹号的设备。手机的 USB 模式选成了“仅充电”需要改成“文件传输MTP”模式。unauthorized 状态表示你没点手机上的授权弹窗或者弹窗已经被误设置为“一律拒绝”。去手机开发者选项里找到“撤销 USB 调试授权”全部撤销后再重新插线会重新弹出授权框。offline 状态一般是 adb 服务问题先执行 adb kill-server 再执行 adb start-server然后重插数据线。还有一个容易忽略的点手机锁屏会导致执行一些可交互操作时失败。建议测试期间把屏幕常亮设置为“超过 30 分钟”或者用 adb shell svc power stayon true 保持屏幕常亮防止黑屏导致截图全是黑色。4.2 不规则 URI 与系统弹窗处理实际测试中经常会碰到系统弹窗和应用内弹窗比如权限请求、更新提示、手机管家拦截。ARTEMIS 的 Agent 虽然能看到弹窗但能不能正确处理是另一回事。以“跳转到文件管理选择文件”为例Android 系统的文件选择器在不同厂商 ROM 上长得完全不一样。有的弹窗会给出类似 content://com.tencent.wework.fileprovider/external_path/android/data/com.xxx 这样的非标准 URI普通文件访问根本拿不到路径。这种情况 Agent 就算看到了也不知道怎么选到目标文件。我的做法分两步。第一步是在 Agent 的工具集中预置“通用弹窗处理”能力识别常见的权限弹窗文案比如“允许”“拒绝”“始终允许”自动做匹配并点击预期按钮。第二步是遇到涉及系统文件选择的场景尽量不用真实文件管理器而是在测试环境中预置一个固定的 UI 元素可点击或者用更深度的工具直接模拟文件选择结果。如果实在绕不过把这一步也交给 Agent 去读提示词里明确告诉它“当前处于系统文件选择页只允许点击带有目标文件名的项”。核心教训是不要把问题抛给 Agent 去自由发挥。它不认识各个 ROM 的文件选择器差异。提前在工具层做兼容处理比堆 prompt 有效得多。4.3 页面加载慢与等待策略AI Agent 测试经常遇到“页面还在加载但 Agent 已经认为操作成功了”的假象。点击一个按钮后页面上先出现加载中的菊花随后才显示内容。如果模型在一个瞬间截了图看到的是中间态可能做出错误判断。ARETMIS 处理这个问题靠的是一套“状态稳定检测”。每执行完一个操作不要立刻截图而是让设备空闲几百毫秒连续截两张图对比。如果两张图一致说明页面结构稳定了再交给模型分析。如果两张图不一致就继续等。这个策略能过滤掉大部分加载动画、过渡动效带来的误判。还有一种常见情况是网络慢导致页面部分加载顶部内容出来了底部还在转圈。模型可能只看到了页面的一部分就误以为流程可用。我的建议是在验收标准里写清楚“需要检查的完整条件”比如“列表页显示至少 3 个商品卡片且没有加载提示”让模型不能拿半成品页面作为通过依据。如果页面加载经常超过 10 秒就要从网络环境和设备性能上找原因了不要单纯拉高超时时间。超时设太高失败用例会拖很久才报错整个测试资源都耗在等待上。4.4 Agent 误操作与模型幻觉约束最后聊一个 AI Agent 项目的“原生问题”模型幻觉。模型可能“觉得”自己点过某个按钮但看日志发现它根本没有执行也可能执行了但点错了坐标它还坚称自己点了正确的地方。约束手段有几层。第一层是“行动前确认”模型的输出必须是一个结构化的工具调用 JSON包含 tool 和 arguments 字段。系统代码只认结构化的工具调用不接受纯文本回复。这样从格式上就把“模型随便说话”的路径堵住了。第二层是“权限最小化”Agent 的工具集不要给全只给当前任务可能用到的工具。比如这个测试任务只需要点击、滑动、截图就不要让它能打开系统设置。第三层是“进度校验”每完成一个关键里程碑比如成功进入购物车页面就用一次独立的截图比对做确认如果页面状态与预期不符立即暂停并说明原因。实操中还有一个很有用的技巧在系统提示词里加一句“如果你不确定当前页面状态请重新截图并检查控件列表后再行动。禁止猜测点击位置。”这看起来简单实际能明显减少模型在奇怪位置乱点的概率尤其是很多模型在首次尝试失败后容易开始“猜坐标”越猜越偏最后把 App 点到了后台。5. 我的使用心得与后续扩展5.1 什么场景真正适合 AI Agent 测试用了一段时间之后我的感受是AI Agent 测试不是银弹它适合的场景非常清晰。第一类是冒烟测试和核心流程回归这些用例数量少但业务价值高UI 改动频繁导致脚本维护成本太高用 Agent 可以省掉大量维护时间。第二类是弱视觉校验比如主题换成深色模式后按钮是否还清晰、多语言切换后是否出现文字截断这类问题用传统断言写起来麻烦但让大模型看图判断很自然。第三类是弹窗和异常状态测试Agent 可以灵活响应意外弹窗而传统脚本遇到弹窗经常直接挂掉。不适合的场景也有大型数据精确校验、涉及大量序列化输入的任务、需要毫秒级 UI 响应的性能测试。这些还是用老办法更靠谱。ARTEMIS 的价值在于补位不是取代。5.2 如何在这个架构上做二次开发开源项目的意义在于你可以把它改成自己的工具。ARTEMIS 架构上留了几个很好的扩展点。第一个扩展点是接入自己的大模型中间层。你可以把决策层替换成私有化部署的模型也可以接入市面上主流的商业大模型 API。关键是要把工具定义部分保持通用这样换模型不影响设备控制链路。第二个扩展点是自定义工具。你可以往工具集里加“读取已安装应用列表”“动态修改系统权限”“注入间接定位”这类定制操作。加工具时记得给模型写清楚工具的适用场景和参数含义模型才能正确调用。第三个扩展点是多设备调度。ARTEMIS 的架构可以扩展成一个简单的设备池一台控制机管理多台真机每台设备跑一个独立的 Agent 实例任务队列统一分发执行结果统一回收。跑兼容性测试的时候这个能力非常实用。5.3 给入坑者的几条实在建议最后分享几条我做过之后觉得最有价值的经验。第一从最小的闭环开始。第一周不要想着做复杂业务流只做“打开 App-截图-返回”这一件事把设备接入、模型调用、结果回收全部跑通。第二周再加一个点击操作。第三周再加输入。这样每个阶段的需求都很清晰出了问题也容易定位。第二日志是绕不开的投入。整个 Agent 执行过程中间产生的决策数据和观察结果一定要保存下来。它们不仅是排查问题的依据也是以后做提示词调优和模型选型的数据基础。没有数据你连“模型这周比上周差”都判断不出来。第三始终保留一个人工确认环节。Agent 可以跑但最终发布之前的确认权暂时还是保留给人类比较稳妥。等你在真实项目里积累足够多的通过率和失败率数据之后再决定哪些步骤可以完全自动化。我在实际使用中的体会是AI Agent 测试目前处于一个很微妙的状态它已经能帮你扛下很多过去要加班去干的回归验证但你仍然需要把它当成一个需要调教的工具而不是一个可以直接信任的测试员。上手之前尽量想清楚你要解决的具体问题是什么不要为了 AI 而 AI。如果你的场景恰好是“UI 频繁变化、真机覆盖多、回归压力大”那么 ARTEMIS 这套思路很可能就是现阶段最值得投入的方向。