做过 App 自动测试的朋友，Appium 这套流程应该都不陌生。

装环境，配驱动，起 Server，写 capability。uiautomatorviewer 抓元素，xpath 一层套一层，等待策略全靠拍脑袋。跑十条挂三条，改完再挂两条，脚本比业务代码还难维护。这一套流程，很多人从入行用到今天。

8 月 13 号，谷歌在 GitHub 上开源了一个项目，ARTEMIS。

这个项目的作用，用自然语言指挥 AI，去操作一台真实的安卓手机。你跟它讲「打开系统设置，找到电池选项，告诉我当前电量」，它会自己去看屏幕，自己找入口，自己点进去，把结果带回来告诉你。

ARTEMIS，谷歌的安卓自动化神器

这个项目开源，大家记住几个关键信息就可以了。

• 谷歌官方开源，Apache-2.0 协议，Python 实现

• 8 月 13 号放出，一个半月 star 破万
  

• 谷歌研究院 AndroidWorld 基准 99%+ 任务完成率，官方榜单第一

• 提供原生 MCP Server，可直接对接 Antigravity、Claude Code、Codex、Windsurf

• 主流多模态模型都能接，比如 Gemini、Claude、GPT、Qwen-VL

需要注意的是，它和 Appium 其实不是同一类定位。

• Appium 是自动化框架，你写脚本，它负责执行。
• ARTEMIS 是一个 agent 系统，你给目标，它自己看屏幕、理解界面、规划动作、执行操作、输出报告，全程不需要你写一行定位代码。

官方的演示 GIF 挺直观，一句指令，它自己打开 Google Maps 设置驾车路线算好全程耗时，再切到 YouTube 放了一首 Coldplay。两个 App，一句话，中间不用人管。

跨 App，是它和传统自动化工具的分界线

传统 UI 自动化由页面和元素组成。就拿开头那个查电量的任务，放到 Appium 框架中，写出来大概是这样。

from appium import webdriver
from appium.options.android import UiAutomator2Options
from appium.webdriver.common.appiumby import AppiumBy
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

# 第一步，描述设备和被测应用
caps = UiAutomator2Options()
caps.platform_name = "Android"
caps.device_name = "test-phone"
caps.app_package = "com.android.settings"
caps.app_activity = ".Settings"

driver = webdriver.Remote("http://127.0.0.1:4723", options=caps)
wait = WebDriverWait(driver, 15)

# 第二步，进到页面，用定位器把元素抠出来
battery = wait.until(EC.presence_of_element_located(
    (AppiumBy.XPATH, "//androidx.recyclerview.widget.RecyclerView/"
                     "android.widget.LinearLayout[2]/android.widget.RelativeLayout")
))

# 第三步，操作元素，取值断言
battery.click()
level = driver.find_element(AppiumBy.ID, "android:id/summary").text
assert "%" in level

driver.quit()

capability、定位器、等待、点击、断言，整段脚本从头到尾围着界面结构展开。

而ARTEMIS 则是由任务驱动。你说要干嘛，它自己决定去哪个页面、点什么、滚哪里。设置、地图、YouTube，一个任务横跨几个 App，它眼里没有 App 的边界，只有目标。

落到测试上，原来最费工的那部分活，场景编排，被绕过去了。你不用再写先启动 Activity、再等待、再点击这种流程了，把测试场景目标直接描述给它就行。

自绘控件，这次有兜底了

还有个对测试人很关键的细节。ARTEMIS 定位元素，优先走无障碍层级拿元素索引，拿不到，退到坐标和视觉模型识别。

做过移动端自动化的都懂这意味着什么。Canvas、Compose、Flutter 这类自绘界面，控件树里根本没有节点，uiautomatorviewer 抓出来一片空白，多少 UI 脚本就死在这类页面上。ARTEMIS 用 OCR 加视觉模型兜底，自绘界面不再是禁区。

先看成绩单

AndroidWorld 是谷歌研究院的安卓 agent 基准，覆盖 20 多个 App、100 多条多步任务，专门考 agent 在真机上完成真实任务的能力。ARTEMIS 在上面拿到 99%+ 的完成率。

官方对比图里，同样是 agent 方案，别家大多卡在五到七成，它一只手够到了天花板。

不过做测试的看到跑分都该冷静。榜单说明它看得准、点得稳，具体到你自己的 App 上灵不灵，还得拿自己的 App 来验一波。跑分是入场券，落地是另一回事。

Flash 和 Pro，两档执行策略

ARTEMIS 跑任务分两个档位。

档位	单步耗时	怎么干活	适合场景
Flash	3 到 5 秒	单模型边看边做的反应式循环	日常冒烟、确定性操作
Pro	15 到 40 秒	Planner、Operator、Checker 多角色协作	长流程、探索测试、要报告

Flash 快在历史压缩。跑过的步骤被压成摘要，旧截图折叠成视觉总结，上下文不会随任务变长无限膨胀，所以长任务也扛得住。

Pro 稳在执行前检查。每个动作发出去之前，先对着当前界面树和像素校验目标还在不在，动作被拦截就交回 Operator 换路子走。跑完还有 Checker 对照原始目标做终审，输出书面报告。

用测试行话说，Flash 是快速回归，Pro 是深度探索加验收测试。

整个系统的架构长这样。

底下设备层，ADB 加 scrcpy 管投屏和操控。中间感知层，无障碍层级、OCR、视觉模型三路取界面信息。往上执行层，Flash 和 Pro 两档。最顶上对外开出四个口子，Web 控制台、命令行、MCP、Python SDK。

快速上手

上手门槛非常低。一台开了 USB 调试的安卓真机，或者一个模拟器，然后 clone 下来跑一条脚本。

git clone https://github.com/google/artemis.git && cd artemis
./start.sh

start.sh 会自动装齐 ADB、scrcpy、FFmpeg、Python 运行时这些依赖，然后把 ARTEMIS 的 MCP 服务和一份移动端测试准则 rules.md 挂进你的 AI IDE。比如 Cursor、Claude Code、Codex。

启动后浏览器会自动打开一个 Web 控制台。

左边真机投屏，中间是实时推理流，它点了哪里、坐标是多少、每步结论，全程可见。底下输入框用自然语言下发任务，右边看板管任务队列和历史回放。跑挂了想看现场，回放点开就是。

不想开浏览器，命令行直接跑。

uv run artemis run "打开系统设置，找到电池选项并告诉我当前电量" --profile flash

接进 AI 编程工具，才是它的完整形态

MCP 装好之后，你在 Claude Code 里可以直接这样说话。

把最新改动打成 APK，装到连着的设备上，用测试账号走完登录，验证登录后有没有意外弹窗，最后把页面截图给我。

它自己调构建，自己装机，自己操作，自己截图。

Bug 复现这个场景尤其顺。用户反馈一段操作路径，原样发给它，它在真机上原样走一遍，Logcat 日志和截图一并带回来。以前复现一个偶现 Bug 要人工反复点半天，现在让它挂着跑。

官方放了一组和 Antigravity 配合的完整工作流，从下指令到出报告四步。

第一步，在 IDE 里描述你要测什么。

第二步，它生成带里程碑的测试计划给你过目。

第三步，真机上自主执行，导航界面，采性能数据。

第四步，输出结构化的诊断报告，指标表格和原始数据集都在。

Python SDK，接进 CI

要在现有工程里用，它提供了零运行时依赖的 Python 客户端。

uv add "artemis-client @ git+https://github.com/google/artemis.git#subdirectory=packages/artemis-client"

from artemis_client import ArtemisClient

client = ArtemisClient(
    "http://artemis-host:8000",
    device_serial="emulator-5554",
    default_profile="flash",
)

result = await client.run(
    "Open Settings, go to Battery, verify battery percentage is displayed, and check for crash dialogs.",
)

assert result.succeeded, f"Test failed: {result.error or result.status}"

返回的是 Pydantic 强类型结果，断言直接写，pytest 工程和 CI 流水线都能接。

Appium 真的慌了吗

标题这话，一半当真，一半别当真。

当真的一半。ARTEMIS 干掉的是「写脚本」这个环节。定位器、等待策略、页面编排，Appium 脚本里最折磨人的三样东西，在自然语言驱动的模式里不存在了。探索测试、日常冒烟、Bug 复现，这些场景它今天就能顶上，比人手点快，比死脚本灵活。

别当真的一半。它的边界同样清楚。

• 目前只支持 Android
• 每一步都是模型调用，token 成本和耗时摆在那，几千条用例的回归矩阵，还是脚本便宜
• 结论带概率属性。脚本断言非黑即白，模型报告讲把握大小，有些质量门禁要的就是那句死话
• 靠无障碍服务读屏，你的 App 要是把无障碍支持阉割了，就得退到坐标和视觉兜底，稳定性打折

所以我的建议是，短期拿它和 Appium 进行搭档互补使用。

日常回归继续用脚本压缩执行成本，探索、冒烟、复现这些边角重活交给它，眼下这是最现实的分工。长期谁吃掉谁，一个半月的项目还看不出答案，但「写 Appium 脚本」这门手艺的溢价，确实在缩水。

我的几条建议

1、做 Android 测试的，这周就把它跑起来

上手成本已经低到两条命令。找台测试机，把你的冒烟场景用中文描述给它，Flash 档跑几遍，看成功率。这种几乎零成本的尝鲜，值得每个移动端测试人做一次。

2、做测试平台的，盯住 MCP 和 SDK 两个口子

ARTEMIS 的平台化意图很明显，MCP 接 IDE，SDK 接 CI。把它包成平台上的一个真机执行节点，用例收自然语言，结果回传结构化数据，这条路已经通了。

3、做 iOS 测试的，先围观，别走远

路线图上排着 iOS 支持、端侧轻量视觉模型、实时语音交互。这批能力落地的时候，移动端自动化的写法要重讲一遍。现在值得做的一件事，是把你们的测试场景整理成清晰的自然语言描述，这批描述往后就是新形态的用例资产。

写在最后

翻了下日历，ARTEMIS 开源到现在，才一个半月。

一个半月，一万多 star，谷歌官方出品，MCP 原生，AndroidWorld 榜首。这几件事凑在一起，基本可以确定，自然语言驱动真机这件事，接下来一年会有一大波跟进者。

被改写的先是入门路径。以前学 UI 自动化，先啃定位器，再啃等待，再啃框架 API，一套下来仨月。以后的第一行用例，可能就是一句中文的测试描述。

工具一直在换，怎么证明它是对的，这个活一直都在。被测对象从函数、接口，一路换到模型、Agent，现在轮到拿着自然语言跑真机的 agent，题面又换了一次，考点没变。你在软件测试里攒下的功力，这套新题里一样用得上。

ARTEMIS 的地址放这了👉 。

https://github.com/google/artemis

觉得有用欢迎转给团队里做移动端测试的同学。

---