ARTICLE · 1185793

155款App拉黑豆包手机:大厂怕的不是AI乱花钱,而是AI不看广告

发布时间：2026-10-15 13:30:35 最近访问：2026-10-15 13:30:36

10月14日，字节跳动旗下的豆包手机助手在开发者平台发布了一则公告，宣布《屏幕自动化操作声明协议》（SAEP）为期30天的公示期正式结束，接下来将向未声明拒绝的第三方应用逐步开放屏幕自动化操作权限。伴随这则公告一起出来的，是一份明确说“不”的应用清单。10月14日下午媒体首批披露的拒绝接入应用是151款，到了当天下午4点，官方动态更新的清单已经增加到了155款。

如果你手头刚好有一台搭载豆包手机助手的努比亚M153工程机，或者9月16日刚发售的消费者版努比亚NaviX Ultra，这份清单意味着一个挺尴尬的现实：你依然可以像用普通手机一样，手动点开微信聊天、打开淘宝买东西、用美团点外卖，但这款手机最核心的卖点——让AI助手看着屏幕、代替你的手指跨应用自动办事——在微信、QQ、淘宝、支付宝、拼多多、美团、快手、小红书乃至DeepSeek和Kimi这155款日常最高频的软件里，被彻底按下了暂停键。

这几天我看了不少围绕这件事的讨论，绝大多数分析都把原因归结为安全与风控：社交软件怕隐私泄露，电商和支付平台怕AI大模型产生幻觉乱下单、转错账，游戏公司怕自动化脚本变成外挂。这些理由听起来非常合乎常理，作为常年跟软件系统和AI Agent打交道的人，我也完全理解安全基线的重要性。但当我顺着豆包官方公开的《SAEP应用开发接入文档》把技术条款从头到尾翻了一遍之后，我发现事情并没有表面上谈论“安全防御”那么简单。

豆包明明递出了“只逛街不付款”的安全锁，大厂为什么不接？

如果各大互联网平台仅仅是担心AI助手操作失误带来资金风险、隐私泄露或者被黑产用来薅羊毛，它们其实完全没有必要把豆包手机助手直接拒之门外。

仔细看豆包这次拿出来的SAEP协议就会发现，为了打消应用开发者的安全顾虑，字节跳动的工程师在协议里设计了一套颗粒度极细的“安全妥协方案”。首先在系统基线层面（文档第2.3节），豆包默认就禁止了AI助手代填密码、代确认支付以及删除核心数据等高危操作；其次在权限声明机制上（文档第4.3节），协议支持按应用级（app）、单页面级（activities）和单意图级（agent_intents）三个维度来做精细化管控。

说得具体一点，一家电商或内容平台如果觉得全局开放风险太高，完全可以使用协议提供的细分限制项：比如在私密聊天页或账单页开启 screenshot_disable（禁止截图读取），在涉及交易激励的页面开启 account_incentive（禁止AI自动签到、领券、秒杀和抢红包），或者使用 post_content 限制项，允许AI帮用户搜索商品、比价、把东西加进购物车，甚至帮用户起草好一篇笔记，但锁死最后一步的“提交订单”和“确认发布”，必须由真人亲手点击才能生效。甚至考虑到开发者改代码发版嫌麻烦，豆包还提供了免开发的线上填表配置通道。

把这套技术方案和最终那155款应用的反应放在一起对比，真正耐人寻味的地方就出来了。

在155款拒接名单里，工商银行等多家商业银行、三大电信运营商、支付宝，以及萤石旗下的7款智能家居安防应用和《王者荣耀》等竞技游戏，直接选择最高级别的 global_disable（应用级全局禁用），这在逻辑上是完全站得住脚的。金融与通信基础设施受制于严格的监管合规与实名风控，智能家居涉及物理门锁与摄像头安全，而竞技手游对任何“非真人操作”都是零容忍——就在今年9月底，部分努比亚NaviX Ultra用户登录《王者荣耀》时就因为系统内置豆包助手触发了“环境异常”提示并被强制下线。对这些应用来说，安全边界就是0和1的关系，不存在折中空间。

但问题在于，淘宝、天猫、盒马、美团、大众点评、拼多多、小红书这些主打商品交易与生活内容的商业平台，为什么同样无视了“页面级”和“意图级”的局部安全锁，齐刷刷地选择了整包拉黑？如果它们怕的只是AI乱花钱，把支付页面锁死、只让AI帮用户逛街比价，交易安全明明就已经保住了。

如果AI替用户省掉了“往下刷”的过程，平台的过路费找谁收？

把“安全风险”这层窗户纸捅破之后，剩下的其实就是移动互联网最底层的商业模式冲突。对于电商、本地生活和内容社区这类超级App来说，哪怕AI助手能够做到100%不买错东西、100%由用户本人完成最后一步付款，只要它接管了前面“搜索、筛选、比价、浏览”的过程，平台的商业根基就会受到直接冲击。

我们可以还原一下普通人平时点外卖或者网购的真实路径：当你打开美团或者淘宝，先会看到几秒钟的开屏广告；输入关键词搜索之后，排在前几位的往往是购买了竞价排名的推广商家；你在往下滑动、点进三四家店铺对比价格和评价的过程中，信息流里还会穿插着算法推荐的关联商品和促销活动。

在过去十几年里，国内互联网大厂之所以能建立起庞大的商业帝国，核心收入来源并不是向用户收软件使用费，也很少单纯依赖微薄的支付通道费，而是靠商家为了争夺用户注意力所支付的“过路费”——无论是淘天集团财报里的客户管理收入（CMR），还是美团、拼多多、小红书财报里占比极高的在线营销服务收入，本质上都是建立在“用户必须亲自打开App、亲自花时间往下刷”这个交互摩擦力之上的。

现在，假设淘宝和美团接受了豆包SAEP协议里“只浏览不付款”的安全折中方案，会发生什么？用户只需要对着手机说一句：“帮我在美团和淘宝闪购上对比一下附近30块钱以内、评分最高的轻食沙拉，选好停在结算页让我付款。”豆包手机助手在后台静默识别屏幕、自动跳过开屏广告、自动过滤掉溢价的推广链接，几秒钟后直接把最终的付款界面推到用户眼前。

在这个过程里，资金交易依然绝对安全，但商家花大价钱买的搜索排名广告和信息流推荐，实际上只展示给了豆包的视觉大模型看。而AI是不会因为看到一张精美的海报就产生冲动消费的。正如观察者网与21世纪经济报道在分析此次事件时所指出的，一旦前端筛选过程被AI截留，超级App就会退化成一个纯粹的后端履约与发货管道；长此以往，商家的营销预算必然会从购买App内部的搜索广告，转移到讨好那个掌握分发权的AI助手上。

所以，商业平台不敢接受豆包的“局部安全开放”，原因并不复杂：对银行来说，风险发生在最后点击转账的那一秒；但对电商和内容平台来说，利润恰恰产生在用户到达付款页之前那三分钟的浏览过程里。让AI安全地替用户省掉这三分钟，就等于直接关掉了超级App的印钞机。

当立规矩的人叫字节跳动，移动端的“爬虫协议”很难复制

在这份155款应用的拒接名单里，还有两个细节非常值得放进一起来观察。

第一个细节是，除了传统互联网巨头，DeepSeek、Kimi（月之暗面）以及腾讯元宝、阿里千问、快手可灵等一众AI原生应用，也全部出现在了拒绝名单中。这些大模型应用既不卖外卖，目前也不靠信息流广告赚钱，为什么同样对豆包严防死守？

第一财经在报道中点出了一句很关键的话：这反映出智能体与现有平台之间的控制权问题。我自己平时在用LangGraph和MCP协议折腾多智能体（Multi-Agent）工作流时也深有体会，在一个由多个Agent协作的系统里，谁掌握最顶层的意图分发入口（Orchestrator），谁就拥有真正的用户关系和上下文数据；而被调用的下层工具，无论模型能力多强，最终都会沦为可随时替换的后台算力节点。如果DeepSeek和Kimi允许豆包通过读屏的方式直接调用它们的界面去回答问题、再把结果截取出来呈现给用户，那用户只知道豆包很聪明，独立AI应用辛辛苦苦做出来的用户留存和品牌认知就会被瞬间抽空。

第二个细节藏在豆包SAEP协议的技术文档代码里。在文档第4.2节介绍客户端如何查询自动化开关状态时，豆包在安卓底层暴露的系统接口类名叫做 android.security.obric.robots.RobotsHelperStub，协议标识则命名为 AGRP-Policy/1.0（Android GUI Robots Policy）。

看到 robots 这个词，熟悉互联网历史的人马上就能明白字节跳动的想法：它试图在智能手机上复刻一套PC网页时代的 robots.txt（君子协议）。在PC互联网时代，全网网站默认都是允许谷歌、百度等搜索引擎爬虫抓取的，只有当你主动在网站根目录下放一个 robots.txt 声明禁止时，爬虫才会停手。豆包这次提前30天发公示、要求开发者“主动声明拒绝否则默认逐步放开”，完全沿用了这套逻辑。

但为什么当年网站愿意接受搜索引擎的默认抓取，今天移动App却对豆包投出了155张否决票？

最核心的差异在于利益交换机制变了。PC时代的搜索引擎抓取网页后，只向用户展示标题和简短摘要，用户要想看完整内容、完成消费，必须点击链接跳回原网站——搜索引擎是用“导流”换取了网站的默认开放。而手机上的GUI智能体干的事情恰恰相反，它是把用户死死留在豆包的对话框里，替用户把所有中间界面点完，只向第三方App索取最终的服务结果，却不返还任何注意力流量。

更何况，站在这个移动端 robots 协议背后的不是中立的国际标准组织，而是字节跳动。在这155款拒绝应用里，腾讯系有66款，阿里系有23款，光是这两家就占到了总数的57.4%，再加上快手系的14款和美团系的11款，几乎就是中国移动互联网的半壁江山。字节跳动自己手里就握着抖音电商、抖音本地生活和巨量引擎广告体系，本身就是场上体量最大的超级运动员之一。如果淘宝、美团和微信向豆包敞开屏幕操作权限，不仅意味着广告展示被跳过，还意味着用户在自家平台上的实时比价偏好、消费频次和交互路径都会毫无保留地暴露给最直接的竞争对手。在这样的竞争格局下，指望各大厂接受一份由字节跳动单方面制定的“默认同意”协议，本就不太现实。

绕得开API接口，终究绕不开商业分账的谈判桌

平心而论，相比于过去一些直接利用安卓无障碍服务（Accessibility）在后台偷偷模拟点击的灰产脚本，豆包这次把SAEP协议摆上台面，给足30天公示期，明确承诺通过系统底层校验身份、记录可审计的操作日志，并且严格遵守开发者的拒绝声明，这在合规程序上已经是相当克制、透明的尝试。

但155款主流应用的集体拉黑，依然给过去两年AI行业极其追捧的“GUI Agent（图形界面智能体）”技术路线泼了一盆冷水。

此前很多做AI终端和Agent的产品经理都有一种乐观的想法：既然互联网大厂各自为战，不愿意开放结构化的API接口，那我们就干脆用多模态视觉大模型去“看屏幕、点屏幕”。只要AI像人的眼睛和手指一样去操作图形界面，就不需要求着App开发者写接口配合，从而用技术手段强行绕开商业生态的封锁。

现在看来，这条试图“靠技术绕开商业谈判”的捷径，在头部超级App面前是走不通的。当然，这并不意味着GUI读屏技术彻底失去了价值——在这次拒绝接入的155款应用之外，安卓生态里还有成千上万款中长尾的工具软件、传统行业应用和企业内部系统，它们既没有庞大的信息流广告护城河需要保卫，也没有充足的研发预算去改造AI接口，豆包的屏幕自动化能力在这些长尾场景里依然能帮用户省下不少繁琐的操作。

只是在决定普通人日常体验的社交、电商、外卖、支付等核心场景里，AI手机的瓶颈早就不再是视觉大模型能不能认出屏幕上的按钮了。当AI助手试图跨过应用围墙去调动服务时，它触碰的是一整套维持了十多年的流量分配与广告变现秩序。在手机厂商、AI平台与超级App坐下来谈拢新的流量分账比例、广告补偿机制以及法律权责边界之前，哪怕技术协议把安全锁设计得再严密，大厂的大门大概率还是会继续关着。

欢迎订阅微信公众号--“Laoer杂谈”

豆包明明递出了“只逛街不付款”的安全锁，大厂为什么不接？

如果AI替用户省掉了“往下刷”的过程，平台的过路费找谁收？

当立规矩的人叫字节跳动，移动端的“爬虫协议”很难复制

绕得开API接口，终究绕不开商业分账的谈判桌

相关学习资料