--- layout: post.njk source: https://yage.ai/share/amazon-ai-shopping-agent-blocking-20260927.html speaker: yage.ai title: Amazon 能封住替你购物的 AI 吗？ date: '2026-09-29' summary: 文章分析了AI购物助手面临的封锁困境。云端架构易被电商平台识别并阻断，本地架构虽能规避技术封锁但面临法律与广告利益争议。尽管行业推进通用协议，平台仍通过控制准入与广告收益维持主导权，AI代理的落地取决于平台意愿。 area: tech-engineering category: ai-application tags: - agentic-commerce - browser-automation - platform-lock-in - legal-risk - ad-revenue people: [] companies_orgs: - amazon - meta - perplexity - openai - google products_models: - muse - comet - ucp - chatgpt - gemini-spark media_books: [] draft: true status: evergreen --- ## Muse 连搜索页都没进去 今年 5 月，我在《Google 关掉 Project Mariner，Anthropic 和 OpenAI 其实也没跑通》里写过，独立浏览器助手在面对网站反爬机制时连连碰壁，行业开始把方向转回用户自己的日常浏览器。4 个月后，战场上出现了一起引人注目的新事件。2026 年 9 月，Meta 推出云端助手 Muse，尝试替用户跑腿浏览网页、处理待办并去电商网站购物。但在购物这项核心能力上，它刚上线就撞到了铁板。 The Register 记者的实测记录显示，测试者让 Muse 去 Amazon 寻找评价最好的工学办公椅，加入购物车，并推进到最后的结账页面。整个流程还没展开就停住了。Muse 没找到椅子，也没能加购，而是在对话框里坦白：浏览器连搜索页都没能进去，所以没找到椅子，也没加购物车。报道还附上了 Amazon 拦截页面的截图。 这并不是说 Muse 从未在 Amazon 买成过东西。The Verge 记者的报道提到，此前曾经用 Muse 在 Amazon 上成功买过背心。也就是说，过去的成功并不能保证后续的通行，Amazon 随后关闭了通道。 围绕这次阻断，GeekWire 拿到了 Amazon 弹出的现场警告和说明。Amazon 在弹窗提示里说，一个没经它同意的 AI 程序在反复访问网站，这违反了用户此前同意的服务条款。按照 Amazon 的说法，他们此前就已经要求 Meta 把 Amazon 排除在代办范围之外。Amazon 还指责 Muse 访问时没有自报家门，说它似乎在收集并存储用户的账号密码，甚至可能根据用户指令调取历史订单。 面对账号密码安全的质疑，Meta 在封锁发生前的 9 月 8 日，就在官方安全文档中写明了系统设计：用户输入的密码会直接进入隔离的安全存储区域，负责推理的主模型本身看不到明文密码；只有网页确实需要登录认证，系统才会把密码注入浏览器窗口。两边的表态完全没有接上。Meta 解释的是密码在自己系统里怎么隔离和加密，回答的是会不会泄密；Amazon 质问的是一个没经它允许的外部程序凭什么进店跑腿。技术上把密码保管得再严密，也只回答了防不防泄密，没有回答平台愿不愿意给跑腿软件开门。 这就引出了一个关键疑问：如果厂商部署在云端的服务器容易让电商平台认出来并直接阻断，那么把浏览器搬回用户自己的电脑上呢？如果让本地运行的浏览器带着真实的登录状态，由 AI 在后台辅助操作，网站还能这样干脆地把门关上吗？ ## 同样是AI点击，网站看到的不同 同样是去挑选办公椅并放进购物车，最直观的区别是究竟谁的电脑在打开 Amazon。在云端代办模式下，你在聊天框里输入要求，真正打开商城的其实是厂商机房里的服务器。根据 Meta 的官方安全文档，Muse 为每个用户分配了数据中心里的云电脑与远端浏览器，所有的翻页、点击和输入全在机房里完成。 对电商平台来说，这种模式特征明显。海量的购物请求集中在厂商的机房，脱离了千家万户分散的宽带。如果平台能认出这些连接来自哪些服务器出口，就可以把来自这些出口的请求成组拦在门外。机房服务器虽然不一定独占网段，批量封锁出口也可能误伤同网段的其他租户，但比起分散各地的家庭宽带，机房出口依然是平台手里相对集中的识别线索。 换到用户自己的电脑上，情形就变了。你在自己的桌前打开平时用的日常浏览器。根据独立安全机构对桌面智能助手的逆向分析，模型虽然在云端负责推理和规划，但具体的操作指令是发给本地浏览器插件。所有的点击和跳转都在你眼前的屏幕上真实发生，发出的网络请求也是从你家里的宽带发出去。 接收请求的电商网站此时看到的是什么？它看到的是一台有着正常软硬件参数的日常设备，带着你平时积累的 Cookie 和真实登录状态，从一个普通的家庭网络发起访问。平台此前对付机房出口的那套批量封锁方法，在这里直接失效了。不过必须说明，设备上保留着已有登录状态，并不代表自动化操作在法律或服务条款上就获得了当然的许可。 但这不意味着本地操作毫无痕迹。浏览器虽然跑在本地，操作过程依然会留下特征。除了检查请求来源与登录状态，电商平台也可以综合操作模式与客户端特征来进行机器人与风险评估。比如自动化程序在商品列表里翻页太快，或者在不同标签页之间切换的节奏反常，这些模式依然可能触发风控警报。 但对平台来说，单纯依靠行为特征去拦截本地设备，要承担误伤的代价。自动化行为与真人习惯之间存在重叠地带：一个熟练比价的真人顾客，在抢购或者挑选打折商品时，同样会快速刷新页面、连续点击对比多个链接。如果平台把检测门槛调得太紧，就会把真实买家当成机器人拦在外面。打断真实顾客的购物流程，会损害用户体验并导致订单流失。这种误伤的商业代价，平台必须自己吞下去。 浏览器在用户电脑还是厂商云端，改变了网站能够辨认的访问来源。 ## 法庭把法律风险讲清楚了 浏览器究竟放在本地还是云端，不只是工程架构的选择，更已经在实际诉讼中变成了双方争执的核心。今年 5 月的那篇文章提到，Amazon 起诉了 Perplexity 旗下的 Comet 浏览器，指控它未经授权自动化访问商城，触犯了规范未授权计算机访问的美国反黑客法律 CFAA。当时初审法院对 Perplexity 颁布了初步禁令，Perplexity 随即提出上诉，读者当时看到的最新节点是双方等待 5 月 15 日的听证。 Comet 浏览器恰好把本地和云端两种架构都试了一遍。在桌面端，独立安全机构的逆向分析显示，Comet 走的是本地路线：由云端模型规划操作步骤，再由用户本地的浏览器扩展在窗口中执行导航与点击。 但在 iOS 移动端上，Comet 的早期测试走了另一条路。MacStories 当时写道：Comet for iOS 的 agent 不会在 iOS 应用内部替你浏览网页，而是在云端为你创建一个虚拟浏览器。为了让这个远端虚拟浏览器拥有登录身份，应用在提示用户后把临时的登录 Cookie 上传到了云端。 这场诉讼在 2026 年 8 月 4 日迎来了转折性进展。美国联邦第九巡回上诉法院作出一项长达 21 页的重要裁决：撤销原审法院针对 Perplexity 颁布的初步禁令，并将案件发回原审法院继续审理。 我翻到第九巡回法院这份意见书时，发现法官关注的核心其实只有一个：在法律意义上，究竟是谁在发起对 Amazon 计算机的访问？ 依据当时案卷记录，上诉法院指出，虽然 Perplexity 的云端系统向本地发送了操作指令，但实际发出访问请求的依然是坐在电脑前、借助辅助工具开展具体操作的消费者本人。法官在意见书第 15 页写道：真正访问 Amazon 计算机的，是借助辅助工具在 Amazon.com 上执行具体操作的用户本人。换句话说，按当时的案卷记录，是消费者本人借助工具访问了 Amazon 的计算机，法院在这份记录上并没有把 Perplexity 认定为法律意义上的访问者。 不过，必须讲清楚的是，撤销初步禁令不等于 Perplexity 赢下了整场官司，更不代表本地工具就拥有不受限制的合法通行权。上诉法院法官在判决附注中作出了严格保留。意见书第 21 页第 5 条附注明确写道：这一结果并不妨碍 Amazon 通过面向用户的私有服务条款来规范对 Amazon.com 的访问。这项裁决丝毫不会削弱 Amazon 依据自身服务条款去约束其用户的权利。法院既没有判定所有本地运行的辅助工具都合法，也没有否定平台通过私人契约管理商城的权力，更没有对案件中诸如经济损失等其他法律要件作出终局认定。 随后，进攻方的火力点迅速发生了转移。2026 年 9 月 21 日，Amazon 正式向法院提交了修订后的新诉状。在这份新诉状里，Amazon 调整了诉讼策略。除了继续坚持原有的反黑客法诉求外，Amazon 新增了一项民事侵权指控：故意干预合同关系（Tortious Interference with Contractual Relations）。Amazon 指控 Perplexity 故意诱导并协助用户规避和违反他们此前同意的网站使用条款。 同时，Amazon 把目光重点转向了 Comet 在移动端的做法。针对 MacStories 记录的 iOS 云端虚拟浏览器，Amazon 主张这种由云端服务器直接连接商城的行为属于未经授权的直连。此外，诉状还指控 Perplexity 在 2025 年经历两轮技术封锁后故意更新软件绕过防御。目前，这些新指控尚未经过法庭审理。 从这份 8 月的法庭裁决和 9 月的新诉状中，我们可以清楚地看出法律风险是如何随着系统架构而分叉的：如果是本地执行架构，由本地浏览器出面操作，那么在反黑客法（CFAA）关于未授权计算机访问的指控上，厂商承受的法律压力明显减轻。因为法庭目前更倾向于认定这是消费者借助工具访问，而非外部黑客程序直接入侵。但这不代表没有法律风险，用户违反平台服务条款的违约责任，以及厂商面临的诱导违约侵权指控，依然是悬在头顶的现实风险。 如果退回云端直连架构，由厂商的机房服务器或云端虚拟浏览器直接访问商城，平台立刻就能重新抓住未授权机房直接连入这一点，在反黑客法上组织起全新的攻击面。此前行业讨论的从云端退回用户客户端，在法律层面到底带来了什么改变、又留下了什么隐患，在这两份法律文件中有了清晰的回答。 ## 广告是卖给真人看的 在法庭诉讼和条款争议之外，平台心里其实还有一笔经济账。很多人以为电商平台拦截跑腿软件，是担心外部程序抢走订单。但从交易本身来看，有人替顾客下单，买卖照旧发生，平台同样能拿到商品价差或者商家的销售佣金，成交环节的损失其实有限。 平台真正受损的地方，在搜索和浏览背后的广告收入。商家在电商网站上花钱购买搜索排名和推荐橱窗，买的是活生生的人类注意力。我翻看 Amazon 2025 年的年度报告，年报写明广告收入按照点击或曝光来计量。广告主愿意付费，是因为广告能吸引真人、影响真人的购买决定，进而促成点击。 AI 助手的浏览方式却完全不同。如果你让它去挑选二十个商品页，它会在短时间内打开大量页面，却不会受广告影响。从技术逻辑推演，自动化程序在解析页面代码时，能够分清哪个是广告位、哪个是自然搜索结果。当然，agent 能分辨广告位属于分析推演，并不是 Amazon 官方公布的实测数据。面对这些页面，AI 只抽取商品价格、规格参数和买家评价，完全避开花钱推广的内容。 这就带来了一个让平台头疼的局面：这些页面原本能向真人展示广告、赚取点击费，而 agent 的浏览把广告赖以成立的那个注意力环节拿掉了。按这个推演，外部助手在免费消耗商城的浏览页面，页面本身的广告价值却很难兑现。这也是平台必须在浏览层防范外部流量的核心动机。 不过，评估这笔损失也要看清体量。Amazon 2025 年年报显示，公司全年总净营收约 7170 亿美元，其中广告服务收入约 686 亿美元，占比不到一成。广告虽然增速较快，但不是平台的营收大头。AI 浏览冲击的是依附在商品展示上的广告层，并不是整个商业模式。 平台既想守住展示页面的广告价值，又不能把接入 AI 的趋势挡在门外。这种复杂的经济考量，直接解释了为什么各大巨头在技术上严加防守的同时，又悄悄坐到了同一张谈判桌前。 同一个商品页，人看到广告会被影响，机器只抽取参数。 ## 为什么一边封锁，一边合作 如果只看商城前端的技术封锁与法庭诉讼，各大科技公司似乎水火不容。但在商业标准的制定现场，展现出的却是另一番景象。 2026 年 4 月 24 日，协议参与方宣布，Amazon、Meta、微软、Salesforce 与 Stripe 共同加入了通用商业协议 UCP 技术委员会。在 UCP 这个开放协议中，各方共同坐下来讨论通用的商品发现、购物车管理与结账流程规范。在此之前的 1 月，Google 也联合 Shopify、Target、Walmart 等零售巨头推进 UCP 落地，并在协议框架中明确指出零售商保留其作为法定销售方的地位，牢牢把控交易控制权与客户关系。 4 月份还在共同起草行业标准，到了 9 月份，Amazon 照样在商城里封锁了 Meta 的 Muse。这组对比说明：坐在一起商量接口协议，与自家的商场愿不愿意向外部程序开门，完全是两码事。协议解决连接格式，不解决准入许可。参与标准制定不会自动开放商城，平台依然在控制自己的流程，相关的条款效力与法律争议如前文所述仍未定论。 各大 AI 厂商在具体的落地方式上也在摸索调整。OpenAI 此前曾尝试让交易留在对话框内，于 2025 年 9 月联合 Stripe 推出 Instant Checkout 和 ACP 协议。但在实际运行近半年后，OpenAI 在 2026 年 3 月 24 日做出了调整。官方坦言最初的即时结账不够灵活，决定允许商家使用自己的结账流程。官方说明的原话是：我们发现第一版 Instant Checkout 没有达到我们希望提供的灵活度，因此允许商家使用自己的结账体验，我们则把重心放到商品发现上。 根据 Shopify 的官方说明，如今 ChatGPT 用户挑好商品后，是通过应用内浏览器进入商家网站完成结账。商家掌控结账流程与用户关系，聊天助手负责前期的寻找与推荐。Google 的支持文档显示，Gemini Spark 既可以连接用户本地 Chrome 浏览器复用登录状态，也可以使用远端浏览器环境。 在身份标记上，技术实现同样不等于准入许可。OpenAI 在云端浏览器说明文档中介绍，系统会用数字签名给外发请求附上可验证的身份，以便目标网站核验请求确实来自 ChatGPT。但这只是证明流量来自谁，网站核验后是放行还是阻断，依然由网站自己决定。自报身份不等于拿到门票。 Amazon 自身的产品做法也体现了这种控制逻辑。在企业服务领域，Amazon 推出了面向机构采购的业务订购接口 Business Ordering API。但这套接口面向特定合作方，有着严格的准入与授权，是一条限定的企业采购专供通道，不是通用的开放准入。 而在面向外部商城时，Amazon 自己也在购物应用中推出了代办功能 Buy for Me，替用户前往第三方商城采购商品。Amazon 表示其代办请求会自报身份，并提供了允许商家通过邮件申请退出的机制。不过，允许事后退出不代表事先得到同意，此前也有独立品牌对商品未经沟通便纳入代办表达了异议。 回到最初买办公椅的场景：技术能把浏览器从机房搬到本地，缩小网络层面的可见差异；算法也可以把操作节奏模拟得越来越像真人；行业协议也能统一数据交互格式。但只要交易发生在他人的商城里，平台依然在控制自己的网站流程、流量和广告收入，相关的条款效力与法律争议仍未定论。决定购物助手能否替人把商品买回家的，不仅在于软件能把网页操作得多熟练，也在于那家店铺在看到有人替顾客跑腿时，究竟愿不愿意把门推开。 ## 额外来源 本次事件与双方说法 - The Register：Amazon 把 Meta 的 Muse 挡在了门外（2026-09-21，记者实测与拦截页截图） - GeekWire：Amazon 封锁 Meta 的 Muse（2026-09-20，弹窗警告与 Amazon 单方说明） - The Verge：Amazon 拦截 Muse 购物（2026-09-21，此前成功买过背心的报道） - Meta Muse 官方安全文档（2026-09-08，凭证隔离设计，早于封锁） 法律文件与独立分析 - 第九巡回上诉法院意见书（2026-08-04，21 页 PDF） - Amazon 诉 Perplexity 案卷，含 2026-09-21 修订诉状 - MacStories：iOS 版 Comet 上手评测（2026-03-18，iOS 早期版上手记录） - Zenity Labs：对 Comet 桌面端的独立逆向分析 财报与行业动作 - Amazon 2025 年年报（广告收入按点击/曝光计量；2025 广告收入约 686 亿美元） - UCP 技术委员会新闻稿（2026-04-24）与 UCP 项目站 - Google：与零售商共建 agentic commerce（2026-01-11）与 Gemini Spark 支持文档 - OpenAI：Instant Checkout 调整说明（2026-03-24）与 ChatGPT 云端浏览器文档 - Shopify：agentic commerce 如何运作（2026-06-18） - Amazon Business Ordering API 文档、Buy for Me 发布说明与商家退出机制页面 - Modern Retail：品牌对 Buy for Me 未经沟通收录商品表达异议（2026-01-06） 本站前文 - Google 关掉 Project Mariner，Anthropic 和 OpenAI 其实也没跑通（2026-05-11）