ARTEMIS：基于MCP协议的移动端AI自动化框架实战指南

1. 项目概述与核心价值定位移动端自动化测试和操作一直是个让人又爱又恨的领域。爱的是它确实能解放双手恨的是方案要么太重、要么太脆、要么门槛高得离谱。谷歌开源的 ARTEMISAutomated Real-world Testing and Evaluation for Mobile Intelligence Systems算是给这个领域投下了一颗不大不小的石子。它本质上是一个移动端 AI 自动化框架核心目标是让 AI 助手能够像真人一样去操作手机——点击、滑动、输入、读取屏幕内容甚至理解当前界面状态并做出决策。我第一次看到这个项目的时候脑子里蹦出来的第一个词是“终于”。因为在此之前想让 AI 操作手机基本只有两条路要么用 Appium 这类传统自动化工具硬写脚本每个控件都要手动定位界面一改脚本就废要么自己从零搭一套基于视觉识别的方案光是截图、OCR、坐标映射这几步就够喝一壶的。ARTEMIS 的价值在于它把“感知-决策-执行”这个闭环做成了标准化框架而且跟 MCPModel Context Protocol做了深度整合让 AI 模型可以直接通过协议层去调用手机操作能力。这个项目适合谁如果你是做移动端测试的工程师想从写脚本升级到用 AI 驱动测试那 ARTEMIS 值得花时间研究。如果你是 AI Agent 方向的开发者想让自己的助手具备操作手机 App 的能力ARTEMIS 提供了一套现成的执行层。哪怕你只是对“AI 怎么像人一样用手机”这件事好奇这个项目的架构设计也足够让你看清背后的门道。它解决的核心问题是把移动端操作从“写死的脚本”变成“可推理的行为”让 AI 根据当前屏幕状态动态决定下一步做什么而不是提前把每一步都编排好。2. 架构设计与技术选型拆解2.1 为什么是“感知-决策-执行”三层架构ARTEMIS 的架构思路很清晰就是经典的三层闭环感知层负责获取手机当前状态决策层负责判断下一步该做什么执行层负责把决策变成实际的触摸或输入事件。这个分层不是拍脑袋定的而是有实际考量的。先说感知层。移动端跟桌面端最大的区别在于你没法直接读取 DOM 树。Android 虽然有 Accessibility Service 可以拿到控件树但很多 App 尤其是游戏或者 Flutter 写的界面控件信息要么缺失要么混乱。ARTEMIS 的做法是双通道感知一路走 Accessibility API 拿结构化控件信息一路走截图加视觉模型做界面理解。两路信息融合之后AI 才能既知道“这里有个按钮”又知道“这个按钮长什么样、在屏幕什么位置”。决策层是 ARTEMIS 跟传统自动化工具拉开差距的地方。传统工具是“你告诉它点哪里它就点哪里”ARTEMIS 是“你告诉它目标它自己决定点哪里”。比如你说“帮我在购物 App 里搜一双跑鞋”决策层会先看当前在哪个页面判断搜索框在哪决定是先点搜索框还是先滑一下屏幕输入关键词之后还要判断是点搜索按钮还是直接回车。这些判断依赖的是大模型的推理能力而不是预设的规则。执行层反而是最“薄”的一层因为 Android 和 iOS 都提供了标准的输入注入接口。Android 这边用 ADB 的 input 命令或者 UiAutomator 的 APIiOS 这边用 XCUITest 的接口。ARTEMIS 把不同平台的执行接口做了统一封装上层决策不需要关心底层是 Android 还是 iOS。2.2 MCP 协议整合带来的扩展性MCP 是最近半年在 AI 工具链里非常火的一个协议全称是 Model Context Protocol。它的核心作用是让 AI 模型能够以标准化的方式去调用外部工具和数据源。ARTEMIS 整合 MCP 之后最大的好处是任何支持 MCP 的 AI 客户端都可以直接调用 ARTEMIS 的移动端操作能力不需要额外写适配代码。我实测下来的感受是这个设计让 ARTEMIS 从一个“独立工具”变成了“能力提供方”。你可以把它理解成一个 MCP Server它暴露出来的工具包括获取当前屏幕截图、获取控件树、点击指定坐标、输入文本、滑动屏幕、返回上一页等等。AI 模型通过 MCP 协议跟 ARTEMIS 通信ARTEMIS 负责把模型的意图翻译成具体的手机操作。这种架构的好处在于解耦。AI 模型不需要知道 Android 的 input 命令怎么拼ARTEMIS 也不需要知道模型是怎么推理的。两边通过 MCP 协议这个“中间语言”对话各自可以独立演进。今天你用 GPT-4 做决策明天换成别的模型只要它支持 MCPARTEMIS 这边完全不用改。2.3 跟传统方案的对比对比维度传统自动化Appium/UiAutomatorARTEMIS脚本编写需要手动定位每个控件只需描述目标AI 自动决策界面变化适应性控件 ID 一变就失效视觉理解适应性更强跨 App 操作需要为每个 App 单独写脚本通用操作能力无需适配决策能力无完全按脚本执行有基于当前状态动态决策部署复杂度中等需要配置驱动和环境中等需要配置 MCP 和模型适用场景回归测试、固定流程探索性测试、AI 助手操作这个对比不是说 ARTEMIS 全面优于传统方案。在需要精确重复执行的回归测试场景里Appium 那种“每次点同一个坐标”的方式反而更稳定。ARTEMIS 的优势在于处理不确定性和跨 App 的通用操作这是传统方案很难做到的。3. 环境搭建与核心配置实操3.1 基础环境准备ARTEMIS 的运行依赖几个基础组件我按实际搭建顺序来说。首先是 Android 环境你需要安装 Android SDK 和 ADB 工具。ADB 是跟手机通信的桥梁ARTEMIS 通过它来发送操作指令和获取屏幕数据。安装完 SDK 之后记得把 platform-tools 目录加到系统 PATH 里不然命令行调 adb 会找不到。然后是 Python 环境ARTEMIS 的主要代码是 Python 写的建议用 3.10 以上的版本。我试过 3.9有些依赖库的版本会冲突升级到 3.10 之后就没问题了。创建一个虚拟环境是个好习惯避免跟系统里的其他 Python 项目打架。python -m venv artemis-env source artemis-env/bin/activate # Linux/Mac # 或者 artemis-env\Scripts\activate # Windows接下来是手机端的准备。你需要一台 Android 手机或者模拟器开启开发者模式和 USB 调试。如果是真机用数据线连上电脑之后在终端里执行adb devices能看到设备序列号就说明连接成功了。模拟器的话推荐用 Android Studio 自带的 AVD或者 Genymotion 也行但要注意模拟器的 ADB 端口可能跟默认的不一样需要手动指定。注意有些手机品牌比如小米、OPPO开启 USB 调试之后还需要额外开启“USB 调试安全设置”选项否则 ADB 能识别设备但无法注入输入事件。这个坑我踩过当时排查了半天以为是 ARTEMIS 的问题结果是手机权限没给够。3.2 ARTEMIS 安装与 MCP 配置ARTEMIS 的安装方式取决于你拿到的版本。如果是源码方式直接 clone 仓库然后pip install -e .就行。如果是打包好的版本按官方文档的步骤来。我建议用源码方式因为方便看代码和改配置。MCP 的配置是重点。ARTEMIS 作为 MCP Server 运行的时候需要在一个配置文件里声明它提供哪些工具。这个配置文件通常是 JSON 格式里面会列出每个工具的名称、描述和参数 schema。AI 客户端读取这个配置之后就知道有哪些能力可以调用。{ mcpServers: { artemis: { command: python, args: [-m, artemis.mcp_server], env: { ANDROID_DEVICE: emulator-5554 } } } }这个配置的意思是启动一个叫 artemis 的 MCP Server用 python 运行 artemis.mcp_server 模块指定操作的设备是 emulator-5554。实际使用的时候你需要把设备序列号换成你自己的。adb devices命令输出的第一列就是序列号。3.3 模型端的对接ARTEMIS 本身不包含 AI 模型它只负责执行和感知。决策部分需要你接入一个支持 MCP 的 AI 客户端。目前比较常见的做法是用 Claude Desktop 或者自己写一个基于 OpenAI API 的客户端。如果你用 Claude Desktop直接在它的配置文件里加上面那段 MCP 配置就行。如果自己写客户端需要实现 MCP 协议的客户端侧处理工具调用请求和响应。我自己的做法是写了一个简单的 Python 脚本用 OpenAI 的 function calling 能力来对接。核心逻辑是把 ARTEMIS 暴露的工具转换成 OpenAI 的 function 定义模型返回 function call 的时候我这边去调用 ARTEMIS 的对应工具拿到结果之后再喂回给模型。这个循环一直持续到模型认为任务完成或者达到最大步数。import openai from artemis.client import ArtemisClient client ArtemisClient(deviceemulator-5554) tools client.get_mcp_tools() # 获取 ARTEMIS 提供的工具列表 messages [{role: user, content: 打开设置查看当前 Android 版本}] while True: response openai.ChatCompletion.create( modelgpt-4, messagesmessages, toolstools ) msg response.choices[0].message if msg.tool_calls: for call in msg.tool_calls: result client.execute_tool(call.function.name, call.function.arguments) messages.append({role: tool, content: str(result), tool_call_id: call.id}) else: print(msg.content) break这段代码是个最小可运行示例实际用的时候还要处理错误重试、超时、截图编码等细节。但核心逻辑就是这么简单模型说要调什么工具你就调调完把结果告诉它它再决定下一步。4. 核心功能实现与操作细节4.1 屏幕感知的实现方式ARTEMIS 获取屏幕信息有两条路。第一条是 Accessibility Service通过 Android 的无障碍接口拿到当前界面的控件树。每个控件有类型、文本、坐标、是否可点击等属性。这条路的好处是信息结构化AI 能直接知道“这是一个按钮文字是‘搜索’位置在屏幕上方”。坏处是很多 App 对无障碍支持不好控件信息缺失或者层级混乱。第二条路是截图加视觉模型。ARTEMIS 会定期截取屏幕把图片传给视觉模型做理解。视觉模型能识别出界面上的元素和布局但没法直接拿到控件的精确属性。所以实际使用的时候ARTEMIS 会把两路信息做融合用控件树提供精确的坐标和属性用视觉模型补充控件树缺失的信息。我实测下来融合策略的效果比单用任何一路都好。纯控件树在遇到 Flutter 或者游戏界面的时候基本抓瞎纯视觉又容易在密集列表里点错位置。两路结合之后AI 既能知道“这里有个搜索框”又能知道“搜索框的精确坐标是 (540, 320)”。4.2 操作指令的生成与执行AI 决定要做什么之后ARTEMIS 需要把决策翻译成具体的操作指令。支持的操作类型包括点击tap、长按long press、滑动swipe、输入文本input text、按键key event、截图screenshot。每种操作都有对应的参数比如点击需要坐标滑动需要起点和终点坐标以及持续时间。坐标的获取是个关键细节。ARTEMIS 从控件树或者视觉模型拿到的是屏幕上的像素坐标但不同手机的分辨率不一样。ARTEMIS 内部做了归一化处理把坐标转换成 0 到 1 之间的比例值执行的时候再根据当前设备的分辨率还原成像素坐标。这样同一套决策逻辑可以在不同分辨率的手机上运行。输入文本这块有个坑。Android 的 ADB input 命令对中文和特殊字符支持不好直接adb shell input text 你好会报错。ARTEMIS 的解决方案是用 ADB 的广播机制或者通过输入法接口来注入文本。我试过用 ADBKeyboard 这个输入法把文本通过广播发过去效果比较稳定。如果你的场景里经常需要输入中文建议提前把这个输入法装好。提示滑动操作有个容易忽略的参数是持续时间。持续时间太短系统可能识别成快速滑动fling列表会惯性滚动很远。持续时间太长又可能被识别成长按。一般设置 300 到 500 毫秒比较合适具体要看目标 App 的响应特性。4.3 任务编排与状态管理ARTEMIS 执行一个任务的时候不是单步执行完就结束了而是有一个状态管理机制。每一步操作之后它会重新获取屏幕状态判断任务是否完成如果没完成就继续下一步。这个循环的上限通常是 20 到 50 步防止 AI 陷入死循环。状态管理里比较关键的是“任务完成”的判断。有些任务是明确的比如“打开设置里的关于手机页面”看到特定文字就算完成。有些任务是模糊的比如“帮我在购物 App 里找一双便宜的跑鞋”什么时候算“找到”就需要 AI 自己判断。ARTEMIS 的做法是让 AI 在每一步都输出一个状态标记进行中、已完成、失败。如果连续几步都是“进行中”但屏幕没有明显变化就触发超时或者重试逻辑。我自己的经验是给 AI 的任务描述越具体完成判断越准确。与其说“帮我买一双鞋”不如说“打开购物 App搜索跑鞋按价格从低到高排序把前三个结果截图给我”。任务拆得越细AI 每一步的决策空间越小出错的概率也越低。5. 常见问题与排查技巧实录5.1 设备连接类问题问题一adb devices 找不到设备。这是最常见的问题。排查顺序是先检查 USB 线是不是只能充电不能传数据换根线试试然后检查手机上的 USB 调试授权弹窗有没有点“允许”再检查电脑上的 ADB 版本是不是太老adb version看一下建议用 1.0.41 以上的版本。如果是无线调试确保手机和电脑在同一个局域网并且用adb connect命令手动连接。问题二设备找到了但操作没反应。这种情况通常是权限问题。有些手机需要在开发者选项里额外开启“USB 调试安全设置”或者“模拟点击”权限。另外如果手机锁屏了ADB 的输入事件会被拦截ARTEMIS 操作之前需要先确保屏幕是解锁状态。我一般会在任务开始前加一步“唤醒屏幕并解锁”的操作。5.2 操作执行类问题问题三点击位置偏移。这个问题的根源通常是坐标计算错误。检查一下 ARTEMIS 获取的屏幕分辨率跟实际分辨率是否一致。有些手机有虚拟导航栏屏幕的实际可用区域比物理分辨率小如果坐标计算没扣除导航栏高度点击就会偏下。ARTEMIS 的配置里有个screen_offset参数用来补偿这个偏差。问题四输入文本失败。前面提到过中文输入的问题。另外如果目标输入框没有获得焦点输入也会失败。ARTEMIS 在输入之前会先点击输入框确保获得焦点但有些 App 的输入框需要先点击再等待一段时间才能输入。如果遇到输入失败可以在点击和输入之间加一个短暂的等待。问题五滑动不生效。滑动操作对坐标和持续时间都很敏感。如果滑动距离太短可能被识别成点击。如果滑动速度太快可能触发 fling 导致滚动过头。建议先用固定的参数测试比如从屏幕 80% 高度滑到 20% 高度持续时间 400 毫秒确认能正常滚动之后再根据实际需求调整。5.3 常见问题速查表问题现象可能原因排查方法解决方案adb 找不到设备USB 线、授权、ADB 版本换线、检查弹窗、adb version换数据线、点允许、升级 ADB操作无响应权限不足、屏幕锁定检查开发者选项、屏幕状态开启安全调试、先解锁屏幕点击偏移分辨率不匹配、导航栏对比分辨率、检查 offset调整 screen_offset 参数输入失败中文支持、焦点问题测试英文输入、检查焦点装 ADBKeyboard、加等待滑动异常持续时间、距离调整参数测试400ms、80%到20%AI 决策循环任务描述模糊查看每步截图和决策细化任务描述、设步数上限5.4 独家避坑经验第一个经验是关于截图频率的。ARTEMIS 每一步操作后都会截图如果截图频率太高ADB 传输图片会占用大量带宽导致操作延迟明显。我的做法是只在需要的时候截图比如 AI 明确要求获取当前屏幕状态的时候而不是每步都自动截。这样能把单步操作的时间从两三秒降到一秒以内。第二个经验是关于模型选择的。不是所有模型都适合做移动端操作决策。我试过几个模型发现对于界面理解任务视觉能力强的模型明显更好。纯文本模型只能靠控件树的文字信息做决策遇到图标按钮就抓瞎。如果预算允许建议用带视觉能力的模型决策准确率会高很多。第三个经验是关于错误恢复的。AI 操作手机不可能百分之百成功关键是出错之后能不能恢复。ARTEMIS 有个重试机制但默认的重试是“原样再来一次”如果失败原因是界面状态变了重试也没用。我的做法是在重试之前先让 AI 重新观察屏幕根据当前状态调整策略而不是盲目重试。6. 应用场景与扩展思路6.1 移动端自动化测试这是 ARTEMIS 最直接的应用场景。传统的移动端 UI 测试需要为每个测试用例写脚本维护成本很高。用 ARTEMIS 之后你可以用自然语言描述测试用例比如“打开登录页面输入错误的密码验证是否显示错误提示”AI 会自动执行这些步骤并判断结果。这种方式特别适合探索性测试。传统脚本只能测你想到的情况ARTEMIS 可以在你给定的范围内自由探索可能会发现一些你没想到的边界情况。比如你让它“随便点点这个页面看看会不会崩溃”它真的会随机点击各种元素有时候能发现一些隐藏的 bug。不过要注意ARTEMIS 做回归测试的稳定性不如传统脚本。同一个测试用例AI 每次执行的路径可能不一样导致结果有波动。我的建议是探索性测试用 ARTEMIS回归测试还是用传统脚本两者互补。6.2 AI 助手操作手机这是 ARTEMIS 更有想象力的场景。你可以把它接入自己的 AI 助手让助手具备操作手机 App 的能力。比如你说“帮我把今天拍的照片发到朋友圈”助手会打开相册、选照片、打开微信、发朋友圈。整个过程不需要你手动操作。这个场景的技术难点在于跨 App 的任务编排。发朋友圈这个任务涉及相册和微信两个 AppAI 需要知道什么时候切换 App切换之后怎么找到对应的功能入口。ARTEMIS 的通用操作能力让这件事成为可能但实际效果取决于 AI 对 App 界面的理解程度。我实测下来对于主流 App 的常用功能成功率还不错但遇到不熟悉的 App 或者界面改版就需要人工干预。6.3 无障碍辅助ARTEMIS 的感知和操作能力理论上也可以用于无障碍辅助。视障用户可以通过语音告诉 AI 想做什么AI 操作手机完成之后再通过语音反馈结果。这个场景对可靠性的要求比测试场景高得多因为操作失败对用户的影响很大。目前 ARTEMIS 在这个方向上的成熟度还不够但架构上是支持的后续如果有针对性的优化会是一个很有价值的方向。6.4 扩展思路自定义工具注入ARTEMIS 的 MCP 架构支持自定义工具注入。你可以写一些额外的工具注册到 ARTEMIS 的 MCP Server 里让 AI 在操作手机的过程中调用。比如你可以加一个“读取剪贴板”的工具AI 在需要粘贴文本的时候就能用上。或者加一个“发送通知”的工具任务完成之后通知你。from artemis.mcp_server import register_tool register_tool(nameread_clipboard, description读取手机剪贴板内容) def read_clipboard(): result subprocess.run([adb, shell, am, broadcast, -a, clipper.get], capture_outputTrue) return result.stdout.decode()这个扩展机制让 ARTEMIS 不局限于内置的操作能力你可以根据实际需求灵活扩展。我目前加了三个自定义工具读取剪贴板、发送通知、录屏。录屏工具特别有用可以回看 AI 的操作过程方便排查问题。7. 性能优化与稳定性提升7.1 减少 ADB 通信开销ADB 通信是 ARTEMIS 的性能瓶颈之一。每次截图、每次获取控件树、每次发送操作指令都要走 ADB 通道。如果这些操作串行执行单步耗时可能达到两三秒。优化的思路是合并请求和异步执行。合并请求的意思是把多个 ADB 命令打包成一个 shell 脚本一次性执行。比如获取屏幕状态的时候截图和获取控件树可以放在同一个 ADB 会话里减少连接建立的开销。异步执行的意思是截图这种耗时操作可以后台进行不阻塞主流程。ARTEMIS 内部有连接池机制但默认配置可能不是最优的需要根据实际设备调整。7.2 视觉模型的调用优化如果使用视觉模型做界面理解模型调用的延迟是另一个瓶颈。一张截图传给模型模型返回理解结果这个过程可能需要一到三秒。优化的方向有两个一是降低截图分辨率把 1080p 的截图压缩到 720p 甚至更低模型处理速度会快很多对理解精度的影响在可接受范围内二是缓存模型结果如果连续几步屏幕没有明显变化可以复用上一次的理解结果不需要重新调用模型。7.3 稳定性提升的实操技巧第一个技巧是加“确认步骤”。AI 执行一个操作之后不要假设它一定成功了而是主动验证一下。比如点击了搜索按钮之后检查屏幕上是否出现了搜索结果列表。如果没有出现说明点击可能没生效需要重试或者调整策略。第二个技巧是设置合理的超时。每个操作都要有超时限制不能无限等待。点击操作超时设 5 秒页面加载超时设 10 秒模型调用超时设 30 秒。超时之后触发重试或者报错避免整个任务卡死。第三个技巧是记录操作日志。ARTEMIS 每一步的决策、操作、结果都要记录下来包括截图。出问题的时候回看日志能快速定位是哪一步出了错。我一般会把日志按任务 ID 分目录存储每个任务一个文件夹里面按步骤编号存截图和操作记录。8. 个人实操体会与建议ARTEMIS 这个项目我断断续续用了大概两个月踩了不少坑也积累了一些心得。最深的体会是AI 操作手机这件事技术上的难点不在操作本身而在“理解当前状态”和“判断任务是否完成”。操作指令的执行是确定的点击就是点击滑动就是滑动但理解屏幕上的内容、判断当前处于什么页面、决定下一步做什么这些才是真正考验 AI 能力的地方。另一个体会是任务描述的质量直接决定执行效果。我一开始给 AI 的任务描述很笼统比如“帮我设置一下手机”结果 AI 在设置页面里乱转不知道到底要设置什么。后来我把任务拆成具体的步骤“打开设置找到显示选项把亮度调到 50%开启自动亮度”成功率就高了很多。所以如果你打算用 ARTEMIS花时间把任务描述写清楚比调任何参数都管用。还有一点是关于设备的选择。我试过用模拟器和真机模拟器的优势是稳定、可重复但有些 App 在模拟器上运行不正常尤其是依赖硬件传感器的 App。真机的优势是真实但不同品牌、不同型号的手机行为差异很大同一套配置在小米上能用换到华为可能就出问题。如果要做通用方案建议在多种设备上测试不要只盯着一台手机调。最后分享一个小技巧ARTEMIS 的 MCP 配置里可以指定多个设备AI 可以在多个手机之间切换操作。这个能力在多设备协同的场景下很有用比如一台手机播放视频另一台手机录屏。不过多设备管理的复杂度也更高建议先把单设备跑通再考虑多设备。