夯爆了，谷歌又一强大AI自动化开源神器，Appium慌了！

做过 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, optionscaps) 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 跑任务分两个档位。档位单步耗时怎么干活适合场景Flash3 到 5 秒单模型边看边做的反应式循环日常冒烟、确定性操作Pro15 到 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.shstart.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 githttps://github.com/google/artemis.git#subdirectorypackages/artemis-clientfrom artemis_client import ArtemisClient client ArtemisClient( http://artemis-host:8000, device_serialemulator-5554, default_profileflash, ) result await client.run( Open Settings, go to Battery, verify battery percentage is displayed, and check for crash dialogs., ) assert result.succeeded, fTest 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 接 IDESDK 接 CI。把它包成平台上的一个真机执行节点用例收自然语言结果回传结构化数据这条路已经通了。3、做 iOS 测试的先围观别走远路线图上排着 iOS 支持、端侧轻量视觉模型、实时语音交互。这批能力落地的时候移动端自动化的写法要重讲一遍。现在值得做的一件事是把你们的测试场景整理成清晰的自然语言描述这批描述往后就是新形态的用例资产