爆火的Meta Muse 撞上亚马逊的“墙”

本文来自微信公众号： Internet Law Review ，作者：张颖

近日，Meta智能体Muse爆火，登顶美国应用市场头把交椅。但同时，亚马逊开始对使用Muse购物的用户进行“弹窗”：Muse属于“未授权AI智能体”，继续使用将违反亚马逊的使用条款（ToS）。这一举措距离Muse发布只过了18天。

这不是亚马逊第一次对第三方智能体出手。去年11月，亚马逊起诉Perplexity AI，指控其Comet浏览器中的购物助手未经授权访问亚马逊系统。诉讼一波三折：今年3月，初审法院批准亚马逊的初步禁令，意味着Perplexity行为被认为存在不妥；但8月4日，第九巡回上诉法院撤销该禁令；9月10日，亚马逊的全席复审请求也被驳回。

不过，第九巡回法院的裁决仅仅暂时厘清了智能体“不是黑客”的问题，并不意味着Perplexity可以“不经平台同意继续访问”——法院用一句话为亚马逊封禁其他智能体提供了另外一个合法性基础：“此结果不损害亚马逊通过其服务条款来管理Amazon.com访问的能力”。

一、Muse和Perplexity：技术不同，对应法律支撑也不同

Muse被亚马逊封禁，表面上与Perplexity案相似，但技术架构却存在实质性差异，法律评价因此可能不同。

按Meta在9月8日发布的公开信息，Muse的个人智能体功能运行在Meta云端名为“Muse Secure VM”的专用虚拟机之中。向亚马逊页面发起的请求来自Meta的云虚拟机，用户本机浏览器并不参与；登录状态、会话与凭据，实际处于Meta云基础设施的控制之下。

Perplexity的Comet走的则是另一条路。它运行在用户本地设备，只把页面截图上传至Perplexity服务器生成操作指令，真正向亚马逊服务器发起点击、跳转、下单请求的，仍是用户自己的浏览器。账号、Cookie、会话都留在本地。

这一差异之所以决定命运，是因为美国法院目前评价“智能体代客进入第三方平台”，首先要看它在什么位置运行、请求由谁发出。在亚马逊诉Perplexity案中，第九巡回法院推翻初审禁令的核心观点只有一句：“Perplexity本身并未直接与亚马逊的服务器通信”，因此“是用户在访问（access）亚马逊的计算机”。

这背后的法律逻辑并不复杂。CFAA规制的是“未经授权访问”这一行为，而实施访问的主体，决定了“责任由谁承担”。请求从用户本机发出时，法院看到的是用户本人在访问；请求从厂商云环境发出时，法院看到的是一个由厂商控制的系统在访问。同一段购物流程，因为服务器位置不同，落进了两条不同的责任轨道。

由此可以得出一个对两家都适用的推论：Comet作为用户本地“工具”，其访问更接近“用户本人的访问”；Muse在“第三方云环境”下的访问，更接近“智能体代替用户访问”，很难获得同样的法律评价与豁免。亚马逊似乎刚刚在Perplexity案中遭遇“失利”，随后就又果断封禁Muse，其理由依据就在这里。因此，一定程度上讲，第三方AI智能体和平台的关系，已经从“是否构成非法入侵”的争论，更具象化地转向到“合同条款能否限制智能体”。

二、给亚马逊“递刀子”的，恰恰是10年前的Meta自己

吸取了Perplexity的教训，亚马逊这次把矛头从“闯入”移到了每位客户开户时都接受的规则上。它在Muse加载亚马逊搜索页面之前就阻断其访问，弹窗提示：“未经授权的AI代理继续访问，违反了亚马逊的使用条件，我们的客户已同意该条款。”

亚马逊这次不再指控智能体“入侵”，它援引的是客户已经同意的合同。按第九巡回法院对Perplexity禁令的裁决可以预判，亚马逊很难用《计算机欺诈与滥用法》（CFAA）证明智能体构成非法入侵。但法院同时留了一个关键的口子：裁决明确不损害亚马逊“通过其私人服务条款管理Amazon.com访问”的能力。反黑客法的路走不通，合同条款的路仍有可能。

有意思的是，给亚马逊这条“合同路径”提供先例的，正是Meta自己。

2016年的Facebook vs.Power案中，Power.com经用户同意、以用户账号密码登录，聚合社交数据并向用户好友推送推广信息。Facebook发出停止函（cease-and-desist letter）并限制其IP后，Power通过更换IP继续访问。第九巡回法院认定：用户的同意不构成对第三方无期限、不可撤销的访问授权；平台以书面函件撤回许可后，第三方继续绕开限制访问受保护计算机，即构成CFAA项下的“未经授权访问”。

这个判例一定程度上为智能体场景确立了有参照意义的规则解释：

1.用户授权与平台授权分属两个层面。用户的授权不能当然抵消平台依据ToS对“何人、以何种架构、在何种范围”进入所设置的限制。

2.平台的授权可以被撤回。平台若以ToS明确第三方的身份与停止义务，再以书面通知撤回许可，第三方继续强行接入，就落入“授权被撤销后继续访问”的事实框架；任何技术手段都不能成为免责理由。

两条规则合起来，对Muse构成了直接约束：本机辅助型智能体（如Comet）可以靠技术架构弱化反黑客责任，但云端代理型智能体（如Muse）一旦回避身份、持续接入，服务条款与撤回通知是平台拒绝它的正当依据。

三、用户点头≠平台放行

亚马逊公开对Muse提出三项异议：1）未事先告知且未取得平台授权；2）浏览时不自我标明智能体身份；3）疑似抓取并存储客户凭证。

第三项显然在社会层面最为敏感，也恰恰是Meta唯一做出回应的地方：“Muse无法查看用户的密码或支付方式。”

仔细看，这场争议中，双方其实各说各话：亚马逊抗议的是Meta在“抓取并存储”（capture and store）客户凭证，Meta否认的是Muse能够“查看”（see）客户凭证。显然，Meta的反驳回应了“可见性”的质疑，却没有回答“持有性”的事实与否。Muse的解释里，登录信息被存放在它自有的安全环境中、代理无需直接访问即可使用——这恰恰符合公众对“存储”的理解。

对用户而言，自己包括密码在内的一系列凭证被第三方所存储，这涉及到隐私关切；对平台运营者而言，客户的信息被第三方所“掌握”，这涉及到控制权的配置。按亚马逊的ToS，Muse若不表明身份、不事先告知访问范围，亚马逊就只能把它视为“未披露、也未授权持有客户凭证的第三方”。此时的隐私风险，落在一个未经平台选择的受托方身上——它取得了可以代替用户持续访问受保护账户的能力。这当然涉及到更复杂的问题，对用户来说是隐私与信任，对平台来说是安全与治理权。

智能体身份披露衍生出的第二个问题，是法律责任的归属。如果Muse在代客操作中出现“幻觉”或错误，而错误订单里找不到任何“智能体”的身份，后果只能由用户、平台或平台商家承担。身份缺失直接导致了责任无法追溯的问题，这正是“申报身份”成为平台规则中“双重授权”必要环节的原因。

双重授权对用户来说也并不意味着负担，而是具有一定必要性。用户授权解决的是“我愿意让谁替我操作”，平台授权解决的是“这个代理进入平台之后处在什么位置、出了问题找谁”。缺少后者，用户得到的是一段无法追责的代理关系：订单下错了，可能找不到责任主体；账户被限制了，也说不清是谁的过错。

四、把“半张通行证”补全

值得注意的是，亚马逊自己也在做AI智能体的探索。去年起在平台内运营Buy for Me，今年其被并入Alexa for Shopping，该智能体也能在亚马逊之外的品牌独立站购物。亚马逊的说明是：品牌如不愿被纳入其智能体使用范围，可邮件申请退出，亚马逊会及时移除；同时，Alexa在使用时会表明自己的智能体身份。

可以看到，亚马逊给了其他品牌“事后退出的权利”，也实质上承认了其自身在价值上认可的一件事：智能体进入平台，需要申报身份、告知范围、确立退出机制。从这个角度说，企业都有必要用同一套标准“待人”和“律己”。任何平台如果对自有智能体与第三方智能体区别对待，反垄断、平台中立与广告入口的争议都可能成为监管机构或其他第三方撬动平台入口的杠杆。这一点无需过多展开论证，道理是相通的：双重授权应当是双向的。

由此可见，虽然Perplexity案子的波折，和目前亚马逊对Muse的处置有所差异，但两件事共同指向：智能体进入第三方平台，无法回避“双重授权”的问题——用户授权，回答的是“允许谁代我操作”；平台授权，回答的是“允许谁以什么身份、什么范围进入”。缺任一项，安全与责任都无处安放。

从美国的案例看，其对全球AI智能体发展所给出的启示是：

短期看，平台出于用户隐私、平台安全、商业利益等因素考量，把第三方AI智能体视为未经授权的入侵者，默认“禁止进入”。因此任何想要访问的第三方智能体，如果不先与平台沟通条款，强行接入必然会遭遇巨大阻力。无论从安全角度还是商业角度，这都具有一定合理性和必要性。

中长期看，“封禁”并不解决任何问题，平台与智能体通过谈判和行业规则，大概率会走向标准化的合作：平台提供服务条款，智能体提供身份申报与操作范围协议，双方在“身份、授权、范围、责任”四项要素上形成新的共识。把“双重授权”从个案抗辩变成行业标准，或许既是这场争端真正的出口，也是Muse、Perplexity以及无数AI智能体都还需要补上的那张通行证。