ARTEMIS：基于无障碍服务与大模型的移动端AI自动化框架解析

1. 移动端 AI 自动化的核心命题1.1 为什么手机上的 AI 助手一直“不好用”过去两年大模型在 PC 端的落地速度远超移动端。你在电脑上可以让 AI 帮你写代码、整理文档、操作浏览器但一到手机上AI 能做的事情就急剧缩水——要么只能聊天要么只能完成非常窄的特定任务。根本原因在于移动端缺少一个通用的、能真正“看见屏幕、理解界面、执行操作”的自动化框架。手机上的 App 是高度封闭的。每个 App 的界面结构不同、控件命名不同、交互逻辑不同传统的 UI 自动化方案比如基于控件 ID 的脚本需要针对每个 App 单独适配维护成本极高。而大模型虽然能理解自然语言但它“看不见”手机屏幕也没有“手”去点击、滑动、输入。ARTEMIS 要解决的就是这个断层——让 AI 助手像人一样操作手机。这个定位非常关键。它不是又一个 RPA 工具也不是一个简单的脚本录制器而是一个把“视觉理解 任务规划 动作执行”串起来的框架。你可以把它理解成给 AI 装上了一双眼睛和一只手让它能在真实的 Android 设备上完成多步骤的复杂任务。1.2 ARTEMIS 到底做了什么ARTEMIS 是谷歌开源的一个移动端 AI 自动化框架核心能力可以拆成三层感知层通过 Android 的无障碍服务Accessibility Service实时获取当前屏幕的界面结构包括控件树、文本内容、控件坐标、可点击状态等。这相当于给 AI 提供了一份“屏幕的语义地图”。决策层把界面信息和用户的任务指令一起交给大模型由模型决定下一步该点哪里、输入什么、滑动多少距离。模型输出的是结构化的动作指令而不是自由文本。执行层把模型输出的动作指令翻译成 Android 系统能执行的底层操作比如点击某个坐标、在某个输入框里填入文本、执行返回或滑动。这三层串起来就形成了一个闭环看屏幕 → 想下一步 → 执行 → 再看屏幕 → 继续。这个循环听起来简单但工程上的坑非常多后面我会逐个拆解。1.3 适合谁来研究这个项目如果你属于以下几类人ARTEMIS 值得你花时间深入Android 开发者想给自己的 App 加上 AI 自动化能力或者想理解无障碍服务在自动化场景下的极限在哪里。AI 应用开发者手里有大模型 API想把它接到移动端做 Agent但不知道怎么解决“模型看不见屏幕”的问题。测试工程师受够了写 UI 自动化脚本时反复适配控件 ID 的痛苦想看看用视觉大模型能不能降低维护成本。自动化爱好者想做一些跨 App 的自动化流程比如自动整理通知、自动填写表单、自动执行重复性操作。需要说明的是ARTEMIS 目前还是一个偏框架层面的开源项目不是开箱即用的成品 App。你需要有一定的 Android 开发基础能跑通编译、能理解无障碍服务的机制才能真正把它用起来。2. 框架整体设计与技术选型拆解2.1 为什么选无障碍服务而不是 ADB 或投屏方案移动端自动化的技术路线有好几条ARTEMIS 选了无障碍服务这条背后有明确的取舍。ADB 方案通过adb shell input tap之类的命令最大的问题是需要连接电脑而且获取屏幕信息要靠截图图像识别延迟高、精度差。你没法在手机上独立运行一个 ADB 驱动的自动化流程。投屏方案比如 scrcpy 类的思路是把手机画面传到另一个设备上操作本质上还是远程控制不适合做端侧 Agent。无障碍服务的优势在于它是 Android 系统原生提供的、运行在设备本地的能力。开启之后你的应用可以实时读取当前界面的控件树可以模拟点击、滑动、文本输入而且不需要 root、不需要连接电脑。对于“让 AI 像人一样操作手机”这个目标来说无障碍服务是唯一能在端侧闭环的方案。但无障碍服务也有它的边界。比如某些 App 会主动屏蔽无障碍服务读取敏感界面比如支付密码输入页某些游戏或自绘 UI 的控件树几乎是空的只能靠坐标点击。ARTEMIS 在设计上需要对这些情况做兜底处理。2.2 界面信息怎么喂给大模型这是整个框架里最考验工程能力的一环。你不能把整个控件树原封不动地丢给模型——一个复杂页面可能有几百个节点token 消耗巨大而且大量信息是噪音。ARTEMIS 的做法是对控件树做裁剪和结构化。常见的处理逻辑包括只保留可交互节点可点击、可输入、可滚动和有文本内容的节点。把节点的层级关系压平成带缩进的列表而不是保留完整的树形结构。给每个节点分配一个临时 ID方便模型在输出动作时引用。把坐标信息归一化避免不同分辨率设备之间的差异。这样处理后一个页面的描述通常能压缩到几百个 token 以内模型理解起来也更聚焦。这个思路和 PC 端浏览器自动化里把 DOM 简化后喂给模型是一样的道理。2.3 动作空间的设计模型不能输出“点击那个蓝色的按钮”这种模糊指令它必须输出框架能精确执行的动作。ARTEMIS 定义的动作空间通常包括动作类型参数说明clicknode_id 或坐标点击指定节点或坐标inputnode_id, text在指定输入框填入文本scrolldirection, distance按方向滑动指定距离back无执行系统返回home无回到桌面waitmilliseconds等待界面刷新done无任务完成动作空间的设计直接决定了模型能做什么、不能做什么。动作太少复杂任务没法完成动作太多模型容易选错。ARTEMIS 选择了一个相对精简的集合把复杂操作拆解成基本动作的组合这样模型的决策难度更低框架的执行逻辑也更清晰。2.4 任务循环与状态管理一次完整的自动化任务不是“看一眼、点一下”就结束的而是一个多轮循环。ARTEMIS 的任务循环大致是这样的获取当前屏幕的界面描述。把界面描述、任务目标、历史动作记录一起构造 prompt。调用大模型获取下一步动作。执行动作。等待界面稳定。判断任务是否完成未完成则回到第 1 步。这里有几个容易出问题的地方界面稳定的判断点完之后页面可能还在加载、历史动作的压缩轮次多了之后 prompt 会超长、死循环的检测模型可能反复点同一个地方。这些都需要在框架层面做处理不能完全指望模型自己收敛。3. 核心细节解析与实操要点3.1 无障碍服务的配置与权限申请无障碍服务不是普通权限用户必须手动在系统设置里开启。你的应用需要在AndroidManifest.xml里声明服务并提供一个配置页面引导用户跳转到系统设置。service android:name.ArtemisAccessibilityService android:exportedtrue android:permissionandroid.permission.BIND_ACCESSIBILITY_SERVICE intent-filter action android:nameandroid.accessibilityservice.AccessibilityService / /intent-filter meta-data android:nameandroid.accessibilityservice android:resourcexml/accessibility_config / /service配置文件accessibility_config.xml里要声明你需要的能力accessibility-service android:accessibilityEventTypestypeAllMask android:accessibilityFeedbackTypefeedbackGeneric android:accessibilityFlagsflagDefault|flagRetrieveInteractiveWindows android:canRetrieveWindowContenttrue android:canPerformGesturestrue android:notificationTimeout100 /注意canPerformGestures是执行滑动和点击手势的前提canRetrieveWindowContent是读取界面内容的前提这两个必须开启。另外flagRetrieveInteractiveWindows对于获取多窗口场景下的界面信息很重要。实测下来不同厂商的 ROM 对无障碍服务的限制差异很大。有些系统会在应用后台运行时自动关闭无障碍服务有些会弹二次确认。做产品化的时候必须考虑这些兼容性问题。3.2 控件树的抓取与清洗拿到AccessibilityNodeInfo的根节点后需要递归遍历。但直接遍历会拿到大量无用节点必须做过滤。我一般按这几个规则来跳过visibleToUser为 false 的节点。跳过宽高为 0 的节点。保留isClickable、isEditable、isScrollable为 true 的节点。保留text或contentDescription非空的节点。对纯容器节点没有文本、不可交互做折叠只保留其子节点。遍历的时候要注意深度限制。有些页面的控件树非常深递归遍历可能栈溢出建议用迭代队列的方式并设置最大深度比如 30 层。还有一个坑RecyclerView 的懒加载。列表里没滚动到的 item 是不在控件树里的所以你不能一次性拿到整个列表的内容。需要结合滚动动作边滚边抓。3.3 Prompt 的构造技巧Prompt 的质量直接决定模型决策的准确率。ARTEMIS 的 prompt 通常包含这几块系统指令告诉模型它是一个手机操作助手输出必须是 JSON 格式的动作指令。任务描述用户输入的自然语言目标。当前界面清洗后的控件树描述。历史动作之前执行过的动作和结果帮助模型避免重复。可用动作列表明确告诉模型有哪些动作可选。一个简化后的 prompt 结构大概是这样你是一个 Android 手机操作助手。根据当前屏幕内容决定下一步动作。 可用动作click(node_id), input(node_id, text), scroll(direction), back(), done() 任务帮我在设置里把字体调大 当前屏幕 [0] 设置 (可滚动) [1] 搜索 可点击 [2] 网络和互联网 可点击 [3] 显示 可点击 [4] 声音 可点击 ... 历史动作 1. 点击 [3] 显示 - 成功 请输出下一步动作JSON格式关键技巧把动作空间和输出格式写死在系统指令里并且在解析模型输出时做严格的格式校验。模型偶尔会输出多余的解释文字解析器要能容错提取 JSON。3.4 坐标点击与节点点击的取舍优先用节点点击通过node_id找到对应的AccessibilityNodeInfo然后调用performAction(ACTION_CLICK)因为节点点击不受分辨率影响也不怕界面轻微位移。但节点点击不是万能的。有些自绘控件虽然可点击但performAction不生效这时候就得退回到坐标点击。坐标点击需要用dispatchGesture构造一个点击手势Path path new Path(); path.moveTo(x, y); GestureDescription.StrokeDescription stroke new GestureDescription.StrokeDescription(path, 0, 50); GestureDescription gesture new GestureDescription.Builder().addStroke(stroke).build(); dispatchGesture(gesture, null, null);坐标点击的坑在于坐标是相对于屏幕的但控件树里的坐标可能是相对于父容器的。你需要把节点坐标逐层累加到根节点才能得到屏幕绝对坐标。这个计算很容易出错建议写个工具方法统一处理。4. 实操过程与核心环节实现4.1 环境准备与项目编译先把项目拉下来用 Android Studio 打开。ARTEMIS 对 Android SDK 版本有要求建议用 API 30 以上的设备或模拟器。编译前检查几个点build.gradle里的minSdkVersion和targetSdkVersion是否和你的设备匹配。大模型 API 的 key 需要配置在本地不要硬编码进代码提交。如果用到网络请求确保AndroidManifest.xml里有INTERNET权限。编译通过后安装到设备上第一件事是引导用户开启无障碍服务。可以做一个检测逻辑用AccessibilityManager判断服务是否已开启没开启就跳转到Settings.ACTION_ACCESSIBILITY_SETTINGS。4.2 跑通第一个自动化任务建议从最简单的任务开始验证链路比如“打开设置进入显示把亮度调到最高”。这个任务步骤清晰、界面稳定适合调试。第一步确认界面抓取正常。在无障碍服务里打印当前根节点的控件树看看能不能拿到“设置”首页的各个条目。如果拿到的是空树检查canRetrieveWindowContent是否开启或者当前页面是不是被系统保护了。第二步手动构造一个 prompt调用大模型看它输出的动作是否合理。这一步先不要自动执行把模型输出打印出来人工检查。确认模型能正确理解界面描述、能选对节点之后再接入执行层。第三步把整个循环跑起来。观察每一轮的动作是否符合预期界面切换后能不能正确重新抓取。这个阶段最容易出现的问题是时序问题——点完之后界面还没刷新框架就抓取了旧界面导致模型基于过时信息做决策。解决办法是在执行动作后加一个短暂的等待或者轮询检测界面是否发生变化。4.3 多步任务的稳定性调优单步任务跑通之后挑战在于多步任务的稳定性。我实测下来影响稳定性的因素主要有这几个界面加载延迟。不同 App 的响应速度差异很大固定的wait时间要么太长浪费时间要么太短抓取到旧界面。更好的做法是轮询检测界面指纹——把控件树的关键信息算一个 hash如果连续两次抓取的 hash 一致就认为界面稳定了。弹窗干扰。很多 App 会突然弹出广告、更新提示、权限申请这些都会打断自动化流程。框架需要有一个弹窗检测与处理机制识别到非预期弹窗时优先关闭它再继续原任务。这个逻辑可以写进 prompt 里让模型判断也可以做规则匹配。模型决策漂移。轮次多了之后模型可能会“忘记”原始目标或者陷入重复动作。解决办法是在 prompt 里始终保留原始任务描述并且在历史动作里标注哪些动作已经执行过、结果如何。如果检测到连续 3 轮动作相同且界面没变化就强制中断并报错。4.4 参数计算与性能考量大模型调用是整個流程里最慢、最贵的环节。一次任务如果跑 20 轮就是 20 次 API 调用。优化方向有几个界面描述压缩前面提到的控件树清洗能把 token 数压到原来的 1/5 甚至更低。历史动作摘要不要把所有历史动作原文塞进 prompt而是做摘要比如“已点击显示、已点击亮度”。缓存机制对于相同的界面相同的任务状态可以缓存模型的决策结果避免重复调用。本地小模型兜底对于一些简单动作比如关闭弹窗、点击明显的按钮可以用规则或小模型处理不必每次都调大模型。延迟方面一次大模型调用通常在 1-3 秒加上界面抓取和执行单步耗时在 2-5 秒。一个 10 步的任务大概需要 30-60 秒。这个速度对于自动化来说可以接受但离“流畅”还有距离。5. 常见问题与排查技巧实录5.1 无障碍服务频繁被系统杀掉这是最常见的问题。国产 ROM 对后台应用的限制很激进无障碍服务经常在应用切到后台后被关闭。排查思路检查应用是否申请了电池优化白名单。在设置里把应用设为“允许后台运行”。对于某些 ROM需要在“最近任务”里锁定应用。监听onInterrupt回调服务被中断时尝试重新连接。需要说明的是这个问题没有完美的技术解法更多是引导用户做系统设置。产品化的时候要把这些引导做进 onboarding 流程。5.2 控件树抓取为空或不完整可能的原因和排查方向现象可能原因排查方法根节点为 null无障碍服务未正确连接检查服务是否开启重启服务控件树为空页面是自绘 UI 或 WebView尝试用截图OCR 兜底部分节点缺失懒加载未触发先执行滚动再抓取文本为空内容在 contentDescription 里同时读取 text 和 contentDescriptionWebView 是个特殊情况。默认情况下无障碍服务能读到 WebView 的 DOM 结构但需要 WebView 开启无障碍支持。如果读不到只能靠截图视觉模型来理解界面。5.3 模型输出的动作无法执行模型说点击 node_id5但框架里找不到这个节点。常见原因界面在模型决策和执行之间发生了变化节点失效了。模型引用了不存在的 node_id幻觉。节点存在但不可点击。处理策略执行前先校验 node_id 是否存在且可交互如果校验失败不要直接报错终止而是把失败信息反馈给模型让它重新决策。这样框架就有了一定的自愈能力。5.4 任务陷入死循环模型反复执行同一个动作界面没有变化。检测逻辑记录最近 N 轮的动作和界面 hash。如果连续 3 轮动作相同且界面 hash 相同判定为死循环。中断当前流程把情况反馈给用户或触发重新规划。死循环的根源往往是任务本身无法完成比如目标按钮不存在或者模型对界面的理解有偏差。这时候与其让模型硬试不如及时止损。5.5 不同分辨率设备的适配坐标点击在不同分辨率下会失效。解决办法优先用节点点击避免坐标点击。必须用坐标时把坐标归一化到 0-1 范围执行时再按当前屏幕尺寸还原。界面描述里不要暴露绝对坐标只暴露节点 ID 和相对位置关系。我在一台 1080P 手机和一台 2K 平板上测试同一个任务节点点击的方案完全不用改坐标点击的方案需要重新校准。这个差异非常明显。6. 这个框架的边界与我的实际体会ARTEMIS 代表了一个明确的方向把大模型的语义理解能力和 Android 系统的自动化能力结合起来做出真正通用的移动端 Agent。这个方向是对的但目前的工程成熟度离“开箱即用”还有距离。我在实际测试中感受最深的一点是界面描述的質量比模型能力更影响最终效果。同一个模型喂给它干净的、结构化的界面信息决策准确率能到 80% 以上喂给它原始控件树准确率直接掉到 50% 以下。所以如果你要基于 ARTEMIS 做二次开发我建议把最多精力花在界面信息的清洗和结构化上而不是反复换模型。另一个体会是不要追求全自动。完全无人干预的自动化在复杂场景下很容易翻车更现实的方案是“AI 执行 人工兜底”——关键步骤让用户确认异常情况让用户接管。这样既能享受自动化的效率又不会因为一次误操作造成不可逆的后果。最后分享一个调试技巧把每一轮的界面描述、模型输出、执行结果都打到日志里出问题的时候回放日志能快速定位是感知错了、决策错了还是执行错了。这个日志系统在调试阶段的价值比任何优化都大。