豆包手机指字节跳动 × 中兴努比亚的 nubia M153（2025-12-01「工程样机」限量上市，3499 元，首批 3 万台 24h 售罄）。它不是一款普通手机，卖点是系统级 AI 智能体的「操作手机 / Phone Use」能力——动嘴让 AI 跨 App 自动比价、下单、发文件。
实现本质 =ROM 层开放的无障碍权限（读屏 + 模拟点击）+ 多模态 VLM 读屏理解（底层方向对标字节自家 UI-TARS）+ 端云协同。属于 GUI Agent（模拟人操作）路线，而非「调用官方 API」路线。
上市即被封：微信、淘宝/支付宝/闲鱼、拼多多、多家银行、王者荣耀等以「登录环境异常 / 风险环境」拒绝登录或踢下线。这并非临时针对，而是既有风控规则被 Agent 的「机器特征」自然触发。
深层是「Agent vs App 必有一战」：
智能体一旦成为统一入口，平台同时失去广告、推荐、会员、定价权与用户数据。封禁是防御，开放协议（MCP / App Intent / 双重授权）是未来方向，但商业利益再分配未解。
豆包手机的实现原理
1.1 手机 GUI Agent 的通用四阶段流水线
每一步的循环（感知→定位→规划→执行→再感知）是长程任务的核心；一次点外卖/订机票可能需要数十步连续操作，误差会逐步累积，这也是后文「为什么容易被风控识别」「为什么 benchmark 难做高」的根源。
1.2 技术路线
1.3 端云协同方案
豆包公开材料强调「端侧加密处理、用户可控、不存储操作记录」（隐私白皮书口径），但端/云具体分工的技术细节未充分公开。可参照同类与学术：
荣耀 YOYO 公开「端云协同矩阵」：端侧小模型（图像理解 + 隐私）+ 云端多个 LLM（意图理解 / 规划）。
学术参照 EcoAgent（arXiv:2505.05440）等「端云协同多智能体」框架。
结论：豆包「端云协同」目前只有宣传口径，缺可验证技术披露，引用须标注。
2、开源opencyvis方案
OpenCyvis 是一个开源的 AI 手机方案。用户可以自由选择 LLM 后端（云端或本地），AI 在后台虚拟显示器上操作，不占用前台屏幕。Apache 2.0 协议，代码完全公开。
OpenCyvis 同时提供两种输入：截图让模型理解当前界面的语义和布局，UI 元素树（Accessibility Tree）提供每个控件的精确坐标、类型和层级关系。两者互补——视觉信息解决"这是什么"，结构信息解决"它在哪里"。此外，当模型陷入死循环时，本地快速哈希相似性检测也可以为模型作出有效提示。
2.1 相关概念
1）a11y树
a11y 是 accessibility 的数字缩写（首尾字母 a 和 y，中间 11 个字母），所以 a11y 树 就是无障碍树。a11y 树是浏览器基于 DOM 树和 CSSOM 生成的一棵平行的树结构，专门用来向辅助技术（如屏幕阅读器、语音控制软件、盲文设备等）暴露页面信息。
普通的网页是通过 HTML 渲染出来的，普通用户通过视觉来阅读网页。但对于视障用户，他们需要依赖屏幕阅读器（如 NVDA、JAWS、VoiceOver）来“听”网页。
屏幕阅读器并不会直接去读取复杂的 HTML 代码或 DOM 树，因为里面包含了太多用于样式、布局或脚本的干扰信息。相反，浏览器会把 DOM 树转换成一棵“a11y 树”，屏幕阅读器等辅助技术通过读取这棵树，来向用户朗读网页内容或进行交互。
工作流程： HTML -> DOM 树 -> a11y 树 (Accessibility Tree) -> 操作系统 API -> 屏幕阅读器 -> 用户
和dom树的区别：
举例
2） IME+ADB概念
利用 ADB 的高权限通道，在手机后台运行一个中转服务（Server），通过网络（IP+端口）接收指令，然后利用“虚拟输入法”和“系统注入权限”来模拟人的操作。手机上安装一个“injectorIME + ADB”类工具，打开后能通过 IP + 端口远程操控手机，本质上是把 Android 调试桥（ADB） 的通信能力、事件注入机制 以及一个自定义输入法（IME） 组合在一起，提供一个网络化的控制接口。下面拆解它的实现原理，再回答能否在打开 App 后上传文件/视频。
核心原理是利用了Android系统的输入法机制（Input Method Framework）作为桥梁，并在输入法后台运行了一个网络服务器（Web Server/Socket Server）。
手机安装了一个输入法 App → 这个 App 同时启动一个 HTTP/WebSocket/TCP 服务 → 电脑/其他设备访问 手机IP:端口 → 发送“输入文本、按回车、删除、粘贴”等命令 → 输入法把这些命令注入到当前焦点输入框里。
在Android系统中，输入法是一个拥有极高权限的后台服务（InputMethodService）。
高权限/免Root：一旦用户在系统设置中启用了该输入法，并将其设为默认，该输入法就自动获得了向当前活动窗口发送按键、字符、甚至模拟点击的天然权限，且不需要手机获取Root权限。
常驻后台：输入法服务由系统管理，生命周期极长，不易被系统杀后台，这保证了远程控制连接的稳定性。
相比于传统的远控软件（如 TeamViewer、向日葵），使用输入法注入有独特的优势：
绕过系统安全限制（免Root）：Android 处于安全考虑，极难让普通 App 模拟全局按键。但系统对“默认输入法”是完全信任的；
极低的延迟：直接通过局域网 Socket 传输指令，延迟通常在几毫秒以内，比视频流远控快得多；
轻量级：不需要传输屏幕画面（通常只传指令），对手机性能和电量消耗极小；
ADB 提供远程控制通道
InjectorIME 提供稳定文本输入能力
input/uiautomator/Appium 提供点击、滑动、控件操作能力
adb push/pull 提供文件传输能力
3） 虚拟屏
VirtualDisplay 是 Android 系统原生提供的一个 API，允许在系统内部创建额外的逻辑显示器。它本来的用途包括 Chromecast 投屏、分屏模式、以及 Android Automotive 的多屏显示等。每个 VirtualDisplay 拥有独立的显示 ID，应用可以被迁移到任意一个 Display 上独立运行。
1）两种运行模式(前台 vs 虚拟显示器)
前台模式:Agent 直接操作物理屏(Display 0),适合人机协作、你盯着看。
VD 模式:Agent 在后台独立虚拟屏运行,你能随时切进去 VIEW(观看)或 TAKEOVER(接管),处理完交还,AI 从断点续跑。
display/VirtualDisplayManager 创建离屏虚拟屏。关键设计:
Surface 用 ImageReader(8 buffer,RGBA_8888)零拷贝读帧；
帧缓存防饿死(很妙的坑):acquireLatestImage() 只在"上次 acquire 后有新帧"才返回非 null。如果屏幕静止(如 launcher 不动),连续重试会全拿到 null 导致任务被中断。
解法是用 OnImageAvailableListener 在后台线程持续 drain 并缓存最新一帧到 cachedBitmap,截图返回缓存副本——这样静态画面也能拿到帧；
Mirror VD(标准模式特有):再镜像一块半分辨率、500ms 节流的 VD,确保用户切到 VIEW 模式(主 VD surface 被 SurfaceView 占用)时,Agent 仍能拿到新截图而非旧缓存。
VD flags 参考豆包 mFlags=120533:PUBLIC | SECURE | AUTOMIRROR | SUPPORTSTOUCH | SHOULDSHOWSYSTEMDECORATIONS | OWNFOCUS | ALWAYS_UNLOCKED | …。
其中 OWNFOCUS(不抢主屏焦点)、ALWAYSUNLOCKED(免解锁)、SHOULDSHOWSYSTEM_DECORATIONS(显示导航栏/状态栏/输入法)是后台跑通的关键。
IME 策略 DISPLAYIMEPOLICY_LOCAL:让软键盘渲染在 VD 内部，这样 TAKEOVER 时用户能在虚拟屏里打字。
VD 内启动统一加 NEWTASK | MULTIPLETASK | EXCLUDEFROMRECENTS | NOUSERACTION,避免被控任务暴露到用户的最近任务里。
display/TaskDisplayGuard：被控 task 可能通过 Recents、通知、deeplink 跳回 Display 0(就出现在你眼前了)。它用隐藏 API TaskStackListener 监听 onTaskMovedToFront 等事件,发现逃逸就 moveTaskToDisplay() 搬回 VD。
4）虚拟屏的特点和优势
虚拟显示器能否"登录一个美团账号,然后后台跑多个搜索任务"?
结论先行：架构上支持——VD 是个持久的独立"影子手机",登录态能一直保持,登录后让 AI 在上面反复搜索完全是它的强项;但"登录"这一步是最脆弱、最可能卡住的环节,且单块 VD 是串行而非并行多任务。最佳实践是 "登录交给人、搜索交给 AI"。
一块 VD 同时只有一个前台 Activity,所谓"多个搜索任务"是 agent 顺序做完一个再做下一个(或用 Routine 排队),不是开 N 个窗口同时搜。要真并行得建多块 VD,资源/复杂度都翻倍,项目默认不这么做。
2.2 opencyvis和豆包手机的主要区别
商业"AI 手机"(各大厂的系统级 AI 助理)是黑箱:你看不到跑的什么模型、什么数据离开了设备、也不能换方案。OpenCyvis 给出开源替代——代码可审计、模型自选、用本地模型时数据不出设备。
2.3 核心实现逻辑
引擎是 engine/AgentEngine.kt(从一个 cli_demo.py 移植成 Kotlin)。一个 step 的完整数据流:
1）观察(Observe)
两路信息一起喂给 LLM:
截图:capture/ 多策略截图 → ImageUtil 处理管道:缩放到 ≤540px 宽 → RGBA 转 RGB → JPEG 85% 编码 → base64。压到 540px 是为省 token / 加速；
UI 树:accessibility/VdAccessibilityService 通过 getWindowsOnAllDisplays().get(displayId) 拿到虚拟屏上的窗口,递归遍历 AccessibilityNodeInfo,输出紧凑文本(可交互元素带 [id] 编号,坐标归一化 0-1000),过滤掉 systemui、不可见节点,最大深度 15、最多 200 节点；
视觉 + 结构化文本"双模态"互补:截图解决"长什么样",a11y 树解决"精确坐标和可点性",显著降低纯视觉模型的坐标幻觉。
2） 思考(Think)
llm/ 下有三个客户端实现同一个 LLMClientInterface,屏蔽协议差异:
输出统一收敛成一个 function tool phoneaction（llm/ToolSchema.kt），actiontype 枚举:tap / openapp / swipe / keyevent / typetext / wait / finish / fail / askuser / handoffuser / note / remember / saveroutine。每次 tool call 必带 thought 和 action_type;坐标用 0-1000 归一化,与设备分辨率解耦。
3）底层提示词与模型交互细节
提示词和模型协议不是散落在业务代码里,而是集中在这几个文件:
一个完整 step 的闭环：
截图/JPEG/base64 + UI树 + 指令 + 反馈/记忆
→ OpenAI compatible chat.completions(stream + required tool)
→ phone_action JSON
→ Action.fromMap()
→ ActionRepeatGuard 防重
→ ActionExecutor 执行
→ 等屏幕刷新
→ 下一轮重新截图验证
这也是 OpenCyvis 和普通脚本最大的差异：脚本是"预先写死路径"，而这里是"每一步都重新观察、让模型重新决策"。所以它更泛化,但也更依赖 prompt/schema 的严谨性、模型 tool calling 稳定性和防重反馈质量。
4） 整体架构
双后端权限抽象(v2.0 核心设计)
所有"需要特权的操作"(输入注入、截图、建虚拟屏、任务管理)都被抽象到 PrivilegeBackend 接口后面,业务逻辑完全不感知特权从哪来:
运行时由 BackendDetector 自动按优先级选:系统 uid → Shizuku → 无线 ADB → (Root)。两种模式上层代码 100% 共享,差异只在权限层。
2.4 其他实现与开源方案肉包的对比
肉包(roubao)团队用 Kotlin 重写了整个 MobileAgent 框架，原生运行在 Android 设备上：
截图、分析、执行全部在手机本地完成
无需电脑中转，延迟更低
利用 Shizuku 获得系统级权限，而非繁琐的 ADB 命令
opencyvis-phone 更像一个“系统级 AI Phone 框架”，重点是后台虚拟屏、双权限后端、远程控制和隐私可控；
roubao 更像一个“面向普通用户的 Shizuku + VLM 自动化 App”，重点是安装门槛低、UI 完整、Skills/Tools 架构清晰。
OpenCyvis 更重工程化。它有 system 和 standard 两个 flavor，说明它同时支持系统签名路径和普通 App 路径；代码里还有 JNI、AIDL、ADB pairing、Shizuku、双 backend设计。这是偏“平台层能力封装”。
Roubao 更直接依赖 Shizuku，核心假设是“先拿到 ADB 级权限，再在 App 内完成截图、点击、输入”。这条路更容易让普通用户理解，但底层权限模型没有 OpenCyvis那么分层和可扩展。
模型协议与 Agent 形态:OpenCyvis 更统一, Roubao 更异构。
它用 LLMClientInterface 收敛了:
OpenAI compatible
Anthropic
Ollama
主路线强调 tool calling 与统一 phone_action schema。这意味着:
上层引擎不关心具体模型厂商
Action 类型统一
SSE、重试、JSON 兜底解析、tool schema 都在同一套抽象里
即便我本地后来给它加了 SearchScenarioClient,那也是在统一接口上加了一个场景化 client,不是另起一套 App runtime。
Roubao 的模型层更异构。它至少并行支持三条路:
VLMClient:OpenAI 兼容多模态接口
GUIOwlClient:阿里云 GUI-Owl 专用协议
MAIUIClient:MAI-UI 专用 prompt 和 格式
这带来两个特点:
优点:可以直接吃专门为 GUI Agent 设计的模型/服务,例如 GUI-Owl、MAI-UI。
缺点:上层逻辑要兼容多种返回格式,系统的一致性不如 OpenCyvis 强。
3、升级一下比亚迪车机系统
3.1 行业背景:大模型 / Agent 已经在上车
座舱 AI 的三阶段:语音识别(2010s)→ 大模型上车(2023) → 推理模型 / AI Agent(2025)。
头部布局:
理想(理想同学):自研多模态 Mind GPT,"三助一师"(用车/出行/娱乐助手 + 百科老师),支持打断式交互、手势+语音融合。
蔚来(NOMI / NomiGPT):多智能体(Multi-Agent)框架,把座舱体验 agent 化(知识类/生成类/任务类),多 Agent 分工完成"理解→决策→执行→反思"。
智己:行业首个 AI Agent 车机,主打 "No Touch & No App"。
端侧算力瓶颈:中科创达 + 吉利 + NVIDIA 的 AIBOX 首次让 7B 大模型车端实时运行;DeepSeek-R1 推动端云协同、降时延提准确率。
判断:行业共识已是"Agent 化",但现阶段上车的 Agent 多停留在"助手/陪伴/场景功能列举"层面,真正"能操作任意 App、完成多步任务"的执行层仍是空白——这正是 OpenCyvis 式 GUI Agent 的切入点。(注:各家 OTA/芯片量产时间点多为前瞻预测,以官方发布为准。)
3.2 小迪没有大模型时代的核心技术原理？
小迪 = 比亚迪 + 科大讯飞，本质是传统意图识别助手(NLU → intent → 绑定动作):
核心痛点：小迪对没做车机定制的第三方 App，只能启动,不能操作内部(播放、选项、跳菜单都不行)。社区只能靠"音乐助手 + 填包名""迪粉桌面 快捷指令包"打补丁，恰恰反证了原生能力的边界。这是典型的"意图白名单"天花板:每多支持一个 App 的一个功能,都要工程师去对接一次。
千万别用 GUI Agent 去做车控——"空调调到 23 度"小迪走 API <1s 确定完成,GUI Agent 每步 4~8s 还是概率性的,既慢又危险。正确做法是意图路由分层:
快路(保留小迪现状):车控、导航、音乐、安全相关——官方 API,确定、快、车规安全。
慢路(新增 GUI Agent):小迪现在做不了的长尾——"在 XX App 里把自动续费关掉""在某点评搜附近评分 4.5 以上的火锅并收藏前三家"。
后台 VD 是天作之合:AI 在虚拟屏忙活,主驾主屏完全不受干扰,结果还能投到副驾屏;配合小迪已有声源定位,按主驾/副驾分级放权。
3.3 分阶段路线图
3.4 核心问题:在哪儿"接"进小迪?
4、手机APP厂商风控和限制方案
4.1 封禁事件时间线（2025.12）
4.2 打开付款码是黑的？
为什么"打开支付宝二维码"是黑屏?(FLAGSECURE)，这是预期行为,不是 bug,根因是 Android 的安全屏机制 FLAGSECURE。
为什么黑:
支付宝付款码/二维码页给窗口加了 FLAG_SECURE(防截屏、防录屏,支付安全合规)。微信支付、银行 App、DRM 视频同理。
系统规则:只有"目标显示屏本身是 SECURE 的",安全窗口才会被合成上去;否则该内容在这块屏上根本不渲染(黑)。普通 SurfaceControl/ScreenCapture 截安全内容也返回黑。
关键代码 VirtualDisplayManager.kt:318-341:只有 SystemBackend(平台签名)才给 VD 加 VIRTUALDISPLAYFLAG_SECURE;RemoteBackend(标准模式,shell uid 2000)建的 VD 没有 SECURE flag(shell 无此权限,还会逐级降级 flag 直到能建成)。
引擎现有的兜底(AgentEngine.kt:287-327):
每步用 isBitmapStrictlyBlack() 判断严格全黑(所有采样像素 == 0x000000),刻意区别于转场动画那种带状态栏颜色的"假黑",避免误判。
连续 ≥3 帧严格全黑 且之前出现过非黑帧 → 触发 WaitingForHandoff,提示:"这屏可能是隐私保护页,请你接管"。
另有 BLACKLIST GATE:把支付/银行类包名配进 blacklistedPackages,agent 一旦检测到这些 App 在顶层就主动交还控制权,根本不尝试操作(默认空集,需自行配置)。
5、现代手机的一些限制
在 Honor 300 上，MagicOS 会把后台 App 的进程放进 cached-app freezer。进程被 freezer 冻结后：
进程还在，pidof ai.guiagent.injector 还能看到 PID。
前台服务记录还在，dumpsys activity services 仍可能显示 isForeground=true。
TCP 端口可能还保持监听，所以电脑侧 connect() 可以成功。
但是 App 里的 Java/Kotlin 线程不会被调度，InjectorService 的 socket 读取线程不处理请求。
最终表现是：TCP connect succeeded，但 ping、tap、screenshot、getcurrentapp 等命令超时。
6、参考
1）opencyvis
https://mp.weixin.qq.com/s/WqscKGhQ2-0tFd-pzeygJg
https://github.com/opencyvis/opencyvis-phone
2）肉包
https://github.com/Turbo1123/roubao
