Amazon 拦下 Meta Muse：AI Agent 必须学会证明「我是谁」

2026 年 9 月 20 日晚，用 Meta 的 Muse 在 Amazon 上买东西的用户开始看到一条弹窗：「未经授权的 AI Agent 持续访问违反 Amazon 使用条款。」这不是一次故障，而是一次明确的封禁。Amazon 表示从未被告知、也从未授权 Muse 访问其商城，并已要求 Meta 把 Amazon 从 Muse 的可用范围里移除。而就在两天前，Muse 还是美国 App Store 免费榜第一。这场巨头之争表面上关于「谁控制购物入口」，技术上却只关于一件很小的事：这个 Agent 有没有表明自己是谁。

当 Agent 替用户下单，身份就成了入场券

一、发生了什么：时间线与事实

Meta 于 2026 年 9 月 8 日发布 Muse，一个美国区可用的个人 AI Agent，主打多步骤任务而非一问一答，能连接邮件、日历、支付、餐饮和购物；它跑在 Meta 所称的「安全虚拟机」里，自带浏览器。它的连接机制是这次争议的中心：如果目标服务有公开 API，Muse 就用用户提供的凭据接入；如果没有 API，Meta 的说法是 Agent「可以像你本人一样，通过浏览器使用这项服务」。上线一周内，Muse 冲上 Apple 美国免费榜第一，超过 ChatGPT；早期用户描述它换过车险保单、在结账时找折扣码、还帮忙装满过购物车。9 月 20 日晚，Amazon 的封禁落地。

# What an agent should send when it acts for a user.
# Declare the agent, the principal, and prove it with a signature
# (HTTP Message Signatures, RFC 9421).
GET /dp/B0EXAMPLE HTTP/1.1
Host: www.example-retailer.com
User-Agent: MuseAgent/1.0 (+https://example.com/agent-policy)
Signature-Agent: https://agents.example.com/.well-known/http-message-signatures-directory
X-Agent-Principal: user-hash-7f3a9c        # opaque, not a raw account id
X-Agent-Purpose: shopping-assist
Signature-Input: sig1=("@authority" "@path" "user-agent")
Signature: sig1=:MEUCIQ...:                  # verifiable by the retailer

# Amazon's complaint was simple: the agent never identified itself.
# If you send nothing, expect a bot block, not a conversation.

二、Amazon 的四条具体指控

Amazon 向媒体给出的理由非常具体，值得逐条读：第一，它事先并不知情，也没有授权；第二，Muse 浏览时不会表明自己的身份；第三，Muse 似乎会捕获并存储用户凭据；第四，它会抓取账户数据。Amazon 的发言人是这样表述的：「我们认为这相当直接——代表用户在其他商家处下单的第三方应用，应当公开透明地运作，并尊重服务商是否愿意参与的决定。」对照之下，Amazon 自家的 agentic 购物功能 Buy for Me 会表明身份，并允许品牌选择退出——这正是它用来划分「合规中介」和「不受欢迎的机器人」的界线。

# Publish an agent policy so crawlers and buyers know the rules
# before they pull a cart through your checkout.
# /.well-known/agent-policy.json
{
  "version": "2026-09",
  "operator": { "name": "Example Agent Co", "contact": "[email protected]" },
  "identification": { "required": true, "signature": "http-message-signatures" },
  "actions": {
    "browse": { "allowed": true },
    "price_compare": { "allowed": true, "rate_limit": "60/hour" },
    "checkout": { "allowed": false, "requires": "partner_api_key" }
  },
  "opt_out": { "method": "headers", "header": "X-Agent-Opt-Out: 1" }
}

三、法律背景：从「黑客法」到合同条款

要理解这次为什么用弹窗而不是诉讼，得看时间线。2026 年 3 月，Amazon 就 Perplexity 的 Comet 浏览器购物行为拿到过初步禁令；但 8 月 4 日第九巡回法院推翻了它，裁定在联邦反黑客法下，「访问 Amazon 计算机」的是用户本人，而不是 AI 公司；9 月 10 日法院驳回了复审请求。这条路径被封之后，Amazon 只剩一条路：合同与使用条款。所以用户看到的提示不是在指控谁「入侵」，而是在援引使用条款——Amazon 的使用条款里确实排除了「数据挖掘、机器人或类似的数据采集与抽取工具」，但并没有明确提到 AI Agent。这恰恰是整场争论里最脆弱的接口：规则还没写好，Agent 已经来了。

// Retailer side: verify the caller, then decide. Do not guess
// "human" versus "bot" from heuristics alone.
import { verifyMessage } from "http-message-signatures";

export async function gate(req) {
  const sig = req.headers.get("signature");
  if (!sig) return deny("unidentified-agent");

  const agentUrl = req.headers.get("signature-agent");
  const keyDir = await fetchDirectory(agentUrl);      // well-known directory

  const ok = await verifyMessage(req, keyDir);
  if (!ok) return deny("bad-signature");

  const policy = await loadAgentPolicy(req.headers.get("x-agent-purpose"));
  if (!policy.allowed) return deny("purpose-not-allowed");

  return allow({ principal: req.headers.get("x-agent-principal"), policy });
}

四、技术课：Agent 身份不是一个 User-Agent 字符串

对任何要做「代表用户上网」的团队来说，这次事件给出的工程要求很清晰：你的 Agent 必须能在没有任何人工介入的情况下，向对方证明三件事——我是谁、我代表谁、我被授权做什么。行业正在往「可验证身份」方向走：用 HTTP Message Signatures（RFC 9421）对请求签名，把公钥挂在知名目录（well-known directory）里，让服务方可以离线验证；同时显式声明 principal（以不透明引用代替原始账号 ID）与 purpose（这次访问的用途）。第二件事是策略：像 robots.txt 之于爬虫那样，为 Agent 发布一份可机器读取的策略文件，声明哪些动作允许、哪些需要合作凭据、以及如何选择退出。第三件事是凭据卫生：不要捕获并保存用户的原始凭据，而是让用户侧签发一个有范围、有额度、有有效期的委托令牌。

# Delegated payment without credential capture: pass a scoped,
# single-use token instead of storing the customer's card.
def build_payment(agent, user):
    token = agent.payments.mint(
        principal=user.id,
        merchant="example-retailer",
        max_amount=250.00,
        scope=["one_time_purchase"],
        expires_in_minutes=15,
    )
    return {
        "authorization": f"Bearer {token}",   # merchant never sees raw PAN
        "on_behalf_of": user.opaque_ref,      # no raw account id in transit
    }

# Amazon said Muse "appears to capture and store customer credentials."
# The fix is architectural: never hold what you can delegate.

五、落地：五段可以照抄的代码

第一段是 Agent 请求该带的头：User-Agent 里放可追溯的身份与策略地址、Signature-Agent 指向公钥目录、用不透明的 principal 引用代替账号 ID、声明 purpose，并附上可被验证的签名。第二段是服务方的机器可读策略文件：明确 browse、price_compare、checkout 等动作的允许状态、速率限制与退出方式。第三段是服务端的网关逻辑：先验签、再查策略、最后才决定放行——不要把「人类还是机器人」交给启发式判断去猜。第四段是支付侧的委托令牌：用一次性、限定商家、限定金额、限定用途的令牌替代保存卡片，让商家永远看不到原始卡号。第五段是 Consent 审计：每次 Agent 动作都留下「谁授权、何时授权、声明了什么用途、验签结果、最终结果」。当纠纷来临时，这段记录就是一段说明和一封律师函之间的距离。

// Keep a consent record per agent action. When a dispute lands,
// this is the difference between a paragraph and a lawsuit.
await audit.write({
  ts: new Date().toISOString(),
  agentId: "muse-personal-agent",
  principal: "user-hash-7f3a9c",
  merchant: "example-retailer",
  action: "checkout_attempt",
  userConsent: { granted: true, source: "in-app", at: "2026-09-21T14:02:00Z" },
  declaredPurpose: "shopping-assist",
  signatureVerified: true,
  outcome: "denied-by-merchant-policy",
});

六、给两个阵营的清单

如果你在做 Agent：上线前先能回答「对方凭什么相信你」。带上可验证身份，声明代表谁与用途，尊重退出信号，永不捕获原始凭据，并对每一次代表用户的操作留下同意记录。如果你在运营一个网站或商城：把「封禁所有机器人」当成最后手段，而不是第一反应——因为被封的流量里，可能装着用户真实想要完成的购买。更有效的做法是把 Agent 当成一种新的客户端类型：给它一条可验证的入口、一份可声明的策略、和一个可选择的合作 API。Amazon 与 Meta 的这场对峙背后有一个很现实的商业张力：Amazon 去年广告收入超过 680 亿美元，这门生意依赖人们浏览页面；而屏蔽购物 Agent，也可能意味着错过真实订单。规则还没写完，但方向已经很清楚——先证明你是谁，然后才谈你能做什么。