亚马逊把 Meta 的 AI 代理挡在门外，我们的 robots.txt 该怎么改

通问AI
42 阅读7分钟

2026 年 9 月 21 日周日晚起，亚马逊开始阻断 Meta 的 AI 智能体 Muse 代用户在 Amazon.com 上下单。下单环节会弹提示，说这是"未经授权的 AI 代理持续访问"，违反使用条件。

亚马逊给了三条理由：事先没收到接入通知、浏览时不表明自己是 AI、疑似采集并保存了客户账号凭证。第三条的"疑似"两个字要留着——多家报道都用它限定，亚马逊自己没公布过已确认的技术证据。

网上大部分讨论停在商业层面。我关心另一件事：这三条理由拆开看，其实就是三个工程字段。缺哪个，你的门禁就有个洞。

一、三条理由，翻译成三个字段

授权边界：对方来之前有没有通知、以什么身份来、代表谁、代表多久。落到系统里，这是一份准入登记表，不是一个布尔开关。

身份可识别性：来访者能不能被认出来是代理。它要是不自报，你还能不能从 UA、IP 段、行为节奏上判断。认不出来，后面所有分级策略都是空谈——你连"这是谁"都答不上。

数据边界：它碰到了什么。尤其它是不是拿着真人的登录态在碰。前两条是门口的事，这条进了院子。

顺序是 授权 → 身份 → 数据。任何一条不成立，门就不该开。这个顺序跟你的站点有没有交易关系不大，只要你有后台、有用户数据、有对外服务，这三个问题今天就已经存在了。

二、别再把 AI 代理当成更聪明的爬虫

这是最容易划错边界的地方。爬虫的麻烦是偷偷来；AI 代理的麻烦是它带着一个真人的授权来。据 The Verge、IT之家、The Decoder 的报道，Muse 是 Meta 面向个人用户的 AI 助手，用户让它代自己办事，包括买东西。

来访的不是一个无主的机器人，是客户派来的代表。技术上它带着真实登录态，很难和真人区分；你封 IP，IP 会变。商业上你拒绝它，可能等于拒绝了自己的客户。法律上它代表谁、责任归谁，现在没有清晰共识——亚马逊对是否诉诸法律拒绝置评，这本身就说明这块地还没路。

所以 robots.txt 里那句孤零零的 User-agent: *，管的根本不是这一类东西。

三、分级准入：一份能落地的 robots.txt

下面这份是示例配置，不是任何一家公司的真实文件，别照抄，按自己的准入清单改。

# /robots.txt
# 分三组：只读型抓取 / 带登录态的代理 / 其余

# 1) 公开信息抓取类：放开产品、价格、FAQ，其余不放
User-agent: GPTBot
User-agent: ClaudeBot
User-agent: PerplexityBot
Allow: /product/
Allow: /pricing/
Allow: /faq/
Disallow: /account/
Disallow: /admin/
Disallow: /*?session=
Crawl-delay: 2

# 2) 代用户操作的代理：默认不放行，走白名单另行登记
User-agent: Muse
Disallow: /

# 3) 兜底
User-agent: *
Disallow: /account/
Disallow: /api/

配完之后配一份 llms.txt，把允许被摘要的页面按优先级列出来。它和 robots.txt 分工不同：robots.txt 说"能不能来"，llms.txt 说"来了先看哪几页"。很多团队只写前者，结果是 AI 进来之后在一堆营销页里自己挑。

# /llms.txt
> 站点名：一行说清你是谁、做什么

## 可摘要
- /product/：产品与规格，价格以页面为准
- /pricing/：价格区间与计费方式
- /faq/：常见问题

## 不摘要
- /method/：方法论原文，需署名引用
- /tools/：需登录使用

四、UA 判定：靠声明，不靠猜

声明优先，猜是兜底。 UA 里带明确 token 的按白名单走，不带的进打分，别一刀切。

DECLARED = {  # 自报身份的，直接采信
    "gptbot": "readonly_crawler",
    "claudebot": "readonly_crawler",
    "muse": "delegated_agent",
}

def classify(ua: str, ip: str, rate_1m: int, has_session: bool) -> tuple[str, float]:
    key = ua.lower()
    for token, kind in DECLARED.items():
        if token in key:
            return kind, 0.95
    # 没声明：看行为特征，只给置信度不出结论
    score = 0.0
    if rate_1m > 60:
        score += 0.35
    if is_datacenter_ip(ip):
        score += 0.25
    if has_session and no_mouse_events():
        score += 0.2
    return ("likely_agent" if score >= 0.6 else "unknown"), min(score, 0.9)

重点是最后一行：打分不出结论。置信度不够就标 unknown 放行只读，别因为 score > 0.5 就把一个真客户拦掉。误杀的成本比漏放高。

五、日志里要能事后回答"刚才那是谁"

绝大多数站点的访问日志回答不了这个问题。最小的改动是在日志里加四个字段，出事的时候才能复盘。

{
  "ts": "2026-09-21T21:14:03+08:00",
  "path": "/product/x200",
  "ua": "Muse/0.9 (+bot-policy-id)",
  "agent_class": "delegated_agent",
  "identity_confidence": 0.95,
  "session_owner": "user_88213",
  "auth_mode": "delegated_token",
  "rate_1m": 34,
  "scope": "read_only",
  "decision": "allow_readonly"
}

auth_mode 和 scope 是这里最值钱的两个。前者区分"主登录态"和"委派令牌"，后者记它当时被允许做什么。等你要写事故报告的时候，能说清"它当时只有只读权限"和说不清，是两回事。

六、凭证隔离：别让它用主人的钥匙

亚马逊第三条理由指向的就是这一层。工程上能做的几件事：

  1. 委派令牌和主登录态分开签发，scope 显式声明，默认只读。
  2. 令牌 TTL 压到分钟级，代下单这类高权限动作单独二次授权。
  3. 令牌上绑 agent_class，后台能一眼看出这个会话背后是不是代理。
  4. 令牌可撤销，撤销要在网关层立即生效，不要等自然过期。

这几条不难，难的是很多站点压根没有委派令牌这层——代理直接复用用户的 Cookie，后台看到的就是"一个正常登录的用户"。这种情况下你根本没数据去证明或反驳"疑似采集凭证"这类指控。

七、别全开。全开会被自己反噬

这是开放边界上最容易被忽略的一面。内容和入口全放开之后，用户还需要访问你的站点吗？如果 AI 已经把价格、服务、优势完整答了，漏斗前端就被抽走了，你换来的是"被引用"这个名义曝光。

判断原则只有一条：区分哪些是可以被摘要走的结论，哪些是必须亲临才能获得的价值。公司是谁、做什么、价格区间、服务范围，这部分开放成本低、收益明确。深度方法论、诊断过程、可操作的工具、一对一判断——这是你真正的货，不该被压成一段摘要送人。

不是开得越多越好，是开得越准越好。

八、改完必须实测，不能猜

两个动作，成本都很低。

一是把关键路径用 curl 逐条请求一遍看返回码，确认你以为关掉的真的关了。改 robots.txt 最容易出的错是写了一条 Disallow，结果因为路径前缀不匹配，页面照样进得来。

# $SITE 换成你自己的站点地址，带协议前缀
for p in /product/x200 /pricing/ /account/ /api/order; do
  printf "%-16s %s\n" "$p" "$(curl -s -o /dev/null -w '%{http_code}' -A 'Muse/0.9' "$SITE$p")"
done

二是去几个主流 AI 里问三个只有你官网才答得准的问题，看它引用了谁、有没有引你。验收标准不该是"内部看着觉得挺好"，而是"外部 AI 有没有读到"。

顺便说一句，读不到也不代表做错了。内容可读只是被引用的必要条件，不是充分条件。先发生变化的通常不是引用量，而是你的站点从"说不清自己是谁"变成"说得清"。

收一句

这次亚马逊做的是拒绝，不是迎接。它动用平台权力把一个代理挡在门外，还要求对方把自己从服务列表里删掉。多数团队的处境更接近亚马逊这边——你是被敲门的那个，不是想进去的那个。

所以先建的能力不是让 AI 更容易读到你，而是想清楚让谁进、怎么进、什么时候不让进。文件改错了还能回滚，顺序错了，后面全白做。

avatar
文章
阅读
粉丝