豆包开启屏幕自动化？为什么众多 App 纷纷拒绝授权

豆包开启屏幕自动化？字节跳动旗下豆包手机助手于 2026 年 10 月 14 日结束了其屏幕自动化执行协议（SAEP）为期三十天的公开征求意见期，正式启动了“默认允许”策略，允许 AI 智能体在未拒绝的第三方安卓应用中自动执行屏幕操作。然而，首批 151 款应用（并在 10 月 14 日迅速更新至 153 款）正式登记拒绝授权自动化图形操作。其中，腾讯旗下的 65 款应用和阿里旗下的 23 款应用领衔，约占更新后拒绝名单的 57.5%。随着自主式人工智能从云端聊天界面向设备端执行演进，这种对峙凸显了在平衡用户主导的任务自动化与应用安全边界、商业模式及反爬虫/反作弊保护时所面临的复杂技术与治理挑战。

时间线与背景演进：SAEP 的推出与应用拒绝潮

核心要点

豆包手机助手于 2026 年 10 月 14 日结束了为期 30 天的 SAEP 公示期，并开始向未声明拒绝的第三方安卓应用分阶段推出 GUI 自动化功能。
10 月 14 日，拒绝名单从最初的 151 款应用扩大至 153 款，其中腾讯和阿里系软件占了 88 条，约占名单的 57.5%。
该协议规范了支持智能体的智能手机上的图形自动化，为跨应用任务建立了声明与审计机制。

端侧人工智能的演进迅速从对话式文本辅助转向图形用户界面（GUI）自动化。GUI 智能体无需等待第三方服务开放定制的 API 接口，而是通过计算机视觉解析屏幕上的视觉元素，解析交互控件并执行合成触摸和键盘输入。理论上，这种兜底能力允许助手代表用户在传统应用或未集成应用中完成跨应用工作流。

为了规范这些自动化交互，字节跳动推出了屏幕自动化执行协议（SAEP），作为移动端 GUI 智能体的声明框架，正如官方的豆包 SAEP 开发者文档中所详细说明的那样。在此框架下，开发者可以在包级别、特定 Activity 级别或功能意图级别定义外部智能体是否可以与应用进行交互，从而为身份验证屏幕或财务结账等敏感交互建立边界。

豆包手机助手官方宣布屏幕自动化执行协议 SAEP 结束公开征求意见期

在始于 2026 年 9 月 14 日的为期三十天的公示期内，该助手严格在系统工具和明确选择接入的应用上运行。当该期限于 10 月 14 日结束时，该框架过渡到拒绝模式：未正式注册拒绝的应用进入了自动化 GUI 执行的分阶段资格管道。

与此同时，正如南方日报对 SAEP 发布的报道所报道的那样，字节跳动公布了最初的 151 款不参与应用名单，该数字在当天晚些时候更新为 153 款。该注册表涵盖了主流消费服务，包括微信、QQ、淘宝、支付宝、美团、拼多多、小红书、滴滴以及工行和招行等主要银行应用。正如新京报关于拒绝名单的报道中所述，月之暗面 Kimi 和深度求索（DeepSeek）等竞争对手 AI 应用也提交了正式的拒绝声明。

在豆包 SAEP 框架下声明拒绝的第三方移动应用官方列表

这种摩擦反映了围绕自动化设备执行的技术敏感性。在现代移动操作系统中，处理敏感金融交易或竞技游戏的应用经常监控运行时环境是否存在合成触摸事件、后台无障碍钩子或未验证的输入驱动程序。当外部软件智能体以编程方式与客户端界面交互时，客户端安全引擎可能会将该会话标记为异常执行环境，因此需要明确的协议级标准来将授权的用户协助与未验证的自动化区分开来。

技术架构：SAEP 治理与 GUI AUTOMATION 的边界

在操作系统层，围绕豆包手机助手的争议说明了结构化 API 集成与模拟图形自动化之间的工程权衡。

字节跳动围绕两个不同的层级构建其跨应用自动化策略：

结构化智能体协议（MCP 与 A2A）：首选的集成层依赖于结构化通信框架，包括模型上下文协议和智能体间标准。在这种模式下，应用通过定义的架构主动公开经过身份验证的端点。虽然结构化协议提供了可审计的数据交换，但其现实世界的安全性取决于令牌验证、加密传输和显式用户同意范围的实现，第三方采用正在逐步推进。
图形用户界面（GUI）兜底：当结构化 APIs 不可用时，助手会回退到 GUI 自动化。此路径使用显示缓冲区、光学字符识别（OCR）和程序化触摸注入来像人类用户一样浏览界面。

为了防止不受管理的屏幕抓取，SAEP 规范定义了显式策略评估管道。下图阐述了官方技术文档中概述的概念决策架构：

[ User-Authorized Agent Task ]
              │
              ▼
[ Agent Identity & Trust Verification ]
              │
              ▼
[ SAEP Policy Evaluation ]
(System Baseline + App Policy + User Authorization + Task Context)
              │
    ┌─────────┼─────────┐
    ▼         ▼         ▼
[ ALLOW ]  [ BLOCK ]  [ CALL_USER ]
    │         │         │
    ▼         ▼         ▼
[ Controlled  [ Operation [ User Takeover
  Execution ]   Blocked ]   Required ]
              │
              ▼
[ Decision & Execution Audit Logging ]

SAEP 公布的设计确立了应用策略无法削弱的系统安全基线。高风险活动（包括金融转账、账户认证、内容发布、删除和权限更改）可能需要额外的用户确认、用户接管或执行阻止，具体取决于有效策略和支持的系统版本。必须在目标构建版本上验证意图级执行的完整性。此外，该架构包含结构化日志记录，使开发者能够审计智能体请求的内容以及发生的动作。

尽管有这些记录在案的控制措施，但 153 款应用正式拒绝仍源于基本的安全和运营担忧：

UI 自动化与恶意欺诈的区别：自动触摸注入和程序化 UI 导航不同于恶意的广告点击注入或凭证撞库。然而，客户端风险引擎通常将快速的非人类触摸模式和无障碍钩子使用标记为异常行为。金融和游戏应用采用旨在保护账户完整性的敏感反爬虫/反作弊启发式算法，这使得它们对第三方自动化工具天生保持谨慎。
敏感上下文与数据保护: 捕获用于 OCR 处理的屏幕缓冲区引入了机密屏幕文本（如财务余额或私密消息）的潜在暴露风险，需要对端侧隔离进行严格验证。
商业与用户旅程考量: 围绕赞助发现信息流、开屏展示和应用内推广设计的应用依赖于直接的人类参与。行业分析师观察到，绕过中间视觉触点的自动化执行路径改变了标准参与指标和平台商业模式。

行使拒绝声明的应用类别生态系统概览

架构权衡：比较集成与状态保持模型

SAEP 框架下广泛的开发者拒绝表明，不受管理的图形自动化在安全敏感的生态系统中面临着严峻的实际限制。移动软件团队必须评估不同的架构模式，以平衡用户自动化与应用安全性。

下表比较了用于启用跨应用工作流和会话连续性的标准行业方法：

Architecture Pattern	Primary Technical Scope	Execution Boundary	Governance & Audit Mechanism
Declared GUI Automation (SAEP)	Visual screen parsing and simulated input fallback	Operates across visible UI elements via system controls	Declarative app policy files and system-level execution audit logs
Structured Agent Protocols (MCP / A2A)	Direct functional tool invocation via structured RPC	Constrained to explicitly exposed schema endpoints	Protocol-specific tokens, authorization scopes, and application permissions
OS-Level Deep Linking (Universal Links)	Standardized content routing into native mobile apps	Native application sandbox and view hierarchy	Verified domain association files and registered system URL schemes
Mobile Attribution & Parameter Recovery	Measuring user acquisition and onboarding continuity	Server-to-server endpoints and mobile SDK handshakes	Platform-supported attribution signals, SDK integration, permitted parameter association, and product-specific fraud checks

在移动归因和用户获取环境中，工程团队面临着一组不同的挑战，涉及营销活动归因、安装信号和安装后参数恢复。诸如 Adjust、AppsFlyer 和 OpoInstall 等移动归因平台在受支持的移动营销和 SDK 集成路径内运行，而不是控制第三方 GUI 自动化。

例如，OpoInstall 公开描述了移动归因、deferred deep linking、营销活动参数传递和防作弊监控功能。这些功能可以帮助发布商评估获客表现，并在支持的 Android 和 iOS 路径上恢复符合条件的上手引导上下文，前提是具备可用的归因信号、SDK 配置、平台权限和适用的隐私要求。它们不确定某项操作是否由豆包手机助手执行，不替代 SAEP 访问控制，也不独立保证所有自动化行为都能与人类活动区分开来。

工程清单：实现与审计智能体自动化策略

随着端侧 AI 助手扩展其功能，移动开发和安全团队应积极审计其应用与自动化智能体框架的交互方式。

开发者实现清单

审查 SAEP 规范和系统支持: 检查官方 SAEP 协议文档以评估与目标 Android 版本的兼容性，检查底层系统固件是否支持声明的策略端点。
通过文档架构配置 SAEP 声明: 使用从 AndroidManifest.xml 引用的文档化 JSON 架构配置 SAEP 策略声明。在依赖该策略之前，验证目标受支持系统版本上的 SAEP 可用性和特定强制执行功能。
保护敏感交易步骤: 确保财务结账、凭证输入字段和账户修改流程实施适当的认证屏障，验证关键路径是否触发用户接管或执行阻止。
审计系统接管行为: 在模拟智能体交互下测试应用行为，以验证系统在遇到用户接管阈值时是否正确暂停执行。
检查运营审计日志: 在支持的情况下定期评估决策和执行审计日志，审计注册智能体请求了哪些操作，并根据本地系统构建审查日志记录策略。

产品与治理清单

评估用户意图与安全边界: 评估用户主导的自动化是否为常规任务提供了切实便利，同时对不可逆操作保持严格限制。
评估商业触点影响: 分析自动任务完成是否会影响所需的广告曝光、上手引导流程或法律披露。
监控官方拒绝注册表: 对于选择退出的团队，验证是否在记录在案的三个工作日窗口内提交了正式拒绝声明并反映在平台注册表更新中。

常见问题 (FAQ)

什么是屏幕自动化执行协议 (SAEP)？

SAEP 是字节跳动为豆包手机助手引入的声明式框架。它为第三方 Android 应用提供了一个标准化机制，以声明端侧 AI 智能体是否可以与其用户界面进行交互以及交互的程度。该协议评估智能体身份、系统安全基线和应用特定策略，以返回诸如 ALLOW、BLOCK 或 CALL_USER 等执行决策。

为什么 153 款应用正式拒绝了豆包的屏幕自动化？

应用提交拒绝声明是由于安全性、隐私和运营因素的结合。虽然 GUI 自动化专为授权的用户任务而设计，但合成触摸输入可能会与银行和游戏应用中的反爬虫/反作弊启发式算法发生意外交互。此外，开发者还提出了关于敏感屏幕上数据保护、交易责任以及核心商业用户旅程保留的考量。

MCP 与 GUI 自动化之间有什么技术区别？

模型上下文协议 (MCP) 使用结构化、可审计的 API 端点，应用通过预定义的架构公开特定数据和工具。相比之下，GUI 自动化是一种视觉兜底机制，它通过 OCR 读取屏幕像素并注入合成触摸输入，直接与应用界面交互，而无需自定义 API 端点。

公示期结束后，SAEP 的退出机制如何运作？

尽管最初的三十天公开征求意见期于 2026 年 10 月 14 日结束，但 SAEP 框架仍维持着持续的退出渠道。开发者可以随时通过技术配置或平台应用表单提交拒绝声明。平台在三个工作日内处理请求，并在每周三定期更新官方拒绝注册表。

实践启示与未来展望

行业对豆包手机助手 SAEP 推广的反应凸显了普适计算的一个决定性挑战：用户主导的任务自动化无法绕过现代应用生态系统的安全和商业架构。虽然多模态模型在技术上可以解释并与任意图形界面交互，但企业软件在授予执行访问权限之前需要明确的同意、可验证的身份和清晰的责任边界。

对于移动开发者和安全架构师而言，前行的道路在于结构化、协议级别的合作，而不是不受管理的视觉模拟。虽然 GUI 自动化为简单的实用任务提供了临时兜底，但持久的企业集成将越来越集中于经过身份验证的智能体协议、显式权限范围和强大的服务端状态保持。今天建立清晰意图声明的工程组织，将最有能力在新兴的智能体经济中平衡自动化便利性与严格的数据保护。