卷土重来的豆包手机，把隐私问题解决了吗？
2025 年 12 月 1 日，搭载豆包手机助手技术预览版的努比亚 M153 以工程样机的形式少量发售，定价 3,499 元，很快售罄。官方演示中，它可以根据一篇种草笔记寻找商品、跨平台比价，也能整理旅游攻略、在地图中标记餐厅，再根据行程继续处理后面的任务。
那是很多人第一次直观地看到，手机里的 AI 不再只是回答问题，而是真的能够「动手」。它看懂屏幕上的文字和按钮，自己规划步骤，再通过点击、滑动和输入，在不同 App 之间把事情办完。
但新鲜感很快撞上现实。部分用户在微信、支付宝和游戏中遇到登录受限、风险拦截或外挂判定。外界将其概括为一轮「行业封杀」。公开信息无法证明不同平台曾统一行动，但结果很明确：一代最有吸引力的跨 App 操作，碰到了第三方平台的安全与权限边界。
不到一年后，豆包手机助手进入消费者预览阶段，将首先搭载于努比亚 NaviX Ultra。第一代豆包手机 M153 官方也有同步推送 OTA 的计划。
所以，这一次真正值得追问的是，它针对上一次碰壁，究竟做了哪些改变？
从底层框架上重组 AI 执行流程
第一代豆包手机主要依靠 GUI Agent 完成任务。
用户提出要求后，模型理解意图，视觉模型读取屏幕，再生成点击、滑动和输入指令。它的优势是通用：即使应用没有专门适配，只要 AI 能够识别页面，就可以尝试操作。
这也是一代最具冲击力的地方。它不必等待所有 App 开放接口，先用一套视觉方案覆盖尽可能多的场景。
问题也由此产生，GUI Agent 高度依赖页面读取能力，为了读取和操作不同应用，它需要较高的系统权限。在第三方 App 看来，这种持续读屏、自动输入和批量点击的行为，与脚本、外挂或群控工具非常接近。
所以，一代遭遇的「封杀」既有生态利益因素，也有执行架构本身的问题。
而在豆包手机二代上，没有放弃 GUI Agent。官方页面依然将「操作手机」标为 Beta，并明确表示这项功能会通过「模拟点击和调用工具」完成任务。真正的变化，是 GUI 不再承担所有工作。
官方的应用开发接入文档里有这样一张图，介绍了豆包手机二代的新系统框架。
如果把新架构简化，可以看到三条执行路径：
第一条是系统工具调用。
电话、日历、闹钟和录音机等能力，可以直接接收结构化指令。比如批量创建多个闹钟，AI 不必在时钟界面中重复点击，而是把时间、日期和重复规则交给系统处理。
它解决的是 GUI 步骤多、速度慢和容易受界面变化影响的问题。只要系统已经提供能力，模型就不需要再模仿人的操作过程。
第二条是标准服务接口。
消费者预览版官网目前明确提到，豆包已经接入曹操出行、地图等服务，通过轻量化、标准化接口处理生活服务需求。应用决定开放哪些数据和能力，豆包则在约定范围内调用。
这条路径直接对应第三方 App 问题。平台知道请求来自谁，也能判断调用是否符合自己的业务规则。任务不再依赖完整页面，App 改版也不会直接破坏执行流程。
对于已经完成接口合作的服务，过去那种「AI 在前台模拟真人点击，App 在后台把它当作脚本拦截」的矛盾，基本可以从执行机制上消除。
第三条仍然是 GUI Agent。
现实中，不可能要求所有应用同时完成接口改造。为了覆盖没有系统工具、也没有开放服务接口的长尾场景，豆包依然需要理解图形界面并模拟操作。
不过，这一次 GUI Agent 外面增加了 SAEP，也就是豆包官方发布的「屏幕自动化操作声明协议」。
按照官方文档，第三方应用可以从 App、Activity 页面和 Intent 业务意图三个层级，声明 Agent 的操作边界。
一家应用可以允许 AI 浏览普通页面，同时禁止它在登录页截图和输入；可以开放商品搜索，却不允许 AI 确认付款；也可以在发布内容、删除文件或修改账号信息时，要求用户亲自接管。
系统执行操作前，会综合 Agent 身份与设备可信状态、系统安全基线、应用声明策略，以及用户对当前任务的授权，随后给出允许执行、直接阻断或者召回用户等结果。
这里最关键的变化，是不再只依赖模型自己的判断，而是把规矩放在前面定死。
SAEP 把约束放在截图、无障碍读取、点击和输入等系统入口。应用已经禁止的操作，Agent 不能换一条通道继续尝试；系统安全基线设定的限制，也不能被模型或应用降低。Agent 的身份、目标页面、操作意图、命中的策略和执行结果还会被记录。
在执行层之上，又增加了任务编排。用户提出需求后，系统需要拆分任务，再判断每一步应该调用系统工具、第三方服务还是 GUI Agent。任务之间存在先后关系时进入队列，信息不足时向用户追问，触及敏感操作时暂停并交还控制权。
因此，新架构已经不再是简单的「大模型加模拟点击」，而是一条更完整的链路：
「意图理解—任务编排—路径选择—权限裁决—执行与审计」。
但这套架构是否已经解决了「App 封杀问题」？答案需要分情况看。
已经开放标准接口的应用，冲突在执行机制上得到较大缓解；愿意接入 SAEP、但仍需 GUI 操作的应用，可以把过去模糊的授权关系变成明确规则；既不开放接口，也不接受 Agent 操作的平台，原来的问题依然存在。
官方目前只表示，「操作手机」支持系统及中兴应用、字节系应用和部分已经接入的第三方应用，没有公布完整名单，也没有宣布微信、支付宝等此前争议最大的应用已经全面开放。
所以 NaviX Ultra 对第三方 App 的限制已经有了应对方案，但距离全面解禁仍有很长的一段路要走。
豆包已经回答了「门应该怎么开」：深度合作的应用走接口，需要 GUI 操作的应用通过 SAEP 协商边界。至于多少应用愿意开门，决定权并不完全掌握在豆包手中。
最关键的隐私问题
行业对豆包手机的另一个担忧，是它为了理解和操作屏幕，会接触大量个人信息。
从官方白皮书看，消费者预览版采用的是端云协同，而不是所有数据都留在手机本地。
设备端部署了 OCR、文本向量化、命名实体识别、内容识别和多模态模型，用来处理部分高敏感数据。TEE 可信执行环境和系统文件加密，则负责保护模型、个人记忆和推理过程中产生的数据。
复杂任务需要云端模型时，部分数据仍会上云。按照白皮书的说法，这些请求会经过加密传输，部分用户和设备标识会被替换为伪 ID，能够关联具体个人的信息则会在进入模型前脱敏。
针对屏幕内容，豆包此前承诺云端处理遵循「不存储、不训练」原则。全局记忆优先在端侧处理，用户可以按照应用、时间和地点控制记录范围，也可以随时关闭功能、删除部分记录或者全部清空。
这些措施主要回答数据如何采集、传输、保存和删除。
SAEP 和高敏感操作确认处理的是另一半问题：AI 获得信息后，能不能据此采取行动。支付、账号认证和不可逆操作可以要求用户接管；锁屏状态下调用高级能力，需要通过 AI 键完成指纹鉴权。
对于普通聊天机器人，隐私主要关心 AI 看到了什么。对于能够操作手机的 Agent，还必须追问它看完以后做了什么。
这也是消费者预览版安全设计更值得关注的地方。隐私不再只是一份数据处理声明，它开始进入任务规划、权限检查和动作执行的过程。
不过，现阶段能够确认的仍是官方披露的设计。白皮书没有公布所有数据类型的具体保存时间，也没有提供消费者预览版在真实环境中的独立安全测试结果。架构已经搭起来，实际效果还需要等待验证。
和苹果不一样的路线探索
从整个行业视角来看，豆包与苹果正在形成两条不同的智能体手机路线。
苹果的 Siri AI 核心是 App Intents 和 App Schemas。
开发者先把应用里的动作、内容和实体整理成系统能够识别的结构。音乐应用可以开放「播放歌曲」，日历可以开放「创建日程」，旅行应用则可以把航班信息变成能够被系统检索的实体。
Siri AI 通过系统编排器、Spotlight 索引和 App Toolbox 寻找这些能力，再根据用户意图进行调用。
苹果也提供屏幕理解和个人 Context，但第三方 App 执行任务的主要入口仍然是开发者主动提供的结构化能力。应用没有开放的动作，Siri AI 通常无法依靠模拟点击自行补足。
这条路线的特点，是应用先把路修好，AI 再沿着规定路线行动。
豆包则保留了一条小路。
有系统工具或者服务接口时，它同样采用结构化调用；没有接口时，GUI Agent 仍可以尝试从应用界面完成任务。SAEP 负责给这条更灵活、也更难控制的路径增加身份、规则和审计。
苹果路线的稳定性和权限确定性更高，能力范围取决于开发者适配。豆包可以更快触达尚未接口化的场景，却要承担页面变化、模型误判、平台风控和权限冲突带来的额外成本。
在模型运行层，两者反而比较相似，都采用端侧与云端结合的方式。
苹果在设备算力不足时使用 Private Cloud Compute。除了声明请求结束后不保留个人数据，苹果还提供部分安全关键组件、透明日志和研究环境，让外部研究人员可以验证云端系统是否符合公开承诺。
豆包采用 TEE、端云加密、假名化、机密计算和任务结束后的数据清理。目前的区别在于，豆包主要公开了安全白皮书与接入协议，苹果还建立了更完整的外部验证机制。
所以，这两条路线都已经从概念走进产品，但它们还处在不同的落地范围和成熟阶段。
让系统长期运转还需要什么？
努比亚 NaviX Ultra 与豆包的深度合作，也让人好奇，它能否由此建立起自己的技术壁垒？
首先 GUI Agent 不属于豆包独有，系统工具和服务接口也可以被其他厂商建设。SAEP 提出了一套更完整的声明、裁决与审计机制，但协议可以被研究和借鉴，文档本身不会自然变成壁垒。
真正难复制的，是把这些模块连成一个稳定运行的系统。
模型需要理解用户意图，把复杂需求拆成任务，为每一步选择 GUI、系统工具或者服务接口，再经过安全策略决定能否执行。任务失败后，系统还要重新规划、解释原因，并保留可以追溯的记录。
这既需要模型能力，也需要操作系统改造、硬件安全环境、第三方服务合作，以及大量真实任务带来的工程经验。
苹果的优势是同时控制芯片、操作系统、云端安全架构和开发者框架，可以让 App Intents 成为整个生态长期使用的标准。
豆包不掌握完整的 Android 生态，需要与手机厂商合作进入系统底层，再推动不同应用接入服务接口或者 SAEP。它潜在的壁垒，来自这种跨平台协调能力：如果同一套 Agent 执行层能够进入更多 Android 品牌，并让第三方应用使用相对统一的方式声明权限，豆包就有机会成为手机厂商和应用之间的一层新平台。
NaviX Ultra 证明了 GUI、工具、服务接口、任务编排和 SAEP 可以被装进同一套消费者产品。它还没有证明的是，这套架构能够稳定覆盖多少应用，第三方厂商是否愿意长期接入，以及高权限操作能不能经受持续安全检验。
问题还没有彻底消失
回到最初的问题，从 Beta 到消费者预览版，豆包手机最大的变化，是从依赖 GUI Agent 的单一路径，转向由任务编排统一调度 GUI、系统工具和服务接口，再用 SAEP 管理第三方应用边界。
这套架构缓解了 GUI 操作不稳定、应用无法识别 Agent 和高风险动作缺少约束等问题，也为此前的「App 封杀」提供了一种协商方式。
但这只是一个开始。接口能够覆盖多少应用，SAEP 能否被主流平台接受，这些悬而未决的问题，仍然决定着豆包手机的能力上限。
所以接下来，豆包需要让更多应用看到接入的价值：既能保留对自身业务和数据的控制，也能通过AI获得新的用户需求，这条路不好走，但却是真正智能体手机必须跨过的门槛。
因此，消费者预览版更像是豆包手机走向成熟的起点。它已经提出了模型、系统与应用共同工作的办法，下一步要证明的，是这套办法能否在更多应用、更多用户和更长时间里持续有效。
作者：Hope
编辑：屹松
来源：未来设备局