Google 开源 ARTEMIS：AI Agent 如何接管 Android 真机测试？

关注 霍格沃兹软件测试开发 公众号，回复「资料」, 领取人工智能测试开发技术合集

摘要：

Google 最近开源了一个很值得测试开发关注的项目——ARTEMIS。

它不是帮你简单生成几段 Appium 脚本，而是让 AI Agent 直接操作 Android 真机或模拟器：理解自然语言测试任务、识别页面、点击控件、跨 App 执行业务流程，还能自动获取截图、Logcat、执行轨迹，并生成测试结果。

更值得关注的是，ARTEMIS 原生支持 MCP，可以直接接入 Antigravity、Codex、Claude Code、Cursor、Windsurf 等 AI 编程环境。

这意味着移动端测试正在从：

人写脚本 → 脚本操作手机

逐渐走向：

人描述测试目标 → Agent 自己规划 → 操作真机 → 分析结果。

一、先看效果：AI 已经可以自己操作 Android 真机
ARTEMIS 官方演示了一个很典型的跨 App 场景。

AI 先在 Google Maps 中规划驾车路线、计算行程时间，然后再自动打开 YouTube，搜索并播放指定歌曲。

整个过程不是提前写死一套 XPath 或坐标脚本，而是 Agent 根据当前手机界面不断判断下一步应该做什么。

这其实已经和传统自动化测试有明显区别。

传统自动化更像：

测试人员
↓
编写脚本
↓
定位元素
↓
执行操作
↓
断言结果
而 ARTEMIS 更像：

测试人员给出目标
↓
AI 理解任务
↓
观察手机页面
↓
决定下一步操作
↓
执行
↓
检查结果
↓
继续执行 / 调整策略
换句话说，测试执行本身开始具备一定的自主决策能力。

二、ARTEMIS 到底是什么？
简单理解：

ARTEMIS 是一套面向 Android 真机自动化的 AI Agent 框架。

你可以直接给它自然语言任务，例如：

打开系统设置，
进入电池页面，
确认当前电量是否正常显示，
同时检查页面有没有异常弹窗。
然后 ARTEMIS 自己完成页面观察、元素定位、点击、滚动、输入以及结果检查。

官方目前重点强调了几个能力：

自然语言驱动 Android 自动化
跨 App 长流程任务
Accessibility + OCR + 视觉模型组合定位
真机截图和 Logcat 采集
Flash / Pro 两种执行模式
MCP 接入 AI IDE
Bug 自动复现
长时间探索性测试
Python SDK 和 CI/CD 集成
也就是说，它并不是单纯的“手机 Computer Use”。

它已经明显在往：

AI 驱动的移动端测试执行引擎

这个方向发展。

人工智能技术学习交流群
伙伴们，对AI测试、大模型评测、质量保障感兴趣吗？我们建了一个 「人工智能测试开发交流群」，专门用来探讨相关技术、分享资料、互通有无。无论你是正在实践还是好奇探索，都欢迎扫码加入，一起抱团成长！期待与你交流！👇

三、真正值得看的，是 Antigravity × ARTEMIS 工作流
如果只是让 AI 自动点击手机，其实并不是最有意思的地方。

ARTEMIS 官方专门展示了一套：

Antigravity × ARTEMIS 自主测试工作流
Antigravity 通过 MCP 调用 ARTEMIS，可以把一句自然语言测试需求，最终转化为：

测试需求
↓
测试计划
↓
真机执行
↓
数据采集
↓
问题诊断
↓
测试报告
完整闭环。

第一步：输入测试需求
首先，测试人员直接在 Antigravity 中描述测试场景以及关注的指标。

不需要先写自动化代码，而是先描述：

我要测什么。

ARTEMIS Task Dispatch
比如你可以告诉 Agent：

测试这个 App 的启动性能。

完成冷启动、登录、首页加载，
记录关键页面加载时间，
同时观察 CPU、内存和异常日志，
最后输出一份测试报告。
这一步实际上对应的是：

Task Dispatch。

也就是任务下发。

第二步：自动生成测试计划
接下来 Antigravity 不会立即开始乱点。

它会先理解目标，然后把任务拆解成测试步骤和执行计划。

ARTEMIS Test Plan

例如：

启动 App

↓

等待首页加载

↓

执行登录

↓

进入目标业务页面

↓

记录性能数据

↓

检查异常日志

↓

整理最终结果
这个变化其实非常重要。

因为传统 UI 自动化里面：

测试流程是人提前写进代码里的。

而 Agent 测试里面：

流程可以在运行前由 Agent 根据目标动态生成。

第三步：自主操作真机完成测试
测试计划确定后，ARTEMIS 开始真正操作 Android 设备。

ARTEMIS Autonomous Test Execution

Agent 会：

观察当前页面；

识别目标控件；

点击、输入、滑动；

判断页面有没有变化；

遇到异常重新选择操作策略；

同时采集执行信息。

如果是性能测试场景，还可以结合设备数据进行分析。

所以这一阶段对应的是：

Autonomous Test Execution。

这也是 ARTEMIS 和“AI 生成自动化脚本”最大的区别之一。

它不是：

AI → 写代码 → 人运行
而是：

AI
↓
直接驱动测试设备
↓
执行测试
第四步：生成诊断报告
测试完成以后，Agent 并不是只告诉你：

测试结束。

而是可以继续整理执行过程中的：

测试步骤
执行结果
指标数据
截图
Logcat
异常信息
原始数据
最终输出结构化测试报告。

ARTEMIS Final Report

这意味着：

测试计划、测试执行、证据采集和测试报告开始被串进同一个 Agent 工作流里。

而不是每一个环节分别使用一套工具。

四、MCP 为什么是这里面很关键的一环？
ARTEMIS 原生提供 MCP Server。

它可以直接接入：

Antigravity
Codex
Claude Code / Claude Desktop
Cursor
Windsurf
VS Code
Cline / Roo
OpenClaw
等 AI 开发环境。

这件事情对测试开发影响其实很大。

因为过去我们的研发测试流程一般是：

研发修改代码
↓
编译
↓
测试人员执行
↓
发现 Bug
↓
截图
↓
导出日志
↓
提交 Bug
↓
研发重新定位
接入 MCP 以后，有可能逐渐变成：

Coding Agent 修改代码
↓
构建 APK
↓
安装到 Android 真机
↓
ARTEMIS 执行测试
↓
复现业务流程
↓
获取截图 + Logcat
↓
Agent 分析问题
↓
修改代码
↓
再次验证
于是：

Coding Agent 和 Testing Agent 真正开始连起来了。

这才是我觉得 ARTEMIS 最值得测试开发关注的地方。

五、传统 XPath 不稳定，它是怎么解决的？
做过移动端自动化的人应该都有体验。

真正让人头疼的，经常不是写第一版自动化脚本。

而是维护。

页面改版以后：

XPath 变了。

Resource ID 变了。

控件层级调整了。

分辨率变了。

脚本就可能开始大量报错。

ARTEMIS 的做法并不是彻底抛弃传统 UI 信息，而是组合使用：

Accessibility
+
OCR
+
视觉模型
普通 Android 控件优先使用结构化信息定位。

如果遇到 Flutter、Compose、Canvas 等自绘 UI，则可以继续借助视觉模型进行定位。

所以它的设计思路其实比较工程化：

可以确定性定位
↓
优先使用元素信息

定位不到
↓
再使用视觉理解

仍然存在特殊情况
↓
坐标等方式兜底
而不是所有页面都截图扔给大模型。

这对速度、Token 成本和稳定性都会更友好。

六、ARTEMIS 还有两种执行模式
ARTEMIS 设计了两套不同的执行模式：

Flash 和 Pro。

它们解决的其实是两类完全不同的测试任务。

Flash：适合高频快速执行
Flash 是比较轻量的：

Observe
↓
Think
↓
Act
循环。

模型观察当前页面，决定下一步，然后马上执行。

官方给出的典型执行速度约为：

3～5 秒一步。

比较适合：

快速 UI 验证
固定流程
高频回归
简单操作任务
Flash 默认不限制执行步数，而是通过历史压缩控制上下文规模。

Pro：适合复杂测试任务
Pro 则更像真正的 Testing Agent。

内部会出现：

Planner
↓
Operator
↓
Checker
Planner 负责维护测试计划；

Operator 负责具体操作；

Checker 负责检查关键节点和最终结果。

并且每个重要操作之前还会经过 Safety Net。

如果某一步操作失败，Operator 可以根据当前页面继续恢复，而不是整条测试直接失败。

官方给出的典型单步耗时大约为：

15～40 秒。

它更适合：

复杂业务流程
探索性测试
长时间稳定性测试
Bug 复现
ADB / 视频 / 日志诊断
需要严格断言的测试场景
甚至支持 100+ 步的长流程任务。

七、怎么安装 ARTEMIS？
官方已经把安装过程做得比较简单。

首先准备：

一台开启 USB 调试的 Android 真机，或者 Android 模拟器。

启动脚本会自动检查和安装包括：

ADB
scrcpy
FFmpeg
Python uv
Python 项目依赖
等环境，同时还会询问你是否安装 MCP 和 ARTEMIS 的测试 Rules。

macOS / Linux
git clone https://github.com/google/artemis.git

cd artemis

./start.sh
Windows PowerShell
git clone https://github.com/google/artemis.git

cd artemis

.\start.bat
Windows 用户这里注意一下。

PowerShell 默认不会直接从当前目录寻找可执行脚本，所以要写：

.\start.bat
而不是：

start.bat
如果使用的是 CMD，则可以直接运行：

start.bat
官方启动脚本目前也会调用 PowerShell bootstrap 完成后续初始化。

八、第一次启动，还需要配置模型
第一次启动时，程序会自动初始化：

.env
配置文件。

至少需要配置一个 LLM Provider。

目前 .env.example 中已经预留了：

GEMINI_API_KEY=

GOOGLE_API_KEY=

OPENAI_API_KEY=

ANTHROPIC_API_KEY=

OPEN_ROUTER_API_KEY=

XAI_API_KEY=
也就是说，你不一定只能使用 Gemini。

选择自己已有的模型 API Key 即可。

Google Cloud Vision OCR 则是可选配置。

九、启动以后还有一个 Web 控制台
启动成功以后，ARTEMIS 默认会打开：

http://localhost:8000
Web 控制台。

里面可以看到：

Android 设备连接
手机实时投屏
自然语言测试任务
Agent 实时执行过程
Flash / Pro 模式
历史任务
执行轨迹
截图
Replay 回放
也就是说，即使暂时不接 Antigravity 或 Codex，也可以先通过 Web UI 直接体验。

还可以直接通过 CLI 测一下：

uv run artemis run
"Open Settings, find Battery and tell me current level"
--profile flash
中文任务同样可以尝试，例如：

uv run artemis run
"打开系统设置，进入电池页面，告诉我当前电量"
--profile flash
十、怎么接入 Antigravity、Codex 或 Claude Code？
这一步其实更简单。

如果只安装 Antigravity：

uv run artemis mcp --install antigravity
如果希望把支持的 AI IDE 全部配置好：

uv run artemis mcp --install all
安装器不仅会配置 MCP Server，还会同步 ARTEMIS 提供的：

rules.md
测试行为规范。

这份 Rules 很值得注意。

它不是单纯告诉 AI：

你可以调用 ARTEMIS。

而是在约束 Agent 怎么进行移动端测试，包括：

先探索真实 App，再写自动化代码
不允许凭空猜测 UI 状态
什么情况使用 Flash
什么情况使用 Pro
如何处理模型延迟
优先动态元素定位
坐标作为兜底
环境异常优先执行诊断
也就是说：

MCP 提供工具能力，Rules 提供测试方法。

这两个结合起来以后，AI IDE 才更像一个真正的移动端测试 Agent。

十一、然后你就可以直接在 IDE 里让 AI 测 App
官方给了一个非常有代表性的 Prompt：

Build the latest changes into an APK,
install it on the connected device,
open the login screen with a test account,
verify if there are any unexpected popups after login,
and return screenshots of the final page.
翻成中文大概就是：

把刚刚修改的代码编译成 APK，

安装到连接的 Android 手机，

打开登录页面，

使用测试账号登录，

检查登录以后有没有异常弹窗，

最后把页面截图返回给我。
你会发现，这已经不是传统意义上的：

生成一个 Appium 测试脚本
而是直接告诉 AI：

把刚才写好的 App，自己测一遍。

这就是两种模式最核心的区别。

十二、那 Appium 会不会被 ARTEMIS 替代？
我觉得暂时没必要这么理解。

对于大量：

固定回归用例
确定性流程
高频 CI
强断言
大规模重复运行
传统 Appium、UIAutomator 依然有明显优势。

因为代码执行仍然更加：

快、确定、可控。

Agent 更适合补充传统自动化成本比较高的地方，例如：

探索性测试

复杂长流程

页面变化频繁

跨 App 操作

Bug 自动复现

异常诊断

临时验证任务
所以未来比较现实的测试架构，很可能不是：

Agent
替代
Appium
而是：

Testing Agent
↓
┌───────────┼───────────┐
↓ ↓ ↓
Appium UIAutomator MCP
↓ ↓ ↓
确定执行 系统能力 外部工具
↓
Vision / OCR
↓
Android Device
AI 做理解、规划和决策。

传统自动化工具继续负责稳定执行。

两者最终组合起来。

十三、99%+ AndroidWorld 成绩应该怎么看？
ARTEMIS 官方 README 还公布了一个非常亮眼的数据：

AndroidWorld Benchmark 任务完成率超过 99%。

AndroidWorld 是 Google Research 发布的 Android Agent Benchmark，主要用于测试 Agent 在 Android 环境中执行复杂多步骤任务的能力。

不过这里需要注意：

这个 99%+ 是 ARTEMIS 项目 README 中公布的 benchmark 成绩。

它并不意味着：

企业里的任意 App 都有 99% 的自动化成功率。

真实业务里面还会存在：

验证码
登录态
网络波动
动态页面
风控策略
权限弹窗
第三方 SDK
自绘 UI
异步请求
复杂业务状态
Benchmark 能证明的是 Agent 的能力上限正在快速提升。

但真正进入企业环境，仍然需要测试工程、数据治理和稳定性机制。

十四、测试开发真正应该关注什么？
过去两年，我们谈 AI 测试时，最常见的其实是：

AI 生成测试用例

AI 生成接口脚本

AI 生成 UI 自动化代码

AI 分析测试报告
这些事情的共同特点是：

AI 主要负责生成内容。

但 ARTEMIS 这种项目开始进入另外一个阶段：

AI 理解测试任务

↓

AI 生成测试计划

↓

AI 操作真实设备

↓

AI 观察执行状态

↓

AI 判断测试结果

↓

AI 获取日志和截图

↓

AI 输出测试报告
也就是说：

AI 开始真正参与测试执行。

这时候需要掌握的东西，也就不只是 Prompt Engineering 了。

测试开发以后越来越需要理解：

Agent
MCP
Tool Calling
Computer Use
Android 自动化
Accessibility
OCR
VLM
Context Engineering
测试规划
Agent 评测
可观测性
异常恢复
CI/CD 集成
因为真正有价值的 AI 测试，并不是：

让大模型帮我们多写几段测试代码。

而是：

怎么把模型真正接进软件研发和质量保障流程。

从：

AI 帮测试人员写测试

逐渐走向：

AI Agent 参与完成测试。

ARTEMIS，就是目前非常值得测试开发工程师研究的一个案例。

推荐学习
智能化测试-测试用例生成公益训练营，从行业大模型特性讲起，带你搞懂AI测试的全链路：大模型能力评测、智能体Harness工程、Skill技能体系、CLI与MCP工具体系、RAG知识图谱——最后直接上手打造一个能自动生成测试用例的智能体。

项目地址：

https://github.com/google/artemis

关于我们
霍格沃兹测试开发学社，隶属于 测吧（北京）科技有限公司，是一个面向软件测试爱好者的技术交流社区。

学社围绕现代软件测试工程体系展开，内容涵盖软件测试入门、自动化测试、性能测试、接口测试、测试开发、全栈测试，以及人工智能测试与 AI 在测试工程中的应用实践。

我们关注测试工程能力的系统化建设，包括 Python 自动化测试、Java 自动化测试、Web 与 App 自动化、持续集成与质量体系建设，同时探索 AI 驱动的测试设计、用例生成、自动化执行与质量分析方法，沉淀可复用、可落地的测试开发工程经验。

在技术社区与工程实践之外，学社还参与测试工程人才培养体系建设，面向高校提供测试实训平台与实践支持，组织开展 “火焰杯” 软件测试相关技术赛事，并探索以能力为导向的人才培养模式，包括高校学员先学习、就业后付款的实践路径。

同时，学社结合真实行业需求，为在职测试工程师与高潜学员提供名企大厂 1v1 私教服务，用于个性化能力提升与工程实践指导。