亚马逊封禁了Meta的Muse，随后Shopify却将其接入每一家店铺。
内容提要
亚马逊封禁Meta的AI购物代理Muse，因其未申报身份、伪装成登录用户浏览并疑似存储凭证，反映代理流量的身份认证问题。亚马逊依据使用条款封禁而非诉讼，因法院裁定用户而非助手构成访问。Shopify则与Meta合作，通过声明式结账和一次性凭证接入代理。文章建议网站明确准入政策，采用签名身份协议如Web Bot Auth，并区分公开页面、登录页面和结账流程，以结构化路径替代封堵。
延伸解读
法律裁决如何改变封禁策略
文章提到第九巡回法院在8月初的裁决中撤销了亚马逊对Perplexity的初步禁令，认定用户而非助手构成访问。这意味着网站很难再以“非法入侵”为由起诉AI代理，因此亚马逊转向使用条款封禁。对运营者而言，法律诉讼不再是阻止代理的有效工具，更可靠的方式是在自身基础设施中实施封禁，并明确准入政策。
签名身份协议的作用与局限
文章介绍了IETF的Web Bot Auth草案，它基于HTTP消息签名，让代理用私钥签名请求，验证方通过公钥目录确认代理运营者。Cloudflare和AWS WAF已支持此类验证。但签名只能识别代理背后的运营者，无法确认实际用户身份或授权范围。因此，签名解决了披露问题，但授权问题仍需通过一次性凭证等机制单独处理。
Shopify与亚马逊的不同选择
亚马逊封禁Muse，因为其自有店面、推荐和助手，外部代理隐藏身份会夺走客户关系。Shopify则向商家出售基础设施，每增加一个代理渠道并通过Shop Pay结算，都强化其底层轨道。文章指出，关键区别在于谁拥有需求界面。这解释了同一代理在24小时内被一家封禁、被另一家合作的原因。
企业应依次回答的三个问题
文章建议企业按顺序解决三个问题：首先是准入，需分别针对公开页面、登录页面和结账流程制定政策并公开；其次是替代，封堵浏览器代理的同时提供结构化路径，如目录feed、MCP服务器或ACP端点，将敌对流量转化为可计量的渠道；最后是授权，使用与命名代理和支出限额绑定的可撤销令牌，避免存储密码被重放。
Q&A
亚马逊为什么封禁Meta的AI购物代理Muse？
亚马逊封禁Muse的原因有三点：Meta未告知亚马逊Muse会访问其商店；代理在浏览时不表明身份；代理似乎捕获并存储了客户凭证。亚马逊认为这违反了其使用条款，因此通过弹窗阻止未授权AI代理继续访问。
亚马逊为什么选择封禁而不是起诉Meta？
因为法院裁定用户而非助手构成访问。第九巡回法院在Perplexity案中撤销了初步禁令，认为指导Comet助手的用户才是访问亚马逊计算机的一方，助手只是工具。因此诉讼难以阻止代理，封禁在自有基础设施中更可靠。
Shopify如何与Meta合作接入Muse？
Shopify与Meta合作，通过声明式结账和一次性凭证接入Muse。Muse读取结构化产品数据，通过声明路径完成支付，商家知道代理在交易，且每次购买使用一次性凭证，卡号不会到达Muse。
什么是Web Bot Auth？它如何解决代理身份问题？
Web Bot Auth是一个IETF草案，基于HTTP消息签名（RFC 9421）。代理用私钥签名请求，并在自己域名的知名目录发布公钥。验证方读取Signature-Agent头，获取密钥集，从而知道调用者身份。Cloudflare和AWS WAF已支持。
网站应如何制定代理准入政策？
网站应分别针对公开页面、登录页面和结账流程制定政策，并发布在代理供应商能找到的地方。同时，应提供结构化路径（如目录feed、MCP服务器或ACP端点）来替代封堵，将敌对流量转化为可计量的渠道。
亚马逊和Shopify对同一代理的态度为何截然不同？
因为商业模式不同。亚马逊运营自己的店面、推荐和助手，外部代理隐藏身份会夺走客户关系且无回报；Shopify向商家出售基础设施，每个新代理渠道通过Shop Pay结算都会强化其底层轨道。关键区别在于谁拥有需求界面。
