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

豆包手机再度回归市场。

今日，努比亚 NaviX Ultra 正式开售，其中预装了面向消费者的豆包手机助手。

去年，豆包手机实现了AI对手机屏幕的识别、模拟点击操作以及跨应用任务执行。用户只需一句话，AI便会自动寻找页面、填写信息并完成操作。

用户虽然获得了效率提升，但技术很快遇到了现有App的交互限制。由于规则未能同步更新，最终只能仓促收场。

经过一年时间，豆包并未放弃这一最具争议性的能力。

图形用户界面操作功能得以保留，但被归入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 Agent能否进入界面以及操作程度的边界问题。

前者更稳定，也更容易明确责任；后者覆盖速度更快，但需处理更复杂的权限关系。

两套机制并行，反映了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来开。但门后的责任，还是要有人接住。

本文来自微信公众号“版面之外”，作者：画画，36氪经授权发布。