豆包手机再度登场。

今日，努比亚 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 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氪经授权发布。