artemis

Artemis Banner 图1：ARTEMIS 标志图（来源：GitHub 仓库）

一、项目背景：为什么你需要关注它？

移动端 App 测试是个出了名的苦差事——UI 变动频繁、跨应用流程难覆盖、弹窗干扰导致脚本崩溃。这些问题在 Web 端早已被 AI Coding Agent 逐步攻克，但手机端却长期停留在"要么手写 XPath，要么花钱买商业工具"的两难局面。

ARTEMIS 正是 Google 想打破这个僵局的答案。

2026 年 8 月，Google Pixel 测试工程团队将 ARTEMIS 开源，Apache-2.0 许可证允许企业直接 Fork 使用。它由自然语言指令出发，让 AI 智能体像真人一样操控真实的 Android 手机——点击、滑动、读取屏幕、收集 Logcat 日志。更关键的是，它通过 MCP（Model Context Protocol） 将手机控制能力直接暴露给主流 AI IDE（Antigravity、Claude Code、Windsurf、Cursor 等），让开发者在熟悉的编程环境中就能驱动真机测试。

实际上，ARTEMIS 的诞生并非完全从零开始。项目代码整合了法国初创公司 Minitap 的开源项目 mobile-use（Apache-2.0），此事在开源社区引发了一场署名争议，Google 于 2026 年 9 月 12 日在 README 中补充了归属说明，相关讨论在 Hacker News 上获得了 166 个热度点。

二、核心能力：它能做什么？

2.1 自然语言 → 真实手机操作

用户只需用自然语言描述任务，例如：

"打开设置，找到电池，告诉我当前电量，然后打开 Maps 规划一条到机场的路线"

ARTEMIS 会自动将这个指令拆解为多步 UI 操作序列，在真实手机上逐项执行。它支持的场景包括：

跨应用工作流：从 Maps 导航切到 YouTube 播放音乐，一个指令搞定
端到端功能测试：登录流程、支付验证、表单填写
Bug 复现：直接在设备上重现用户报告的问题并收集诊断数据
稳定性测试：连续 10 小时以上的猴子测试（Monkey Testing）

2.2 双模式执行引擎

ARTEMIS 提供两种执行策略，用户可根据任务复杂度灵活选择：

Flash 模式（轻量快速）：

单一大语言模型执行"观察→思考→行动"循环
每步耗时仅 3–5 秒，适合确定性 UI 任务
无任务规划、无前置检查、无验证报告
历史记录通过异步压缩而非截断，支持长时间运行

Pro 模式（深度推理）：

多智能体图架构：Planner（规划者）+ Operator（操作者）+ Checker（验证者）
每步耗时 15–40 秒，支持 100+ 步长任务
每步操作前均有 Safety Net（XML-first + 像素备选）拦截异常弹窗
支持里程碑验证、意外阻塞自动恢复、最终报告生成
适合需要严密验证的复杂跨应用工作流

2.3 三层渐进式定位引擎

传统的移动端自动化严重依赖 XPath 或元素 ID，一旦 UI 改版就会集体失效。ARTEMIS 采用了"渐进式降级"策略：

Accessibility 层级优先（约 150ms，0 Token）：从系统无障碍服务读取界面元素索引号，精准且稳定
视觉模型兜底：对于 Compose/Flutter/Canvas 等无障碍信息缺失的自定义 UI，切换视觉定位
坐标备用方案：最终万不得已时使用屏幕坐标，附带预执行像素校验避免误点击

2.4 IDE 原生集成（MCP）

ARTEMIS 原生实现了 MCP 服务器，提供 5 个标准化工具：

MCP 工具	功能
`mobile_run_task`	异步分发自然语言任务，不阻塞 IDE
`mobile_manage_task`	控制运行中的任务，中断/恢复
`mobile_get_device_state`	获取实时截图、前台应用包名、屏幕方向
`mobile_inspect_trace`	审查执行步骤和动作轨迹
`mobile_diagnose`	捕获 Logcat 输出、崩溃堆栈、系统资源

安装方式简洁：uv run artemis mcp --install claude（Claude Code）或 uv run artemis mcp --install antigravity（Antigravity）。ARTEMIS 还会自动将 Mobile Testing Mindset 规则文件（mcp_server/rules.md）注入到 IDE 系统提示中，指导 AI Coding Agent 以资深移动测试工程师的思维执行操作。

三、技术架构拆解

3.1 技术栈一览

层次	技术选型
编排框架	LangGraph（多智能体图）+ LangChain
Python 版本	3.12+
多模态 LLM	Google Gemini（默认）、Claude、GPT-4o、Qwen-VL、Ollama
设备通信	ADB（Android Debug Bridge）+ uiautomator2 + adbutils
视觉处理	OpenCV + Pillow + imageio-ffmpeg
Web 控制台	FastAPI + uvicorn + Angular（前端）
SDK 形态	Python SDK（`artemis-client`）+ MCP Server
协议	MCP（Model Context Protocol）

3.2 目录结构

artemis/
├── artemis/            # 核心 Agent 模块（17个智能体：planner/operator/checker/explorer/log_analyzer等）
├── apps/
│   ├── admin_console/  # Web 可视化控制台（FastAPI + Angular）
│   └── showcase_ui/     # Demo 展示界面（Angular）
├── mcp_server/         # MCP 服务器实现
├── config/              # artemis.jsonc（模型路由、Agent 参数配置）
├── scripts/             # 辅助脚本
└── packages/artemis-client/  # Python SDK 包

值得注意的是，config/artemis.jsonc 中可以配置不同 Agent 节点使用不同的模型：主循环默认 Gemini 3.8 Flash，Hopper 节点使用 Gemini 3.5 Flash Lite，物体检测节点使用 Gemini Robotics ER 2。

四、部署体验：能快速跑起来吗？

4.1 容器化支持

ARTEMIS 提供多阶段 Dockerfile，构建产物为 wheel 包，最终镜像仅运行 Web 控制台服务：

阶段 1：Node.js 构建 Angular 前端
阶段 2：Python 构建 wheel 包
阶段 3：运行时镜像（python:3.12-slim + ADB + curl）

Dockerfile 中将前端构建产物复制进镜像，因此构建出的镜像可独立运行 Web 控制台（端口 8080）。不支持 docker-compose 一键启动完整测试环境，因为完整功能需要连接真实 Android 设备。

4.2 一键启动脚本

项目提供跨平台启动脚本：

# macOS / Linux
./start.sh

# Windows PowerShell
.\start.bat

脚本会自动：

检测并安装 ADB、scrcpy、FFmpeg、Python（uv）依赖
配置 MCP 服务器到检测到的 IDE（Antigravity、Claude Code 等）
注入 Mobile Testing Mindset 规则文件
启动 Web 控制台（http://localhost:8000）

4.3 使用门槛

维度	描述
硬件要求	Android 真机（USB 调试开启）或 Android 模拟器；无需 GPU
网络要求	需访问 Google Gemini API（或配置其他模型 Key）
隐私注意	Artemis Accessibility Helper 会在设备上安装辅助服务，只读取本地屏幕，无网络上传；`ARTEMIS_KEEP_DEVICE_AWAKE=true` 默认保持设备唤醒
部署难度	中等——脚本已封装大部分复杂度，配置模型 API Key 是主要门槛

五、benchmark 争议：99% 是真的吗？

ARTEMIS 在 Google Research 的 AndroidWorld 基准测试上自报 99%+ 任务完成率，涉及 20+ 真实应用、100+ 多步任务。这个数字值得冷静看待：

自报数据：AndroidWorld 排行榜本身不验证提交，项目方报多少就是多少
对比混淆：Minitap（即 mobile-use 的开发者）自己评测 mobile-use 在 2026 年 1 月得分 100%，但排行榜上显示的是较旧的 91.4%，Google 用自己的新鲜自报数据对比竞争对手的旧数据
代码渊源：ARTEMIS 本身建立在 Minitap 的代码基础上，并非完全独立评测

建议：在生产项目上使用前，用自己的真实测试集跑一遍，而非直接套用 99% 的数字。ARTEMIS 对传统 Appium/Maestro 最大的优势在于"自然语言维护成本低"和"与 AI Coding Agent 无缝集成"，这两个价值点不需要依赖 benchmark 数字来支撑。

六、项目亮点与局限性

亮点

零维护测试用例：自然语言编写测试，用例对 UI 改版有天然容错性
极速执行：Flash 模式 3–5 秒/步，远快于通用移动 VLM Agent 的 20–30 秒
真正打通编码工具链：Claude Code 里直接驱动真机做 QA，Dev 和 Test 在同一个界面完成
Safety Net 设计优秀：Pro 模式的事前拦截 + 事后恢复机制，真正解决了"弹窗导致测试卡死"的行业痛点

局限性

仅支持 Android：iOS 支持在路线图上，尚未落地
Benchmark 可信度存疑：99% 是自报数据，未经独立验证
模型 Key 成本：Gemini API 调用有成本，大规模回归测试需关注用量
无 CI 原生集成说明：虽然支持 Python SDK + CLI，但缺乏与 GitHub Actions 等常见 CI 系统的官方集成指南
法律争议隐患：整合自 Minitap 代码的事实可能引发许可证方面的持续争议

七、总结与适用场景

ARTEMIS 代表的趋势是：让 AI Coding Agent 把手机当另一块屏幕来用。它真正解决的不是"能不能自动化"的问题（Appium 也能做），而是"谁来写和维护这些自动化脚本"的问题。

强烈推荐尝试 ARTEMIS 的场景：

移动 App 的 AI Coding Agent 用户（Antigravity / Claude Code / Windsurf 重度用户）
需要频繁做跨应用回归测试的 QA 团队
想把移动端 Bug 复现流程自动化、减少人工操作的开发团队

暂不推荐：

iOS App 测试（iOS 支持缺失）
需要 100% 精确可复现结果的合规测试（传统 Maestro/Espresso 仍是更稳的选择）
对 benchmark 数字有强依赖的评测场景

Artemis 工作流演示 图2：ARTEMIS 演示——在 Maps 规划路线后切换到 YouTube 播放音乐（来源：GitHub 仓库）

工作流步骤1：指令输入 图3：Antigravity 中输入自然语言测试指令（来源：GitHub 仓库）

工作流步骤2：测试计划生成 图4：ARTEMIS 自动生成多步测试计划（来源：GitHub 仓库）

工作流步骤3：自主执行 图5：ARTEMIS 在真实设备上执行测试并收集 Logcat（来源：GitHub 仓库）

工作流步骤4：报告输出 图6：最终测试报告——结构化发现、指标表与原始数据集（来源：GitHub 仓库）

Artemis Banner 图1：ARTEMIS 标志图（来源：GitHub 仓库）

一、项目背景：为什么你需要关注它？

ARTEMIS 正是 Google 想打破这个僵局的答案。

实际上，ARTEMIS 的诞生并非完全从零开始。项目代码整合了法国初创公司 Minitap 的开源项目 mobile-use（Apache-2.0），此事在开源社区引发了一场署名争议，Google 于 2026 年 9 月 12 日在 README 中补充了归属说明，相关讨论在 Hacker News 上获得了 166 个热度点。

二、核心能力：它能做什么？

2.1 自然语言 → 真实手机操作

用户只需用自然语言描述任务，例如：

"打开设置，找到电池，告诉我当前电量，然后打开 Maps 规划一条到机场的路线"

ARTEMIS 会自动将这个指令拆解为多步 UI 操作序列，在真实手机上逐项执行。它支持的场景包括：

跨应用工作流：从 Maps 导航切到 YouTube 播放音乐，一个指令搞定
端到端功能测试：登录流程、支付验证、表单填写
Bug 复现：直接在设备上重现用户报告的问题并收集诊断数据
稳定性测试：连续 10 小时以上的猴子测试（Monkey Testing）

2.2 双模式执行引擎

ARTEMIS 提供两种执行策略，用户可根据任务复杂度灵活选择：

Flash 模式（轻量快速）：

单一大语言模型执行"观察→思考→行动"循环
每步耗时仅 3–5 秒，适合确定性 UI 任务
无任务规划、无前置检查、无验证报告
历史记录通过异步压缩而非截断，支持长时间运行

Pro 模式（深度推理）：

多智能体图架构：Planner（规划者）+ Operator（操作者）+ Checker（验证者）
每步耗时 15–40 秒，支持 100+ 步长任务
每步操作前均有 Safety Net（XML-first + 像素备选）拦截异常弹窗
支持里程碑验证、意外阻塞自动恢复、最终报告生成
适合需要严密验证的复杂跨应用工作流

2.3 三层渐进式定位引擎

传统的移动端自动化严重依赖 XPath 或元素 ID，一旦 UI 改版就会集体失效。ARTEMIS 采用了"渐进式降级"策略：

Accessibility 层级优先（约 150ms，0 Token）：从系统无障碍服务读取界面元素索引号，精准且稳定
视觉模型兜底：对于 Compose/Flutter/Canvas 等无障碍信息缺失的自定义 UI，切换视觉定位
坐标备用方案：最终万不得已时使用屏幕坐标，附带预执行像素校验避免误点击

2.4 IDE 原生集成（MCP）

ARTEMIS 原生实现了 MCP 服务器，提供 5 个标准化工具：

MCP 工具	功能
`mobile_run_task`	异步分发自然语言任务，不阻塞 IDE
`mobile_manage_task`	控制运行中的任务，中断/恢复
`mobile_get_device_state`	获取实时截图、前台应用包名、屏幕方向
`mobile_inspect_trace`	审查执行步骤和动作轨迹
`mobile_diagnose`	捕获 Logcat 输出、崩溃堆栈、系统资源

三、技术架构拆解

3.1 技术栈一览

层次	技术选型
编排框架	LangGraph（多智能体图）+ LangChain
Python 版本	3.12+
多模态 LLM	Google Gemini（默认）、Claude、GPT-4o、Qwen-VL、Ollama
设备通信	ADB（Android Debug Bridge）+ uiautomator2 + adbutils
视觉处理	OpenCV + Pillow + imageio-ffmpeg
Web 控制台	FastAPI + uvicorn + Angular（前端）
SDK 形态	Python SDK（`artemis-client`）+ MCP Server
协议	MCP（Model Context Protocol）

3.2 目录结构

artemis/
├── artemis/            # 核心 Agent 模块（17个智能体：planner/operator/checker/explorer/log_analyzer等）
├── apps/
│   ├── admin_console/  # Web 可视化控制台（FastAPI + Angular）
│   └── showcase_ui/     # Demo 展示界面（Angular）
├── mcp_server/         # MCP 服务器实现
├── config/              # artemis.jsonc（模型路由、Agent 参数配置）
├── scripts/             # 辅助脚本
└── packages/artemis-client/  # Python SDK 包

四、部署体验：能快速跑起来吗？

4.1 容器化支持

ARTEMIS 提供多阶段 Dockerfile，构建产物为 wheel 包，最终镜像仅运行 Web 控制台服务：

阶段 1：Node.js 构建 Angular 前端
阶段 2：Python 构建 wheel 包
阶段 3：运行时镜像（python:3.12-slim + ADB + curl）

4.2 一键启动脚本

项目提供跨平台启动脚本：

# macOS / Linux
./start.sh

# Windows PowerShell
.\start.bat

脚本会自动：

检测并安装 ADB、scrcpy、FFmpeg、Python（uv）依赖
配置 MCP 服务器到检测到的 IDE（Antigravity、Claude Code 等）
注入 Mobile Testing Mindset 规则文件
启动 Web 控制台（http://localhost:8000）

4.3 使用门槛

维度	描述
硬件要求	Android 真机（USB 调试开启）或 Android 模拟器；无需 GPU
网络要求	需访问 Google Gemini API（或配置其他模型 Key）
隐私注意	Artemis Accessibility Helper 会在设备上安装辅助服务，只读取本地屏幕，无网络上传；`ARTEMIS_KEEP_DEVICE_AWAKE=true` 默认保持设备唤醒
部署难度	中等——脚本已封装大部分复杂度，配置模型 API Key 是主要门槛

五、benchmark 争议：99% 是真的吗？

ARTEMIS 在 Google Research 的 AndroidWorld 基准测试上自报 99%+ 任务完成率，涉及 20+ 真实应用、100+ 多步任务。这个数字值得冷静看待：

自报数据：AndroidWorld 排行榜本身不验证提交，项目方报多少就是多少
对比混淆：Minitap（即 mobile-use 的开发者）自己评测 mobile-use 在 2026 年 1 月得分 100%，但排行榜上显示的是较旧的 91.4%，Google 用自己的新鲜自报数据对比竞争对手的旧数据
代码渊源：ARTEMIS 本身建立在 Minitap 的代码基础上，并非完全独立评测

六、项目亮点与局限性

亮点

零维护测试用例：自然语言编写测试，用例对 UI 改版有天然容错性
极速执行：Flash 模式 3–5 秒/步，远快于通用移动 VLM Agent 的 20–30 秒
真正打通编码工具链：Claude Code 里直接驱动真机做 QA，Dev 和 Test 在同一个界面完成
Safety Net 设计优秀：Pro 模式的事前拦截 + 事后恢复机制，真正解决了"弹窗导致测试卡死"的行业痛点

局限性

仅支持 Android：iOS 支持在路线图上，尚未落地
Benchmark 可信度存疑：99% 是自报数据，未经独立验证
模型 Key 成本：Gemini API 调用有成本，大规模回归测试需关注用量
无 CI 原生集成说明：虽然支持 Python SDK + CLI，但缺乏与 GitHub Actions 等常见 CI 系统的官方集成指南
法律争议隐患：整合自 Minitap 代码的事实可能引发许可证方面的持续争议

七、总结与适用场景

强烈推荐尝试 ARTEMIS 的场景：

移动 App 的 AI Coding Agent 用户（Antigravity / Claude Code / Windsurf 重度用户）
需要频繁做跨应用回归测试的 QA 团队
想把移动端 Bug 复现流程自动化、减少人工操作的开发团队

暂不推荐：

iOS App 测试（iOS 支持缺失）
需要 100% 精确可复现结果的合规测试（传统 Maestro/Espresso 仍是更稳的选择）
对 benchmark 数字有强依赖的评测场景

Artemis 工作流演示 图2：ARTEMIS 演示——在 Maps 规划路线后切换到 YouTube 播放音乐（来源：GitHub 仓库）

工作流步骤1：指令输入 图3：Antigravity 中输入自然语言测试指令（来源：GitHub 仓库）

工作流步骤2：测试计划生成 图4：ARTEMIS 自动生成多步测试计划（来源：GitHub 仓库）

工作流步骤3：自主执行 图5：ARTEMIS 在真实设备上执行测试并收集 Logcat（来源：GitHub 仓库）

工作流步骤4：报告输出 图6：最终测试报告——结构化发现、指标表与原始数据集（来源：GitHub 仓库）

社区活跃度

一、项目背景：为什么你需要关注它？

二、核心能力：它能做什么？

2.1 自然语言 → 真实手机操作

2.2 双模式执行引擎

2.3 三层渐进式定位引擎

2.4 IDE 原生集成（MCP）

三、技术架构拆解

3.1 技术栈一览

3.2 目录结构

四、部署体验：能快速跑起来吗？

4.1 容器化支持

4.2 一键启动脚本

4.3 使用门槛

五、benchmark 争议：99% 是真的吗？

六、项目亮点与局限性

亮点

局限性

七、总结与适用场景

社区活跃度

一、项目背景：为什么你需要关注它？

二、核心能力：它能做什么？

2.1 自然语言 → 真实手机操作

2.2 双模式执行引擎

2.3 三层渐进式定位引擎

2.4 IDE 原生集成（MCP）

三、技术架构拆解

3.1 技术栈一览

3.2 目录结构

四、部署体验：能快速跑起来吗？

4.1 容器化支持

4.2 一键启动脚本

4.3 使用门槛

五、benchmark 争议：99% 是真的吗？

六、项目亮点与局限性

亮点

局限性

七、总结与适用场景