ARTEMIS 开源框架：让 AI 像真人一样稳定操作 Android 手机

移动端自动化这个方向过去几年一直有个尴尬的现实能跑通 Demo 的方案很多能稳定跑一整天的方案很少。我自己从早期用 ADB 脚本硬怼坐标点击到后来折腾各种 UI 自动化框架踩过的坑基本能写一本书。直到谷歌把 ARTEMIS 开源出来我才觉得这件事终于有了一个正经的工程化答案。ARTEMIS 是一个面向 Android 的移动端 AI 自动化框架核心目标是让 AI 助手能够像真人一样理解屏幕内容、做出决策、执行操作。它解决的不是能不能点的问题而是点得对不对、稳不稳、能不能规模化的问题。这篇文章适合三类人看正在做移动端自动化测试的工程师、想把 AI Agent 能力落到手机上的开发者、以及单纯对AI 操作手机这件事好奇的技术爱好者。我会从架构设计、核心机制、实操落地、踩坑经验几个维度把 ARTEMIS 拆开讲透。1. ARTEMIS 到底在解决什么层面的问题1.1 传统移动端自动化的三条死路先说清楚背景不然你无法理解 ARTEMIS 的设计取舍。移动端自动化这些年主要走了三条路每条路都有硬伤。第一条是基于坐标的脚本录制。早期工具像 MonkeyRunner、部分商业自动化平台本质是记录你点击了屏幕的哪个像素点然后回放。这条路的问题极其致命分辨率一变、系统字体一变、状态栏高度一变坐标全废。我见过一个团队为了适配 20 款机型维护了 20 套坐标脚本最后维护成本比人工测试还高。第二条是基于控件树的 UI 自动化。以 UiAutomator、Appium 为代表通过 AccessibilityService 拿到界面的控件树然后按 resource-id、text、class 去定位元素。这条路比坐标靠谱得多但它的死穴在于它假设界面是结构化的、可枚举的。现实是大量 App 用自绘 View、Flutter、Unity、游戏引擎渲染控件树里要么是空的要么是一堆无意义的节点。你拿不到有语义的元素定位就无从谈起。第三条是基于图像识别的模板匹配。截屏后在图库里找目标图片找到就点。这条路对自绘界面友好但模板图一旦遇到主题切换、夜间模式、动态内容、分辨率缩放匹配率断崖式下跌。而且它只能识别你预先准备好的模板遇到没见过的界面就抓瞎。1.2 ARTEMIS 的破局思路让模型看懂屏幕ARTEMIS 的核心思路和上面三条路都不一样。它不依赖控件树也不依赖预置模板而是把屏幕截图直接交给多模态大模型去理解让模型输出当前界面是什么、有哪些可交互元素、下一步该做什么。这个转变的意义在于它把界面理解这件事从规则驱动变成了语义驱动。规则驱动需要你穷举所有情况语义驱动则是模型基于视觉和语言理解去泛化。一个从没见过某款 App 的模型也能大致判断出这个蓝色按钮大概率是登录这个输入框应该填手机号。ARTEMIS 在工程上做的事情就是把这套截图 → 模型理解 → 生成动作 → 执行动作 → 再截图的循环封装成一套可复用、可扩展、可观测的框架。它要处理的问题包括截图怎么高效拿、模型输出怎么解析成可执行动作、动作怎么在设备上落地、多步任务怎么保持上下文、异常怎么恢复。1.3 它和AI Agent 操作电脑的本质区别有人会问这不就是把 Computer Use 那套搬到手机上吗方向类似但移动端的约束完全不同这也是 ARTEMIS 存在的价值。移动端的约束主要有三个。第一是屏幕小、信息密度高一屏可能塞了几十个可点击元素模型要在有限分辨率下准确区分。第二是交互方式特殊除了点击还有长按、滑动、双指缩放、返回手势、下拉刷新这些动作的语义和桌面端完全不同。第三是系统权限和稳定性Android 的截屏、注入事件、后台保活都受系统限制框架必须处理这些底层问题。ARTEMIS 针对这些约束做了专门设计这也是它区别于通用 Agent 框架的地方。它不是简单套壳而是真正为移动端场景打磨过的。2. 拆解 ARTEMIS 的核心架构与运行机制2.1 感知层截图与界面信息采集ARTEMIS 的感知层负责把设备当前状态喂给模型。这里有几个关键设计点值得说。截图方式的选择。Android 上截屏有好几种途径MediaProjection API、ADB screencap、AccessibilityService 的 takeScreenshot。ARTEMIS 通常会组合使用。MediaProjection 速度快、无需 root但需要用户授权一次ADB screencap 最通用但延迟高AccessibilityService 的截图在部分系统版本上有限制。框架会根据运行环境自动选择最优路径这是工程化的体现。截图之外的辅助信息。光有截图还不够ARTEMIS 还会采集当前前台应用包名、Activity 名称、屏幕分辨率、旋转状态、甚至控件树的精简版本如果拿得到。这些信息作为上下文一起给模型能显著提升判断准确率。比如模型知道当前是微信聊天界面就不会把输入框误判成搜索框。图像预处理。原始截图往往很大直接喂给模型既慢又贵。ARTEMIS 会做缩放、压缩、必要时裁剪感兴趣区域。这里有个经验缩放比例要谨慎缩太小模型看不清小字缩太大 token 消耗爆炸。实践中一般把长边压到 1080 到 1280 之间比较平衡。2.2 决策层多模态模型如何输出可执行动作这是 ARTEMIS 最核心的部分。模型看到截图后要输出一个结构化的动作指令。ARTEMIS 定义了一套动作空间通常包括动作类型参数说明tapx, y 或 element_id点击指定位置或元素long_pressx, y, duration长按swipestart_x, start_y, end_x, end_y滑动typetext输入文本back无返回home无回桌面waitduration等待doneresult任务完成模型的任务是把自然语言指令比如帮我在设置里把蓝牙打开和当前截图结合起来输出下一步动作。这里的关键挑战是坐标的准确性。模型直接输出像素坐标往往不准因为它在缩放后的图上判断映射回原图会有偏差。ARTEMIS 的解法通常是让模型输出归一化坐标0 到 1 之间的相对位置框架再乘以实际分辨率。更精细的做法是让模型先描述目标元素右上角的齿轮图标再由框架结合控件树或视觉定位去精确定位。这种语义描述 精确定位的两段式设计比让模型直接吐坐标稳得多。2.3 执行层动作如何真正落到设备上模型输出动作后得有人去执行。ARTEMIS 的执行层主要依赖两个通道。AccessibilityService 通道。这是首选因为它不需要 root能执行点击、滑动、输入、返回等大部分操作。它的原理是通过无障碍服务注入手势和文本。优点是权限相对好拿缺点是部分 App 会检测无障碍服务并做对抗还有些系统对输入文本有限制。ADB 通道。通过adb shell input系列命令执行比如input tap x y、input swipe、input text。优点是通用、不依赖 App 配合缺点是需要设备开启调试、延迟较高、不适合高频操作。ARTEMIS 一般把 ADB 作为兜底方案。执行层还要处理动作确认。执行完一个动作后框架会再截一次图对比前后状态判断动作是否生效。如果界面没变化可能是点击没命中需要重试或调整策略。这个执行-验证闭环是稳定性的关键。2.4 记忆与规划层多步任务怎么不迷路单步操作好做难的是多步任务。比如帮我把某商品加入购物车并下单涉及搜索、筛选、进详情、加购、结算等十几个步骤。ARTEMIS 需要维护任务上下文。它通常维护一个历史动作序列和任务状态。每一步把之前的动作和观察结果作为上下文喂给模型让模型知道我已经走到哪一步了。但上下文不能无限增长否则 token 爆炸。所以框架会做上下文压缩比如只保留最近 N 步的详细记录更早的用摘要代替。还有一个重要机制是任务分解。复杂任务先由模型拆成子任务再逐个执行。这样每步的决策空间更小准确率更高。比如下单拆成搜索商品 → 选择规格 → 加入购物车 → 进入购物车 → 点击结算 → 确认订单。3. 从零跑通 ARTEMIS 的实操路径3.1 环境准备那些文档不会告诉你的细节假设你要在本地把 ARTEMIS 跑起来环境准备有几个坑必须提前知道。Python 环境。ARTEMIS 主体通常是 Python 写的建议用 3.10 或 3.11太新的版本某些依赖可能没适配。用 conda 或 venv 建独立环境别污染系统 Python。Android 设备或模拟器。真机优先因为模拟器的截图和手势行为和真机有差异尤其是涉及系统 UI 的操作。如果必须用模拟器推荐 Android 11 以上的 AOSP 镜像别用带 Google Play 的镜像因为权限限制更多。ADB 配置。确保adb devices能列出你的设备。如果是真机打开开发者选项和 USB 调试。这里有个细节部分国产 ROM 需要额外开启USB 调试安全设置否则input命令会被拦截。模型接入。ARTEMIS 需要接一个多模态模型。你可以用云端 API也可以本地部署。云端 API 上手快但有成本和延迟本地部署需要显卡。实践中开发调试阶段用云端 API 快速迭代生产环境再考虑本地化是常见策略。3.2 安装与首次运行安装一般就是克隆仓库、装依赖git clone artemis-repo cd artemis pip install -r requirements.txt然后配置模型密钥和设备信息。ARTEMIS 通常有个配置文件让你填 API key、模型名称、设备序列号等。首次运行建议从最简单的任务开始比如打开设置。命令大概长这样python run_artemis.py --task 打开设置 --device serial如果一切正常你会看到设备自动打开设置界面。第一次跑通这个说明链路是通的。3.3 一个完整任务的执行流程拆解拿打开蓝牙这个任务举例完整流程是这样的初始截图框架截取当前屏幕识别出当前在桌面。模型决策模型看到桌面截图和任务打开蓝牙判断需要先进入设置输出动作点击设置图标。执行动作框架通过无障碍服务点击设置图标。验证再截图确认已进入设置界面。继续决策模型看到设置界面判断需要找蓝牙选项可能在已连接的设备里输出滑动或点击动作。循环重复上述过程直到进入蓝牙设置页并打开开关。任务完成模型判断目标达成输出 done。这个过程看起来简单但每一步都可能出问题图标识别错、点击没命中、界面加载慢、弹窗干扰。ARTEMIS 的健壮性就体现在对这些异常的处理上。3.4 如何自定义任务和扩展动作ARTEMIS 一般支持自定义任务描述你直接用自然语言写就行。但要注意任务描述越具体成功率越高。比如打开蓝牙比帮我处理一下连接问题要好得多。如果要扩展动作比如支持双指缩放需要在动作空间定义里加新动作并在执行层实现对应的注入逻辑。这部分需要改代码不是纯配置能搞定的。4. 实测中暴露的问题与应对策略4.1 坐标偏移最常见的翻车点坐标偏移是我遇到最多的坑。表现是模型说点某个按钮结果点偏了点到隔壁元素上。根因通常有三个。第一模型在缩放图上判断坐标映射回原图时因为取整或比例计算有误差。第二截图和实际执行之间有时间差界面可能已经变了。第三状态栏、导航栏的高度在不同设备上不一样模型不知道这些偏移。应对策略优先让模型输出元素描述而非坐标由框架去精确定位。如果必须用坐标确保归一化计算准确并在执行前重新截一次图确认界面没变。另外可以在 prompt 里明确告诉模型屏幕的实际分辨率和安全区域。4.2 界面加载与异步等待移动端界面加载是异步的点了按钮后界面不会立刻变。如果框架点完立刻截图判断会看到旧界面导致误判。应对策略在动作执行后加一个等待稳定的逻辑。简单做法是固定等待 1 到 2 秒但这样效率低。更好的做法是轮询截图直到界面稳定比如连续两次截图差异小于阈值就认为稳定了。ARTEMIS 一般会内置这类等待机制但你需要根据 App 的实际响应速度调参数。4.3 弹窗、广告与意外干扰真实 App 里到处是弹窗开屏广告、更新提示、权限申请、活动弹窗。这些会打断任务流程。应对策略在决策 prompt 里明确要求模型如果遇到弹窗优先关闭弹窗再继续任务。同时可以在框架层加一个弹窗检测预处理识别到常见弹窗模式就先关掉。我自己的经验是维护一个常见弹窗的关闭策略库比完全依赖模型判断更稳。4.4 模型幻觉与错误决策模型有时候会自信地犯错比如把取消按钮当成确认按钮。这在涉及支付、删除等敏感操作时非常危险。应对策略对敏感操作加二次确认机制。框架在执行不可逆操作前先截图让模型复核或者直接暂停等人工确认。另外可以在 prompt 里强调不确定时选择等待或返回不要贸然操作。4.5 性能与成本控制每一步都要调模型一个复杂任务可能几十步成本和延迟都很可观。应对策略第一缓存和复用相同界面状态的决策可以缓存。第二分级模型简单判断用小模型复杂判断用大模型。第三减少不必要的截图只在界面可能变化时才重新感知。第四批处理如果做大规模测试把多个设备的请求合并调度。5. 把 ARTEMIS 用在实际场景里的经验5.1 自动化测试场景的落地要点用 ARTEMIS 做 App 自动化测试最大的价值是它能处理传统框架搞不定的自绘界面和复杂交互。但它不是银弹落地时要注意几点。测试用例要用自然语言写这降低了编写门槛但也带来了不确定性。同一个用例多次执行可能走不同路径。所以断言要设计得宽松一些关注最终状态而非中间步骤。要建立失败重试和截图留证机制。ARTEMIS 执行失败时把当时的截图、模型决策、动作序列都存下来方便排查。这比传统测试的日志有用得多。覆盖率评估要换思路。传统测试看代码覆盖率ARTEMIS 这种更关注任务成功率和路径多样性。5.2 无障碍辅助场景的可能性ARTEMIS 这类框架对无障碍场景其实很有想象空间。视障用户可以用自然语言描述想做的事AI 帮忙操作手机。这个方向技术上已经可行主要障碍是响应速度和准确率要达到实用水平。5.3 和现有自动化体系的集成如果你团队已经有 Appium 或 UiAutomator 的测试体系不建议全盘替换。更务实的做法是混合使用结构化界面用传统框架自绘和复杂场景用 ARTEMIS。两者通过统一的测试调度层整合。6. 我对这类框架的一些判断ARTEMIS 代表的方向是对的用模型的语义理解能力替代人工穷举规则。这条路在移动端尤其有价值因为移动端界面碎片化严重规则维护成本极高。但它现在的成熟度还没到开箱即用的程度。模型的不确定性、执行层的权限限制、真实 App 的对抗都是需要持续打磨的地方。我的建议是把它当成一个强大的辅助工具而不是完全托管的黑盒。关键流程保留人工兜底敏感操作加确认这样才能既享受 AI 的便利又控制风险。另外这类框架的演进会很快。模型能力在涨框架的工程化也在成熟。现在投入学习等它真正成熟时你就是有经验的那批人。我自己的做法是先用它跑一些低风险的重复任务积累 prompt 和异常处理的经验等摸透了再往核心场景推。最后分享一个实操小技巧给模型的任务描述里把成功标准写清楚。比如打开蓝牙直到看到蓝牙开关处于开启状态为止。这样模型知道什么时候该停不会无限循环或者提前收工。这个细节看起来小但对任务成功率的影响非常大是我踩了好几次坑才总结出来的。