让 AI 助手自己拿起一台安卓手机，点开设置看电量、翻进应用里搜一个词、回到聊天软件把消息发出去——这类活过去要么靠人手动录脚本，要么靠写死的控件选择器撑着，界面一改整条用例就报废。ARTEMIS 是 Google 放在自己 GitHub 组织下的一个开源项目，做的正是这层翻译：你用一句话说清楚要验什么，它把指令拆成动作，在连着调试通道的真机或模拟器上一步步点下去，顺手抓 Logcat、截图和每一步的推理轨迹。它对外公布的 AndroidWorld 成绩是 99% 以上，那是 Google Research 那套覆盖 20 多个应用、100 多道多步任务的基准。它还自带 MCP 服务器，能把同一台手机接进 Antigravity、Claude Code、Windsurf 这类 IDE，让编码助手直接触发测试并读回结果。下面把它怎么定位、两条执行档差在哪、装起来要走几步、花不花钱，一条条说清。
ARTEMIS 是什么？
一句话概括：把自然语言指令变成可靠的安卓自动化，跑测试、跑日常操作都算。仓库挂在 Google 的官方组织账号下，采用 Apache-2.0 许可，主体是 Python 写的，要求 3.12 以上，作者署名 Farley Wang，项目自标版本 1.0。仓库 2026 年 8 月中旬建立，到 10 月底已经积累 1.5 万余 star、1.7 千 fork，未结议题 62 条、待合并的拉取请求 112 条，6 位贡献者、121 次提交、817 个文件的体量；四条分支、零个 tag，说明它至今没有正式发布版本，所有更新直接推在主干上，想用就跟着主干走。
它和传统 UI 自动化脚本的差别在感知方式上。传统脚本依赖控件树的固定选择器，一次改版就得全体返工；ARTEMIS 把屏幕当成一张图来读，优先用可访问性层级里的元素索引，索引缺失时退回坐标与视觉定位，所以自绘 Canvas、Compose、Flutter 这类拿不到标准控件的界面它也能处理。这让它更接近”让一个人拿着手机按描述操作”，而不是”回放一段录好的坐标”。也正因为有模型参与，它的单步耗时是秒级的，不是毫秒级的。
核心功能
最值得先看的是双执行档：一个负责快，一个负责稳，同一套指令换个参数就能切。围绕这两档，外围工具补齐了从触发到复盘的全链路。
- Flash 档——单智能体的”看一眼、想一下、点一下”循环，每步 3 到 5 秒，没有图编排的开销，适合步骤固定、界面熟悉的日常用例；默认不设轮次上限，靠压缩历史而不是截断来控上下文。
- Pro 档——多智能体图，规划者维护一份带里程碑和校验项的 Markdown 计划，执行者用全套工具落地，只读的检查者负责核验里程碑和收尾终审；每步 15 到 40 秒，能扛 100 步以上的长流程和连续监控。
- 动作预检——Pro 档每个动作发出前都要跟实时界面树和像素对一遍，XML 优先、像素兜底；被拦下的动作会变成一条留在执行者上下文里的”事件”，直到后续动作成功才消解，恢复由执行者自己完成，不另开修复智能体。
- 多模态定位——元素索引、文字识别与视觉模型三层叠加，专门对付自绘界面；坐标定位必须用 Google 的具身推理系列模型，普通视觉模型在这件事上精度不够。
- MCP 服务器——原生实现，把真机接进编码 IDE，提供五个工具：跑任务、管任务、取设备状态、翻执行轨迹、做失败诊断；IDE 端能直接拿到 Logcat 与截图。
- Web 控制台——启动后在本机 8000 端口打开，有设备连接向导、实时投屏、指令沙盒、执行回放和任务队列看板，长任务挂在后台也能随时回来查。
- Python SDK——客户端包零运行时依赖，ADB、模型、图像处理都留在设备主机侧；接进 pytest 或 CI 时能拿到强类型的结构化结果和断言，适合挂进现有流水线。
- 历史压缩——旧截图折成视觉摘要，已完成的步骤压成可检索的历史块，需要时按关键词回捞或重放；另有录像分析节点，能拿任务录像做时序核对。
使用场景
它不是给所有人准备的，最有价值的位置是”要反复验证真实界面、又不想维护一堆选择器”的团队。个人开发者拿它做上线前自测，QA 拿它做回归，都能省掉一批手工点击。
| 人群/角色 | 场景描述 | 推荐指数 |
|---|---|---|
| 安卓开发 | 改完登录流程想立刻验一遍异常弹窗与最终页面，不想为一次性检查写用例 | ★★★★★ |
| 测试工程师 | 回归用例里大量跨应用流程，界面改版频繁，选择器维护成本高 | ★★★★★ |
| 独立开发者 | 一个人维护应用，没有人手做真机巡检，需要一份可重复跑的自测流程 | ★★★★☆ |
| 创业团队 | 想把冒烟测试挂进流水线，又没有专职自动化岗能长期养脚本 | ★★★★☆ |
| AI 工具玩家 | 想让编码助手直接操作手机取截图、抓日志，做端到端演示 | ★★★★☆ |
| 模型评测研究 | 需要一个能跑 AndroidWorld 基准的执行环境与对照口径 | ★★★☆☆ |
操作指南
官方的路径很短：克隆仓库，跑一个启动脚本，剩下的交给它。第一次在真机上跑任务，它还会往手机里装一个辅助服务，这一步会改变手机状态，动手前先确认设备是测试机。
- 打开 ARTEMIS 仓库页，把代码克隆到本地，进到项目目录；机器上需要 Python 3.12 以上，剩下的依赖由启动脚本处理。
- 用数据线接上开了 USB 调试的安卓设备，或者先起一个模拟器；接不上的话脚本里的设备向导会给出排查提示。
- macOS 与 Linux 跑 `./start.sh`，Windows 在 PowerShell 里跑 `.\start.bat`，注意带上 `.\` 前缀，命令提示符下则直接写 `start.bat`。
- 脚本会检测并自动装好 ADB、投屏、FFmpeg 与 Python 包管理工具，然后询问要不要把 MCP 配置和一份”移动测试思路”规则文件写进本机已装的 IDE；这一步按需确认即可。
- 浏览器会自动打开本机 8000 端口的控制台，按向导选设备、填模型密钥，然后在底部「Prompt Dock」指令框里用一句话描述要验的场景，先试一条最短的，结果会落在「Task Queue」看板里。
- 不想开界面就直接用命令行：`uv run artemis run “打开设置，找到电池，告诉我当前电量” –profile flash`；要长流程与校验就换成 `–profile pro`。
- 想接进编码助手，跑 `uv run artemis mcp –install all` 让它自动写配置，或者手动在客户端的 MCP 配置里指向项目内的 Python 解释器；装完在对话里描述测试意图即可。
- 需要长驻服务时用 `artemis ui` 起控制台、`artemis status` 看状态、`artemis restart` 重启、`artemis stop` 停掉；手机上的辅助服务可用 `artemis helper install` 预装、`artemis helper status` 检查、`artemis helper uninstall` 移除。
支持平台
宿主侧三平台都覆盖：macOS 与 Linux 走 shell 启动脚本，Windows 走 PowerShell 批处理，仓库另外带了 Dockerfile 与一套容器化的演示环境，方便在服务器上起服务。设备侧只认安卓——真机开 USB 调试，或者用模拟器，ADB 默认连本机的 5037 端口。运行环境要求 Python 3.12 以上，模型通过各家的 API 密钥接入，官方示例里给了 Gemini、OpenAI、Anthropic、OpenRouter 与 xAI 的配置位，另可选用 Google Cloud Vision 做文字识别。iOS 目前只写在路线图里，尚未落地。
产品定价
项目本身免费。代码以 Apache-2.0 发布，没有订阅档、没有授权费、也没有按设备或按次计费的版本，手机端那个辅助服务随仓库一起给出。真正的开销在模型调用上：它自己不带模型，你填哪家的密钥就按哪家的价目表走量，一步一张截图、长流程上百步，账单跟着步数涨。想压成本有两条路，一是在配置里换成便宜档的预设，二是把定位与观察节点指向本地跑的视觉模型；代价是坐标精度和稳定性都会退一截，长流程未必跑得完。
常见问题
Q：它会不会动我手机上的东西，隐私怎么算？
会动，但改动是可见且可逆的。第一次跑任务时它往手机装一个辅助服务，用来读取当前界面的布局，通知栏会出现一条折叠的提示，设置里的无障碍列表也会多一项；这个服务只在本机监听，不往外发数据，随时可以卸掉。它还能通过调试通道执行 shell 命令、抓日志、截图，这些都在你的机器和你自己的模型密钥下发生。用个人主力机的话，建议关掉自动安装辅助服务、也关掉保持屏幕常亮这两项，只在测试机上放开。
Q：和传统的 UI 自动化框架比，它替代谁？
替代的是”写选择器、维护选择器”这部分工作量，不是替代整个测试体系。写死的脚本快、确定、可重复，但改版就崩；ARTEMIS 慢，每步要等模型看屏幕，却能在界面变化后自己找路。实践中更省事的组合是：把稳定的核心流程留给脚本，把跨应用、界面常变、需要人眼判断的那部分交给它。它也能作为库接进 pytest，两种方式可以在同一套流水线里共存。
Q：非得用 Google 的模型吗，能不能全本地跑？
坐标定位这一环目前强绑定 Google 的具身推理系列模型，配置里明确写了非该系列模型做不好空间定位，这是硬约束。规划、观察、总结这些节点可以换成别家，也能接本地跑的视觉模型，配置里就有一个本地预设。但全本地意味着精度和速度都往下掉，长流程更容易在中途卡住；要跑基准或做正式回归，还是按官方默认的组合来更稳。
开发者小结
它的价值不在于”又一个自动化框架”，而在于把感知这件事从选择器换成了看屏幕，顺带把失败恢复做成了流程的一部分——被拦下的动作会挂在上下文里等后续成功，而不是直接让整条用例挂掉。99% 以上的 AndroidWorld 成绩说明这条路走得通，双执行档的取舍也很诚实：要快就别要校验，要稳就接受每步几十秒。短板同样明显，没有正式发布版本、主干随时在动、坐标系那环离不开特定模型、iOS 还在路线图上，这些都得自己担。适合已经在做安卓端到端测试、并且愿意接受秒级步进节奏的团队先拿一台备用机试水；只想找现成脚本录制工具的人，会觉得它绕远了。
相关文章
