Google的ARTEMIS开源Android自动化：99%的AndroidWorld说法究竟涵盖了哪些内容

上最新的一次提交google/artemis并不是什么新功能，而是一行署名致谢——“fix: complete README and relevant file headers per Apache 2.0 requirements”，于 2026 年 9 月 12 日推送，此时距离 Minitap 发布一篇题为我本以为谷歌会做得更好的文章刚过去三天。谷歌的 ARTEMIS 是该公司新近开源的 Android 自动化智能体：它能把一句平实的英文指令，转化为在实体 Android 设备或模拟器上真实的点击、滑动、输入与验证，并一路记录日志与截图，在 Google Research 的 AndroidWorld 基准测试中报告了 99% 以上的任务完成率。它由谷歌 Pixel Test Engineering Fusion 团队于今年八月以 Apache 2.0 许可发布，也确实值得你花上一个下午。而截至九月中旬，它还成了一场开源署名之争的中心——这场争斗对移动智能体如何被构建的揭示，比那个基准分数更有意义。两个故事都是真的。但只有其中一个，能解释为什么这个仓库的最后一次提交是一处许可证修正。

实际发布的内容

ARTEMIS 不是模型，也不是聊天机器人封装器。它是一个控制框架——一个 Python 3.12+ 系统，位于视觉语言模型和真实手机之间。你用英语给它一个任务；它观察屏幕，决定动作，通过 ADB 执行该动作，检查发生了什么，然后继续运行。盒子里有五样东西：

• 一个 CLI 和一个 Python SDK。 code>./start.sh/code> 会初始化 ADB、scrcpy、FFmpeg 和 uv 环境；code>uv run artemis run "…" --profile flash/code> 以无头模式运行任务；code>artemis-client/code> SDK 封装了同一调用以供 pytest 和 CI 使用，返回 code>succeeded/code>、code>status/code>、code>device_serial/code> 以及一个 code>trace_id/code>，之后你可以追踪它。

• 一个 Web 控制台。 code>uv run artemis ui/code> 会在 code>localhost:8000/code> 上提供一个可视化测试控制台，让你逐步观察循环的每一步。

• 原生 MCP 服务器。 正是这一部分让它得以传播开来。 code>uv run artemis mcp --install all/code> 暴露了 code>mobile_run_task/code>、code>mobile_manage_task/code>、code>mobile_get_device_state/code>、code>mobile_inspect_trace/code> 以及 code>mobile_diagnose/code> 给任何支持 MCP 的助手，并为 Antigravity、Claude Code 和 Codex 提供一流的安装路径，同时可为 Cursor、Windsurf、VS Code 和 Cline/Roo 生成配置。对于已连接该服务器的助手，“构建 APK、安装它、打开设置、切换飞行模式、对结果截图”不再是一段脚本，而变成一句话。

• 一个无障碍辅助工具。第一个任务会安装 Artemis Accessibility Helper，它读取屏幕布局时不会占用 UiAutomation 连接——这是有意为之，以免同一设备上其他基于 UiAutomator 的工具被抑制。它在手机上运行，不会向设备外发送任何数据；当无法附加时，会回退到 UIAutomator2，回退情况会在任务时间线中显示。

• 日志与跟踪捕获。崩溃堆栈、关键帧截图和诊断报告均由系统自动收集，而不是由调用方临时加装上去——这正是它能够用作回归测试套件、而不只是演示的原因所在。

Flash 和 Pro 是两个不同的产品，却共用同一个名称

在对 ARTEMIS 与任何东西进行基准比较之前，最重要的一点是要明白，code>--profile flash/code> 和 code>--profile pro/code> 并不是同一个 agent 上的速度设置。它们是两个 agent。

• Flash —— 一种反应式“观察-行动”循环，每一步大约 3–5 秒，没有计划、没有笔记、没有执行前安全检查、没有检查点验证、没有最终报告，也没有 ADB shell。默认情况下，该循环是无界的，因为历史是被压缩而非累积的。

• Pro — 一个多智能体图，每步大约 15–40 秒，由以下部分组成：一个 Planner，维护一份带有显式 code>verify/code> 和 code>assert/code> 条目的动态 Markdown 计划；一个拥有完整工具集的 Operator；以及一个只读 Checker，用于验证检查点并执行退出评审。 code>--verification-level/code> 接受 code>off/code>、code>final/code>（默认值）、code>checkpoints/code> 或 code>strict/code>。

对于同一个任务描述，这就是五到十倍的延迟差距，也是冒烟测试与 100 多步探索性运行之间的差别。Google 自己的说法是，Pro 面向长时程工作和持续的code>[Loop:continuous]/code> 监控；Flash 则用于常规、确定性的 UI 杂务。如果你读到的评测引用了各步骤的耗时，却没有告诉你这些数据出自哪个配置，那它等于什么都没说。

定位策略才是真正的工程

大多数移动自动化框架都败在选择器上。ARTEMIS 以动态优先为设计原则：当无障碍元素索引存在时，它就用它；当不存在时——比如 Canvas、Compose 界面、Flutter 视图、游戏——它就回退到坐标和视觉。没有需要维护的 XPath 层，也没有会失效的 ID，这很重要，因为你最想测试的应用，正是那些每周都发布新构建的应用。

Pro 配置文件增设了一层安全网：每个操作都会先经过一次执行前检查，以 XML 为主、像素回退为辅，从而捕捉即将吞掉你点击的系统弹窗。失败会开启一个“执行事故”，它会一直留在上下文中，直到后续某次成功将其解决，而不是另起一个独立的修复代理。长时间会话会被压缩——旧截图变成视觉摘要，已完成的步骤被切分成可召回的纪元，code>search_history/code> 和 code>replay_steps/code> 可以将它们重新拉取回来——这正是让 100 步的上下文不至于变得负担不起的原因。

排行榜上的99.1%，以及那些发布帖略过的注意事项

ARTEMIS 的核心宣称是在 AndroidWorld 上达到 99%+ 的完成率，这是 Google Research 的基准，涵盖 20 多个应用中的 116 项真实任务，按 Pass@1 评分。截至 2026 年 9 月 11 日，AndroidWorld 排行榜显示 ARTEMIS 为 99.1%，而 Minitap 的 mobile-use 为 91.4%，人类表现为 80%。从榜单上看，这是公开报告结果中的最先进水平。

有两件事需要放在那个数字旁边。首先，AndroidWorld 排行榜明确不会独立核实提交内容——榜单上的每一个数字，包括 ARTEMIS 的，都是由产出该结果的团队自行报告的；而一项稳健性分析表明，仅任务变化本身就可能大幅改变一个智能体的得分。要把 99.1% 视为在一个公开、可核查的基准上做出的强有力的厂商声明——这本身是真实且有价值的——而不是经过审计的测量结果，因为它并不是。其次，比较的形态很重要：该基准是一组固定的任务，而据报道，ARTEMIS 公布的比较图表遗漏了 mobile-use，却包含了其他条目。一张图表若缺失了此前最强结果，这样的基准所支撑的主张就比原始百分比所暗示的更弱。

这场争议，才是这个月真正的新闻

在其博客以及该仓库的一个公开 issue 中，Minitap——一家移动测试初创公司，其开源的 mobile-use 项目为 Android 和 iOS 做同样的工作——指控 ARTEMIS 的 229 个文件中有 228 个与其自己的文件完全相同。其公布的细节异常具体：Android 设备连接代码与其实现相符，逐字复用属于名为“Hopper”的智能体的指令，以及一个向 Alice、Bob 和 Charlie 发送新年消息的 WhatsApp 示例，连相同的注释、相同的清理步骤和相同的 bug 都被一并复现。它还进一步指控，一份载有三位 Minitap 作者姓名——Pierre-Louis Favreau、Jean-Pierre Lo 和 Nicolas Dehandschoewercker——的文件于 8 月被强制推送替换，姓名被移除，并换成了另一位作者。

许可证问题并不模糊。mobile-use 采用 Apache 2.0，而 Apache 2.0 恰恰允许这种复用——商业性的、衍生的、闭源的——前提是你保留版权声明并说明你做了哪些改动。它不允许的是，在剥离这些声明的情况下分发代码。自相关指控浮出水面以来，该仓库一直带有“This project includes source code developed by Minitap, Inc.”这一行，并附有指向 minitap-ai/mobile-use 的链接，而完成这一署名归属的 9 月 12 日提交，截至本文撰写时，是 code>main/code> 上最近的一次变更。Minitap 尚未公布任何证据，将其自身未获回应的排行榜提交与删除署名一事联系起来，谷歌也未发布详细的公开回应。诚实的解读是：所分享的代码是合法的，而且一直以来都是被允许的；只是在一段时间里，文书工作没做到位，而如今它已被纠正。

没人算进成本的那部分：模型账单

ARTEMIS 出厂时随附一枚徽章，上面写着"Multi-Model — Gemini | Claude | GPT-4o | Qwen-VL"，而其配置文件位于 code>config/artemis.jsonc/code>，你可以在其中将它指向你持有凭据的任意视觉模型。除非你在真实的工作流上运行 Pro，亲眼看到长时间运行的智能体实际花掉多少钱，否则那个文件里的任何内容都还谈不上面向用户。

算一算这些配置档的账。一次 100 步的 Pro 运行，每步 15–40 秒，实际耗时在 25 分钟到刚过一个小时之间，而且其中每一步都至少是一次携带截图的视觉模型调用。Flash 每步更便宜，但循环得更厉害，而且由于它的上下文是压缩而非截断的，它会轻松越过你原本以为已是上限的轮次限制。无论你选哪个配置档，随测试套件规模扩展的支出项都是模型，而不是许可证或硬件。

这正是路由层不再只是抽象概念的地方。一个视觉模型驱动着漫长的 Android 会话，这种工作负载有两个棘手的特性：它长期存在，而且无法容忍在第 74 步中途出现提供商故障，因为该次运行的上下文就在那个提供商的端点上。把 ARTEMIS 指向单一的 OpenAI 兼容基础 URL，并让我们的故障转移把运行转移到同一模型的另一个提供商，这就是偶发失败的测试与白白浪费一下午之间的差别。Qwen3.8-Flash 是值得首先尝试的有趣候选——一个 6B 激活参数的多模态 MoE，拥有 1M token 上下文，在我们的目录中定价为每百万输入 token 0.15 美元、每百万输出 token 0.47 美元，缓存读取为 0.018 美元，缓存写入为 0.230 美元。这里真正相关的是缓存读取价格，因为一次 Pro 运行在每一步都会重新读取不断增长的上下文。

不过，要精确理解这意味着什么：Qwen3.8-Flash 不在 ARTEMIS 已测试的后端列表中，该列表列出了 Gemini、Claude、GPT-4o 和 Qwen-VL。它是一个有可能适配该测试框架的模型，而该框架明确就是为接受这样一个模型而构建的。没有人发表过这种组合的基准测试，若有人声称有过，你应当认为那是他们编造出来的。

路线图，以及其中有多少是承重部分

已公布的路线图上有四项内容：具备编辑器内调试、测试录制和设备控制功能的 Android Studio 集成；iOS 支持；面向低延迟、隐私优先场景的端侧轻量级视觉语言模型；以及实时双工语音交互。

第一个才是值得相信的那个，因为它是 Pixel 测试工程团队顺理成章会拿出的下一个产物，而且不附带任何研究风险——该 agent 已经能驱动设备，只需要在 IDE 里加一个面板。iOS 这件事比从外部看上去的野心要大得多：整个定位策略都依赖 Android 的无障碍服务，而 iOS 没有具备相同权限模型的等价界面，所以预计会是感知层的重写，而不是移植。端侧 VLM 这一项值得密切关注，因为它是清单上唯一能消除当前主导大型测试套件的逐步 API 成本的项目——并且它意味着一个体积小、速度快、具备视觉能力、能让 UI 任务保持连贯的模型，这比“一个擅长工具使用的小模型”要窄得多的目标。

本周该拿它怎么办

克隆它，运行 code>./start.sh/code>（在一个模拟器上），并给 Flash 一个你现有 Espresso 套件覆盖的任务。这会在一个小时内告诉你，动态优先定位器能否在你应用的 Compose 界面上存活，而这个问题决定了其余部分是否重要。然后在 Pro 上运行同一任务，并比较两条轨迹——每步 3–5 秒与 15–40 秒之间的差距，就是你的预算所在；没有它，你就无法推断 ARTEMIS 的成本。

当你阅读代码时，也要读一读文件头。添加 Minitap 署名信息的 9 月 12 日提交是仓库中最新的提交，这意味着你正在阅读的文件头已有四天之久，而这个项目正在公开地积极修复中。这不是回避它的理由，而是一个理由：在幻灯片里引用成功率之前，先弄清楚你手里拿的是这个故事的哪个版本。

将 ARTEMIS 指向单个与 OpenAI 兼容的基础 URL，并让我们的故障转移把运行转到同一模型的其他提供商，这就是一次不稳定的测试与一个白白浪费掉的下午之间的区别。