AI手机真正的挑战不再只是能否操作，而是能否被整个应用生态接受。
文章作者、来源：ME News
TL;DR
- 豆包手机助手正在改变跨App操作规则。 10月14日，SAEP协议30天公示期结束，第三方应用由此前原则上需要主动同意才能被操作，转向未明确拒绝即可按风险等级逐步开放。
- 153款应用明确拒绝，互联网头部生态占据多数。 腾讯及关联生态65款、阿里及关联生态23款，两者合计占拒绝名单约57.5%，美团、拼多多、小红书、DeepSeek等也在其中。
- 争议不仅在于安全，更涉及移动互联网的入口和商业利益。 当AI可以直接完成搜索、筛选、点击和交易流程，App原本掌握的用户交互、流量分配和商业转化路径都可能发生变化。
- SAEP试图用分级权限解决争议，但技术协议无法独自消除商业分歧。 即使允许AI操作部分页面，支付、认证、发布及删除等高风险行为仍需要更严格的控制。
- AI手机真正的挑战不再只是能否操作，而是能否被整个应用生态接受。 未来谁能建立可信、可审计、责任清晰的跨应用协作机制，谁才更有机会成为下一代移动互联网入口。
一、30天公示期结束，豆包改变了游戏规则
10月14日，豆包手机助手宣布，《屏幕自动化操作声明协议》（SAEP）为期30天的公示正式结束，接下来将逐步开放第三方应用的屏幕自动化操作权限。与其说这是一项常规的功能更新，不如说它标志着豆包开始主动调整AI手机与整个移动应用生态的相处方式。
变化主要体现在授权逻辑上。按照此前的规则，公示期内，豆包手机助手只能自动操作系统应用、字节跳动旗下应用，以及明确表示同意的第三方应用。其他没有作出回应的开发者，默认不会受到AI自动化操作的影响。
但从10月14日起，规则发生了改变。对于没有明确回复、也没有通过协议声明拒绝的第三方应用，豆包将依据风险等级逐步开放自动化能力。需要强调的是，未拒绝并不等于开发者已经同意，开放也不意味着所有操作都能无限制执行。
这种从主动许可向默认分级开放的变化，直接改变了平台与开发者之间的关系。此前，豆包需要等待其他应用主动开放权限；现在，应用开发者需要主动表达限制条件，否则就可能进入豆包的自动化操作范围。
这也解释了为什么一份技术协议能够迅速引发互联网行业的广泛关注。AI助手虽然运行在用户自己的手机上，但当它尝试进入其他公司的应用，代替用户点击、输入甚至完成复杂任务时，实际触及的已经不只是用户体验，还包括应用开发者对于自身产品的控制权。
事实上，这场争议并非第一次出现。2025年12月，豆包手机助手技术预览版发布后，就曾遭遇微信、QQ、支付宝、淘宝、拼多多等应用的风控限制，部分金融类App也无法正常完成自动化任务。面对这些问题，豆包随后调整了金融场景的操作能力。
从去年底的技术预览，到今年9月14日推出消费者版和SAEP协议，再到10月14日正式结束公示，豆包一直在尝试回答一个问题：当AI可以像人一样操作手机时，究竟应该由谁来决定它能做什么？
二、153款App拒绝，背后远不止安全问题
与豆包宣布扩大开放同时出现的，是一份相当引人注目的拒绝名单。
根据10月14日更新的信息，明确拒绝豆包手机助手自动化操作的应用达到153款。其中，腾讯及关联生态应用65款，包括微信、QQ、王者荣耀、腾讯会议、元宝等；阿里及关联生态应用23款，包括淘宝、天猫、支付宝、钉钉、高德地图等。
除此之外，快手旗下14款、美团旗下11款以及萤石旗下7款应用也出现在名单中。拼多多、小红书、知乎、DeepSeek、Kimi，以及中国工商银行、招商银行等金融机构应用，同样明确表达了拒绝态度。
值得注意的是，这份名单在当天上午曾出现151款的版本，随后增加至153款。因此，不同时间发布的报道存在数量差异，并不意味着这些媒体引用了完全不同的事件。
从名单构成来看，拒绝自动化操作的应用涉及社交、电商、游戏、生活服务、金融和人工智能等多个领域，不能简单归结为某一家互联网企业与字节跳动的竞争。
安全显然是其中一个重要原因。对于银行而言，账号登录、转账和支付涉及资产安全与身份验证；对于游戏平台而言，自动点击与模拟输入可能与正常操作、外挂或脚本行为产生识别上的冲突；对于内容平台而言，自动发布、评论及批量互动也可能触及反垃圾信息和反作弊机制。
但如果只从安全角度理解这场集体拒绝，仍然不够全面。
过去十多年的移动互联网商业模式，建立在用户进入特定App、完成交互并产生商业价值的基础之上。电商平台需要用户浏览商品和参与推荐，内容平台依赖信息流与用户停留，生活服务平台则围绕搜索、排序和交易建立完整的服务体系。
AI助手的出现，可能改变这一切。当用户不再需要逐个打开应用，而是直接告诉AI自己的需求，再由AI完成查询、比较和操作，应用依然提供服务，但用户与服务之间多了一层新的决策和交互入口。
对于大型互联网平台而言，真正需要评估的不只是AI能否进入自己的App，而是当用户习惯于通过AI使用服务时，平台还能在多大程度上掌握用户关系与商业转化过程。
当然，目前没有充分证据证明153款应用都是出于流量或商业利益而拒绝接入。安全、合规、技术兼容性及竞争关系可能同时存在。将所有拒绝都解释为大厂保护既得利益，同样是一种过度简化。
三、AI替用户操作手机，为什么会改变互联网的生意？
传统手机助手与新一代AI智能体之间，一个根本区别是执行能力。
过去，语音助手更多承担打开应用、设置提醒、查询天气等相对简单的任务。即使可以跳转至第三方服务，很多复杂操作仍需要用户进入具体App，按照平台设计的流程完成。
具备图形界面操作能力的AI智能体则不同。它可以理解屏幕内容，识别按钮和输入框，并通过模拟点击、输入及页面切换执行连续任务。理论上，只要操作路径允许，它就可以在不依赖每个应用专门提供接口的情况下，完成一部分原本需要人手动处理的工作。
例如，一名用户希望比较几个出行平台的服务价格。在传统模式下，他需要分别打开应用、输入目的地、查看结果并自行比较。若AI获得相应权限，这些步骤就可能被整合为一条自动化任务链。
这种变化的价值在于减少操作成本，但其商业含义同样不容忽视。
首先受到影响的是流量入口。过去，搜索框、推荐列表和应用首页是平台连接用户的重要方式，而AI可能在用户进入这些页面之前，就完成初步的信息筛选。平台仍然拥有商品、服务和交易系统，却未必继续掌握整个用户决策过程。
其次是商业转化路径。广告展示、推荐排序、会员权益和营销活动往往与用户的具体交互流程绑定。如果AI只提取完成任务所需的信息，一些原本依靠页面展示和用户浏览实现的商业模式就可能面临调整。
不过，这不意味着AI会直接取代App。商品履约、支付清算、社交关系、内容供给以及售后服务等能力，仍然需要具体平台提供。AI更可能首先改变这些服务被发现、组织和调用的方式，而不是立即取代服务本身。
这也是为什么跨App自动化可能成为比传统AI聊天更敏感的竞争领域。聊天机器人主要争夺用户的提问时间，能够操作手机的AI智能体则有机会介入用户真实的消费、社交和工作流程。
从这个角度看，豆包此次推进跨App操作，是在争取一个更靠近用户需求的入口位置。它能否形成规模化商业价值，目前尚无充分数据支持，但其产品方向已经触及移动互联网长期形成的流量分配结构。
四、SAEP试图解决矛盾，但不是一张万能通行证
为了避免AI操作与应用自身的安全边界发生直接冲突，豆包推出的SAEP并不是简单的允许或禁止机制，而是一套分级声明方案。
根据官方开发者文档，第三方应用可以在整个App、指定页面以及操作意图三个层面设置限制。开发者能够禁止AI进入某些页面，也可以只限制截图、模拟输入、内容发布、删除或奖励领取等具体行为。
例如，内容平台可以允许AI辅助用户撰写帖子，但禁止它直接执行最终发布；金融应用则可以限制登录页面的截图和输入能力，并对支付确认环节实施更严格的控制。
在决策机制上，SAEP还区分了允许操作、阻止操作以及要求用户接管等不同结果。涉及支付转账、账号认证和其他高风险行为时，即使应用没有主动禁止，系统安全基线仍然可以要求用户确认或阻止执行。
这套设计体现了一种相对务实的思路：不是让AI获得无限操作权限，而是尝试明确哪些操作可以交给机器，哪些必须保留给用户。
不过，协议设计与实际安全能力不能画等号。官方文档也指出，某些意图级约束能否被系统完整强制执行，仍取决于目标系统版本。当前文档列出的支持环境为ObricUI 2.2及以上，这意味着SAEP并不是一项已经覆盖全部安卓手机的通用标准。
更重要的是，安全问题并不会因为增加一层授权机制就自动消失。AI可能误识别页面、选择错误对象，也可能在连续任务中遇到异常状态。对于涉及资金、隐私或不可逆操作的场景，仅仅判断AI是否获得权限还不够，还必须明确异常情况下谁负责、如何追溯，以及用户能否及时终止执行。
从制度设计看，SAEP的价值在于把原本模糊的操作边界转化为能够被系统识别和审计的规则。但要真正获得开发者信任，仍需要实际运行记录、技术验证和长期稳定性来证明其有效性。
五、争议的核心：用户授权与平台控制权如何平衡？
豆包与第三方应用之间的分歧，还揭示了一个长期被忽略的问题：用户已经拥有某个App的正常使用权限，是否意味着用户也可以授权AI代替自己完成所有操作？
从用户角度看，AI助手只是提高效率的工具。既然可以自己打开应用、查看内容、点击按钮，那么让软件代替自己执行部分重复步骤，似乎也是一种合理的使用需求。
但应用开发者面对的情况要复杂得多。它需要保障系统稳定，识别恶意脚本与正常用户，维护交易安全，并承担相应的合规责任。即使一项自动化操作确实源自用户指令，也不能因此认定它与人工操作具有完全相同的风险。
尤其是在金融和社交领域，用户授权并不能替代平台的身份验证、业务风控和反滥用规则。
这实际上涉及三种不同的控制权：用户决定希望完成什么任务，应用开发者决定自身服务允许怎样被访问，操作系统则决定AI能够调用哪些设备能力。
SAEP尝试在三者之间建立协调机制，但规则由豆包及其合作的系统生态提出，本身也意味着平台需要持续证明这套机制公平、透明且能够被外部开发者信任。
作为对照，苹果的App Intents提供了另一种思路：由开发者主动将特定功能以结构化方式开放给系统智能能力和快捷指令使用。这与豆包通过图形界面模拟用户操作的技术路径并不相同，各自也存在限制。
结构化接口通常更容易明确调用范围和返回结果，但依赖开发者适配；图形界面自动化拥有更广泛的潜在覆盖能力，却需要面对页面变化、操作误判及授权边界等问题。
两条路线的差异，反映的是AI手机生态面临的现实取舍：究竟应该优先追求跨应用能力的覆盖范围，还是优先通过开发者协作建立稳定的操作标准？
至少在现阶段，很难仅凭一次协议公示就得出答案。
六、153款应用拒绝之后，AI手机真正的考验才开始
对豆包而言，10月14日是一个重要节点，但远不是跨App自动化争议的终点。
首先，153款拒绝应用不代表整个移动互联网生态都在反对AI自动化。这份名单反映的是截至当天明确表达拒绝的应用范围，不能据此推算全部开发者的真实态度。同样，未出现在名单中的应用也不能被直接视为已经主动支持豆包。
其次，拒绝名单并非永久不变。豆包已明确表示，公示期结束后，开发者仍然可以随时提交拒绝声明，官方将在3个工作日内反馈，并持续更新名单。因此，接下来真正值得关注的是新增拒绝应用的数量、允许部分能力的开发者比例，以及具体自动化任务的完成情况，而不是某一天名单的绝对规模。
对于整个行业来说，AI手机能否获得消费者认可，最终还要取决于实际体验。如果一项跨应用任务经常因为平台限制而中断，用户很难长期依赖它；如果为了提高任务完成率而过度放开敏感权限，又可能损害用户及应用方的信任。
未来较为现实的路径，可能不是要求所有App全面开放，也不是让每个平台彻底关闭入口，而是逐步建立更清晰的协作边界。低风险的信息查询和重复性操作可以探索更灵活的授权方式，高风险交易与身份验证则保留严格确认机制，开发者也应当能够审计AI行为，并在必要时调整权限。
这种生态建设显然比演示一次成功的自动化操作困难得多，因为它要求模型能力、操作系统权限、开发者利益及用户安全同时得到协调。
从更长远的视角来看，AI手机真正可能改变的不是用户是否还需要App，而是用户是否还需要亲自完成每一个使用App的步骤。 这一变化既可能提高整个移动互联网的使用效率，也可能重新分配不同平台在用户决策过程中的价值。
豆包此次放开跨App操作，证明技术提供方仍在积极推动这种变化；153款应用的拒绝，则说明现有应用生态尚未形成足够广泛的共识。双方各有合理诉求，也各有需要进一步回答的问题。
因此，这件事不宜被简单理解为AI创新遭遇传统互联网大厂阻挠，更不是一个通过技术升级就能迅速解决的权限问题。它实际上是移动互联网向智能体时代过渡时，一场关于控制权、责任和商业规则的重新协调。
能操作多少App，决定了AI助手现阶段的功能边界；能让多少开发者和用户放心地接受它，才决定了AI手机能走多远。