豆包手机端（特指豆包手机助手，即与中兴合作的系统级工程机，非普通豆包App）在操作手机页面时，采用的是一套**“绕过无障碍服务、直抵系统内核”**的底层方案。其核心在于：虚拟屏幕隔离 + 系统级事件注入 + 端云视觉推理。

---

一、整体架构：感知 → 规划 → 执行

豆包手机助手的运行逻辑遵循 GUI Agent（图形界面智能体）的经典循环 ：

┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│  感知（看）  │ → │  规划（想）  │ → │  执行（做）  │
│ GPU缓冲区读屏 │    │ 云端大模型   │    │ 注入输入事件 │
│ 虚拟屏幕截图  │    │ 视觉理解+推理 │    │ 模拟触控    │
└─────────────┘    └─────────────┘    └─────────────┘

---

二、感知层：如何"看到"页面？（不截图、不依赖无障碍）

传统自动化工具（如AutoGLM）依赖 AccessibilityService 读取界面元素，但豆包手机助手完全不依赖无障碍服务 。

它通过以下系统级权限获取屏幕内容：

权限	作用
CAPTURE_VIDEO_OUTPUT	捕获屏幕视频输出流
CAPTURE_SECURE_VIDEO_OUTPUT	捕获标记为 Secure 的页面（但豆包声称遵循Secure标记，不截取银行类敏感页面）
READ_FRAME_BUFFER	直接从 GPU图形缓冲区 读取原始图像数据，而非调用上层截图API

关键优势：绕过应用层的反截图/反录屏限制（如银行App的DRM保护），因为数据来自内核层的GPU缓冲区，而非应用层API。

---

三、后台操作的核心：虚拟屏幕（“影子系统”）

这是回答你**“页面位于后面时也可以操作吗”**的关键：可以，且不影响你前台正常使用手机。

豆包手机助手通过 Android 的 WindowManagerService 创建了一个与物理屏幕分辨率相同的"无头"虚拟屏幕（Headless Virtual Display）：

┌─────────────────────────────────────────┐
│           物理屏幕 (Display 0)           │
│  ┌─────────────────────────────────┐    │
│  │     用户前台：刷抖音、聊微信      │ ← 你正常使用
│  └─────────────────────────────────┘    │
│                                         │
│  ┌─────────────────────────────────┐    │
│  │  虚拟屏幕 (Virtual Display)      │ ← 豆包在后台操作京东/淘宝
│  │  分辨率相同，独立焦点，GPU合成     │    │
│  │  画面低频发送至云端推理            │    │
│  └─────────────────────────────────┘    │
└─────────────────────────────────────────┘

• 独立焦点：虚拟屏幕拥有独立的输入焦点，与物理屏幕互不干扰
• 后台运行：用户可以在前台刷视频、发消息，豆包在虚拟屏上默默执行任务
• 随时查看：点击屏幕顶部的横条，可将虚拟屏画面投射到物理屏上"监工"

---

四、规划层：端云协作推理

豆包手机助手的"大脑"主要在云端：

1. 本地：aikernel 进程（内存占用约160M）负责承接任务、执行指令、管理本地状态
2. 云端：每 3-5秒 将虚拟屏画面（约 250KB/帧）上传至字节服务器（obriccloud.com）
3. 推理：云端多模态大模型（推测为 UI-TARS 系列）分析屏幕内容，返回约 1KB 的精简指令（如：click @e2, swipe_up, input_text 等）
4. 循环：本地执行 → 再次截图上传 → 云端判断下一步，直到任务完成

这种"重云轻端"的设计，让本地负担最小化，复杂推理由云端承担 。

---

五、执行层：如何"操作"页面？（幽灵手指）

这是豆包与传统自动化工具最本质的区别。它不通过无障碍服务模拟点击，而是：

1. INJECT_EVENTS 系统权限

通过 系统签名（与手机厂商合作预装，拥有系统级私钥），豆包持有 INJECT_EVENTS 权限，直接向 Linux内核的 Input Subsystem 注入原始输入事件 ：

// 伪代码示意：直接向内核注入触摸事件
injectInputEvent(MotionEvent.obtain(..., displayId=virtualDisplayId, ...));

• 权限级别：远高于无障碍服务，仅手机厂商预装应用或持有系统签名key的应用才能获得
• 跨应用能力：可将事件发送到任何窗口或任意App，不受前台限制
• 指定displayId：通过指定虚拟屏幕的displayId，事件精准落在虚拟屏上，而非物理屏

2. 仿生触控算法（反风控）

为了骗过微信、淘宝等App的风控引擎（它们能识别机械点击），豆包还引入了仿生运动算法 ：

• 点击坐标加入微小随机偏移（非像素级完美）
• 按压时间模拟人类分布（非固定50ms）
• 滑动轨迹加入贝塞尔曲线拟合（非直线）

---

六、与传统方案的对比

维度	普通无障碍方案（如AutoGLM）	豆包手机助手
读屏方式	AccessibilityService 读取节点树	GPU缓冲区直接取图
操作方式	无障碍模拟点击（前台独占）	INJECT_EVENTS 内核注入（后台并行）
后台能力	❌ 占用物理屏幕，无法前台并行	✅ 虚拟屏隔离，用户可正常使用手机
权限来源	用户手动授权无障碍	系统签名预装，系统级权限
反风控能力	较弱，易被识别为脚本	仿生算法，更接近真人
适用设备	任意安卓手机	仅合作厂商预装机型（如中兴nubia M153）

---

七、安全边界与限制

尽管权限极高，豆包也设置了若干安全阀 ：

1. Secure标记尊重：声称不截取标记为Secure的页面（如银行App）
2. 支付拦截：涉及转账、支付时强制用户手动确认 + 真人检测
3. 逐项授权：权限调用需用户逐项主动授权，屏幕显示明确提示
4. 用户可中断：随时可点击顶部横条停止任务

---

八、总结

豆包手机助手能在后台操作"位于后面"的页面，核心依赖三项技术：

1. 虚拟屏幕：在GPU中创建一个与物理屏隔离的"影子系统"，任务在后台运行
2. GPU缓冲区直读：绕过截图API，直接从内核层获取屏幕原始数据
3. INJECT_EVENTS注入：以系统级权限向内核注入输入事件，指定虚拟屏displayId，实现"幽灵触控"

这套方案与Playwright完全不同——Playwright是基于CDP协议的浏览器自动化工具，而豆包手机助手是操作系统级的GUI Agent，其权限深度、架构复杂度和运行模式都远超浏览器自动化范畴。它本质上不是"在App里操作页面"，而是**“在操作系统里再运行一个虚拟手机，让AI在虚拟手机上替你操作”**。