谷歌ARTEMIS：基于无障碍服务的AI手机自动化框架实战

1. 为什么我会盯上 ARTEMIS 这个项目移动端自动化这个领域说实话已经卷了很多年了。从最早的 Appium、UiAutomator到后来的 Airtest、SoloPi再到近两年冒出来的各种基于视觉大模型的自动化方案工具换了一茬又一茬但真正能让人眼前一亮、觉得这东西能改变工作方式的项目并不多。ARTEMIS 是我最近在翻开源项目的时候挖到的一个全称是 Android Real-Time Environment Manipulation and Interaction System由谷歌开源定位很明确——让 AI 助手像真人一样去操作手机。你可能会说操作手机这件事自动化测试框架不早就能干了吗Selenium、Playwright、pytest 那一套在 Web 端玩得飞起移动端也有 Appium 撑着。但 ARTEMIS 跟它们走的完全不是一条路。传统自动化框架依赖的是控件树、元素定位、坐标点击本质上是你告诉它点这个 ID 的按钮它去执行。而 ARTEMIS 的思路是给 AI 一个目标让它自己看着屏幕、理解界面、决定下一步点哪里、输入什么。这中间的差别就像是你给一个人一份详细到每一步的操作手册和给他一个任务让他自己看着办——后者才是真正的智能。我之所以对这个项目感兴趣是因为它踩中了一个很实际的痛点。现在做移动端 AI Agent 的人越来越多大家都想让 AI 帮忙点外卖、订机票、回消息、填表单但真到落地的时候发现最大的障碍不是模型不够聪明而是模型看不见手机屏幕、摸不到手机界面。ARTEMIS 解决的正是这个最后一公里的问题——它把手机屏幕变成 AI 能理解的输入把 AI 的决策变成手机能执行的动作。这篇文章适合几类人看一是做移动端自动化测试的想看看 AI 驱动的方案跟传统方案到底差在哪二是做 AI Agent 开发的需要给 Agent 接上手和眼三是对移动端 AI 应用感兴趣的产品和技术人员想了解这个方向现在能做到什么程度。我会从架构设计、核心原理、实操部署、常见坑几个维度把它拆开讲尽量让不同背景的人都能拿到能用的东西。2. ARTEMIS 到底是个什么东西2.1 一句话说清楚它的定位ARTEMIS 是一个运行在 Android 设备上的 AI 自动化框架它通过无障碍服务Accessibility Service获取屏幕上的界面信息把这些信息转换成结构化的数据喂给 AI 模型AI 模型输出操作指令后再由框架通过无障碍服务执行点击、滑动、输入等动作。整个闭环是感知—决策—执行跟人类操作手机的逻辑几乎一模一样。跟传统自动化框架最本质的区别在于传统框架是指令驱动你写死每一步操作ARTEMIS 是目标驱动你告诉它要达成什么它自己规划路径。这个区别决定了它的适用场景完全不同——前者适合回归测试这种流程固定的任务后者适合探索性任务、动态界面、以及需要理解界面含义的场景。2.2 核心组件拆解ARTEMIS 的架构可以分成四层我从下往上说。最底层是设备交互层基于 Android 的无障碍服务实现。无障碍服务是 Android 系统提供的一套 API允许应用读取屏幕内容并模拟用户操作。选它而不是 ADB 或者 root 方案原因很实际无障碍服务不需要 root 权限不需要连电脑可以在真机上独立运行而且能拿到比 ADB 更丰富的界面语义信息。代价是它拿不到某些游戏或者用了特殊渲染的界面的内容这个后面会细说。往上一层是界面解析层。这一层负责把无障碍服务拿到的原始节点树转换成 AI 能理解的格式。原始节点树信息量很大但很杂包含大量无意义的容器节点、装饰性元素。ARTEMIS 会做一轮过滤和简化提取出可交互元素、文本内容、位置关系然后序列化成结构化的描述。这一步的质量直接决定了 AI 能不能看懂屏幕。再往上是决策层也就是接 AI 模型的地方。ARTEMIS 本身不绑定特定模型它定义了一套输入输出的接口规范你可以接 GPT、Gemini、Claude也可以接本地部署的开源模型。输入是当前屏幕的结构化描述加上任务目标输出是下一步的动作指令。这种解耦设计很聪明模型迭代快框架不用跟着改。最上面是任务编排层负责任务的分解、多步执行的上下文管理、异常处理。比如帮我订一张明天去北京的机票这种任务需要拆成打开 App、搜索航班、选择日期、填写乘客信息、支付等多个步骤每一步的执行结果都要反馈给模型做下一步决策。2.3 跟同类方案的对比市面上做移动端 AI 自动化的方案不少我挑几个有代表性的对比一下。方案感知方式决策方式是否需 root适用场景ARTEMIS无障碍服务AI 模型否通用 AI AgentAppium控件树/坐标脚本写死否回归测试Airtest图像识别脚本写死否游戏测试纯视觉方案截屏CVAI 模型否通用但精度低ADB 脚本坐标脚本写死否简单批量操作ARTEMIS 的差异化在于它同时做到了AI 决策和结构化感知。纯视觉方案虽然也能接 AI但截屏做 OCR 再理解信息损失大、延迟高、精度差。无障碍服务拿到的节点树是系统级的语义信息比像素级识别靠谱得多。这也是谷歌做这个项目的底气——它掌握 Android 系统底层知道怎么把无障碍服务的能力榨干。3. 核心原理深挖AI 是怎么看懂手机屏幕的3.1 无障碍服务到底能拿到什么很多人对无障碍服务的理解停留在能模拟点击其实它能拿到的信息远比想象中多。当你开启一个无障碍服务后系统会把当前窗口的节点树实时推送给服务。这棵树里每个节点包含这些关键属性text节点显示的文本比如按钮上的确认、输入框里的提示语contentDescription无障碍描述很多图标按钮没有文字但有这个className控件类型比如 Button、EditText、ImageViewboundsInScreen节点在屏幕上的坐标范围四个值分别是左上右下clickable / scrollable / editable是否可点击、可滚动、可编辑isEnabled / isVisibleToUser是否可用、是否对用户可见viewIdResourceName资源 ID开发时定义的稳定性最高这些属性组合起来就构成了 AI 理解界面的基础。举个例子屏幕上有个立即购买按钮节点树里会有一个 clickabletrue、text立即购买、boundsInScreen[540,1800,900,1920] 的节点。AI 看到这个描述就知道屏幕下方有个可以点的购买按钮位置在屏幕中下部。3.2 界面信息的结构化处理原始节点树直接丢给 AI 是不行的原因有三个一是节点太多一个复杂页面动辄几百个节点全塞进去 token 直接爆二是噪音太多大量布局容器、装饰元素没有实际意义三是层级太深AI 很难从嵌套结构里快速定位关键信息。ARTEMIS 的处理策略我拆解了一下大致是这么几步第一步是可见性过滤。把 isVisibleToUserfalse 的节点全部剔除这些是屏幕上看不到的对操作没意义。第二步是交互性优先。优先保留 clickable、scrollable、editable、checkable 这些有交互能力的节点以及有 text 或 contentDescription 的节点。纯装饰性的 ImageView、无内容的 FrameLayout 会被过滤掉。第三步是扁平化重组。把树形结构压平成列表每个元素带上它的位置信息。这样 AI 看到的就是一个线性的元素清单而不是需要递归遍历的树。第四步是语义标注。给每个元素打上类型标签比如按钮输入框文本列表项让 AI 更容易理解元素的用途。处理完之后一个页面的描述大概长这样[1] 按钮 返回 位置(50,100,150,200) [2] 文本 商品详情 位置(400,100,700,200) [3] 图片 商品主图 位置(100,250,900,850) [4] 文本 ¥299.00 位置(100,900,500,980) [5] 按钮 加入购物车 位置(100,1800,450,1900) [6] 按钮 立即购买 位置(550,1800,900,1900)这种格式 AI 理解起来毫无压力而且 token 消耗可控。3.3 决策循环是怎么跑起来的ARTEMIS 的执行循环是一个标准的 ReAct 模式——推理加行动。每一轮循环包含这几个步骤感知抓取当前屏幕的节点树结构化成上面的格式推理把屏幕描述、任务目标、历史操作记录一起发给 AI 模型让模型决定下一步行动解析模型输出的动作指令通过无障碍服务执行观察等待界面响应抓取新屏幕判断任务是否完成或需要继续这个循环的关键在于历史上下文的管理。如果每一轮都把完整历史塞给模型token 会迅速膨胀。ARTEMIS 的做法是保留最近若干轮的操作记录加上一个任务进度的摘要既保证模型知道我做到哪了又控制住上下文长度。还有一个细节是动作空间的设计。模型能输出的动作是有限的几种点击某个元素、在某个输入框输入文本、滑动、返回、等待、任务完成。动作空间越小模型越不容易输出无效指令。ARTEMIS 把动作定义得很克制这是工程上的成熟表现。3.4 为什么用无障碍服务而不是截屏这个问题值得单独说因为它是 ARTEMIS 技术选型的核心。截屏方案的优势是通用——不管什么界面截下来做图像识别就行游戏、视频、特殊渲染的界面都能处理。但劣势也很明显OCR 识别有误差图像理解延迟高而且像素级信息对 AI 来说理解成本高。你让模型看一张截图它得先识别出哪里是按钮、哪里是文字再决定点哪中间每一步都可能出错。无障碍服务的优势是精准——它直接拿到系统级的语义信息按钮就是按钮文本就是文本坐标是精确的不需要识别。劣势是覆盖不全某些用了自绘控件、WebView 内嵌、游戏引擎渲染的界面无障碍服务拿不到有效节点。ARTEMIS 选了无障碍服务为主但据我了解它保留了扩展视觉能力的接口。这个取舍很务实先把 80% 的常规 App 场景做好特殊场景再想办法补。对于绝大多数日常 App 操作任务无障碍服务的信息质量是碾压截屏方案的。4. 实操部署从零把 ARTEMIS 跑起来4.1 环境准备清单在动手之前先把需要的东西列清楚免得中途卡壳。一台 Android 手机建议 Android 8.0 以上真机优先模拟器也可以但无障碍服务在模拟器上偶尔有兼容问题Android Studio用来编译和安装 ARTEMIS 的 APK版本建议用较新的稳定版Git拉取源码一个 AI 模型的 API KeyGemini、GPT 都行看你的网络和预算情况数据线用来首次安装和调试装好之后可以拔掉独立运行这里有个坑要提前说ARTEMIS 依赖无障碍服务而不同厂商的 ROM 对无障碍服务的限制不一样。小米、华为、OPPO 这些国产 ROM 为了省电会主动杀后台服务需要手动在设置里给 ARTEMIS 加白名单关闭电池优化。这个后面会详细讲。4.2 拉取源码与编译从谷歌的官方仓库拉代码命令很直接git clone https://github.com/google-research/artemis.git cd artemis拉下来之后用 Android Studio 打开项目根目录等 Gradle 同步完成。同步过程中可能会遇到依赖下载慢的问题可以在项目的 build.gradle 里配置国内镜像源或者挂个代理这里说的是开发环境的网络代理不是别的别想歪。同步完成后连接手机确保开发者选项和 USB 调试都打开了然后点运行按钮Android Studio 会自动编译并安装到手机上。首次安装后打开 App它会引导你开启无障碍服务。4.3 配置无障碍服务的关键步骤这一步是整个部署里最容易出问题的环节我详细说。打开 ARTEMIS App 后它会提示你跳转到系统设置的无障碍页面。路径一般是设置 → 无障碍 → 已安装的服务 → 找到 ARTEMIS → 打开开关。打开时会弹一个权限确认框告诉你这个服务能读取屏幕内容、能模拟操作点同意。打开之后回到 ARTEMIS它应该显示服务已连接。如果显示未连接检查这几个地方无障碍服务开关是不是真的打开了有些 ROM 打开后会自动关闭ARTEMIS 有没有被系统限制后台运行有没有其他无障碍服务冲突比如某些输入法、悬浮球工具我实测下来小米的 MIUI 和华为的 EMUI 最容易出问题。MIUI 需要在设置 → 应用设置 → ARTEMIS → 省电策略里改成无限制还要在设置 → 应用设置 → ARTEMIS → 权限管理 → 后台弹出界面里允许。EMUI 类似需要在电池优化里把 ARTEMIS 排除。4.4 接入 AI 模型ARTEMIS 的模型接入是通过配置文件或者 App 内的设置界面完成的。你需要填的是模型类型、API 地址、API Key、模型名称这几个参数。以 Gemini 为例配置大概是这样{ model_provider: gemini, api_key: 你的API Key, model_name: gemini-pro-vision, max_tokens: 2048, temperature: 0.1 }temperature 设成 0.1 是有讲究的。自动化任务需要的是稳定和确定不需要模型发挥创造力。温度越低模型输出越保守越一致同样的界面每次决策结果基本一样这对自动化任务至关重要。你要是设成 0.8模型可能这次点左边下次点右边任务就没法稳定复现了。max_tokens 设 2048 是因为动作指令本身很短不需要太长的输出设太大反而浪费。但如果你的任务描述很复杂可以适当调大。4.5 跑第一个任务配置好之后就可以试跑一个简单任务了。在 ARTEMIS 的输入框里输入任务描述比如打开设置找到关于手机读出系统版本号然后点执行。你会看到 ARTEMIS 开始工作它先抓取当前屏幕发给模型模型返回点击设置图标ARTEMIS 执行点击然后抓取新屏幕再发给模型模型返回向下滑动找到关于手机如此循环直到任务完成。第一次跑的时候建议盯着屏幕看观察它的决策过程。如果发现它点错了地方可以中断任务检查是界面解析的问题还是模型理解的问题。这个调试过程是必须的跑通几个任务之后你就对它的能力边界有感觉了。5. 实操中的坑与排查技巧5.1 无障碍服务被系统杀掉这是最高频的问题没有之一。表现是任务跑到一半突然卡住或者 ARTEMIS 显示服务断开。根本原因是 Android 的后台管理机制。无障碍服务虽然优先级比普通后台服务高但在内存紧张或者厂商激进省电策略下还是会被杀。解决办法分两层系统层面把 ARTEMIS 加入电池优化白名单允许后台活动允许自启动。不同 ROM 路径不一样但核心就是找到电池后台管理自启动这几个设置项把 ARTEMIS 设成不受限制。应用层面ARTEMIS 本身应该实现前台服务显示一个常驻通知这样系统杀它的概率会低很多。如果你在用的是早期版本没有这个机制可以考虑用 adb 命令把它的 oom_adj 值调低提高优先级adb shell am set-inactive com.artemis.app false adb shell dumpsys deviceidle whitelist com.artemis.app这两条命令一条是标记应用为活跃一条是加入 Doze 模式白名单实测能明显降低被杀概率。5.2 界面解析拿不到元素有时候你会发现 ARTEMIS 明明在某个页面上但解析出来的元素列表是空的或者缺了关键元素。常见原因有这么几个。一是页面用了 WebView网页内容在无障碍节点树里可能只显示为一个 WebView 容器里面的内容拿不到。这种情况需要开启 WebView 的无障碍支持或者退而求其次用坐标点击。二是页面用了自绘控件比如游戏、某些定制 UI这些控件不暴露无障碍信息。三是页面还在加载中节点树还没构建完抓早了。排查方法很简单用 Android Studio 自带的 Layout Inspector或者装一个无障碍调试工具实时看节点树。对比 ARTEMIS 解析出来的结果就能定位是哪个环节丢了信息。5.3 模型决策不稳定同一个任务跑十次有三次失败这种不稳定最让人头疼。先排查是不是温度参数的问题前面说了设 0.1。如果已经很低了还不稳定那大概率是界面描述的信息不够模型在猜。这时候要优化界面解析把更多有用的信息喂给模型比如把元素的相对位置关系描述清楚把相似元素的区分特征标出来。还有一个技巧是给模型加约束。在 prompt 里明确告诉它只能点击列表里存在的元素编号如果找不到目标元素就返回等待或者滑动减少它自由发挥的空间。模型越自由越容易出错。5.4 输入中文乱码在输入框里输入中文时偶尔会遇到乱码或者输入不进去的情况。这是无障碍服务输入文本的一个已知限制某些输入法或者某些 App 的输入框对无障碍输入支持不好。绕过方法是改用剪贴板方案先把文本写到剪贴板然后模拟粘贴操作。ARTEMIS 如果没内置这个能力可以自己扩展一个动作类型。或者用 adb 的 input text 命令但那个对中文支持也一般需要先做编码转换。5.5 常见问题速查表问题现象可能原因排查方向解决手段服务频繁断开系统省电杀后台查电池优化设置加白名单、前台服务元素列表为空WebView/自绘控件Layout Inspector 看节点树换坐标方案或开 WebView 无障碍决策不稳定温度高/信息不足查模型参数和界面描述降温、补充元素特征中文输入失败输入法兼容性换输入法测试剪贴板粘贴方案点击无响应坐标偏移/元素遮挡对比实际坐标校准坐标、处理弹窗任务死循环模型陷入重复决策看历史操作记录加最大步数限制、人工干预6. 这套东西能用在哪些场景6.1 移动端自动化测试的新思路传统自动化测试写用例一个页面改版定位器全失效维护成本极高。用 ARTEMIS 这种 AI 驱动的方案用例可以写成验证登录流程能走通这种目标描述界面小改版不影响因为 AI 是看着界面找元素的不是靠写死的 ID。当然这不意味着传统框架就没用了。回归测试要求的是稳定、快速、可重复AI 方案在这三点上都不如脚本方案。但探索性测试、兼容性测试、新功能冒烟测试这些场景AI 方案的优势就体现出来了——你不需要为每个页面写脚本给个目标它自己跑。6.2 个人效率工具我自己试过用它做一些重复性的手机操作比如批量整理相册、定时签到、自动填写表单。这些事情单次做不费劲但天天做就很烦。用 ARTEMIS 写个任务描述让它自己跑省下来的时间很可观。不过要提醒一句用它做自动化操作要遵守各个 App 的用户协议别用来做刷量、薅羊毛这类事情容易封号也不道德。6.3 AI Agent 的能力扩展做 AI Agent 的人都知道Agent 要真正有用必须能操作真实世界的工具。手机是现代人最重要的工具之一让 Agent 能操作手机等于给它开了很大一扇门。ARTEMIS 提供的正是这个能力你可以把它当成 Agent 的一个手机操作技能Agent 负责高层规划ARTEMIS 负责底层执行。这个方向我觉得是 ARTEMIS 最有想象力的地方。现在大模型的能力已经足够理解界面和规划操作了缺的就是一个稳定可靠的执行层。ARTEMIS 补上了这块。6.4 无障碍辅助这个场景可能很多人没想到。ARTEMIS 基于无障碍服务天然就能服务于视障用户。视障用户操作手机本来就依赖无障碍服务如果再加上 AI 的理解和决策能力可以做到用户说一句话AI 帮忙完成操作这对无障碍体验是质的提升。谷歌做这个项目我猜无障碍辅助也是考量之一。毕竟无障碍服务这套 API 的初衷就是为无障碍设计的用它来做 AI 自动化算是副业但反过来用 AI 增强无障碍体验是很有社会价值的方向。7. 我对这个项目的一些判断ARTEMIS 现在还在早期阶段代码不算特别成熟文档也偏简略很多地方需要自己摸索。但它的方向是对的技术选型是务实的架构设计是留了扩展空间的。谷歌开源这个项目我理解是想推动移动端 AI Agent 这个方向的基础设施建设让更多人能基于它做应用而不是每个人都从零造轮子。从实际使用体验看它在常规 App 上的表现已经可用了复杂界面和特殊场景还需要打磨。如果你现在就想用它做生产级的东西建议做好异常处理和人工兜底别指望它 100% 可靠。但如果你是想研究移动端 AI 自动化的技术方案或者想给自己的 Agent 加个手机操作能力这个项目值得花时间研究。我踩过的坑基本都在上面写了核心就一句话无障碍服务是这套方案的命脉把它的稳定性和信息质量搞定了后面的事情就顺了。模型选择反而是次要的现在主流模型的理解能力都够用关键是你喂给它的信息质量。后续我打算再研究一下它的多设备协同和任务编排部分那块代码还没细看。如果有什么新发现再单独写一篇。