做移动端自动化这块快十年了我一直觉得有两件事特别拧巴一是用例维护成本UI一变定位符全废二是跨应用流程比如“把相册里第一张图发给微信好友”写起脚本来能让人加班到怀疑人生。直到看到谷歌开源的ARTEMIS这个拧巴劲儿才顺了不少。ARTEMIS的全称是Android Reactive Tool-Enhanced Mobile Intelligence System核心思路一句话就能讲完用视觉语言模型看懂屏幕再像人一样通过手势去操作系统把自然语言任务变成一连串真实的点按滑动。这篇文章适合三类人看做自动化测试想摆脱选择器噩梦的、研究移动端AI Agent想找落地框架的、以及单纯对“AI操作手机”这件事好奇的开发者。我会从架构原理、部署流程、模型选型到踩坑调优把整个项目完整拆一遍。1. ARTEMIS是什么一个能“看懂屏幕”的移动端智能体1.1 项目定位与核心价值ARTEMIS不是传统意义上的自动化测试工具它是把“大模型决策”和“手机系统操作”缝合在一起的智能体框架。市面上有个很流行的概念叫AI AgentARTEMIS就是把Agent落到Android上的一个具体实现。我第一次看它的演示视频时说实话有点被震到。它不只是机械地执行预设脚本而是真的像一个人那样先看一眼当前屏幕长什么样然后决定点哪里、滑哪里、输入什么做完一步再停下来看结果再决定下一步。整个过程是动态的、可纠错的。它的核心价值在于改变了人机交互的自动化范式。以前我们操作手机靠的是UI Automator、Appium这类框架本质上是在“定位元素、点击坐标、断言状态”。现在ARTEMIS直接把“理解界面”这件事交给了视觉语言模型你只需要告诉它目标是什么“帮我在设置里打开Wi-Fi并连接一个叫MyHome的网络”剩下的路径规划、页面跳转、弹窗处理它自己看着办。1.2 与传统自动化框架的本质差异我用一张表直观对比一下ARTEMIS和传统UI自动化框架的区别这样你很快就能理解它的定位差异对比维度传统框架Appium/UiAutomatorARTEMIS用例编写写代码定位元素、写动作、写断言自然语言描述任务目标执行引擎线性脚本或条件分支视觉语言模型动态规划UI变更影响元素定位符失效需频繁维护靠视觉语义理解一般能自适应跨应用操作需要明确定位到跨应用的控件像人一样切换应用、看界面操作稳定性确定性强适合高频回归概率性决策需要加校验机制上手门槛需要会写代码、懂控件树会描述任务就能跑适合场景成熟功能的回归验证探索性任务、跨应用流程、智能助手这里要特别说明一点ARTEMIS并不是要全面替代传统框架。它俩其实是互补关系。传统框架适合确定性要求高的高频回归场景比如支付流程每一步都必须精确ARTEMIS适合那些路径不唯一、界面变化频繁、需要“人味”判断的场景。我在实际项目中现在的做法是核心交易链路继续用Appium做回归探索性测试和跨应用流程丢给ARTEMIS。1.3 一个具体任务的全过程拆解拿“把相册里第一张图发给微信好友小林”这个任务举例。传统自动化写起来要解决一堆问题相册列表怎么定位、分享菜单是哪个控件、微信联系人搜索框的resource-id是什么、发送按钮在哪。每个环节都要单独调整个脚本没几百行下不来而且换台手机可能就废了。ARTEMIS处理这个任务的逻辑完全不同。它拿到任务后第一步会对当前屏幕截图认出这是相册首屏识别出第一张照片网格项。然后它会模拟长按等待分享面板弹出再从面板里找到微信图标。进入微信后它会看到好友选择界面自动跳过可能出现的“最近聊天”列表直接在搜索框输入“小林”最后点发送。整个过程没有一句硬编码选择器全是大模型看着屏幕现学现卖。过程中如果点错了比如误触了某个弹窗它会观察屏幕变化自主绕过去或者点掉弹窗继续执行。这种容错能力是传统自动化框架完全不具备的。2. 技术架构拆解视觉、决策与执行的闭环2.1 感知层截图与UI层次的双通道输入ARTEMIS在“看屏幕”这件事上不是只靠截图它同时利用了两个信息源纯视觉截图和Android无障碍服务导出的UI层级结构。纯视觉截图很好理解就是手机当前屏幕的画面这是视觉语言模型最擅长的输入形式模型能从颜色、布局、图标、文字排版中理解界面语义。但截图有个天然缺陷分辨率不同、字体缩放不同模型对空间坐标的估计会有偏差。所以ARTEMIS还接入了Android的AccessibilityService来读取UI树。这棵UI树包含每个控件的类名、文本内容、坐标边界、是否可点击等属性。ARTEMIS会做一层过滤和压缩只保留叶节点、可点击节点、带文本的节点打包成结构化的文本信息喂给模型。这里有个很关键的细节无障碍服务给出的坐标是整个屏幕的绝对坐标不会受某些复杂容器的相对定位影响可以放心拿去做手势操作。但如果你自己改造这个框架注意别把子节点的相对坐标直接当屏幕坐标用这是新手最容易踩的坑坐标换算错了点击就会全面跑偏。2.2 决策层视觉语言模型如何“思考”ARTEMIS的决策核心是视觉语言模型我在实操中习惯把它理解成一个“长了眼睛的脑子”。模型的输入是一段结构化的JSON或多模态内容包含当前屏幕截图、UI树文本、任务描述、历史操作记录。ARTEMIS借鉴了ReAct模式的思路让模型先输出思考过程再输出具体动作。也就是说模型的回应里会有一个思考字段类似“当前页面是设置首页目标WiFi入口在顶部搜索框附近点击网络和互联网”然后才是具体动作“tap(522, 210)”。这种“思考-动作-观察”的循环非常利于排查问题。任务跑挂了翻日志就能看到模型在哪个环节产生了错误判断是因为视觉识别错了还是因为任务理解偏了一目了然。我在调试阶段基本离不开这个思考字段。模型还会接收一段任务规划上下文。ARTEMIS不是简单地把整段任务一次性丢给模型而是让模型把长任务拆分成若干子目标逐步完成。比如“下单买一个杯子”会拆成“搜索杯子→筛选商品→加入购物车→结算→支付”每一步都单独决策这样即使中间哪一步失败也不会让整个任务彻底崩盘。2.3 执行层动作空间与系统调用ARTEMIS定义了一套精炼的动作空间这是它能够准确操作手机的根本保障。主要动作包括点击tap、长按long_press、滑动swipe、文本输入type_text、按返回键press_back、按Home键press_home、按回车press_enter、等待wait等。这些动作最终都是通过Android的无障碍服务接口或系统注入事件来执行的这也是ARTEMIS能做到“像人一样”操作的原因之一。它没有走adb shell input那条路因为adb注入在部分场景下权限受限而且部分应用会校验输入来源无障碍服务的权限等级更高更接近真实用户的手势事件。执行层还有一个细节值得注意每个动作执行完ARTEMIS都会自动截取一张新屏幕截图回传模型形成“看→想→动→再看”的闭环。这个反馈机制是整个系统稳定的基石模型能随时根据实际界面变化修正下一步动作而不是闭着眼睛一路点到底。2.4 状态记忆多步任务不迷路的关键如果ARTEMIS只有“看-动-看”这个简单循环它处理复杂任务时很容易失忆。比如一个下单流程有8个步骤模型在第五步就忘了最初的任务目标或者忘记已经填过收货地址。所以ARTEMIS内部维护了一个对话记忆机制把所有历史步骤的屏幕摘要、动作记录和模型思考都存下来作为后续决策的上下文。为了防止这个问题实际使用中还需要对记忆做窗口截断。大模型的上下文窗口是有限的任务每一步的截图和思考都会占用大量token如果任务有十几步很容易把上下文填满导致模型忽略早期指令。我在给团队调优时就特别强调一点长任务最好设置子任务检查点每完成一个子目标就做一次简短摘要替换掉冗长的原始截图记录。这样既保留关键信息又控制上下文长度实测能把任务成功率提升不少。3. 从零部署ARTEMIS环境准备与第一个任务3.1 环境清单与版本选择部署ARTEMIS之前先把环境清单列清楚。我推荐用模拟器做前期验证原因很简单模拟器可以随时截图、重置系统状态、调整分辨率比物理机灵活太多。Android官方模拟器配合Pixel系统镜像是最稳的手势交互机制完整不容易出现输入法、分辨率相关的幺蛾子。具体需要准备这些东西一台Android 9及以上版本的设备或模拟器最好8GB运存以上开启开发者选项、USB调试、允许模拟点击Python 3.10及以上版本用于运行Agent控制端ADB工具链用于设备连接和基础操作Git用于拉取项目代码一个可用的视觉语言模型后端官方默认是Google的Gemini接口也可以配置其他兼容模型我实际测试中发现Android系统版本别太高也别太低。Android 9到Android 13之间的兼容性最好太新的版本某些OEM厂商会对无障碍服务做权限限制太老的版本则可能缺少部分手势API。3.2 安装配置与后端模型选择克隆代码和安装依赖的步骤很常规git clone 官方仓库地址 cd artemis python -m venv venv source venv/bin/activate pip install -r requirements.txt装好依赖后重点在配置文件。ARTEMIS的配置文件结构不算复杂核心就是告诉系统设备是谁、模型是谁、任务限制是什么。我从实际使用角度给你一个模板参考device_id: emulator-5554 backend: model_type: openai_compatible_vlm api_base: http://127.0.0.1:8000/v1 api_key: local-test-key model_name: qwen2.5-vl-7b-instruct execution: max_steps: 30 screenshot_interval_ms: 500 temperature: 0.3 language: zh-CN accessibility: enabled: true service_name: com.example.agent/.AutoAccessibilityService这里有个选型问题要展开讲。官方默认使用的是Gemini这类云端大模型效果确实好视觉理解能力和指令跟随能力都强。但如果你有数据隐私顾虑或者想降低调用成本完全可以换成开源视觉语言模型用本地GPU做推理服务。我试过用Qwen2.5-VL系列模型跑ARTEMIS小尺寸模型就能完成日常任务识别准确率在简单界面上不输云端模型太多而且延迟可控。配置后端的核心指标不是模型多大而是三点视觉定位能力、指令跟随的稳定性、输出格式的规范性。你可以准备20条固定任务做一个小样本测试集分别跑不同模型对比成功率用数据说话比看评测榜单务实得多。3.3 运行第一个自动任务环境准备好之后运行流程是启动Agent服务然后给它下发任务指令。第一次测试我推荐跑一个经典任务“打开计算器计算12乘以8”。启动后日志会展示这样的过程[step 1/10] thought: 当前屏幕是桌面需要找到计算器图标并打开 action: tap(320, 860) [step 2/10] observation: 计算器应用已打开界面显示数字键盘 thought: 当前需要按顺序输入1、2、乘号、8、等号 action: tap(140, 420) # 数字1 [step 3/10] action: tap(260, 420) # 数字2 [step 4/10] action: tap(200, 560) # 乘号 [step 5/10] action: tap(140, 680) # 数字8 [step 6/10] action: tap(380, 780) # 等号 [step 7/10] observation: 屏幕上显示结果为96 thought: 目标已达成任务完成 action: final_answer(96)看到final_answer输出就说明任务闭环成功了。整个过程模型会自主判断何时结束结束条件就是它认为目标已经达成并给出答案。这个结束判断机制特别重要没有它模型会在任务完成后继续乱点现在有了判断标准逻辑上完整了很多。3.4 关键参数的选择逻辑ARTEMIS配置里的参数不是随便填的每个参数背后都有性能和安全考量参数推荐值选择逻辑screenshot_interval_ms500~1000太快浪费token太慢可能漏掉界面状态max_steps15~30限制最大动作数防止任务死循环temperature0.2~0.5温度越低动作越保守稳定越高越有探索性language按任务语言设置中文任务用zh-CN描述更准确截图保存目录独立目录保留过程截图便于复盘和构建数据集我重点说下temperature这个参数。很多人觉得AI嘛温度高一点才有创造力但在移动端自动化这个场景里我强烈建议低温运行。任务是确定性的操作不是写诗模型动作越稳定越好。温度设到0.7以上模型偶尔会“灵光一闪”点出一些不可思议的位置那个排查成本很高。4. 任务引擎与VLM模型选型让AI稳定“干活”的细节4.1 任务描述怎么写成功率更高ARTEMIS的性能上限很大程度取决于你任务下发的质量。它不是搜索引擎你输入得越规范它执行得越稳。我总结了一套写任务指令的格式明确最终目标不要留歧义“打开设置把Wi-Fi切到已开启”比“帮我弄一下网络”靠谱一百倍注明前置条件“如果Wi-Fi已经开启就跳过这一步直接返回结果”限定操作边界“只操作相册应用不要进入设置”给出验证标准“执行完成后确认首页出现登录按钮”这里有一个生活化的类比你让一个实习生去办事任务描述越清晰他办砸的概率越低。ARTEMIS本质上就是一个永远不会累、但偶尔会幻觉的实习生你得把话说清楚还要在它跑偏时能拉回来。4.2 提示词模板与结构化输出ARTEMIS对模型输出格式有严格要求模型必须吐出结构化的动作指令而不是随心所欲的一段话。我用的系统提示词长这样你是一个手机操作助手只能通过结构化动作与手机交互。 当前任务{task_description} 当前屏幕信息{screenshot_url} 你的历史操作{conversation_history} 请分析当前屏幕输出下一步动作。必须使用如下JSON格式 {thought: 你的思考过程, action_type: tap|swipe|type|press_back|press_home|wait|final_answer, params: {...}} 注意 1. 如果任务已完成使用final_answer并给出结果。 2. 点击坐标必须是屏幕绝对坐标。 3. 优先选择可点击且有明确功能的元素。这个模板看起来简单但实际跑起来非常关键。它同时完成了三件事约束模型输出格式、强制模型先思考再行动、给定任务完成判定标准。如果你自己改模型一定不要省掉thought字段它会极大地提升后续调试效率。4.3 不同视觉模型的实测对比思路我很建议自己在本地测一测不同模型的效果。判断模型适配度的维度主要是视觉定位准确率、对中文界面文字的识别能力、对图标语义的理解能力、输出格式的稳定程度。这些维度里最容易被忽略的是“图标语义理解”。比如一个分享按钮在不同App里可能是一个箭头、一个方框加箭头、或者三个点组成的菜单视觉模型需要认出这些图标背后的功能含义而不仅仅是读文字。如果你的目标任务大量涉及跨App分享、菜单操作选购模型时就要重点看它在图标理解上的表现本地开源模型在这一项上普遍弱于云端商业模型。5. 落地场景与稳定性调优从Demo到能用5.1 值得优先落地的三类场景ARTEMIS部署起来不难但从Demo到生产可用中间隔着大量工程细节。我目前看到的价值场景主要有三类。第一是结合pytest这类框架做任务级回归编排。传统断言式测试是基于步骤的ARTEMIS可以把整个用户旅程当做一个任务来验证。比如注册登录流程不再每一步都写死定位符而是下发“完成新用户注册并断言首页出现欢迎语”这个自然语言任务由ARTEMIS自主完成。配合pytest组织测试集稳定性整体可控而且UI多次改版后测试脚本基本不用动维护成本下降非常明显。第二是探索性测试和崩溃发现。让ARTEMIS带着“随便逛逛这个App点击所有可操作入口遇到崩溃就记录下来”这类任务去执行它能跑出大量手工测试难覆盖的路径。我在某个项目里用它扫过几十个页面一部分深层页面的崩溃问题就这样暴露出来了。第三是跨应用流程自动化。这类流程传统自动化写起来最痛苦ARTEMIS反而最擅长因为它不受单应用边界限制。常见的图文分享、内容转发、多应用协同操作做起来都很顺语言表达能力的大模型在跨应用语义理解上的优势在这里发挥得比较明显。5.2 常见问题与排查技巧速查表我把自己跑ARTEMIS时遇到的坑整理成了一张速查表这里面的问题每一个都是真实踩过的现象可能原因解决方案点击坐标跑偏系统分辨率与截图分辨率不一致用DisplayMetrics换算坐标或统一模拟器分辨率中文输入乱码输入法拦截或ADB注入编码问题切换无障碍输入法或采用粘贴板方案权限弹窗中断任务任务过程中出现系统级弹窗启动前预清理权限或prompt中预设弹窗处理模型输出非JSON格式模型指令跟随能力弱增加格式示例解析失败后带错误信息重试步骤进入死循环没有识别界面无变化加入屏幕diff检测连续N次无变化则重置动作任务上下文被截断聊天历史过长压缩早期步骤动作用摘要文本替代截图点击操作用过快界面还没渲染完成适当延长screenshot_interval动作前加wait5.3 安全边界与合规提醒最后必须认真提醒一句ARTEMIS权限很大它通过无障碍服务拿到了几乎等同于你本人的手机操作权限。如果部署在正式Android应用或对外服务中必须做到三点敏感操作前有人工确认环节、所有操作轨迹留痕审计、不使用真实用户账号做无人值守的大规模自动化。涉及支付、账号、隐私数据等敏感场景尤其要慎重。我一般建议用沙箱环境、测试账号进行任务执行绝不让ARTEMIS直接操作个人真实账号中的资金或敏感信息。这个框架本身是强大的效率工具但安全性取决于使用它的工程团队防护措施做足体验会好很多。5.4 一点实战小技巧把执行记录沉淀成数据集最后分享一个我觉得很有价值的小技巧。ARTEMIS每跑完一个任务都会留下完整的屏幕截图序列、模型思考内容和动作序列。这些数据千万不要直接删掉它们天然就是高质量的“屏幕-动作”配对数据。我把这些数据清洗标注后沉淀成了一个小型训练集用于后续微调优化模型。执行记录经过拼装就能变成一份可复看的“设备操作演示视频”在问题复盘和团队分享时用处也很大。越用越顺手这大概是做移动端AI自动化最有成就感的一件事了。