ARTEMIS 这个名字刚出来的时候我在测试群里看到不少人都在转第一反应是 Google 终于把“AI 自己测 Android 应用”这件事做成开源工具了。以前我们聊 AI 测试更多是停留在“用 AI 生成测试用例”“用 AI 分析日志”但 ARTEMIS 给人的感觉完全不一样——它是一个跑在真机上的 AI Agent能自己看屏幕、自己点按钮、自己输入文字遇到崩溃还能自己捞日志。这篇文章我就基于自己的理解和动手实践把 ARTEMIS 是什么、怎么工作、怎么部署、有哪些坑一次性讲清楚。1. 传统真机测试为什么让人头疼先说一个容易被忽略的事实真机测试和模拟器测试体验完全是两回事。模拟器环境干净、资源可控、方便复现但很多问题只在真机上才会出现——特定厂商的系统定制、屏幕分辨率、传感器状态、弱网场景、内存压力、推送通道甚至某些系统的“省电策略”都会让应用行为变得不一样。所以正规的移动端项目发布前一定会过一轮真机兼容性测试。可真机测试的痛点也非常明显。第一是耗时。一个人一台手机从安装、启动、登录、浏览、操作、回归场景一多就是半天。如果涉及多个机型、多个系统版本时间成本直接翻倍。第二是脚本维护成本。传统的 UI 自动化测试Espresso、Appium、UIAutomator 这类虽然能跑但脚本和控件绑定页面结构一变脚本就死维护成本常常高过写脚本的成本。第三是覆盖有限。脚本是人写的人想到什么才测什么很难穷尽真实用户的路径更别提临时起意的探索性测试了。还有一个隐藏问题很多现成的自动化工具依赖 root 或者特定测试框架在用户日常使用的系统环境里跑不起来导致“测试环境过了用户手机崩了”的事情反复出现。ARTEMIS 切入的其实是这个场景——用大模型驱动一个 AI Agent 在真实设备上“像人一样操作”你只需要用自然语言告诉它要做什么剩下的点击、滑动、输入、等待、观察它自己完成。听起来有点科幻但实际操作下来它确实把“自然语言驱动真机测试”从概念变成了可运行的工程方案。2. ARTEMIS 核心思路拆解Agent 是怎么“接管”手机的要理解 ARTEMIS 的原理先搞清楚一个最根本的问题它凭什么知道该怎么操作手机答案是大模型对屏幕的“视觉理解”能力。ARTEMIS 的核心机制并不复杂——它把手机屏幕截图喂给视觉语言模型VLM模型通过截图识别出当前界面的布局、控件、文字然后基于你给出的任务目标决定下一步要执行什么动作。这个“看屏幕—想动作—做动作—再看屏幕”的循环就是 Agent 的基本运行方式。打个比方以前我们用脚本测试等于给一个不认识路的司机写死每一步怎么走。ARTEMIS 则是给司机一个目的地和一套交通规则它自己看路牌、避让行人、转弯掉头。这里有个关键点ARTEMIS 不需要 XML 控件树、不需要 id、不需要 xpath它直接“看”像素所以对界面结构的依赖性极低。哪怕页面元素乱飘、动画频繁、控件层级复杂它都能靠着画面信息做出下一步判断。动作层的设计也很有讲究。ARTEMIS 不是只能“点一下”或者“划一下”它抽象出了一个相对完整的动作空间包括点击、长按、滑动、输入文字、返回、按键等基本操作。这个动作空间本质上就是 Agent 能使用的“工具”模型从工具列表里挑选合适的工具再配合坐标参数执行。这样做的好处是既能覆盖绝大多数测试场景又不会因为动作太自由而失控。我特别注意到它对于抽屉、弹窗、权限提示这类内容的处理。这些元素在传统自动化里是“杀手”权限弹窗一出现脚本就不知道该怎么办而 ARTEMIS 可以识别弹窗内容并主动选择“拒绝”或者“允许”配合系统返回键绕过阻塞效果比固定脚本强很多。在任务推进方式上ARTEMIS 也做了分层。它先接受一个高层的用户指令比如“测试注册流程并验证是否能成功创建账号”然后模型自己拆解成“打开应用—进入注册页—输入邮箱—设置密码—点击注册—检查跳转—验证是否登录成功”一系列子任务再逐条执行。这种从总目标到子动作的任务分解能力恰恰是传统自动化框架最欠缺的部分。3. 为什么说 ARTEMIS 和普通“AI 测试工具”不一样市面上其实已经有一些号称 AI 测试的产品但看下来大多停留在“用 AI 帮你生成测试脚本”的阶段——你给它录一段操作它生成代码或者你用语言描述场景它翻译成脚本。这类工具的价值在于节省脚本编写时间本质上还是脚本驱动。ARTEMIS 路径完全不同Agent 本身在执行测试任务不做代码翻译。它像一个“虚拟测试员”你说“帮我在设置里关闭自动更新”它会自己去设置页、找到开关、滑动关闭再返回。这种差异带来两个直接变化一是测试过程不受脚本“死步骤”的限制。脚本是线性执行的每一步结果固定一步错也许下面全错而 Agent 每一步都根据实时屏幕内容做动态决策页面多了半个广告、弹了个红包、系统改了交互样式它都能即时调整。二是测试失败后的可解释性大大提升。传统脚本失败只会告诉你“元素没找到”你得猜是页面崩了还是控件变了。ARTEMIS 的执行过程本身就是多轮视觉文字的记录它能告诉你“我看到了什么、我做了什么、结果如何、最终是否完成目标”。这对定位 bug 非常有价值。还有一点是并行扩展性。真机测试往往需要“多机同测”传统脚本你要为每台设备单独维护配置ARTEMIS 的 Agent 机制天然适合配对多台真机每个设备一个 Agent 实例共用一套模型服务任务可以分布式下发。这意味着“一组推理模型管一排手机”的集中式测试架构是可行的。不过也要说句公道话ARTEMIS 并非万能它更适合“任务导向的验证”和“探索性回归”你让它做像素级断言或者复杂到需要领域知识的业务校验短期内还是需要人来兜底。4. 动手实操从 0 到 1 跑起 ARTEMIS接下来是大家最关心的部分怎么把它跑起来。我以 Linux 环境为例Mac 和 Windows 的差异点在过程中会单独说明。4.1 第一步准备基础环境ARTEMIS 的底层依赖几个基础组件Python 3.9 及以上、Android SDK重点是 platform-tools 里的 adb、JDK部分依赖 gradle 构建时需要、一个可用的模型推理接口。首先把 SDK 和平台工具装好。# 下载并解压 Android SDK command-line tools mkdir -p ~/android-sdk/cmdline-tools cd ~/android-sdk/cmdline-tools # 将下载的 tools 压缩包解压并重命名目录为 latest export ANDROID_HOME~/android-sdk export PATH$PATH:$ANDROID_HOME/platform-tools # 或者直接使用 apt 安装不适合生产环境但快速验证够用 sudo apt install android-sdk-platform-tools adb versionadb 能正常输出版本号说明基础连接工具就绪。真机方面需要打开开发者选项和 USB 调试用数据线连接电脑执行adb devices确认设备状态为 “device” 而不是 “unauthorized”。如果出现 unauthorized要在手机上确认调试授权弹窗。接着创建 Python 环境并安装项目依赖git clone https://github.com/google/artemis.git cd artemis python3 -m venv .venv source .venv/bin/activate pip install -r requirements.txt4.2 第二步配置模型服务ARTEMIS 依赖一个大语言模型作为推理大脑。官方支持 Google Cloud Vertex AI 上的 Gemini 系列模型也兼容一些其他 model endpoint 配置。我实测下来的经验是模型服务本身只要有标准接口和 token 信息都可以通过配置文件接入。如果是企业内部已有模型服务这里可以直接替换 base_url。配置文件的典型结构如下重点关注模型部分llm: provider: google model: gemini-2.0-flash base_url: https://your-endpoint api_key_env: GOOGLE_API_KEY temperature: 0.1 max_tokens: 1024这里有几个参数值得展开讲temperature 我建议压在 0.2 以下。测试任务需要稳定性和可控性如果模型随机性太强同样的任务跑两次动作不一致调起 Bug 来会非常痛苦。max_tokens 要看任务类型简单操作用 1024 足够复杂任务规划可以放宽到 2048。api_key 不要直接硬编码在 YAML 文件里务必使用环境变量注入。否则一旦配置仓库被分享你的模型 key 就裸奔了。export GOOGLE_API_KEYyour-key-here4.3 第三步准备应用与任务描述ARTEMIS 的测试任务以 YAML 文件描述里面定义设备、应用包名、任务目标、执行次数等信息。一个最简任务的配置长这样devices: - serial: your-device-serial platform: android tasks: - app: com.example.testapp task: 打开应用在首页点击“登录”按钮 输入用户名为 testexample.com 密码为 123456 点击登录 验证是否进入主页 max_steps: 30 timeout_seconds: 300这里有个很重要的实践细节task 描述不要只写“登录应用”这种一句话。AI Agent 虽然强但太模糊的目标容易导致它动作发散它可能会先去翻设置、看通知栏、点其他按钮。我的建议是任务描述按照“入口—操作—预期结果”三步写清楚既要交代用户路径也要写明验证点。例如上面那个任务最后一句“验证是否进入主页”就是明确的验收标准。它在执行完毕之后会自己判断“是否进入主页”这个条件是否达成。max_steps 的作用是限制 Agent 的最大操作步数默认值一般够用但我遇到过一个任务因为页面反复弹广告Agent 一直在关弹窗最后把步数耗尽也没完成任务。遇到这种情况要么在描述里写上“若出现广告弹窗则关闭后继续”要么适当调大步数上限。timeout_seconds 是硬性超时防止网络卡住时任务无限挂起。4.4 第四步启动测试并观察 Agent 行为配置完成后启动命令即可python run_artemis.py --config config/demo.yaml执行过程中终端会实时打印 Agent 的思考过程、动作选择、执行结果。我第一次跑的时候看到屏幕里一个黑框自己在模拟器页面里跳来跳去一会儿点这里一会儿滑那里确实有种“陌生人在操作我的手机”的感觉。输出日志里你会看到类似这样的信息层级[1/20] 观察到页面登录界面包含 输入框和 登录 按钮 [2/20] 决策输入文本 用户名 [3/20] 执行成功输入 https://... [4/20] 决策点击 登录 按钮 [5/20] 观察页面跳转出现 加载中 提示这个日志体系很值得给团队推广。每一个步骤都有“观察—决策—执行—反馈”四元组即使出了 bug也能回放整个 Agent 的操作路径定位是第几步出了错。如果需要捕获崩溃ARTEMIS 会自动监听应用进程一旦发生 ANR 或 crash就把 logcat 里面的异常堆栈保存下来并记录 crash 时的屏幕截图。这一点很多传统自动化工具是做不到的——传统工具更像“调用接口执行测试”而不是“像人一样在系统层观察崩溃”。五笔实操过程中建议打开 Android Monitor 或者直接adb logcat实时观察设备日志可以显著缩短排查问题的时间。5. 真机调试中的常见坑与排查方法真机测试最不缺的就是意外这里整理我实际踩过的几个高频问题后面按“症状—原因—解法”给你一个速查表。先聊聊最常见的 adb 连接问题。症状是adb devices能看到设备但状态是 offline或者设备列表反复刷新。原因通常是 USB 数据线问题——很多第三方线只支持充电不支持数据传输。另外一些 Linux 机器缺少 USB 权限需要给 adb 设置 udev 规则。解决方法是换原装线优先插机箱背板 USB 口尤其是 USB 2.0 口稳定性往往更好然后重启 adb 服务adb kill-server adb start-server adb devices第二种高频问题是模型服务连接失败。ARTEMIS 启动后一直报 401 或者 connection timeout基本就是两个原因API key 没生效或者网络策略拦截了模型服务地址。这个需要你自己在环境层面打通。我的建议是先将模型配置放到一个单独的文件里先用 curl 做一次最小连通性测试确认通了再让 ARTEMIS 去连。第三种问题是设备权限弹窗处理不当导致 Agent 卡死在弹窗上。ARTEMIS 虽然能识别权限弹窗但有些厂商定制系统的弹窗样式不规范模型可能识别为普通页面。这时候可以在任务描述里加一句“忽略所有权限申请弹窗直接点击拒绝”或者提前用 adb 预授权adb shell pm grant com.example.testapp android.permission.CAMERA第四种比较隐蔽有些 App 有启动广告页而且倒计时结束前“跳过”按钮不可点。Agent 如果画面更新不及时可能在广告页上反复尝试无效操作。遇到这种情况的解法是在任务描述中明确写“等待广告页结束后再操作”并配合加大等待时间。ARTEMIS 本身支持在执行动作前先等待页面稳定这个参数在配置里可以调整。第五种是布局过于复杂的页面尤其是各家 App 自绘的卡片流首页控件位置动态变化。Agent 有时会点错位置。我观察到 ARTEMIS 对常规原生控件的识别准确率很高但对完全自绘的 UI 偶尔会误判。这种情况目前没有完美方案但可以通过拆分任务、缩小操作范围来降低误点击率。最后一种坑是设备冷却问题。长时间跑任务手机会发热系统会自动降频导致界面渲染变慢Agent 可能误判“页面无响应”。建议大规模执行时加散热设备或者定时让任务队列休息。5.1 常见问题速查现象可能原因处理方法设备状态 offlineUSB 数据线质量问题 / udev 规则缺失换原装线配置 udev重启 adb401 / key 错误API Key 失效或环境变量未生效检查 export 是否在相同终端窗口执行任务执行到一半挂起模型返回超时 / 网络抖动调大 timeout_seconds增加重试机制Agent 反复点击同一位置页面有动画 / 广告遮罩在描述中明示等待条件增加页面稳定等待无法捕获崩溃应用崩溃后 Agent 已退出上下文确保 logcat 权限崩溃捕获服务保持监听多设备同时连接时映射混乱设备序列号重复指定 dev serial避免通过索引选择设备6. 实际使用中给我留下印象的几个细节ARTEMIS 首次进入我的视野是因为它重新定义了“测试文档”。以前测试用例是表格、是代码、是截图拼贴现在它是自然语言描述的目标加 Agent 操作日志。这个变化对协作的影响非常直接产品经理能读懂测试描述开发能看懂操作日志测试不再需要先翻译一遍“这个用例在测什么”。它对于回归测试的颠覆性也值得一说。以前做回归是固定脚本跑固定场景现在你可以让 Agent 每天换着花样做同样的核心路径甚至故意进行一些边缘操作。本质上它把“抱着脚本跑回归”变成了“让 Agent 探索式地验证核心功能”既能保证覆盖面又能发现一些脚本时代的漏网之鱼。还有一点是它在无障碍测试上的意外价值。ARTEMIS 通过视觉理解界面那些对视觉依赖过强的页面、对比度不足的按钮、点击区域过小的控件在 Agent 的视角下也会出现识别困难——这其实反过来暴露了界面可用性的问题。如果你的产品面向大众用户ARTEMIS 在“模拟模糊状态下的用户操作”方面比脚本工具能更早发现设计缺陷。从团队落地角度ARTEMIS 的入门门槛没有想象中高。团队里只要有一个人能写 YAML、能配通模型服务其他人只需要会描述任务就能用起来。它不会替代测试工程师的判断力但能把很多重复性的验证工作从人手里接过去。7. 部署时要留意的资源消耗与性能表现说点实在的ARTEMIS 不是个轻量工具。它的每一轮操作都要经过“截图—模型推理—动作执行—再观察”的闭环而模型推理恰恰是时间和金钱的大头。我在多设备并行时测过一轮大概 20 步左右的任务单设备消耗的模型 token 量远高于普通对话任务因为每次观察都要把整张截图作为视觉输入。所以部署之前一定要想清楚预算和并发数。team 规模不大、任务量也不高的场景用 Gemini Flash 这类效率型号就够没必要一上来就堆 Pro 级别的大参数模型。性价比更高的做法是把高频回归任务做成固定任务模板只有探索性测试才用完整 Agent 模式跑。设备数量方面实测下来一个推理进程带 3 到 5 台设备是可行的再往上就要考虑请求排队和延迟任务超过 10 个并发以后响应速度会明显下降。另外我强烈建议在 CI/CD 里给 ARTEMIS 单独配一个 runner 节点别和编译任务抢资源。截图和模型推理都对 CPU/内存不太敏感但对网络和稳定性要求高放在独立环境里能减少很多莫名的超时问题。8. 想办法让 ARTEMIS 真正融入现有研发流程把所有真机测试一刀切交给 ARTEMIS 并不现实我的建议是分阶段渐进式引入。第一阶段先用它在“冒烟测试”和“核心路径回归”上做试点挑 5 到 10 个高频核心业务场景把它当作“每天自动在各品牌真机上跑一遍核心流程”的巡检机器人。这时候人工只需要看它每日生成的结果报告处理它标红的失败项。第二阶段把它引入“探索性测试”。每周挑一个版本让 Agent 以“新用户”的视角在新包上自由操作同时开启崩溃监听。这个模式下Agent 找到的崩溃信息比手工测试高效得多——你想想同一时间让 5 台真机都去操作你的 App手下的“虚拟实习生”24 小时不休息这个效率是真实团队比不了的。第三阶段再考虑与 CI/CD 深度集成。MR 触发冒烟测试时除了跑常规单元测试和构建验证额外给一台备用真机跑一遍 ARTEMIS 核心路径。这样代码改动影响核心流程时在代码评审阶段就能暴露出问题比合入主干后再发现要省钱省时间得多。我这个分法的核心逻辑是先拿它补人工的重复劳动再借它探索盲区最后才谈流程改造。直接一刀切全量替换大概率会被各种边界情况折磨到怀疑人生。9. 最后说几句没有写进读文档的狠话ARTEMIS 绝不是“装好就能全自动出测试报告”的神器。我在试用初期至少遇到三次以上因为任务描述不精确导致 Agent 在页面迷路的情况。它更像一个“很有悟性的新人测试”你得把任务的边界、期望结果说清楚它才能发挥真正的作用。我也觉得 ARTEMIS 目前更偏“验证辅助”而不是“质量守门员”。真正决定 App 质量的仍然是人你设计的测试场景是否有代表性你写的任务描述是否覆盖了关键路径你对失败结果的分析是否找到根因。AI Agent 只是把这些环节的执行成本大幅压缩了。有条件的朋友我建议直接从 GitHub 拉下代码跑一个 demo。不需要多完善的测试环境一台真机、一个模型 key、一个简单的测试应用十分钟就能感受到“AI 在我手机上自己操作”这件事的沉浸感。当你第一次看到它自己处理广告弹窗、自己滑动寻找按钮、自己判断页面是否加载完成时你心里会冒出来的那句话只有一句——“这套东西未来三年一定会成为移动端测试的主流方式。” ARTEMIS 实战：用 AI Agent 驱动真机测试，告别脚本维护时代
ARTEMIS 这个名字刚出来的时候我在测试群里看到不少人都在转第一反应是 Google 终于把“AI 自己测 Android 应用”这件事做成开源工具了。以前我们聊 AI 测试更多是停留在“用 AI 生成测试用例”“用 AI 分析日志”但 ARTEMIS 给人的感觉完全不一样——它是一个跑在真机上的 AI Agent能自己看屏幕、自己点按钮、自己输入文字遇到崩溃还能自己捞日志。这篇文章我就基于自己的理解和动手实践把 ARTEMIS 是什么、怎么工作、怎么部署、有哪些坑一次性讲清楚。1. 传统真机测试为什么让人头疼先说一个容易被忽略的事实真机测试和模拟器测试体验完全是两回事。模拟器环境干净、资源可控、方便复现但很多问题只在真机上才会出现——特定厂商的系统定制、屏幕分辨率、传感器状态、弱网场景、内存压力、推送通道甚至某些系统的“省电策略”都会让应用行为变得不一样。所以正规的移动端项目发布前一定会过一轮真机兼容性测试。可真机测试的痛点也非常明显。第一是耗时。一个人一台手机从安装、启动、登录、浏览、操作、回归场景一多就是半天。如果涉及多个机型、多个系统版本时间成本直接翻倍。第二是脚本维护成本。传统的 UI 自动化测试Espresso、Appium、UIAutomator 这类虽然能跑但脚本和控件绑定页面结构一变脚本就死维护成本常常高过写脚本的成本。第三是覆盖有限。脚本是人写的人想到什么才测什么很难穷尽真实用户的路径更别提临时起意的探索性测试了。还有一个隐藏问题很多现成的自动化工具依赖 root 或者特定测试框架在用户日常使用的系统环境里跑不起来导致“测试环境过了用户手机崩了”的事情反复出现。ARTEMIS 切入的其实是这个场景——用大模型驱动一个 AI Agent 在真实设备上“像人一样操作”你只需要用自然语言告诉它要做什么剩下的点击、滑动、输入、等待、观察它自己完成。听起来有点科幻但实际操作下来它确实把“自然语言驱动真机测试”从概念变成了可运行的工程方案。2. ARTEMIS 核心思路拆解Agent 是怎么“接管”手机的要理解 ARTEMIS 的原理先搞清楚一个最根本的问题它凭什么知道该怎么操作手机答案是大模型对屏幕的“视觉理解”能力。ARTEMIS 的核心机制并不复杂——它把手机屏幕截图喂给视觉语言模型VLM模型通过截图识别出当前界面的布局、控件、文字然后基于你给出的任务目标决定下一步要执行什么动作。这个“看屏幕—想动作—做动作—再看屏幕”的循环就是 Agent 的基本运行方式。打个比方以前我们用脚本测试等于给一个不认识路的司机写死每一步怎么走。ARTEMIS 则是给司机一个目的地和一套交通规则它自己看路牌、避让行人、转弯掉头。这里有个关键点ARTEMIS 不需要 XML 控件树、不需要 id、不需要 xpath它直接“看”像素所以对界面结构的依赖性极低。哪怕页面元素乱飘、动画频繁、控件层级复杂它都能靠着画面信息做出下一步判断。动作层的设计也很有讲究。ARTEMIS 不是只能“点一下”或者“划一下”它抽象出了一个相对完整的动作空间包括点击、长按、滑动、输入文字、返回、按键等基本操作。这个动作空间本质上就是 Agent 能使用的“工具”模型从工具列表里挑选合适的工具再配合坐标参数执行。这样做的好处是既能覆盖绝大多数测试场景又不会因为动作太自由而失控。我特别注意到它对于抽屉、弹窗、权限提示这类内容的处理。这些元素在传统自动化里是“杀手”权限弹窗一出现脚本就不知道该怎么办而 ARTEMIS 可以识别弹窗内容并主动选择“拒绝”或者“允许”配合系统返回键绕过阻塞效果比固定脚本强很多。在任务推进方式上ARTEMIS 也做了分层。它先接受一个高层的用户指令比如“测试注册流程并验证是否能成功创建账号”然后模型自己拆解成“打开应用—进入注册页—输入邮箱—设置密码—点击注册—检查跳转—验证是否登录成功”一系列子任务再逐条执行。这种从总目标到子动作的任务分解能力恰恰是传统自动化框架最欠缺的部分。3. 为什么说 ARTEMIS 和普通“AI 测试工具”不一样市面上其实已经有一些号称 AI 测试的产品但看下来大多停留在“用 AI 帮你生成测试脚本”的阶段——你给它录一段操作它生成代码或者你用语言描述场景它翻译成脚本。这类工具的价值在于节省脚本编写时间本质上还是脚本驱动。ARTEMIS 路径完全不同Agent 本身在执行测试任务不做代码翻译。它像一个“虚拟测试员”你说“帮我在设置里关闭自动更新”它会自己去设置页、找到开关、滑动关闭再返回。这种差异带来两个直接变化一是测试过程不受脚本“死步骤”的限制。脚本是线性执行的每一步结果固定一步错也许下面全错而 Agent 每一步都根据实时屏幕内容做动态决策页面多了半个广告、弹了个红包、系统改了交互样式它都能即时调整。二是测试失败后的可解释性大大提升。传统脚本失败只会告诉你“元素没找到”你得猜是页面崩了还是控件变了。ARTEMIS 的执行过程本身就是多轮视觉文字的记录它能告诉你“我看到了什么、我做了什么、结果如何、最终是否完成目标”。这对定位 bug 非常有价值。还有一点是并行扩展性。真机测试往往需要“多机同测”传统脚本你要为每台设备单独维护配置ARTEMIS 的 Agent 机制天然适合配对多台真机每个设备一个 Agent 实例共用一套模型服务任务可以分布式下发。这意味着“一组推理模型管一排手机”的集中式测试架构是可行的。不过也要说句公道话ARTEMIS 并非万能它更适合“任务导向的验证”和“探索性回归”你让它做像素级断言或者复杂到需要领域知识的业务校验短期内还是需要人来兜底。4. 动手实操从 0 到 1 跑起 ARTEMIS接下来是大家最关心的部分怎么把它跑起来。我以 Linux 环境为例Mac 和 Windows 的差异点在过程中会单独说明。4.1 第一步准备基础环境ARTEMIS 的底层依赖几个基础组件Python 3.9 及以上、Android SDK重点是 platform-tools 里的 adb、JDK部分依赖 gradle 构建时需要、一个可用的模型推理接口。首先把 SDK 和平台工具装好。# 下载并解压 Android SDK command-line tools mkdir -p ~/android-sdk/cmdline-tools cd ~/android-sdk/cmdline-tools # 将下载的 tools 压缩包解压并重命名目录为 latest export ANDROID_HOME~/android-sdk export PATH$PATH:$ANDROID_HOME/platform-tools # 或者直接使用 apt 安装不适合生产环境但快速验证够用 sudo apt install android-sdk-platform-tools adb versionadb 能正常输出版本号说明基础连接工具就绪。真机方面需要打开开发者选项和 USB 调试用数据线连接电脑执行adb devices确认设备状态为 “device” 而不是 “unauthorized”。如果出现 unauthorized要在手机上确认调试授权弹窗。接着创建 Python 环境并安装项目依赖git clone https://github.com/google/artemis.git cd artemis python3 -m venv .venv source .venv/bin/activate pip install -r requirements.txt4.2 第二步配置模型服务ARTEMIS 依赖一个大语言模型作为推理大脑。官方支持 Google Cloud Vertex AI 上的 Gemini 系列模型也兼容一些其他 model endpoint 配置。我实测下来的经验是模型服务本身只要有标准接口和 token 信息都可以通过配置文件接入。如果是企业内部已有模型服务这里可以直接替换 base_url。配置文件的典型结构如下重点关注模型部分llm: provider: google model: gemini-2.0-flash base_url: https://your-endpoint api_key_env: GOOGLE_API_KEY temperature: 0.1 max_tokens: 1024这里有几个参数值得展开讲temperature 我建议压在 0.2 以下。测试任务需要稳定性和可控性如果模型随机性太强同样的任务跑两次动作不一致调起 Bug 来会非常痛苦。max_tokens 要看任务类型简单操作用 1024 足够复杂任务规划可以放宽到 2048。api_key 不要直接硬编码在 YAML 文件里务必使用环境变量注入。否则一旦配置仓库被分享你的模型 key 就裸奔了。export GOOGLE_API_KEYyour-key-here4.3 第三步准备应用与任务描述ARTEMIS 的测试任务以 YAML 文件描述里面定义设备、应用包名、任务目标、执行次数等信息。一个最简任务的配置长这样devices: - serial: your-device-serial platform: android tasks: - app: com.example.testapp task: 打开应用在首页点击“登录”按钮 输入用户名为 testexample.com 密码为 123456 点击登录 验证是否进入主页 max_steps: 30 timeout_seconds: 300这里有个很重要的实践细节task 描述不要只写“登录应用”这种一句话。AI Agent 虽然强但太模糊的目标容易导致它动作发散它可能会先去翻设置、看通知栏、点其他按钮。我的建议是任务描述按照“入口—操作—预期结果”三步写清楚既要交代用户路径也要写明验证点。例如上面那个任务最后一句“验证是否进入主页”就是明确的验收标准。它在执行完毕之后会自己判断“是否进入主页”这个条件是否达成。max_steps 的作用是限制 Agent 的最大操作步数默认值一般够用但我遇到过一个任务因为页面反复弹广告Agent 一直在关弹窗最后把步数耗尽也没完成任务。遇到这种情况要么在描述里写上“若出现广告弹窗则关闭后继续”要么适当调大步数上限。timeout_seconds 是硬性超时防止网络卡住时任务无限挂起。4.4 第四步启动测试并观察 Agent 行为配置完成后启动命令即可python run_artemis.py --config config/demo.yaml执行过程中终端会实时打印 Agent 的思考过程、动作选择、执行结果。我第一次跑的时候看到屏幕里一个黑框自己在模拟器页面里跳来跳去一会儿点这里一会儿滑那里确实有种“陌生人在操作我的手机”的感觉。输出日志里你会看到类似这样的信息层级[1/20] 观察到页面登录界面包含 输入框和 登录 按钮 [2/20] 决策输入文本 用户名 [3/20] 执行成功输入 https://... [4/20] 决策点击 登录 按钮 [5/20] 观察页面跳转出现 加载中 提示这个日志体系很值得给团队推广。每一个步骤都有“观察—决策—执行—反馈”四元组即使出了 bug也能回放整个 Agent 的操作路径定位是第几步出了错。如果需要捕获崩溃ARTEMIS 会自动监听应用进程一旦发生 ANR 或 crash就把 logcat 里面的异常堆栈保存下来并记录 crash 时的屏幕截图。这一点很多传统自动化工具是做不到的——传统工具更像“调用接口执行测试”而不是“像人一样在系统层观察崩溃”。五笔实操过程中建议打开 Android Monitor 或者直接adb logcat实时观察设备日志可以显著缩短排查问题的时间。5. 真机调试中的常见坑与排查方法真机测试最不缺的就是意外这里整理我实际踩过的几个高频问题后面按“症状—原因—解法”给你一个速查表。先聊聊最常见的 adb 连接问题。症状是adb devices能看到设备但状态是 offline或者设备列表反复刷新。原因通常是 USB 数据线问题——很多第三方线只支持充电不支持数据传输。另外一些 Linux 机器缺少 USB 权限需要给 adb 设置 udev 规则。解决方法是换原装线优先插机箱背板 USB 口尤其是 USB 2.0 口稳定性往往更好然后重启 adb 服务adb kill-server adb start-server adb devices第二种高频问题是模型服务连接失败。ARTEMIS 启动后一直报 401 或者 connection timeout基本就是两个原因API key 没生效或者网络策略拦截了模型服务地址。这个需要你自己在环境层面打通。我的建议是先将模型配置放到一个单独的文件里先用 curl 做一次最小连通性测试确认通了再让 ARTEMIS 去连。第三种问题是设备权限弹窗处理不当导致 Agent 卡死在弹窗上。ARTEMIS 虽然能识别权限弹窗但有些厂商定制系统的弹窗样式不规范模型可能识别为普通页面。这时候可以在任务描述里加一句“忽略所有权限申请弹窗直接点击拒绝”或者提前用 adb 预授权adb shell pm grant com.example.testapp android.permission.CAMERA第四种比较隐蔽有些 App 有启动广告页而且倒计时结束前“跳过”按钮不可点。Agent 如果画面更新不及时可能在广告页上反复尝试无效操作。遇到这种情况的解法是在任务描述中明确写“等待广告页结束后再操作”并配合加大等待时间。ARTEMIS 本身支持在执行动作前先等待页面稳定这个参数在配置里可以调整。第五种是布局过于复杂的页面尤其是各家 App 自绘的卡片流首页控件位置动态变化。Agent 有时会点错位置。我观察到 ARTEMIS 对常规原生控件的识别准确率很高但对完全自绘的 UI 偶尔会误判。这种情况目前没有完美方案但可以通过拆分任务、缩小操作范围来降低误点击率。最后一种坑是设备冷却问题。长时间跑任务手机会发热系统会自动降频导致界面渲染变慢Agent 可能误判“页面无响应”。建议大规模执行时加散热设备或者定时让任务队列休息。5.1 常见问题速查现象可能原因处理方法设备状态 offlineUSB 数据线质量问题 / udev 规则缺失换原装线配置 udev重启 adb401 / key 错误API Key 失效或环境变量未生效检查 export 是否在相同终端窗口执行任务执行到一半挂起模型返回超时 / 网络抖动调大 timeout_seconds增加重试机制Agent 反复点击同一位置页面有动画 / 广告遮罩在描述中明示等待条件增加页面稳定等待无法捕获崩溃应用崩溃后 Agent 已退出上下文确保 logcat 权限崩溃捕获服务保持监听多设备同时连接时映射混乱设备序列号重复指定 dev serial避免通过索引选择设备6. 实际使用中给我留下印象的几个细节ARTEMIS 首次进入我的视野是因为它重新定义了“测试文档”。以前测试用例是表格、是代码、是截图拼贴现在它是自然语言描述的目标加 Agent 操作日志。这个变化对协作的影响非常直接产品经理能读懂测试描述开发能看懂操作日志测试不再需要先翻译一遍“这个用例在测什么”。它对于回归测试的颠覆性也值得一说。以前做回归是固定脚本跑固定场景现在你可以让 Agent 每天换着花样做同样的核心路径甚至故意进行一些边缘操作。本质上它把“抱着脚本跑回归”变成了“让 Agent 探索式地验证核心功能”既能保证覆盖面又能发现一些脚本时代的漏网之鱼。还有一点是它在无障碍测试上的意外价值。ARTEMIS 通过视觉理解界面那些对视觉依赖过强的页面、对比度不足的按钮、点击区域过小的控件在 Agent 的视角下也会出现识别困难——这其实反过来暴露了界面可用性的问题。如果你的产品面向大众用户ARTEMIS 在“模拟模糊状态下的用户操作”方面比脚本工具能更早发现设计缺陷。从团队落地角度ARTEMIS 的入门门槛没有想象中高。团队里只要有一个人能写 YAML、能配通模型服务其他人只需要会描述任务就能用起来。它不会替代测试工程师的判断力但能把很多重复性的验证工作从人手里接过去。7. 部署时要留意的资源消耗与性能表现说点实在的ARTEMIS 不是个轻量工具。它的每一轮操作都要经过“截图—模型推理—动作执行—再观察”的闭环而模型推理恰恰是时间和金钱的大头。我在多设备并行时测过一轮大概 20 步左右的任务单设备消耗的模型 token 量远高于普通对话任务因为每次观察都要把整张截图作为视觉输入。所以部署之前一定要想清楚预算和并发数。team 规模不大、任务量也不高的场景用 Gemini Flash 这类效率型号就够没必要一上来就堆 Pro 级别的大参数模型。性价比更高的做法是把高频回归任务做成固定任务模板只有探索性测试才用完整 Agent 模式跑。设备数量方面实测下来一个推理进程带 3 到 5 台设备是可行的再往上就要考虑请求排队和延迟任务超过 10 个并发以后响应速度会明显下降。另外我强烈建议在 CI/CD 里给 ARTEMIS 单独配一个 runner 节点别和编译任务抢资源。截图和模型推理都对 CPU/内存不太敏感但对网络和稳定性要求高放在独立环境里能减少很多莫名的超时问题。8. 想办法让 ARTEMIS 真正融入现有研发流程把所有真机测试一刀切交给 ARTEMIS 并不现实我的建议是分阶段渐进式引入。第一阶段先用它在“冒烟测试”和“核心路径回归”上做试点挑 5 到 10 个高频核心业务场景把它当作“每天自动在各品牌真机上跑一遍核心流程”的巡检机器人。这时候人工只需要看它每日生成的结果报告处理它标红的失败项。第二阶段把它引入“探索性测试”。每周挑一个版本让 Agent 以“新用户”的视角在新包上自由操作同时开启崩溃监听。这个模式下Agent 找到的崩溃信息比手工测试高效得多——你想想同一时间让 5 台真机都去操作你的 App手下的“虚拟实习生”24 小时不休息这个效率是真实团队比不了的。第三阶段再考虑与 CI/CD 深度集成。MR 触发冒烟测试时除了跑常规单元测试和构建验证额外给一台备用真机跑一遍 ARTEMIS 核心路径。这样代码改动影响核心流程时在代码评审阶段就能暴露出问题比合入主干后再发现要省钱省时间得多。我这个分法的核心逻辑是先拿它补人工的重复劳动再借它探索盲区最后才谈流程改造。直接一刀切全量替换大概率会被各种边界情况折磨到怀疑人生。9. 最后说几句没有写进读文档的狠话ARTEMIS 绝不是“装好就能全自动出测试报告”的神器。我在试用初期至少遇到三次以上因为任务描述不精确导致 Agent 在页面迷路的情况。它更像一个“很有悟性的新人测试”你得把任务的边界、期望结果说清楚它才能发挥真正的作用。我也觉得 ARTEMIS 目前更偏“验证辅助”而不是“质量守门员”。真正决定 App 质量的仍然是人你设计的测试场景是否有代表性你写的任务描述是否覆盖了关键路径你对失败结果的分析是否找到根因。AI Agent 只是把这些环节的执行成本大幅压缩了。有条件的朋友我建议直接从 GitHub 拉下代码跑一个 demo。不需要多完善的测试环境一台真机、一个模型 key、一个简单的测试应用十分钟就能感受到“AI 在我手机上自己操作”这件事的沉浸感。当你第一次看到它自己处理广告弹窗、自己滑动寻找按钮、自己判断页面是否加载完成时你心里会冒出来的那句话只有一句——“这套东西未来三年一定会成为移动端测试的主流方式。”