豆包手机再进App，权限不能只分允许和拒绝

作者｜画画

豆包手机又来了。

就在今天，努比亚 NaviX Ultra 正式发售，搭载豆包手机助手消费者版本。

去年，豆包手机让 AI 看懂手机屏幕、模拟点击、跨 App 完成任务。用户说一句话，AI 去找页面、填信息、办事情。

用户得到效率，技术却很快撞上 App 原有的交互边界。结果规则没跟上，只能草草收场。

一年时间，豆包没有放弃最容易引发争议的能力。

GUI （图形用户界面）操作被保留下来，但放进 Beta；屏幕自动化操作声明协议 SAEP 同时上线，进入 30 天公示期。对开发者来说，这不像一次沟通，更像一份来自入口方的规则通知。

同时，豆包也开始补一堂更难的课：一个 App 允许 Agent 进来，究竟允许它做到哪一步？

搜索商品、读取订单、完成支付，显然不该共用同一个开关。权限的开放，更不是一个同意或者拒绝这么简单。

豆包手机再进 App，入口越大，权限的调用反而越难。

一、AI 进入 App，规则得先跟上

传统软件之间的连接，大多从开发者开放接口开始。App 决定开放什么能力，调用方按照接口规则使用。

GUI Agent 绕过了逐一适配，通过识别界面、寻找按钮来完成操作。

这让 Agent 可以迅速覆盖大量应用，也让原有边界变得模糊。开发者未必知道 AI 会进入哪个页面，更难仅凭用户授权判断一次操作是否符合自身的风控和商业规则。

这里同时考验两层信任：用户是否信任豆包，App 是否信任这个 Agent。

用户授权 AI 代表自己行动，App 则需要决定 AI 能否进入、可以调用哪些能力。

缺少其中任何一层，跨应用操作都很难成为稳定服务。

豆包同时推进的 MCP（模型上下文协议） 和 SAEP（屏幕自动化操作声明协议），对应两条不同的连接路径。

MCP 让开发者把搜索、查询、下单等能力封装为标准工具，主动交给 Agent 调用；SAEP 处理的是大量 App 尚未完成接口适配时，GUI 智能体能否进入界面，以及可以操作到什么程度。

前者更稳定，也更容易划清责任；后者覆盖更快，却要处理更复杂的权限关系。

两套机制并行，反映出 AI 手机当前的现实，Agent 需要尽快获得足够广的服务能力，开发者生态却不可能在短时间内全部完成适配。

如果每个 App 都要等到接入 MCP 或其他原生接口后才能被调用，手机助手的能力扩张就会受制于开发者的接入速度。

GUI 提供了一条过渡路径，AI 先学会像人一样使用软件，软件再逐渐把能力以更稳定的方式交给 AI。

SAEP 则把此前模糊的关系摆到了台面上。AI 替用户行动之前，除了获得用户许可，也需要回应应用方的边界。

Agent 时代，授权开始变成双向的。

这次变化，真正有意思的是“同意”如何成立。

SAEP 自 9 月 14 日起公示 30 天。公示期内，豆包只操作系统应用、字节旗下应用，以及通过 SAEP 或邮件明确同意的第三方应用，其余 App 默认不操作。

但公示期结束后，豆包将逐步扩大可操作范围，未明确拒绝的 App 可能被纳入；已经拒绝的应用始终不会进入操作范围。

前 30 天采用主动同意，30 天后则可能转为未拒绝即可逐步开放。开发者拥有退出权，也需要主动完成判断和表态。

头部 App 有安全、法务和产品团队，可以评估协议、划定权限；大量长尾应用未必能及时完成同样的工作。没有回复，可能是接受，也可能只是没有看到通知，或者尚未判断 GUI 操作会不会触发账号、内容和交易风险。

30 天机制背后还有一个更深的问题：App 究竟应该给 Agent 多大权限。

以整个 App 为单位表达允许或拒绝，对 Agent 仍然过于粗糙。同一个电商 App 里，搜索商品、读取订单和完成支付是三种风险完全不同的动作；哪怕是一个办公软件里，读取公开文档和调取企业内部资料，也不该使用同一层权限。

一张覆盖整个 App 的通行证远远不够。

Agent 需要一套任务级权限系统，哪些内容可以读取，哪些页面可以操作，什么动作必须重新获得用户确认，操作记录由谁查看，授权如何撤回。

这种分级能让开发者清楚知道，开放一项能力之后，权限如何划分。

变化最终还会落到手机系统本身。过去，操作系统主要管理 App、账号和设备权限；Agent 加入后，它还需要管理谁可以代表用户行动，以及这种代表权在什么条件下生效。

AI 手机的竞争不会只看能操作多少 App，还要看多少 App 愿意持续、稳定地开放能力。

豆包已经给了开发者拒绝权，接下来要解决的，是如何让“同意”成为一次清楚、具体、可以随时收回的授权。这件事，目前还没有清晰的答案。

三、豆包要争的，是任务入口

就在豆包手机消费者版本发售前一天，飞书发布 8.0 版本，并宣布与豆包工作原生融合。

飞书 8.0 为 Agent 进行了系统性重构，文档、多维表格、会议、日历和审批等工具开始向 Agent 开放。豆包工作与飞书共用账号体系，沿用用户原有的身份和权限：员工看不到的信息，Agent 同样无法获取；管理员可以配置权限、追溯行为，并限制高风险场景。

同时发布的豆包工作伙伴又往前走了一步。它拥有独立身份、权限和记忆，可以进入群聊，在授权范围内使用企业文档、会议记录和业务系统。

这个产品目前仍处于与企业定向共创阶段，但字节想要的形态已经清楚：让 Agent 从临时调用的工具，变成长期留在组织里的协作者。

豆包手机面对的是另一种环境。

飞书内部有共同的账号体系和管理关系，Agent 可以先获得身份，再沿着既有权限工作；手机里的 App 彼此独立，背后有不同的账户、风控和商业模式。豆包想跨应用完成任务，首先要获得足够广的操作范围。

豆包手机和豆包工作因此不是两条无关的产品线。它们是在两种环境里验证用户是否愿意把一件完整的事情交给 Agent。

在企业场景里，字节要让 Agent 理解组织、权限和上下文；在消费场景里，它要让 Agent 连接更多服务。

过去，用户先找到 App，再在 App 里寻找功能。Agent 希望把这个顺序倒过来，用户先说出目的，Agent 负责选择工具、调用服务和交付结果。

如果这种交互成立，Agent 就会成为新的任务分发层。它未必取代 App，却会影响哪个服务被调用、调用到哪一步，以及什么结果最终呈现给用户。

字节过去最擅长的是内容分发。到了 Agent 时代，它正在尝试把这种能力向任务分发延伸。

内容分发连接注意力，任务分发连接行动。

这也是豆包手机之所以加速的原因，在字节这场 AI 布局里，豆包手机是最靠近消费者的一个入口。

四、模型可以等，入口不能

豆包要争任务入口，背后是字节正在用两种速度推进 AI。

8 月初，字节管理层给出了两个节奏不同的信号。先是张一鸣在 Seed 内部会议上强调长期主义和延迟满足，不能依赖其他模型的输出换取一时的榜单成绩。

模型端强调耐心，这没错，但字节的产品端却开始抢时间。

更早的 7 月 30 日，飞书产品团队与豆包产品团队整合，飞书 GTM 与火山引擎团队合并。不到两个月，飞书 8.0、豆包工作和豆包工作伙伴集中发布，豆包手机助手消费者版本紧接着进入市场。

字节 CEO 梁汝波更是在 9 月 15 日的飞书未来无限大会上说，公司将投入更多资源，让智能更快进入企业组织。

更快，也是理解这组密集动作的关键词。

基础模型的差距可以用更长时间追赶，入口的位置却不能一直空着。

用户尚未形成把完整任务交给 Agent 的习惯，各家产品都还有机会；一旦习惯形成，后来者还要补上用户认知、服务覆盖和开发者生态的差距。

SAEP 采取当前机制，也可以放在这层背景下理解。

逐一等待开发者主动接入，边界更清楚，速度也更慢；公示期结束后逐步扩大 GUI 操作范围，可以让豆包更快获得覆盖，但也把如何取得同意变成了一个必须回答的问题。

手机 Agent 很难停在少数几个 App 里。能调用的服务太少，它就会退回一个会回答问题、却办不了多少事的助手。豆包需要尽快证明，用户愿意把一件完整的事情交给它。只有这件事成立，手机、飞书、豆包工作和火山引擎才可能从产品组合连成一套新的入口。

当 Agent 只负责回答问题，错误的代价通常只是一段不准确的文字；当它开始发消息、下订单、调用账户和处理工作，平台分发的已经是行动，责任也随之而来。

这也是豆包手机与飞书权限体系最终指向的同一个问题。

Agent 进入真实场景后，平台要证明它能把事情做完，也要说明它凭什么进入，以及谁为结果负责。

【版面之外】的话：

移动互联网把服务装进一个个 App，用户自己在 App 之间选择。

Agent 想接过这段路，把用户的一句话分发给不同服务。入口因此前移，责任也随之移动。

豆包手机还在敲门。门可以交给 AI 来开。但门后的责任，还是要有人接住。