一、引言：移动端智能体浪潮为何兴起

2025 年以来，一个明显的技术趋势是：大模型从“会说话的聊天窗口”走向“会动手的智能体”。而智能体最早、也最直观落地的场景，恰恰是我们每天握在手里的智能手机。

想象这样一个场景：你对着电脑说一句“打开手机上的测试应用，登录测试账号，执行下单流程，把结果截图存下来”，然后整台手机就在无人值守的情况下把这一连串操作做完。这正是“大模型 + ADB”驱动的移动端 AI Agent（智能体）所具备的能力。

从工程视角看，这套能力之所以突然变得可行，依赖两个底层支点：

1. ADB（Android Debug Bridge，安卓调试桥）：Google 官方提供的、连接电脑与安卓设备的调试通道。通过它，程序可以截图、读取界面控件树、模拟点击/滑动/输入、安装应用、抓取日志——几乎覆盖了驱动手机所需的一切底层能力。
2. 多模态大模型（VLM）：像 Gemini、GPT-4o、Qwen2.5-VL 这样既能“看图”又能“推理”的模型。它们能够理解屏幕截图上的文字、按钮、布局，并推理出“下一步该点击哪里、该输入什么、该往哪个方向滑动”。

把两者拼起来，就构成了一个完整的闭环智能体。而围绕“如何组织这个闭环”，业界已经涌现出多款开源框架——它们各有侧重，有的偏向测试工程，有的偏向个人助理，有的只是极简的工具桥。本文就聚焦这四款最具代表性的方案做一次全景拆解。

二、底层原理：ADB 与大模型如何驱动一台手机

在讨论具体框架之前，必须先理解它们共享的底层运行逻辑。几乎所有手机 Agent 都遵循同一个 “感知 → 推理 → 执行 → 反馈” 循环：

flowchart LR
A[用户任务描述<br/>自然语言] --> B[感知 Perception<br/>ADB截图 + UI控件树]
B --> C[推理 Reasoning<br/>多模态大模型理解页面]
C --> D[执行 Action<br/>翻译为ADB指令]
D --> E[反馈 Feedback<br/>再次截图校验结果]
E -->|未完成| B
E -->|任务完成| F[输出结果/报告]

2.1 四个环节的工程细节

环节一：感知（Perception） 智能体通过两条路径“看见”手机屏幕：

• 控件树路径（首选）：执行 adb shell uiautomator dump 导出当前界面的 UI 控件层级，得到每个控件的 id、text、bounds 等结构化信息。这条路径不依赖像素坐标，定位精准、稳定性高，是主流框架的首选。
• 视觉截图路径（兜底）：执行 adb shell screencap 截取屏幕位图，交给多模态模型做视觉理解。适用于 H5 页面、游戏画面等没有标准控件的场景，但容易受到画面干扰，定位精度下降。

环节二：推理（Reasoning） 大模型拿到“截图 + 控件树 + 任务描述”后，判断当前页面状态，决策下一步动作。这一步是整个闭环的“大脑”，模型能力直接决定了任务的完成率——这也是为什么各家框架都在优化模型选型。

环节三：执行（Action） 把模型的决策翻译成真实的 ADB 指令下发到设备：

adb shell input tap x y # 点击坐标 (x,y)
adb shell input text "test@123" # 输入文字
adb shell input swipe x1 y1 x2 y2 # 从(x1,y1)滑动到(x2,y2)
adb shell input keyevent 4 # 按返回键
adb shell am start -n pkg/.MainActivity # 拉起指定App

环节四：反馈（Feedback） 再次截图/读取控件树，校验刚才的动作是否生效、任务是否完成；若失败则重试或调整策略，直到任务结束。

2.2 一个关键的认知澄清

很多初学者误以为“让大模型直接输出 ADB 命令”就能完成任务。实际上，裸模型写出的 ADB 命令经常坐标错位、无法理解页面状态、更不会在失败后自我纠偏。真正稳定的是像 Artemis 这样的框架，它在模型外围做了 UI 元素定位、MCP 工具封装、失败重试、结果校验等多层工程化处理。这也是“框架”存在的根本价值。

三、四大开源框架逐帧拆解

理解了底层原理，我们再来看四款框架各自的定位与实现。

3.1 Google Artemis：为测试工程而生的“闭环大师”

Artemis 是 Google 开源的一套面向安卓应用测试的智能体框架，也是目前测试工程化能力最完整的开源方案。它有几个标志性特点：

（1）模型完全解耦 Artemis 不绑定任何特定大模型。它通过 config/artemis.json（支持 JSONC 注释）+ .env 的方式管理模型配置，可自由切换 Gemini、OpenAI、Claude，甚至本地 Ollama 模型。这为不同安全等级的环境提供了极大灵活性。

（2）双感知策略 优先读取无障碍 UI 控件树；当控件树失效时，自动降级为 VLM 视觉识别。这套策略显著提升了在不同类型页面上的稳定性。

（3）完整的测试闭环 Artemis 内置了 Plan → Execute → Verify → Summarize 的完整流程：会先生成带校验点的测试计划，每一步自动断言校验、记录 logcat 日志、截图留痕，失败自动重试并生成可读的测试报告。这套能力是其他轻量框架普遍不具备的。

（4）MCP 原生支持 Artemis 本身就是一个 MCP Server，可以直接被 Claude Code、Cursor 等 IDE 编码助手调用，实现“编码 Agent 驱动手机做测试”的联动。

需要特别说明：Mobile-Use 是 Artemis 的底层核心，Artemis 在其之上叠加了断言、报告、日志、Web 控制台等测试工程化能力。理解了这一点，就能明白两者为何“师出同门”又“定位迥异”。

适用场景：安卓 APP 自动化回归测试、真机巡检、企业测试中台建设、与 IDE 编码助手联动。

Artemis 的模型配置机制详解：Artemis 把模型配置拆成两个文件，这一设计非常值得借鉴：

• config/artemis.json（或 artemis.jsonc，支持注释）：负责声明模型与 Provider，即“用哪个模型、默认和降级模型分别是什么”。例如：

{
  "default_model": "google/gemini-3.8-flash",
  "fallback_model": "google/gemini-3.7-flash",
  "providers": {
    "google": { "type": "gemini" },
    "openai": { "type": "openai", "base_url": "${OPENAI_BASE_URL}" }
  }
}

这里 ${OPENAI_BASE_URL} 是环境变量引用语法，表示从 .env 读取对应值，实现了“敏感信息与代码解耦”。

• .env：存放真正的密钥与接口地址，属于敏感文件，绝不能提交进 git 仓库。GEMINI_API_KEY、OPENAI_API_KEY、ANTHROPIC_API_KEY 等都放这里。

Artemis 官方界面提供了“Custom Configuration（自定义配置）”与“Google Gemini（推荐）”两种模式：前者手动声明 provider，灵活适配任意模型；后者只需填一个 Gemini Key 即可极速上手。对团队而言，前者配合环境变量是最佳实践，既保留了切模型的自由度，又规避了密钥泄露风险。fallback_model 则承担了“主模型调用失败时自动降级”的容错职责，这在模型服务不稳定时价值巨大。

3.2 Mobile-Use：轻量跨端的核心 Agent

Mobile-Use（minitap-ai）是 Minitap 公司开源的手机智能体框架，基于 Python 与 LangGraph 编排，最大的差异化价值在于同时支持 Android + iOS，且性能表现优异（是 AndroidWorld 基准上首个拿到满分 116/116 的开源手机 Agent）。

架构三层：

• Agent Planner（LangGraph）：负责循环闭环，包含重试、异常恢复。
• Device Controller：统一封装 Android（ADB + uiautomator2）与 iOS（IDB）两套设备指令，对外呈现一套统一 API。
• LLM 接入层：完全可插拔，兼容全部 OpenAI 兼容接口，既支持云端模型，也支持本地 Ollama。

优势：一套代码控制安卓 + 苹果；架构轻量，无厚重测试模块，二次改造空间大；LangGraph 原生编排，可自定义任务循环与校验逻辑。短板：原生不是为测试平台设计，断言、报告、用例管理需要二次开发；iOS 受苹果沙箱限制，稳定性弱于安卓；社区与中文生态弱于 Artemis、AutoGLM。

适用场景：需要同时控制安卓 + iPhone 的场景、个人轻量自动化、基于 MCP 客户端调用手机。

3.3 AutoGLM Phone Agent：中文日常助理的“特长生”

AutoGLM Phone Agent 是智谱 AI 推出的中文 GUI 手机助理智能体，配套自研的 AutoGLM-Phone-9B 多模态模型，核心优势是对国内主流 App 的深度适配。

• 针对微信、QQ、淘宝、京东、美团、饿了么、12306、滴滴、B 站、抖音、小红书等 50+ 国内高频 App 做了专项数据微调，中文弹窗、验证码、登录、支付流程的识别成功率明显高于通用海外模型。
• 内置 ADB 输入法适配，解决安卓输入框、验证码输入的痛点。
• 自带敏感操作二次确认机制。

需要客观指出其边界：AutoGLM 并不支持所有 App。它对清单内的国内主流 App 表现优异，但对小众冷门 App、游戏、企业自研内部 App、无标准控件的 H5 页面，泛化能力明显不足——“能点开”不等于“能稳定完成任务”。同时，原生体验与优化逻辑围绕智谱云端 VLM 构建，切换到本地第三方模型后效果掉得比较明显，离线适配不如其他框架灵活。

适用场景：中文场景的自助任务、运营自动化、国内主流 APP 的流程自动操作。

3.4 MCP-Android：极简的“工具桥”（最容易混淆的定位）

MCP-Android 是最容易被误会的框架。它本质上不是完整 Agent，而是一组把 ADB 能力封装成 MCP 工具函数的适配器：截图、点击、滑动、输入、读取 logcat、安装 APK。

它的定位是工具层而非大脑层——任务拆解、判断下一步、失败重试全部交给上层的大模型（Claude、Cursor 等）来完成。这也意味着：

• 它没有任何内置的规划、闭环、校验逻辑；
• 但它最轻量、最可控、最不容易有“框架自带逻辑”带来的意外行为；
• 尤其适合你想完全自定义智能体逻辑的场景。

适用场景：自己编写 Agent 规划逻辑、在 IDE 编码助手中直接调用手机原子操作。

MCP-Android 接入 Cursor / Claude Code 实战：由于 MCP-Android 是纯 MCP 工具桥，接入 IDE 编码助手格外简单。以 Cursor 为例，只需在其 MCP 配置中声明：

{
  "mcpServers": {
    "android": {
      "command": "npx",
      "args": ["-y", "mcp-android"],
      "env": { "ANDROID_HOME": "/path/to/android-sdk" }
    }
  }
}

配置完成后，Cursor 里的 Agent 就能像调用普通函数一样调用手机能力：截图 → 看界面 → 决策点击 → 校验。规划、重试、闭环逻辑全部由 Cursor 内置的大模型负责，这正是 MCP-Android 定位“工具桥”的价值——它把最灵活的规划能力完整交还给了上层模型，让你完全掌控智能体的行为逻辑。

四、横向深度对比

维度	Google Artemis	Mobile-Use	AutoGLM Phone Agent	MCP-Android
维护方	Google 测试团队	Minitap	智谱 AI	社区开源（多实现）
定位	测试工程 Agent 框架	跨端通用手机 Agent	中文日常 GUI 助理	MCP 工具适配器（桥）
支持平台	仅 Android	Android + iOS	仅 Android	仅 Android
模型自由度	任意模型可切	自由替换 VLM	优先自研 VLM，适配弱	完全不限（模型即大脑）
MCP 原生	是	是	否	是（纯 MCP）
测试工程化	强（断言/报告/日志）	弱（需二次开发）	弱	无
国内 App 适配	一般	一般	强	依赖上层模型
冷门/自研 App	依赖通用模型	依赖通用模型	较弱	依赖上层模型
典型场景	回归测试/测试中台	双端轻量自动化	中文业务自动化	自定义 Agent 工具层

五、内网离线与数据安全：高安全环境如何选型

对于很多企业（尤其是涉密、内网隔离环境）来说，“能不能不走外网、数据不出本地”是选型的首要约束。这里有一个至关重要的认知：

框架能不能离线 ≠ 你配置对了就安全。

不管哪个框架，只要 base_url 填的是公网地址（Gemini / OpenAI / 智谱等），手机的截图、APP 界面文字、验证码、隐私信息都会被发送到远端大模型服务商。只有把 base_url 指向本机 Ollama（http://127.0.0.1:11434），才是真正意义上的本地闭环。

5.1 各框架的离线能力排序（前提：搭配本地 Ollama 多模态模型）

框架	离线适配	说明
MCP-Android	★★★★★	纯 ADB 工具桥，本身不带模型、无上报逻辑，最可控
Mobile-Use	★★★★☆	模型可插拔，默认指向本地 Ollama 即可纯内网闭环
Google Artemis	★★★☆☆	支持 Ollama，但原生默认偏 Gemini，需手动配置防外泄
AutoGLM Phone Agent	★★☆☆☆	深度绑定智谱云端，本地第三方模型适配差，难断外网

5.2 推荐本地多模态模型

适合 ADB 手机画面识别、对中文 UI 友好的本地模型：

• Qwen2.5-VL（7B/14B）：速度与效果均衡，对按钮、中文弹窗识别优秀。
• InternVL2-8B：稳定性强，适合小文字、深色 UI 界面。
• Llava 系列：资源占用更低，适合低配电脑。

5.3 ADB 本身的安全边界（容易被忽略）

无线调试一旦开启，同局域网内其他设备若拿到授权也能控制手机。高安全场景强烈建议只用 USB ADB，不要开启无线 ADB，进一步降低内网泄密风险。

六、手机端辅助工具对比：要不要在手机上装额外 App

这是另一个高频关注点。不同框架对手机端辅助安装物的依赖差异很大：

框架	是否有自研专属手机辅助 App	说明
Mobile-Use	❌ 无自研助手	默认用 uiautomator2 通用 atx-agent（开源生态自带，非 minitap 开发），可卸载
Google Artemis	✅ 有自研 Helper（可选）	Artemis Accessibility Helper，可通过配置关闭、走原生 uiautomator
AutoGLM Phone Agent	✅ 强制安装自研 APK	自研无障碍 APK 强依赖，不能去掉
MCP-Android	❌ 完全无	纯原生 ADB 指令，无任何手机端 APK

特别说明：Mobile-Use 首次连接时会通过 uiautomator2 自动向手机推送一个很小的 atx-agent 服务包（uiautomator-server.apk），这是 openatx/uiautomator2 生态的通用组件，不是 Mobile-Use 开发的。若介意，执行 python -m uiautomator2 uninstall 即可卸载。它没有任何需要手动在手机设置中开启的无障碍服务，对隔离内网真机更友好。

Artemis 若要完全不装自研 Helper，可在 .env 配置 ARTEMIS_HIERARCHY_BACKEND=uiautomator，切换到原生 UIAutomator 模式（缺点是与别的自动化框架有独占冲突）。

七、商用许可与合规：能不能拿来赚钱

对开源框架，商用能力是核心关切。逐个说明：

• Google Artemis：Apache-2.0 协议，允许商用、闭源集成、二次改造，只需保留版权声明与 LICENSE。
• Mobile-Use：Apache-2.0 协议，明确允许商用，可闭源集成进商业产品；分发时须保留版权声明、标注修改；附带专利授权（Minitap 不因你的使用与改造起诉专利侵权）。
• AutoGLM Phone Agent：需区分版本——智谱云端 API 版本在开发者协议中通常限制用于研究、测试、个人体验，不允许直接拿来做商业化产品集成；开源权重版本（AutoGLM-Phone-9B）可本地部署，许可证相对宽松，允许二次改造与商用集成。
• MCP-Android：社区开源，多为宽松协议，可直接商用集成。

合规提醒：商用风险不在框架本身，而在业务合规——不要用来自动化爬虫薅数据、绕过风控、恶意自动化；且很多手机 App 的用户协议明令禁止自动化操作，部署前务必评估目标 App 的平台规则与隐私合规。

八、选型建议：结合你的实际场景

场景 A：做 APP 自动化测试、回归、质量中台、对接 MCP 编码助手 → 首选 Google Artemis。它原生就是为测试场景设计的，日志、断言、校验闭环是其他框架不具备的；若需内网隔离，切本地 Ollama 模型即可。

场景 B：国内主流 App 的业务自动化、日常任务、中文场景 → 选 AutoGLM Phone Agent。微信/美团/12306 这类场景中文弹窗识别最优；但需接受其离线与冷门 App 短板。

场景 C：同时要安卓 + 苹果自动化、个人轻量玩法 → 选 Mobile-Use。一套代码两套设备，架构轻量，改造成本低。

场景 D：自己开发一套 Agent，只要一个 ADB MCP 工具层，规划逻辑自己写 → 选 MCP-Android。安全上限最高，无框架自带逻辑干扰。

场景 E（高安全内网）：要完整测试闭环 + 数据不出本地 → Google Artemis + 本地 Ollama 多模态模型（InternVL2 / Qwen2.5-VL），删掉所有外网 API Key，provider 指向本地。

九、实战演示：一句自然语言驱动一台真机

理论讲得再多，不如看一次真实的任务闭环。假设我们要让 Agent 完成“打开测试应用 → 登录 → 截图留存”这个最小可验证任务，在 Artemis 这类完整框架中，整个执行过程大致如下：

（1）下达任务 你只需用自然语言描述目标，例如：“打开名为 SampleApp 的测试应用，用账号 demo / 密码 test123 登录，成功后截图保存，并把结果写进测试报告。”

（2）Agent 自动规划 框架先生成一份带校验点的执行计划，把大目标拆解为可验证的小步骤：打开应用 → 等待首页加载 → 定位登录入口 → 输入账号 → 输入密码 → 点击登录 → 校验是否跳转成功 → 截图。

（3）逐步骤闭环执行 每一步都走“感知 → 推理 → 执行 → 反馈”：先截图/读控件树，模型判断当前状态与下一步坐标，框架下发 ADB 指令，再截图校验该步骤是否真正完成。某一步失败（例如弹窗遮挡、元素未加载），框架自动重试或调整策略，并在日志中留下完整痕迹。

（4）输出产物 任务结束后，框架自动汇总：每一步的截图快照、logcat 日志、操作时间线、断言结果，以及最终的可读测试报告。这些产物正是测试工程最需要的“可回溯证据”。

这一过程看起来简单，但背后是控件树优先、VLM 视觉兜底、失败重试、结果校验、日志留痕等多层工程能力的叠加——这也再次说明，稳定可靠的手机智能体，从来不只是“模型 + ADB”两个孤立组件的拼装。

十、落地实践：一个最小离线闭环的配置骨架

无论选哪个框架，本地离线闭环的配置思路是一致的。以 Artemis 对接 Ollama 为例，核心只需三步：

第一步：.env 只保留本地配置，删掉所有外网 Key

# 不填任何 Gemini / OpenAI / 智谱密钥
# 仅用于非 Ollama 场景时的兼容占位
OLLAMA_BASE_URL=http://127.0.0.1:11434

第二步：artemis.json 把 provider 指向本地 Ollama

{
  "default_model": "ollama/qwen2.5-vl:7b",
  "fallback_model": "ollama/qwen2.5-vl:7b",
  "providers": {
    "ollama": {
      "type": "openai",
      "base_url": "http://127.0.0.1:11434/v1"
    }
  }
}

第三步：确认手机端已开启 USB 调试，且 ADB 能识别设备

adb devices # 应能看到设备且状态为 device
uv run artemis helper install # Artemis 可选：预装辅助服务

只要确保 base_url 指向本机 127.0.0.1:11434，手机截图与界面数据就只在本机流转，实现真正意义上的本地闭环。

十一、选型决策树：三分钟锁定方案

如果不想逐一阅读上面的对比，可以直接按下面的决策路径快速收敛：

是否要求数据不出内网（涉密/隔离环境）？
├─ 是 → 还需要完整测试闭环？
│  ├─ 是 → Artemis + 本地 Ollama VL（强推，测试能力 + 离线可控）
│  └─ 否 → MCP-Android + Ollama（最可控，无框架自带逻辑）
├─ 否 → 需要同时控制安卓 + 苹果？
│  ├─ 是 → Mobile-Use（唯一双端开源方案）
│  └─ 否 → 主要操作国内主流 App？
│     ├─ 是 → AutoGLM Phone Agent（中文业务特长生）
│     └─ 否 → 要完整测试工程化？
│        ├─ 是 → Google Artemis
│        └─ 否 → MCP-Android（做工具层）/ Mobile-Use（做轻量闭环）

十二、常见问题 FAQ

Q1：大模型直接输出 ADB 命令就能完成任务吗？ 不能。裸模型容易坐标错位、无法理解页面状态、不会失败纠偏。稳定可靠必须依赖框架的 UI 定位、MCP 封装、失败重试与校验闭环。

Q2：这些框架需要手机 Root 吗？ 不需要。只需开启开发者选项中的 USB 调试（或无线调试），无需 Root。iOS 无 ADB，只能用 XCUITest/IDB 方案。

Q3：纯本地离线部署，需要哪些硬件？ 取决于本地模型的体量：Qwen2.5-VL-7B 建议至少 8G 显存；14B 建议 16G+；纯 CPU 推理会很慢，不适合生产。低配机器可退而求其次选 Llava-7B 或更小参数量模型。

Q4：本地模型识别手机中文界面效果会差吗？ 本地 Qwen2.5-VL、InternVL 对中文 UI 的识别已经相当不错，配合控件树路径（优先取 uiautomator 文本），大部分标准界面可以稳定完成。真正吃力的是纯视觉、无控件的 H5/游戏界面。

Q5：手机通知栏出现“Artemis test helper is running”是怎么回事？ 这是 Artemis 的可选辅助服务在运行，仅在本机 socket 读取 UI 树，不会主动外传数据。若不想安装，可在 .env 配置 ARTEMIS_HIERARCHY_BACKEND=uiautomator 关闭。

Q6：这些框架会违反 App 的用户协议吗？ 可能。很多 App 明令禁止自动化操作，强风控 App 甚至可能封号。用于测试自有应用或合规授权场景没问题；用于爬取数据、绕过风控则存在法律与封号风险，务必评估合规性。

Q7：无线 ADB 和 USB ADB 该如何选择？ 日常开发用无线调试更方便，但无线 ADB 一旦开启，同局域网内其他设备若拿到授权也能控制手机，存在被横向渗透的风险。涉密、内网隔离环境务必只用 USB ADB，且用完及时断开授权。

Q8：本地模型推理速度会不会很慢，导致任务超时？ 会。手机 Agent 是“多轮截图 → 多次推理”的循环，每一步都要调用模型，本地小模型（7B）单次推理约 1~3 秒，复杂任务累积下来耗时明显。生产环境建议 GPU 推理（至少 8G 显存起步），并合理设置每一步的超时与重试阈值，避免无限循环拖死任务。

Q9：如何评估一个手机 Agent 方案的成熟度？ 建议关注三个维度：一是闭环完整性（是否有失败重试与结果校验）；二是留痕能力（是否产出截图、日志、控件树快照等可回溯证据）；三是模型可替换性（是否被单一服务商锁定）。三者兼备的方案，才具备进入企业级生产环境的资格。

十三、企业落地最佳实践

最后，结合一线实践，给正在搭建移动端 AI 测试中台或自动化体系的团队几点建议：

1. 先在测试机上验证，再上真机池 开发阶段用模拟器或测试机跑通流程，减少真机损耗与风险；稳定后再扩展到真机集群。

2. 建立“配置即代码”的模型管理 把模型配置（Provider、default/fallback、base_url）纳入版本管理，环境变量与密钥走密钥管理系统，杜绝密钥进仓库。

3. 关注失败样本而非成功率 智能体的价值不只在于“跑通一次”，更在于失败时的留痕（截图、logcat、控件树快照）。优先建设失败样本库，反哺模型与提示词优化。

4. 分层封装，保持模型可替换 不要把某一家模型写死在业务代码里。通过 Provider 抽象层保持模型可替换，既规避服务商锁定，也能在不同安全等级的环境间迁移。

5. 合规先行 涉及外部 App 的自动化，先确认目标平台协议、隐私政策与所在地区的合规要求，再投入资源，避免做了“不能落地”的工程。

十四、总结与展望

移动端大模型驱动的 Agent 开源框架，正在从“玩具”走向“工程基座”。四款框架各擅其长：Artemis 把测试工程化做到极致，Mobile-Use 以跨端轻量见长，AutoGLM 深耕中文业务场景，MCP-Android 则提供最底层的可控性。

对工程团队而言，真正的决策不是“选哪个最好”，而是“我的场景需要哪一层能力”——是要完整的测试闭环，还是轻量的跨端工具，还是极致的离线可控。同时必须记住安全配置的决定性作用：离线不等于安全，配置决定边界。

这里还想强调一个经常被忽视的结论：手机 Agent 的工程价值，藏在“闭环”与“留痕”里，而不是藏在“模型有多聪明”里。一个能稳定跑完任务、失败时留下完整可回溯证据、且模型可随时替换的方案，远比一个“偶尔惊艳”却不可复现、不可审计的演示更有生产意义。这也是为什么成熟的团队会把重点放在框架的校验、日志、报告与模型抽象层上，而不是只盯着单次成功率。

随着本地多模态模型（Qwen2.5-VL、InternVL 等）的持续进步，以及 MCP 生态的日益成熟，我们有理由相信：不久的未来，驱动一台手机完成任务，将像今天写一条 SQL 一样自然。而这四款开源框架，正是通往那个未来的第一块跳板。

如果你正准备启动移动端 AI 自动化或测试中台建设，建议先拿本文的决策树锁定期望方案，再搭建一个最小的离线闭环跑通真实任务——用一次端到端的真实执行，胜过十次纸面上的参数对比。