做了七八年移动端自动化我越来越确信一件事把“点击屏幕上第三个商品”写成脚本很容易让机器自己看懂什么叫“第三个商品”才是真正难的地方。传统 UI 自动化工具在这个问题上努力了很多年始终绕不开一个死结——它们依赖的界面结构跟人眼看到的界面根本不是一回事。ARTEMIS 是谷歌最近开源的一个移动端 AI 自动化框架它想解决的就是这个死结让 AI 助手像人一样操作手机而不是像脚本一样机械执行坐标。这篇文章适合三类人。第一类是移动端测试开发天天写 UIAutomator、Appium 脚本被版本迭代和界面变动折磨第二类是正在做 AI Agent 应用的人想找一个可靠的移动端“手脚”去落地你的“大脑”第三类是纯好奇的爱好者想看看所谓“AI 操作手机”到底是真的智能还是又一个 PR 视频。我会把这套框架的原理、本地跑通路径和实测中踩过的坑一次讲清楚全程不回避问题。1. 为什么移动端自动化卡在了“看懂屏幕”这一步1.1 传统自动化工具的三个共同短板先别急着聊 ARTEMIS 有多强得先弄清楚它要替代的是什么。过去十年移动端自动化基本被三个技术路线统治基于控件树的 UIAutomator、基于坐标和截图的 Image Recognition、以及基于无障碍服务的 AccessibilityService。这套组合拳看起来很完整但实际用起来各有各的窝囊。基于控件树的问题在于它只能识别“愿意暴露自己”的控件。原生 TextView、Button 这种好办到了 Flutter、游戏引擎或者大量自定义绘制的界面整个视图树要么是空的要么是几块巨大的空白区域。你 dump 出来的 XML 和用户看到的屏幕完全对不上。坐标方案就更脆弱了。脚本写死(540, 1200)这个位置换一台分辨率不同的手机就废了即使同一台手机开了单手模式、弹出键盘、或者出现一个系统悬浮窗坐标整体下移点击全部错位。更别提很多 App 有开屏动画和过渡动画脚本辛辛苦苦等了个固定时间动画还没走完下一步操作就已经发出去。最隐蔽的短板是“状态机思维”。传统脚本本质上是预设路径从 A 点走到 B 点中间遇到什么情况都写在代码里。一旦出现没有预判到的弹窗、网络延迟导致的加载态、或者某个按钮文案从“立即购买”改成“马上抢”脚本就当场死亡。测试工程师常年干的一件事就是给脚本打补丁——这个地方加个if那个地方加个sleep——而不是让脚本“自己看情况办”。1.2 “像人一样操作”到底意味着什么人是怎么操作手机的看到屏幕理解当前状态结合任务目标决定下一步动作执行然后观察结果错了再纠正。这个过程和写脚本有本质区别脚本是“我早就知道要怎样”人是“我根据现场情况决定怎样”。ARTEMIS 想做的就是把这套人类行为模型搬到自动化框架里。它不再要求你预先定义每一步动作而是给 AI 一个任务目标比如“帮我在备忘录里创建一条关于项目周报的提醒”然后由 AI 自己去看屏幕、想办法、执行、反馈、修正。整个链路可以拆成四个环节感知界面、推理规划、执行动作、观察结果。这个思路在 LLM 大规模普及之前其实很难落地。原因很简单传统算法做界面语义理解的能力太弱了。你让一套规则引擎去分析“当前屏幕是一个商品列表第三件商品在促销”它能做到但成本极高而且换个 App 就全部推翻。大语言模型出现之后“理解截图 理解自然语言指令”变成了一个通用能力ARTEMIS 这类框架的价值才真正被释放出来。2. ARTEMIS 的核心链路从屏幕像素到可执行动作2.1 感知层UI 状态不是一张截图那么简单ARTEMIS 要解决的第一个问题是AI 怎么“看懂”手机屏幕。大多数人对这件事的理解是“给模型截个图”这远远不够。截图只是一个像素矩阵模型虽然能看图但有几个致命弱点。第一像素级别的信息量太大整张截图直接塞进模型推理延迟和 token 成本都不可接受第二纯视觉理解容易出错尤其是面对小字号的灰色提示、被折叠的菜单、状态栏和系统图标这类区域模型经常看错第三很多 App 的界面状态并不是静态的列表在滚动、进度条在转、弹窗在冒出来单张截图根本反映不了。所以 ARTEMIS 的感知层通常会做两个动作。一个是抓取视图树也就是通过无障碍服务拿到当前界面的控件层级和布局信息把“屏幕上有哪些可交互元素”这件事结构化成文本或者更高层的语义描述另一个是结合截图针对视图树缺失的场景做兜底。你可能会问视图树不是刚才还说不可靠吗对所以更合理的设计是把两者合并有视图树就用视图树没有视图树就退回视觉识别然后统一编码成一个对 LLM 友好的“界面状态表示”。这个表示才是关键。它决定了模型能不能理解“当前屏幕是一个商品详情页右上角有购物车图标底部有加入购物车按钮”。界面表示做得越干净、越结构化规划层推理出错的可能性就越低。2.2 规划层任务怎么被拆成可执行动作感知完成之后模型手里有一份“当前屏幕状态说明书”接下来要做的是决策——在众多可执行动作里选一个。ARTEMIS 一类框架通常会把动作空间限定在一个集合里点击、长按、滑动、输入、返回、等待。这些动作需要绑定到具体元素上而不是简单给一个坐标。比如“点击屏幕中央”这种动作是反模式的正确的方式是“点击 ID 为product_card_3的节点”或者“点击文本为‘加入购物车’的按钮”。规划过程本身是一个动态循环。比如任务是“打开设置里的 Wi-Fi 页面并连接指定网络”。模型看到桌面决定先找到“设置”图标点击进入设置主页后重新感知看到列表里有“WLAN”选项再点击进入 WLAN 页后感知当前网络列表找到目标 SSID执行点击和输入密码。每一步决策都依赖于上一步执行后的新界面状态。这个过程中最值得聊的是“约束”。一个裸奔的 LLM 在手机上随便乱点很快就能把自己带进沟里点了不可点击的文案、把系统设置改了、在支付页面误触了确认按钮。ARTEMIS 这类框架在规划层会有意识地做动作过滤和风险控制把明显不可逆的、敏感的动作拦下来至少要求额外的确认信号。这种约束不是限制框架能力而是让它变成一个可用的生产工具而不是玩具。2.3 执行与反馈操作之后怎么知道对不对执行动作这一步本身并不复杂点击就是adb shell input tap滑动就是adb shell input swipe整个动作周期可能不到 200 毫秒。真正难的是“操作之后怎么确认动作生效了、对不对”。如果没有反馈闭环AI 就是一个盲人只能靠猜。ARTEMIS 的做法是在每次动作执行后主动发起一次新的界面感知把执行前后的界面状态做对比然后判断是否离目标更近了一步。比如点击“加入购物车”后屏幕上出现了一个 Toast“已加入”或者购物车角标从 0 变成了 1这些都算正反馈如果点击之后没有任何变化那就要考虑是不是点错了、按钮被遮挡、或者页面还没加载完。这个环节最容易翻车的是“时机判断”。你以为点击之后界面已经稳定于是立刻感知结果动画还在播放、列表还在刷新拿到的状态是伪状态。更合理的做法是引入一个等待策略感知到界面上有“正在加载”“转圈”“骨架屏”这类特征时先等待再重新感知直到界面进入稳定状态再进行下一个决策。整个感知、规划、执行、再感知的循环其实就是人类操作手机的原子化版本。你把一个人操作手机的每秒钟拆开看本质也是这套循环。ARTEMIS 和传统自动化最根本的区别就在这里。3. 本地跑通最小闭环环境、依赖与一份可照抄的 Demo3.1 环境准备里最容易被忽略的三个细节聊完原理该动手了。不管你是想直接跑 ARTEMIS 的官方示例还是想先搭一套最小闭环验证一下思路基础环境都绕不开这几样一台 Android 手机或者模拟器、ADB 工具链、Python 3.10 以上环境以及一个能理解图片和界面文本的大模型接口。如果你用真机强烈建议优先选 Pixel 或者类原生系统手机。这不是崇洋媚外是因为原生系统对无障碍服务的兼容性最好国内定制 ROM 经常会杀掉后台的无障碍服务、限制 ADB 指令、或者弹一些奇怪的自启动管理窗口排查起来非常麻烦。模拟器也可以用但分辨率尽量固定在一个值别开自适应旋转不然下面的坐标问题会把你折磨死。开发者选项里有两个设置特别容易被忽略。一个是“USB 调试”要打开这个大家都知道另一个是“USB 调试安全设置”允许通过 ADB 修改权限或模拟点击的选项很多系统默认是关闭的不打开的话部分自动化动作会被系统拦截。连接之后先跑一句adb devices确认设备在线再跑一句adb shell wm size拿到当前分辨率这两个命令是后面所有操作的基础。3.2 一段能跑的决策循环截图、取 XML、问模型、执行在接入任何 Agent 框架之前我建议你先用一套“裸链路”把流程跑通。这套链路的核心就是四句话拿当前界面截图、拿界面 XML、丢给大模型问下一步动作、执行 ADB 命令。ARTEMIS 的封装本质上也是在优化这四步之间的衔接但你亲手把它跑一遍对框架的理解会完全不一样。以下是一段可以直接跑的最小 Python 脚本雏形我用的是最常见的 Android 调试工具链import subprocess import base64 import time def adb_exec(cmd: list) - str: 执行 ADB 命令并返回 stdout result subprocess.run( [adb, shell] cmd, capture_outputTrue, textTrue, encodingutf-8, errorsignore, ) return result.stdout def dump_ui_xml(): 抓取当前界面的视图树 XML 并拉到本地 adb_exec([uiautomator, dump, /sdcard/ui_dump.xml]) subprocess.run([adb, pull, /sdcard/ui_dump.xml, ui_dump.xml]) with open(ui_dump.xml, r, encodingutf-8) as f: return f.read() def take_screenshot(): 抓取当前屏幕截图并保存到本地 with open(screen.png, wb) as f: f.write(subprocess.check_output([adb, exec-out, screencap, -p]))拿到截图和 XML 之后构造一个给大模型的提示词核心内容是你有当前手机界面的截图和视图树任务是完成“XXX”请从候选动作tap、swipe、input、back、wait里选择一个返回并给出目标元素的坐标或文本描述。然后把模型返回的动作解析出来用 ADB 执行adb shell input tap X Y adb shell input swipe X1 Y1 X2 Y2 duration adb shell input text hello这一步看起来简单但它已经是一个真正的 Agent 闭环了。我见过很多人上来就去调 ARTEMIS 的完整 API环境配了一整天还没跑起来就是因为缺了这条最朴素的手搓链路。裸链路能跑通你才算真正具备了排查框架问题的前置知识。3.3 模型选型云端多模态还是本地推理框架只是骨架真正决定“智能”的是背后的模型。ARTEMIS 类的 GUI Agent 对模型有两个硬性要求第一是能理解截图也就是多模态能力第二是能输出结构化决策最好直接给出 JSON 格式的动作指令。如果走云端方案主流的选择是 GPT-4V、Gemini、Qwen-VL 这一档的多模态模型。实际测试下来这几家在“看图 理解界面 输出动作”上的能力都够用差异主要在延迟和成本。一次决策大概要消耗几千个 token其中截图占大头。如果你的任务环节很多一场完整流程跑下来消耗几十万 token 很正常做预算的时候要有心理准备。走本地方案的话门槛会高不少。界面截图这种高分辨率图像对显存要求很苛刻7B 级别的多模态模型勉强能用但推理速度在普通消费级显卡上会比较难受一次决策等十几秒根本没法做实时自动化。我的建议是先跑通云端方案验证效果等确认思路可行再考虑对延迟敏感的部分做本地化微调或者模型蒸馏。不要一上来就在本地部署上死磕。4. 实测中绕不开的四个坑偏移、动态界面、弹窗与输入4.1 坑一视图树坐标和实际渲染位置对不上ARTEMIS 的感知层拿到视图树之后模型天然会信任节点坐标。但在我实测的很多场景里视图树给的bounds和元素实际显示的位置就是有偏差。最典型的情况是 WebView 混合页面HTML 内容渲染出来的节点坐标经常偏移几十个像素Flutter 应用更极端整个界面可能只有一个根节点坐标范围覆盖全屏等于没坐标。遇到这种情况第一步排查永远是做“截图对照”。把当前截图拉下来再用开发者工具或 UIAutomator Viewer 打开同一时刻的 XML肉眼比对目标元素的视觉位置和节点bounds是否一致。如果偏移是固定方向的比如总是向下偏 100 像素很可能是系统状态栏或导航栏占据了部分空间视图树以全屏坐标计算而你设备的实际可用区域更小这种情况用adb shell wm size和adb shell wm density确认分辨率再做坐标归一化。如果偏移不固定就要考虑走视觉锚点方案。也就是不完全依赖视图树坐标而是让模型根据截图上的视觉特征自己估算点击位置。这个方法准确率会略降但能应对动态渲染和自绘 UI。ARTEMIS 的感知层如果只开了视图树模式碰到这种情况大概率翻车记得确认框架是否支持切换或合并感知模式。4.2 坑二界面是活的看一遍就动手必然出错第一次跑全流程的时候我低估了“界面是动态的”这件事对 AI 决策的破坏力。比如一个商品列表页模型看到第五个位置是“蓝牙耳机”决定点击它但就在模型推理的那两三秒里页面已经自动刷新第五个位置变成了“充电器”。模型还按旧状态执行点下去就歪了。更隐蔽的是延迟加载。列表快速滑动时底部还在加载更多搜索框输入关键词后联想词才慢慢蹦出来。如果你在界面未稳定时就去感知拿到的状态是残缺的决策质量必然下降。我的解决经验是给感知层加一道“稳定守卫”在执行动作前连续抓两次界面状态做 diff如果差异很小就认为稳定如果差异大继续等待并重新感知。同时在动作执行后加一个最小观察窗口别急着推进下一步。这套逻辑听起来像是给脚本加sleep但区别在于它是感知驱动的动态等待而不是拍脑袋的固定等待。4.3 坑三系统弹窗和权限浮层随时打断流程几乎所有移动端 Agent 跑到一半都会遇到一个头疼问题——系统弹窗。权限请求、App 更新弹窗、广告弹窗、优惠券弹窗、手机管家悬浮窗每一样都能把流程截断。传统脚本的做法是提前写好哪个弹窗、点哪个按钮但 Agent 面临的弹窗是开放式的你根本无法穷举。一个比较实用的思路是在规划层加入“弹窗处理优先”的默认策略每次感知界面后先让模型判断当前是不是异常浮层是的话先处理掉再继续主线任务。同时对高频的权限弹窗做预授权——在启动 App 之前把存储、定位、通知等权限提前用pm grant授予减少运行时弹窗的触发次数。这不能覆盖所有情况但至少能干掉一半的打断场景。另一个建议是给框架配置“任务禁区”。比如某些系统级页面、支付确认页、账号删除入口一旦感知到进入这些页面强制让 Agent 停下来等待人工确认。这个约束极其重要我宁可在流程上多一步人工点确认也不愿意让模型在无人监管的情况下误触敏感操作。4.4 坑四中文输入在 ADB 这条路上总是翻车最后这个坑看起来小实际杀伤力极大。adb shell input text是一个很低层的输入命令它只支持 ASCII 字符。你想让 Agent 在搜索框里输入“蓝牙耳机”命令发过去界面可能是空的或者出现一串乱码。我见过不少做 Agent 演示视频的人一到输入环节就卡住最后只能放慢动作录个屏幕键盘找补。常见解法是用剪贴板广播先把要输入的内容复制到系统剪贴板然后通过 ADB 广播一个粘贴事件让目标 App 接收。具体原理是利用 Android 的剪贴板服务命令大体是cmd clipboard set或者通过am broadcast发送自定义广播各家 Rom 实现不一稳定性要看目标设备的系统版本。更省心的方案是直接安装 ADBKeyboar 这类开源的 ADB 输入法它会监听 ADB 过来的广播消息并模拟真实键盘输入对中文输入法环境比较友好。这类输入法本质上是系统输入法的一种装好之后切到它再执行输入就能绕开input text的 ASCII 限制。不过要留意某些过于严格的国产 ROM 可能不会让第三方输入法稳定驻留所以在真机测试时先跑通输入再谈别的。5. 从 Demo 到生产ARTEMIS 落地前要想清楚的事5.1 评估 Agent 好不好用别只看最终成功率很多人测试 AI 自动化只看“任务最终完成了没有”这是个严重的误导。一次任务可能中途点错三次最后误打误撞完成也可能走了完全离谱的路径只是结果碰巧正确。生产环境里这种“碰巧成功”比失败还危险因为它不可复现、不可预测。我建议从四个维度去评估任务成功率、平均步数、平均耗时、异常恢复能力。成功率衡量最终结果平均步数是看 Agent 找路的效率人类 10 步做完的事 AI 花了 40 步说明决策质量不行平均耗时是把模型推理时间也算进去异常恢复能力最关键——就是遇到意外弹窗、界面错位、动作执行失败之后Agent 是能自己纠偏还是一路错到底。拿这四个维度做个简单的评分表跑二十组任务求平均比盯着一两个成功案例管用得多。我在选型任何 GUI Agent 框架时都会先做这组评估ARTEMIS 也不例外。5.2 落地场景自动化测试之外可能更有价值很多人第一反应是拿 ARTEMIS 做自动化测试这当然可以但我觉得它价值更大的场景是“跨 App 的复杂流程编排”。这类流程对传统自动化来说是灾难因为要跨越多个应用、处理各种状态但对 Agent 来说它天然是用自然语言理解任务的反而更擅长。另外一个值得尝鲜的方向是回归验证的“模糊探索”。让 Agent 在 App 里自由游走按预设的风险偏好随意点击、滑动、输入遇到崩溃或异常就截图留证。这可以覆盖掉很多测试用例设计时没想到的边界路径相当于请了一个不知疲倦的探索者帮你找问题。不过有一点风险必须反复提醒别拿它做支付、删除、账号注销这类高影响动作的无人值守自动化。Agent 再强也是概率决策是概率就有失败的可能。把这些环节设成人工确认或者干脆划出禁区保证系统边界稳定。5.3 我的扩展实践与一点收尾建议最后分享两个我自己扩展的做法。第一个是“动作白名单”在 ARTEMIS 的规划层外面再拦一道规则只允许 Agent 执行我指定的动作类型和操作范围比如禁止打开系统设置、禁止长按删除 App、禁止点击所有带“删除”“退出登录”字样的节点。这层约束放在模型之外从工程上兜底不依赖模型自觉。第二个是“全过程留痕”把每一步的截图、界面 JSON、模型思考内容、执行命令全部落盘。出问题的时候回放这个过程比任何日志都更直观。跑完这套流程之后我最大的感受是ARTEMIS 真正改变的不是自动化测试的写法而是我们和手机交互的抽象层级。过去我们用坐标、控件 ID 跟手机对话现在用自然语言任务跟手机对话中间的理解和翻译交给模型手脚交给框架。这套体系不会让所有脚本立刻消失但它会让那些真正复杂、真正反模式的场景第一次变得可以被自动化。如果你想试试看建议从今天的最小闭环开始不要一开始就追求全流程跑通。先把机制彻底理解清楚了再去碰框架的高级能力遇到的每一个问题你都会知道该从哪一层入手排查。