ARTEMIS：多模态大模型驱动的手机屏幕智能体自动化框架-北京尧图网络

1. 从脚本点按钮到看屏幕点按钮ARTEMIS 为什么在这个时间点出现我最初看到谷歌开源移动端 AI 自动化框架这几个字的时候第一反应不是又一个 Demo而是想到一个非常具体的场景你跟手机说帮我把上一个来电号码存成联系人备注叫王工然后 AI 真的自己打开拨号、翻通话记录、点新建联系人、逐项填写、保存全程不需要你碰屏幕。这种像人一样操作手机的能力过去十几年一直有人在尝试但绝大多数路径走的是脚本自动化要么给每个元素写死 ID 和坐标要么依赖系统控件树逐层查找。问题是真实手机 App 的界面不是表格而是充满动效、弹层、轮播图、键盘、权限框的动态画面。你让脚本跑一遍自测没问题一旦换个 ROM、换个屏幕尺寸、App 改版一次脚本可能当场就废了。ARTEMIS 给我的第一印象就是它把这个问题彻底换了赛道不再要求你去告诉机器每个按钮在哪,而是让模型直接看截图理解当前界面的含义再决定下一步按哪里、滑哪里、输入什么。这种思路在 2023 年之前基本不可能落地——当时的小模型看不出屏幕上哪个区域是确认付款哪个文案是标题还是按钮。但在多模态大模型成熟之后屏幕上的一草一木对模型来说都是可以被推理的视觉信息ARTEMIS 这类框架才有了真正的土壤。这个项目对哪类人价值最大我觉得是三类一是做 App 自动化测试的工程师想用自然语言描述代替一条条写脚本二是做智能体应用的产品经理和开发者希望让大模型真正落到操作真实软件而不是只停留在聊天框三是个人开发者想在夜深人静的时候跑通一个能替你操作手机的 Agent然后把经验迁移到其他端侧场景。我自己实际把类似的框架跑过几遍之后最大的体会是这类项目真正的门槛不在模型而在工程。模型只看截图就能输出点击坐标这件事已经非常成熟但怎么保证每一次点击都稳定、怎么处理系统弹窗抢焦点、怎么在长任务里不让 Agent 迷路这些才是决定项目能不能从能跑变成能用的关键。ARTEMIS 的价值就是把这些工程细节封装成了相对完整的流水线让你可以直接站在上面继续做自己的事。2. 感知-决策-执行闭环ARTEMIS 内部到底是怎么运作的你如果打开 ARTEMIS 这类框架的源码会发现它的核心逻辑并不复杂甚至可以拆成三个非常清晰的模块感知Perception、决策Planning、执行Execution。理解这个闭环是之后调参、排错、做二次开发的基础。2.1 感知层它怎么看到屏幕手机屏幕对 Agent 来说本质上就是一张截图加一棵 UI 控件树。ARTEMIS 的感知层会同时拿到两样东西一是通过adb exec-out screencap -p抓取的实时屏幕截图二是通过uiautomator dump导出的控件布局描述里面包含每个控件的类型、文本、坐标范围、是否可点击等信息。这里有一个很关键的细节截图和控件树是两套不同步的信息。截图是位图适合给视觉模型做整体理解比如界面上方有一张广告横幅控件树是结构化文本,适合给模型提取精确的按钮坐标和文案比如这个叫确定的按钮在 x540, y1800 的位置。ARTEMIS 的策略是两者都抓然后让模型融合判断——视觉模型回答当前界面大概在干嘛结构化信息回答哪些位置可以点。这种双通道设计能显著减少模型对按钮位置的误判尤其是遇到图标按钮、纯图片广告这类没有文本信息的区域。当然双通道也有坑。uiautomator dump在部分国产 ROM 上可能输出为空或者控件树里有大量无用节点比如一个 TextView 嵌套六七层。处理办法一般是对控件树做裁剪只保留clickabletrue的节点和关键文本节点再做一次去重和排序把内容压到模型上下文能接受的范围内。ARTEMIS 在这个环节做得比较扎实它会做坐标归一化把像素坐标统一映射到 0~1000 的相对坐标这样换设备之后模型输出不会乱。2.2 决策层模型怎么决定下一步点哪里拿到屏幕信息之后决策层要回答的问题是离用户的目标还有多远接下来应该执行什么动作。这里 ARTEMIS 采用的动作空间非常接近人机交互的基础单元一般包含六类tap单击某个坐标点long_press长按swipe滑动带起点、终点和时长text_input输入文字key_event按键事件比如返回键、Home 键wait等待若干毫秒让页面加载完成模型每轮推理都会输出一个结构化动作通常是一段 JSON例如{ thought: 当前页面是通话记录列表目标联系人叫王工我需要点击第一条记录进入详情。, action: { type: tap, coordinate: [540, 300], description: 点击通话记录第一条 } }这里最有意思的是 thought 字段。它不只是给开发者看的而是在多轮任务中帮助模型维持状态--当任务长达十几步时模型可以借助之前的思考链条回顾自己做到哪一步了避免出现已经保存了联系人又去打开拨号盘这种迷失。我实测下来长任务稳定性的一大提升就是靠这个显式的思考输出。2.3 执行层动作如何落到真实手机决策层只输出意图真正让手机动起来的是执行层。ARTEMIS 的执行层底层走的是 Android 的 ADB 通道通过adb shell input tap x y注入点击事件通过adb shell input swipe模拟滑动输入文字则走adb shell input text。但如果你以为只是把命令原样发出去那就太天真了。实际执行中会遇到一个问题动作太快界面还没反应过来。特别是某些页面有转场动画你点击后界面要过几百毫秒才跳到下一页如果 Agent 立刻截图准备下一轮决策截到的往往是过渡帧或者上一页的残影。所以 ARTEMIS 在动作之后通常会加一个固定等待或者动态等待比如等待页面上的某个关键控件出现然后再进入下一轮循环。这个细节看起来不起眼却是整个项目能不能稳定跑完一个长任务的分水岭。2.4 Mini Agent 的完整循环把三个模块串起来整个 Agent 的运行循环其实就是一个 while 循环while not task_completed: screenshot capture_screen(device) ui_tree dump_ui_tree(device) observation build_observation(screenshot, ui_tree) action model.plan(observation, task_description, history) execute_action(device, action) history.append(action) sleep(0.5)循环的终止条件也很讲究不是模型说结束就结束而是要满足两个条件之一要么模型明确输出task_completed: true要么连续多轮动作重复且无进展触发超时保护。否则模型会在一些界面上反复尝试同一个点击白白消耗 token。3. 自己动手跑通 ARTEMIS环境搭建与第一个自动化任务讨论再多架构不如实际跑一遍。下面这部分基于我自己的操作经验尽量按一条可以直接照着做的路径来写。3.1 环境准备清单动手之前先把下面的东西准备好组件要求说明操作系统Linux / macOS 优先Windows 也能跑但 ADB 驱动和路径配置容易折磨人Python3.10 及以上项目主语言Android 设备真机或模拟器均可建议先用模拟器比如 Android Studio 自带的 AVD操作可回滚设备调试开启 USB 调试真机还需要关闭USB 安装监控等安全拦截硬件显存 12GB 以上如果你本地推理多模态模型这是最低门槛否则用 API工具链Android SDK Platform-Tools提供 adb、uiautomator 命令ARTEMIS 的模型端有两条路可选一是接入云端的多模态大模型 API配置简单适合快速验证二是本地部署开源权重模型隐私性好但需要较充足的显存。我个人建议第一次跑通用云端 API把精力集中在熟悉框架流程上等你自己改二开的时候再上本地模型。3.2 初始化项目与连接设备项目拉下来之后核心操作就两件事连上设备确认 adb 能看到你的 Android 设备adb devices正常会出现类似emulator-5554 device如果显示 unauthorized说明设备上的 USB 调试授权弹窗没点允许如果什么都不显示多半是驱动问题macOS 上还需要在系统设置里允许终端访问 ADB。3.3 配置模型 API在项目配置文件中填入你的模型 API Key 和模型名称。这里提醒一句不同模型对本任务的遵守能力差异巨大。有些模型 API 会输出格式不稳定的 JSON甚至把coordinate写成字符串有些则对点击某个坐标这种指令天然敏感。建议第一次直接用项目 README 里写明验证可用的默认模型跑通之后再尝试替换其他模型。3.4 跑一个简单任务打开相机拍一张照片给 Agent 的任务描述尽量明确比如打开相机应用切换到前置摄像头拍一张照片然后返回桌面。这个任务有意思的地方在于它涵盖了打开 App、点击按钮、触发快门、按键返回四类动作但又不至于复杂到让 Agent 一开始就迷路。任务描述应该写清打开哪个应用和最终要达成什么结果中间的路径细节留白让模型自己规划。跑起来之后的日志会像这样[Step 1] thought: 用户需要打开相机应用我先从桌面找到相机图标。 [Step 1] action: tap (540, 1180) - 点击相机图标 [Step 2] thought: 相机已打开当前应该是默认的后置摄像头。屏幕上有切换摄像头的按钮通常在右上角。 [Step 2] action: tap (960, 240) - 点击切换摄像头按钮 ... [Step 5] action: key_event: BACK [Step 5] task_completed: true我第一次跑类似任务时最直观的感受是原来模型的思考过程真的能还原成一个人在操作手机的轨迹。它不依赖任何 App 的内部接口纯粹靠看屏幕理解操作这一点和传统自动化测试框架是本质不同的。4. 实测最容易翻车的四个环节坐标、时序、上下文与系统弹窗前面说过框架本身不难难在稳定。我把自己和身边人跑这类项目时踩过的坑梳理成四类每一条背后都有对应的排查思路。4.1 坐标偏移截图分辨率和控件树不一致这是第一个高频问题。某些设备开启显示大小或字体大小调整后截图像素坐标跟uiautomator输出的坐标会出现比例偏差。你从控件树里拿到一个bounds转成坐标后去点击结果点在按钮边缘甚至点到了旁边的广告位。排查思路是先确认两套坐标系是否一致用adb shell wm size看物理分辨率再对比截图文件的实际尺寸。如果不一致需要做等比换算。ARTEMIS 的坐标归一化逻辑能缓解这个问题但如果你在国产定制 ROM 上跑还是要亲自验证一次坐标映射。4.2 时序问题页面动画导致动作落到错误的位置App 里的转场动画、底部弹窗出现动画、列表惯性滚动都会让模型看到截图那一刻和执行点击那一刻之间产生时间差。常见表现是模型分析截图时按钮在屏幕中央等它执行点击时按钮因为轮播图滚动已经跑到了左边结果点了一个完全无关的地方。缓解办法有两个方向。一是给动作执行后加长等待比如点击后固定等 1~2 秒再截图二是做动作前细看——执行点击前对目标区域再做一次放大识别或者直接等到控件树里出现目标控件再出手。后者对时序问题的改善更明显但会增加延迟。4.3 上下文污染长任务做到后面模型忘记前半段当一个任务超过十步时模型的上下文里塞满了历史截图描述和思考链。问题在于早期识别的一些信息比如联系人列表第三行是目标在列表刷新后可能彻底失效。模型如果还抱着旧信息不放就会反复去点一个已经不存在的位置。这个问题的处理思路是给历史信息做时间衰减只保留最近 3~5 轮的动作和思考更早的信息做摘要而不是全量塞进上下文。同时在执行关键动作之后让模型重新确认当前页面是否符合预期如果不符就回溯。ARTEMIS 这类框架默认保留全部 history我在二开时通常会改成滑动窗口式上下文实测对长任务成功率提升非常明显。4.4 系统弹窗拦截权限框、更新提示、垃圾通知把任务带偏真实手机上你刚打开一个 App可能弹出一个允许获取定位的权限框也可能跳出发现新版本的更新浮层。这些弹窗对普通用户来说是干扰对 Agent 来说同样是干扰。模型如果没见过这种弹窗可能直接困惑或者更糟——乱点一气把弹窗点掉了然后又点错地方。处理这类弹窗有两个层次。第一层是预判法环境准备阶段就把目标 App 的权限全部授予、关闭通知、关闭自动更新从源头减少弹窗。第二层是应对法在感知层加入一个弹窗识别器如果检测到系统级弹窗先执行固定策略比如点击拒绝或关闭而不是让模型自由发挥。框架层面通常不会自动处理这个问题需要你自己在任务循环里加一层弹窗守卫。5. 和 Appium、UIAutomator 这些老方案比ARTEMIS 的优势在哪聊完实操细节有必要退一步把 ARTEMIS 放到移动自动化的谱系里做个对比。很多测试工程师是带着这玩意儿能不能替代我手上的框架的疑问来看它的。5.1 从API 驱动到视觉驱动的范式变化传统自动化方案比如 Appium、UIAutomator、Espresso都有一个共同前提你按控件 ID、类名、文本去定位元素。这套方案在你自己开发的 App 上完全没问题因为你知道每个控件的 ID 叫什么。但换个场景就尴尬了你手里是一个没有源码的第三方 App元素 ID 完全不可控或者 App 强制走 Flutter、游戏引擎渲染原生控件树里什么都拿不到。ARTEMIS 走的是另一条路它不关心控件有没有 ID只关心模型从截图上看到了什么。本质上它把元素定位这一步从编程问题变成了视觉理解问题。对纯代码渲染的画布类应用传统方案基本缴械ARTEMIS 反而能靠截图轻松上手。5.2 跨 App 任务能力只看单 App 自动化ARTEMIS 不一定比传统方案快但一旦任务需要跨多个应用协同比如从相册挑一张图发到微信朋友圈AGENT修改为从相册挑一张图发到微信朋友圈传统方案就非常痛苦——每个 App 都要写一套定位逻辑App 之间切换状态还要自己管理。这类框架的定位设计天然适合跨 App 场景模型在截图之间自由切换不受控件 ID 跨 App 失效的约束。5.3 各自的地盘不是谁取代谁不过要说明白ARTEMIS 目前还不能无缝替代传统测试框架。它的动作执行延迟通常是秒级模型每次决策都要经过一轮视觉推理而 UIAutomator 执行一个点击是毫秒级。如果你的核心诉求是每天跑几千条回归用例要求快速、稳定、低延迟传统框架依然是正解。我的建议是分场景对待维度Appium / UIAutomatorARTEMIS 这类智能体框架元素定位方式控件 ID / 文本 / XPath视觉理解结构化动作适合场景高频回归、批量接口验证探索式测试、跨 App 任务、不可控 Ui 结构执行速度快毫秒到秒级慢单步需 1~3 秒推理稳定性极高可重复受模型能力影响需大量调优维护成本App 改版后需更新定位器App 改版后多数情况仍能工作上手门槛需要编程基础自然语言描述任务即可6. 从 Demo 到实战ARTEMIS 能延展到的三个方向跑通一个 Demo 只是开始。站在我的角度ARTEMIS 这类框架真正的想象空间在这几个地方而且都和让 AI 从聊天框走向真实世界这个主线有关。6.1 自动化测试的自然语言用例测试团队以后写用例可能不再需要关心元素定位细节了而是用一段自然语言描述预期流程新用户首次打开 App 时应出现引导页点击跳过进入首页首页底部应有 4 个 Tab。Agent 负责把这句话翻译成一系列视觉验证。这样做的好处是业务同学也能评审用例测试和产品之间的沟通成本会下降很多。当然目前还需要一个人来做验收Agent 跑完流程后你需要确认它确实点击了正确位置而不是在错误的道路上完成了错误的闭环。这提醒我们这类框架短期内是测试人员的辅助工具而不是替代。6.2 个人自动化助手ARTEMIS 的底座能力是看屏幕、想一步、点一步这恰恰是所有个人手机助手的公共底层模块。你可以基于它做更上层的应用比如定时任务助手、App 巡检工具、无障碍辅助工具。有些开发者把它和本地大模型组合做成完全离线运行的手机操作助手数据不出本机这个组合我个人非常看好。6.3 智能体反馈数据的采集器最后说一个很多人没注意到的价值ARTEMIS 天然是一个人机交互行为数据采集器。它在每一步都会记录截图、思考、动作、结果这些日志本身就是训练下一代端侧模型的高质量语料。如果你在做 Agent 相关的数据工程这类框架产出的结构化轨迹数据比从网上扒的纯文本数据有价值得多。我个人在实际跑这类项目时最深的一个体会是别指望第一天就让模型完成一个 20 步的长任务。先给它一个三步的短任务跑通再加一个分支逻辑跑通再上真机、换模型、改上下文窗口。每一步都以稳定复现为验收标准比一上来就追求宏大效果要可靠得多。ARTEMIS 这个项目还在快速迭代社区里每天都有新的踩坑案例和二次开发方案保持跟进你会看到它带来的变化比想象中更快。

ARTEMIS：多模态大模型驱动的手机屏幕智能体自动化框架

相关推荐

PDF显示名称与文件名不符：四层根因排查与批量修复

旅游推荐系统架构设计与大数据技术实践

AI智能客服模型路由失控：Prompt版本管理与排查实战

更多资讯

4240亿参数重塑AI产业：ERNIE 4.5多模态大模型的技术突破与行业变革

腾讯开源全球最大文生图模型：HunyuanImage-3.0重构多模态技术格局

NV-Generate-CT训练数据集揭秘：60,000个3D体积数据的完整处理流程

腾讯混元POINTS-Reader：端到端文档转换技术的新突破

如何快速接入 PX4 距离传感器：22 款驱动从使能、启动到调优的完整指南

Lance vs 主流多模态模型：VBench评测中85.11分夺冠背后的技术解析

今日更新

淘宝商品详情API开发实战与性能优化指南

Unity Package Manager刷新错误排查与解决方案

Java record 规范构造器能否被反序列化或反射绕过

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？