-
buo4 技术教程组 用户
谷歌开源 ARTEMIS：让 AI 像人一样操作安卓真机，官方基准完成率 99%+
做移动端测试的朋友，对下面这套流程应该都不陌生：装环境、配驱动、起 Server、写 capability；uiautomatorviewer 抓元素，xpath 一层套一层；等待策略全靠拍脑袋。跑十条挂三条，改完再挂两条，脚本比业务代码还难维护。
更难受的是两个结构性毛病。一是控件树和真实渲染经常对不上：Compose、Flutter、混合 WebView 渲染的界面，拿到的节点要么没有 resource-id，要么时机和内容跟屏幕上看到的不是一回事。二是脚本本身是无状态的：它不关心屏幕上发生了什么，只按预设路径走。遇到一个权限弹窗、一次热修复提示、一句文案变更，脚本直接原地去世。
所以"换台真机就点不到元素"不是调侃，是日常。大家嘴上说着智能等待、动态重试，实际上都是在给一套盲操作打补丁，补丁叠多了，维护成本比手工点点点还高。
更要命的是验收标准。Agent 真把界面点完了，不等于测试通过了——它可能走了另一条路径，可能只看到页面变了就认为成功。工具越强，"凭什么算通过"这个问题反而越突出。
谷歌最近开源的 ARTEMIS 想换一条赛道：不写定位脚本，直接用自然语言说目标。你跟它讲"打开系统设置，找到电池选项，告诉我当前电量"，它自己看屏幕、自己找入口、自己点进去，把结果带回来。项目的定位写在 README 第一行——让 AI 助手和测试套件像人一样使用真机。
它到底是什么
ARTEMIS 是谷歌组织下的开源项目，Python 3.12+ 实现，Apache 2.0 协议，原生内置 MCP（Model Context Protocol）服务器，支持 Gemini、Claude、GPT-4o、Qwen-VL 等多模态模型。
注意它的定位不是"又一个自动化测试框架"。传统框架的逻辑是你写脚本、它负责执行；ARTEMIS 是一个 agent 执行层：你给目标，它看屏幕、理解界面、规划动作、执行操作、输出报告，全程不需要你写一行定位代码。底层靠 ADB 和 scrcpy 管投屏与操控，感知靠无障碍层级、OCR 和视觉模型三路取信息，往上长出 Flash / Pro 两档执行策略，对外开四个口子：Web 控制台、命令行、MCP、Python SDK。
官方演示很能说明问题：让它先在 Google Maps 里规划一条跨城驾驶路线并算出全程耗时，再打开 YouTube 放一首 Coldplay。两个 App，一句话，中间不用人管。
四种用法：控制台、CLI、MCP、SDK
ARTEMIS 对外开了四个口子，覆盖从"看着它跑"到"接进流水线"的全谱系：
- Web 可视化控制台（
uv run artemis ui）：实时屏幕投影加交互面板，支持自然语言下发任务、实时推理遥测、动作轨迹和执行回放。界面里能看到视图切换、模型与回放（Flash / Pro 状态与视频回放）、实时 Agent 流（动作感知、目标坐标与结构化结果）、提示词停靠站、任务队列与仪表盘。跑挂了想看现场，回放点开就是。 - 开发者 CLI（
uv run artemis run）：终端直接执行，高保真结构化输出，适合自动化用例、探索性稳定性检查，也是跑 AndroidWorld 基准的入口。 - MCP Server：把真机接进 AI IDE，让编程助手直接驱动设备。
- Python SDK：作为标准库嵌进现有测试框架（如 pytest）或 CI/CD，带强类型的 Pydantic 结构化输出和断言支持。
这四层是同一个内核的不同皮肤，不是四个独立工具——这对后期维护是个好消息。
定位不迷信控件树：索引、坐标、视觉三级回退
ARTEMIS 的元素定位策略，README 里叫 Multimodal Targeting：有控件索引就用索引，没有就回退到坐标，自定义界面再上视觉定位。
这个顺序不是偷懒，是被现实毒打出来的。无障碍树在标准 View 体系上很好用，但自绘的 Canvas、Compose、Flutter 界面，控件树的粒度、时机、内容经常和控制台对不上，强依赖无障碍树等于把鸡蛋放在一个篮子里。OCR 和视觉模型兜底，本质上是用"看得见"兜住"读不到"。
项目还把一套移动端测试心智（rules.md）一起装进你的 IDE，里面明确写了"Dynamic-First, Coordinate-Fallback"的定位模式、Flash 与 Pro 的路由策略、延迟与时序补偿等规则。换句话说，它不只给工具，还把"资深移动测试工程师怎么思考"这件事一并打包了。
Flash 和 Pro：一快一深的两档执行
两档执行档位是 ARTEMIS 最有意思的设计，官方给出的典型耗时：Flash 每步约 3-5 秒，Pro 每步约 15-40 秒。差好几倍，但换来的东西完全不一样。
Flash 是一个快速反应的观察-行动循环：一个模型看实时屏幕、思考、行动，没有图编排，适合常规的、确定性的 UI 任务。瞬时 UI（自动消失的控制条、toast）用 click_sequence 把连续点击串成一次动作，不用再等一轮模型。它还和 Pro 共享同一份会话账本——会话相对时钟（T+mm:ss）、截图折叠成的视觉摘要、按时代块切分的历史，全盘通用。
Pro 是一个规划加验证的多智能体工作流，每一步都慢，但慢得有道理：
- Planner 维护一份活的 Markdown 任务计划，带里程碑和 verify / assert 检查项；
- Operator 拿着全工具集执行——Explorer 定位（flash / pro / ultra 三档是用户按配置设定的，Agent 不能自己挑贵的用）、笔记、历史召回、视频分析、ADB 诊断；
- 每个动作发出前都要过一道 Safety Net（先查实时 UI 树，不行再上像素校验），多个连续动作可以成串发出，专治瞬时控件；
- 一个只读的 Checker 负责核对计划检查点，并在收尾时对着最初目标做终审（
--verification-level可选 off / final / checkpoints / strict，默认 final）。
Pro 面向 100 步以上的长程工作流和 [Loop:continuous] 持续监控，跑完还能出一份书面报告。
把真机接进 AI IDE：MCP 与 rules.md
ARTEMIS 原生带 MCP 服务器，一条命令就能挂进主流 AI IDE：
uv run artemis mcp --install all
支持 Antigravity、Claude Code、Codex、Windsurf、Cursor、VS Code、Cline / Roo、OpenClaw。挂上之后，MCP 侧露出五个工具：mobile_run_task（跑任务）、mobile_manage_task（管任务）、mobile_get_device_state（拿设备状态）、mobile_inspect_trace（查执行轨迹）、mobile_diagnose（诊断）。
然后你就可以在 Claude Code 里直接说人话：
"把最新改动打成 APK，装到连着的设备上，用测试账号走完登录，验证登录后有没有意外弹窗，最后把页面截图给我。"
它自己调构建、自己装机、自己操作、自己截图。Bug 复现这个场景尤其顺：用户反馈一段操作路径，原样发给它，它在真机上原样走一遍，Logcat 日志和截图一并带回来。以前复现一个偶现 Bug 要人工反复点半天，现在让它挂着跑。
和 Antigravity 配合时，官方给出的完整工作流是四步：在 IDE 里描述要测什么；它生成带里程碑的测试计划给你过目；真机上自主执行，导航界面、采集性能数据；最后输出结构化诊断报告，指标表格和原始数据集都在。人始终待在"过目"和"读报告"这两个环节里——这恰好是自动化最该留给人的位置。
成绩单：AndroidWorld 99%+（官方数据）
ARTEMIS 在 AndroidWorld 上拿到了 99%+ 的任务完成率——这是谷歌研究院的基准，覆盖 20 多个 App、100 多个多步任务，README 标注为 SOTA。
需要说明：这是官方口径。单一基准、官方自测，第三方尚未复现，建议把它当作方向性参考而不是定论。但一个肯把基准成绩和榜单截图直接放进 README 的项目，至少态度是端正的。
几个容易被忽略的设计取舍
第一，历史是压缩，不是截断。 Flash 默认不设轮次上限（agent.flash.max_turns，0 表示无限），靠的是历史压缩：旧截图被折成视觉摘要，完成的步骤被切成"时代块"按需召回（search_history / replay_steps），还能用 video_analyzer 直接查会话录像。这一步背后是赤裸裸的 token 经济学：agent 的每一个动作都是一次模型调用，历史无限累积等于给账单埋雷；简单设个轮次上限又会丢上下文。压缩让"长任务"和"可负担"第一次同时成立，这个取舍比一刀切聪明得多。
第二，手机上那个无障碍助手，降级是要留痕的。 第一个任务会在手机上装一个 Artemis Accessibility Helper：一个只读屏幕布局的小服务，不走 UiAutomation 连接（用 UiAutomation 的工具会压制无障碍服务，除非显式放开）。它只在本机监听，不外发任何数据；可以预装（省掉首次约 3 秒的延迟），也可以随时卸载；想彻底不装，ARTEMIS_HELPER_AUTO_INSTALL=false 即可。万一它中途失效，ARTEMIS 会回退到 UIAutomator2，并且在任务时间线、mobile_manage_task 状态和最终报告里明确说明。自动降级不丢人，偷偷降级才丢人。
第三，恢复交给 Operator 自己，没有"修复 Agent"。 Pro 的流程里，被拦截或失败的动作会开一个 execution incident，留在 Operator 的上下文里，直到后续某个动作成功才关闭。多智能体图上每个角色职责单一：Planner 只规划、Checker 只读校验、Operator 执行兼恢复。不单独养一个 repair agent，省的是复杂度和上下文。
第四，贵不贵，人说了算。 Explorer 的 flash / pro / ultra 档位由配置决定（pro.explorer.mode / flash.explorer_mode，或 --explorer-pro-mode），Agent 不能自己挑更贵的推理档。Planner 改计划里程碑会触发一次顾问式复核，但只建议、不阻塞。这种"关键决定留给人"的分寸感，在满屏"全自动"叙事里反而少见。
顺带一提，它对第三方代码的处理也规矩：非谷歌代码集中在 third_party/ 目录，一份上游一个目录，各自带 LICENSE 和 METADATA——比如其中用到了 Minitap 的 mobile-use（Apache 2.0）。这种洁癖值得表扬。
安装与使用
前提：一台开了 USB 调试的安卓真机，或者一个模拟器。推理走外部多模态服务，本机不需要 GPU。
# 1. 拉仓库
git clone https://github.com/google/artemis.git && cd artemis
# 2. 一键启动（macOS / Linux；Windows PowerShell 用 .\start.bat）
./start.sh
start.sh 会自动装齐 ADB、scrcpy、FFmpeg 和 Python（uv）依赖，并提示把 MCP 配置和测试规则装进检测到的 IDE。启动后浏览器打开 http://localhost:8000：设备连接向导、实时投屏、提示词沙盒、执行回放都在里面。命令行里也能管服务生命周期：uv run artemis restart、uv run artemis stop、uv run artemis status。
不想开浏览器，单发任务用 CLI：
uv run artemis run "Open Settings, find Battery and tell me current level" --profile flash
想接进 CI，用零运行时依赖的 Python SDK：
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", default_profile="flash")
result = await client.run("Open System Settings, go to 'Battery', verify battery percentage is displayed.")
assert result.succeeded
两个实操提醒：多模态模型每一步都在花 token，长流程别指望快；第一次跑会往手机装无障碍服务，用测试机，别拿装着支付和聊天记录的主力机。路线图方面，Android Studio 集成、iOS 支持、端侧轻量视觉模型、实时语音交互都排在后面——iOS 用户还得再等等。
适用人群
- Android 测试 / QA 团队：回归、冒烟、偶现 Bug 复现，Logcat 和截图自动带回，探索性测试可以无人值守地跑。
- 重度使用 AI 编程助手的安卓开发者：让 Claude Code / Codex 改完代码自己装机、自己验收，闭环不用人递手机。
- 移动端 Agent 研究者：一个现成的"感知-决策-执行"执行层，加一个可复核的公开基准，适合做实验底座。
- 要接 CI/CD 的团队：Python SDK + pytest + Pydantic 结构化输出，每条执行带 trace_id，失败可回放。
- 爱折腾的极客玩家：跨 App 的日常任务也能一句话搞定——规划路线、放首歌这类演示，本质上是在预览"手机自己照顾自己"的样子。
最后说两句
ARTEMIS 真正的价值，不是"AI 会点手机了"这个爽点，而是它把移动端自动化的入口换了：从"写死的路径"变成"说清楚的目标"。但工具只解决了"怎么走"，没解决"凭什么算通过"。目标要可观察、动作要有边界、关键结论要能被独立验证——这些测试设计的基本功，Agent 一步都替不了你。
比较现实的姿势是：探索归 Agent，断言归确定性。让 Agent 去跑不固定的路径、去碰边角 case，把稳定重要的场景沉淀成可重复脚本，关键结果继续用页面状态、接口响应这类硬断言守住。Flash / Pro 两档档位本身也是这个思路的产物——快的那档跑量，深的那档啃硬骨头。
GUI 自动化的下一个阶段，大概率不是谁替代谁，而是分工重新划了一遍。
还有一个细节值得玩味：那个只读屏幕、不外发数据的无障碍助手，那个降级必须留痕的执念，那个"贵不贵人说了算"的开关——谷歌在教市场怎么信任一个会操作你手机的 Agent。信任建立起来，平台才是平台。这一步，比 99% 这个数字更接近项目的真正野心。
项目地址：google/artemis ｜ 基准：AndroidWorld ｜ 社区：Discord