做移动端自动化的朋友应该都有同感传统测试框架解决的是“按脚本执行”而真正麻烦的是让程序学会“看着屏幕自主判断下一步”。谷歌开源的移动端 AI 自动化框架 ARTEMIS核心目标就是让 AI 助手像人一样操作手机——看到界面、理解任务、拆解步骤、执行点击与滑动再根据屏幕反馈调整动作。这篇文章我会从框架设计思路、核心原理、部署实操、选型对比到踩坑记录完整过一遍适合三类人做自动化测试想引入 AI 能力的、搞 LLM Agent 应用开发找落地方案的、以及想给自己的手机做个人 AI 助理的。1. 项目定位与设计思路拆解1.1 传统移动端自动化为什么不够用先聊一个很现实的问题。Appium、Espresso 这类框架的核心逻辑是“拿控件树按控件操作”底层依赖 Android 的 UIAutomator 或 iOS 的 XCUITest 去读取当前界面的控件层级和属性。听起来很美好但一落到真实场景就翻车游戏界面和 Flutter 自绘 UI 拿不到标准控件树拿到也是一堆没有语义的空白节点。WebView、RN、小程序里混合渲染层级深、嵌套多定位一个元素要写一长串 xpathUI 稍微一变脚本就碎。弹窗、权限提示、开屏广告这些“非预期元素”一旦出现脚本直接找不到目标控件原地报错。动态布局和动画场景下控件位置会变坐标型脚本更是脆得一碰就挂。这也是很多团队自动化维护成本居高不下的原因。脚本写的时候很爽三个月后维护起来想哭每周都在修定位器和等待时间。1.2 ARTEMIS 的路线选择视觉优先理解驱动ARTEMIS 换了一条思路不再把“控件树”当作唯一输入而是把“屏幕截图”当作主要感知来源配合 OCR、目标检测、图标识别、布局理解等技术先把屏幕转成模型能理解的结构化信息再交给大语言模型做任务拆解和动作决策。这个设计取向不是凭空拍脑袋。人在操作一部陌生手机时其实也不是靠“控件 ID”操作而是靠视觉我看到屏幕上有个“确认”按钮我知道点它会发生什么我看到某个图标像设置齿轮我会点开看看。ARTEMIS 本质上是把人的这套“看—想—动”流程搬到 AI 框架里。从工程角度说视觉优先还有一个好处跨平台适配成本低。只要截图和触摸注入能力具备同一套感知和决策逻辑可以同时跑在 Android、iOS 乃至车机、电视等带屏幕的设备上不用为每个平台的控件体系单独维护一套解析器。1.3 ARTEMIS 的三大核心模块感知、决策、执行从架构上看ARTEMIS 可以清晰地拆成三个层次感知层负责任务开始前的状态观察。拿到一张截图后先做分辨率归一化和必要裁剪然后并行执行多个视觉任务OCR 抽取所有可见文本目标检测框出按钮、输入框、卡片、图标布局模型分析元素之间的位置关系最终把结果汇总成一份带坐标的“界面语义快照”。决策层是大模型的主战场。系统把“界面语义快照用户任务描述历史操作记录”一起打包进 Prompt模型经过思考后输出下一步动作动作可以是 tap、swipe、input_text、back、wait 等类型也可以是一次“先观察再操作”的组合决策。执行层负责把模型输出的动作变成真实设备操作。通过 ADB 或系统的无障碍服务注入点击和滑动事件动作执行后再自动截图反馈给决策层形成“观察—决策—执行—再观察”的闭环。这三个模块各司其职最大的好处是每一层都可以单独替换。嫌默认模型效果不好换更强的视觉模型执行层觉得 ADB 注入不够自然可以换无障碍方案决策 Prompt 写得不够好也可以单独调优而不影响其它部分。2. 核心原理AI 如何“看”“想”“动”2.1 “看”从像素到可操作的界面语义AI 看屏幕和人看屏幕不一样。人扫一眼就知道这里有个输入框、那里有个发送按钮但模型拿到的是像素矩阵需要先做一层“翻译”。ARTEMIS 的做法是分路抽取信息而不是让大模型直接盯原图。第一路做文本识别把屏幕上所有文字连坐标一起抽出来比如“搜索商品”“购物车”“我的订单”分别在哪第二路做通用目标检测识别按钮、卡片、图片、输入框等 UI 元素第三路做图标理解很多 APP 的导航栏没有文字只有图标齿轮代表设置、房子代表首页、放大镜代表搜索这套图标语料需要预训练支持。三条路的结果会合并成一份结构化的界面描述。打个比方这相当于先让一个秘书把电脑屏幕上的所有窗口、按钮、文字列成清单再交给老板做决策。这样做的好处是大幅降低大模型的感知负担也方便定位——坐标信息可以直接用于后续点击。实际操作中你会发现这层最影响整体效果。截图清晰度不够、中文小字号文字被漏识、深色模式下按钮对比度低、图标语义含糊都会直接传导到决策层。所以框架通常会把截图切成若干区域分别识别用不同置信度阈值过滤垃圾结果再保留“可点击元素”单独标记。2.2 “想”任务拆解与动作规划感知完之后进入决策环节。ARTEMIS 并不指望模型一步到位生成整个流程而是采用逐步推理的工作方式每走一步模型看到的是一份最新界面状态、一段用户目标和一个历史动作序列然后思考当前应该做什么再输出一个具体动作。这种“走一步看一步”的方式非常接近人操作手机的真实习惯。比如任务目标是“打开系统设置把字体调大”模型不会一开始就输出十步动作而是先观察当前桌面思考第一步应该是点击“设置”图标执行点击后再观察确认进入了设置界面再想下一步去搜索“字体大小”。中间任何一步结果和预期不符模型都可以撤回、重试或换一条路径。为了在零样本场景下也能稳定工作框架会在 Prompt 里注入几个关键要素任务描述要具体最好包含“在哪个应用内完成、不能跳出 App、失败后怎么办”等约束条件。历史记忆要完整模型需要知道自己已经点了哪里、看到了什么结果否则很容易反复点击同一个地方。动作语法要明确输出格式是结构化的 JSON比如{action: tap, coordinate: [540, 1200]}方便执行层直接解析。推理过程要求先输出思考再给动作。这一步实测非常关键强制模型“先写理由再执行”误操作率比直接输出动作低很多效果也更好排查。2.3 “动”动作注入与反馈闭环决策层输出动作后执行层要做几件事。先把模型输出的逻辑坐标映射到设备真实物理坐标因为不同手机分辨率、状态栏高度、屏幕比例都不一样坐标映射错了就会出现“点了但没点对地方”的情况再选择合适的注入方式模拟点击、坐标滑动、文本输入分别对应不同的系统指令最后做动作后校验重新截图去确认这次操作是否真的改变了界面状态。一个容易被忽略的点是“操作的粒度”。早期很多方案习惯把“打开设置—找到字号—调大”拆成连续多次 adb 命令一次性执行完这样速度快但风险极高一旦中间弹出权限弹窗或焦点变化整个操作链就全歪了。ARTEMIS 选择每一步都校验虽然慢一些但稳定性和可追踪性完全不一样。真机上的动作注入也有讲究。部分系统对 adb 模拟点击有限制尤其是 Android 12 之后的“最小化触摸区域”和部分定制 ROM 的安全策略会吞掉一些坐标注入事件。更稳定的方案是通过无障碍服务执行点击和用户真实手势的兼容性更好但需要额外开启无障碍权限。这一层在实际部署时建议先跑通最小点击样例再做完整流程。3. 从零跑通环境搭建与实操流程3.1 环境准备与最小依赖想本地跑起来体验一下建议准备以下环境一台能跑 Android 模拟器的电脑或者一台开了 USB 调试的真机。Python 3.10 以上环境用来运行框架入口和依赖服务。一个可用的 LLM 接口OpenAI 兼容 API 或本地部署的 Ollama / vLLM 服务都可以模型建议选支持工具调用和视觉理解的版本。ADB 环境确保命令行执行adb devices能看到设备。克隆 ARTEMIS 仓库后通常需要先安装 Python 依赖再配置模型服务地址和环境变量。这步没什么黑魔法核心是把“设备接口”“模型接口”“视觉模型接口”三个配置填对。有一点经验要提前说如果是第一次跑强烈建议先用模拟器而不是真机。模拟器的分辨率统一、可随时重置、不怕误操作弄乱系统对调试 Agent 动线非常友好。真机等整套流程稳定后再换不然一个误点击可能就进入了支付页面。3.2 最小复现让 AI 自主完成一个简单任务这里给一个最简的复现路径方便快速验证整套链路是否通。第一步启动模拟器确认adb devices可以正常发现设备记住设备序列号后面所有命令都要绑定这个设备。第二步初始化 ARTEMIS 会话。以“打开计算器执行 12 乘以 8 等于多少”为例先确认模拟器桌面上能看到计算器图标任务描述越明确模型越不容易跑偏。第三步执行自动化过程。框架会循环执行“截图 — 感知 — 模型决策 — 执行动作 — 再截图”这个过程在命令行或日志面板里可以看到每一步的思考输出和动作结果。第四步检查结果。任务完成后查看最终界面状态是否停留在计算结果页面同时核对执行日志里是否出现过无效路径或重复点击。这个最小用例跑通说明感知、决策、执行三条链路都没问题。如果卡在某一步先快捷键截一张当前设备截图手工看感知结果是否识别出了目标控件问题基本能定位一半。3.3 实操记录一个完整任务的执行轨迹拿“打开系统设置把字体调到最大”来说我实际操作时记录到的典型轨迹是这样的第一步模型观察到桌面图标列表识别出“设置”应用图标输出 tap 动作坐标在图标中心点击成功系统进入设置首页。第二步模型观察到设置首页有搜索框和分类列表但没有直接显示“字体大小”入口于是输出 swipe 动作向上滑动列表等待出现“显示”分类。第三步模型识别到“显示”项点击进入在显示设置里找到“字体大小”选项。第四步模型识别到字号调节滑块输出一次长按拖拽动作向右滑到底再截屏确认字号预览变大任务完成。整个过程大约 40 多秒比人工操作慢不少但完全自主完成没有任何手工干预。这个案例里最关键的一步是第二步的滑动决策因为“字体大小”藏在二级菜单里单靠第一屏截图看不到模型必须会“翻页寻找”。这也是这类框架比传统坐标脚本最有价值的地方面对动态布局它知道要去找。日志排布上建议把每次循环的模型思考、动作 JSON、截图文件名都记录下来。之后调试或者复现问题时这三个信息缺一不可。3.4 分辨率适配与显示参数调整不同模拟器和真机的分辨率差异直接影响坐标映射和视觉识别效果。分辨率太高截图非常大视觉模型处理慢分辨率太低小字和图标识别不清感知层就有问题。一个可行的适配策略是在感知阶段把原图压缩到 720p 左右做识别但在执行阶段仍按原始物理分辨率计算点击坐标。另一个细节是状态栏和导航栏的高度偏差。很多界面元素坐标是相对整个屏幕的但 Android 的沉浸式模式下内容区域会延伸到状态栏后面点击坐标可能被系统手势区域吞掉。实测最稳的方式是感知阶段就让视觉模型只处理内容区域识别结果里直接滤除顶部状态栏和底部导航栏的候选框。颜色和主题适配也值得关注。深色模式下文本对比度高OCR 反而更好但部分浅色背景上的白色按钮目标检测模型容易漏掉。如果目标 App 用的是特殊主题色可以在感知层做一次简单的颜色增强或灰度化效果提升非常明显。4. 选型对比与落地场景ARTEMIS 和同类方案怎么选4.1 与传统自动化测试框架的对比很多团队第一次接触 ARTEMIS 都会问这和 Appium 到底什么关系是不是要取代它。从我的实践看两者不是替代关系而是解决不同层级的问题。维度ARTEMISAppium / Espresso纯坐标脚本依赖控件树不依赖以视觉感知为主强依赖拿不到控件就废不依赖但不知道界面状态智能决策有模型自主拆解任务无脚本定死操作路径无脚本定死坐标路径应对动态布局强会自主寻找目标弱UI 一变脚本就挂极弱布局一动全盘崩维护成本低换界面描述即可高元素定位器精维护高坐标定期重录对 LLM 服务依赖强需要模型接口无无稳定性中等依赖模型质量高但前提元素可定位中依赖无弹窗无干扰一句话总结如果目标是每日回归、稳定可重复的测试执行传统框架仍然高效可靠如果目标是应对动态 UI、探索性测试、未知流程验证ARTEMIS 这类 AI 驱动的框架价值更大。4.2 与移动端 LLM Agent 类方案的区别市面上已经有不少“让大模型操作手机”的研究项目比如 Mobile-Agent、AppAgent思路和 ARTEMIS 同源。ARTEMIS 的优势在这个背景下会更明显工程化程度高设备管理、截图流程、动作注入、日志追踪都是框架自带能力而不是研究代码拼接。模块可替换性更强感知模型、规划模型、执行器都能独立更换方便接入自己的模型和优化策略。作为谷歌推动的项目其后续迭代、社区支持和生态挂接有明显优势在 Android 系统能力深度结合上有更大想象空间。选型时一个实用建议是如果只是做个 Demo 验证可行性任何 Agent 方案都可以如果要接到真机环境长期使用优先选工程完整度高、有活跃维护的框架。4.3 适合的应用场景与边界我实际验证下来ARTEMIS 在下面这几类场景里效果最好探索性自动化测试。不想写具体脚本让 AI 自己在 App 里“乱逛”发现崩溃和异常跳转这个场景对感知能力要求高但容错也高很适合 AI。跨应用任务代理。比如从短信中提取验证码填入另一个 App再返回原界面这种跨应用切换对传统自动化是噩梦对 ARTEMIS 反而简单。辅助功能演示和流程录制。做产品演示时演示脚本最怕环境变化AI 自主操作可以临场应变比录屏脚本体面得多。无障碍辅助。为视障用户设计的自动操作方案AI 可以理解语音指令并转换成 UI 操作。但也要说清楚边界。毫秒级点击、高频重复操作、对精度有严格要求的场景不合适AI 决策意味着每次操作都有耗损和不确定性纯离线环境也不合适就算本地模型能跑决策质量相比在线 API 还是有差距涉及支付密码、验证码输入等安全敏感流程建议不要交给自动化代理风险不可控。5. 常见问题与调优经验实录5.1 误识别与点击错位最常见的坑是视觉模型把界面元素认错。比如 OCR 把“取消”识别成“确定”目标检测把广告卡片误判为功能按钮图标识别把“我的”看成“购物车”。一旦感知层出问题决策层再聪明也白搭。我的排查思路是先在“观察模式”下跑流程不去执行动作只看每一轮的界面语义快照是否正确。绝大多数误识别都能在这一步暴露。修的时候可以叠加两个手段一是提高视觉模型置信度阈值让它少报但不能乱报二是在 Prompt 里补充界面来源信息比如“这是一个电商 App 的首页左侧是分类列表右侧是推荐商品”让模型结合业务常识去判断。点击错位的另一个来源是坐标映射。模拟器分辨率设置和感知层压缩比例不一致输出的点击坐标就会偏移。解决方法是固定一套分辨率设置感知层统一按 1080p 处理执行层做等比缩放换算实测可以消灭绝大多数错位问题。5.2 任务卡死与循环点击AI 自动化跑久了偶尔会出现“卡死”现象典型表现是反复点击同一个位置、不停上下滑动、或者在一个页面里来回进出。根因通常是任务的进度判定失效了模型分不清当前状态是“已经做过”还是“还没做过”。处理这个问题有两个实用手段。第一是设置最大步数上限比如规定最少完成 20 步内完成任务超出则停止并导出日志第二是引入相似状态检测每次截图后和最近几步截图做相似度比对连续 N 步界面无变化时强制中断并让模型换一条操作路径。更有效的办法是在 Prompt 里要求模型维护一个“已完成动作清单”每次决策前先读一遍清单避免重复执行。我实测这个简单改进能把无效循环减少五成以上。5.3 延迟控不住操作一顿一顿每步操作都需要截图、识别、模型推理、执行、再截图一个环节慢了整体就跟着慢。想优化先分清瓶颈在哪视觉识别慢还是决策慢截图传输慢还是动作执行慢。常见优化套路是这几条截图压缩后传输把 PNG 转成 JPEG 或降低分辨率减少传图耗时。视觉模型和 LLM 并发感知结果做缓存界面没大变化时不重复识别。本地部署小型视觉模型专门做元素识别大模型只负责决策分工后延迟下降明显。模型降到 4-bit 量化延迟能接受且质量损失可控本地跑推荐优先尝试。对任务响应时间要求不高的场景延迟优化不用太激进稳定优先。5.4 权限、安全与合规一层最后说一个必须重视的问题AI 能像人一样操作手机意味着它也拥有和你一样的设备权限。支付类、金融类、社交类 App 的敏感操作尤其是密码输入、验证码填写、转账确认绝对不要让自动化代理碰。平台权限弹窗也要特别小心AI 一旦误点了“允许”授权后面可能引发一串连锁反应。推荐做法是让 ARTEMIS 运行在隔离环境或专用测试机上不登录真实账号不接入真实支付渠道。实测很多自动化团队踩坑都是因为在一个绑定真实账号的设备上跑代理结果 AI 误触发了转账操作补救非常麻烦。权限控制上尽量用 adb 级别的注入权限并手动开启受控的无障碍权限不要为了省事把所有权限打包放行。日志脱敏也很重要截图里难免出现消息内容、通讯录、位置信息团队内部要约定好日志保存和清理策略。5.5 一个值得尝试的混合模式根据我的实操体验ARTEMIS 最稳的用法不是做“纯自主 Agent”而是做“混合执行器”让 AI 负责理解和决策但把高频重复动作交给脚本原子操作去执行。比如模型决定“下一步需要输入一段文本”文本输入可以直接调用一个预置的稳定注入函数而不是让模型生成字符再逐个输入模型决定“上滑三次回到顶部”可以直接执行一段封装好的手势脚本。这样做的好处是既保留了 AI 对动态界面的适应力又把最容易出错、最需要稳定的动作交给确定性代码整体成功率能上一个台阶。把这个混合模式做成配置化策略在人工介入率、执行耗时、任务成功率三个指标上会表现得非常均衡。最后再分享一个小经验新接一个目标 App 时不要急着跑完整任务。先让 ARTEMIS 在这个 App 里自由探索五分钟产出一份“界面元素统计清单”看看每个页面的感知覆盖率是多少再针对性补充图标语料或调优 Prompt。这套准备工作做完正式跑任务时的成功率会高很多也少踩很多动态布局的坑。 
长河君 · 2026/11/3 18:07:18 · 阅读 1.2k 谷歌开源ARTEMIS：视觉+大模型驱动移动端AI自动化
做移动端自动化的朋友应该都有同感传统测试框架解决的是“按脚本执行”而真正麻烦的是让程序学会“看着屏幕自主判断下一步”。谷歌开源的移动端 AI 自动化框架 ARTEMIS核心目标就是让 AI 助手像人一样操作手机——看到界面、理解任务、拆解步骤、执行点击与滑动再根据屏幕反馈调整动作。这篇文章我会从框架设计思路、核心原理、部署实操、选型对比到踩坑记录完整过一遍适合三类人做自动化测试想引入 AI 能力的、搞 LLM Agent 应用开发找落地方案的、以及想给自己的手机做个人 AI 助理的。1. 项目定位与设计思路拆解1.1 传统移动端自动化为什么不够用先聊一个很现实的问题。Appium、Espresso 这类框架的核心逻辑是“拿控件树按控件操作”底层依赖 Android 的 UIAutomator 或 iOS 的 XCUITest 去读取当前界面的控件层级和属性。听起来很美好但一落到真实场景就翻车游戏界面和 Flutter 自绘 UI 拿不到标准控件树拿到也是一堆没有语义的空白节点。WebView、RN、小程序里混合渲染层级深、嵌套多定位一个元素要写一长串 xpathUI 稍微一变脚本就碎。弹窗、权限提示、开屏广告这些“非预期元素”一旦出现脚本直接找不到目标控件原地报错。动态布局和动画场景下控件位置会变坐标型脚本更是脆得一碰就挂。这也是很多团队自动化维护成本居高不下的原因。脚本写的时候很爽三个月后维护起来想哭每周都在修定位器和等待时间。1.2 ARTEMIS 的路线选择视觉优先理解驱动ARTEMIS 换了一条思路不再把“控件树”当作唯一输入而是把“屏幕截图”当作主要感知来源配合 OCR、目标检测、图标识别、布局理解等技术先把屏幕转成模型能理解的结构化信息再交给大语言模型做任务拆解和动作决策。这个设计取向不是凭空拍脑袋。人在操作一部陌生手机时其实也不是靠“控件 ID”操作而是靠视觉我看到屏幕上有个“确认”按钮我知道点它会发生什么我看到某个图标像设置齿轮我会点开看看。ARTEMIS 本质上是把人的这套“看—想—动”流程搬到 AI 框架里。从工程角度说视觉优先还有一个好处跨平台适配成本低。只要截图和触摸注入能力具备同一套感知和决策逻辑可以同时跑在 Android、iOS 乃至车机、电视等带屏幕的设备上不用为每个平台的控件体系单独维护一套解析器。1.3 ARTEMIS 的三大核心模块感知、决策、执行从架构上看ARTEMIS 可以清晰地拆成三个层次感知层负责任务开始前的状态观察。拿到一张截图后先做分辨率归一化和必要裁剪然后并行执行多个视觉任务OCR 抽取所有可见文本目标检测框出按钮、输入框、卡片、图标布局模型分析元素之间的位置关系最终把结果汇总成一份带坐标的“界面语义快照”。决策层是大模型的主战场。系统把“界面语义快照用户任务描述历史操作记录”一起打包进 Prompt模型经过思考后输出下一步动作动作可以是 tap、swipe、input_text、back、wait 等类型也可以是一次“先观察再操作”的组合决策。执行层负责把模型输出的动作变成真实设备操作。通过 ADB 或系统的无障碍服务注入点击和滑动事件动作执行后再自动截图反馈给决策层形成“观察—决策—执行—再观察”的闭环。这三个模块各司其职最大的好处是每一层都可以单独替换。嫌默认模型效果不好换更强的视觉模型执行层觉得 ADB 注入不够自然可以换无障碍方案决策 Prompt 写得不够好也可以单独调优而不影响其它部分。2. 核心原理AI 如何“看”“想”“动”2.1 “看”从像素到可操作的界面语义AI 看屏幕和人看屏幕不一样。人扫一眼就知道这里有个输入框、那里有个发送按钮但模型拿到的是像素矩阵需要先做一层“翻译”。ARTEMIS 的做法是分路抽取信息而不是让大模型直接盯原图。第一路做文本识别把屏幕上所有文字连坐标一起抽出来比如“搜索商品”“购物车”“我的订单”分别在哪第二路做通用目标检测识别按钮、卡片、图片、输入框等 UI 元素第三路做图标理解很多 APP 的导航栏没有文字只有图标齿轮代表设置、房子代表首页、放大镜代表搜索这套图标语料需要预训练支持。三条路的结果会合并成一份结构化的界面描述。打个比方这相当于先让一个秘书把电脑屏幕上的所有窗口、按钮、文字列成清单再交给老板做决策。这样做的好处是大幅降低大模型的感知负担也方便定位——坐标信息可以直接用于后续点击。实际操作中你会发现这层最影响整体效果。截图清晰度不够、中文小字号文字被漏识、深色模式下按钮对比度低、图标语义含糊都会直接传导到决策层。所以框架通常会把截图切成若干区域分别识别用不同置信度阈值过滤垃圾结果再保留“可点击元素”单独标记。2.2 “想”任务拆解与动作规划感知完之后进入决策环节。ARTEMIS 并不指望模型一步到位生成整个流程而是采用逐步推理的工作方式每走一步模型看到的是一份最新界面状态、一段用户目标和一个历史动作序列然后思考当前应该做什么再输出一个具体动作。这种“走一步看一步”的方式非常接近人操作手机的真实习惯。比如任务目标是“打开系统设置把字体调大”模型不会一开始就输出十步动作而是先观察当前桌面思考第一步应该是点击“设置”图标执行点击后再观察确认进入了设置界面再想下一步去搜索“字体大小”。中间任何一步结果和预期不符模型都可以撤回、重试或换一条路径。为了在零样本场景下也能稳定工作框架会在 Prompt 里注入几个关键要素任务描述要具体最好包含“在哪个应用内完成、不能跳出 App、失败后怎么办”等约束条件。历史记忆要完整模型需要知道自己已经点了哪里、看到了什么结果否则很容易反复点击同一个地方。动作语法要明确输出格式是结构化的 JSON比如{action: tap, coordinate: [540, 1200]}方便执行层直接解析。推理过程要求先输出思考再给动作。这一步实测非常关键强制模型“先写理由再执行”误操作率比直接输出动作低很多效果也更好排查。2.3 “动”动作注入与反馈闭环决策层输出动作后执行层要做几件事。先把模型输出的逻辑坐标映射到设备真实物理坐标因为不同手机分辨率、状态栏高度、屏幕比例都不一样坐标映射错了就会出现“点了但没点对地方”的情况再选择合适的注入方式模拟点击、坐标滑动、文本输入分别对应不同的系统指令最后做动作后校验重新截图去确认这次操作是否真的改变了界面状态。一个容易被忽略的点是“操作的粒度”。早期很多方案习惯把“打开设置—找到字号—调大”拆成连续多次 adb 命令一次性执行完这样速度快但风险极高一旦中间弹出权限弹窗或焦点变化整个操作链就全歪了。ARTEMIS 选择每一步都校验虽然慢一些但稳定性和可追踪性完全不一样。真机上的动作注入也有讲究。部分系统对 adb 模拟点击有限制尤其是 Android 12 之后的“最小化触摸区域”和部分定制 ROM 的安全策略会吞掉一些坐标注入事件。更稳定的方案是通过无障碍服务执行点击和用户真实手势的兼容性更好但需要额外开启无障碍权限。这一层在实际部署时建议先跑通最小点击样例再做完整流程。3. 从零跑通环境搭建与实操流程3.1 环境准备与最小依赖想本地跑起来体验一下建议准备以下环境一台能跑 Android 模拟器的电脑或者一台开了 USB 调试的真机。Python 3.10 以上环境用来运行框架入口和依赖服务。一个可用的 LLM 接口OpenAI 兼容 API 或本地部署的 Ollama / vLLM 服务都可以模型建议选支持工具调用和视觉理解的版本。ADB 环境确保命令行执行adb devices能看到设备。克隆 ARTEMIS 仓库后通常需要先安装 Python 依赖再配置模型服务地址和环境变量。这步没什么黑魔法核心是把“设备接口”“模型接口”“视觉模型接口”三个配置填对。有一点经验要提前说如果是第一次跑强烈建议先用模拟器而不是真机。模拟器的分辨率统一、可随时重置、不怕误操作弄乱系统对调试 Agent 动线非常友好。真机等整套流程稳定后再换不然一个误点击可能就进入了支付页面。3.2 最小复现让 AI 自主完成一个简单任务这里给一个最简的复现路径方便快速验证整套链路是否通。第一步启动模拟器确认adb devices可以正常发现设备记住设备序列号后面所有命令都要绑定这个设备。第二步初始化 ARTEMIS 会话。以“打开计算器执行 12 乘以 8 等于多少”为例先确认模拟器桌面上能看到计算器图标任务描述越明确模型越不容易跑偏。第三步执行自动化过程。框架会循环执行“截图 — 感知 — 模型决策 — 执行动作 — 再截图”这个过程在命令行或日志面板里可以看到每一步的思考输出和动作结果。第四步检查结果。任务完成后查看最终界面状态是否停留在计算结果页面同时核对执行日志里是否出现过无效路径或重复点击。这个最小用例跑通说明感知、决策、执行三条链路都没问题。如果卡在某一步先快捷键截一张当前设备截图手工看感知结果是否识别出了目标控件问题基本能定位一半。3.3 实操记录一个完整任务的执行轨迹拿“打开系统设置把字体调到最大”来说我实际操作时记录到的典型轨迹是这样的第一步模型观察到桌面图标列表识别出“设置”应用图标输出 tap 动作坐标在图标中心点击成功系统进入设置首页。第二步模型观察到设置首页有搜索框和分类列表但没有直接显示“字体大小”入口于是输出 swipe 动作向上滑动列表等待出现“显示”分类。第三步模型识别到“显示”项点击进入在显示设置里找到“字体大小”选项。第四步模型识别到字号调节滑块输出一次长按拖拽动作向右滑到底再截屏确认字号预览变大任务完成。整个过程大约 40 多秒比人工操作慢不少但完全自主完成没有任何手工干预。这个案例里最关键的一步是第二步的滑动决策因为“字体大小”藏在二级菜单里单靠第一屏截图看不到模型必须会“翻页寻找”。这也是这类框架比传统坐标脚本最有价值的地方面对动态布局它知道要去找。日志排布上建议把每次循环的模型思考、动作 JSON、截图文件名都记录下来。之后调试或者复现问题时这三个信息缺一不可。3.4 分辨率适配与显示参数调整不同模拟器和真机的分辨率差异直接影响坐标映射和视觉识别效果。分辨率太高截图非常大视觉模型处理慢分辨率太低小字和图标识别不清感知层就有问题。一个可行的适配策略是在感知阶段把原图压缩到 720p 左右做识别但在执行阶段仍按原始物理分辨率计算点击坐标。另一个细节是状态栏和导航栏的高度偏差。很多界面元素坐标是相对整个屏幕的但 Android 的沉浸式模式下内容区域会延伸到状态栏后面点击坐标可能被系统手势区域吞掉。实测最稳的方式是感知阶段就让视觉模型只处理内容区域识别结果里直接滤除顶部状态栏和底部导航栏的候选框。颜色和主题适配也值得关注。深色模式下文本对比度高OCR 反而更好但部分浅色背景上的白色按钮目标检测模型容易漏掉。如果目标 App 用的是特殊主题色可以在感知层做一次简单的颜色增强或灰度化效果提升非常明显。4. 选型对比与落地场景ARTEMIS 和同类方案怎么选4.1 与传统自动化测试框架的对比很多团队第一次接触 ARTEMIS 都会问这和 Appium 到底什么关系是不是要取代它。从我的实践看两者不是替代关系而是解决不同层级的问题。维度ARTEMISAppium / Espresso纯坐标脚本依赖控件树不依赖以视觉感知为主强依赖拿不到控件就废不依赖但不知道界面状态智能决策有模型自主拆解任务无脚本定死操作路径无脚本定死坐标路径应对动态布局强会自主寻找目标弱UI 一变脚本就挂极弱布局一动全盘崩维护成本低换界面描述即可高元素定位器精维护高坐标定期重录对 LLM 服务依赖强需要模型接口无无稳定性中等依赖模型质量高但前提元素可定位中依赖无弹窗无干扰一句话总结如果目标是每日回归、稳定可重复的测试执行传统框架仍然高效可靠如果目标是应对动态 UI、探索性测试、未知流程验证ARTEMIS 这类 AI 驱动的框架价值更大。4.2 与移动端 LLM Agent 类方案的区别市面上已经有不少“让大模型操作手机”的研究项目比如 Mobile-Agent、AppAgent思路和 ARTEMIS 同源。ARTEMIS 的优势在这个背景下会更明显工程化程度高设备管理、截图流程、动作注入、日志追踪都是框架自带能力而不是研究代码拼接。模块可替换性更强感知模型、规划模型、执行器都能独立更换方便接入自己的模型和优化策略。作为谷歌推动的项目其后续迭代、社区支持和生态挂接有明显优势在 Android 系统能力深度结合上有更大想象空间。选型时一个实用建议是如果只是做个 Demo 验证可行性任何 Agent 方案都可以如果要接到真机环境长期使用优先选工程完整度高、有活跃维护的框架。4.3 适合的应用场景与边界我实际验证下来ARTEMIS 在下面这几类场景里效果最好探索性自动化测试。不想写具体脚本让 AI 自己在 App 里“乱逛”发现崩溃和异常跳转这个场景对感知能力要求高但容错也高很适合 AI。跨应用任务代理。比如从短信中提取验证码填入另一个 App再返回原界面这种跨应用切换对传统自动化是噩梦对 ARTEMIS 反而简单。辅助功能演示和流程录制。做产品演示时演示脚本最怕环境变化AI 自主操作可以临场应变比录屏脚本体面得多。无障碍辅助。为视障用户设计的自动操作方案AI 可以理解语音指令并转换成 UI 操作。但也要说清楚边界。毫秒级点击、高频重复操作、对精度有严格要求的场景不合适AI 决策意味着每次操作都有耗损和不确定性纯离线环境也不合适就算本地模型能跑决策质量相比在线 API 还是有差距涉及支付密码、验证码输入等安全敏感流程建议不要交给自动化代理风险不可控。5. 常见问题与调优经验实录5.1 误识别与点击错位最常见的坑是视觉模型把界面元素认错。比如 OCR 把“取消”识别成“确定”目标检测把广告卡片误判为功能按钮图标识别把“我的”看成“购物车”。一旦感知层出问题决策层再聪明也白搭。我的排查思路是先在“观察模式”下跑流程不去执行动作只看每一轮的界面语义快照是否正确。绝大多数误识别都能在这一步暴露。修的时候可以叠加两个手段一是提高视觉模型置信度阈值让它少报但不能乱报二是在 Prompt 里补充界面来源信息比如“这是一个电商 App 的首页左侧是分类列表右侧是推荐商品”让模型结合业务常识去判断。点击错位的另一个来源是坐标映射。模拟器分辨率设置和感知层压缩比例不一致输出的点击坐标就会偏移。解决方法是固定一套分辨率设置感知层统一按 1080p 处理执行层做等比缩放换算实测可以消灭绝大多数错位问题。5.2 任务卡死与循环点击AI 自动化跑久了偶尔会出现“卡死”现象典型表现是反复点击同一个位置、不停上下滑动、或者在一个页面里来回进出。根因通常是任务的进度判定失效了模型分不清当前状态是“已经做过”还是“还没做过”。处理这个问题有两个实用手段。第一是设置最大步数上限比如规定最少完成 20 步内完成任务超出则停止并导出日志第二是引入相似状态检测每次截图后和最近几步截图做相似度比对连续 N 步界面无变化时强制中断并让模型换一条操作路径。更有效的办法是在 Prompt 里要求模型维护一个“已完成动作清单”每次决策前先读一遍清单避免重复执行。我实测这个简单改进能把无效循环减少五成以上。5.3 延迟控不住操作一顿一顿每步操作都需要截图、识别、模型推理、执行、再截图一个环节慢了整体就跟着慢。想优化先分清瓶颈在哪视觉识别慢还是决策慢截图传输慢还是动作执行慢。常见优化套路是这几条截图压缩后传输把 PNG 转成 JPEG 或降低分辨率减少传图耗时。视觉模型和 LLM 并发感知结果做缓存界面没大变化时不重复识别。本地部署小型视觉模型专门做元素识别大模型只负责决策分工后延迟下降明显。模型降到 4-bit 量化延迟能接受且质量损失可控本地跑推荐优先尝试。对任务响应时间要求不高的场景延迟优化不用太激进稳定优先。5.4 权限、安全与合规一层最后说一个必须重视的问题AI 能像人一样操作手机意味着它也拥有和你一样的设备权限。支付类、金融类、社交类 App 的敏感操作尤其是密码输入、验证码填写、转账确认绝对不要让自动化代理碰。平台权限弹窗也要特别小心AI 一旦误点了“允许”授权后面可能引发一串连锁反应。推荐做法是让 ARTEMIS 运行在隔离环境或专用测试机上不登录真实账号不接入真实支付渠道。实测很多自动化团队踩坑都是因为在一个绑定真实账号的设备上跑代理结果 AI 误触发了转账操作补救非常麻烦。权限控制上尽量用 adb 级别的注入权限并手动开启受控的无障碍权限不要为了省事把所有权限打包放行。日志脱敏也很重要截图里难免出现消息内容、通讯录、位置信息团队内部要约定好日志保存和清理策略。5.5 一个值得尝试的混合模式根据我的实操体验ARTEMIS 最稳的用法不是做“纯自主 Agent”而是做“混合执行器”让 AI 负责理解和决策但把高频重复动作交给脚本原子操作去执行。比如模型决定“下一步需要输入一段文本”文本输入可以直接调用一个预置的稳定注入函数而不是让模型生成字符再逐个输入模型决定“上滑三次回到顶部”可以直接执行一段封装好的手势脚本。这样做的好处是既保留了 AI 对动态界面的适应力又把最容易出错、最需要稳定的动作交给确定性代码整体成功率能上一个台阶。把这个混合模式做成配置化策略在人工介入率、执行耗时、任务成功率三个指标上会表现得非常均衡。最后再分享一个小经验新接一个目标 App 时不要急着跑完整任务。先让 ARTEMIS 在这个 App 里自由探索五分钟产出一份“界面元素统计清单”看看每个页面的感知覆盖率是多少再针对性补充图标语料或调优 Prompt。这套准备工作做完正式跑任务时的成功率会高很多也少踩很多动态布局的坑。