引言

“测试脚本会因为一个按钮换了位置就崩掉，但一个真正理解界面的 AI 不会。”

这是"一天一个开源项目"系列的第 224 篇。今天的项目是 ARTEMIS。

移动端 UI 自动化测试长期存在一个矛盾：基于元素 ID 或坐标的传统脚本足够快，但极其脆弱——UI 稍微调整一下布局，测试用例就大面积失效，维护成本随着应用迭代速度线性增长。用视觉模型驱动的方案虽然更鲁棒，但速度慢、成本高，不适合大规模回归测试。

ARTEMIS 是 Google 开源的答案，试图在这两个极端之间找到平衡。它把自然语言指令（比如"打开设置，找到电池选项，告诉我当前电量"）转化为可靠的 Android 自动化操作，同时提供两种执行模式：一种为常规确定性任务追求速度，另一种为复杂长周期任务追求准确性和可验证性。更关键的是，它通过 MCP 协议直接接入 Claude Code、Antigravity、Codex 等 AI IDE，让 AI 编程助手获得操作真实手机的能力。

8.1k Stars，Apache-2.0，Python 构建，在 AndroidWorld 基准测试中达到 99%+ 的任务完成率。

你将学到什么

• ARTEMIS 如何把自然语言指令转化为 Android 自动化操作
• Flash 与 Pro 两种执行模式的架构差异及适用场景
• 多模态目标定位：无障碍层级树 + OCR + 视觉模型的组合策略
• 通过 MCP 协议与 Claude Code 等 AI IDE 集成的具体方式
• Python SDK 如何集成进现有的自动化测试框架

前置知识

• 了解 Android 自动化测试的基本概念（ADB、Accessibility 服务）
• 熟悉 Python 异步编程（asyncio）
• 可选：了解 MCP（Model Context Protocol）的基本概念

---

项目背景

项目简介

ARTEMIS 的官方定位是：“让 AI 助手和测试套件像人类一样操作真实手机”（ARTEMIS turns natural-language instructions into reliable Android automation）。

需要澄清一点：这不是安全测试或模糊测试工具，而是面向移动端 UI 自动化测试与日常任务执行的智能代理系统，属于 AI 驱动的移动端测试/自动化框架领域。

团队与项目信息

• 所属组织：Google
• 协议：Apache License 2.0
• 主要语言：Python（要求 Python 3.12+）
• 代码来源：项目说明中标注包含 Minitap, Inc. 开发的源代码，基于开源项目 mobile-use 构建

项目数据

• ⭐ GitHub Stars：8,100+
• 🍴 Forks：770+
• 👀 Watchers：71
• 📄 协议：Apache-2.0
• 🏆 基准成绩：AndroidWorld 基准测试 99%+ 任务完成率（覆盖 20+ 应用、100+ 多步骤任务）

---

主要功能

解决什么问题

传统基于元素 ID/坐标的自动化脚本：
  UI 布局稍微调整 → 元素定位失效 → 测试大面积崩溃
  ↑ 速度快，但极其脆弱，维护成本高

纯视觉模型驱动的方案：
  每一步都靠视觉模型识别界面 → 准确但慢
  ↑ 鲁棒性好，但速度慢、成本高，难以规模化

ARTEMIS 的做法：
  自然语言指令 → 多模态定位（元素索引优先，视觉/坐标兜底）
  ↓ Flash 模式：常规确定性任务，3-5秒/步，快速反应循环
  ↓ Pro 模式：复杂长周期任务，15-40秒/步，规划-执行-验证工作流
  ↑ 根据任务复杂度选择合适的模式，兼顾速度和可靠性

使用场景

1. 移动应用端到端测试自动化

   • 用自然语言描述测试步骤，替代维护脆弱的元素定位脚本

2. Bug 复现与诊断

   • 结合 Logcat 日志和截图采集，快速复现和定位问题

3. 探索性稳定性测试

   • Pro 模式支持长时间、持续监控的探索性测试

4. CI/CD 集成的自动化测试

   • 通过 Python SDK 集成进 pytest 等测试框架，纳入持续集成流水线

5. AI IDE 驱动真实设备操作

   • 让 Claude Code、Antigravity 等 AI 编程助手直接操作手机验证功能

快速开始

克隆并一键启动：

git clone https://github.com/google/artemis.git && cd artemis

# macOS/Linux 一键启动（自动检测安装 ADB、scrcpy、FFmpeg 等依赖）
./start.sh

CLI 直接运行任务：

uv run artemis run "Open Settings, find Battery and tell me current level" --profile flash

为 IDE 安装 MCP 集成：

# 为 Antigravity 安装
uv run artemis mcp --install antigravity

# 为所有支持的 IDE 安装（包括 Codex）
uv run artemis mcp --install all

首次执行任务时，ARTEMIS 会在设备上安装一个"Artemis Accessibility Helper"辅助功能服务，仅在本机读取屏幕布局，不上传数据，可通过命令预装、检查或卸载。

核心特性

1. 四种使用方式

方式	适用场景
Web 可视化测试控制台（artemis ui）	交互式调试和结果查看
MCP 服务器	连接 AI IDE 驱动真实设备
开发者 CLI（artemis run）	自动化测试或基准测试脚本
Python SDK	集成进 pytest 等现有测试框架/CI 流水线

2. Flash 与 Pro 双执行模式

维度	Flash 模式	Pro 模式
响应速度	约 3-5 秒/步	约 15-40 秒/步
架构	单模型观察-思考-执行反应式循环	多智能体图（Planner+Operator+Checker）
任务规划	无任务计划	Planner 维护 Markdown 任务计划，含里程碑
安全机制	无预执行安全网	每个动作先经 XML 校验，像素回退
验证能力	无检查点验证或最终报告	Checker 验证计划检查点，支持最终审查
工具集	无 ADB shell	完整工具集：Explorer、笔记、历史回溯、视频分析
适用场景	常规确定性 UI 任务	100+ 步长周期工作流、持续监控

3. Python SDK 集成示例

uv add "artemis-client @ git+https://github.com/google/artemis.git#subdirectory=packages/artemis-client"

import asyncio
from artemis_client import ArtemisClient


async def main():
    client = ArtemisClient(
        "http://artemis-host:8000",
        device_serial="emulator-5554",  # 可选：指定目标设备序列号
        default_profile="flash",  # "flash"（快速反应）或 "pro"（深度推理）
    )

    result = await client.run(
        "Open System Settings, go to 'Battery', verify battery percentage is displayed, and check for any crash dialogs.",
    )

    assert result.succeeded, f"Test failed: {result.error or result.status}"
    print(f"✅ Test Passed! Device: {result.device_serial} | Trace ID: {result.trace_id}")


if __name__ == "__main__":
    asyncio.run(main())

SDK 号称"零运行时依赖"，ADB、Agent、模型和图像处理都保留在设备主机端，支持强类型 Pydantic 结构化输出和断言，可直接接入 pytest 等测试框架。

4. MCP 集成配置

以 Claude Desktop 为例（claude_desktop_config.json）：

{
  "mcpServers": {
    "artemis": {
      "command": "/path/to/artemis/.venv/bin/python",
      "args": ["-m", "mcp_server"],
      "cwd": "/path/to/artemis"
    }
  }
}

文档还建议为 AI Agent 挂载行为规则文件 mcp_server/rules.md，涵盖编码前的主动探索、Flash/Pro 路由策略、延迟补偿等约束逻辑。

---

深入剖析

Flash 与 Pro：一个务实的速度/可靠性取舍

ARTEMIS 没有用单一模式应对所有任务，而是明确拆分出两个架构完全不同的执行路径：

Flash 模式（反应式）：
  观察界面 → 思考下一步 → 执行动作 → 循环
  ↑ 单模型循环，无规划、无安全网、无最终报告
  ↑ 默认循环轮次不受限（历史用压缩而非截断管理）
  ↑ 适合"打开设置改个开关"这类确定性强的短任务

Pro 模式（规划验证）：
  Planner 制定 Markdown 任务计划（含里程碑和验证项）
      ↓
  Operator 执行单个动作前先做"Safety Net"校验
      ↓ （先比对实时 UI 树，再像素回退验证）
  遇到阻塞 → 开启"执行事件"，Operator 自主处理恢复
      ↓
  Checker（只读）验证计划检查点，支持退出前最终审查

这个设计的核心洞察是：移动端自动化任务的复杂度分布是双峰的。大量任务是"打开某个页面确认某个状态"式的确定性短任务，用简单反应式循环就足够快且够用；少数任务是需要多步骤规划、容错、长时间监控的复杂工作流，这时候多智能体的规划-执行-验证结构才能保证可靠性。用同一套架构应对两种极端场景，无论选哪种都是浪费。

多模态目标定位的容错设计

ARTEMIS 的元素定位机制体现了一种"优先精确、逐级降级"的容错思路：

定位优先级：
  1. 无障碍层级树（Accessibility Hierarchy）— 最精确，标准 Android UI 首选
  2. OCR 文字识别 — 处理层级树信息不足的场景
  3. 视觉模型识别 — 兜底方案，处理自定义 Canvas/Compose/Flutter 界面

标准 Android 控件通常能被无障碍服务准确暴露语义信息，这是最快最可靠的定位方式；但越来越多应用用 Compose、Flutter 或自定义 Canvas 绘制界面，这些界面对无障碍服务不友好，此时才需要 OCR 和视觉模型介入。这种分层容错策略避免了"所有情况都用最贵的方案"的浪费，也避免了"标准控件识别不出来就直接失败"的脆弱性。

共享历史压缩：应对长周期任务的记忆管理

Flash 和 Pro 共用一套历史压缩机制，这个细节值得关注：

问题：长周期任务(尤其 Pro 模式的 100+ 步工作流)会积累大量截图和操作记录
  ↑ 直接塞进上下文会超出窗口限制
  ↑ 简单截断会丢失早期关键信息

ARTEMIS 的做法：
  旧截图 → 替换为视觉摘要（保留语义，丢弃像素细节）
  已完成步骤 → 压缩为可检索的历史片段
  ↑ Agent 需要回溯时可以检索，而不是永远携带全部历史

这种设计让 Flash 模式即便不设置循环轮次上限也能长期稳定运行，也是 Pro 模式支持 100+ 步工作流的记忆管理基础。

与同类移动自动化方案的对比

维度	Appium（传统脚本）	纯视觉模型驱动方案	ARTEMIS
定位方式	固定元素 ID/XPath	纯视觉识别	元素索引优先 + OCR + 视觉兜底
UI 变化容错	❌ 脆弱	✅ 较鲁棒	✅ 较鲁棒
执行速度	快	慢	Flash 快 / Pro 适中
自然语言驱动	❌	部分支持	✅ 原生支持
AI IDE 集成（MCP）	❌	少见	✅ 原生支持多种 IDE
长周期任务规划验证	需自行实现	少见	✅ Pro 模式原生支持
开源	✅	视具体项目	✅ Apache-2.0

ARTEMIS 的差异化在于把"自然语言驱动 + 多模态容错定位 + AI IDE 原生集成"这三件事整合在一套工具里，同时用双模式设计避免了"要么全用视觉模型太慢，要么全用固定脚本太脆弱"的两难。

---

项目地址与资源

官方资源

• 🌟 GitHub：https://github.com/google/artemis
• 📄 协议：Apache License 2.0
• 🐛 Issues：GitHub Issues

相关资源

• AndroidWorld — Google Research 的移动 Agent 基准测试项目，ARTEMIS 的评测基准
• Model Context Protocol — ARTEMIS 与 Claude Code 等 AI IDE 集成所依托的标准协议
• mobile-use — ARTEMIS 构建所基于的开源项目（Minitap, Inc.）

---

总结与展望

核心要点回顾

1. 自然语言驱动的移动端自动化：用指令替代脆弱的元素定位脚本，降低测试维护成本
2. Flash/Pro 双模式设计：按任务复杂度选择反应式快速循环或规划验证工作流，兼顾速度与可靠性
3. 多模态容错定位：无障碍层级树优先，OCR 和视觉模型逐级兜底，适配从标准控件到自定义 Canvas 的各类界面
4. MCP 原生集成：让 Claude Code、Antigravity、Codex 等 AI IDE 直接获得操作真实 Android 设备的能力
5. AndroidWorld 99%+ 成绩：在标准移动 Agent 基准测试中验证过的可靠性

适合谁

• 移动应用测试团队：想摆脱脆弱的元素定位脚本，降低 UI 变化带来的测试维护成本
• AI 应用开发者：想让 AI 编程助手具备操作真实 Android 设备的能力，用于功能验证或 Bug 复现
• CI/CD 流水线维护者：需要把移动端自动化测试无缝接入现有测试框架和持续集成流程
• 探索性测试/稳定性测试团队：需要长周期、持续监控的移动端测试能力

一句话评价

ARTEMIS 没有在"快但脆弱"和"稳但慢"之间选边站，而是用 Flash/Pro 双模式把这个矛盾直接拆开——这可能是移动端自动化走向 AI 驱动过程中一个务实的中间答案。

---

欢迎访问 PrimeSkills —— 一个精心策划的 AI Agent 与技能市场，所有内容均经过真实企业级工作流验证。没有噱头，只有真正有效的东西。

更多实用知识和有趣产品，欢迎访问我的个人主页