恒美微站 Logo 恒美微站
  • 首页
  • 关于我们
  • 建站服务
  • 主题模板
  • 案例展示
  • 资讯中心
  • 联系我们

谷歌开源ARTEMIS:基于MCP的移动端AI自动化框架实战指南

  • 首页
  • 资讯中心
  • /
  • 谷歌开源ARTEMIS:基于MCP的移动端AI自动化框架实战指南

相关资讯

从银行营销数据到认购概率:Python机器学习建模实战 2026/9/28 15:52:44
Simplorer与Simulink联合仿真实现PMSM FOC控制实战指南 2026/9/28 15:52:44
MT32F006与MAX17048的I2C通信实战:从波形异常到稳定读取电量 2026/9/28 15:52:44

最新资讯

基于Kubernetes的Agentic运行时编排:ax调度与池化实践
Kubernetes 上 agentic 工作负载的运行时编排层设计与实践
手机摄像头模组拆解:Lens、VCM、CMOS与DSP的协同原理
ax基础设施层:跨语言Agent调度的运行时契约与排错实践
ax:AI原生工作流的应用执行层标准
Cursor Agent成本优化:五处脚手架改动拆解,token消耗降7%

今日推荐

婚恋网站实战案例:避开3个高价坑,省钱50%还能跑赢流量
制作网页比较方便的软件怎么选?一文搞懂避坑指南
BootCamp6.1.7071驱动包手动安装与回滚全攻略

本周热门

从像素到笔画:srt-whiteboard-animation骨架笔迹追踪实现(Zhang-Suen细化+8邻接追踪)
网站建设的英语怎么说?别只背单词,看完这套安全完整流程才敢上线
新手入门看这篇:建设网站加盟避坑指南与SEO实操

本月精选

自研推理加速器Redwood:两周内实现PyTorch模型高效部署的实战教程
V4L2摄像头采集实战:从camera_client.rar到出图全流程解析
从“谁发明了钢琴键”到知识问答智能体:RAG与记忆工程实践

谷歌开源ARTEMIS:基于MCP的移动端AI自动化框架实战指南

发布时间:2026/9/28 15:57:44
谷歌开源ARTEMIS:基于MCP的移动端AI自动化框架实战指南 1. 为什么移动端自动化突然又火了移动端自动化这件事其实不是新话题。早年做 App 测试的同学谁没写过几行 Appium 脚本、谁没被 UiAutomator 的层级树折磨过。但这两年风向明显变了核心变量就是大模型和 Agent 的成熟。以前自动化是人写死脚本机器照着跑现在大家想要的是人给一句话AI 自己看着屏幕把事办了。这两者的难度完全不在一个量级。ARTEMIS 就是在这个背景下出现的。它是谷歌开源的一个移动端 AI 自动化框架目标很直接让 AI 助手像真人一样去操作手机——看屏幕、理解界面、点按钮、填表单、滑动列表最后把任务完成。你不需要为每个 App 写一套选择器也不需要维护一堆脆弱的坐标点击AI 通过视觉和界面结构去理解当前该做什么。我第一次看到这个项目的时候第一反应是这不就是把 Computer Use 那套思路搬到手机上吗。确实如此但移动端的坑比桌面端多得多屏幕小、控件密集、弹窗乱飞、权限弹窗随时打断、不同厂商 ROM 差异巨大。所以 ARTEMIS 的价值不在于提出了新概念而在于它把移动端这套脏活累活做了工程化封装并且和 MCPModel Context Protocol这套工具调用协议打通了。这篇文章适合三类人看一是做 App 测试、想升级自动化能力的工程师二是做 AI Agent、想把手机纳入执行终端的开发者三是纯粹好奇AI 到底怎么操作手机的技术爱好者。我会从设计思路、核心机制、实操步骤、踩坑经验几个维度把它讲透尽量让你看完就能自己跑起来。2. ARTEMIS 的整体设计与思路拆解2.1 它到底解决了什么核心问题传统移动端自动化最大的痛点是脆弱。你写一个find_element_by_id(login_btn)开发改个 ID 脚本就废了你用坐标点击换个分辨率就点偏了。维护成本高到很多团队干脆放弃 UI 自动化只留少量冒烟用例。ARTEMIS 换了个思路不再依赖精确的选择器而是让 AI 去看屏幕。它把当前界面的截图和控件树信息一起喂给模型模型输出一个动作点击某坐标、输入某文本、滑动某方向框架执行后再截一张图循环往复直到任务完成。这就是所谓的Perception-Action Loop感知-动作循环。这个思路的好处是鲁棒性大幅提升。按钮位置变了、文案改了只要人还能认出来AI 大概率也能认出来。代价是每次决策都要调用模型速度和成本比硬编码脚本高。所以 ARTEMIS 的定位不是替代所有自动化脚本而是处理那些流程不固定、界面经常变、写脚本不划算的场景。2.2 为什么选择 MCP 作为对外接口这是我觉得 ARTEMIS 设计上最聪明的一点。它没有自己造一套 Agent 协议而是直接拥抱了 MCP。MCP 你可以理解成AI 和工具之间的 USB 接口——模型不需要知道工具内部怎么实现只要按协议调用就行。ARTEMIS 把移动端操作封装成一组 MCP 工具比如tap、swipe、input_text、get_screen_state等等。任何支持 MCP 的客户端Claude Desktop、各种 IDE 插件、自研 Agent都能直接调用这些工具去操作手机。这意味着你不需要为 ARTEMIS 单独写一套集成代码生态里现成的 MCP 客户端拿来就能用。提示MCP 是当前 Agent 工具调用的事实标准之一理解它对用好 ARTEMIS 至关重要。如果你还不熟建议先花半小时看看 MCP 的基本概念再回来看这个项目会顺畅很多。2.3 分层架构谁负责什么我把 ARTEMIS 的架构拆成四层来理解这样最清晰层级职责关键技术设备连接层与手机建立通信执行底层操作ADB / 平台原生接口感知层获取截图、控件树、当前 Activity截图 API UI 层级 dump决策层把界面信息交给模型解析动作指令多模态大模型协议层对外暴露 MCP 工具接收任务MCP Server这样分层的好处是每一层都能单独替换。比如你觉得某个模型决策不准换一个就行你觉得 ADB 太慢理论上也能换成别的连接方式。工程上这种解耦非常关键因为移动端环境太碎片化了任何硬绑定都会让你在某个特定机型上翻车。2.4 和传统方案的本质区别我做个对比表方便你判断什么时候该用它维度传统脚本Appium 等ARTEMIS 类 AI 方案编写方式手写选择器和流程自然语言描述任务界面变化适应性差需改脚本强AI 自适应执行速度快慢每步调模型成本开发成本高运行成本低开发成本低运行成本高适合场景稳定回归测试探索性任务、多变流程结论很明确稳定的核心流程用脚本多变的、一次性的、探索性的任务用 AI。两者不是替代关系是互补关系。我见过太多团队一上来就想用 AI 全替代结果又慢又不稳最后灰头土脸回去写脚本。3. 核心机制与实操要点拆解3.1 感知层AI 到底看到了什么这是整个框架的地基。ARTEMIS 给模型提供的信息通常包含三部分屏幕截图最直观模型能看到界面长什么样控件树UI Hierarchy每个控件的类型、文本、坐标、可点击状态上下文信息当前包名、Activity 名、屏幕尺寸、键盘是否弹出为什么截图和控件树都要给因为两者互补。截图能识别图标、图片按钮、复杂布局但拿不到精确坐标和控件属性控件树能给出精确的 bounds 和 text但对自定义绘制的内容无能为力。两者结合模型判断的准确率会明显提升。实操中有一个关键细节截图和控件树的采集必须尽量同步。如果先截图、隔了 500ms 再 dump 控件树中间界面可能已经变了模型拿到的就是错位的信息决策必然出错。ARTEMIS 在实现上会尽量把这两步压缩到同一时间窗口内。3.2 决策层模型如何输出一个动作模型拿到的是一张图加一段结构化的界面描述它需要输出一个明确的动作。常见的动作空间大概是这样{ action: tap, params: { x: 540, y: 1200 }, reason: 点击登录按钮 }或者{ action: input_text, params: { text: 13800138000 }, reason: 在手机号输入框填入号码 }注意那个reason字段它不是摆设。让模型显式输出推理理由一方面能提升决策质量相当于思维链另一方面在调试时你能清楚看到它为什么点这里排查问题效率翻倍。动作空间的设计要克制。我见过有人把动作设计得特别细几十种结果模型经常选错。ARTEMIS 这类框架通常只保留最核心的几种点击、长按、输入、滑动、返回、等待、任务完成。动作越少模型越不容易犯错。3.3 循环控制什么时候停下来这是最容易被忽视、但最容易翻车的地方。AI 操作手机是个循环如果控制不好它会无限循环点同一个按钮任务早就完成了还在瞎点遇到弹窗卡死ARTEMIS 的控制策略一般包含几个保险最大步数限制比如 30 步还没完成就强制终止重复动作检测连续 N 次相同动作且界面无变化判定卡死完成信号模型可以主动输出任务完成异常中断检测到崩溃、无响应等状态直接退出注意最大步数这个参数一定要设。我踩过的坑就是没设上限模型在一个广告弹窗上反复点关闭点了两百多次token 烧了一大把。3.4 坐标与分辨率适配移动端最烦的就是分辨率。模型看到的是缩放后的截图输出的坐标是相对截图的但实际点击需要的是设备真实坐标。这中间必须做一次映射。假设设备真实分辨率是 1080x2400你给模型的截图缩放到了 540x1200模型输出坐标 (270, 600)那么真实点击坐标就是real_x 270 * (1080 / 540) 540 real_y 600 * (2400 / 1200) 1200这个换算看起来简单但如果你忘了做或者缩放比例算错就会出现点偏的经典问题。ARTEMIS 内部会处理这个映射但你自己写扩展工具时一定要记得。3.5 输入法的坑输入文本这件事在移动端自动化里是个大坑。直接往输入框塞文本很多 App 是不认的因为它监听的是真实的按键事件。常见做法有两种用 ADB 的input text命令模拟真实输入通过输入法IME注入前者简单但对中文和特殊字符支持差后者稳定但配置麻烦。ARTEMIS 一般会优先用 ADB 方式遇到不支持的字符再降级处理。实操中如果发现文本输不进去先检查是不是字符编码问题再检查输入框是不是需要先点击聚焦。4. 从零跑通 ARTEMIS 的完整实操4.1 环境准备清单在动手之前把下面这些东西准备好能省你至少两小时项目要求说明操作系统macOS / Linux / WindowsLinux 最省心Python3.10大部分 MCP 实现依赖ADB最新版设备通信的基础安卓设备真机或模拟器建议先用模拟器大模型 API支持多模态视觉能力是刚需MCP 客户端任意兼容实现用于发起任务ADB 这块特别强调一下一定要用比较新的版本。老版本 ADB 在某些新机型上会出现连接不稳定、截图失败的问题。装完之后用adb devices确认设备能被识别这是所有后续操作的前提。4.2 设备连接与调试模式第一步手机开启开发者选项和 USB 调试。不同厂商入口不一样一般在关于手机里连点版本号七次。开启后连上电脑执行adb devices正常应该看到类似输出List of devices attached emulator-5554 device如果显示unauthorized说明手机上还没确认授权看手机屏幕点一下允许就行。如果显示offline试试adb kill-server adb start-server重启服务。提示用模拟器的话推荐分辨率设成 1080x1920 这种主流尺寸别用太奇葩的比例否则坐标映射容易出问题。4.3 拉取项目与依赖安装从项目仓库克隆下来进入目录后建虚拟环境python -m venv venv source venv/bin/activate # Windows 用 venv\Scripts\activate pip install -r requirements.txt依赖里通常包含 ADB 封装库、图像处理库、MCP SDK 等。如果安装过程中某个包编译失败八成是缺系统级依赖Linux 上装一下libjpeg-dev、python3-dev之类的通常能解决。4.4 配置模型与 MCP Server配置文件一般是个 YAML 或 JSON核心要填的是模型相关的信息model: provider: your_provider name: your_multimodal_model api_key: YOUR_KEY max_tokens: 2048 device: adb_path: /usr/local/bin/adb screenshot_scale: 0.5 loop: max_steps: 30 repeat_threshold: 3screenshot_scale这个参数很关键。设成 0.5 意味着截图缩小一半再给模型能显著降低 token 消耗和延迟但太小了模型看不清小字。我的经验是 0.5 到 0.7 之间比较平衡具体看你的界面文字密度。启动 MCP Serverpython -m artemis.server看到监听端口的日志就说明起来了。4.5 发起第一个任务在 MCP 客户端里配置好这个 server然后就可以用自然语言下任务了。比如打开设置找到关于手机读出系统版本号模型会开始循环截图 → 分析 → 点击 → 再截图……你可以在日志里看到每一步的决策理由。第一次跑建议盯着看观察它的决策是否符合预期。4.6 一个完整的动作序列示例假设任务是在计算器里算 12 乘以 8实际执行大概是这样的截图识别到桌面决策点击计算器图标截图识别到计算器界面决策点击数字 1截图决策点击数字 2截图决策点击乘号截图决策点击数字 8截图决策点击等号截图识别到结果 96决策任务完成每一步都是一次完整的感知-决策-执行循环。看起来笨但正是这种笨让它能适应各种没见过的界面。5. 常见问题与排查技巧实录5.1 点击没反应怎么办这是最高频的问题。排查顺序建议这样确认坐标是否正确把模型输出的坐标画到截图上看是不是真的落在目标控件上确认控件是否可点击有些控件看着能点实际被上层透明 View 挡住了确认是否需要先滚动目标在屏幕外得先滑上来确认是否有弹窗遮挡权限弹窗、广告弹窗经常是罪魁祸首我遇到最多的是第四种。很多 App 一启动就弹权限申请模型没识别出来一直在点后面的界面自然没反应。解决办法是在 prompt 里明确告诉模型遇到弹窗优先处理弹窗。5.2 模型决策不稳定同一个界面这次点对了下次点错了。原因通常有几个截图质量差压缩太狠模型看不清控件树信息缺失某些自绘界面 dump 不出有效信息prompt 不够明确任务描述太模糊我的经验是把screenshot_scale调高一点同时在任务描述里把目标说清楚。比如别说登录一下而说在手机号输入框填入 138xxxx然后点击获取验证码按钮。5.3 速度太慢的优化思路AI 操作手机慢是天然的但可以优化优化点做法效果降低截图分辨率调小 scale明显减少无关信息精简控件树字段中等缓存界面状态界面没变不重复调模型明显用更快的模型换小模型做简单决策明显其中界面没变不重复调模型这个技巧特别实用。如果连续两次截图完全一样说明上一步动作没生效这时候要么重试要么换策略没必要再问一遍模型。5.4 中文输入失败前面提过ADB 的input text对中文支持不好。解决方案用 ADB 的广播方式配合输入法或者先把文本写到剪贴板再模拟粘贴第二种更通用。具体做法是用adb shell am broadcast把文本塞进剪贴板然后长按输入框选粘贴。虽然绕但稳定。5.5 多设备并发如果你要同时操作多台设备注意 ADB 需要指定设备序列号adb -s emulator-5554 shell ...ARTEMIS 的配置里一般也支持指定设备。并发时最大的坑是资源竞争比如多台设备同时截图会拖慢整体速度。建议控制并发数别超过 3 台。6. 我对这类框架的真实看法跑通 ARTEMIS 之后我最大的感受是移动端 AI 自动化的瓶颈不在框架在模型和场景选择。框架层面ARTEMIS 已经把该做的都做了——设备连接、感知采集、动作执行、MCP 封装工程完成度不错。但真正决定成败的是两件事一是模型的多模态理解能力够不够强二是你选的任务场景适不适合 AI 来做。我试过让它做一些固定流程的回归测试结果又慢又不稳还不如老老实实写脚本。但换成帮我在某个 App 里找找有没有某个功能入口这种探索性任务它的价值就体现出来了——这种任务你根本没法提前写脚本。所以我的建议是别把它当成万能工具把它当成一个能处理模糊任务的新武器。稳定的核心流程继续用脚本把 AI 留给那些脚本搞不定的边角场景。这样组合起来整体效率才是真的提升。另外MCP 这个方向值得持续关注。ARTEMIS 只是移动端的一个实现同样的思路可以套到桌面、浏览器、甚至 IoT 设备上。当所有终端都能通过 MCP 被 AI 调用时AI 帮你操作一切这件事才算真正落地。现在还在早期但方向已经很清楚了。

关于恒美微站

恒美微站专注于为个体商户、工作室提供极简自助建站服务,让每个人都能轻松拥有专业网站。

快速链接

  • 关于我们
  • 建站服务
  • 主题模板
  • 案例展示
  • 资讯中心

服务项目

  • 可视化建站
  • 拖拽编辑
  • 主题定制
  • SEO 优化
  • 网站托管

联系方式

  • 📍 地址:北京市朝阳区建国路 88 号
  • 📞 电话:400-888-8888
  • ✉️ 邮箱:info@hmyw.cn
  • 🕐 时间:周一至周日 9:00-18:00

© 2024 恒美微站 hmyw.cn 版权所有 | 京 ICP 备 12345678 号