AI 代理准入治理实战：从亚马逊阻断 Meta Muse 看网站门禁改造

一、事件2026 年 9 月 21 日周日晚起亚马逊开始阻断 Meta 的 AI 智能体 Muse 代用户在 Amazon.com 购物下单环节弹提示称这是未经授权的 AI 代理持续访问违反使用条件。三条理由未获接入通知——据 The Verge、TechCrunch、IT之家、The Decoder 四家媒体 2026 年 9 月 21 日的报道亚马逊称事先未收到 Muse 的接入告知。浏览时不表明 AI 身份——IT之家、The Decoder、The Verge 的报道均提到亚马逊对这一点的关切。疑似采集保存客户账号凭证——疑似二字要留着。多家报道都以它限定亚马逊并未公布已确认的技术证据。二、为什么技术团队要在意主流解读是AI 代理时代来了赶紧让 AI 读到你的内容。这个读法漏了一半亚马逊做的不是迎接是拒绝——它把一个代理挡在门外还要求对方把自己从服务列表里删掉。多数站点的位置更接近亚马逊你是被敲门的一方。先建的能力不是让 AI 更容易读到你而是想清楚让谁进、怎么进、什么时候不让进。顺序错了后面全错。三、AI 代理不是升级版爬虫爬虫的麻烦是偷偷来AI 代理的麻烦是它带着真人的授权来。据 The Verge、IT之家、The Decoder 的报道Muse 是 Meta 面向个人用户的 AI 助手用户让它代自己办事包括买东西。来访的是客户派来的代表不是无主机器。三个层面的变化技术上它带着真实登录态难与真人区分封 IP 收效有限商业上拒绝它可能等于拒绝自己的客户法律上它代表谁、责任归谁没有共识亚马逊对是否诉诸法律拒绝置评。代表和爬虫不该被同一套规则对待而多数站点的 robots.txt 里只有一句User-agent: *。四、三条理由对应三个工程字段亚马逊的理由字段系统里该有什么未获接入通知授权边界准入登记表谁来、以什么身份、代表谁、有效期不表明 AI 身份身份可识别性UA 白名单 行为打分 置信度疑似采集凭证数据边界委派令牌、scope、TTL、可撤销框架是授权 → 身份 → 数据任何一条不成立门就不该开。只要有后台、有用户数据这三个问题今天就在。五、步骤一先画准入清单别先改文件。技术加业务一起把表填出来填不出来改 robots.txt 就是瞎改。问题要填的内容哪些页面必须让 AI 读到产品、价格、FAQ、资质、联系方式哪些页面必须拦住后台、用户数据、内部文档、未发布内容希不希望代理自报身份不报的话靠什么识别代理持真人登录态访问数据处理动作是什么拒绝一个代理时是否留申诉通道谁负责没有技术团队的话靠什么识别代理不是半天能解决的涉及 UA 白名单、IP 段、行为特征。中小团队更现实的做法是先列清开关清单识别能力从能认出常规爬虫起步。六、步骤二分级准入配置以下是示例不对应任何一家公司的真实文件。# 分组1公开抓取类只放开产品/价格/FAQ User-agent: GPTBot User-agent: ClaudeBot Allow: /product/ Allow: /pricing/ Allow: /faq/ Disallow: /account/ Disallow: /admin/ Crawl-delay: 2 # 分组2代用户操作的代理默认不放行走白名单登记 User-agent: Muse Disallow: / # 分组3兜底 User-agent: * Disallow: /account/ Disallow: /api/再配一份 llms.txtrobots.txt 回答能不能来llms.txt 回答先看哪几页。只写前者代理进来后会自己乱挑。# /llms.txt 站点名一行说清你是谁、做什么 ## 可摘要 - /product/产品与规格 - /pricing/价格区间与计费方式 - /faq/常见问题 ## 不摘要 - /method/方法论原文引用需署名 - /tools/需登录使用七、步骤三身份判定与日志声明优先猜测兜底。UA 里有明确 token 的按白名单走没有的进打分。DECLARED{gptbot:readonly_crawler,claudebot:readonly_crawler,muse:delegated_agent}defclassify(ua,ip,rate_1m,has_session,has_pointer_events):fortoken,kindinDECLARED.items():iftokeninua.lower():returnkind,0.95# 自报身份直接采信score0.0ifrate_1m60:score0.35ifis_datacenter_ip(ip):score0.25ifhas_sessionandnothas_pointer_events:score0.20return(likely_agentifscore0.6elseunknown),min(score,0.9)关键在最后一行打分不出结论。置信度不够就标unknown并按只读放行别因为score 0.5拦掉一个真客户误杀的代价高于漏放。日志里补几个字段出事才复盘得了{ts:2026-09-21T21:14:0308: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记当时允许它做什么。能说清它当时只有只读权限和说不清是两回事。八、凭证隔离别让代理用主人的钥匙对应第三条理由。工程上四件事委派令牌与主登录态分开签发scope 显式声明且默认只读TTL 压到分钟级代下单这类高权限动作单独二次授权令牌绑agent_class令牌可撤销撤销在网关层立即生效。难点不在实现在很多站点根本没有委派令牌这一层——代理直接复用用户 Cookie后台看到的就是一个正常登录的用户。这种情况下你既没有数据证明疑似采集凭证也没有数据反驳它。九、两个反面门关上之后内容优化会失效。内容侧优化的全部作用建立在AI 能读到你的内容上前提不成立方法归零。大量站点把 AI 锁在门外这个说法也要谨慎常见统计口径是 robots.txt 里存在任意一条 Disallow 规则这类规则拦的多是参数路径和后台路径公开产品页往往是开放的。更准确的说是大量站点对开放边界没有清晰规划。全开会被自己反噬。内容全开、答案全前置之后用户还需要访问你的站点吗AI 把价格、服务、优势完整答了漏斗前端就被抽走。判断原则是区分可被摘要走的结论和必须亲临的价值公司是谁、做什么、价格区间、常见问题开放成本低、收益明确深度方法论、诊断过程、可操作的工具、一对一判断这是真正的货不该被压成摘要送人。开得越准越好。十、实测验收curl 逐条验返回码。改 robots.txt 最常见的翻车是写了Disallow因为路径前缀不匹配页面照样进得来。# $SITE 换成你自己的站点地址带协议前缀forpin/product/x200 /pricing/ /account/ /api/order;doprintf%-16s %s\n$p$(curl-s-o/dev/null-w%{http_code}-AMuse/0.9$SITE$p)done用外部 AI 反向验证。找几个人在主流 AI 里问三个只有你官网才答得准的问题看它引用了谁。验收标准不该是内部看着挺好而是外部 AI 有没有读到。十一、两条限制读不到不等于做错了。内容可读只是被引用的必要条件不是充分条件三步做完 AI 依然可能引用行业媒体或比你早做三年的人。先发生变化的通常不是引用量而是站点从说不清自己是谁变成说得清——客服重复咨询变少新人上手变快。这些收益在被引用之前就已经到账。小结亚马逊这次做的是拒绝。多数团队第一件事是治理准入授权 → 身份 → 数据按序补齐第二件事才是边界内的内容优化。文件改错可以回滚顺序错了全是白做。