Android 测试跑到 99%，ARTEMIS 真正接住的是 Bug 复现

Android 测试里最烦的一句话，不是“这个版本有 Bug”，而是“我这边复现不了”。

前端说弹窗只在某台真机上出现，后端要一段 Logcat，测试同学手里已经排了回归。等你把 APK、账号、机型、操作顺序重新凑齐，那个一闪而过的 Toast 又没了。不是哥们，移动端的 Bug 有时就是这么会挑时间。

Google 刚开源的 ARTEMIS 想接住的，正是这段最容易断的链路。它可以让 AI 编码助手通过 MCP 驱动已连接的 Android 真机或模拟器，按自然语言需求操作界面、抓截图、收集 Logcat，再把任务轨迹留下来。官方给出的 AndroidWorld 成绩是 99%+，覆盖 20 多个应用和 100 多个多步任务。

这个数字当然很显眼。好家伙，99% 放在移动自动化里，谁看了都会多停一秒。

可我觉得，真要不要把它接进团队，不该先问“它是不是比现有脚本更聪明”，而该问一个更朴素的问题：它能不能把一次难复现的问题，变成下一次还找得回来的证据。

官方 README 展示的 AndroidWorld 对比图。跑分是入口，不是上线验收单。

99% 不是把测试交出去的许可证

AndroidWorld 是一个公开基准，不是你的登录页、支付页、深链路跳转和灰度配置。ARTEMIS 的 99%+ 说明它在那套 100 多个多步任务里完成得很好；它不自动证明你的业务流程已经安全，也不替你判断某次真实异常到底是客户端、服务端还是测试数据惹的祸。

但它把三个以前散开的东西放到了一起：设备上的实际操作、操作过程里的诊断信息、以及可回放的结果。 对移动端团队来说，这比“再来一个会点屏幕的 Agent”有用得多。

官方文档里把它分成了两档。Flash 是快路径，单步通常约 3 到 5 秒，适合确定性的 UI 操作。它会持续压缩历史，处理 Toast、自动消失的控件这类转瞬即逝的东西；代价也写得很直白：没有任务计划、没有执行前安全网、没有检查点校验和最终报告，也不能跑 ADB shell。

Pro 则慢得多，单步约 15 到 40 秒。它会维护一份带 verify 和 assert 的任务计划，在每个动作前用 UI 树优先、像素兜底的方式确认目标，并把被拦截或失败的动作作为事故继续追踪。它适合登录、支付前置流程、复杂表单和长回归这种“慢一点没关系，别把证据弄丢”的场景。

这两档的取舍很像生产环境里常见的选择。想快，就少带护栏；想让一条问题单能交到下一个人手里，就得为计划、校验和回放付时间。厉害了，工具把这层代价摊在 README 上了，反倒省掉很多“怎么跑这么慢”的误会。

从自然语言测试需求到执行和报告，官方给出的四段流程。

最适合先接进“复现”，不是全量回归

如果团队现在已经有 Appium、Espresso 或一堆 CI 脚本，别急着把它们扔进回收站。ARTEMIS 最顺手的位置，是脚本最不擅长、人工又最耗时的那段：把模糊的报错描述变成一条可重复执行的探索任务。

比如需求不是“测登录”，而是“安装最新 APK，用测试账号进入登录页，检查登录后有没有异常弹窗，把最终页面截图和日志带回来”。这类任务里有明确目标，也有现实世界常见的岔路：权限弹窗、网络慢、页面改版、按钮位置变化。传统脚本很适合稳定回归；需要先摸清楚问题在哪里时，能读屏、能留轨迹的执行器更对味。

官方最快的启动方式没有故弄玄虚：准备好开启 USB 调试的真机或模拟器，拉取仓库后运行启动脚本即可。

git clone https://github.com/google/artemis.git
cd artemis
./start.sh

启动后会有本地控制台，也可以在终端直接下一个小任务。这里建议从只读、可回退、没有真实交易的页面开始，别一上来就让它碰生产账号和敏感流程。

uv run artemis run "打开系统设置，找到电池并确认是否显示当前电量" --profile flash

等这条链路稳定了，再把它接到 IDE 里的需求描述、测试账号和失败工单上。要的是一条短路径：描述问题 → 驱动设备 → 留下截图和日志 → 人来判断结论。 这才是把 Agent 用在移动测试里的舒服姿势。

官方架构图把设备控制、定位、历史压缩与诊断放在同一条执行线上。

有三件事，还是得由人守着

第一件是账户和动作边界。ARTEMIS 首次在设备上执行任务时，会安装一个用于读取屏幕布局的无障碍辅助服务。官方说明它只在手机本机监听，不向外发送数据；即便如此，团队仍该把测试设备、测试账号、可执行动作和删除方式写清楚。能点屏幕，不等于该替人点所有屏幕。

第二件是断言。Agent 可以说“没有看到异常弹窗”，但你要先定义什么算异常：一个空白页算不算、接口超时后自动重试算不算、埋点缺失算不算。没有这层业务断言，最后只会得到一段很努力的操作录像。棒棒的，录像很完整，问题还是没回答。

第三件是证据归属。ARTEMIS 的仓库已经在许可证页说明包含了 Minitap mobile-use 开发的源代码。对团队而言，遇到这种高热开源项目，多看一眼许可证、依赖和源代码声明，比只看星标和跑分靠谱。你接进 CI 的不只是一个 Demo，还是一条要长期维护的供应链。

上车前，拿这张小单子过一遍

• 任务是否能写成一个可观察的结果，而不是“帮我看看有没有问题”？
• 设备和账号是否是隔离的测试环境，失败后能恢复？
• 需要 Flash 的速度，还是 Pro 的计划、检查点与报告？
• 截图、Logcat、操作轨迹最终由谁确认，并写回哪张缺陷单？
• 现有脚本覆盖稳定路径时，ARTEMIS 是否只补探索、复现与界面变动这块空白？

这五个问题过了，再把它放进试验分支。没过，先别把“99%”贴到发布门禁上。跑分负责让人注意到工具，复现证据才负责让团队敢相信它。

我更愿意把 ARTEMIS 看成一个会用真机的排障搭子，而不是一个替你盖测试章的机器人。它最有价值的地方，不是替人按了多少次按钮，而是把那些“当时看见过、后来找不到”的瞬间，尽量留在可检查的轨迹里。

如果你们要试，第一条会交给它复现的 Android 问题是什么？