155款App拒接豆包SAEP协议：AI智能体与超级App的流量与隐私博弈

事件概述

2026年10月14日，字节跳动旗下豆包手机助手官网公布了《屏幕自动化操作声明协议》（SAEP, Screen Automation Execution Protocol）公示期结束后的结果名单。共有155款主流应用明确拒绝接入该协议，涵盖社交、电商、金融、游戏等高频场景。其中腾讯系应用66款占比最高，阿里巴巴系23款紧随其后，京东和百度系基本未出现在拒绝名单中。

这一事件标志着AI智能体（Agent）在尝试通过“看屏操作”替代用户直接交互时，遭遇了来自互联网巨头构建的生态壁垒的强力阻击。这不仅是单一产品的适配问题，更揭示了AI技术重塑移动互联网权力结构的深层矛盾。

核心信息

1. SAEP协议的技术逻辑与局限

SAEP是字节跳动为规范GUI Agent（基于图形用户界面的智能体）操作而制定的行业标准。其核心设计包含三层机制：

• 边界声明：允许第三方应用声明哪些页面或操作允许Agent访问，哪些敏感页面（如支付、登录页）禁止代理。
• 策略裁决：由系统综合Agent身份、安全基线及应用声明进行最终决策，对支付转账、账号认证等高风险动作默认限制。
• 系统级约束：将应用声明的策略以系统层面强制执行，防止被轻易绕过。

尽管SAEP试图通过“先打招呼后上车”的方式解决合规问题，但由于GUI模式本质上是模拟人类点击，AI仍需读取屏幕内容，这引发了应用方对流量入口丧失和数据隐私泄露的担忧。

2. 冲突根源：流量入口权与隐私安全

应用集体拒绝的核心原因可归结为两点：

• 流量劫持风险：GUI Agent直接接管用户操作，使得超级App沦为后台执行工具，平台首页推荐、广告位及用户停留时长等核心价值被架空。例如，用户通过AI直接下单购买T恤，无需经过淘宝首页浏览，导致平台失去交叉销售机会。
• 隐私安全隐患：GUI操作需要将屏幕图像上传至云端供AI识别。腾讯创始人马化腾曾公开批评此类录屏传云端的操作方式极不安全且不负责任，认为其类似黑产外挂行为。

3. 技术路线分化：GUI vs MCP+A2A

不同技术路线导致了截然不同的生态待遇：

• 豆包手机（GUI为主）：激进采用视觉识别与模拟点击，虽体验流畅但缺乏应用配合，导致被广泛拉黑。二代产品虽转向“协议优先”，但仍保留GUI兜底，受限于应用封锁，目前主要只能调用字节系和中兴系应用。
• 阶跃星辰 STEPX Neo（MCP+A2A）：采用模型上下文协议（MCP）和智能体对智能体通信（A2A）标准，让App主动开放API接口。这种方式下，应用能精准控制数据开放范围，因此已与支付宝、腾讯、携程等近百家企业合作，获得大量“通行证”。

4. 全球性结构矛盾

此类冲突并非中国独有。Meta推出的个人智能体Muse在美国上线仅13天，即被亚马逊切断购物通道。亚马逊理由包括：Meta未事先告知Muse将访问其平台、Muse浏览网页时不亮明身份、存在安全与隐私透明度问题。这与国内App拒绝豆包的理由高度一致，均指向AI试图充当用户与应用间“中间商”所引发的利益重构阻力。

值得关注

• 生态闭环的强化：大厂可能倾向于开发自有个人智能体（如阿里千问Go!、腾讯元宝），在自家生态内实现无缝协同，但跨生态协作依然困难。未来可能出现“每个大厂拥有独立AI助手，互不兼容”的局面。
• 体验上限的权衡：MCP+A2A路线虽获应用方欢迎，但其能力上限取决于各App愿意开放的接口深度。复杂跨应用任务（如跨平台比价、多步流程自动化）的实现难度远高于GUI模式。
• 行业博弈长期化：SAEP协议的推出仅是起点。AI智能体要真正翻越互联网围墙，需在权限细化、责任划分及利益分配上与开发者达成新的平衡。短期内，超级App的护城河难以被彻底击穿。