豆包手机助手消费者版发布：首款量产 AI 智能体手机 9 月 16 日开售

一、先把时间线钉准

2026 年 9 月 14 日，字节跳动正式发布豆包手机助手消费者版。两天后的 9 月 16 日 14:00，首发机型努比亚 NaviX Ultra 正式发布并开售，被多家媒体称为「全球首款 AI 智能体手机」。硬件由中兴努比亚与字节联合研发。

这里有个容易被写错的地方：发布与开售是两个动作。9 月 14 日发布的是助手与配套协议，9 月 16 日开售的是硬件。追热点的稿子经常把两者揉成一句话，读者一旦去查就会觉得不对。

热度数据也要用可核实口径。中兴通讯终端事业部总裁倪飞在 9 月 14 日透露京东预约量已超 30 万台；9 月 15 日 9:30 京东平台数据显示预约量突破 36 万台。候选摘要里流传的「31.6 万」在公开报道中查不到，写作时不建议采用。同时需要说明：预约不收钱、随时可退，更接近意向数字，反映的是关注度而非销量。

对开发者读者来说，更值得关注的参照系是上一代。2025 年 12 月 1 日，一代努比亚 M153 工程样机发布，16GB+512GB 定价 3499 元，首批备货约 3 万台，京东天猫开卖当日售罄（有报道称 17 秒内），且官方售罄后未追加物料采购，成了事实上的「创始限量版」。后果是二手全新未拆封报价普遍到 5599—7999 元，个别最高报到 3.6 万元，还催生了数百至上千元一天的租赁生意，后期回落到 4000—4500 元成交。

二代备货量的报道口径不一（约 20 万台 / 首批 8—10 万台 / 总量 50 万台），但无论取哪个，相比一代的 3 万台都是数量级跃升。备货量本身就在说明字节对这次「转正」的把握程度——一代是试探，二代是量产。

二、技术拆解：一个 GUI Agent 的能力清单

消费者版相比去年底的技术预览版，官方强调的是「稳定性」与「日常可用性」。功能上可以拆成四块：

多模态唤醒。 语音唤醒之外，还有一个带指纹鉴权的专属 AI 键。这个设计有意思的地方在于它同时是入口和授权点——按下去这个动作本身携带了生物特征验证，等于把「唤起助手」和「授权助手」合并成一次交互。

屏幕问答。 结合当前屏幕画面直接处理任务，这是 GUI Agent 的典型形态：不依赖应用提供 API，而是看懂屏幕上有什么，然后决定点哪里。

本地记忆与检索。 覆盖电话、相册、短信、便签等，以用户主动授权为前提，录音可接入飞书妙记做转写与整理。

任务执行。 跨度从打车下单这类垂直场景，到「操作手机 Beta」这种通用路径。

真正需要开发者注意的是权限从哪来。传统 App 交互里，权限边界由系统 API 划定，粒度是「读通讯录 / 读写存储 / 定位」。GUI Agent 绕开了这套 API 契约——它通过视觉理解加模拟点击操作界面，本质上是以「用户本人」的身份在操作，系统层面的权限模型对它几乎不设防。这就是智能体手机把权限边界问题推到台前的原因。

三、SAEP：把拒绝权交回给第三方

SAEP，屏幕自动化操作声明协议。这是这次发布里最有信息量的一块，因为它是对上一代踩坑的直接回应。

先看因果链条。2025 年 12 月技术预览版推出后，微信弹出「登录环境异常」提示，随后淘宝、支付宝、闲鱼、高德、大麦、美团、拼多多等应用在不同时点跟进限制，出现登录受限、AI 操作无法继续的情况。12 月 5 日，官方下线了微信相关操作、AI 代打游戏、电商激励任务等核心功能。争议的核心被概括为：AI 助手可能绕过广告、会员引导、数据埋点，干扰第三方应用的商业逻辑。

SAEP 就是在这个背景下出台的。媒体普遍把它概括为「第三方可拒绝 AI 操作」，但更精确的机制不是「可拒绝」，而是默认不操作、主动声明才开放：

• 30 天公示期内，应用默认不会被 GUI 智能体操作，除非主动声明接受；
• 若未通过邮件或协议拒绝，公示期后才开放操作能力；
• 开发者有两条拒绝通道：回邮件到 o-feedback@mail.doubao.com，或走 SAEP 协议声明，两种声明均长期有效。

默认 opt-in 而非 opt-out，这个取向值得单独拎出来说。放在 GUI Agent 的能力语境里，「默认可操作、应用自己来拒绝」和「默不可操作、应用自己来开放」是两种完全不同的责任结构。前者把成本压给应用（你得盯着，不然就被自动化了），后者把成本压给助手厂商（你得等，不然就没法演示）。字节选了后者。

第二个值得说的是权限颗粒度下沉到页面级 / 业务环节级。这不是普通的白名单——白名单的粒度是「应用是否允许被操作」，SAEP 的粒度可以细到具体页面与业务环节。官方给的例子包括：

• 可禁止登录页面的截图和模拟输入；
• 可允许助手辅助编辑内容，但限制其完成最终发送或发布；
• 签到、抽奖、秒杀、积分及奖励领取等也在可限制范围内。

最终能否执行，需要结合助手身份 + 系统安全基线 + 应用声明 + 用户授权四方共同判断。这里有一条关键约束：应用声明允许不代表可以跳过业务鉴权；被拒绝的操作，助手必须停止，不得换用其他通道绕过。同时设计了操作日志查询机制，第三方可追溯助手的操作目标、决策与执行结果。

下面这段是按官方描述整理的示意性判定结构，不是官方 schema 原文，只用来帮助理解四方判定的组合关系：

def can_execute(action, page, app, assistant, user) -> bool:
    """四方判定：助手身份 + 系统安全基线 + 应用声明 + 用户授权。
    任一环节否决即拒绝，且不允许换通道重试。"""

    # 1. 系统安全基线（平台底线，不可被应用声明或用户授权突破）
    if action.target in SYSTEM_FORBIDDEN or page.is_secure_input:
        return False

    # 2. 应用声明：默认不存在声明 == 默认不允许
    decl = app.saep_declaration  # None 表示未主动开放
    if decl is None or not decl.supports_assistant(assistant.identity):
        return False

    # 3. 页面级 / 业务环节级限制
    if page.id in decl.denied_pages:
        return False
    if action.is_final_submit and not decl.allow_final_action:
        # 例：允许辅助编辑，但不允许替用户点击「发布」
        return False

    # 4. 用户授权（最小必要 + 自主控制）
    if action.scope not in user.granted_scopes:
        return False

    return True


# 被拒时的正确行为：停止，并记录，而不是绕道
if not can_execute(action, page, app, assistant, user):
    audit_log.record(target=action.target, decision="denied", reason=...)
    raise AssistantRefused("declaration denies this action")  # 禁止 fallback 到其他通道

四、MCP 与 SAEP 是双轨，不是替代

开发者容易把 SAEP 和 MCP 混为一谈，实际上两者管的是不同的事：

	MCP	SAEP
管什么	应用主动开放接口给模型调用	读屏 + 模拟点击能做到哪一步
谁发起	应用侧开放能力	助手侧声明边界
形态	工具调用	权限声明 + 日志追溯

换句话说，MCP 是「我愿意给你一条正规通道」，SAEP 是「你不走正规通道、非要读屏点按钮时，我允许你点到哪」。两条路并存，一个应用完全可以开放 MCP 接口、同时用 SAEP 声明拒绝 GUI 自动化。

对应用开发者来说，这意味着接入决策变成一个二维选择：开放接口能换来助手场景的流量，而允许 GUI 操作则要评估自身商业逻辑是否会被绕过。SAEP 至少把这个选择权显式化了。

五、对比：苹果把模型当 App 卖，字节把 Agent 装进硬件

同一个「开放 vs 封闭」问题，两家给出了完全相反的答案。

苹果在 iOS 27 推出 Extensions 系统，让用户自选调用 Google Gemini、Anthropic Claude 或 ChatGPT，终结 ChatGPT 自 iOS 18 起的独家整合；WWDC 2026 前后相关设置页已出现在测试版中。有分析认为苹果可能对 Siri 入口抽取 15%—30% 订阅分成，实质是再造一个「AI App Store」。这里有个容易被带偏的技术澄清：苹果并非直接使用 Gemini 产品，而是用 Gemini 训练自研第三代 Apple Foundation Models（AFM 3，共 5 个模型，含 30 亿参数端侧到云端 Pro 版），Federighi 称「我们使用的 Google 助手部分，是零」。

字节走的是垂直自研加硬件绑定。模型不在应用商店里被挑选，而是长在特定机型上；能力不通过 API 暴露，而是通过屏幕理解和模拟点击落进既有应用。前者把模型当商品，后者把 Agent 当系统能力。

两条路线的治理难点也不一样。苹果的模式里，模型厂商与应用商店的分成、审核、责任归属有既有的 App Store 框架可以套用；字节的模式里，助手要操作的是别人的应用，而它自己既不是系统方也不是应用方，只能靠 SAEP 这类协议去协商——这正是 SAEP 必须存在的原因，也是它与纯软件 Agent 最大的区别。

顺带记一条可用的合规细节：官方口径称数据处理遵循「最小必要」与「用户自主控制」原则，采用端云结合方案，对可操作范围分层分级管理。公开的合规资质包括 ISO 27001、ISO 27701、ISO/IEC 42001 及等保三级。其中 ISO/IEC 42001 是 AI 管理体系认证，在国内消费级 AI 产品里披露得并不多。

六、SAEP 的边界，以及接下来该盯什么

把治理意义写足，也要把边界写清楚，否则文章站不住：

其一，SAEP 由字节自行制定维护，不是行业标准组织的产物。 如果只停留在豆包生态内部，它至多算一份企业自律规范；只有其他主流 AI 助手厂商与应用商店兼容采纳，才有可能进化为行业标准。

其二，它尚未触及深层配套。 增量收益分成、用户授权透明化、争议行为的责任归属，这三件事目前都没涉及。声明颗粒度怎么统一、拒绝清单是否公开等细则也未公布。

其三，公示期机制的长期效果待观察。 30 天公示期 + 默认不操作，在冷启动阶段是稳妥的；但如果大多数中小应用既不拒绝也不声明，实际结果会是什么，还需要看真实数据。

对开发者而言，接下来值得盯的三个点：一是头部应用里有多少会公开声明拒绝，这份清单本身就是行业态度的读数；二是操作日志查询机制的开放程度，第三方能否真正追溯；三是如果没有其他厂商跟进，SAEP 会不会变成豆包生态的私有规范——那它的意义就从「规则」退回到「产品文档」了。

工具能力会被追平，权限边界不会自动收敛。智能体手机真正的分水岭，不在于助手能操作多少个 App，而在于有多少 App 愿意让它操作——SAEP 是这个问题第一次以成文规则的形式被摆到台面上，9 月 16 日开售之后，它会拿到第一份真实样本。