本文转载自：https://mp.weixin.qq.com/s/s13YBYD9R8y-PK7FO3Suyw 作者：OpenBMB开源社区

近日，字节跳动发布的豆包手机助手在业内激起了广泛讨论。这不仅是一款新智能硬件的亮相，更标志着大模型应用范式的一次重要跃迁——从“chat（对话）”真正迈向“action（行动）”。作为长期深耕大模型领域的研究者，我们将豆包手机助手定义为行业首款系统级 gui agent。它不再是一个孤立的智能应用，而是深度耦合于操作系统底层、具备跨应用感知与操作能力的“超级中枢”。

如何看待豆包手机助手的当下与未来？藉此机会，我们希望与大家分享我们眼中的手机助手，以及端侧智能的演进愿景与路线图。

 

豆包手机助手关键技术解析与研判

GUI Agent 无疑是豆包手机助手的核心技术。为透视豆包手机助手的技术本质，我们有必要先回顾 GUI Agent 技术从实验室走向产业界的演进脉络。2023 年至 2025 年间，GUI Agent 技术经历了从“外挂式框架”到“模型原生智能体”的根本性范式转变：

GUI Agent 发展的最早期阶段（2023‑2024）采用外挂式框架，其核心思路是不改变大模型本身，而是通过提示工程将界面转化为模型可读的文本和函数接口（如 HTML/DOM 树，代表工作有 OSU 的 Mind2Web、腾讯的 AppAgent）或带数字标记的截图（Set‑of‑Mark，如阿里的 Mobile‑Agent‑v1）。这一阶段的智能体能力上限受限于提示词设计与外部工具（OCR、检测模型）的精度，模型并未真正“看见”GUI 环境，更多是在进行文本逻辑推理。

立即进入“豆包AI人工智官网入口”；

立即学习“豆包AI人工智能在线问答入口”；

后来，模仿学习驱动的视觉语言模型方案代替出现（2024）。随着视觉语言模型能力提升，技术路径转向模型内生。智谱的 CogAgent、我们的 GUICourse [1]、上交&MIT 的 OS‑Atlas 等工作摒弃了对 XML/DOM 等底层数据的依赖，直接基于像素输入理解界面，并输出坐标。这一阶段实现了感知层面的“原生化”，模型开始像人类一样通过“看”屏幕来理解界面布局，显著提升了对非结构化 GUI 的适应能力。

目前，强化学习驱动的视觉语言模型成为主流（2024‑2025）。其核心突破在于引入强化学习以解决复杂决策问题。伯克利的 DigiRL 首次验证了利用强化学习构建 GUI Agent 的可行性。在此基础上，智谱的 AutoGLM 和我们的 AgentCPM‑GUI [2] 进一步在大规模 GUI 任务中验证了强化学习的有效性。字节的 UI‑TARS 工作则引入大规模在线强化学习，使得智能体能在与 OS 环境的持续交互中优化策略，学会错误修正、长程规划与泛化应对。至此，GUI Agent 真正具备了在动态环境中自主执行任务的能力，而豆包手机助手正是这一技术路线的集大成者。

GUI Agent 的发展历程

而为何之前的 GUI Agent 多停留于 Demo 阶段，而豆包手机助手却接近了实用临界点？通过技术复盘，我们认为其在工程侧与模型侧完成了关键突破：

在工程侧，以往的 GUI Agent 方案多依赖 Android 无障碍服务或 ADB 调试，存在权限易屏蔽、高延迟以及“抢占前台焦点”干扰用户等致命缺陷。豆包手机助手凭借定制 OS 的优势，实现了“非侵入式”的系统级接管。据我们研判，其工程实现包含两大核心要素：

• GPU Buffer 直读：绕过传统截图接口，在系统底层直接读取屏幕渲染缓冲区的数据，大幅降低了视觉信号获取的延迟。

• 虚拟屏幕后台进程：这是一个巧妙的工程技巧。为避免智能体操作抢占用户焦点，系统内部构建了第二块虚拟屏幕，AI 在后台不可见的虚拟屏幕上执行点击与滑动，而前台用户仍可正常使用。

而在模型侧，综合现有使用体验与技术特征判断，豆包手机助手采用端云协同的模型架构：

• 端侧模型：主要负责意图识别与任务路由。对于调节音量、亮度等简单任务，直接通过端侧模型调用本地系统 API 完成，实现毫秒级响应。

• 云侧模型：处理多步骤、跨应用的复杂任务（如跨 APP 订票）。该模型内部区分“思考”与“非思考”两种模式：非思考模式下以低时延直接执行；思考模式下会先进行任务拆解、流程规划与需求澄清，再进入执行阶段，以平衡响应速度与任务成功率。

• RL 数据飞轮：其核心护城河在于建立了基于强化学习的数据闭环。通过高保真 OS 沙盒环境，模型经历了数百万次轨迹的探索与优化，高质量数据用于下一轮 SFT 训练，低质量数据回收至持续预训练阶段。这种工业级数据规模使其泛化能力显著优于学术界开源模型。

豆包手机助手的出现，标志着 GUI Agent 终于走出实验室的“玩具”阶段，开始具备实用价值。它揭示了一个事实：大模型不仅是大脑，更能接管屏幕、模拟触控，成为连接数字世界的“万能接口”。当然，若我们将目光投向更长远的未来，GUI 操控或许并非端侧智能的终局。 目前的 GUI Agent 本质上是一种“兼容旧生态”的过渡方案——它不得不通过模拟人类的视觉和触控，去适应那些并非为 AI 设计的图形界面。这种方式虽然通用，但链路过长、依赖屏幕渲染。 我们认为，随着端侧生态的成熟，手机助手的操控方式可能进一步兼容“APP/系统工具调用”与“生态级智能协同”：

• APP/系统接口调用：相比于模拟点击，直接调用 APP 或系统的接口（API）具备更高的准确率和更短的执行链路。事实上，豆包手机助手在调节音量、亮度等系统级任务上，正是通过直接调用系统接口实现了毫秒级的零失误响应。虽然目前第三方 APP 厂商开放接口的意愿受限于商业博弈，但随着 AI 手机渗透率的提升，高频功能（如支付、打车、预订）必将从“视觉组件”封装为“语义接口”，供智能体高效调度。

• APP 即智能体：目前的架构中，手机助手作为“大脑”需要承担极其沉重的认知负荷，它必须理解成千上万个 App 内部的微观逻辑。未来的 APP 或许不再仅仅是等待被操作的“工具”，而是演化为具备独立能力的“子智能体”。对于“规划差旅”这种超长程任务，主智能体仅需向下分发子任务，而具体的比价、选座、风控核验等繁琐步骤由 App 内部的子智能体在应用内自主闭环。这种分层协作模式将极大降低主智能体的认知负荷，通过生态级的智能分工，显著提升复杂任务的执行泛化性与鲁棒性。

豆包手机助手虽然目前主要依赖 GUI 技术，但其在系统层面的深度整合，实际上也为未来向 API 调用和多智能体协同演进展示了可能性。

 

豆包手机助手的技术局限性分析与展望

豆包手机助手让大众看到了端侧智能的潜力。但从性能评测与应用生态来看，以它为代表的端侧智能体要想真正服务数十亿用户的智能化生活，仍需攻克三大方向难题：

首先，终端调用云侧模型存在安全风险。豆包手机虽采用端云协同架构，但绝大多数屏幕理解与操作任务仍严重依赖云侧 GUI 模型，这相当于将用户的数字生活全面映射至云端。“云侧接管一切”的模式在隐私安全、网络依赖和算力成本上均面临可持续性挑战，也触及了应用厂商将用户行为数据视为核心资产的红线。其直接后果是，豆包手机助手在市场博弈中已陆续暂停对微信、淘宝等核心应用的智能操作支持。我们判断，未来的 AI 手机生态不应是“云侧通吃”，而应遵循端云结合原则：云侧模型处理通用逻辑与专业需求；涉及用户隐私、实时交互的私有数据必须在端侧闭环。当前“端侧过轻”的架构缺陷，亟需通过构建本地“安全屋”来化解。

其次，智能体自主完成任务能力不足。我们在豆包手机助手发布后第一时间进行了高难度测评，并同时开展智谱 AutoGLM 的测评作为参照。结果显示，豆包手机助手在 59.86% 的复杂任务上取得成功，AutoGLM 等开源方案则成功率更低。失败案例复盘显示，核心问题集中在四方面：

• 生态覆盖有限：面对小红书、美团、淘宝等高频应用，智能体常因无法精准调起原生应用，被迫降级为网页搜索或通用问答，“服务直达”退化为“内容检索”。

• 复杂指令解析精度不足：模型对含多参数（时间、地点、价格）、多对象（私聊 vs 群聊）的复合指令理解存在缺陷，难以精准提取关键槽位信息。

• 动态环境执行鲁棒性缺失：面对网络波动、权限弹窗及风控校验时，模型缺乏中断恢复与替代方案规划能力，易因单点受阻陷入死循环。

• 长程交互上下文管理混乱：在多轮交互中，模型易受历史信息干扰，导致“最近”“附近”等时空约束被错误覆盖。

最后，个性化与主动服务能力不足。目前的豆包手机助手本质仍是“用户下令‑智能体执行”的被动工具。大模型拥有全人类通用知识，却唯独缺少对“你”的深度理解。它不知道你下班的习惯路线、点咖啡的糖度偏好，也无法在开会时自动拦截骚扰电话。真正的个人助理必须是“千人千面”的，这要求智能体能够利用端侧数据进行持续学习，形成专属用户的个性化记忆。当前的豆包手机助手仍偏向傻瓜式任务自动化，远未达到个性化主动服务的阶段。

综上所述，为应对隐私安全、环境感知、复杂任务决策与个性化服务四大挑战，未来的 AI 手机技术体系必须向 端侧智能（隐私安全）、全模态智能（环境感知）、自主智能（复杂决策）与 主动智能（个性化服务）四个方向持续演进。

 

端侧智能：以端侧模型实现安全可控的智能应用

现代移动操作系统的安全基石是“沙盒机制”，即应用间数据隔离、互不干扰。然而，系统级 GUI Agent的出现，本质是赋予了一个超级进程一把打开所有沙盒的“万能钥匙”。豆包手机助手的实践揭示了一个根本性矛盾：系统级智能体为实现“万能操作”所必需的全局视野，与用户对隐私和数据主权的根本诉求之间，存在着天然张力。而解决这一矛盾，是端侧智能走向普及的前提。

尽管厂商采用了“端云协同”架构，并宣称对密码输入等极端敏感场景进行本地处理，但在绝大多数日常场景下，海量用户行为数据的流向与控制权依然是一个不透明的“黑盒”。这导致了便利性与数据主权之间的根本博弈：如果每一次点击、每一屏浏览都需要经过云端审视，用户实际上是在向服务商让渡自己的“数字主权”。一旦这个超级智能体被攻破，后果将不堪设想。

正是基于对上述矛盾的深刻认识，我们认为，未来的AI手机生态绝不能是“云侧通吃”，而必须确立 “端侧原生、端云协同” 的根本原则，建立清晰的分工体系。端侧是 隐私的“守门人”与体验的“基石”：涉及用户隐私、实时交互、个人习惯的所有“私有域”数据与操作，必须在端侧形成闭环。用户是数据的唯一持有者，端侧模型充当隐私的“守门人”。这不仅是保护数据主权，也是实现毫秒级极致响应、提供“类人”交互体验的物理基础。云侧是专业的“智库”与广域的“连接器”，涉及海量知识、复杂逻辑推理或需要广泛互联的“专业域”任务，则可路由至云侧专家模型处理。云侧凭借其参数规模、知识广度与互联网连接，充当专业的智库。这一分工的改进是 将数据主权和安全闭环坚定地锚定在端侧。当智能真正在用户设备内部运行时，人机之间更容易建立起坚实的信任契约，这也是我们团队坚持“端侧原生”路线的根本原因。

将大模型能力装入边缘设备，面临功耗、存储和算力的多重约束。我们团队并未盲目追逐参数规模，而是围绕 “端侧、高效” 构建全栈技术壁垒，核心是提升模型的“能力密度”——即单位参数内蕴含的智能水平。因此，我们提出 “能力密度法则” ：大模型能力密度每 3.5 个月翻倍。这意味着，技术创新的目标是以更小的模型实现更强的性能，这一规律反映了大模型发展从"尺度驱动"向"能效驱动"的必然转变。围绕这一法则，我们构建了“模型架构-数据治理-学习方法”的高能力密度制备技术体系，其中以模型架构技术为例，w在 稀疏模型架构 和 软硬协同的极限压缩与加速 两方面的工作，验证了这一技术发展方向的可行性：

• 稀疏模型架构：我们研发了如 BlockFFN [3] 和 InfLLM-V2 [4] 等技术，摒弃传统 Transformer 的全参数激活模式，实现计算资源的“按需分配”。在推理时仅激活极少部分相关神经元，尤其在处理长文本时，能将计算复杂度从二次方降低至线性，实现超高稀疏度，让端侧设备“跑得动、不发烫”。

• 软硬协同加速：针对“内存墙”瓶颈，我们融合投机采样与极低比特量化技术。通过“小模型起草、大模型验证”的协同解码，以及将参数压缩至 4 比特乃至更低，大幅降低内存带宽占用。我们开源的轻量端侧模型 MiniCPM 系列，累计下载超 1700 万次，并已落地众多主流终端设备。

大模型的能力密度在不断增强[7]

端侧智能不仅仅是技术路径的选择，更是价值取向的锚定。它通过将隐私闭环于设备、将响应提速至毫秒、将算力负担优化至可持续，从根本上解决了智能普及中的信任、体验与成本问题，是构建未来个人化、可信赖数字伴侣的必由之路。

 

全模态智能：能听会看的全模态感知能力

包括豆包手机助手在内的当前 GUI Agent，在感知层面仍主要依赖“截图+上传”的静态处理模式。要实现真正的“类人”助手体验，智能体必须突破传统视觉语言模型的模态壁垒，具备在端侧深度处理文本、图像、视频、音频等多模态信息的能力。我们认为，下一代端侧智能感知将围绕 “统一架构下的全模态融合” 与 “实时流式的动态交互” 两个维度演进。

第一，架构演进需要从“多模态”走向“全模态”。当前主流多模态模型本质仍是“拼接式”架构，即通过连接器浅层对齐视觉/音频编码器与语言模型。这种范式限制了对跨模态细微关联（如语音语调与面部表情的同步性）的捕捉能力。随着 GPT‑4o 及 Gemini 系列模型的发布，全模态（Omni）正成为新前沿。这类模型旨在底层打通不同模态的表征空间，实现原生的理解与生成。在端侧算力受限的挑战下，我们的 MiniCPM‑o 系列模型验证了这一路径的可行性：我们摒弃臃肿的外部组件堆叠，通过统一建模将语音理解生成、视觉理解与文本处理集成到高效端侧基座中。这种架构统一不仅显著降低推理开销，更使智能体能像人类一样综合处理并行信号，为未来覆盖触觉、温度等更广泛物理信号奠定基础。我们相信，全模态感知能力是大模型走出屏幕、走进物理世界，支撑具身智能、自动驾驶等关键应用的重要基础。

第二，交互演进需要从“静态采样”走向“动态流式”。真实世界的多模态信息流是动态连续的，而非静态截图。当前大部分端侧智能体仅能处理离线采样数据，相当于对真实世界进行“切片”。这种“回合制”交互导致显著延迟，无法满足实时翻译、视频通话辅助等即时需求。为打破瓶颈，端侧感知必须向流式演进。我们研发的 MiniCPM‑o 2.6 通过多路时分复用的流式编码技术，在端侧设备上实现了对动态信息流的实时响应。模型无需等待语音说完或视频录完，而是在接收信息的同时进行增量式理解与决策。这种流式架构不仅大幅降低首 token 延迟，更实现“全双工”交互——用户可随时打断模型，模型也能敏锐捕捉插话时机。此外，针对流式处理可能丢失细节的问题，我们在底层融合了 LLaVA‑UHD [5] 的高分辨率处理技术，通过自适应切片策略，实现对任意长宽比图像的低功耗、低延迟高清编码。“流式传输+高清编码”的组合，让端侧智能体既能流畅“看”视频，也能精准捕捉一闪而过的文字细节（如屏幕报错代码），真正将电影《Her》中全天候、实时响应的智能伴侣带入现实。

标签： react html android 操作系统 微信 编码 人工智能 app 字节 美团 淘宝 工具 qq 腾讯 mac