★ FEATURED ARTICLE 移动端 AI 自动化这两年一直挂着“看着热闹、落地稀碎”的标签。手机上的日常操作本质上就是“看屏幕、定计划、动手操作”这跟 AI 智能体最擅长的“感知、决策、执行”几乎是一一对应的可真的能让 AI 自己跑到手机里点按钮、滑页面、填表单的开源方案少之又少。ARTEMIS 是谷歌开源出来的移动端 AI 自动化框架它的核心目标非常直接让 AI 助手像人一样操作手机——拿到当前界面之后自己拆解下一步然后执行点击、滑动、输入这些真实操作。这篇不是翻译官方 README而是把 ARTEMIS 从原理到落地拆开讲清楚再附上我本地跑通一个 Demo 的完整经历和踩坑记录。适合这几类人看被移动端 UI 自动化脚本维护烦透了的测试开发、想自己搭一台手机助手的研究者、以及做 Agent 应用但执行端一直没找到好载体的产品团队。我先把结论放这儿ARTEMIS 的入门曲线确实比想象中低但“跑通”和“跑稳”之间隔着一堆工程细节如果你正准备上手这篇能帮你省掉不少弯路。1. 传统移动端自动化框架为什么卡在“像人操作”这件事上1.1 脚本第一步是定位控件这本身就限定了它的天花板传统移动端自动化方案Appium、UIAutomator、XCUITest 这些核心工作对象是控件树也就是 Android 里的 View Hierarchy 或者 iOS 里的 Accessibility 节点。测试代码里的核心语句永远是driver.findElement(By.id(xxx))、findElementByXPath(//android.widget.Button[1])这一类。这背后有一个隐含前提必须先拿到页面结构脚本才能做事。问题就出在这个“先有结构”上。现代移动应用大量使用服务端下发配置、动态渲染、跨端框架控件 ID 可能被混淆、结构可能随版本变化、甚至同一个按钮在不同 A/B 实验组里有着完全不同的标识脚本的维护成本会迅速失控。我见过不少团队自动化用例量看似庞大实际每个迭代光“修定位”就要花掉一半的排期这已经不是自动化而是新形式的体力活。1.2 跨端一致性折腾掉无数团队的半条命如果只做 Android 单端控件树方案勉强能用一旦要覆盖 iOS、鸿蒙或者小程序容器跨端方案就开始乱套。不同端拿出来的 UI 描述格式完全不同端描述结构常见痛点AndroidView Hierarchy / Accessibility NodeInfoID 混淆、动态布局错位iOSAccessibility 元素可访问性支持不完整列表元素被大量合并小程序/RN虚拟节点树与原生控件映射不稳定部分元素拿不到坐标跨端框架往往要自己再做一层抽象和原生桥接每一端都要单独适配。这个抽象层的代价不小而且一旦页面是 Canvas 绘制或者游戏渲染出来的控件树直接拿不到可用信息脚本立刻失效。1.3 最核心的缺口语义理解传统自动化脚本最缺的其实是对“屏幕在表达什么”的理解。举个真实例子购物 App 的“结算”按钮在控件树里可能叫tv_btn_pay也可能叫button_right也有可能因为动态布局压根没有稳定 ID。人看到页面结合“下单”这个意图能瞬间判断该点哪个位置脚本没有这个能力只能靠写脚本的人事先把所有可能性预测完。这就是传统方案的上限它们做的是“翻译已有结构”而不是“理解当前画面”。ARTEMIS 敢于拿 AI 模型来做自动化本质就是把“翻译结构”这一环替换成“理解意图”从根上解决语义缺失问题。2. ARTEMIS 的核心链路UI 感知、意图理解、动作执行2.1 一次完整操作循环拆开看只有四步ARTEMIS 的基本工作模式是一个智能体闭环。我把它拆成四个步骤观察获取当前屏幕截图同时把页面 UI 描述信息一并采集出来。推理把截图 UI 描述 用户任务一起交给视觉语言模型让模型输出下一步该执行什么动作。执行将模型输出的动作解析成系统级指令通过 ADB 通道模拟点击、滑动、输入。验证再次获取屏幕状态确认动作是否生效、任务是否完成不满足则回到第一步。这四步形成一个循环直到任务完成或者触发终止条件。从架构上看ARTEMIS 做的其实是把所有“脚本里写死”的东西全部外置给模型——定位逻辑外置、异常处理外置、任务拆解外置本地代码只保留“观察和执行”这两件确定性的事情。2.2 为什么“纯视觉”不够还得配合 UI 描述信息很多人做 AI 自动化的第一反应是“给模型截图就行”。但实际跑下来你会发现纯截图有太多坑坐标不精确模型看到的图是经过缩放的直接按像素坐标去点误差会大到离谱界面相似时容易误判两个卡片长得差不多模型根本分不清哪个是目标动态列表的时候截图上无法精确定位列表项的位置。ARTEMIS 的做法是“视觉 结构”双通道输入。截图负责表达视觉语义UI 描述信息负责把控件位置、可点击区域、文本标签这些结构化信息同步给模型。模型在推理时结合两种信息输出的动作坐标就会准确得多。打个比方截图是“看照片认人”UI 描述是“拿着通讯录对号入座”两者一结合准确率才有保障。2.3 动作类型的设计藏着一个很低调但很关键的细节ARTEMIS 定义的基础动作其实不多点击、长按、输入文字、滑动、返回、等待。各家 Agent 框架的动作集基本都长这样ARTEMIS 真正讲究的是每个动作参数带回退语义。举个例子“点击”动作不只要带上 x、y 坐标还带上了目标元素在 UI 描述中的索引或标识。这样一来模型如果发现点击之后页面没有任何变化就能立刻知道自己“点空了”然后在下一轮换个策略而不是傻傻地再点一次同样的坐标。这个“动作级自省”机制特别重要它决定了多步任务在真实手机上的成功率也是 ARTEMIS 和许多学生项目式 automator 拉开差距的地方。3. 本地部署实录从拉代码到跑通一个真实任务3.1 环境准备最容易被忽略的三个细节ARTEMIS 整体定位偏框架和研究验证本地跑起来依赖链并不复杂。我的环境是这样配的Python 3.10虚拟环境建议用venv而不是 conda后面装依赖省心。Android SDK platform-tools必须把adb加到系统 PATH。一台 Android 真机或者模拟器模拟器建议选 Pixel 镜像默认开了调试。一个可用的 VLM 服务地址和 KeyARTEMIS 默认对接的是兼容 OpenAI 接口的模型服务可以接云端服务也可以接本机部署的视觉模型。这里有一个特别容易踩的坑模拟器分辨率。ARTEMIS 最终的点击坐标需要从截图坐标映射到真实屏幕坐标如果你模拟器开了 240 DPI而模型服务拿到的是缩放到 512px 宽的截图映射系数一旦没配对点击位置会整体偏移。我建议第一步就把模拟器固定成一个常用分辨率比如 1080x2400后续调试省很多事情。3.2 拉代码、装依赖、写配置git clone https://github.com/google/artemis.git cd artemis python -m venv .venv source .venv/bin/activate pip install -e .装完依赖之后需要创建一个配置文件。ARTEMIS 的配置读取方式很常规我用的是 YAML 风格device: adb_host: localhost adb_port: 5037 serial: emulator-5554 model: provider: openai-compatible api_base: http://127.0.0.1:8000/v1 api_key: sk-your-key model_name: your-vlm-model max_tokens: 1024 temperature: 0.1 execution: max_steps: 30 retry_times: 3 screenshot_delay: 0.8temperature我强烈建议设成 0.1 或者更低。自动化任务里要的是确定性不是创造性温度一高模型就会开始给自己加戏输出一些莫名其妙的动作组合。3.3 第一次试跑让它帮我填一个登录表单我准备了一个最简单的测试任务打开一个测试 App输入账号密码点击登录。启动方式大致长这样python -m artemis.cli \ --config config.yaml \ --task 打开登录页在账号框输入 test_user密码框输入 123456然后点击登录按钮ARTEMIS 的循环开始跑之后日志会实时打印每一轮的动作和坐标。我这次跑了 7 轮完成中间有一轮“点击账号输入框”之后没有弹出键盘模型在下一轮选择了“轻触输入框的稍上方区域”来自救成功。这个第一次跑通的体验很微妙你会直观感受到跟传统脚本的“按行执行”完全不一样ARTEMIS 真的会在每一步执行完停下来重新看一眼屏幕、再决定下一步。它很像一个实习生做事会回头确认虽然慢一点但很少犯同样的错。4. 真正决定 ARTEMIS 能否落地的工程细节4.1 坐标映射模型输出 512 宽坐标手机要按 1080 宽执行这是所有视觉类移动端自动化项目都躲不开的问题。模型看到的截图经过缩放输出的是模型图像坐标系里的点但 ADB 注入点击事件需要的是原始屏幕坐标。ARTEMIS 在代码里做的是线性映射real_x model_x * (screen_width / image_width)。乍看很简单实际坑在截图的“相对坐标”有些界面有系统状态栏、底部手势条截图区域和可点击区域不是一回事。要处理的办法是在采集 UI 描述时一并将安全区域 inset 带出来做坐标修正时先裁剪掉非内容区域。我实测下来如果直接用全屏截图而不考虑状态栏页面上半部分的按钮点击准确率会出现明显下降尤其是那些贴近状态栏的元素。跑自动化之前先把截图裁剪规则理清楚这个时间花得最值。4.2 系统弹窗和应用内动效是打断循环的两大杀手自动化过程里最怕的不是模型理解错而是手机环境的稳定性被破坏。ARTEMIS 在执行过程中如果突然冒出系统权限弹窗、应用更新弹窗、甚至只是键盘弹起把布局顶上去整条链路就会从“预期路径”变成“随机路径”。我在跑表单任务时键盘弹起把输入框挤到屏幕上方点击验证码按钮时坐标偏移直接点到了旁边区域。之后我在配置里把每一步之间的等待时间加长到 0.8 秒并且在任务描述里增加了“如果出现系统弹窗先关闭弹窗”的前置约束成功率明显提升。这里给个我自己的经验清单系统内置测试机不要乱装工具类 App比如全局悬浮球、屏保、输入法增强都会干扰界面稳定性。关闭“动画缩放”开发者选项里的三个动画缩放全设为关闭能减少很多时序错乱。允许 ARTEMIS 用“跳过引导页”这类预动作避免首次启动进入欢迎流导致坐标全偏。4.3 终止条件无限循环比执行失败更可怕Agent 类框架最常见的翻车方式就是“死循环”。任务没法完成时模型会在几个动作之间反复横跳看起来像是真的在尝试实则一直在原地打转。ARTEMIS 本身有最大步数限制但这只是兜底不够。我建议在任务描述里额外强调“如果发现动作重复三次以上就停下来报告无法完成”然后通过配置文件里的max_steps再兜一层。把终止条件看成产品的边界而不是异常这对落地体验很重要——一次得体的失败比无限重试更能赢得用户信任。4.4 权限边界ADB 能做的事比你以为的多得多ARTEMIS 的本质是 ADB 通道的设备控制这意味它对手机的掌控能力非常强能安装应用、授予权限、读取日志、模拟各类触摸事件。框架本身没有恶意但一旦被滥用风险非常高。所以我在本地部署时坚持三条红线只用专门的测试机或模拟器不碰主力机。ADB 端口只对localhost开发不映射到局域网。不在生产环境开放 ARTEMIS 的接口就算团队内部要用也必须套一层任务白名单和审批流。移动端 AI 自动化的价值建立在“被信任”的基础上守住权限边界这个方向才走得长远。5. 基于 ARTEMIS 的落地场景从测试到个人助手5.1 移动端回归测试先拿“冒烟用例”试水ARTEMIS 最稳的落地场景就是回归测试里的冒烟用例特点是任务链路短、页面相对固定、结果容易判断。以前冒烟测试要写大量脚本现在只需要把验收动作写成自然语言就够了启动 App进入首页点击“我的”确认用户头像可见。这种任务对视觉模型来说非常简单稳定性很高。它不能完全替代传统自动化测试但能把测试团队从繁重的脚本维护里解放出来去处理那些真正需要深度场景覆盖的用例。5.2 个人手机助手让 Agent 模型拥有“手”和“眼睛”如果你在搭建个人的 AI Agent 类应用ARTEMIS 可以直接作为移动端的执行终端。很多项目卡在“模型思考得很好但没有手”ARTEMIS 正好把“手”补齐了。比如你给本地知识库助手下指令“帮我把今天新闻 App 的头条转发到便签”模型可以在语义层拆解任务然后在 ARTEMIS 的循环里一步步点击、跳转、复制粘贴。我用这个思路搭过一个原型虽然每一步都比人工操作慢但“无人值守地完成跨应用任务”这件事本身就是价值。5.3 企业级移动端 RPA效果好但要有“人机协同”心态企业场景里移动端 RPA 的需求一直存在比如供应链的验收流程、仓管系统的订单处理。ARTEMIS 在这些场景里表现非常亮眼因为企业移动应用往往结构老旧有些还是套壳 H5传统脚本反而难做。但企业环境有它自己的复杂度多账号切换、网络差导致的超时、多因素认证、数据安全要求。我合作过的几个项目最终都放弃了“全自动无人值守”的幻想改成“AI 负责常规操作人负责异常审批”这个混合模式反而最稳定团队接受度也最高。6. 关于选型和调优的个人经验总结ARTEMIS 不是一个“装上就能全自动”的银弹它更准确地说是给移动端 AI 自动化补齐了一块关键拼图。我经历过跑几十步任务一次成功的高光时刻也经历过模型在同一张弹窗图上来回转圈的尴尬场面。我的体会是在模型能力足够强的今天限制自动化上限的往往不是“模型会不会想”而是“工程能不能稳”。坐标映射对不对、UI 描述拿得全不全、终止条件有没有兜住、权限边界控制得紧不紧——这些不起眼的细节决定了 ARTEMIS 在生产环境是工具还是玩具。最后分享一个我自己的调试技巧给模型的任务描述不要把话说得太死比如“点击登录按钮”就比“点击坐标为 (720, 1200) 的按钮”稳健得多。ARTEMIS 的价值本来就在于模型自己会看、会判断你只需要把意图边界画清楚剩下的交给循环就好。
阅读完成 · 觉得有帮助？
