谷歌把 ARTEMIS 开源这件事在 Android 真机测试圈子里算是炸了锅。一句话说清楚它是什么一套让 AI Agent 在真实 Android 手机上自主完成任务的测试平台同时附带一整套评测基准。以前我们聊自动化测试绕不开脚本、选择器、录制回放而 ARTEMIS 的思路是把测试目标写成自然语言让大模型驱动的 Agent 像人一样在手机上点、滑、输入最后用预置条件自动判定通过与否。这个方向对做移动质量保障的同学、搞 AI Agent 应用开发的团队、还有研究智能体评估的人来说都属于刚需级参考因为它把AI 能不能用这个问题落到了一个非常具体的工程载体上而不是停留在 Demo 里。我拿到这个项目之后最大的感受是它不像普通开源测试框架那样只给你一堆 API而是把整套测试基础设施——任务定义、设备控制、Agent 交互、结果回放、指标计算——都串起来了。这篇文章我就从项目要解决的问题讲起再拆架构、说部署、讲评测、列坑尽量把我实际摸索出来的东西一次讲透。1. 项目定位拆解AI Agent 和 Android 真机测试是怎么结合的1.1 传统真机测试的三大痛点先说一下传统方案为什么越来越不够用。做过 Appium 或者 UiAutomator 的人都有体会自动化脚本本质上是在和 UI 结构做对抗页面改了 id、加了弹窗、升级了 Flutter/Compose 版本选择器就失效脚本就红。我见过维护成本高到离谱的用例库三分之一的时间在修定位符而不是在找 Bug。第二个痛点是脚本只能覆盖你写过的路径。真实用户的操作往往是跨应用的——从消息通知跳转到支付、从日历复制会议号再切到会议 App、在相册选图再发到聊天窗口。这种多应用交织的场景脚本写起来极其痛苦因为你要同时管理等多个应用的前后台状态任何一个环节的时序错位都会导致整条链路崩掉。第三个痛点是断言难写。传统自动化断言的是某个元素存在不存在、某个文本对不对但用户任务成功的标志往往不是某个控件可见而是整件事办成了——比如订单状态变成了已发货、会议链接真的能被识别。这类语义级的成功判断脚本几乎做不了。1.2 ARTEMIS 用自然语言任务 条件判定绕开这三个问题ARTEMIS 的做法和我上面说的套路完全反过来。它不要求你写一串点击坐标和选择器而是把任务描述成一句话比如在时钟应用里设置一个明天早上 8 点的闹钟标签为 起床。这句话同时包含两层信息一是给 Agent 的指令告诉它做什么二是评测依据平台在 Agent 操作完之后去检查系统里是不是真的多了一个 8 点的闹钟这就是所谓的 post condition。这个设计的精妙之处在于它把测试用例从代码变成了数据。任务清单是 JSON 或者 Python 结构同一个任务可以反复跑在不同的真机上、配不同的模型不需要因为手机分辨率变化而改脚本因为 Agent 是靠界面截图和视图层级去理解页面的而不是靠固定坐标。说白了ARTEMIS 不是一个自动化测试工具它是一个AI 智能体能力测试台只是刚好借用了真机测试的外壳。做质量保障的人可以用它验证模型能不能操作手机做 AI 应用的人可以用它评测我的 Agent 在真实环境里到底行不行这两类需求最后落到了同一个开源项目上这是它最值钱的地方。2. 架构和核心链路Agent 到底是怎么接管手机的2.1 一个典型任务的完整执行链路从我在本地跑通的情况来看ARTEMIS 的一条任务链路大致是这么走的用户在任务配置里写好目标自然语言和前后置条件执行器把任务下发出去Agent 侧拿到任务描述后先从测试台取回一帧手机截图和 UI 层级信息然后由大模型决策下一步动作动作通过 adb 执行到真机上比如input tap、input text、input swipe或者启动某个应用每次动作之后平台会再次截屏再把新的状态回传给 Agent循环往复直到 Agent 自己判定任务完成或者达到最大步数上限。这个观察-决策-执行-再观察的闭环本质上和人类操作手机的流程是一模一样的。人也是看一眼屏幕决定点哪里点完再看一眼确认结果ARTEMIS 只是把这个循环里的人换成了大模型。执行链路里比较关键的一个点是ARTEMIS 和底层设备之间的通信并不只有一个裸的 adb而是有一个中间控制层负责把 Agent 发来的结构化动作指令翻译成具体的 adb 命令同时把设备端截图和视图层级清洗成模型方便读的格式。这一层在项目里充当的是手机的手和眼睛Agent 本身不带任何 Android 相关的技术依赖它只需要理解一张图和一串文本就能干活。2.2 四个核心模块逐个拆我把项目里最重要的四个模块拎出来讲按我的理解简单分类第一是任务定义模块。每一个测试任务都带 setup、goal 和检查条件。setup 负责把手机恢复到同一个起点比如清掉应用缓存、登录指定账号、预置某条消息goal 是给 Agent 看的自然语言描述检查条件则是平台用来判定成功与否的硬指标。这三者的解耦是 ARTEMIS 能稳定复现同一任务的关键因为如果没有 setup 做状态归位Agent 第一次跑和第二次跑面对的初始界面不一样结果就没有可比性。第二是设备编排模块。它的职责是管理一批真机支持并发调度、任务排队、设备恢复。Android 真机在长时间运行 Agent 任务时非常容易进入异常状态——弹窗挡住屏幕、应用崩溃、系统 OOM——编排模块要能做最基本的健康检查发现设备无响应就重启任务或者重新初始化设备。这一层对跑大规模评测来说是刚需没有它就只能一台机器跑一个小任务然后人肉去救。第三是Agent 交互模块。它定义了模型怎么接进来包括使用哪个模型服务、上下文怎么组装、历史轨迹怎么组织。你可以把它理解成 Agent 的运行时框架ARTEMIS 本身不绑定某一个模型你可以接 GPT、Claude、Gemini也可以接本地部署的小模型这正是它适合做模型对比评测的原因。上下文的长度控制、截图压缩策略、历史动作的裁剪都在这一层做属于调优潜力最大的地方。第四是评测与回放模块。任务跑完之后平台会依据预置的条件检查结果同时把整个过程的截图、动作序列、模型思考记录打包供人复盘。这一步在传统自动化里对应的是测试报告但在 Agent 场景下它的价值更高因为你不能只看通过不通过你得知道 Agent 哪一步绕了远路、哪一步点错了又自己纠偏了这些过程信息才是优化 Agent 的真正素材。2.3 ARTEMIS 和 Appium 这类工具的真正边界经常有人问我有了 ARTEMISAppium 是不是可以扔了我直接给结论两者解决的问题不同短期内是互补关系不存在谁替代谁。一个重要区别在于确定性。Appium 脚本是确定性的同一个版本下跑一百次预期结果是一致的适合做回归验证能精确地告诉你某个功能坏没坏。ARTEMIS 跑同一个任务模型每次的决策路径都可能不一样它告诉你的更多是这个任务在当前模型能力下能不能完成、大概要几步统计意义大于精确断言。第二个区别是定位粒度。Appium 面向的是测试工程师要求你懂代码、懂选择器、懂等待策略ARTEMIS 面向的是任务本身写配置的人只需要描述清楚目标和判定条件剩下全交给 Agent。门槛不同适用范围自然也不一样。第三个区别是成本。脚本跑一遍消耗的是几秒钟执行时间和一点点电费Agent 跑一遍消耗的是几十次甚至上百次模型调用量级完全不是一个概念。所以我的建议很直接日常回归继续用脚本需要探索新路径、评测模型能力、模拟真人复杂操作的时候再上 ARTEMIS把资源用在刀刃上。3. 从 0 到 1 搭建本地跑通 ARTEMIS 的实操笔记3.1 环境准备清单我本地实际跑通用的环境如下给大家一个可复现的配置参考硬件一台 Android 10 以上的真机我用的是一台 Pixel 4ARM 架构模拟器也能跑但真机表现更接近真实使用场景ARTEMIS 的名字里就带着 real-world所以我建议上手阶段直接用真机系统Ubuntu 22.04macOS 也可以Windows 需要多做一步 USB 驱动的事基础软件Python 3.10、Android SDK platform-tools确保adb命令可用、Android Studio 可选但建议装调试 UI 层级时好用模型服务准备一个可用的 LLM API Key我初期用的 Gemini后面换了其他模型做对比发现任务配置层基本不用动这个兼容性做得确实舒服设备连接上跟普通开发调试没有区别手机开启开发者模式、打开 USB 调试、用数据线连上电脑然后确认adb devices能列出设备。这里有个细节ARTEMIS 初始化阶段会往设备上安装它自己的一个控制应用这个应用需要辅助功能权限才能读取视图层级所以手机上会弹权限授权框这一步要手动点掉不然 Agent 拿不到 UI 树信息后面就会变成瞎子摸象。提示建议在授权完成后用adb shell settings把相关权限固定成默认授予否则设备重启后授权会失效自动化流程会卡在启动阶段。这属于我第一次跑就踩过的坑。3.2 三步跑通内置示例任务项目仓库里带了一批内置任务覆盖通信、娱乐、出行、办公等场景我拿其中一个最基础的任务做了冒烟测试。整个流程抽象下来就是三步第一步克隆代码并安装 Python 依赖。仓库结构比较清晰核心代码在artemis/目录下配置入口是一个 YAML 文件。依赖安装直接用pip install -r requirements.txt没有遇到什么版本地狱这点对新手很友好。第二步修改配置文件。你需要填三样东西设备 ID就是adb devices里那串序列号模型服务的 API Key 和端点任务清单路径。我建议第一次跑的时候把最大步数限制调低一点比如 15 步这样假设 Agent 卡住也不会等太久方便快速验证整条链路通不通。第三步执行启动命令。运行入口会先做设备初始化安装控制应用然后开始任务循环。你会看到终端里实时输出每一步的决策内容和截图编号那个过程其实相当解压——模型真的在一张一张看图、一点一点操作到最后输出 PASS 或者 FAIL 的时候你会有一种在围观一个虚拟同事干活的错觉。我第一次跑通用了大概半小时其中大部分时间耗在权限授权和配置踩坑上真正的任务执行只要几十秒。所以这里给新手的建议是先跑通冒烟任务再研究内部实现别一上来就想改源码。3.3 自定义一个测试任务直接抄这套模板内置任务跑通之后绝大部分人的下一步需求一定是我想测我自己的 App。自定义任务的路径也不复杂核心是理解任务配置的字段结构。我贴一个精简版的任务模板结构上可以直接套用{ task_id: com.example.calendar.add_event, name: 在日历中创建一个明天上午10点的事件, goal: 打开日历应用创建一个明天上午10点开始、标题为项目评审的事件, setup: [ {action: clear_app_data, package: com.google.android.calendar}, {action: launch_app, package: com.google.android.calendar} ], check: { pre_conditions: [], post_conditions: [ {type: event_exists, title: 项目评审, time: 10:00} ] }, max_steps: 30 }字段含义我逐个说一下。goal是给 Agent 的任务描述写得越贴近真人自然语言越好它会成为模型引导的核心setup是前置状态准备我习惯把清数据启动应用固定搭配确保每次跑之前环境是干净的post_conditions是成败判定这里写的是一个语义化条件——去找日历里是不是真的存在一个符合标题和时间的事件而不是去匹配某个控件的坐标。这里必须强调一个原则post condition 要写结果状态不要写操作过程。你去检查是否点击了保存按钮是没有意义的你要检查的是事件是否真的创建成功。这个原则决定了任务评测的鲁棒性Agent 可以换一百种方式达成同一个结果但只要结果对就算对。3.4 关键配置参数的个人推荐值配置参数里我调过最多的是下面几个直接给结论max_steps控制在 20~40 之间比较合理。太短了模型还没试错空间就被判失败太长了复杂任务会白白浪费 token而且长轨迹容易让上下文超出窗口限制。history_window我一般保留最近 5~8 步的历史太少模型会忘记之前做过什么太多则容易把关键信息挤出去。截图压缩策略建议打开真机截图原图分辨率通常很高直接塞给模型会拖慢响应、拉高成本压缩到适合视觉模型输入的尺寸是个性价比很高的优化。模型温度建议调低Agent 操作手机是个需要稳定性的场景温度太高会出现莫名其妙的炫技操作。注意这些参数不是固定的不同模型、不同任务复杂度最优参数差异很大。我建议每换一个模型就跑一遍参数扫描用任务完成率而不是单次通过情况来定参数这才有统计意义。4. 评测机制详解怎么判断 Agent 是真的会还是蒙对的4.1 为什么用结果条件而不是路径匹配最开始我做 Agent 评测的时候用的还是传统思路——拿 Agent 的轨迹和预设的标准操作序列比对相似度高就算好。这套思路在 Agent 场景下很快就崩了因为大模型从来不会老老实实按标准路径走它可能跳过中间页、可能先去设置里改个东西再回来、可能绕一大圈最后还能到终点。过程匹配对这种殊途同归的智能行为几乎无能为力。ARTEMIS 的做法是只看终态不看过程这是它评测设计上最聪明的部分。它把一个任务的成功定义成系统最终状态满足若干条件比如指定文件存在、指定设置生效、指定数据写入成功。这本质上是一种弱监督方式不需要人工标注每一步对不对只要最终状态达标就判通过。对于评测规模化来说这种免标注特性太关键了。当然只看终态也有盲区我会在下面常见问题里展开讨论。这里先给结论终态判定是 Agent 评测的基石但它适合的是任务型评测不适合过程合规性评测——如果你关心的是支付过程中有没有违规绕过风控那还得单独看轨迹。4.2 评测输出里我最关注的四个指标平台最终会汇总一批指标我实际分析结果时主要看四个维度第一是任务完成率这是最硬的指标。同一任务集跑 N 轮完成的占比多少直接反映模型在这类任务上的基础能力。不同模型之间比高低首先看这个数字。第二是平均步数反映效率。两个模型完成率一样一个平均 12 步搞定一个平均 40 步还在原地绕圈后者明显对复杂界面的理解能力偏弱。这个指标在成本核算时尤其重要因为步数几乎等价于 token 消耗。第三是失败原因分类。我把跑的失败任务全部分类后发现一个规律大部分失败不是模型不会操作而是卡在了环境异常上——弹窗未处理、权限没给、网络慢导致页面加载超时。这类失败其实是假失败和 Agent 能力无关。把它们单独归类后模型的真实能力才浮出水面。第四是任务回放里的纠错行为这个是定性指标。我特别喜欢看 Agent 点错之后的反应有些模型会停下来思考并修正有些模型会沿着错误路径越走越远。会纠错的 Agent 才是真在理解页面这可能比完成率更能反映模型上限。4.3 一组实测数据的解读范例我拿三个模型在同一组 10 个任务上跑出来的对比数据做个示范虽然具体数字不具备普适性但解读思路是可以复用的。假设结果是这样模型 A完成率 80%平均步数 22 步失败集中在跨应用跳转类任务模型 B完成率 70%平均步数 35 步失败集中在需要输入长文本的任务模型 C完成率 90%平均步数 18 步但有 2 次出现了越权操作点了系统设置里的危险权限这个结果如果只看完成率模型 C 好像最强但结合其他维度看就有隐患C 的越权操作说明它对界面元素的理解存在风险虽然最终结果正确方式却有合规性问题。模型 A 的跨应用能力弱适合在单应用场景用模型 B 效率低可能上下文组织有问题调调参数还有上升空间。这样多维度的解读才能让评测真正指导选型和优化而不是停留在谁分高谁厉害的层面。5. 常见问题与排查技巧实录5.1 设备连接与控制类我跑 ARTEMIS 过程中遇到最多的就是设备侧问题。最常见的是 adb 掉线表现为终端里设备显示offline。排查思路一句话先看线材和接口再看驱动最后看授权。实话说十次里有八次是 USB 线质量不行换根原生数据线瞬间恢复。另外建议在长时间评测前执行一次adb kill-server adb start-server能规避很多偶发问题。还有一个困扰过我很久的是设备休眠。手机锁屏之后 Agent 的截图就全黑了任务必失败。解决方案是无脑取消屏幕休眠开发者选项里把不锁定屏幕打开同时用adb shell svc power stayon true保持唤醒。这个命令在长时间任务集执行时几乎是必须的不然你半夜挂机跑评测第二天起来发现所有任务都失败在锁屏上。权限类问题也很隐蔽。ARTEMIS 控制应用需要悬浮窗、辅助功能、通知读取这三类权限缺任何一个都会导致 Agent 感知或操作受限。我踩过的具体坑是辅助功能权限在部分 ROM 上重启后自动失效如果发现任务一开始就看得到界面但点不动先查权限是不是掉了。5.2 Agent 动作与模型相关的问题Agent 侧的问题通常更高级一点。最典型的是点击偏差模型看到了界面也知道该点什么但给你的坐标有偏差点到了旁边的元素。这类问题根源往往在截图分辨率和实际触摸坐标的映射上我遇到过设备默认分辨率下正常、切到高分辨率显示模式后就出现系统性偏移的情况排查时先排除这层因素。第二个高发问题是上下文超长。复杂任务跑几十步之后历史记录会把上下文窗口塞爆模型开始失忆重复之前的操作或者答非所问。我的对策是缩短history_window、加截图压缩强度实在不行就拆分任务把一个长任务拆成多个中等任务串起来效果立竿见影。第三个问题是模型幻觉。模型在无法读取页面完整信息时会脑补一些不存在的按钮或者状态然后做出完全匹配不上现实的决策。这类问题没有银弹解法我能给的建议只有两条一是让模型在动作前输出一句简短的当前页面理解二是在代码层面拦截重复动作——同一个位置连续点击超过三次就强制暂停这两个手段能把幻觉带来的损失控制在一定范围内。5.3 任务恢复与状态污染任务恢复是很多人忽略但其实很要命的环节。ARTEMIS 以任务开始时状态一致为前提但真实设备跑久了之后会积累大量状态残留通知栏堆消息、应用后台开了几十个、缓存撑满存储。这些残留会让同一个任务在不同轮次面临完全不同的初始环境评测结果直接失真。我的排查经验是每个任务跑完后强制清一次应用数据定期重启设备。如果发现某个任务从稳定通过变成偶尔失败先别急着怀疑模型很大概率是设备状态污染了重启之后再跑立刻恢复。这一点在长时间无人值守的自动化评测中尤其重要宁可跑慢一点也要保证每个任务之间的状态隔离。5.4 问题速查表现象可能原因快速处理设备显示 offline线材/USB 口/驱动问题换线、重启 adb 服务截图全黑设备锁屏关闭锁屏、保持唤醒能看到界面但点不动辅助功能权限丢失重新授权并固定权限持续点到错误位置分辨率映射问题检查 display 设置模型重复执行同一动作上下文过长导致失忆缩短历史窗口、拆分任务任务时好时坏设备状态被污染清数据、重启设备6. 落地实践与个人体会6.1 哪些场景适合上 ARTEMIS根据我跑了大量任务的经验ARTEMIS 目前最“出活”的场景有三个。第一个是跨应用流程的回归验证比如从短信验证码跳转并填入 App 完成登录这类脚本难写、但 Agent 天然擅长的任务第二个是模型能力横向对比团队在做 Agent 选型的时候用它当统一的评测题板最公平第三个是新功能探索式测试让 Agent 自由操作新版本 App它经常能走出测试同学想不到的操作路径虽然定位 System UI 的 Bug 是超纲了但发现交互设计上的迷惑点非常有用。6.2 不适合的场景也要说清楚我也不建议把 ARTEMIS 神化。纯 UI 像素级回归、性能压测、需要精确毫秒级操作的场景它都不合适。另外像支付流程这种强合规场景终态判定无法覆盖过程中是否违规需要谨慎使用。成本上它也不便宜一个复杂任务的模型调用费可能抵一整个脚本回归套件所以我的原则很清楚能用脚本的地方用脚本脚本搞不定的再交给 Agent两者是组合拳不是替代关系。6.3 个人的一些建议最后分享几个我在实操中的体会。第一别一上来就追求全自动无人值守先让跑出来的轨迹可以人工复盘你对 Agent 表现建立直觉之后再做自动化才有意义。第二任务配置要当测试用例一样做版本管理Agent 和平台版本迭代后旧任务的表现可能会有变化有版本记录才能追溯原因。第三时刻关注设备群的健康状态真机就是消耗品跑得越狠坏得越快。这套东西的未来其实可以想得很远——任务生成、失败自动分类、模型自我反思都还有大量可扩展空间。我个人的看法是ARTEMIS 这类项目真正打开的不是某个工具的市场而是把智能体能不能在真实世界干活这个抽象问题变成了一个可以量化、可以复现、可以迭代的工程问题。对做 AI 应用的人来说这种把玄学变成工程的进展可能比工具本身更值得关注。