Google把Android测试搬进AI对话：ARTEMIS如何用自然语言操作你的手机

做Android自动化测试的人，大概都吃过Appium的苦。

写一个测试用例：要定位元素？先写一堆XPath。要处理弹窗？得预判所有可能。App更新了？元素ID变了？脚本全挂，从头改。

Google自己的测试团队也受够了。他们把内部用的AI手机操作工具开源了——你不用写脚本，直接用大白话告诉手机"打开设置，找电池，告诉我电量"，AI自己会操作。

这个项目叫ARTEMIS，在Google Research做的Android agent基准测试AndroidWorld上跑到了99.1%成功率。我翻了它的README和技术文档，说说这东西到底能不能用。

ARTEMIS是什么

一句话：一个用自然语言驱动Android设备的AI Agent框架。

你输入一句话，比如"打开YouTube，搜索放松视频，播放一个10小时的自然风景视频"，ARTEMIS会：

1. 理解你的目标，拆成执行计划

2. 观察当前手机屏幕上有什么元素

3. 决定下一步点哪里、输入什么、等多久

4. 通过ADB（Android Debug Bridge，安卓调试桥，电脑和手机通信的命令行工具）真正操作手机

5. 每一步都截图记录，最后给你一份执行报告

它不是模拟器——连的是真实手机或模拟器。不是录屏回放——它是AI根据当前屏幕实时判断下一步。不是固定脚本——同一个任务，每次执行路径可能不同，因为它会根据屏幕变化调整。

它解决了什么问题

传统Android自动化测试的痛点，用过的都懂：

**第一，脚本太脆。**Appium写的测试用例，元素定位靠resource-id或XPath。产品经理改个UI、加个弹窗、换个按钮位置，脚本就崩了。维护测试脚本的时间，比写脚本的时间还长。

**第二，写脚本门槛高。**你得会Python/Java、懂UIAutomator（安卓官方UI自动化框架）、知道怎么定位控件。测试同学能写，但产品经理、设计师、运营想自己测一个流程？别想了。

**第三，动态场景搞不定。**比如"搜索一个视频并播放"——搜索结果页长什么样，每次都不一样。传统脚本写死了第几个结果能点，换个搜索词就废了。

ARTEMIS打的就是这三点：不用写脚本、谁都能用、AI自己看屏幕决定下一步。

技术上怎么做到的

1. 三层UI元素定位

AI要操作手机，首先得知道屏幕上有什么。ARTEMIS用了三层策略，从快到慢、从可靠到兜底：

层级	方式	速度	什么时候用
第一层	无障碍树元素索引	最快	App有完整的accessibility tree（无障碍树，安卓把界面控件结构暴露给辅助功能服务的树状数据）
第二层	坐标点击	快	控件信息不全时，直接点屏幕坐标
第三层	视觉搜索	最慢	前两层都搞不定时，调用Gemini Embodied Reasoning模型"看"屏幕截图找元素

这个设计很务实：能不用视觉模型就不用——视觉推理慢、贵、不稳定。先用结构化的无障碍树，拿不到才退到坐标，最后实在没办法才上视觉模型。

2. Flash模式和Pro模式

ARTEMIS有两个执行模式，不是快慢切换，是两个完全不同的Agent：

	Flash模式	Pro模式
每步耗时	约3-5秒	约15-40秒
执行前规划	无，直接做	先出完整计划再执行
安全检查	无	操作前验证目标元素是否正确
错误恢复	无，错了就挂	出错后自动重试或换路径
适合场景	快速回归测试、简单任务	长流程、复杂场景、关键路径

简单任务用Flash跑得快，复杂任务用Pro跑得稳。这个分层思路和现在AI编程工具的"快速补全"vs"深度重构"异曲同工。

3. 怎么操作手机的

底层不神秘——就是ADB + UIAutomator2。

ADB你可以理解成"电脑控制手机的数据线"：通过USB或WiFi连接手机后，电脑可以发命令"点屏幕坐标(500,800)"、“输入文字hello”、“截图”。

UIAutomator2是安卓官方的UI自动化库，能拿到当前界面所有控件的信息——按钮的位置、文字、是否可点击。ARTEMIS把这些信息喂给AI，AI看完决定下一步。

所以ARTEMIS本身不做"操作手机"这件事——它做的是决策层：理解目标→看屏幕→决定做什么。真正的手指动作，还是ADB和UIAutomator在做。

4. MCP Server和Python SDK

ARTEMIS内置了MCP Server（Model Context Protocol，模型上下文协议——一种让AI助手直接调用外部工具的标准协议），你可以在Claude Code、Cursor、Codex这些AI编程工具里直接指挥手机：

uv run artemis run "打开设置，找到电池，告诉我当前电量" --profile flash

同时提供Python SDK，可以集成到pytest或CI/CD流水线里——每次发版自动在真机上跑一遍核心流程：

from artemis_client import ArtemisClient
client = ArtemisClient("http://localhost:8000")
result = await client.run("打开设置，进入电池页面，确认电量百分比正常显示")
assert result.succeeded

99.1%是什么水平

这是Google官方在AndroidWorld上自测的数据。AndroidWorld是Google Research做的Android Agent基准测试——116个多步骤任务，覆盖20个真实App（不是模拟的，是真App），任务参数随机生成，理论上能跑出无数种变体。

几个关键点：

• 这个数字是Google自己报的，不是第三方独立审计。项目里也写了"results on AndroidWorld are self-reported"

• 第二名FinalRun是97.4%，人类操作者约80%。也就是说在这个测试集上，AI已经超过了人类平均水平

• 但benchmark高不等于实战稳。测试集上的任务是结构化的，真实App的各种弹窗、权限请求、网络异常，比测试集复杂得多

真实评价：能打几分

优点：

• **Google亲儿子。**做这个的是Pixel测试工程团队，他们每天要测的就是真实Android设备，需求是真的，不是玩具项目

• **Apache 2.0协议。**可以商用，不像AGPL那样有传染性。企业用起来没法律负担

• **和AI编程工具打通。**MCP Server意味着你在Claude Code里写完代码，直接让手机跑一遍验证——这个闭环对开发者很有吸引力

• **分层定位策略务实。**不搞"一切都靠视觉模型"那种花哨方案，能用结构化数据就不用视觉推理

局限和坑：

• **只支持Android。**iOS完全不支持。苹果的自动化生态比安卓封闭得多，短期内别想

• **视觉搜索依赖Gemini。**第三层视觉推理要用Gemini Embodied Reasoning模型，这意味着你需要Google API权限。没有API key的话，视觉搜索功能用不了

• **项目很新。**2026年8月才创建，还没有正式release版本，API和功能可能频繁变动

• **需要本地环境。**要装ADB、scrcpy（开源安卓屏幕镜像工具）、FFmpeg、Python 3.12+，还要连真机或模拟器。不是开箱即用

• **99%是benchmark数字。**官方自己也说了，真实设备上的稳定性需要自己验证

适合谁，不适合谁

适合：

• Android测试团队，被Appium脚本维护成本搞到崩溃的人

• 用AI编程工具（Claude Code/Cursor）做Android开发的人——写完代码自动在真机验证

• 需要做大量回归测试的App团队——Flash模式跑起来很快

• 对AI Agent在移动端落地感兴趣的研究者

不适合：

• iOS开发者——不支持，别折腾

• 想要开箱即用、不想配环境的人——还得自己装ADB、连设备

• 没有Android真机或模拟器的人——没设备跑不起来

• 需要稳定生产级工具的团队——项目还在早期，API会变

---

ARTEMIS最有意思的地方，不是它能操作手机——操作手机这件事，Appium、UIAutomator早就做了。它真正的价值在于把"操作手机"这件事从"写脚本"变成了"说一句话"。

以前你要测一个流程，得学自动化框架、写定位代码、调试脚本。现在你只需要告诉AI你要测什么，它自己看屏幕、自己点、自己判断结果。这不是替代测试工程师——是把测试工程师从写脚本里解放出来，去设计更好的测试用例。

Google做这个项目还有一层意义：Android生态的自动化，以前被Appium这类框架把持了很多年，都是基于固定脚本。AI Agent来了之后，整个思路变了——不再是"预先写好每一步"，而是"给个目标，AI自己想办法"。

方向是对的，工具还年轻。可以关注，别急着上生产。

项目地址：github.com/google/artemis

转载自 CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/weixin_41007138/article/details/168453010