# Mobile Use / Phone Use 手机自动化技术方案深度调研报告

> 调研日期：2026-10-26 ｜ 调研方式：全网公开信息（GitHub / 官方文档 / 论文 / 独立评测 / 新闻判例）交叉核对
> 范围：AI GUI Agent、传统自动化栈（无障碍/adb/测试框架）、Root/Hook/虚拟化、协议级方案、云手机/模拟器/群控、iOS 路线、商业 RPA 与官方合规通道
> 特别关注：微信等强风控超级 App 的适用性与合规风险

---

## 目录

1. [执行摘要（TL;DR）](#一执行摘要)
2. [术语与问题定义](#二术语与问题定义)
3. [技术路线全景图](#三技术路线全景图)
4. [路线 A：AI GUI Agent（多模态大模型 + 手机控制）](#四路线-aai-gui-agent)
5. [路线 B：传统确定性自动化栈](#五路线-b传统确定性自动化栈)
6. [路线 C：Root / Hook / 虚拟化框架](#六路线-croot--hook--虚拟化框架)
7. [路线 D：协议级方案（以微信自动化编年史为核心）](#七路线-d协议级方案微信自动化编年史)
8. [路线 E：云手机 / 模拟器 / 群控基础设施](#八路线-e云手机--模拟器--群控)
9. [路线 F：iOS 自动化](#九路线-fios-自动化)
10. [路线 G：官方合规通道](#十路线-g官方合规通道)
11. [微信专项：风控、封号规律与法律边界](#十一微信专项分析)
12. [横向对比矩阵与选型建议](#十二横向对比矩阵与选型建议)
13. [法律与合规综述](#十三法律与合规综述)
14. [参考资料](#十四参考资料)

---

## 一、执行摘要（TL;DR）

**本报告调研了 7 条技术路线、60+ 个开源/商业项目，所有关键事实（版本、维护状态、判例、数据）均经 2026-10-26 时点交叉核实。核心结论：**

1. **手机自动化 = 执行层 × 感知层 × 决策层 × 基础设施层的组合问题。** 执行层只有三种注入方式（adb/无障碍/驱动级事件），感知层三种（无障碍树/截图视觉/内存 Hook），差异在决策层（脚本 vs 大模型）和基础设施（真机/模拟器/云手机/容器）。
2. **"mobile use/phone use"（AI GUI Agent）是 2024-2026 最热方向但远未成熟**：AndroidWorld 榜首已到 ~87%，但独立 65 任务实测最高仅 43%（DroidRun），纯视觉方案（AppAgent 7%、单任务 $0.9/180s）已被证明是死胡同，读无障碍树的结构化方案胜出。**读树 + 推理模型 + adb 执行**是当前最优架构共识。
3. **传统栈（Appium 3.x/uiautomator2/Maestro/scrcpy 5.0）依然是工业级最稳底座**，且正在与 AI 合流（Maestro MCP、SoloPi Harness）。但系统层正在关门：Android 13-17 逐年收紧无障碍 API，**Play 2025-10 政策明确禁无障碍自动化上架**；**鸿蒙 NEXT 上 adb/安卓无障碍全家桶彻底失效**，必须换 hdc 栈。
4. **微信是所有路线的"最终 Boss"**：web 协议（2017）→ pad 协议（2021-22）→ PC hook（2025 微信 4.0 重写后全部失效）三连杀；8.0.52+ 连无障碍树都主动混淆；开发销售外挂已有**最高 10 年实刑**判例（最高法入库参考案例）、群控厂商被判赔最高 1000 万。**微信个人号自动化不存在合规路线，唯一合法通道是企业微信 API + 公众号/小程序。**
5. **基础设施层趋势是 ARM 原生化**：x86 模拟器检测率 95%+，redroid 必须跑在 ARM 板上才是稳态，商业云手机全面转向 ARM 真芯片；真机群控（含 315 曝光的主板机）法律风险最高。
6. **给不同读者的建议**：做自动化测试 → Maestro/Appium+uiautomator2；做个人 AI 助手 → GUI Agent（mobile-use/Open-AutoGLM）+ 真机 + adb，或 PC 端微信 + UI 自动化；做私域运营 → 企业微信 API（唯一答案）；做灰产 → 本报告不提供帮助，且判例表明此路不通。

---

## 十二、横向对比矩阵与选型建议

### 12.1 全路线总对比

| 维度 | A: AI GUI Agent | B: 传统栈 | C: Hook/虚拟化 | D: 协议级 | E: 云机/群控 | F: iOS | G: 官方通道 |
|---|---|---|---|---|---|---|---|
| 能力上限 | 中高（可泛化） | 高（确定性） | 极高 | 极高 | 叠加增益 | 中 | 中（限官方功能） |
| 成熟度 | 低-中 | **高** | 中（冻结中） | 低（死亡中） | 高 | 中 | **高** |
| 速度 | 慢（57-180s/任务） | 快（10ms-1s/操作） | 极快 | 极快 | 取决于上层 | 慢 | 快（API） |
| 微信可用性 | 勉强 | 勉强（节点混淆） | 高风险 | 历史可用现死 | 高风险 | 勉强 | **企微可用** |
| 封号风险 | 低-中 | 低-中 | 高 | 极高 | 高 | 低-中 | 无 |
| 法律风险 | 低 | 低 | **高（实刑）** | **极高（实刑）** | 中-高（判赔+曝光） | 低 | 无 |
| 维护成本 | 中（模型 API） | 低 | **极高（追版本）** | 极高 | 中 | 中 | 极低 |
| iOS 支持 | 仅模拟器 | WDA（困难） | 无 | 无 | 无 | 原生 | App Intents |

### 12.2 按场景选型

**场景 1：App 自动化测试（自有 App）**
→ Maestro（首选，抗 flaky + MCP）或 Appium 3.x + uiautomator2（生态最全）；游戏用 Airtest 图像识别 + Poco（需嵌 SDK）；鸿蒙 NEXT 用 @ohos.UiTest/hmdriver2；CI 真机池用 DeviceFarmer STF。无合规问题。

**场景 2：个人手机 AI 助手（自己的设备/账号）**
→ 开源 GUI Agent（minitap/mobile-use、Open-AutoGLM、Mobile-Agent v3/GUI-Owl、DroidRun）+ 真机 + adb；感知优先选无障碍树模式；操作微信等敏感 App 要接受封号风险并控制频率；不要碰 Hook/协议。中低端方案：AutoJs6/assists 写脚本 + LLM 决策。

**场景 3：微信生态业务运营**
→ **唯一答案：企业微信 API**（客户联系 + 群机器人 + 会话存档 RSA 双钥）+ 公众号/小程序接口。需要个人微信效果的场景，官方智能体平台（腾讯元器等）是正在打开的口子。

**场景 4：批量设备运维 / 云真机平台**
→ B 端合规：阿里云无影云手机（矩阵版）/华为云 CPH + STF；自建：ARM 服务器 + redroid（Android 8.1-16）+ scrcpy 5.0 串流，注意 SELinux/指纹/GMS 三大硬伤；海外：Genymotion on AWS。

**场景 5：安全研究**
→ Corellium（虚拟化天花板）+ Frida（Zygisk Gadget 注入对抗检测）+ 越狱 iOS（Dopamine ≤17.x）；注意国内对微信逆向的司法红线。

**场景 6：iOS**
→ 测试：XCUITest/Appium+WDA（接受签名与速度折磨）；合规自动化：App Intents + Foundation Models（依赖目标 App 开放）；批量控制：越狱+go-ios+WDA（灰产向，不推荐）。

### 12.3 技术趋势判断（2026 时点）

1. **AI Agent 与测试栈合流**：Maestro MCP、SoloPi Harness、scrcpy 虚拟显示都是为 GUI Agent 做的执行层准备；"读树 Agent"替代"截图 Agent"已成定局。
2. **系统层防御性收紧**：Android 13→17 对无障碍的连环封杀 + Play 政策，无障碍自动化 App 化分发已死，侧载/自用是唯一形态。
3. **平台收回自动化权**：微信自研智能体、Apple App Intents、Android App Functions——**官方正在把"AI 操作 App"变成平台能力**，第三方通用自动化空间被两头挤压。
4. **微信 Hook 生态处于历史最低谷**（4.0 未破 + LSPosed 归档 + 司法打击三重叠加），短期（1-2 年）看不到恢复。
5. **ARM 原生化**是基础设施层的单行道。

---

## 二、术语与问题定义

- **Mobile Use / Phone Use**：2024 年底随智谱 AutoGLM 发布而流行的术语，指 AI Agent 自主操作手机（感知屏幕 → 理解 → 执行点击/滑动/输入）完成自然语言任务的能力；对应 Anthropic 的 Computer Use 在手机上的延伸。
- **手机自动化的四个层次**（本报告的分析框架）：
  1. **执行层**：怎么把"点击(x,y)/滑动/输入文本"打到设备上 —— adb input、无障碍 performAction、minitouch/sendevent、注入事件；
  2. **感知层**：怎么知道屏幕上有什么 —— 无障碍树（accessibility tree）、截图+OCR/视觉模型、截屏+控件 dump（uiautomator dump）、内存/Hook 数据；
  3. **决策层**：怎么决定下一步 —— 确定性脚本（Appium/Maestro）、多模态大模型（GUI Agent）；
  4. **基础设施层**：跑在哪 —— 真机、模拟器、云手机、容器（redroid）、虚拟化（VirtualApp）。
- 所有方案都是这四层的不同组合；**微信这类强风控 App 的核心矛盾在"能力（感知+决策的深度）"与"隐蔽性/合规性"不可兼得**：感知越深（Hook/协议），能力越强、检测与法律风险越大。

---

## 三、技术路线全景图

| # | 路线 | 感知层 | 执行层 | 需 Root | 微信适用性 | 合规风险 |
|---|------|--------|--------|---------|-----------|---------|
| A | AI GUI Agent | 截图+VLM / 无障碍树 | adb input / 无障碍 | 否 | 可用但慢、贵、成功率有限 | 低-中（违反平台条款风险，无刑事风险） |
| B | 传统自动化（Appium/Maestro/无障碍/adb） | 无障碍树 / 控件 dump | 无障碍 / adb input | 否 | 可用（测试场景）；生产风控中危 | 低 |
| C | Root + Hook（Xposed/Frida）/ 虚拟化（VirtualApp） | 内存/Hook API | 任意 | 部分 | 能力最强；检测与封号风险最高 | 高（刑事判例存在） |
| D | 协议级（微信 Web/Pad/Windows hook 协议） | 协议消息 | HTTP/Socket | 否（Windows hook 免 root） | 历史主流黑产路线 | 极高（多起刑事判决） |
| E | 云手机/模拟器/群控 | 同上叠加 | 同上叠加 | 否 | 基础设施层，被风控重点识别 | 中-高 |
| F | iOS（WDA/XCUITest） | XCUITest 树 | WDA | 否（需证书） | 可用但极其受限 | 低-中 |
| G | 官方通道（企微 API/小程序/App Intents） | 官方 API | 官方 API | 否 | 唯一合规路线，仅覆盖 B 端场景 | 无 |

---

## 四、路线 A：AI GUI Agent

> 定位：用多模态大模型（VLM）看屏幕（截图和/或无障碍树），理解任务后自动规划并操作手机。这是 2024-2026 年最活跃的方向，"mobile use / phone use" 一词通常特指这条路线。

### 4.1 代表开源项目

#### 1) mobile-use（minitap-ai/mobile-use）
- **定位**："browser-use 的手机版"，开源 AI Agent 用自然语言控制手机；GitHub `minitap-ai/mobile-use`，约 **3.3k stars**，885 commits，活跃维护中；**Apache-2.0（附加署名条款：使用代码或借鉴架构需注明 Minitap, Inc.）**，配套论文 arXiv:2602.07787（多 Agent + 任务分解）。
- **技术架构**：Python（uv 管理），基于 **LangChain/LangGraph 多智能体编排**；提供 MCP server（docs.minitap.ai/v2/mcp-server）与 Docker 快速启动。
- **感知**：**UI-Aware Automation**——基于无障碍树导航，而非纯截图视觉；因此**游戏等无无障碍树的应用明确效果有限**。
- **执行**：Android 通过 **ADB**（USB 真机 + USB 调试，或 Android Studio 模拟器）。
- **iOS**：仅支持 **macOS + Xcode + fb-idb 的模拟器**，**不支持 iOS 真机**。
- **模型**：可插拔 LLM（OpenAI/Google Vertex/xAI/OpenRouter/MiniMax/Anthropic；推荐 claude-sonnet-4-6 或 MiniMax M2.7）。
- **已知坑（官方 README/文档自认）**：游戏无效（无无障碍树）；Docker 与设备需同 Wi-Fi 且要手动指定 `--interface`；防火墙可能阻断 5555 端口且无通用解法；ghcr.io 镜像拉取需先 `docker logout ghcr.io`。

#### 2) Mobile-Agent 系列 / GUI-Owl（阿里 X-PLUG）
- GitHub `X-PLUG/MobileAgent`，约 **9.3k stars**，**MIT**，活跃维护（动态更新至 2026 年）。
- **演进**：v1（ICLR 2024 Workshop，单 Agent 视觉感知）→ v2（NeurIPS 2024，多 Agent 协作）→ **v3（基于自研 GUI-Owl 基础模型的跨平台多智能体框架，具备规划、进度管理、反思、记忆）** → v3.5 / **GUI-Owl-1.5**（基于 Qwen3-VL 的原生 GUI 基础模型家族，2B–235B，含 Instruct/Thinking 双版本，在 20+ GUI 基准 SOTA，支持桌面/移动/浏览器、grounding、MCP 调用与长期记忆）。
- **部署形态**：可部署到阿里云无影云手机（云端 Android）或真机；模型权重在 HuggingFace/ModelScope 开放，API 走阿里云百炼。
- **中文 App 适配**：官方 demo 即为中文场景（携程/小红书/抖音/WPS），对中文 App 生态友好；微信无官方验证案例。
- **注意**：192 个 open issues，社区实际使用问题需查看 issue 区；OSWorld 桌面场景需要单独 RL 微调的 checkpoint，说明通用模型在特定平台仍需调优。

#### 3) DroidRun（droidrun）
- 开源框架，让 LLM Agent 以"人肉模仿"方式自动化 Android（现已宣称支持 iOS），多 LLM 供应商（OpenAI/Gemini/Anthropic）；通过 Android 无障碍 API 读取真实 UI 结构并执行操作，"the eyes and hands of the LLM"。
- 2025 年 4 月 Hacker News 发布帖（news.ycombinator.com/item?id=43703688）有社区对可靠性的质疑讨论。

#### 4) AutoGLM / Open-AutoGLM（智谱 Zhipu AI / Z.ai）
- **时间线**：
  - 2024-10：第一代 **AutoGLM**，业内公认首个能在真机稳定完成完整操作链路的 Phone Use Agent（论文 arXiv:2411.00820：AndroidLab 36.2%，常用中文 App 任务 89.7%，Web 55.2%）；
  - 2025-08：**AutoGLM 2.0**，由 GLM-4.5/GLM-4.5V 驱动，配备专属云手机/云电脑，可 24 小时后台运行（"平行手机"概念），验证 RL scaling laws（MobileRL/ComputerRL 训练方案）；
  - 2025-12：**开源 Open-AutoGLM / Phone Agent 框架**（GitHub `zai-org/Open-AutoGLM`，支持 Android 7.0+ 与鸿蒙设备，ADB 控制），并开放 AutoGLM-Phone API（bigmodel.cn / Z.ai）。
- **开源 SOTA**：THUDM/**MobileRL-9B** 在 AndroidWorld 达 **80.2%**、AndroidLab 53.6%（GitHub `THUDM/MobileRL`）。

#### 5) AppAgent（腾讯，2023）
- 探索式学习（人工演示/自主探索构建 App 知识库）+ 部署执行的纯视觉方案；论文影响大，但独立实测表现差（见 4.2）。

#### 6) AutoDroid（学术，MobiCom'24）
- LLM + 无障碍树的学术先驱（DroidAgent），成本低但任务完成能力有限。

#### 7) 其他值得关注的
- **MobileUse**（GitHub topic: mobile-agent 下的同名项目，分层反思 + 主动探索，面向 AndroidWorld/AndroidLab 评测）；
- **OS-Atlas / OS-Genesis / UGround**：GUI grounding（截图→坐标）基础模型系列，是纯视觉方案的核心组件；grounding 精度是纯视觉路线的主要瓶颈；
- **手机厂商内置 Agent（2025-2026）**：Google Gemini Intelligence 跨应用任务执行（Project Mariner 落地 Android）、三星 Galaxy S26 三助手（Bixby/Gemini/Perplexity）、传音 Tecno EllaClaw、AGI Inc × Qualcomm 端侧 Agent、荣耀 YOYO/华为小艺等——趋势是**厂商自己把 Agent 做进系统层**，第三方 App 的边界仍在博弈中。

### 4.2 实测成功率与坑（重要）

**独立评测（AIMultiple，2026）**：基于 Google AndroidWorld 框架（Pixel 6 模拟器 / Android 13），统一 Claude 4.5 Sonnet，65 个真实任务：

| Agent | 成功率 | 单任务成本 | Tokens | 单任务耗时 |
|---|---|---|---|---|
| DroidRun | **43%** | $0.075 | ~3,225 | 78s |
| Mobile-Agent (M3A) | 29% | $0.025 | ~1,130 | 66s |
| AutoDroid | 14% | $0.017 | ~765 | 57s |
| AppAgent（纯视觉） | **7%** | $0.90 | ~2,346 | 180s |

**结论性教训**：
1. **纯截图视觉方案是当前最大瓶颈**：坐标计算与 UI 元素识别不准（AppAgent 成本 12 倍、成功率垫底）；读无障碍树的结构化方案（DroidRun）显著更稳。
2. **榜单成绩 ≠ 真实成功率**：AndroidWorld 榜首模型已达 ~87%（2026，Qwen3.8-Omni-Flash 87.1%，开源 MobileRL-9B 80.2%，D-Artemis 75.8%），但独立 65 任务实测最高仅 43%——存在榜单过拟合与模拟器-真机落差。
3. **成本与延迟**：单任务 $0.017–$0.9、57–180 秒，无法支撑高频批量场景。
4. **无障碍树依赖的连锁坑**：Flutter/自绘引擎/游戏无树（直接失效）；中文超级 App 弹窗、广告、权限对话框频繁打断任务链。
5. **隐私与安全新坑**：屏幕内容整屏发第三方模型（隐私泄露）、界面提示注入（prompt injection）攻击开始被正视（AIMultiple 特别提示）。
6. **iOS 基本不可用**：主流框架 iOS 仅支持模拟器或不支持；真机需 WDA 且证书问题繁琐（见路线 F）。
7. **微信适用性**：无任何框架官方验证过微信场景；微信对异常操作模式（匀速滑动、无停顿点击、后台运行时序）有行为风控，Agent 直接裸跑存在封号风险；登录（短信验证、好友验证）无法全自动。

---

## 五、路线 B：传统确定性自动化栈

> 定位：确定性脚本/测试框架，工业界最成熟的路线。**所有"能读到 UI 树"的方案（无障碍/UiAutomator/Appium）本质都依赖同一个底层：Android 无障碍框架的 `AccessibilityNodeInfo`。** 以下维护状态均经 GitHub API/版本时间戳核实（截至 2026-10-26）。

### 5.1 子路线全景

| 子路线 | 控制原理 | 需 Root | 跨应用 | 速度 | 代表 |
|---|---|---|---|---|---|
| 无障碍服务 | 节点树 + performAction | 否 | 是 | 中 | Auto.js 系、assists、Tasker |
| Instrumentation | 进程内/系统测试 API | 否 | 部分 | 快 | UiAutomator2、Espresso |
| 测试中间件 | Instrumentation 封装 + WebDriver 协议 | 否 | 是 | 慢 | Appium、Maestro |
| adb 直控 | input/sendevent/截屏推流 | 部分 | 是（黑盒） | input 慢/sendevent 快 | scrcpy、minitouch |
| 真机农场 | adb 直控 + 设备调度 | — | — | — | STF、atxserver2、WeTest |

### 5.2 无障碍服务（AccessibilityService）

- **原理**：App 注册服务后系统推送 `AccessibilityNodeInfo` 快照树（viewId/text/bounds/className），程序按选择器找节点调 `performAction()` 或 `dispatchGesture()`；免 root、跨 App、可操作系统界面。
- **系统限制收紧时间线（每个都是历史大坑）**：
  - Android 9（2018）：封锁非 SDK（hidden API）接口；
  - Android 10（2019）：SELinux 禁止第三方进程向 `/dev/input/eventX` 注入触摸（**minitouch 之死**）；
  - Android 13（2022）**Restricted Settings**：侧载 App 默认禁止开无障碍，需手动"允许受限设置"；
  - Android 14（2023）：**App 自更新后系统自动禁用其无障碍权限**（无人值守场景致命）；
  - Android 15/16（2024-2025）：继续收紧；Android 16 新增 `AccessibilityDataSensitive`——App 可把敏感视图标记为只对"可信无障碍工具"可见；
  - **Android 17 Beta（2026-03）：高级保护模式（APM）下系统级封杀非辅助类 App 使用无障碍 API**；
  - **Google Play 政策（2025-10-30 更新）**：严禁利用无障碍 API 让应用自主发起/规划/执行操作——**自动化类 App 无法上架 Play，只能侧载/企业分发**。
- **代表项目**：
  - **Auto.js 家族**：原版 hyb1996 2020 停更；活跃分支 **AutoJs6**（v6.7.0，2026-03，6.5k stars）、AutoX；OpenAutoJS 事实停滞；Auto.js Pro 为原作者付费闭源版；
  - **assists**（Kotlin 无障碍框架，v3.5.5，2026-08，活跃）；
  - **商业云控**：Hamibot（AutoJS 系 SaaS：脚本市场+云端控制台）、按键精灵手机版、EasyClick（图色/HID 模式，宣称支持鸿蒙 NEXT 真机）。
- **坑**：节点树异步推送延迟；Android 13+ 激活流程复杂且更新即失权；ROM 杀后台；**微信 8.0.52+ 无障碍节点混淆（见 5.7，微信专项最大坑）**。

### 5.3 Google 官方栈：UiAutomator / Espresso

- **Espresso**：白盒、同进程、快而稳，但**只能在单 App 内**（碰不了系统弹窗/其他 App）。
- **UiAutomator2**：黑盒、经无障碍层取树、**天然跨应用**（系统弹窗/通知/设置都能操作），比 Espresso 慢。
- 社区标准实践：App 内用 Espresso，跨应用环节交 UiAutomator2。
- 坑：需构建/签名 instrumentation 环境；`uiautomator dump` 在部分 ROM 拿不到 WebView 内容；watcher 机制弱。

### 5.4 Appium 生态（活跃，已进 3.x 时代）

- **架构**：Appium server（Node.js）+ 插件式 driver；Android 黑盒 = uiautomator2-driver + 设备端 netty server（经 adb forward 暴露 HTTP）；iOS = xcuitest-driver（底层 WDA）。
- **版本现状（已核实）**：Appium **3.0.0（2025-08-18）**，当前稳定 **3.8.0（2026-09-24）**，4.0-beta 测试中；3.x 仅保留 W3C WebDriver 协议。uiautomator2-driver v8.7.0、xcuitest-driver v12.20.0 均**密集维护**。
- **长期痛点**：慢（多层转发，大页面 `getPageSource` 可达 1MB+）；flaky（XPath 滥用、等待策略混乱、弹窗是首因）；环境矩阵复杂（JDK/SDK/Node/驱动版本）。
- **Python 直连替代**：openatx/**uiautomator2**（v3.7.1，2026-10-23，8.4k stars，非常活跃；`d(text="登录").click()` 一行上手），配套 facebook-wda（iOS）、adbutils。

### 5.5 Maestro（mobile.dev）

- YAML flow + 单二进制 CLI，**内建抗 flaky**（自动等待、未命中重试、selector 容错）；CLI 2.11.0（2026-09），16.2k stars，非常活跃；**已内置 MCP server（`maestro mcp`）供 AI Agent 调用**——传统测试栈与 AI Agent 路线正在合流。
- 局限：YAML 表达力弱于代码框架；多设备协同需 workaround；iOS 真机支持有限。

### 5.6 adb 层直接控制（执行层"底座"）

| 工具 | 速度 | 现状 |
|---|---|---|
| `adb shell input tap/swipe` | ~0.5–1s/次（每次起 JVM 进程） | 兼容性最好，慢是原罪 |
| `sendevent`/`getevent` | 10–50ms（拼批后） | 机型协议碎片化；Android 10+ SELinux 部分限制 |
| **minitouch** | 曾为 STF 核心 | **已死**：Android 10 起失效（官方 issue #49 确认），仓库 2020 年停更 |
| **minicap** | 曾为截屏流标准 | **事实停滞**：Android 10+ 失效 |
| **scrcpy** | 实时 | **当前事实标准**：设备端 jar + MediaCodec 编码视频流回传、控制指令经 adb 注入（免 root）。版本线：3.0（2024-11，虚拟显示）→ 4.0（2026-07）→ **5.0（2026-10，桌面硬件解码）**。可用于"投屏取流+注入控制"，其 `--new-display` 虚拟显示可做"第二屏自动化不占前台"；社区已有基于 scrcpy 改造 STF 的方案 |

### 5.7 国产 App / 国产 ROM 特殊性（工程上最"脏"的部分）

**微信专项大坑——无障碍节点混淆（2026 年确认）**：
- **微信 8.0.52+ 在生成无障碍节点时主动混淆**：把其他节点的 viewId/text/description 随机填入当前节点，导致按 id/text 的选择器全面失效——这是微信对无障碍自动化路线的直接反制。
- 已知对策：① 开启系统"随选朗读"可强制微信渲染真实语义节点（影刀社区方案）；② 改用 bounds/坐标/父子关系匹配（知乎/博客园有原理分析）。

**自绘引擎问题**：Flutter 不用原生 View，未暴露 Semantics 树时无障碍只能看到一个整体节点；Unity/Cocos 游戏同理（只能嵌 Poco SDK 或退回图像/坐标）；抖音系大量自绘+动态化，控件 id 不稳定。

**ROM 层**：
- MIUI/HyperOS：「USB 调试（安全设置））需登录小米账号，adb install 弹确认框；
- ColorOS：侧载/更新后无障碍开关需重走"允许受限设置"；
- **鸿蒙 HarmonyOS NEXT（重大变化）**：不兼容 Android，**adb 完全不可用**，替代是 **hdc**；安卓无障碍 API、uiautomator2、Appium(Android) **全部失效**。替代栈：`@ohos.UiTest`/hypium（官方）、**hmdriver2**（"uiautomator2 的鸿蒙版"，活跃）、SoloPi 的 solopi-harmony 分支。**鸿蒙 NEXT 上"安卓自动化全家桶"整体失效，必须换栈。**

### 5.8 设备农场 / 真机云管理

- **DeviceFarmer STF**（原 openstf）：**"STF 已死"是过时说法**——DeviceFarmer 接力后 **v3.8.0（2026-09-23）** 仍在发版，CI 覆盖 Android 5.0–16；新机型依赖预编译二进制需自行维护。
- **Sonic（SonicCloudOrg）**：**2025-05-26 整个组织归档（已死）**，作者自述因代码被无授权商用、维护者被骚扰；可 fork 自维护。
- **openatx atxserver2**：半活跃（2026-06 仍有 push），iOS provider 停在 2023。
- **商业**：BrowserStack App Live（3.5 万+真机）、Sauce Labs、Firebase Test Lab（按分钟计费最便宜）；国内腾讯 WeTest/优测持续运营（鸿蒙覆盖较好）、阿里 MQC 据传将停服（待核实）、Testin 转型。
- **并发坑**：adb server 是并发瓶颈（多设备需分 host）；iOS 需 WDA 实例池。

### 5.9 中国系框架现状

- **网易 Airtest**：OpenCV 图像识别 + adb 控制链；**仍在低频维护（v1.4.3，2025-12）**，"2024 停更"说法过时；**Poco（UI 树框架）已停滞约两年**。适合游戏测试（需嵌 SDK）。
- **蚂蚁 SoloPi**：录制回放 + 性能测试 + 一机多控；**非但没死还在活跃（v1.0.3，2026-10-21），2026-10 还发布了面向移动 GUI Agent 的"SoloPi Harness"和鸿蒙分支**——大厂开始为 GUI Agent 做执行层安全。
- **商业 RPA 手机能力**：**影刀 RPA** 手机自动化 = ADB 直连 + 多机群控（场景包括微信发消息、打卡、养号类）；**UiPath** Mobile Automation = 本地 Appium 实例；来也科技手机端主打"机器人监控"（微信小程序）。EasyClick 走免 root 图色/HID，主打群控与"鸿蒙 Next 真机自动化"。

---

## 六、路线 C：Root / Hook / 虚拟化框架

> 定位：感知层从"看屏幕"深入到"读内存/改函数"，能力最强（能拿到消息明文、绕过 UI 直接调内部函数），但检测与法律风险最高。**Hook 微信在国内外均有刑事判例，属本报告中风险最高的路线。**

### 6.1 Root 生态现状（2026）

| 组件 | 现状 | 说明 |
|---|---|---|
| Magisk | 仍是主力方案 | 搭配 Zygisk + DenyList；社区有多个 fork（Magisk Delta/Kitsune 等）活跃 |
| KernelSU / KernelSU-next | 活跃 | 内核级 root，常搭配 SUSUFS（内核级隐藏） |
| APatch（fork: Folkpatch） | 活跃 | 2026 年配置灵活度最高的方案之一 |
| ZygiskNext | **已归档** | 后继由 Zygisk Assistant 等承担 |
| Play Integrity 对抗 | 攻防持续 | 事实标准组合：osm0sis/**PlayIntegrityFork** + Shamiko/Zygisk Assistant/NoHello；银行类 App 甚至能检测到 ZygiskNext 模块本身 |
| LSPosed（Xposed 系） | **2024-01-10 官宣停止维护，仓库归档** | 支持范围定格在 **Android 8.1–14**；Android 15 仅有内部版（DP1）不再公开；作者因遭受恶意攻击而停更；LSPatch（免 root）2023-12 归档，太极/两仪同步停更 —— **整个 Xposed 模块生态在 2024-2025 明显萎缩，Android 15+ 无官方稳定 Xposed 方案** |

**关键教训**：想在 Android 15/16 新机上走 Xposed 模块路线，2026 年已基本无稳定开源框架可用；继续使用 LSPosed 意味着停留在 Android ≤14 的旧设备/旧 ROM 上——这正是微信 Hook 类方案当前的普遍生存状态（锁定旧版微信 + 旧版系统）。

### 6.2 动态插桩：Frida

- **形态**：① frida-server（需 root，ptrace 注入 zygote/目标进程）；② frida-gadget（免 root，把 gadget 打进重打包 APK 或经 Zygisk 模块注入）。
- **2026 对抗趋势**：检测方用多信号引擎（如开源 [taisuii/sentry](https://github.com/taisuii/sentry)：扫 /proc/maps、特征端口 27042、线程名 gum-js-loop、Magisk 路径、Xposed 模块痕迹）；绕过方从 frida-server 转向 **Zygisk 注入 Frida Gadget**（看雪 FridaManager 类方案、绕过 DexProtector 加固检测的实践 2025-12 仍有更新）。
- **微信上的现实**：微信自带加固与完整性检测（含 Xposed/Frida/多开/模拟器检测）；Frida 方案主要用于**安全研究**（看雪对微信 4.0 三端 hook 的研究帖），**长期驻留的量产方案极少敢用纯 Frida**（稳定性 + 检测 + 封号三重压力）。

### 6.3 App 虚拟化/容器：VirtualApp 系

- **原理**：用户态虚拟化引擎——宿主容器进程内 Hook 系统接口（虚拟 AMS/Binder 代理），让插件 APK 以为自己在独立系统中运行；实现免 root 多开/双开。
- **现状**：开源版功能受限且更新缓慢（支持到 Android 14 的商业版需**付费授权**，作者 asLody 商业化运营）；基于 VA 的 **VirtualXposed** 早已停更（不支持 x86/模拟器、不能 Hook 系统 API、资源 Hook 缺失）。
- **检测与封号**：微信有成熟的多开检测（多用户 id、虚拟路径 /data/data/\<宿主\>/、mount 与 maps 特征、包名不一致等）；社区共识"多开容易封号"。2017 年微信官方公告明确打击"多开"与"外挂"。
- **司法风险**：此类"免 root 虚拟框架 + 微信"的组合正是多起刑事判决中"专门用于侵入、非法控制计算机信息系统的程序"的认定对象（详见第十三节）。

### 6.4 本路线坑汇总

1. **版本锁定死结**：微信 4.0 重写架构后，WeChatFerry/wxhelper 等全部停留在 3.9.x；Hook 方案要求"旧版微信 + 关自动更新 + 常被要求旧版系统/已归档的 Xposed 框架"——技术栈整体冻结在 2023-2024。
2. **检测面最大的路线**：root 特征、注入痕迹、虚拟环境特征、行为时序（消息发送频率、设备指纹漂移）四个维度同时暴露。
3. **维护成本极高**：微信每次小版本更新都可能导致偏移地址失效（社区项目以周为单位打补丁）。
4. **刑事红线**：开发、销售、甚至规模化使用均有实刑判例（见第十三节）。

---

## 七、路线 D：协议级方案（微信自动化编年史）

> 定位：不操作 UI，直接实现/伪造微信客户端协议（Web/Pad/Windows hook）与服务器通信。曾是"微信机器人"的主流形态，也是腾讯风控与司法打击的核心目标。

### 7.1 编年史（全部经来源核实）

| 时间 | 事件 | 影响 |
|---|---|---|
| ~2014-2017 | **itchat**（web 协议）盛行，衍生 wxpy 等生态 | 个人号机器人黄金期 |
| **2017-06** | 微信封堵 Web 协议：新注册账号大概率无法登录 Web 微信（Wechaty FAQ 官方记载） | web 协议路线死亡；itchat 仅对 2017 前老号部分可用 |
| 2017 | 微信官方公告打击"多开"与"外挂"，多开/营销号开始大规模封号 | 虚拟化路线风险公开化 |
| 2018-2021 | **Pad/iPad 协议**黑灰产平台化（Wechaty 生态 PadLocal/PadPlus 等付费 token puppet 成为主流） | 功能全面（加群、发圈、收发消息），但 token 费用高、来源灰色 |
| 2019-2021 | 腾讯多波封号潮（营销号/群控号百万级）；2021 年起对 pad 协议平台专项打击，多个卖协议平台被查 | pad 协议进入"随时暴毙"状态 |
| 2021-2022 | **ComWeChatRobot**（Windows 注入）流行后随微信更新失效；微信外挂"海贼王"案主犯获刑 10 年（广州南沙法院，2021 判决） | Windows hook 路线进入公众与司法视野 |
| 2022-2025 | **WeChatFerry（wcferry，lich0821）**：Windows DLL 注入 + RPC（Rust/Python SDK），适配到微信 3.9.12.17，可接 LLM 做 ChatGPT/DeepSeek 机器人；**wxhelper（ttttupup）** 支持 3.8.0.41–3.9.2.26 等 | 3.9.x 时代事实标准；仅供研究声明；**均不支持 Mac、不支持微信 4.0** |
| 2025-03 起 | **微信 4.0**（Windows/Mac/Android 多端统一架构重写）推送 4.0.3/4.0.5… | **全部主流开源 hook 项目未跟进**；仅看雪等论坛有研究性 Frida 脚本（《微信 4.0 hook——三端可行方案》2025 底），无生产级开源框架 |
| 2025-2026 | Wechaty 生态 PadLocal token 申请入口不稳定（issue #389）；社区持续迁移 | pad 协议供给端萎缩 |

### 7.2 各协议形态对比

| 形态 | 原理 | 现状 | 封号/法律风险 |
|---|---|---|---|
| Web 协议（itchat/wxpy） | 模拟 web.wechat 接口 | 2017 后新号不可用，实质死亡 | 低（已死） |
| Pad/iPad 协议（PadLocal 等） | 逆向 iPad 客户端私有协议 | 灰产供给、2021 后屡遭打击、入口不稳定 | **极高**（开发者有刑案） |
| Windows hook（wcferry/wxhelper/ComWeChatRobot） | DLL 注入 PC 微信读内存/调内部函数 | 卡死在 3.9.x；4.0 未适配 | 高（开发销售有判例；自用封号） |
| Mac hook | —— | 基本无公开成熟方案 | —— |

### 7.3 本路线核心结论

1. **"微信机器人"开源生态的实质是逆向军备竞赛**：每一代方案（web→pad→PC hook）都经历"出现→流行→腾讯打击（封号+司法）→死亡"的周期，平均寿命 2-3 年。
2. **2026 年的现状是历史最低谷**：微信 4.0 架构重写 + 旧框架（LSPosed）归档 + pad 协议打击三重叠加，没有一条生产级开源路线存活。
3. **该路线不存在"安全的使用方式"**：即使只做"自动回复"这类轻量需求，也直接违反《微信软件许可及服务协议》，规模化使用有刑事风险（第十三节判例）。

---

## 八、路线 E：云手机 / 模拟器 / 群控基础设施

> 定位：手机自动化的"基础设施层"——替代真机的运行载体 + 批量控制。四条子路线的本质差异：**执行架构（ARM 原生 vs x86 翻译）、指纹真实性（真硬件 vs 伪造）、成本结构（CAPEX vs OPEX）**。

### 8.1 开源容器化安卓

**redroid（remote-android）——自建云手机事实标准**
- **原理**：Docker/podman/k8s 容器内跑完整 Android（共享宿主内核，binder IPC），不做硬件仿真；单机高密度多开，配 scrcpy/串流交付。Apache-2.0。官方镜像覆盖 **Android 8.1–16**。
- **关键坑**：
  - 需内核 `binder_linux` 模块（内核 4.14+；Ubuntu 装 `linux-modules-extra`）——**容器秒退九成是缺内核模块**；
  - x86 宿主跑 ARM App 靠 libhoudini/libndk_translation/QEMU 翻译：性能约原生 70%、兼容性碰运气（Android 13 装 libhoudini 失败 issue #685；Unity 引擎 App 闪退）——**ARM 宿主才是稳态**；
  - 默认无 GMS、过不了 Play Integrity（需容器内 Magisk+PIF 伪造指纹，成功率随 Google 收紧波动）；
  - **SELinux 默认 permissive + 指纹库雷同 = 风控识别重灾区**；
  - 切勿公网暴露 5555 adb 端口（安全）。
- **低成本自建**：斐讯 N1（二手 50-100 元）/树莓派/RK3588 阵列 + Docker redroid，单实例硬件成本可压到百元级；RK3588 一板 8-12 实例。坑：树莓派内核缺 binder 要自编译、GPU 直通配置繁琐。

**其他**：
- **Waydroid**：LXC 容器 + LineageOS，桌面 Linux 体验最佳，但**系统镜像停在 Android 13**、AMD GPU 有 bug——极客玩具，非农场方案。
- **Anbox**：2023-02 官方弃用；商业版 Anbox Cloud（Canonical）存活，企业订阅制（1.30 起支持 LXD 内跑 Cuttlefish 全虚拟化）。
- **Cuttlefish**：Google 官方 AOSP 虚拟设备（crosvm 虚机、独立内核、行为贴近 Pixel）——"最正统"但无消费级产品化，需自建。
- **AVD 模拟器**：API 35 起双向 ABI 翻译更可靠，NEON/SIMD 翻译性能差是通病；趋势是 ARM 宿主直跑 ARM 镜像（Genymotion 2025 推 ARM64 设备）。

### 8.2 国内商业云手机

共同架构：ARM 服务器（鲲鹏裸金属/RK3588 阵列）+ 容器/虚拟化多开 + 串流交付。

| 产品 | 形态 | 价格（月） | 备注 |
|---|---|---|---|
| 红手指 | ARM 云 + SaaS 群控 | ~35 元起 | 横评测：多开账号**共用部分底层设备标识，批量养号有关联封号风险** |
| 雷电云手机 | 雷电同门，安卓 7.1–14/鸿蒙 | ~27 元（8核8G） | 批量同屏群控为高阶付费功能 |
| 多多云 | 宣传 ARM 真机 + AI 行为模拟 | 16-59.9 元 | "AI 行为模拟封号率低 80%"为厂商宣传，不可信 |
| 河马云手机 | ARM + 真机芯片，网页端群控 | 按天/月 | 千台级批量控制、Root/Xposed/ADB/RPA、**虚拟传感器/虚拟相机（专为过风控）** |
| VMOS | 手机内本地虚拟机 App + 海外云手机 | 云手机 $13-15/月 | 官方自认：云手机环境异常操作易触发微信风控 |
| 阿里云无影云手机 | ARM + 神龙虚拟化 | 实例 65-140 元；**矩阵版（群控）约 8000 元/月** | 大厂 B 端，合规路线 |
| 华为云 CPH | 鲲鹏 ARM 裸金属 + 容器 | 仅包年包月 | 同上 |

**客群**：游戏挂机工作室、跨境电商多账号、短视频矩阵、CPA 推广。**低价档掉线/卡顿/隐形收费是普遍吐槽**。"封号率 X%"类数字均出自厂商软文，无独立验证。

### 8.3 海外云手机 / 虚拟化

- **Genymotion SaaS**：$0.06/分钟/设备（≈$3.6/时），BYOC $0.60/时/实例；Genymotion on AWS（Graviton ARM）活跃。
- **AWS Device Farm**（**未废弃**，2025-11 还新增 Managed Appium Endpoint）：真实设备云，$0.17/设备分钟或 $250/月/槽。
- **Corellium**：iOS+Android CPU 级全系统虚拟化（安全研究向），~$3/设备小时，企业入门 ~$9,995/年——虚拟化天花板，与群控无关。
- 防关联生态：GeeLark（$39.90/并发/月）、FoxPhone（$12.90/设备/月）等主打 TikTok 多账号矩阵。

### 8.4 模拟器

- 原理：VirtualBox/QEMU + Android-x86，ARM App 靠 NativeBridge 动态翻译（libhoudini/libndk，Intel 专利）——这是模拟器跑 ARM 应用掉帧的根源。
- 代表：MuMu（网易，安卓 15/12 双内核，MuMu Pro 适配 Windows on ARM）、雷电（工作室渗透率最高，多开器+改机工具链）、BlueStacks 5（海外主流）、夜神（引擎老旧，弱势）。
- **检测**：模拟器是**最易识别**的形态——Group-IB 估计检测率 95%+（x86 CPU、虚拟 GPU 字符串、传感器缺失、触控时序异常）。腾讯/网易反作弊普遍"静默标记、择期封号"；部分游戏/应用直接禁模拟器登录。**微信对模拟器登录同样风控降权。**

### 8.5 群控系统

- **USB 真机群控**：一台 PC + Hub 拖 ~100 台真机（USB 单控制器 127 口上限），scrcpy/QtScrcpy 批量投屏 + adb 注入；农场管理用 STF/SoloPi（一机多控）。
- **主板机（机箱农场）**：去屏去电池的手机主板 20 块/箱集中供电——**2024 年央视 315 晚会首个案例曝光**（定性网络水军黑灰产工具）。优点：真实物理指纹；缺点：农场"聚集性"可被平台图分析识别。
- **云控 SaaS**：云手机厂商网页端千台级批量开关机/装包/同步操作/RPA 脚本/IP 池切换。
- **微信群控封号史（时间线，主流媒体报道）**：
  - 2017-03：微信大规模封杀群控产业链（"通路云"等，一台电脑控百机营销）；
  - 2017-12：大规模封禁"双开/多开"普通用户；
  - 2019-07：官方确认**当年已打击上百万**使用外挂（多开/群控）账号；
  - 2020-05：WeTool（社群运营工具）遭封禁；2020-06：群控软件"聚客通"开发商被判赔腾讯 260 万元；
  - 2024-03：微信公告对自动抢红包/一键群发/多开阶梯处罚。
- **AI 化新形态（2024-2026）**：LLM 接进云手机/工作手机做 AI 养号（自动朋友圈文案、AI 回复、智能外呼）；多多云等把"AI 行为拟人化"当防封卖点（宣传口径）。**合规化对冲**：企业微信 + 腾讯元器等官方智能体平台成为"白名单"替代；微信 2026 年被曝自研 AI 智能体打通小程序——**平台正把自动化能力收回官方手里**。

### 8.6 检测对抗与成本

**风控检测信号**（Group-IB 2026 报告等）：系统指纹（ro.kernel.qemu、SELinux 状态）→ 硬件一致性（ARM 机型 x86 CPU、GL Renderer、传感器/电池）→ 硬件认证（Play Integrity 三档）→ 网络（数据中心 IP、IP 与时区不一致）→ **图分析（设备批次/IP 段/行为模板的关联性，对群控杀伤最大）**。云手机厂商的反制：ARM 真芯片 + 独立持久指纹 + 虚拟传感器/相机 + 住宅 IP。Group-IB 评估云手机是当前**最难检测**的形态，但检测仍在升级。

**100 实例规模成本对比**：

| 路线 | 一次性 | 月成本 | 指纹真实性 |
|---|---|---|---|
| 真机 USB 群控 | 5-10 万（二手机+Hub） | 电费+人力（最大项） | 最高 |
| 本地模拟器 | 4-8 万（4-6 台高配 PC） | 电费 | 最差（95%+ 识别） |
| 自建 redroid（ARM 板） | 1-1.5 万（RK3588 阵列） | 极低电费 + **全 DIY 人力** | 中 |
| 国内云手机 | ≈0 | **1500-3000 元** | 中高 |
| 海外云手机 | ≈0 | $1000-3000 + 住宅代理 | 中高 |
| 大厂 B 端（阿里矩阵版） | 0 | ~8000 元 | 高（合规） |

**结论**：灰色场景的真实成本大头是 **IP 资源 + 封号损耗 + 人力**，不是硬件；技术趋势是 ARM 原生对 x86 翻译的全面替代；法律边界上群控已从"平台封号"升级到"司法判赔 + 315 曝光"。

---

## 九、路线 F：iOS 自动化

> 结论先行：**iOS 是"操作 UI"路线的困难模式、"Hook/协议"路线的禁区**。所有方案都绕不开苹果的签名与沙箱管控，2026 年的可行面比 Android 窄一个数量级。

### 9.1 UI 自动化：WebDriverAgent / Appium XCUITest

- **WebDriverAgent（WDA）**：Facebook 开源、后由 Appium 社区维护；原理是在 XCUITest 之上注入一个 WebDriver 协议 server，Appium 的 xcuitest-driver 通过它驱动真机/模拟器。这是 iOS 上**唯一**事实标准的第三方 UI 自动化通道。
- **典型坑（2024-2026 社区高频问题）**：
  - iOS 17/18 起调试协议迁移（CoreDevice），WDA 启动失败/白屏回主屏问题频发（Appium Discuss 大量帖子），几乎每个 iOS 大版本都要重编译 WDA；
  - **签名枷锁**：免费开发者证书 **7 天过期**、付费账号有设备数上限；真机规模化必须反复重签；
  - iOS 15+ 真机自动化时系统强制显示 "Automation Running" 悬浮条——**无法隐蔽运行**；
  - 无法跨 App 操作系统级界面，系统弹窗处理受限。
- **规模化实践**：灰产/营销工作室的真实做法是 **Dopamine 越狱（支持到 iOS 17.x）+ go-ios/tidevice + WDA** 绕过签名限制做批量真机（如 2025-10 BlackHatWorld 披露的 Instagram 群控架构）——越狱设备做微信自动化同样面临检测与封号，且越狱生态本身在萎缩。

### 9.2 越狱与注入

- 越狱现状：Dopamine/palera1n 等工具停留在 **iOS 17.x 及以下**，新版本（iOS 18+）无公开稳定越狱；越狱生态实质进入低潮。
- TrollStore 只是**永久签名利用**（装未签名 App），**不是注入框架**，不能 hook 微信。
- iOS 上 Hook 微信：无公开可行方案（无越狱=无注入；有越狱也需对抗微信加固），社区仅存在研究性质讨论。**"iOS 微信协议/hook"在开源世界基本不存在**——所有主流微信 hook 项目都是 Windows/Android 侧。

### 9.3 官方通道：App Intents + Foundation Models（2025-2026 新变量）

- Apple Intelligence 开放 **Foundation Models framework**（Swift 原生调用端上大模型）+ **App Intents**（声明式动作接口）；一句话概括社区共识："Foundation Models = 你的 App 跑模型；App Intents = Apple Intelligence 跑模型并路由到你的 App"（WWDC25/26 议程持续扩展，含第三方 LLM 接入）。
- 意义：这是 iOS 上**唯一合规、免越狱、系统级**的"AI 操作 App"路径——但前提是目标 App 自己声明了 App Intents。**微信是否深度暴露 App Intents 决定了这条路在微信场景的实际可用性**（目前微信仅支持有限的基础 intents，如分享）。
- 坑：能力完全取决于 App 开发者开放度；跨 App 复杂任务链仍不可控；中国区 Apple Intelligence 的功能可用性受地区限制影响。

### 9.4 iOS 路线小结

| 需求 | 可行方案 | 主要限制 |
|---|---|---|
| 自动化测试 | XCUITest / Appium+WDA | 签名、速度、稳定性 |
| 批量真机控制 | 越狱 + go-ios + WDA（灰产向） | 越狱设备稀缺、检测、封号 |
| Hook/协议 | **无可行公开方案** | 沙箱+无越狱 |
| 合规 AI 自动化 | App Intents + Foundation Models | 依赖目标 App 开放 intents |

---

## 十、路线 G：官方合规通道

> 结论先行：**面向"微信生态"的自动化，唯一长期可持续的路线是企业微信 API + 公众号/小程序体系**。个人微信永远不会有官方自动化 API（协议不开放是腾讯的明确立场）。

### 10.1 企业微信 API（合规自动化的主战场）

- **会话存档（MsgAudit）**：官方合规的"消息读取"通道——企业开通后，员工与客户的会话经 **RSA 双密钥加密**拉取（员工持私钥才可解密，保障合规知情）。SDK 能力边界：单次拉取 ≤1000 条、频率 ≤4000 次/分钟（官方文档 91774）。支持文本/图片/语音/视频/文件/小程序消息，**撤回消息亦保留**。这是所有合规 SCRM（纷享销客、点镜、微伴等）做质检、敏感词监控、超时提醒的技术底座。
- **客户联系（外部联系人）API**：客户增删、打标签、群管理、「联系我」二维码（临时会话每日上限 10 万个）——覆盖私域运营 80% 的自动化需求。
- **群机器人 webhook**：内部群发消息；**外部群机器人**收消息需"会话存档 + 回调"组合实现（官方推荐架构）。
- **边界与坑**：API 有严格频率限制与审核；营销消息仍受"骚扰拦截"约束；**个人微信 ≠ 企业微信**——用企微 API 操作个人微信号不存在合法通道。

### 10.2 公众号 / 小程序 / 开放平台

- 公众号（订阅/服务号）：模板消息、客服消息接口（48 小时窗口限制）——传统"微信机器人"的合规替代。
- 小程序服务通知、微信客服（weixin.qq.com 客服 API）：覆盖 C 端触达。
- 开放平台 UnionID/网站应用扫码登录：账号体系打通。

### 10.3 平台规则红线（官方文本）

- 《微信软件许可及服务协议》明确禁止：使用插件、外挂、第三方登录/同步、多开、模拟器仿真系统、自动化脚本/机器人 —— 这是所有非官方路线的违约基础，腾讯据此享有封号处置权。
- 2017 年微信官方公告（打击"多开""外挂"）是历次封号潮的政策起点。

### 10.4 Android 官方自动化通道

- Intent/deeplink、App Links：App 间跳转与传参的官方通道（合规"半自动"）。
- App Actions / Assistant、Android 15/16 的 App Functions 与 AICore：面向 LLM 的系统级动作接口（对应 iOS App Intents，生态早期）。
- **限制同样存在**：目标 App 不开放 deeplink/intent 时无从下手；微信只开放极少数 deeplink（如 weixin:// 跳转）。

---

**【路线 B（传统栈）与路线 E（云手机/群控）章节由后台调研代理返回后填写】**

---

## 十一、微信专项分析

### 11.1 微信风控的四层模型（综合公开资料与判例反推）

1. **环境层（设备指纹）**：root/Xposed/Frida 特征、多开虚拟环境、模拟器特征（build.prop/GL renderer/传感器）、云手机数据中心 IP、同一设备登录多号。微信自研加固 + 完整性校验（业界公认微信是国内反逆向最强的 App 之一）。
2. **账号层**：注册时长、好友数/频率、设备切换历史、实名状态。新号 + 自动化行为 = 秒杀；老号 + 轻度自动化 = 限功能/警告。
3. **行为层（服务端时序模型）**：消息发送频率与间隔分布（机器间隔过于均匀是经典信号）、加好友通过率、群发模式、操作时间（凌晨批量活跃）、UI 自动化的滑动/点击物理特征（速度、加速度、触点面积）。
4. **网络层**：IP 信誉（数据中心段、代理池）、同一出口多账号。

**各路线在微信上的暴露面**：

| 路线 | 环境层暴露 | 行为层暴露 | 总体存活率口碑 |
|---|---|---|---|
| 协议/Hook（D） | 高（协议指纹与官方客户端差异、版本异常） | 极高（消息时序最易建模） | 历史最低，历次封号潮主力打击对象 |
| 群控 + 真机/云机（E） | 高（IP 段、设备农场指纹） | 高 | 低-中（营销号常态化封禁） |
| UI 自动化（A/B） | 低（真机+官方客户端，环境干净） | 中（行为模拟质量决定） | 中（个人助手场景相对最稳） |
| 官方通道（G） | 无 | 无（在配额内） | 唯一稳定 |

### 11.2 "微信上到底能用什么"——按场景的诚实回答

- **个人 AI 助手（自动回复/摘要/记账）**：路线 A（GUI Agent）或 B（无障碍脚本）在**本人设备、本人账号、用户知情**场景可行；需处理：登录墙（短信/扫码必须人工）、防撤回类功能绝不做、消息发送保持拟人节奏、接受封号可能性。开源参照：wcferry + 3.9.x 旧客户端（研究用途、版本锁定）；wechaty + 协议 puppet（灰色）；更稳妥的是 **PC 端微信 + UI 自动化**（不注入、不逆向，仅操作界面，违约风险仍在但无"突破安全措施"的刑事要件）。
- **团队私域运营/SCRM**：唯一正确答案是企业微信 API（路线 G）。个人号 SCRM（群控型）已被判例+执法物理消灭。
- **自动化测试**：微信小程序/公众号 H5 可用 Appium/Web 自动化；微信 App 本体的 UI 自动化可用 Appium+UiAutomator2（微信 Android 无障碍树质量尚可）。
- **数据采集/监控**：会话存档（企微）或官方导出；爬朋友圈/聊天记录的第三方方案全部违规且有刑事判例。

### 11.3 已被验证的死路（勿投入）

1. itchat/wxpy（web 协议）——2017 年已死。
2. 个人号 pad 协议平台——2021-2022 打击后无稳定供给，法律定性明确。
3. 微信 4.0 hook——截至 2026-10 无生产级开源适配，只有研究脚本。
4. 多开/双开跑微信——官方公告明令禁止，检测成熟。
5. 模拟器登录微信——环境检测 + 风控降权，功能受限。

---

## 十三、法律与合规综述

> 本章所有案例均来自公开判决/报道，附来源。**核心结论：在中国大陆，"微信外挂/协议/群控"的开发者与销售者已有大量实刑判例；使用者层面以封号为主要风险，规模化商用则可能触刑。**

### 13.1 刑事红线：刑法第 285 条第三款（提供侵入、非法控制计算机信息系统程序、工具罪）

| 案例 | 法院/时间 | 结果 | 要点 |
|---|---|---|---|
| **丁某提供侵入计算机信息系统程序案** | 无锡梁溪区法院，(2022)苏0213刑初223号 | 有期徒刑 **1 年 6 个月** | **最高人民法院"入库参考案例"**（court.gov.cn，2024-12 发布）——此类案件的官方参考标杆 |
| **微信外挂"海贼王"案** | 广州南沙法院，2021 判决 | 主犯获刑 **10 年** | 提供专门用于侵入、非法控制计算机信息系统的程序（人民网 2021-04） |
| 余某等开发销售外挂案 | 2024 | 定罪判刑 | 共谋开发+销售外挂软件 |
| 反向编译微信通讯协议"盗版微信"案 | 2020 报道 | 主犯实刑、从犯免刑 | 逆向微信协议在功能机上运行盗版客户端 |
| 浙江安吉公众号推广微信外挂案 | 2018 | 定罪 | **"推广销售"环节同样入罪**，不限于开发者 |

**构成要件要点**（两高 2011 年司法解释及后续解释）：程序"专门用于侵入/非法控制计算机信息系统"的认定核心是**避开或突破安全措施、未经授权获取数据/控制权限**——微信 hook/协议/群控全部命中。情节特别严重档（3-7 年）的入罪门槛并不高（获利 5000 元以上、提供 20 人次以上等标准参见司法解释）。

### 13.2 民事红线：《反不正当竞争法》第 12 条（互联网专条）

| 案例 | 结果 | 要点 |
|---|---|---|
| **联络易微信群控系统案** | 二审判赔 **1000 万元** | 微信个人号群控/SCRM 工具的代表性判决 |
| **微源码"数据精灵"群控软件案** | 腾讯胜诉 | 入选**最高人民法院典型案例**，确立"互联网专条"对群控的适用 |
| 武汉某公司群控外挂案（2019，深圳中院） | 立即停止销售 | 早期代表案例 |
| 北京黑灰产业链案（2022，北京知产法院） | 判赔 **500 万元** | 反法第 12 条适用 |
| 网站买卖微信号案（2021） | 判赔 100 万+9 万维权费 | 账号交易环节也被追责 |
| 银光公司破解微信缓存数据案 | 认定不正当竞争 | "技术中立"抗辩被驳回 |

### 13.3 个人使用层面

- **封号是常态处置**：违反用户协议 → 腾讯单方处置权（功能限制、封号、设备拉黑），无救济渠道（仲裁/诉讼极少支持恢复）。
- **刑事边界**：单纯自用一般不构成 285 条犯罪（该罪打击"提供"行为），但**规模化使用+获利**（如营销矩阵、流量变现）在多起案例中被纳入共犯/帮信罪评价范围。
- **数据合规叠加风险**：自动化采集聊天记录/通讯录 → 同时触碰《个人信息保护法》（ consent 原则）与《数据安全法》；若涉及对外提供，还有刑法 253 条之一（侵犯公民个人信息罪）风险。

### 13.4 海外对照（简述）

- **美国**：CFAA 时代 *Van Buren v. United States*（2021）与 *hiQ v. LinkedIn* 收窄了"未授权访问"的认定，抓取公开数据/自动化操作的刑事风险较低，但平台 ToS 违约诉讼（民事）与州级反机器人法（如加州）仍有效。
- **欧盟**：GDPR 约束数据处理；DMA 要求守门人开放互操作（iMessage/WhatsApp 互操作接口正在落地）——**平台封闭性在欧洲正被立法渐进打破**，这是与中国的最大环境差异。
- **共性**：全球范围内"平台服务条款"都是第一道约束；差异在于违约的后果是民事还是刑事。

### 13.5 给技术选型的合规结论

1. **测试自己的 App**：任意路线（Appium/无障碍/adb）均合法。
2. **操作微信生态、面向业务**：只有企业微信 API / 公众号 / 小程序合规；个人微信自动化 = 违约封号风险起步，规模化 = 刑事风险。
3. **通用手机助手（用户自己的设备、自己的账号、辅助操作）**：UI 层自动化（路线 A/B）法律风险低，但违反具体 App 条款仍可能封号——产品形态上必须设计为"用户明确指令的辅助工具"而非"无人值守营销工具"。

---

## 十四、参考资料

### AI GUI Agent 路线
- minitap-ai/mobile-use：https://github.com/minitap-ai/mobile-use
- X-PLUG/MobileAgent（GUI-Owl）：https://github.com/x-plug/mobileagent
- DroidRun：https://github.com/droidrun/mobilerun ｜ https://droidrun.ai
- zai-org/Open-AutoGLM ｜ THUDM/MobileRL：https://github.com/THUDM/MobileRL
- AutoGLM 论文：https://arxiv.org/html/2411.00820v1 ｜ 智谱研究页：https://www.zhipuai.cn/zh/research/145
- AIMultiple 独立评测：https://aimultiple.com/mobile-ai-agent
- DroidRun HN 讨论：https://news.ycombinator.com/item?id=43703688

### 微信 Hook / 协议编年史
- WeChatFerry：https://github.com/lich0821/wechatferry（适配 3.9.x，不支持 4.0/Mac）
- wxhelper：https://github.com/ttttupup/wxhelper（3.8–3.9.x）
- Wechaty FAQ（2017 web 协议封禁记载）：https://wechaty.gitbook.io/wechaty/zh/faq
- puppet-padlocal：https://github.com/wechaty/puppet-padlocal
- 看雪《微信 4.0 hook——三端可行方案 + Frida 脚本》（2025 底，研究性）

### Root / Hook / 虚拟化
- LSPosed 停止维护报道：https://www.sohu.com/a/751005116_827544 ｜ https://cloud.tencent.com/developer/news/1290083
- LSPosed 兴衰史：https://zhuanlan.zhihu.com/p/2050637394790160307
- VirtualApp：https://github.com/aslody/virtualapp ｜ 原理解析：https://zhupite.com/sec/virtualapp.html
- Android 多开检测原理：https://song-dev.github.io/2019/12/23/more-open-check
- VA 生存风险研究：https://huigll.com/gemini-deep-research-virtualapp
- PlayIntegrityFork：https://github.com/osm0sis/PlayIntegrityFork
- 2026 过 Play Integrity 指南：https://www.reddit.com/r/Magisk/comments/1snwug7/
- 风控检测引擎 sentry：https://github.com/taisuii/sentry
- 绕过加固 Frida 检测（Zygisk Gadget）：https://zhuanlan.zhihu.com/p/1984679739089253036 ｜ https://bbs.kanxue.com/thread-282623.htm

### 法律判例
- 最高法入库参考案例·丁某案：https://www.court.gov.cn/zixun/xiangqing/449641.html
- 微信外挂"海贼王"案（主犯 10 年）：http://society.people.com.cn/n1/2021/0405/c1008-32069719.html
- 浙江安吉公众号推广外挂案：https://m.21jingji.com/article/20180911/herald/61abd9f524a63ea3f91b034631e6b141_zaker.html
- 微源码"数据精灵"群控案（最高法典型案例）：http://frlde.court.gov.cn/8/2106/138.html
- 腾讯获赔 500 万黑灰产案：https://tech.ifeng.com/c/8Iw3HCEHnau
- 武汉群控案：https://tech.sina.cn/2019-12-05/detail-iihnzahi5535230.d.html?vt=4

### 传统自动化栈
- redroid-doc（本节及路线 B/E 维护状态均经 GitHub API 核实，来源同下）
- Appium：https://appium.io ｜ uiautomator2-driver：https://github.com/appium/appium-uiautomator2-driver
- Maestro：https://github.com/mobile-dev-inc/maestro ｜ openatx/uiautomator2：https://github.com/openatx/uiautomator2
- scrcpy：https://github.com/Genymobile/scrcpy ｜ minitouch 死因：https://github.com/openstf/minitouch/issues/49
- DeviceFarmer STF：https://github.com/DeviceFarmer/stf ｜ Sonic 归档公告：https://github.com/SonicCloudOrg
- AutoJs6：https://github.com/SuperMonster003/AutoJs6 ｜ SoloPi：https://github.com/alipay/SoloPi
- Airtest：https://github.com/AirtestProject/Airtest ｜ assists：https://github.com/ven-coder/assists
- Android 无障碍限制：https://developer.android.com/about/versions/16/behavior-changes-16 ｜ Play 政策：https://support.google.com/googleplay/android-developer/answer/10964491
- 微信 8.0.52 节点混淆：https://zhuanlan.zhihu.com/p/1907372254662198397 ｜ 影刀对策：https://www.yingdao.com/community/detaildiscuss?id=778797613129592832
- 鸿蒙 hdc：https://github.com/openharmony/developtools_hdc ｜ hmdriver2：https://github.com/codematrixer/hmdriver2

### 云手机 / 模拟器 / 群控
- redroid：https://github.com/remote-android/redroid-doc ｜ Docker Hub：https://hub.docker.com/r/redroid/redroid
- Waydroid：https://waydro.id ｜ Cuttlefish：https://source.android.com/docs/devices/cuttlefish ｜ Anbox Cloud：https://canonical.com/anbox-cloud
- 树莓派 redroid：https://ivonblog.com/posts/redroid-on-raspberry-pi ｜ 百元硬件云手机：https://zhuanlan.zhihu.com/p/16813369338
- 红手指：https://www.gc.com.cn ｜ 雷电云：https://www.ldyunos.com ｜ 多多云：https://www.ddyun.com ｜ 河马云：https://lcloud.longene.com.cn ｜ VMOS：https://www.vmos.cn
- 阿里云无影云手机：https://www.aliyun.com/product/cloud-phone ｜ 华为云 CPH：https://support.huaweicloud.com/intl/zh-cn/productdesc-cph/cph_prod_0002.html
- Genymotion SaaS：https://www.genymotion.com/product-cloud ｜ AWS Device Farm：https://aws.amazon.com/device-farm/pricing ｜ Corellium：https://www.corellium.com
- Group-IB 云手机威胁报告（2026-03）：https://www.group-ib.com/blog/cloud-phones-invisible-threat
- 315 曝光主板机：https://v.cctv.com/2024/03/15/VIDEoJJNPNT4g4F3Yt4BZjHP240315.shtml
- 微信打击百万外挂账号（2019）：https://www.secrss.com/articles/12405 ｜ 微信云控江湖：https://zhuanlan.zhihu.com/p/428530398
- QtScrcpy：https://github.com/barry-ran/QtScrcpy ｜ 模拟器原理：https://zhuanlan.zhihu.com/p/557003707

### iOS / 官方通道 / RPA
- Appium iOS 18 适配追踪：https://github.com/appium/appium/issues/20239
- XCUITest 驱动排障（Automation Running 条等）：https://appium.github.io/appium-xcuitest-driver/latest/guides/troubleshooting
- 越狱+WDA 批量自动化实例：https://www.blackhatworld.com/seo/ios-instagram-automation-with-appium-architecture-review-scaling-questions.1761075
- Apple Foundation Models：https://developer.apple.com/documentation/foundationmodels ｜ App Intents 解读：https://blakecrosley.com/blog/foundation-models-on-device-llm
- 企微会话存档官方文档：https://developer.work.weixin.qq.com/document/path/91774 ｜ 100142 ｜ 92228
- UiPath 移动自动化：https://docs.uipath.com/activities/other/latest/ui-automation/android-local-devices
- 影刀手机自动化（ADB 群控）：https://blog.csdn.net/ddf128/article/details/142258708
- EasyClick 移动自动化（群控工具生态）：https://ieasyclick.com/mobile-automation