云计算百科
云计算领域专业知识百科平台

豆包后台操作手机原理分析

豆包手机端(特指豆包手机助手,即与中兴合作的系统级工程机,非普通豆包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合成 │ │
│ │ 画面低频发送至云端推理 │ │
│ └─────────────────────────────────┘ │
└─────────────────────────────────────────┘

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

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

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

  • 本地:aikernel 进程(内存占用约160M)负责承接任务、执行指令、管理本地状态
  • 云端:每 3-5秒 将虚拟屏画面(约 250KB/帧)上传至字节服务器(obriccloud.com)
  • 推理:云端多模态大模型(推测为 UI-TARS 系列)分析屏幕内容,返回约 1KB 的精简指令(如:click @e2, swipe_up, input_text 等)
  • 循环:本地执行 → 再次截图上传 → 云端判断下一步,直到任务完成
  • 这种"重云轻端"的设计,让本地负担最小化,复杂推理由云端承担 。


    五、执行层:如何"操作"页面?(幽灵手指)

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

    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)

    七、安全边界与限制

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

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

  • 八、总结

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

  • 虚拟屏幕:在GPU中创建一个与物理屏隔离的"影子系统",任务在后台运行
  • GPU缓冲区直读:绕过截图API,直接从内核层获取屏幕原始数据
  • INJECT_EVENTS注入:以系统级权限向内核注入输入事件,指定虚拟屏displayId,实现"幽灵触控"
  • 这套方案与Playwright完全不同——Playwright是基于CDP协议的浏览器自动化工具,而豆包手机助手是操作系统级的GUI Agent,其权限深度、架构复杂度和运行模式都远超浏览器自动化范畴。它本质上不是"在App里操作页面",而是**“在操作系统里再运行一个虚拟手机,让AI在虚拟手机上替你操作”**。

    赞(0)
    未经允许不得转载:网硕互联帮助中心 » 豆包后台操作手机原理分析
    分享到: 更多 (0)

    评论 抢沙发

    评论前必须登录!