移动端自动化这个方向过去几年一直有个尴尬的瓶颈要么是基于坐标点击的脚本方案换个分辨率就全废要么是基于无障碍树的方案遇到自绘UI或者游戏画面直接抓瞎。谷歌开源的ARTEMIS算是给这个领域提供了一个新思路——让AI真正看懂屏幕然后像人一样去操作。我拿到这个项目之后花了两天时间跑通了完整链路中间踩了不少坑这篇文章就把整个探索过程拆开来讲从架构设计到环境搭建再到实际跑通一个自动化任务尽量把每个环节的为什么说清楚。1. ARTEMIS到底解决了移动端自动化的哪个核心痛点1.1 传统移动端自动化方案的两条死路先说清楚背景不然很难理解ARTEMIS的设计取舍。目前移动端自动化主流方案大致分两类第一类是基于控件树的方案典型代表是UiAutomator、Appium这类工具。它们的逻辑是通过系统提供的无障碍服务拿到当前界面的控件树然后根据控件ID、文本内容、层级关系来定位元素最后执行点击、输入等操作。这套方案在标准控件上很稳但问题也很明显——一旦遇到Flutter自绘、Unity游戏、Canvas绘制的界面控件树里可能只有一个空壳节点什么信息都拿不到。我之前做一个电商App的自动化任务商品列表页用的是自绘引擎整个页面在控件树里就是一个大框完全没法定位。第二类是基于图像匹配的方案比如Airtest、Sikuli这类。逻辑是截屏之后做模板匹配或者特征点匹配找到目标图片的位置然后点击。这套方案不依赖控件树理论上什么界面都能处理。但它的致命伤是脆弱性——换个主题、改个字体、调个亮度匹配就失败了。而且模板图需要提前准备维护成本极高。我见过一个团队维护了上千张模板图每次App改版都要重新截图运维成本比开发成本还高。这两条路走到最后都会撞墙核心原因是它们都缺乏对界面语义的理解。控件树方案理解的是结构语义图像方案理解的是像素语义但人类操作手机时用的是意图语义——我看到一个按钮写着确认订单我知道点它就能下单我不需要知道它的控件ID是什么也不需要记住它的像素长什么样。1.2 ARTEMIS的解题思路让多模态模型当眼睛和大脑ARTEMIS的核心思路就是引入多模态大模型来补上意图语义这一环。它的工作流程大致是这样的截屏获取当前手机屏幕的截图理解把截图和任务指令一起送给多模态模型让模型理解当前界面状态并决定下一步操作执行把模型输出的操作点击坐标、输入文本、滑动方向等通过ADB或者设备端Agent执行循环执行后重新截屏重复上述过程直到任务完成这个思路听起来简单但工程上的难点非常多模型输出的坐标怎么保证准确操作延迟怎么控制任务怎么分解异常怎么处理ARTEMIS在这些方面做了不少设计后面会逐一拆解。注意ARTEMIS目前还在快速迭代阶段API和架构可能会有变动。我写这篇文章时用的是当时最新的版本如果你跑的时候发现接口对不上建议先看官方仓库的README和examples目录。1.3 这个框架适合谁用从我的实际体验来看ARTEMIS目前最适合以下几类场景App自动化测试尤其是那些自绘UI多、控件树不完整的App传统方案搞不定的ARTEMIS可以兜底RPA流程自动化比如自动签到、自动填表、自动比价这类重复性操作AI Agent研究想研究多模态模型在GUI操作上的表现ARTEMIS提供了一个不错的实验平台无障碍辅助理论上可以帮视障用户操作手机不过目前延迟还偏高实际体验有待优化不太适合的场景也很明确对执行速度要求极高的比如抢购对稳定性要求极高的比如金融交易以及需要精确操作的比如精细绘图。这些场景目前还是传统方案的天下。2. 拆开ARTEMIS的架构三个模块如何协同工作2.1 设备端Agent跑在手机上的手和脚ARTEMIS的设备端部分负责实际执行操作。它有两种模式ADB模式是最简单的通过USB或者网络连接用ADB命令来截屏和执行操作。优点是部署简单不需要在手机上装任何东西。缺点是延迟较高一次截屏操作往返大概在200-500ms而且ADB连接本身有时候不太稳定。设备端Agent模式是在手机上跑一个轻量级服务直接调用Android的AccessibilityService和MediaProjection API。优点是延迟低截屏和操作都在本地完成一次循环可以控制在100ms以内。缺点是需要安装APK而且需要手动授予无障碍和录屏权限。我两种模式都试过如果只是做原型验证ADB模式足够了如果要跑长时间任务或者对延迟敏感建议上设备端Agent。下面是两种模式的对比对比项ADB模式设备端Agent模式部署复杂度低只需USB调试中需安装APK并授权单次循环延迟200-500ms80-150ms稳定性一般ADB可能断连较好本地通信适用场景原型验证、短任务长时间任务、延迟敏感场景权限要求USB调试无障碍录屏权限2.2 模型推理层决策的大脑这一层是ARTEMIS的核心。它需要把截图和任务描述转化成具体的操作指令。目前支持几种接入方式云端API模式直接调用多模态模型的API把截图base64编码后发过去。优点是模型能力强不需要本地算力。缺点是依赖网络有隐私顾虑而且按token计费成本不低。本地推理模式在本地跑一个多模态模型比如通过llama.cpp或者MLC来加载量化后的模型。优点是隐私好、无网络依赖。缺点是对硬件要求高而且小模型的理解能力确实有限。我实测下来云端API模式的效果明显更好尤其是界面元素多、任务复杂的时候。本地小模型在简单场景比如点击设置图标上还行一旦涉及多步推理就容易出错。模型输出的格式很关键。ARTEMIS定义了一套结构化的操作指令大致长这样{ action: click, coordinate: [540, 1200], reasoning: 界面上有一个确认按钮位于屏幕中下方 }支持的action类型包括click、long_press、swipe、input_text、back、home、wait等。模型需要根据当前界面状态选择合适的action并给出坐标或文本参数。2.3 任务编排层把大任务拆成小步骤用户给的是一个自然语言任务比如帮我在设置里把WiFi关掉。ARTEMIS需要把这个任务拆解成一系列可执行的步骤然后逐步执行。目前的任务编排有两种策略端到端策略直接把任务描述和当前截图送给模型让模型直接输出下一步操作。这种方式简单直接但模型容易迷失尤其是在长流程任务中可能执行到一半就忘了原始目标。分层策略先用一个规划模型把任务拆成子步骤列表然后每一步再调用执行模型。这种方式更可控但需要两次模型调用延迟翻倍。ARTEMIS默认用的是端到端策略但在prompt里会带上历史操作记录帮助模型保持上下文。我实测下来对于5步以内的短任务端到端效果不错超过10步的长任务建议还是用分层策略或者手动把任务拆好再喂给框架。3. 从零跑通ARTEMIS环境搭建的完整链路3.1 基础环境准备别小看这些细节先把基础环境列一下我踩过的坑会标注出来Python 3.10官方要求3.9以上但我建议直接用3.10或3.113.12有些依赖还没适配ADB工具确保adb命令在PATH里adb devices能正常列出设备Android设备或模拟器建议用真机模拟器的截屏和触控有时候会有兼容性问题多模态模型API Key如果用云端模式需要准备一个支持视觉输入的模型API提示Windows用户注意ADB的USB驱动有时候会抽风设备管理器里如果看到黄色感叹号需要手动装一下驱动。Mac和Linux一般插上就能用。安装ARTEMIS本身倒不复杂git clone https://github.com/google-research/artemis.git cd artemis pip install -e .但这里有个坑ARTEMIS依赖的一些包版本比较新如果你之前装过老版本的opencv或者numpy可能会有冲突。建议用虚拟环境python -m venv artemis-env source artemis-env/bin/activate # Windows用 artemis-env\Scripts\activate pip install -e .3.2 设备连接与权限配置最容易卡住的一步设备连接这块我卡了差不多半天把遇到的问题列一下问题一adb devices显示unauthorized这是最常见的问题。手机上会弹一个是否允许USB调试的对话框点允许就行。如果没弹试试在开发者选项里撤销USB调试授权然后重新插拔。问题二截屏返回黑屏有些App尤其是金融类会设置FLAG_SECURE禁止截屏。这种情况下截出来就是黑屏ARTEMIS没法处理。目前没有太好的绕过方案只能换App或者换测试环境。问题三点击坐标偏移这个问题很隐蔽。如果你的手机设置了显示缩放或者开发者选项里的最小宽度改过ADB的点击坐标和实际屏幕坐标可能对不上。解决办法是先用adb shell wm size确认实际分辨率然后在ARTEMIS配置里手动指定。设备端Agent模式的权限配置更麻烦一些安装Agent APK在设置里找到无障碍服务启用ARTEMIS Agent授予录屏权限每次重启手机都要重新授权这是Android的限制如果用的是Android 11以上还需要在adb shell appops set package PROJECT_MEDIA allow里额外授权3.3 模型接入配置云端还是本地配置文件一般在configs/目录下核心是模型相关的配置。以云端API模式为例model: provider: openai # 或者 anthropic, gemini 等 model_name: gpt-4-vision-preview api_key: your-api-key max_tokens: 1024 temperature: 0.1 # 建议调低减少随机性 device: mode: adb # 或者 agent serial: your-device-serial screen_width: 1080 screen_height: 2400temperature这个参数很关键。我一开始用默认的0.7模型经常输出一些创意操作比如把点击确认理解成滑动到确认按钮再点击。调到0.1之后稳定多了。做自动化任务要的就是确定性不需要模型发挥创造力。本地推理模式的配置稍微复杂一些需要指定模型路径、量化方式、推理后端等。我试过用llama.cpp加载一个7B的量化模型在M1 Mac上大概能跑到5 tokens/s勉强能用但理解准确率明显不如云端大模型。4. 跑通第一个自动化任务从打开设置到关闭WiFi4.1 任务定义与初始Prompt设计先从一个最简单的任务开始关闭WiFi。任务描述就一句话task 打开设置找到WiFi选项把它关闭ARTEMIS的入口大概是这样from artemis import ArtemisAgent agent ArtemisAgent(config_pathconfigs/default.yaml) result agent.run(task打开设置找到WiFi选项把它关闭) print(result)但实际跑起来第一版prompt效果并不好。模型经常在设置首页就迷路因为设置首页的选项太多了模型不知道该点哪个。后来我在prompt里加了一些引导task 任务关闭WiFi 步骤提示 1. 在设置首页找到网络和互联网或类似选项 2. 进入后找到WiFi选项 3. 点击WiFi开关将其关闭 注意如果当前已经在WiFi设置页直接执行第3步 加了步骤提示之后成功率从大概40%提升到了80%以上。这说明一个问题多模态模型虽然能看懂界面但在复杂界面上的决策能力还是有限需要人类提供一定的先验知识。4.2 执行过程的逐步拆解跑通之后我把每一步的截图和模型输出都打出来看了一遍整个过程大致是这样的第1步截屏显示设置首页。模型输出{ action: click, coordinate: [540, 680], reasoning: 看到网络和互联网选项位于屏幕上方区域 }第2步进入网络设置页。模型输出{ action: click, coordinate: [540, 420], reasoning: 看到WiFi选项当前显示为已开启状态 }第3步进入WiFi设置页。模型输出{ action: click, coordinate: [980, 380], reasoning: 右上角有一个开关控件当前为开启状态点击可关闭 }第4步截屏确认WiFi已关闭。模型输出{ action: finish, reasoning: WiFi开关已变为关闭状态任务完成 }整个过程大概用了12秒其中模型推理占了大部分时间每次调用大概2-3秒实际操作执行很快。4.3 成功率与失败案例分析我连续跑了20次成功了16次成功率80%。失败的4次里2次是模型点错了位置点到了旁边的选项1次是截屏延迟模型看到的还是上一帧的画面1次是WiFi开关的点击没生效可能是触控事件被系统拦截了针对这些问题我做了几个优化优化一增加重试机制。如果点击后界面没有变化自动重试一次。ARTEMIS本身有简单的重试逻辑但可以配置得更激进一些。优化二加入界面变化检测。每次操作后对比前后截图如果变化很小说明操作可能没生效需要重新决策。优化三坐标微调。模型输出的坐标有时候会偏几个像素可以在点击前做一个小的随机偏移避免总是点在同一个位置导致某些控件的点击热区没覆盖到。import random def adjust_coordinate(x, y, offset5): return ( x random.randint(-offset, offset), y random.randint(-offset, offset) )这个技巧在点击小控件的时候特别有用实测能把点击成功率提升10%左右。5. 实际项目中的坑与优化经验5.1 延迟优化从12秒压到5秒默认配置下一次完整的任务执行延迟很高主要花在三个地方截屏ADB截屏大概200-300ms设备端Agent可以压到50ms以内模型推理云端API一次调用2-3秒这是大头操作执行ADB点击大概100-200ms优化思路有几个第一换设备端Agent模式。截屏和操作延迟直接降一个数量级。第二用流式输出。如果模型支持流式返回可以在模型还在生成的时候就开始解析已经输出的部分提前执行。不过这需要模型输出格式比较规整不然容易解析出错。第三缓存界面状态。如果连续几步操作都在同一个界面可以复用上一次的截图不需要每次都重新截。这个优化需要谨慎因为界面可能在你不知道的时候变了。第四模型选型。不同模型的推理速度差异很大。我实测下来同样一个任务有的模型2秒出结果有的要5秒。如果对延迟敏感建议多试几个模型。优化之后一个4步的任务大概5秒左右能完成基本可用了。5.2 稳定性提升如何处理模型幻觉多模态模型的幻觉问题在GUI操作上特别明显。我遇到过几种典型的幻觉幻觉一看到不存在的元素。模型说看到右下角有一个确认按钮但实际上那个位置什么都没有。这种情况通常是模型根据任务描述脑补出来的。幻觉二误判元素状态。比如WiFi开关明明是开着的模型说是关着的然后就不操作了。幻觉三坐标计算错误。模型说点击屏幕中央的按钮但输出的坐标明显偏了。应对这些幻觉我总结了几个方法方法一在prompt里强调只根据截图内容决策。明确告诉模型不要脑补只根据实际看到的界面来操作。方法二加入验证步骤。每次操作后让模型确认操作是否生效。如果模型说已点击确认按钮但截图显示界面没变化就触发重试。方法三设置操作白名单。对于关键操作比如删除、支付加入人工确认环节避免模型误操作造成损失。方法四多模型投票。对于关键决策同时调用两个模型如果输出一致就执行不一致就重新决策或者人工介入。这个方法成本翻倍但稳定性提升明显。5.3 复杂任务的拆解策略前面提到长任务容易让模型迷失。我实际做的一个复杂任务是在电商App里搜索一个商品加入购物车然后进入结算页但不支付。这个任务大概有8-10步端到端跑成功率只有30%左右。后来我改成了分层策略手动把任务拆成几个阶段stages [ 打开App进入首页, 在搜索框输入无线耳机点击搜索, 在搜索结果中找到第一个商品点击进入详情页, 点击加入购物车, 进入购物车点击去结算, 确认到达结算页任务完成 ] for stage in stages: result agent.run(taskstage) if not result.success: print(f阶段失败: {stage}) break拆成阶段之后每个阶段的成功率都在90%以上整体成功率提升到了70%左右。虽然还是不够完美但比端到端好太多了。这里的关键是阶段之间的衔接。每个阶段结束时需要确认当前界面状态符合下一个阶段的起始条件。比如进入购物车这个阶段需要确认当前确实在购物车页面而不是还在商品详情页。6. 和其他方案的对比ARTEMIS的边界在哪里6.1 对比Appium互补而非替代Appium的优势在于精确和快速。如果控件树完整Appium可以在几百毫秒内完成一个操作而且100%准确。ARTEMIS的优势在于灵活控件树拿不到信息的界面它也能处理。我的建议是混合使用能用控件树定位的地方用Appium控件树搞不定的地方用ARTEMIS兜底。ARTEMIS本身也支持在prompt里传入控件树信息帮助模型更准确地定位。6.2 对比Airtest语义理解是降维打击Airtest依赖图像匹配ARTEMIS依赖语义理解。在界面变化频繁的场景下ARTEMIS的优势非常明显——不需要维护模板图界面改版了模型照样能看懂。但Airtest也有它的优势不依赖网络不依赖模型纯本地计算速度快且成本低。如果界面很稳定Airtest其实更划算。6.3 当前的能力边界用了这段时间我对ARTEMIS的能力边界有了比较清晰的认识能做的标准App的常规操作界面元素清晰可见任务步骤在10步以内对延迟要求不苛刻。做不好的游戏画面、视频内容、需要精细操作比如拖拽排序、需要理解复杂业务逻辑的任务。做不了的需要登录态保持的模型没法处理验证码、需要多设备协同的、对安全性要求极高的。7. 我对这个项目的一些实际体会ARTEMIS代表了一个方向用大模型的通用理解能力来替代传统自动化的规则化定位。这个方向我觉得是对的但目前还处于早期阶段工程成熟度离生产可用还有距离。最让我印象深刻的是一次测试中模型在处理一个从没见过的App界面时居然自己摸索出了正确的操作路径。那个App的控件树完全是空的传统方案直接歇菜但ARTEMIS通过视觉理解找到了正确的按钮。这让我看到了这个方向的潜力。但问题也很明显延迟高、成本高、稳定性不够。一个任务跑下来模型调用成本可能几毛钱到几块钱如果大规模跑成本不容忽视。而且80%的成功率在演示场景够用在生产场景远远不够。我的建议是现在可以把ARTEMIS当作一个实验性工具来探索但不要急着上生产。如果你的场景里传统方案确实搞不定可以试试ARTEMIS兜底但要做好人工介入的准备。等模型能力再上一个台阶推理成本再降一个数量级这个方向可能会迎来真正的爆发。最后分享一个实用技巧如果你要跑长任务建议在每一步操作后都保存截图和模型输出方便出问题的时候回溯。我一开始没存出了问题完全不知道是哪一步错了后来加了日志之后排查效率高了很多。ARTEMIS本身有日志功能但默认级别比较高建议调到DEBUG级别把每次模型调用的输入输出都记下来。