如果你最近在刷 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 自绘引擎渲染出的部分控件在原生层级里就是一整块 CanvasWebView 内部的 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 或 LinuxWindows 需要额外折腾 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 问题速查表问题现象可能原因快速处理adb devices 看不到设备未授权 USB 调试 / 驱动缺失重新插拔、授权弹窗点允许重启 adb server模型加载很慢或内存不足权重过大 / 内存不够关闭其他进程换 M1 小模型或扩展 swap 空间任务执行到一半停住不动作界面被弹窗遮挡 / 状态切换丢失手动截屏确认当前界面必要时重新下发任务点击位置偏差较大屏幕缩放导致坐标偏移用真机而非模拟器或尝试将模拟器设为标准分辨率中文文本输入失败输入法兼容性问题调整输入法设置或切换为英文任务描述demo 启动后界面空白Gradio 端口占用 / 依赖缺失看日志定位报错缺包就额外 pip 安装对应依赖5.3 实操后的一点个人经验连续跑了几十次任务之后我对这种“视觉操作手机”的框架有了一个更深的认识。查看结果的时候别只关注最后一步对不对中间所有 landmark、zoom、action 日志都值得看一遍。你会发现模型几乎每次点击前都会先放大目标区域这是它能保持高准确率的重要原因。调试复杂任务时尽量把任务描述拆细一点但不要拆到每一步都告诉它怎么做。比如“打开设置把亮度调低到大约 40%”比“打开设置点击显示与亮度拖拽滑块”稳定性更好。后者如果界面顺序稍有不同模型反而容易懵。本地复现时不要贪图一步到位先跑两个最简单动作打开应用、回主屏确认模型能持续输出正确动作后再上复杂场景这样排错成本会低很多。我在模拟器上开始跑复杂任务时踩坑最多换成真机后坐标精度和稳定性明显改善。如果条件允许用真机做验证真的会省心不少。