★ FEATURED ARTICLE 做移动端自动化的朋友这些年应该没少跟 UI Automator、Espresso、Appium 这些框架打交道。脚本写起来倒不复杂真正让人头疼的是设备碎片化带来的兼容性调整以及页面改版后一堆选择器失效的维护成本。ARTEMIS 这个谷歌开源的移动端 AI 自动化框架思路跟传统自动化完全不在一个维度——它让 AI 助手像人一样“看”屏幕、“理解”界面然后用自然语言描述任务就能操作手机。我第一时间把它跑起来做了验证今天把整个框架的拆解、实操过程和踩坑记录整理出来给想尝试或已经在关注移动端自动化新方向的朋友一个参考。1. 项目定位与设计思路拆解1.1 传统自动化测试的痛点在哪里先说清楚我们面临的问题。传统 UI 自动化测试框架无论用的是 ID、XPath 还是 Accessibility 属性定位元素本质都是“程序化”地告诉设备去点坐标 (x,y) 或者找resource-id为com.example:id/button_login的控件。这种方式在页面结构稳定的时候很可靠但只要版本迭代改了布局、换了控件层级或者出现 A/B 测试导致相同功能不同页面结构脚本就得跟着改。更麻烦的是复杂任务。比如“从购物车结算并选择优惠券”这类跨页面、多步骤的操作用传统框架写出来往往是一长串步骤流每一步都要精心设计等待条件和异常处理。测试用例写多了之后维护成本会逐渐逼近甚至超过开发成本这也是很多团队自动化测试投入产出比不高的根本原因。1.2 ARTEMIS 换了一条完全不同的路子ARTEMIS 的核心理念是让 AI 像人一样使用手机。人类是怎么操作 App 的先看屏幕理解当前页面有哪些可用元素然后根据肚子里的知识和目标决定点哪里、滑到哪里、输入什么内容。ARTEMIS 把这个思路完整复刻了一遍它用视觉语言模型去“看”屏幕理解界面语义再结合任务目标做出操作决策。这个项目全称是Android Reliable Task Execution and Management Intelligence System跟希腊神话里的狩猎女神同名学的是让 AI 在手机屏幕上精准“狩猎”目标操作点。研究团队把它定位成一个端到端的环境不只是算法模型还包含了一套完整的离屏渲染系统、任务执行评估体系和模型微调方案。跑起来之后你可以直接对它说“帮我把闹钟设定到明天早上七点”“打开设置把亮度调到最低”AI 会自动完成操作不需要任何人为编排的步骤脚本。1.3 这套方案真正解决的三个层次的问题第一层是脚本维护问题。不需要写选择器和步骤流自然语言描述任务就行页面结构变化对已经写好任务的影响大幅降低。第二层是任务泛化问题。传统脚本只会在特定页面上做特定操作ARTEMIS 更像一个通用手机助手遇到没见过的页面也能靠视觉理解能力继续执行。第三层是落地规范问题。它把“目标描述—屏幕理解—操作决策—执行反馈”这个闭环标准化了不管后面用的是 Claude、GPT 还是开源 VLM都可以套用这套框架去做移动端 Agent。2. 核心架构与关键技术点解析2.1 视觉语言模型是大脑但不止一个模型ARTEMIS 的主干模型是基于 PaLM 2-S* 微调出来的视觉语言模型具备屏幕理解和 grounding 能力也就是能把自然语言描述映射到屏幕坐标系的具体位置。这里的重点在于模型不是简单地“描述图片”而是要做到对 UI 元素级别的理解——知道哪个是按钮、哪个是文本输入框、哪些元素可点击、哪些只是装饰。要实现这种能力团队用了行为克隆Behavior Cloning加偏好优化Preference Optimization的两阶段训练策略。行为克隆先让模型模仿大量人工演示的操作轨迹学会“看到什么界面就做什么操作”偏好优化则从多个候选操作中选择人类更认可的那个动作进一步校准模型的决策偏好。最终推理时使用贪婪解码配合低温度参数保证输出稳定性而不是像对话模型那样追求多样性和创造性。这个模型最核心的设计是用“严格语法文本”作为 UI 表示。它不像其他多模态模型那样把截图直接丢给模型而是先通过离屏渲染提取当前屏幕的语义结构转成一段特定格式的文本再把这段文本交给 VLM 去决策。这样做的好处是大幅减少了模型需要理解的冗余视觉信息让模型把注意力集中在真正需要操作的元素上。2.2 离屏渲染在后台画出手机屏幕的“语义地图”离屏渲染是 ARTEMIS 里一个容易被忽略但极其关键的组件。它在真实设备上通过实用 UI AutomatorGoogle 官方的 UI 测试框架自动化获取当前界面的控件树然后利用 Android 系统的 View 绘制能力在屏幕外生成一张“带标注”的渲染图——每个控件会被分配一个唯一的 OLCOn-screen Labeled Cell编号并记录它的 bounding box 坐标和文本属性。这个过程有点像地图导航里的“路网图”而不是卫星照片。传统视觉模型直接看截图会被壁纸、图片、广告这些装饰性内容干扰ARTEMIS 的离屏渲染把 UI 逻辑结构提取出来相当于给模型一张清晰的路网图哪里是按钮、哪里是输入框、哪些元素可以点击一目了然。最终模型看到的是带坐标注释的屏幕表示[OLC 128] Button 登录 at (280, 950, 560, 1100) [OLC 132] EditText 用户名输入框 at (140, 720, 760, 870)这种格式可以精确指导后续的点击和输入操作也方便模型建立“目标描述与界面元素”之间的对应关系。由于严格语法文本压缩了视觉 token 数量推理速度也比直接输入原始截图更快这个设计在处理低端机型上的复杂界面时优势特别明显。2.3 实用 UI Automator 与 ADB 命令协作的交互闭环执行层面ARTEMIS 通过谷歌官方的好用 UI Automator 拿到可操作控件节点后由 VLM 决策出动作意图再调用 ADBAndroid Debug Bridge层执行对应的操作指令比如点击 OLC 编号对应的坐标区域、在输入框内填充文字、执行滑动等。整个闭环流程是这样的任务描述输入模型模型根据当前屏幕语义结构一次推理输出包含动作类型和 OLC 目标的决策框架把动作翻译成具体的 ADB shell 命令或 UiAutomation API 调用设备执行完后重新提取界面结构进入下一轮决策。这个循环持续进行直到模型判定任务完成或达到最大轮次限制。这里有一个关键细节环境用的是真实安卓设备或模拟器不需要特制 ROM也不需要 root。因为只要 Android SDK 的自动化接口能工作框架就能获取界面信息并注入操作事件这保证了方案具备较好的普适性和可复现性。3. 实操准备与核心环节实现3.1 环境准备把依赖一项项配齐ARTEMIS 的代码以研究代码库的形式开源主体基于 Python 和 Jupyter Notebook不是开箱即用的产品级工具我把完整跑通需要配的环境列出来方便参考。首先是基础依赖。系统层面需要 Python 3.9建议通过 conda 创建独立虚拟环境不然容易跟本机其他项目打架。然后装 Android SDK命令行工具至少要有 adb 和 aapt。突出推荐配置好 Android 模拟器API 30 以上因为真机调试时设备碎片化带来的渲染差异可能影响离屏渲染的准确性。pip install gdown pip install -r requirements.txtARTEMIS 的模型检查点文件放在 Google Drive 上用 gdown 下载时要注意文件 ID 不是公开分享链接里的那一串随机字符直接复制容易出错。我实际下载时遇到过 403 权限错误解决方法是去代码仓库的 README 里找它提供的共享文件路径配置确认了文件权限为“任何知道链接的人”之后才能顺利拉取。3.2 数据集认知千万别跳过评估环节很多朋友拿到这个项目第一件事就是直接跑模型操作手机我建议先冷静一下。ARTEMIS 开源内容里还包含了一个精心标注的评估数据集涵盖 10 类常见日常任务、超过 150 种应用操作场景每种场景都有详细的任务说明、参考操作轨迹和 EUI 层面的数据标注。跑通模型后先在这个数据集上做量化验证能直观感受模型的成功率、步骤数与基线对比情况也为后续接入自己的测试任务提供校准基准。评估过程不需要人工盯着屏幕框架自带评估脚本会自动对比 AI 操作后的页面状态与预期目标页面状态是否一致。这一点值得给团队推广自动化测试的朋友提个醒评估脚本本身就可以沉淀成一条可持续运行的任务链路实现“发任务、看结果、出报告”的闭环。3.3 模型配置与首次任务执行模型权重大约 12GB 左右下载之后需要配置路径。ARTEMIS 的实现参考了 MiniGPT-v2 的模型结构所以配置里需要指定 LLM 路径、视觉编码器路径和 tokenizer 路径。我的建议是把这些路径统一写在一个.env文件或配置脚本里避免每次启动都要手改参数。首次启动执行任务时推荐用官方仓库里的 Jupyter Notebook 逐格运行先初始化三个核心组件离屏渲染器、模型推理器和动作执行器。示例任务建议选一个页面结构简单、元素数量少的比如“打开计算器计算 128 乘以 6”因为这类任务能快速验证整个链路是否通畅也不会消耗太多推理时间。执行任务的指令格式需要注意尽量描述结果而不是描述过程。比如“帮我把 Wi-Fi 打开”就比“从设置页面找到无线网络选项点击开关按钮”更适合 ARTEMIS因为后者等于人为限制了模型的决策空间一旦页面结构跟预期不一致就容易失败。3.4 高效控制任务执行与动态信息收集框架导航策略参考了 ReAct 模式也就是在每一轮操作时同时输出“推理过程 动作指令”类似人脑先思考再行动的逻辑。跟 OpenAGI 等框架相比它更强调 UI 状态与任务的相关性会自动跳过与目标无关的干扰元素。我实际操作时发现一个实用技巧任务执行时ARTEMIS 支持在 FLAG 中加入get_info来实时收集应用信息和 UI 布局数据。比如在“设置”界面切换开关时捕获到的 UI hierarchy 快照会被自动保存方便后续追踪操作历史和调试。对于做自动化测试的朋友来说这个能力可以直接复用相当于自动生成了每一步操作对应的页面变更记录。4. 常见问题、排查技巧与避坑实录4.1 离屏渲染结果不准或拿不到控件树这是跑 ARTEMIS 时最容易遇到的一类问题。常见情况有三种页面元素没有可用的 content-desc 或文本属性、控件层级嵌套太深导致 UI Automator 解析超时、WebView 页面里的内容不暴露给原生控件树。对应的排查思路是先检查页面是否渲染完成在任务描述里偷偷加一句“等待页面加载完成后再操作”的语义或者修改代码里的等待策略遇到纯 H5 页面老实说 ARTEMIS 的离屏渲染能力会受限需要换原生功能场景先验证如果控件树拿到但显示错位检查设备分辨率与渲染配置里的尺寸是否一致。4.2 模型推理慢得像蜗牛爬ARTEMIS 的视觉语言模型跑在个人 GPU 上推理速度跟显卡直接挂钩。我用一块 RTX 4090 测下来单步决策大约在 3 到 5 秒一个 10 步任务跑完就是一分钟上下效率问题会在体系化回归测试时立刻暴露出来。实际能优化的手段有用 FP16 量化减少显存占用和推理耗时将框架的截屏渲染频率从每步都渲染改为检测到界面变化才渲染把任务描述中的目标写得更明确以减少决策轮次。如果业务场景允许优先在模拟器上跑而不是真机因为模拟器的 UI Automator 响应通常更稳定能减少等待耗时的干扰。4.3 设备连接不稳导致执行中断adb 连接断开在无线调试模式下特别常见。我的经验是优先用 USB 数据线连接并在代码里增强重连逻辑比如检测到device offline时自动执行adb reconnect。同时给模拟器固定端口避免反复弹窗分配随机端口。另一个隐蔽坑是弹窗干扰。系统级弹窗权限申请、系统更新提醒、自动旋转建议会打断任务的连续决策。我的处理方式是在设备上手动安装并启用“拒绝权限请求”的设置助理或者用 Demo 模式禁用部分系统窗口。把这类弹窗干扰记录下来作为任务前置条件固定在执行环境配置里能显著提升成功率。4.4 常见问题速查表异常现象可能原因解决方案模型输出乱码/日志异常tokenizer 路径配置错误检查路径是否指向 BPE tokenizer 的 vocab 文件gdown 下载报 403文件权限未公开确认 Google Drive 共享链接权限任务执行到一半卡住UI Automator 解析线程阻塞调低页面解析超时并对无响应控件做跳过处理任务结果与预期状态偏差大目标描述过于笼统动词前置描述终端状态而非中间过程多步任务步骤数爆炸模型在无关元素上反复决策在提示词中强调“仅操作与目标相关元素”4.5 实测中的三个独家心得第一点是任务描述要像给人类同事派活一样写。要求越清楚模型的决策路径越短。我试过描述“清理一下手机空间”和“删除相册里最近 30 天内截图”前者模型纠结了很久不知道该进哪个菜单后者直接完成了删除操作。这就是场景约束带来的现实差距。第二点是不要迷信单一模型。ARTEMIS 的框架是可插拔的PaLM 2-S* 只是官方实验用的模型实际工程落地时完全可以替换成量化后的开源 VLM。我后来用一个 7B 的模型做试验步骤数虽然多了一些但在简单任务上的成功率是达标的这对于没有高算力预算的团队是个好消息。第三点是注意坐标系偏移。离屏渲染出来的 OLC 坐标以渲染视图为准但最终动作是靠 ADB 注入的一旦设备屏幕有刘海、水滴屏或系统导航栏手势区域注入点可能出现偏位。解决办法是通过wm size获取实际有效显示区域并换算坐标后再执行点击。5. 从 ARTEMIS 看 AI 操作手机的未来方向5.1 它给自动化测试行业带来了范式级启发做这么多年自动化测试我一直觉得行业天花板在于“脚本的脆弱性”。ARTEMIS 从模型层面绕开了选择器依赖问题让测试人员从写步骤脚本变成写业务目标、维护评估标准。这意味着测试团队结构也会跟着变需要懂 Prompt 工程、懂模型评估、懂数据标注的人而不是只会写 XPath 的人。这个转变不是 PPT 上的概念。ARTEMIS 在评估数据集上表现出的成功率相较之前工作有显著提升同时会把复杂任务简化成更少的步骤数量级。对于长期维护移动端核心链路的团队这类“无脚本自动化”思路值得快速做一轮概念验证选 20 个高频核心用例跑一跑看看模型对自家业务的理解能力。5.2 AI Agent 落地手机的参考架构ARTEMIS 的“离屏渲染 VLM 决策 ADB 执行”三层设计本质上是为手机 AI 助手提供了一套标准动作接口。以后手机上的智能体不需要厂商开放系统 API也能通过 UI 层完成大部分操作——打车、点外卖、订机票、查快递通通可以用自然语言驱动。我认为后续的演进方向大概率是轻量化模型加端侧部署。一套几十亿参数的视觉语言模型如果能跑在手机 NPU 上配合 ARTEMIS 这类框架个人智能助手的体验会上升一个台阶。至少从开源生态看ARTEMIS 把落地路径完整摊开了谁能在模型成本和执行稳定性上做到平衡谁就可能在下一轮移动端 AI 应用竞赛里占得先机。5.3 关于直接上手的一点点建议直接拿 ARTEMIS 上生产环境我会劝你先冷静但先跑通它绝对值得。项目本身是研究性质代码Bug 和小毛病不少文档也比较零散。我是在 Ubuntu 系统上配好的环境Windows 用户建议用 WSL 2 避免一堆依赖编译问题。最后再提一个小细节任务执行完之后ARTEMIS 会保留完整的操作轨迹日志。这份轨迹数据特别宝贵我通常会把失败任务的操作序列翻出来看模型到底是哪一步走偏了比猜测和反复重跑高效得多。谷歌能把这个项目开源确实给移动端 AI 自动化开了一个很好的头接下来就看社区能在上面长出什么有意思的应用了。
阅读完成 · 觉得有帮助？
