谷歌ARTEMIS：大模型驱动的移动端AI自动化框架详解与实战

如果你最近在刷 AI Agent 方向的内容，ARTEMIS 这个名字应该早就不陌生了。谷歌开源的移动端 AI 自动化框架，主打让 AI 助手像人一样操作手机。我把它从仓库里拉下来、跑通、又折腾了几个小任务之后，最大的感受是：这玩意的思路和传统自动化测试完全不是一回事。它不是在给你写脚本，而是在让模型自己“看屏幕 → 想下一步 → 点哪里”。这篇我把从原理到上手的实操过程完整记下来，适合移动端测试工程师、AI 应用开发者、Agent 方向研究者，以及任何好奇“AI 怎么替我按手机”的人。

1. ARTEMIS 到底在解决什么问题

1.1 一句话理解这个项目

ARTEMIS 不是一个普通的 UI 测试框架。它把手机截图喂给多模态大模型，让模型理解当前屏幕上有什么、元素在哪个位置、该执行什么操作，然后把点击、滚动、输入这类动作下发到设备上。整个过程不需要预先编译 UIAutomator 脚本，也不用写死 XML 路径。

我当时的直观类比是：你雇了一个远程助理，助理面前有台手机。他看不到 UI 层级树，只能通过截屏看屏幕。你说“帮我把字体调大一点”，他就会打开设置，翻页，找到字体选项，点进去，调完再退出来。ARTEMIS 就是这个助理的“眼睛加手”。

仓库地址是 github.com/google/artemis，属于谷歌“Made with Gemini”系列开源研究项目。与同类方案相比，它的独特之处不在模型本身，而是围绕“像人一样看屏幕”设计的一整套动作原语与训练方案。

1.2 它能做什么，不能做什么

先说说能做的。ARTEMIS 可以完成那种“多步骤、跨界面”的手机任务。比如打开一个应用，进入设置页，改一个选项，返回主界面；或者在浏览器里搜索某个关键词，再点开第一条结果。任务描述直接用自然语言给，不需要拆步骤。

我自己实测跑通过“帮忙在通讯录里找到联系人并打开详情”这类任务，模型会自己判断先点哪个 tab、滑到哪个位置、再点击哪一行。这些步骤如果你用 Appium 写脚本，光是定位元素就要花好一会儿。

不能做的也很明显：它不适合像素级还原的高强度回归测试；对中文输入法的适配也有点粗糙；如果设备处于锁屏、系统弹窗、权限申请这类硬交互场景，模型偶尔会发呆。它不是“万能测试工人”，更像是一个可以做技术预演的 Agent 原型。

2. ARTEMIS 与传统自动化方案的差异：模型凭什么知道点哪里

2.1 传统框架最大的坑：UI 层级树不是万能的

做移动端自动化的朋友应该都体会过：Appium 也好、UIAutomator 也好，核心都依赖 UI 层级树（View Hierarchy）。这个 XML 里描述了每个控件的类型、文本、坐标，脚本只要按路径或者 xpath 去匹配就行。

问题在于，很多场景下这套玩法直接失效。Flutter 自绘引擎渲染出的部分控件在原生层级里就是一整块 Canvas；WebView 内部的 DOM 结构原生层根本透不出来；游戏、直播、视频类应用更是全程 OpenGL 绘制。你拿 UIAutomator 去 dump 层级，要么拿到一堆<android.view.View>的空壳，要么直接超时。

我之前维护一个 Flutter 应用的用例时，最怕的就是界面改版。UI 组件一换，所有resource-id全废，脚本光修定位就要一个下午。这种痛苦经历让我一看到 ARTEMIS “不做 UI hierarchy 解析”的设计，立刻产生了兴趣。

2.2 ARTEMIS 的感知方案：直接看屏幕像素

ARTEMIS 采用的方案是视觉主导。它把整块屏幕截图交给模型，直接输出语义描述和坐标，而不是解析底层结构。这等于把问题从“读取一棵树”改成“看懂一张图”。

这么做有几个实际好处。第一，不依赖平台差异，Android、iOS、甚至车机系统，只要你能截屏、能注入触摸事件，理论上都能适配。第二，对于 Flutter、游戏、WebView 这种无法访问原生控件的场景，反而成了它的主场，因为模型看到的是渲染后的画面，画面是什么它就是什么。第三，不需要动态更新控件树，减少了测试框架本身的维护成本。

当然，代价也有：模型要足够聪明。如果大模型看不懂复杂的图标和布局，一切白搭。这也是为什么 ARTEMIS 没有简单拿通用模型直接零样本推理，而是专门训练了 M0/M1/M2 系列模型，后面我会详细说。

2.3 比较适合的场景和暂时不适用的场景

结合我自己试用经验，ARTEMIS 比较适合这么几类场景：

• 技术预研：验证大模型在真实设备上的 GUI 交互能力。
• 自动化探索测试：让它自己跑一遍主要流程，看是否有异常。
• 跨应用 Agent 任务：比如“打开地图找到最近的咖啡店，然后复制地址到备忘录”。
• 原型验证：产品设计未定时，让模型按自然语言走通主流程。

暂时不合适的场景包括：高并发的稳定性回归、需要断言像素级 UI 是否一致、以及需要精准操作特定第三方控件的场景。当然，如果你打算拿它做 RPA 类“外挂”，也要考虑合规风险，自己把握好度。

3. 核心原理拆解：YaTA 方法、动作原语与 M0/M1/M2 模型

3.1 YaTA 方法：不再是“读元素”，而是“你就在那儿”

ARTEMIS 的关键技术叫 YaTA，全称 You Are There，意思是让模型“真的身处屏幕之前”。听起来玄乎，其实流程特别清晰。

第一步，模型先看整屏截图，输出一个 landmark 和一段描述。Landmark 表示“我大概是盯着屏幕的这个位置”，描述是“这里是一个搜索框”。

第二步，调用 zoom 动作，把该位置为中心的局部区域裁剪放大。因为整屏截图缩放到模型输入分辨率后，很多小图标根本看不清，zoom 相当于给模型递上一个放大镜。

第三步，模型再观察放大后的裁剪图，输出一个带有语义目标的动作，比如tap("搜索框")或者scroll("列表", 向下)。

第四步，执行这个动作，屏幕发生变化后，重新回到第一步，继续循环，直到任务完成。

为什么要设计成两步而不是直接让模型点击坐标？核心原因是高分辨率下的感知精度。如果把整张 1080×2400 的截图直接压到 448×448，一个小 icon 可能只剩几个像素，模型很难分辨它是“齿轮”还是“放大镜”。先定位再裁剪，相当于先用广角看全局，再用微距看细节，准确率能拉开明显差距。

3.2 五个核心动作原语：screen、zoom、number、scroll 与点击

ARTEMIS 的动作空间非常有特点，每个都对应一个真实世界里的操作习惯。

• screen：获取当前屏幕的全屏截图。每次环境状态变化后都要重新截屏，让模型看到最新画面。
• zoom：围绕指定 landmark 坐标截取局部放大图。它不真正改变界面，只改变模型的“注意力”。
• number：这是最惊艳的一个原语。模型可以对屏幕上的元素统一标号，比如“第一项、第二项、第三项”，随后通过编号直接指定目标。这样做可以避免模型绞尽脑汁去描述元素语义，减少幻觉。
• scroll：在屏幕特定区域模拟滑动。因为手机界面是长列表，模型需要滚动来“翻页”。
• 点击与输入：tap 负责最基本的交互，type 负责输入文本。

这套原语组合起来非常接近人类操作手机的方式：先看全貌，聚焦局部，给元素编号，再决定点击还是滑动。相比让模型直接输出像素坐标，它有更强的容错性和可解释性。

3.3 M0、M1、M2 三档模型到底是什么关系

Artemis 在推理模型上不是单打独斗，而是按照能力分了三档：

• M0：基础版本，相当于一个通用的多模态底座，具备对话能力，但还没有针对屏幕操作做专业化训练。
• M1：把 YaTA 训练数据灌进去之后的结果。经过后训练，模型学会了“看截屏 → 输出 landmark → 缩放查看 → 输出操作”这套思维链。
• M2：在 M1 基础上加入了提示集成。简单说就是通过多种 Prompt 策略让模型更好地拆解任务，比如让它先列出当前屏幕上的候选元素，再决定点击哪一个，推理稳定性比 M1 更强。

我自己实际用下来，跑 demo 时首选 M2，效果明显稳定。M0 基本只能做文本问答，不建议直接用于设备操作。

3.4 AITZ 数据格式与任务生成

光有模型结构还不够，AI Agent 最怕缺数据。Artemis 提出了 AITZ 格式（AI Task Zoo），专门用来描述移动端 GUI 自动化任务。

一个 AITZ 样本里包含当前屏幕截图、任务提示文本、可选的 UI 层级信息、历史动作序列，以及动作标注。这些样本来自 700 多个真实访问过的网络任务，涵盖了各种现代 UI 模式，比如登录表单、商品列表、图片轮播、订阅弹窗。

为了防滥用，原数据集的安全过滤很严格，并没有直接把所有原始样本一股脑扔出来，但仓库里给了完整的生成管道和示例格式。如果你想构造自己的移动端 Agent 训练集，AITZ 的 schema 完全可以直接参考。

4. 动手跑通：环境准备、安装与首次任务实录

4.1 环境要求与预备检查

先看清楚自己手里的条件，满足这些再动手，省得浪费时间。

• 操作系统：建议 macOS 或 Linux，Windows 需要额外折腾 ADB 和设备连接，理论上能跑但坑更多。
• Python 版本：3.10 或更高。
• Android 设备：真机或者模拟器都行。真机需要开启开发者选项并允许 USB 调试，同时保证adb devices能看到设备。
• 内存：本地加载模型推理建议 16GB 以上。8GB 能跑但非常吃力，尤其模型第一次加载时内存直接飙升。
• 模型权重：M2 模型体量不小，下载是个体力活，耐心等。

我自己的环境是 Ubuntu 22.04 加一台 Pixel 模拟器，跑通整个流程大概折腾了一个下午。第一次主要是下载各种依赖，之后重新运行就快了。

4.2 安装与启动

拉仓库，装依赖，这些操作比较常规：

git clone https://github.com/google/artemis.git cd artemis pip install -r requirements.txt

接下来需要确认 ADB 已经连上设备。执行adb devices能看到设备序列号和device状态，如果没有，先检查 USB 调试授权弹窗是否允许，或者重启 adb server。

连接之后，可以跑仓库里的 demo 脚本。官方给了两种交互方式，一种是 notebook 逐格运行，适合学习和观察中间过程；另一种是 Gradio 界面，把截图和推理过程都可视化了，我强烈推荐直接用 Gradio。启动后会在本地开一个网页端口，你可以在输入框里填中文或英文的任务描述，模型就会在真机上一步步执行。

python demo_artemis.py

启动过程中模型会加载权重，耗时根据机器配置从几十秒到几分钟不等。看到输出中出现设备截图和动作日志，就说明跑通了。

4.3 第一次让 AI 操作手机：实测过程记录

我布置的第一个任务是：“打开设置，把屏幕亮度调到中间”。想看看模型能不能自主完成这种多级操作。

执行开始后，模型首先对整屏截图调用了 screen，识别出这是主屏。接着它没有急着滑页面，而是先输出一个 landmark，预测“设置”图标大概在屏幕右上角。随后调用 zoom 放大该区域，确认那确实是设置图标，最后执行点击。

进入设置界面后，模型在列表面板上滑动了一次，找到“显示与亮度”这一项，点击进去，再找到亮度滑块。这里最让我意外的是 number 原语的使用：模型把亮度调节区域识别为若干可交互项，给滑块标记为“第 2 个元素”，然后执行了拖动操作。

整个过程大约花了 20 秒，比人慢，但胜在完全没人为干预。我中途故意切到别的应用，再切回来，任务状态没有丢，这一点做得很稳。

5. 常见问题排查与避坑指南

5.1 我踩过的三个坑

坑一：ADB 权限异常，任务卡在第一步

第一次跑 demo 时，设备始终没状态，后来才发现手机上的“允许 USB 调试”弹窗被误点了拒绝。解决方法很直接：拔掉数据线重插，或者在手机上撤销 USB 调试授权后重新授权。另外注意adb kill-server && adb start-server是个好东西，遇到奇怪连接问题先重启一下服务。

坑二：模型输出的动作格式偶尔不合法

模型毕竟是概率输出，偶尔会生成一个动作空间里不存在的命令，或者输出 landmark 但坐标明显异常。这种情况多半不是环境问题，而是模型没看清屏幕。解决办法是给模型多一点上下文，比如先手动触发一次 screen 和 zoom 操作，让它重新看清页面，再继续执行任务。

坑三：中文输入支持不完善

ARTEMIS 的交互数据以英文为主，我在任务里让模型输入“你好”时，模型确实也执行了输入动作，但系统键盘和输入法兼容性不佳，最终结果不理想。如果要做中文场景测试，即便最终目标是中文应用界面，也建议用英文描述任务，识别成功率会高不少。

5.2 问题速查表

5.3 实操后的一点个人经验

连续跑了几十次任务之后，我对这种“视觉操作手机”的框架有了一个更深的认识。查看结果的时候，别只关注最后一步对不对，中间所有 landmark、zoom、action 日志都值得看一遍。你会发现模型几乎每次点击前都会先放大目标区域，这是它能保持高准确率的重要原因。

调试复杂任务时，尽量把任务描述拆细一点，但不要拆到每一步都告诉它怎么做。比如“打开设置，把亮度调低到大约 40%”比“打开设置，点击显示与亮度，拖拽滑块”稳定性更好。后者如果界面顺序稍有不同，模型反而容易懵。

本地复现时不要贪图一步到位，先跑两个最简单动作（打开应用、回主屏），确认模型能持续输出正确动作后再上复杂场景，这样排错成本会低很多。我在模拟器上开始跑复杂任务时踩坑最多，换成真机后坐标精度和稳定性明显改善。如果条件允许，用真机做验证真的会省心不少。