★ FEATURED ARTICLE 做移动端自动化这么久我越来越觉得传统那套“写死坐标和控件ID”的做法正在被一种新思路慢慢替代。那就是让AI直接“看”屏幕像人一样思考下一步点哪里、划哪里。谷歌开源的ARTEMIS就是这条路上一个非常有代表性的框架。如果你关注AI Agent、自动化测试或者单纯想让手机自动帮你干活这篇值得认真看完。ARTEMIS的核心其实不复杂你把一个自然语言指令扔给它比如“帮我把屏幕亮度调到最低”它内部会用大语言模型规划出几步操作然后通过识别屏幕截图来决定具体在哪个位置点击、滑动最后用Android的无障碍服务把动作执行出来。整个过程是“计划-观察-行动”的循环像极了一个真实用户拿着手机在操作。1. 为什么传统UI自动化脚本越来越让人头疼要理解ARTEMIS的价值得先知道我们以前是怎么做移动端自动化的。这一节算是个铺垫但确实值得掰开揉碎讲清楚。1.1 坐标与选择器写死的世界传统移动端自动化主流方案无非两种一种是基于坐标的比如老式的按键精灵那种直接把点击位置写死成(x, y)另一种是基于控件选择器的比如Appium、UIAutomator通过resource-id、content-desc、class name这些属性来定位一个按钮。坐标方案的问题显而易见只要屏幕分辨率一变、页面布局微调脚本就废了。我早年维护过一套基于坐标的脚本每次产品改版我都要花大量时间重新录屏、重新取点那种感觉就像在修补一栋地基每天都在晃的房子。控件选择器方案比坐标可靠但也有一个致命前提应用必须“配合”你把所有可交互的元素都暴露在无障碍树里。遇到那些用Canvas自绘界面的应用、游戏引擎渲染的UI还有大量WebView加载的内容选择器经常抓不到任何有效节点。你打开一个Flutter或者手游界面dump出来的XML里全是空的所有元素都是一块画布。这个问题的本质是传统自动化把“理解界面”这件事完全寄托在控件和布局上但移动端生态早就超越了这套体系。真实世界里的UI是画出来的、是动态的、是千变万化的用一套死板的属性去匹配天然就是脆弱的。1.2 真正像人的操作是视觉优先那人类是怎么操作手机的我们不会去看什么资源ID也不关心这个按钮在坐标(x, y)我们就是看一眼屏幕认出“这里有个亮度滑杆”“那里有个确定按钮”然后手指就过去了。ARTEMIS这个项目最打动我的地方就是它把操作从“坐标驱动”换成了“视觉驱动”。框架通过截屏拿到当前屏幕画面交给视觉模型去理解布局和元素再由语言模型根据理解结果决定动作。相当于把大模型训练时积累的“看世界”能力直接搬到了手机屏幕上。这里有朋友可能会问“这不就是多模态模型看图吗有什么稀奇的”关键区别在于ARTEMIS不是让你对着截图做一次性的问答而是把“看屏幕-决策-执行-再看屏幕”这个循环做成了闭环系统。每一步执行后都会重新获取屏幕状态和预期的目标进行比对错了就纠正没到位就继续直到任务完成或确认失败。这种结构化行为决策和单纯“看图说话”完全不是一个层面的事情。举个例子你让它“打开支付宝并完成一笔转账”它不会盲目地在一个布满键盘和数字的界面里乱点而是先识别出余额、转账入口、收款人、金额输入框这些元素再按部就班地操作每次点击前都会确认当前的屏幕状态。我觉得这才是AI操作手机应该有的样子。2. ARTEMIS的State Machine规划、观察、执行如何闭环如果你扒过ARTEMIS的源码或者看过它的论文会发现整个框架最核心的不是某个单独的模型而是一个设计得很清晰的有限状态机。别被“状态机”这个词吓到说白了就是一套“接下来该干什么”的流程控制逻辑。整个执行链路可以拆成四个环节我一个个讲。2.1 从自然语言到行动计划Planning第一步是意图理解。用户输入的那句话不管是“帮我把壁纸换成纯黑色”还是“打开抖音搜一下AI手机”ARTEMIS会先把这句话拆成高层行动计划。打个比方你说“帮我叫个外卖”如果是个真人他脑子里会先过一遍需要先打开外卖APP再选择商家再加入购物车再结算……这整个过程就是“高层规划”。ARTEMIS的编译器会利用大模型的语义理解能力把一句模糊的自然语言映射成若干个有顺序的子目标。这一步之所以重要是因为它把“做什么”和“怎么做”彻底分开了。“做什么”由大模型负责属于智能决策“怎么做”则由状态机负责属于工程实现。这种分层带来的好处是用户指令可以非常口语化甚至有点残缺系统也能结合上下文猜出意图。比如你说“把亮度调低点”它不需要问你亮度具体要调到百分之几而是自己根据当前屏幕画面判断亮度滑杆在哪然后做出适当的调整动作。2.2 屏幕感知与视觉TokenObservation规划做得再好如果看不到屏幕那就是闭着眼睛开车。ARTEMIS的屏幕感知模块有两条腿走路一条是通过Android无障碍服务抓取辅以补充的UI层级信息比如页面上有没有对话框、当前焦点在哪里另一条是直接截屏拿到视觉画面交给视觉编码器处理得到当前界面的语义描述。这里我想重点强调一下为什么视觉信息比纯UI层级可靠。很多同学在写自动测试脚本时都遇到过这种情况一个元素明明显示在屏幕上但用UIAutomator去查XML里里外外都找不到。原因可能是应用把文字绘制在了一张动态位图里也可能是一个自绘组件不向外暴露任何语义。ARTEMIS把视觉画面作为主要观察信号就绕开了这个短板。在实际执行中ARTEMIS并不需要把所有截图像高清图一样一字不差地送给大模型那样成本太高。它会把屏幕描述转换成结构化的文本token类似于“顶部有状态栏中间出现一个标题为xxx的对话框右下角有一个蓝色按钮标注为确定”然后带着这种观察结果去做下一步决策。这份感官信息会跟着每一轮Action一起送到模型里模型再产出对应的决策。也正是这种“当前屏幕状态 - 目标差距”的比对逻辑让系统有了纠错能力如果发现点击后界面没有任何变化它就知道这次操作大概率没生效。2.3 动作执行与状态转移Action有了计划和观察接下来就是动作执行。ARTEMIS定义了一套精心设计过的“动作空间”类似人的手指能力集合。常见的有点击根据视觉模型输出的坐标在屏幕上触发一个tap事件。滑动做上下滑动、左右滑动输入比如滚动列表、翻页。输入文本聚焦到输入框后用系统输入法注入文本。返回、回到桌面模拟系统级的导航手势。等待当页面处于加载状态或动画过渡期暂停等待。写成伪代码就是这样的if (current_state 盘点余额输入框) { perform_click(中心点判断); observe_screen(); if (检测到键盘弹出 输入框有焦点) { perform_input_text(100.00); } }你注意看这里面每一步都是有前置条件和后置校验的不是一股脑儿执行完就拉倒。执行完动作后系统必然重新获取一次屏幕状态判断自己是否真的进入了预期状态。这个“确认-再确认”的过程就是ARTEMIS比传统脚本稳的核心原因脚本是一次性赌博ARTEMIS是逐步验证的闭环。2.4 为什么State Machine而不是纯ReAct链路有些朋友接触过LangChain里的ReAct模式可能会问“为什么不让大模型自己无限循环直到任务完成非要套一个状态机”这也是我看了源码后最大的收获。纯ReAct虽然灵活但也有一个麻烦大模型在长序列任务里容易迷失会忘记自己已经做过哪一步、接下来应该做什么甚至会把“行动”和“观察”的逻辑搞混淆。一旦对话历史拉长token开销飙升出错概率也跟着水涨船高。ARTEMIS的状态机相当于给模型戴了一个“责任围栏”模型只负责在当前状态内选择合适动作状态转移的合法性由代码而非模型保证。比如点击后没有进入预期界面状态机可以强制回滚到重试状态而不是让模型自由发挥去点别的。这种设计牺牲了一部分“灵性”但换来了工程落地最需要的稳定性和可解释性。做自动化的人都懂AI再聪明也不可能把一个总是弹窗的应用操作得很丝滑而状态机至少能确保每次弹窗后都走同一条处理路径行为可预测、可复盘。3. 实战把ARTEMIS跑起来的最短路径说再多原理不如上手跑一遍。我花了大概一个下午在模拟器上把ARTEMIS完整跑通了一遍这里把整个操作流程和中间遇到的坑都记录下来。3.1 环境准备与源码构建ARTEMIS目前主要面向Android生态官方推荐的运行环境是Google Pixel系列手机或者带Google Play服务的模拟器。我这边用的是Android Studio自带的模拟器系统镜像选的是Android 13内存分配了4GB。环境准备四件套Android Studio最新稳定版确保SDK Platform和Build Tools都装齐了。一个能正常联网的构建环境因为要从GitHub拉源码、从Maven仓库拉依赖。一个可用的LLM API KeyARTEMIS的推理引擎需要调用大语言模型和视觉模型本地不具备完整的模型运行能力。一台Android设备或模拟器Android 9及以上系统并开启“开发者选项”里的USB调试。源码构建流程就是标准的Gradle操作git clone https://github.com/google-research/ARTEMIS.git cd ARTEMIS open -a Android Studio . # macOS用户可以用这个命令直接打开项目 # 然后在Android Studio中 # 1. 配置 local.properties设置 sdk.dir 路径 # 2. 等待 Gradle 同步完成 # 3. 构建 app 模块生成 debug APK构建完会得到一个APK文件。这里要提醒一下首次构建因为要下载大量依赖耗时可能从二十分钟到半小时不等中间如果网速不稳定容易出现Gradle同步超时。可以把Gradle的镜像源换成国内可用的Maven镜像速度会快很多。有个朋友可能会问为什么不直接从官方发布的渠道下载现成APK就我看到的ARTEMIS更接近一个研究性质的框架目前主要是源码形态对外开源。想体验的话自己构建是唯一可靠的路不过这也不是坏事构建过程本身能让你对这个框架的结构有个初步了解。3.2 我的第一个任务让AI帮我打开微信读书并开始听书构建完成并安装到模拟器后ARTEMIS会作为一个独立应用出现在桌面上。首次打开需要对它授权“无障碍服务”权限这一步是必须的否则它无法读取屏幕内容也无法帮你执行点击。授权界面和普通应用的权限申请差不多打开系统设置-无障碍-已安装的服务找到ARTEMIS并开启。开启后系统会弹一个警告大致意思是这个服务可以监控你的屏幕操作。做自动化的朋友对这个界面都很熟悉了不用慌这是Android系统的正常提示。我在ARTEMIS的输入框里直接输入中文指令“帮我打开微信读书然后开始播放我书架里的第一本书”。这里有个很影响体验的小细节指令尽量是“结果导向”的陈述句不要用反问句也不要牵扯太多中间条件否则大模型会把更多精力花在理解你的附加条件上反而忽略了主目标。提交指令之后我在执行日志里看到了非常清晰的过程[Planning] 用户意图分析完成 目标1: 打开微信读书应用 目标2: 进入书架页面 目标3: 点击第一本书并开始播放 目标4: 暂停且无需登录操作 [Step 1/3] Action: OPEN_APP(微信读书) Observation: 应用启动成功等待首页加载完成 [Step 2/3] Action: SWIPE_UP(short) Observation: 界面滚动书架区域出现在屏幕第三屏 [Step 3/3] Action: TAP(坐标(984, 1760)) Observation: 点击命中第一本书卡片音频播放页面出现说实话第一次看到这个日志的时候我是有点震惊的。它没有出现“找不到元素”“点击坐标越界”这种传统脚本常见的报错而是像一个人一样一边看屏幕一边找还自己做了个小滚动最终找到了目标。整个过程大概花了20秒左右比我手动去点还快。3.3 跑通之后立刻会踩的3个坑跑通“Hello World”之后我又连续试了七八个不同场景的任务成功的多翻车的也不少。这里挑三个我实际遇到的坑给大家排一下雷。第一个坑是无障碍服务没启用到位。有时候你以为自己开启了但Android系统会出于省电策略自动回收部分后台服务。判断是否开启的有效方法是随便给ARTEMIS发一个任务如果日志里提示“Unable to retrieve screen hierarchy”或者“Accessibility service not running”八成就是这个原因。重新去设置里关掉再开启服务一般就能恢复。第二个坑是API Key配置错误导致执行卡死。我第一次配置时不小心在API Key的前面粘了一个空格结果整个任务提交后一直卡在“Planning”阶段没有任何日志输出一度以为是我的模拟器卡死了。后来检查才发现是Key格式问题。这类问题非常隐蔽排查时不要只盯着代码逻辑先从最基础的配置项查起。第三个坑比较复杂也最值得警惕长指令任务中途容易“失忆”。我试着让它执行一个很复杂的任务比如“打开设置把WiFi关掉再回到桌面再打开计算器算一道乘法题”。任务前三个步骤都成功了但到计算器界面时它突然不知道自己要干什么了对着数字键盘发了好一阵呆。后来我重新给了条更聚焦的指令它又正常了。这其实就是大模型在长链路任务中的上下文漂移问题上面说的状态机虽然能约束动作合法性但约束不了模型自身的注意力分散。我的经验是复杂任务拆成两到三条独立指令分批执行远比一次性输入一个长句可靠。4. 实测能力边界哪些稳、哪些翻车一个框架好不好用不能只看演示视频里的高光时刻更要看真实使用时的翻车率。我花了一天时间让ARTEMIS帮我执行了一系列任务覆盖日常操作的各种类型。下面是我整理的实测表现。4.1 稳定区系统设置、打开应用、表单填写先说表现比较稳定的几类任务。系统设置类任务是我测试下来成功率最高的比如调整亮度、切换网络、修改壁纸、更改字体大小。这类界面通常很标准控件位置也比较固定视觉模型可以很轻松地识别出滑杆和开关。打开并操作指定应用也算稳定区。只要目标应用已经安装在设备上桌面上有对应的图标ARTEMIS基本都能可靠地打开并且能通过滑动找到不在首屏的应用图标。这替代了我以前脚本里的“启动Activity”操作——以前我得先知道应用的包名和Activity名现在只需要说“打开网易云音乐”它自己就处理了。表单填写类任务在ARTEMIS这里表现也不错但有个前提界面不能太复杂。普通的登录页、注册页它能识别输入框、能聚焦、能输入文字成功率相当高。我觉得这背后是大模型在海量网页和App截图上学到了一种“常识”——输入框长什么样、按钮该不该点这些认知被迁移到了手机屏幕上。我把整体稳定性数据整理成了一张表任务类型测试次数成功率失败原因说明系统设置调整亮度/网络/壁纸2095%极少数情况滑杆识别偏移进度条多拖了一格打开指定应用1593%桌面图标布局较密集时存在点击相邻图标的风险表格表单填写1275%复杂表单的必填校验、下拉选择偶发失误应用内跨页面操作1060%多个页面来回跳转时容易丢失原任务上下文游戏或画布类界面操作616%视觉模型无法把游戏UI映射成常规控件语义4.2 翻车区游戏场景、动态内容、登录验证同一类框架真正的技术难点其实不在“标准界面”里而在那些非标准的界面上。我专门下载了一个小游戏来测试结果ARTERMIS的表现很“拉胯”——它把游戏里的技能按钮误判成普通按钮把血条误判成进度条甚至会对着游戏内特效产生困惑长时间判断不出当前画面在发生什么。原因很好理解大模型训练数据里大量是普通应用的截图游戏UI非常特殊存在大量动态特效、自定义按钮、复杂的半透明图层视觉模型很难从中提取到稳定的操作语义。这也意味着如果你在做一个游戏自动化工具ARTEMIS暂时还替代不了那些针对游戏引擎做专门适配的方案。动态内容另一个翻车点是刷新列表和滚动加载。当屏幕上一个页面正在快速变化时比如短视频播放列表、实时滚动弹幕、倒计时动态ARTEMIS的观察模块会频繁“走神”——它无法准确判断当前帧里有价值的元素是哪几个导致点击偏靶。实测过程中我让它“打开淘宝直播并点进第一个直播间”它好几次把关注按钮当成了直播卡片。登录验证这类场景更是重灾区。当屏幕上出现滑块验证码、图形选字验证、拼图验证时ARTEMIS基本没有任何有效的办法。我试过一次让管理员完成滑块验证它艰难地拖动了好几次最后还是失败了。这里我想说不要期待AI能像人类一样轻松破解各种验证手段这类验证的设计初衷就是“防AI”ARTEMIS作为自动化工具自然也逃不过这个边界。4.3 长任务与状态回归问题除了任务类型差异我还专门测试了长链路任务的稳定性。结论很简单链路越长成功率越低。一个5步以内的任务比如“打开音乐App-搜索周杰伦-播放第一首歌-把音量调到70%-切到后台”成功率大概有七成。但一旦任务超过8步尤其是中间涉及页面回退、多应用切换时系统就开始表现出明显的“糊涂”它会走到第三步时突然以为自己已经走到第五步了或者在一个输入框已经填好内容后又去重新点了一遍输入框。状态回归问题是我认为ARTEMIS目前最大的短板之一。传统自动化脚本有一个特性一旦某一步失败整个流程就中断至少不会继续错下去。ARTEMIS虽然有状态机约束但它允许一定程度的重试和纠错这原本是优势但如果它错误地判定“当前状态已达成”就会跳过必要的步骤直接奔向下一个目标最后的任务结果自然就是错的。我自己的观察是ARTEMIS目前更像一个“比较优秀的用户代理演示框架”它的适用场景是完成中等复杂度、界面比较规范的日常任务。真的要拿来做生产级的自动化流水线还需要在状态验证的严谨性上做更多工作。5. 把ARTEMIS用进Agent移动端操作基座的后续扩展跑完测试以后其实我和一些朋友也聊过ARTEMIS现在最值得挖掘的价值到底在哪。我的判断是它不只是个玩具而是一个可以嵌入更大AI Agent体系的“操作基座”。最后一节分享一下我自己的扩展思路和选型建议。5.1 从“单任务助手”到“可编排Agent”ARTEMIS本身解决的是“如何安全可靠地在手机上执行一个动作”的问题。往上接一层规划器你可以把它变成更复杂的Agent。比如你可以用一段Python脚本作为调度中枢定义好一个业务流程的状态流转每个状态调用ARTEMIS去执行对应的手机操作把返回结果成功/失败/截图路径作为下一段的输入条件。这就是把手机操作抽象成一个函数库任何上层Agent都可以按需调用。我之前搭了一个很粗糙但够用的流程Agent先让ARTEMIS打开公司考勤App等待1.5秒后让它点击“打卡”按钮打卡完成后把结果截图回传如果失败触发ARTEMIS执行“截取当前屏幕并保存到指定目录”供排查使用。这一套下来虽然没有复杂的状态管理但已足够把手机侧的“手”接到外部的“脑”上。想要更工程化的话还可以在回调里加进重试逻辑、失败告警、记录完整执行轨迹做回放审计。ARTEMIS已经把最困难的“屏幕理解”和“动作执行”做掉了剩下的编排工作实际上就是普通的后端开发了。5.2 与RPA/Appium对比时的选型建议很多读者肯定想问ARTEMIS和Appium这类自动化测试框架到底怎么选。我的建议是看你是“测试用户流程”还是“执行用户操作”。Appium这类框架优势在于和测试生态深度绑定断言、报告、截图对比、CI/CD集成都很成熟。如果你是在做质量保障每天对同一个App跑几十遍固化的回归用例那ARTEMIS并不合适它的随机性和不确定性在测试场景里反而是致命的。你无法接受同一个用例这次点对了、下次点偏了。ARTEMIS的优势场景是“没有人明确告诉我正确的操作路径”的探索性任务。比如产品经理想验收“新用户首次登录的体验是否流畅”与其写一大堆选择器不如直接让ARTEMIS以自然语言方式跑一遍真实流程它能以更高的还原度模拟真实用户的行为了解、试错和最终完成。这类需求在Agent Demo开发、Lets Go级别的AI产品原型验证中特别有价值。所以我的选型建议很简单需要可重复、可断言、确定性的任务交给Appium需要以人机交互方式完成任务、且界面可预期性较弱的任务ARTEMIS目前更符合这类场景。5.3 个人注意隐私与权限边界最后聊一个偏使用体验的注意事项。用过ARTEMIS之后你会发现它其实是一把双刃剑——它能访问你屏幕上的一切内容包括聊天记录、银行卡信息、短信验证码等。所以使用的时候一定不要把个人敏感信息暴露在屏幕上更不要让它代为执行涉及支付、修改密码这类高风险操作。我个人的习惯是用法上把ARTEMIS限制在“低风险任务”区间比如帮你打开App、调整设置、浏览内容、填充非敏感表单。涉及转账、隐私数据读取、系统关键权限修改的一律手动介入。大模型的理解能力还不足以判断一个操作的真实风险后果作为使用者底线要靠自己守住。另外一点我在实际使用中发现ARTEMIS越用越顺手。它对同一个应用的识别精度会随着使用次数提升——可能是因为模型对当前界面的上下文有了更多积累。一开始它点错几次的界面跑了几轮之后明显准了许多。所以如果你真打算把它纳入日常工作流不要第一次失败就放弃多给它几次机会它的表现会比一开始好不少。
阅读完成 · 觉得有帮助？
