大家好，我是Neo。

9月15日，Search Engine Journal 转载了 Slobodan Manic（No Hacks 创始人）的一篇文章，标题很直接：《Meta发布了两份关于Muse的文档，只有一份提到了“攻击”》。

这篇东西表面上在讲Meta的AI代理，实际上在讲你未来会遇到的第三类访客。我觉得这是近期最被低估的一篇文章，今天把它讲透，再补上其他几个数据源，凑成一个完整的判断。

先把那“一句话”拎出来

Meta 在9月8日发布了个人AI代理 Muse：能开浏览器、能填表、能代替你议价，付款走 Stripe 的 Link，跑在专用的 Muse Secure VM 里，目前只在美国开放，入口是 WhatsApp 和 Muse App。

同一天，Meta 发了两份文档：一份是给普通用户看的新闻稿，一份是给工程师看的《How We Built Safety Into Muse》。Manic 把两份文档的文本都抓下来做了词频统计，结果是：

• 在 risk、attack、attacker、mistake、untrusted、prompt injection 这几个词上，消费级公告出现 0 次，工程博客出现 39 次；
• 工程博客开篇就写：“任何这样的代理都会犯错，并且会因为它读取的数据而遭受攻击”，还明确写着“我们按’代理可能已被攻陷’来设计系统、限制潜在损失”；
• Meta 为安全报告提供最高 30 万美元赏金，其中对影响单个用户的成功提示注入（prompt injection），单项最高 13 万美元。

一家公司对工程师坦白到这个程度，其实是好事。两份文档描述的是同一个产品的两个版本：一份是“安全已经做完”的能力故事，一份是“假设它随时被攻陷”的收容故事。如果你只读了写给你的那一份，你不会知道另一份是这么写的。

但真正让我坐直的是这一句——它只出现在工程博客里：

“当 Muse 浏览互联网时，它会以你的活动形式（as your activity）出现。所以如果你让 Muse 去一家服装设计师的网站买件衬衫，那位设计师可能会用你的这次访问，在 Instagram 上给你投广告。”

这话是在描述设计，不是在承认缺陷。Muse 驱动的是“一个真实的、最新的、基于 Chromium 的浏览器”。于是那位设计师在数据里看到的，是一个人。

为什么这句话对独立站卖家是大事

把它翻译成站长语言：

• GA4 记录了一次访客访问；
• 你的再营销像素触发了一次受众写入；
• 你的广告系统开始追着一个当时正在做别的事情的人跑；
• 你的转化率、跳出率、停留时长，全部被这类“访客”污染。

而且这个访问不是爬虫。爬虫至少会报上名号（至少在大部分情况下），代理不会——它做的就是“你”。

Manic 的结论一针见血：bot规则识别的是爬虫名字，机器读的付费墙检查的是请求里的一行UA，分析工具把“浏览器执行了JS”算作真人。这三道防线的共同前提，都是“机器要么自报家门，要么不像浏览器”。而代理两个都不满足，Meta还把这件事写进了公开文档。

现在到底有多少这样的流量？三组数据

这不是未来学，当下已经在发生。

第一组，Cloudflare。 2026年6月3日，Cloudflare CEO Matthew Prince 发帖：“这事比我预测的来得更快。“Cloudflare Radar 显示，HTML网页流量里自动化请求占57.5%，人类占42.5%——这是互联网历史上第一次机器流量超过人。他原先的预测是2027年底，提前了大约18个月。补充一句：这57.5%里不全是AI代理，绝大多数还是传统爬虫和恶意机器人（约37%是恶意bot，14%是合法爬虫），但”AI代理“正是增长最快的那部分。

第二组，HUMAN Security。 其2026年《State of AI Traffic》报告显示，代理式AI流量同比增长约7,851%（是的，四位数），自动化流量扩张速度约为人类的8倍。而2026年4月的月度榜单里，浏览器型代理占代理流量的约71%：Perplexity 的 Comet 占48.12%，OpenAI 的 Atlas 占21.33%，Claude 的 Chrome 扩展占17.33%，ChatGPT Agent 占8.55%。

HUMAN 还提醒了一个容易被忽略的点：主流分析工具分不清AI代理和真人访问，更别说识别是哪个代理、想干什么。

第三组，Akamai。 其2026年电商bot威胁报告显示，接近一半（47.9%）的AI机器人流量集中在电商行业，而且点出了一个新问题：“代理式电商欺诈”和信号掩蔽（signal masking）——自主购物的代理能完美模仿人类的细微行为，让风控失去判断依据。Akamai 的安全战略CTO Patrick Sullivan 的说法是：要开始做“agentic readiness”，欢迎合法的AI，同时果断掐掉恶意的机器人。

顺带一提，Cloudflare 2026年3月曾预测bot流量在2027年超过人类，结果4月27日就跨过50%了。所有关于“代理潮什么时候到”的预测，都在被事实打脸——包括偏乐观的那些。

关键结构：你在哪一层？

Manic 扒出了一个我觉得比“流量占比”更重要的结构性问题。

Meta 的工程博客里，connector（连接器）这个词出现了11次。对Meta有合作关系的服务，根本不开浏览器：双方一起对接API，范围化的凭证、按worker划分的白名单、服务方清楚知道自己在跟谁说话。

对其余所有人，Muse 直接开一个 Chromium，然后装作是你。

所以独立站老板真正该问的问题不是“代理会不会来”，而是——我在哪一层？

• 如果Meta愿意为你做连接器，你会得到一个接口和一次谈判；
• 如果不是，你会得到一个戴着访客面具的机器。

这就是“代理式互联网”正在形成的分水岭：一边是能证明“我是谁”的代理，一边是只会“做事”的代理。

Neo的解读：这事该怎么理解，怎么做

先说我的三个判断。

判断一：你的数据会先坏，而不是你的流量先坏。 代理流量目前占比还不高（HUMAN 的统计口径是每月数百万到上千万量级请求），所以短期不会让你的总流量暴涨。但它会污染样本：代理解析价格、对比规格、跑一次结账流程，这些访问的停留时长短、页面数少、转化行为异常。如果你还不做分段，你看到的“跳出率上升、转化率下滑”，可能只是分母变了。

判断二：一刀切屏蔽代理，等于把自己的订单挡在门外。 Cloudflare 的数据里有个很现实的提醒：代理式购物者访问一两个页面、提交表单、然后离开——流量很低，但购买意图极高。有一份行业报告记录过一个典型场景：用户让代理“帮我找个水管工、约周六上午”，代理打开几个候选站点试着提交表单，被风控拦成CAPTCHA，代理没有人在旁边等着，于是直接跳去下一个候选。你什么都没做错，只是丢掉了一单。

判断三：谁先把“代理可读性”做起来，谁就先吃到这波红利。 这话我在2010年听过一模一样的版本，只不过那会儿说的是“移动端”。当时的结论是：做了响应式的站两年后笑，没做的只剩优化关键词。

现在能做、且值得做的五件事

第一件：把 robots.txt 的规则映射到服务器层。

Google 在2026年3月20日给爬虫文档加了一个新条目：Google-Agent，用于“AI助手代表真人访问网页”的场景。它和 Googlebot 最大的区别是——Google 把 Google-Agent 归类为“用户触发型抓取器”（user-triggered fetcher），因此它基本上无视 robots.txt，就像你在浏览器里输入网址时，robots.txt 拦不住你一样。想拦它或者限速它，只能在防火墙、CDN 或应用层做。

对比之下，OpenAI 的 ChatGPT-User 和 Anthropic 的 Claude-User 虽然也是用户触发型抓取器，但两家都声明会尊重 robots.txt。

这意味着：如果你把访问控制建立在“robots.txt 是万能的门”这个假设上，那已经是漏洞了。 行动项很具体——把你依赖的每一条 disallow 规则列出来，逐条判断要不要在服务器/CDN/WAF 上做等价控制；robots.txt 保留为礼貌信号，但别当安全边界。

第二件：把“三层访客模型”写成一份政策。

代理流量最忌讳的就是“全都当bot拦”。建议明确分三层：

访客类型	处理方式
真人用户	正常服务，正常风控
爬虫（含AI训练/搜索类）	按业务策略：允许、计量、或要求授权（付费抓取）
代理（代表真人执行任务）	优先放行，给单独的策略和配额；只拦那些伪装已知UA的

基线上，先把 Google-Agent、ChatGPT-User、Claude-User、Perplexity-User 这几类在日志里拉出趋势，很多站现在还是零，但基线必须先有，趋势才看得懂。

第三件：关注 Web Bot Auth，这是给代理发“数字护照”的协议。

这是一套基于 IETF 的 HTTP Message Signatures（RFC 9421）的机制：代理运营方生成一对 Ed25519 密钥，把公钥发布在一个可访问的目录（JWKS）里，然后给每个出站请求签名。网站或它前面的CDN/WAF验证签名，就能确定“来的到底是谁”。伪造在密码学上变得不可行，而不是“不礼貌”。

目前的状态（2026年）：

• Cloudflare 主导提案，2026年成立了IETF工作组；
• OpenAI 已为 ChatGPT Agent 和 Operator 的请求签名；
• Cloudflare 的 Signed Agents 计划创始成员包括 ChatGPT Agent、Block 的 Goose、Browserbase、Anchor Browser，并已并入它的 Verified Bots 体系；
• AWS WAF 已支持验证，Akamai 也支持；
• Google 从2026年5月起让 Google-Agent 用 https://agent.bot.goog 这个身份做实验性签名，但只签一部分请求，并明确建议网站继续并行使用IP段、反向DNS和UA判断。

对你我的实操结论只有一条：问一下你的CDN/WAF能不能验证签名。 能，就打开“已验证代理”的报告；不能，就催时间表。这决定你未来能不能做“分级配额”——而不是只有“全放”和“全拦”两个按钮。

第四件：把代理流量从分析里切出来。

GA4 已经有了 AI Assistant 默认渠道组，可以把来自 ChatGPT、Gemini 这类聊天机器人的引荐流量单独看。但注意：这个渠道组统计的是“代理把你推荐给了人”，和你站内的代理访问是两件事。代理到站访问，需要你自己按UA在会话维度打自定义维度，然后单独做一个看板看：

• 人类会话的行为是什么样的；
• 代理会话的行为是什么样的；
• 你的结账/询盘漏斗在两类会话里的表现差多少。

补一句现实提醒：在分段能力成熟之前，把互动指标（停留、跳出）当趋势看，别当绝对值看。因为它们的分母正在被机器改写。

第五件：让自己的站“对代理友好”——这件事其实就是在做无障碍。

Google 现在的 web.dev 官方指南明确建议把AI代理当成一类独立访客来对待，而且强调了一句很关键的话：“我们建议的每一条让网站’代理就绪’的做法，同时也会让网站对真人更好。” 代理理解页面的三种方式：截图（视觉模型）、原始HTML（DOM结构）、以及无障碍树（accessibility tree）——Google 称后者是交互元素的高保真地图。

落到具体动作上：

• 用语义化 HTML（真正的 <button>、<a>，而不是套了样式的 <div>）；
• <label for=""> 和输入框正确关联；
• 每个可交互元素都要有程序化的可访问名称；
• 布局稳定（关注 CLS，元素别乱跳——代理会点错）；
• 可点击元素加 cursor: pointer。

Chrome 团队已经把这件事产品化了：Lighthouse 从 M150 开始有了“Agentic browsing”审计类别，另外还有 WebMCP（让网站把工具以明确schema暴露给代理，而不是让代理猜按钮）的早期预览计划。如果你是技术型卖家，值得排期试一次。

最后提醒一个坑：别在浏览器端做动态内容替换（比如给代理换个电话号码）。原因很实际——大量AI爬虫根本不执行页面JS。有研究统计过5亿+次 GPTBot 抓取，没有一次执行了JavaScript；约69%的AI爬虫不具备JS执行能力。真要按爬虫类型区别对待，必须放在服务端，而且必须小心别踩到cloaking（伪装）的红线——按UA给完全不同内容的做法，在Google的垃圾政策里是有明确风险定义的。

接下来盯三个信号就行

Manic 给了三个观察指标，我觉得可以直接抄：

1. 这些代理最终会不会带上网站能验证的身份（也就是 Web Bot Auth 的落地程度）；
2. connector 名单会不会扩张——这份名单就是“能拿到接口而不是被浏览器模拟”的网站清单；
3. 下一个发布的代理，是发一份文档还是两份。

我加第四个：你的GA4里，AI Assistant渠道组的占比变化。 那是用户习惯迁移最直接的读数。

Manic 说了一句我很认同的话：今天没什么特别需要你去“做”的。但你现在怎么理解这件事，决定了三年后你在哪个位置。 移动互联网那一次，早做的人吃到的是增量；这一次的形态还没定，但方向已经很清楚了——未来你的访客里，机器人的数量会超过人，而其中一部分是“有人派来的”。