GUI 智能体撞上应用边界
9 月 14 日，豆包手机助手消费者版本正式发布，与去年底的技术预览版相比，这一版更强调稳定性与日常可用性。「操作手机」这项能力以 Beta 形式开放，配合的是一份名为 SAEP 的屏幕自动化操作声明协议，即 Screen Automation Execution Protocol，并从发布之日起进行为期 30 天的规则公示。
这份协议要解决的是一个此前真实发生过的问题。2025 年 12 月技术预览版推出后，部分应用出现登录受限、AI 操作无法继续的情况；当时产品方下线了对部分应用的操作能力，登录限制解除并不等于恢复代操作。这件事暴露了一个结构性矛盾：手机 GUI 智能体「看着屏幕替用户操作」的能力，落在应用开发者眼里，是一次由外部程序发起的、非用户手动的界面操作。
把选择权交给应用，是这份协议的核心决定。第三方应用可以自主声明是否接受 AI 助手在本应用内执行屏幕自动化操作，声明渠道包括接入 SAEP 协议或回复官方沟通邮件。
授权不是一个开关，而是三层与多档
细看规则会发现它并非简单的允许或拒绝。按协议设计，最终能否执行一项操作，需要结合四件事共同判断：助手身份、系统安全基线、应用声明，以及用户授权。应用声明允许，并不代表可以跳过业务鉴权。
应用侧还可以对具体操作类型单独设限。官网接入文档给出了几种粒度：可以禁止登录页面的截图与模拟输入；可以允许助手辅助编辑内容，但限制其完成最终发送或发布；签到、抽奖、秒杀、积分与奖励领取也被列入可限制范围。这种把「读屏」「输入」「改内容」拆开授权的做法，比单一开关更贴近真实风险的分布——多数人担心的不是助手看懂页面，而是它在用户没看清的情况下把内容发了出去。
协议还写了两条约束。对被拒绝的操作，助手应停止执行，不得换用其他通道绕过；需要用户确认或接管时，确认只覆盖界面展示的具体步骤。后一条针对的是一类常见偷懒：把某个大动作拆成若干小步骤，用一次授权撬动整条链路。
公示期的两个方向
时间维度上，规则被分成两段。公示期内，豆包手机助手仅对系统自带应用、字节跳动旗下应用，以及已通过 SAEP 或邮件明确同意接入的第三方应用执行自动化操作，其余应用默认不操作。开发者提交拒绝声明后，相关应用会被列入不可操作清单。
公示期满后的规则方向相反：若开发者既未通过官方渠道声明拒绝，也未配置禁用策略，系统将按应用风险层级逐步开放该应用的 GUI 自动操作能力。明确表示拒绝的应用则始终不在操作范围内。
这两段规则的差别值得单独指出。前半段是「明示同意才开放」，后半段是「未拒绝即按风险开放」。对开发者而言，沉默的含义会在 30 天后发生改变；对用户而言，可操作范围会在同一时点扩大。这也是公示期的实际作用——它把变化提前告知，而不是在切换当天通知。
可追溯性：操作日志向第三方开放
协议中一项容易被忽略但结构意义较大的设计，是操作日志查询机制。第三方应用可以查看与自身相关的操作记录，追溯助手在应用内的操作目标、决策与执行结果。
这条设计把审计能力从平台侧单向持有，变成了应用侧也能核对的账本。对开发者来说，这意味着出现争议时不必完全依赖平台提供的事实认定；对平台来说，这也是一种成本更高的透明承诺，因为日志一旦可被外部查阅，任何不一致都会暴露。
同一份文档也说明了这项能力的边界：意图级限制是否具备完整的系统强制执行能力，取决于目标版本。这句话需要认真读——它承认了在不同版本上，限制的执行强度存在差异。限制写在文档里与限制被系统强制执行，是两件不同的事。
声明权外移，责任也外移
把声明权交给应用方，效果并不全是分散风险，它也重新分配了责任。允许自动化操作，意味着把界面的一部分交给外部助手；拒绝自动化操作，意味着放弃 AI 代办的入口。相应的，用户投诉与数据责任也随之留在应用方一侧。这是一个对称的交换，谈不上谁占便宜，但它改变了博弈的起点：应用方需要在「接入带来的便利」与「接入带来的责任」之间做判断，而这个判断没有标准答案。
对中小开发者来说，这类判断往往更难做。拒绝的代价是用户在助手场景里用不到你的服务；接受的代价是要为自己的界面被自动化操作之后的一切后果负责，而自动化操作的执行质量并不由自己控制。协议提供了细粒度设限作为中间态，这大概是当前最实用的选项。
落地现状与实测观感
9 月 16 日，搭载这一版本豆包手机助手的努比亚 NaviX Ultra 正式开售。多家媒体在真机上做了实测，尝试通过助手在微信、小红书、美团、淘宝等应用内完成发帖、下单外卖、网购等操作，暂时均无法实现，而字节系产品可以优先调用。
这个结果与协议规则一致，也说明一个容易误读的细节：当下部分应用无法由助手操作，并不一定代表开发者已经明确拒绝接入，也可能只是尚未完成主动同意适配的流程。官方未公布已接入 SAEP 协议的第三方应用名单。
另一处需要留意的信息是努比亚作为硬件合作方承担研发设计与生产制造，软件与模型能力来自豆包一侧，手机生产与销售由努比亚承担。这个分工决定了协议的执行边界：能操作哪些应用由软件侧的系统与协议决定，而系统层面的权限基线则依赖于硬件侧的实现。
需要继续观察的三个问题
想要判断这套设计能否成为其他厂商的参考样本，有三个问题值得跟踪。其一是 30 天公示期结束后的实际开放节奏：是按应用逐个评估风险层级，还是按类别批量开放，两者的治理成本差别很大。其二是意图级限制的执行强度在不同系统版本上的落地情况，这决定了开发者设下的限制是硬约束还是软约定。其三是投诉与责任的判例，尤其是当自动化操作在用户确认范围之外造成损失时，责任如何在应用、平台与用户之间划分——目前尚无公开案例。
把范围再放大一些，这套协议的思路对其他端侧智能体同样有参照价值。当智能体的操作对象从自家系统延伸到第三方软件，授权就不再是模型能力问题，而是界面归属问题。谁拥有这个界面，谁就该拥有否决权，这个原则比任何技术方案都更接近问题的本质。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
结语
这份协议最值得记住的不是它的名字，而是它把一个长期被含糊处理的问题摆到了台面上：智能体替用户操作第三方应用时，界面到底属于谁。它给出的答案是把否决权前置给应用方，代价是责任同步前移。这套设计未必是终局，但它至少让「默认不操作」成为公示期内的起点，而不是让「默认全开放」成为既成事实后，再回头去补授权。