一场注定会输的竞争:传统互联网软件的入口保卫战

10 月 14 日，豆包手机助手公布了一份拒绝操作应用清单。150 余款应用在列，包括微信、淘宝、支付宝、美团、小红书，也包括 DeepSeek 和 Kimi。

这些应用仍可由用户手动使用，但不允许豆包手机助手通过识别屏幕、模拟点击等方式代为操作。按照豆包公布的规则，应用开发者可以声明拒绝屏幕自动化操作；即使公示期结束，开发者仍然可以提出拒绝，豆包会关闭相应能力。

就在一个月前，海外也发生了类似的冲突。亚马逊拦截了 Meta 的个人助手 Muse。用户想让 Muse 替自己浏览商品、完成购物，却遇到了关于未经授权 Agent 访问的提示。亚马逊表示，第三方助手应当公开运行方式，并尊重服务方是否参与的决定。

从国内的手机 App 到海外的电商网站，AI 替用户办事，遇到了一个共同的问题：用户同意让助手操作，不代表平台也愿意接受这个助手。

平台有自己的顾虑。私人消息能不能被读取，支付是否需要本人确认，出错后由谁负责，都需要明确规则。但如果限制也覆盖搜索、比较、整理和普通查询，问题就不只是防止误操作了。

用户希望少打开几个 App、少填几次资料，平台却可能因此失去展示商品、安排推荐和销售广告的机会。用户想把事情交给助手，平台仍希望用户进入自己的页面。这场入口保卫战，就从这里开始。

一、平台担心的，不只是多了一个机器人

假设你想买一台空气净化器。你告诉助手预算和要求，它比较几家商店的价格、滤芯成本和配送时间，给出两个选项。你确认其中一个，助手再去下单。

商店收到了一笔订单，但你没有逛首页，没有看商品推荐，也没有经过那些原本可能促成加购的页面。对主要靠销售商品赚钱的商家，这可能是一次高效成交；对依靠广告、推荐位置和用户停留赚钱的平台，情况就复杂得多。

过去，用户通常先进入平台，再决定买什么。平台可以影响先展示哪些商品、推荐哪些商家，以及在哪里插入广告。如果用户先把要求告诉助手，比较和筛选就可能在平台之外完成。等助手访问商店时，用户已经作出了选择。

类似的变化也可能发生在出行、办公和生活服务中。用户说明要办什么事，助手负责在不同软件之间查询信息、填写资料、完成操作，用户不必再逐个打开页面。

订单可能还在，平台影响用户选择的机会却减少了。所以，即使 Agent 能带来订单，也未必足以说服平台开放。平台还要考虑：通过 Agent 获得的收入，能不能弥补用户减少浏览后带来的广告和推荐收入损失？

二、封禁能挡住访问，却没有消除需求

平台确实需要防止滥用。助手可能发送过多请求、泄露数据、重复提交订单，也可能因为理解错误，执行不符合用户意愿的操作。读取订单信息和修改收款账户，显然不能采用同一套权限规则。

但这些风险可以分别处理：谁有权发起操作，可以读取哪些信息，每分钟允许请求多少次，哪些动作必须由用户确认，出错后如何核对。

豆包的 SAEP 协议也允许开发者分别限制整个应用、某个页面或某类操作。例如，允许助手辅助编辑内容，同时限制最终发布；允许普通页面操作，同时禁止敏感页面截图。管理 Agent，可以比全面允许或全面禁止更细致。

如果一个助手只读取用户自己的订单，遵守访问限额，也不获取额外数据，平台仍然拒绝访问，就需要解释这种操作究竟带来了什么风险。

因为用户原本想省下的工作，并不会随之消失。查询订单、整理发票、比较价格、追踪退款，这些事情还是要做。平台不允许助手完成，用户就只能继续自己操作，或者寻找其他工具和服务。

用户未必会因此离开。如果平台价格更低、商品独家、售后明显更好，多操作几步也可能值得。真正留住用户的，是这些交易和服务条件，而不是操作步骤本身。仅仅提高外部工具的使用难度，很难让用户重新喜欢上填表、复制信息和反复切换页面。

三、哪些平台更容易失去优势？

传统互联网软件受到的影响不会完全一样。一家酒店拥有真实的客房，一家航空公司提供实际的航班。助手可以替用户比较和选择，却不能凭空增加房间，也不能绕过服务方独自完成改签和退款。预订平台如果能提供更好的价格、结算方式和售后保障，也依然有被选择的理由。

另一类平台可能面临更大的压力：它们没有独特的商品或服务，也没有明显更好的交易条件。用户使用它们，主要是为了搜索信息、比较选项，再跳转到其他地方成交。如果助手能直接完成这些步骤，用户就少了一个必须经过它们的理由。

一款软件即使很少被用户直接打开，也可能因为功能可靠、服务稳定而持续获得收入。用户减少操作，不等于软件失去价值。

比如，用户需要一份准确的报表，过去要亲自打开多个页面、设置筛选条件、导出文件，再整理结果。如果助手接手这些步骤，报表系统仍然有用，只是用户不再需要熟悉每一个按钮。

软件公司需要重新看清楚：用户究竟需要它提供什么，又有哪些操作只是为了获得结果而不得不付出的时间。

四、独立 Agent 也没有稳操胜券

用户不再打开 App，并不意味着独立 Agent 就能获得这些用户和收入。助手需要稳定访问不同服务，保存任务进度、处理失败，还要承担模型调用和异常处理的成本。有的平台提供接口，有的平台只开放部分功能，还有的平台可能调整页面和访问规则。

这些问题由助手的开发者处理，用户则按整项任务评价它。

比如，用户让助手安排出差并处理报销。助手完成了订票、订酒店和整理行程，最后报销系统不允许自动提交，用户仍然要自己登录、补充资料。前面已经完成的工作有价值，但如果经常需要用户补做或返工，用户就会重新衡量这笔订阅是否值得。

平台限制访问，也会直接增加助手的成本。某个必用服务无法操作，它就需要寻找替代办法、请用户手动完成，甚至无法完成原来的任务。

因此，独立 Agent 要持续收费，需要证明两件事：它能稳定完成用户经常需要处理的工作，确实节省时间；用户愿意支付的费用，足以覆盖模型调用、服务接入和异常处理等成本。

偶尔演示成功一次，还不足以证明这门生意能够长期成立。它还要面对另一个问题：如果手机系统或浏览器已经自带助手，用户为什么要额外购买你的产品？

五、这场竞争里，至少有三方

操作系统、浏览器和模型提供商，同样可以开发跨 App 助手，而且可能已经拥有用户熟悉的入口。用户不用专门寻找、安装另一款产品，就能开始交代任务。

独立 Agent 因而同时面对两边的压力：服务平台决定开放哪些功能，系统或浏览器附带的助手则影响用户是否愿意再购买一套工具。

服务平台掌握商品、价格、库存和售后；系统和浏览器附带的助手更方便用户开始使用，也可能把费用包含在已有产品中；独立 Agent 则需要在具体工作上做得更好，例如准确理解业务要求、持续处理长期任务、解决特殊情况，让用户觉得额外付费值得。

同一家公司，也可能同时扮演平台和助手提供商。Meta 的 Muse 希望进入亚马逊替用户购物，Meta 自己管理的 WhatsApp 却也曾限制竞争对手的通用 AI 助手接入。2026 年 6 月，欧盟委员会对此采取临时措施，要求恢复相关接入，等待调查结果。

做助手时希望外部服务开放，经营平台时又要决定允许谁进入。公司的立场会随着具体业务而变化，App 和 Agent 很难成为两支界限清楚的队伍。

如果判断未来三到五年的发展，我更看好掌握默认入口、又有能力完成跨应用任务的大公司成为主要受益者。拥有稀缺供给和可靠履约能力的平台，也仍然有很强的议价能力。独立 Agent 的机会，更可能先出现在需求明确、反复发生，而且用户愿意付费的工作中。

传统 App 失去一部分访问量，最后获益的也可能是另一家大公司。

六、谁能替用户换一家，谁才更有谈判能力

随着 Agent 开始实际处理任务，双方需要商量的问题会越来越具体：哪些操作可以开放，接口如何收费，订单出了问题由谁处理，助手推荐商品时是否收取佣金。

一些技术方案已经在处理接入问题。Visa 的 Trusted Agent Protocol 使用数字签名等机制，帮助商家识别助手及其请求；WebMCP 则尝试让网站主动声明可供助手调用的功能，减少助手对页面按钮和表单的猜测。

这些方案能帮助双方确认身份、明确操作。接入价格、推荐规则和交易分成，仍然需要谈判。

谈判时，一个关键因素是双方有多容易被替换。如果多家商店能提供相近的商品、价格和售后，助手就有选择。某家不愿开放，订单可能流向另一家，助手也更有机会争取有利条件。但如果用户必须使用某个平台，换一家就会失去重要商品、优惠或服务，助手就没有多少替代选择，平台仍然可以坚持自己的要求。

这也解释了为什么不同平台可能作出不同决定。对不缺客户的大平台，开放助手可能意味着减少自己影响用户选择的机会；对希望获得新订单的商家，接入助手却可能是一条新的销售渠道。用户已经明确想买什么，商家未必需要他先逛完一遍首页。

只要商家还有争取新订单的动力，Agent 就有寻找合作伙伴的空间。但它必须把这些合作变成稳定、可靠的服务，才有能力持续争取用户。

七、软件要回答的是：用户为什么还需要我？

这场入口保卫战中，最难长期维持的，是平台对用户提出的一个要求：想使用我的服务，就必须亲自进入我的界面，按照我设计的步骤操作。

当助手不够可靠、成本又高时，用户会继续自己做。但如果助手能以相近的成本稳定完成任务，用户就有理由选择更省事的方式。

禁止外部助手访问，短期内可能有效。用户需要平台提供的商品或功能，就不得不遵守它的规则。但这种限制没有让原来的操作变得更有价值，也没有改变用户希望省事的需求。

传统互联网软件可以开放接口、改进授权，也可以开发自己的助手，让用户更方便地使用服务。

平台要留住用户，还是要靠价格、功能和服务。如果助手能把同一件事办好，用户就没有理由继续花时间手动操作。