豆包手机重构GUI操作：AI智能体陷入权限困局

努比亚 NaviX Ultra 正式发售，搭载了豆包手机助手的消费者版本。

去年，豆包手机曾尝试让 AI 识别屏幕、模拟点击，甚至跨 App 自动完成任务。用户只需一句话，AI 负责找页面、填信息。这种高效率的交互很快触碰到了 App 原有的安全与商业边界，在缺乏成熟规则的情况下草草收场。

一年后，豆包并没有放弃这项极具争议的能力。

图形用户界面（GUI）自动化操作被保留并置于 Beta 状态；与此同时，《屏幕自动化操作声明协议》（SAEP）正式上线并进入 30 天公示期。对开发者而言，这更像是一份来自流量入口方的规则通知。

豆包手机重返 App 背后，暴露出一个深层问题：一个 App 允许 AI 智能体进入，究竟该允许它做到哪一步？

AI 进驻 App，双轨并行的规则困局

传统软件的互联依赖开发者主动开放 API 接口。App 决定权限范围，外部调用方按规矩请求。

GUI AI 智能体则绕过了这一繁琐的逐一适配过程。它直接识别屏幕界面、寻找按钮模拟操作。这让 AI 能够迅速覆盖海量应用，却也让原有的风控边界变得模糊。开发者无法预测 AI 会点进哪个页面，仅凭单一的用户授权，难以判断操作是否符合自身的风控与交易规则。

豆包目前推进着两条连接路径：

1. MCP（模型上下文协议）：开发者将搜索、查询、下单等功能封装为标准化工具，主动交由 AI 智能体调用。这种模式更安全稳定，责任边界清晰，但生态适配周期极长。
2. SAEP（屏幕自动化操作声明协议）：针对未适配 API 的大量应用，界定 GUI 智能体何时可以进入界面、能操作到何种程度。其覆盖速度极快，但需要处理复杂的权限博弈。

两条路线并行，反映出当前 AI 手机的现实诉求：若一味等待每个 App 接入原生接口，AI 助手的扩展速度将被生态严重拖累；让 AI 先学会像人一样操作屏幕，成为唯一的过渡方案。

“未拒绝即同意”背后的权限颗粒度

这次规则变化的关键，在于“同意”究竟如何确立。

SAEP 协议设立了 30 天公示期。在此期间，豆包仅操作系统应用、字节系应用以及主动确认同意的第三方 App，其余默认不操作。但公示期结束后，未明确发函拒绝的 App 可能被逐步纳入操作范畴；只有主动拒绝的应用才会被彻底排除。

头部应用拥有完备的法务与技术团队评估风险，而大量长尾应用往往缺乏响应能力。没有回复，未必代表接受，更可能是尚未评估自动化操作可能带来的账号风险与交易纠纷。

更为核心的痛点在于权限粒度。以整个 App 为单位进行“允许”或“拒绝”，对 AI 智能体而言过于粗放：

• 在电商软件中，搜索商品、读取历史订单与完成资金支付，其风险完全不在一个层级。
• 在办公协同软件中，查阅公开文档与调取核心商业机密，显然不能共用同一个开关。

AI 智能体亟需一套任务级权限系统：哪些内容可读，哪些页面可点，哪一步必须触发用户二次确认，授权何时可以单次撤销。操作系统原有的 App 级权限管理，必须进化为对“代表用户行动之代理权”的细分监管。

字节跳动的野心：从内容分发走向任务分发

在豆包手机发售前夕，飞书发布 8.0 版本，全面与“豆包工作”原生融合。企业内部文档、表格、日历和审批全面向 AI 开放。飞书具备天然的组织权限架构，员工看不到的数据，AI 同样受限，行为可追溯。

豆包手机面对的环境则复杂得多。手机内的应用相互隔离，各有一套账户体系与风控规则。豆包手机若想跨应用办事，必须突破这些壁垒。

飞书与手机助手是字节跳动的两块试验田：一个在组织内验证上下文与安全授权，一个在消费端验证用户是否愿意让 AI 代替自己操作。过去，移动互联网是用户在 App 之间寻找功能；而在 AI 时代，用户只需表达意图，AI 负责调度服务与交付结果。

字节跳动擅长内容分发。到了 AI 时代，它试图把这种分发能力升级为“任务分发”。

在模型端，字节强调长期主义与延迟满足；但在产品落地端，节奏却在全面提速。用户形成让 AI 代办任务的习惯尚需时日，谁先占据入口，谁就能在未来的服务生态中掌握话语权。

门可以先由 AI 推开，但门后的责任与安全机制，依然需要一套清晰严密的权限框架来接住。