做过 App 自动测试的朋友，Appium 这套流程应该都不陌生。
装环境，配驱动，起 Server，写 capability。uiautomatorviewer 抓元素，xpath 一层套一层，等待策略全靠拍脑袋。跑十条挂三条，改完再挂两条，脚本比业务代码还难维护。这一套流程，很多人从入行用到今天。
8 月 13 号，谷歌在 GitHub 上开源了一个项目，ARTEMIS。
这个项目的作用，用自然语言指挥 AI，去操作一台真实的安卓手机。你跟它讲「打开系统设置，找到电池选项，告诉我当前电量」，它会自己去看屏幕，自己找入口，自己点进去，把结果带回来告诉你。
[图片上传失败...(image-42a8d1-1791507782281)]
ARTEMIS，谷歌的安卓自动化神器
这个项目开源，大家记住几个关键信息就可以了。
谷歌官方开源，Apache-2.0 协议，Python 实现
8 月 13 号放出，一个半月 star 破万
[图片上传失败...(image-cc6a61-1791507782281)]谷歌研究院 AndroidWorld 基准 99%+ 任务完成率，官方榜单第一
提供原生 MCP Server，可直接对接 Antigravity、Claude Code、Codex、Windsurf
主流多模态模型都能接，比如Gemini、Claude、GPT、Qwen-VL
需要注意的是，它和 Appium 其实不是同一类定位。
- Appium 是自动化框架，你写脚本，它负责执行。
- ARTEMIS 是一个 agent 系统，你给目标，它自己看屏幕、理解界面、规划动作、执行操作、输出报告，全程不需要你写一行定位代码。
官方的演示 GIF 挺直观，一句指令，它自己打开 Google Maps 设置驾车路线算好全程耗时，再切到 YouTube 放了一首 Coldplay。两个 App，一句话，中间不用人管。
[图片上传失败...(image-5351ab-1791507782281)]
跨 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 方案，别家大多卡在五到七成，它一只手够到了天花板。
[图片上传失败...(image-9497c3-1791507782281)]
不过做测试的看到跑分都该冷静。榜单说明它看得准、点得稳，具体到你自己的 App 上灵不灵，还得拿自己的App来验一波。跑分是入场券，落地是另一回事。
Flash 和 Pro，两档执行策略
ARTEMIS 跑任务分两个档位。
| 档位 | 单步耗时 | 怎么干活 | 适合场景 |
|---|---|---|---|
| Flash | 3 到 5 秒 | 单模型边看边做的反应式循环 | 日常冒烟、确定性操作 |
| Pro | 15 到 40 秒 | Planner、Operator、Checker 多角色协作 | 长流程、探索测试、要报告 |
Flash 快在历史压缩。跑过的步骤被压成摘要，旧截图折叠成视觉总结，上下文不会随任务变长无限膨胀，所以长任务也扛得住。
Pro 稳在执行前检查。每个动作发出去之前，先对着当前界面树和像素校验目标还在不在，动作被拦截就交回 Operator 换路子走。跑完还有 Checker 对照原始目标做终审，输出书面报告。
用测试行话说，Flash 是快速回归，Pro 是深度探索加验收测试。
整个系统的架构长这样。
[图片上传失败...(image-bba68f-1791507782281)]
底下设备层，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 控制台。
[图片上传失败...(image-13daf7-1791507782281)]
左边真机投屏，中间是实时推理流，它点了哪里、坐标是多少、每步结论，全程可见。底下输入框用自然语言下发任务，右边看板管任务队列和历史回放。跑挂了想看现场，回放点开就是。
不想开浏览器，命令行直接跑。
uv run artemis run "打开系统设置，找到电池选项并告诉我当前电量" --profile flash
接进 AI 编程工具，才是它的完整形态
MCP 装好之后，你在 Claude Code 里可以直接这样说话。
把最新改动打成 APK，装到连着的设备上，用测试账号走完登录，验证登录后有没有意外弹窗，最后把页面截图给我。
它自己调构建，自己装机，自己操作，自己截图。
Bug 复现这个场景尤其顺。用户反馈一段操作路径，原样发给它，它在真机上原样走一遍，Logcat 日志和截图一并带回来。以前复现一个偶现 Bug 要人工反复点半天，现在让它挂着跑。
官方放了一组和 Antigravity 配合的完整工作流，从下指令到出报告四步。
[图片上传失败...(image-c55cd3-1791507782281)]
第一步，在 IDE 里描述你要测什么。
[图片上传失败...(image-7f4b90-1791507782281)]
第二步，它生成带里程碑的测试计划给你过目。
[图片上传失败...(image-326571-1791507782281)]
第三步，真机上自主执行，导航界面，采性能数据。
[图片上传失败...(image-e7b501-1791507782281)]
第四步，输出结构化的诊断报告，指标表格和原始数据集都在。
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
觉得有用欢迎转给团队里做移动端测试的同学。
我是狂师，公众号长期分享 AI 提效与测试开发技术干货。
以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～谢谢你看我的文章，我们，下次再见。
