AI 流量控制方案横评 2026：Cloudflare、Akamai、Vercel 的分类口径差在哪
Cloudflare 在 2026 年 7 月之前，AI 爬虫只有一个开关：挡还是不挡。现在三家主流方案都是分类管控，而且拆法出奇一致，都是训练、搜索、实时代抓这三类。差别在于每类叫什么名字、默认是放行还是拦截、以及你能精确到什么粒度。做跨境电商的卖家要在这里做选择，因为挡错一类的后果不一样：挡掉训练爬虫是少被模型记住，挡掉实时代抓是用户在 ChatGPT 里点你的链接时页面打不开。
三家的分类口径对照
| 方案 | 分类名称 | 默认动作 | 粒度 | 能不能硬拦 | 设置位置 |
|---|---|---|---|---|---|
| Cloudflare | Search / Agent / Training | 2026 年 9 月 15 日起，新接入且页面带广告的域名默认拦 Training 和 Agent，放行 Search | 三类各自独立开关 | 能 | 控制台的机器人管理设置 |
| Akamai | 训练爬虫 / 搜索爬虫 / fetcher | 按策略配置，无统一默认 | 按分类加单个 bot 指纹 | 能 | Bot Manager 策略 |
| Vercel | 训练 / 搜索 / 用户触发抓取 | 需要主动启用规则集 | 规则集内按类别 | 能 | 防火墙里的 AI bots 托管规则集 |
| robots.txt | 按 User-agent 自己写 | 无，纯声明 | 到单个 UA 和路径 | 不能 | 站点根目录 |
三家不约而同切成这三类，是因为这三类流量的商业含义完全不同。训练爬虫抓一次，内容进模型，你短期看不到任何回报，回报在几个月后模型回答问题时。搜索爬虫抓一次，内容进 AI 搜索的索引，几天内就可能被引用。实时代抓这一类抓一次，对面就有一个真人在等答案。这三种请求可能来自同一家公司的同一个 IP 段，对你的生意却是三笔完全不同的账。
Cloudflare 这次改动的时间点是 2026 年 7 月，它把原来那个「拦截 AI 爬虫」的单一开关换成了三个独立管理的类别。Agent 这一类指的是实时代表某个人执行的自动访问，典型例子是聊天工具在用户提问时去抓页面的那种请求。
9 月 15 日那条新规则只作用于新接入 Cloudflare 的域名，而且只作用于展示广告的页面：Training 和 Agent 默认拦，Search 默认放。已经在 Cloudflare 上的老域名不受这条影响，但值得自己进去确认一遍当前三个类别各是什么状态。这条变化的逐项排查清单在另一篇里单独写了，这里不重复。
有一点 Cloudflare 自己说得很明确，受影响的是那些同时做搜索和训练的多用途爬虫，也就是身份混合的那些。Cloudflare 没有点名具体是哪几个，所以别自己往下推某个搜索引擎的爬虫会不会被挡。
三类流量对电商站的价值排序是固定的。Agent 最值钱，因为对面是一个正在比价的真人，抓不到你的页面就等于这单没有你。Search 次之，它决定你在 AI 搜索结果里出不出现，时间尺度是天到周。Training 最不紧急，它影响的是几个月后模型里有没有你的品牌知识。排查和配置也照这个顺序走。
Akamai：名字不一样，切法一样
Akamai 把 AI 流量分成训练爬虫、搜索爬虫和 fetcher 三类。对着上面那张表看，这就是 Cloudflare 的 Training、Search、Agent 换了个说法，fetcher 对应的就是用户发起的实时抓取。
Akamai 公布过一个数字，它自己网络上的 AI bot 流量，从 2025 年到 2026 年初涨了超过 300%。按这个量级，你现在写的任何一条 AI 流量规则，影响的请求数都比一年前大一截，配错的代价也跟着放大。
涨 300% 还有一个成本维度。做流量策略之前先拉一下这部分请求的缓存命中率。命中率低意味着它们直接打到源站，账单和源站负载都跟着涨，这种情况下先优化缓存比先配拦截规则更划算，而且不损失任何可见度。命中率本来就高的话，这部分流量的成本压力有限，直接去做分类策略就行。
Akamai 安全团队公开写过一句话：把 AI agent 一刀切拦掉，等于主动退出购买决策正在发生的地方。用户在 AI 助手里问「哪个牌子的登山杖轻」，助手去抓你的产品页，你把这类请求挡了，你就不在候选名单里。
Akamai 的粒度是三家里最细的，除了按类别，还能针对单个 bot 指纹配策略。代价是它是企业级产品，配置和计费都按企业合同走，小店用不上也买不起。
指纹级粒度什么时候真的用得上？同一个类别里两个爬虫表现完全不同的时候。比如都归在 fetcher 里，一个每天来几百次、抓完就走，另一个短时间内把你的全站产品页扫一遍。前者该放，后者该限速。只有按类别的开关做不到这种区分，要么两个都放进来，要么两个一起挡掉。
Vercel：跟着部署走的规则集
Vercel 的 AI bots 托管规则集管的是三类流量：为训练数据来抓的、为搜索来抓的、以及用户触发的抓取。它是托管规则集，也就是 Vercel 维护这张 bot 名单，你只决定每类怎么处理。
Vercel 另外还有 BotID，用来识别自动化请求本身，跟 AI bots 规则集解决的是两个问题。规则集管的是「这个已知的 AI 爬虫要不要放进来」，BotID 管的是「这个来路不明的请求是不是机器人」。两个一般同时开。
Vercel 这套的好处是跟项目走，规则跟着部署配置一起管理，团队里做前端的人自己就能改。对 headless 架构的店来说这点很实际，因为这类站的运维往往就是前端团队自己。
限制是它只覆盖跑在 Vercel 上的流量。如果你的产品页在 Vercel，图片和评论接口在别的域名下，那部分流量这套规则管不到，要另外处理。
每一类选什么动作也要想一下。放行和拦截之外，一般还有一档是加验证挑战。挑战这一档对 AI 爬虫基本等于拦截，因为它们不会去过人机验证。想让某类爬虫少抓一点又别彻底抓不到，挑战这个选项帮不上忙，该找的是速率限制。
robots.txt 是零成本起点，但它只是声明
不管你用哪家，robots.txt 都该先写对。它不花钱、改一行就生效、粒度可以精确到单个 User-agent 加路径，是唯一一个所有站点都能立刻做的动作。
它的问题是没有强制力。robots.txt 是给爬虫看的一份声明，遵守与否取决于对方。守规矩的爬虫会读，不守规矩的照抓不误。拿它当防护手段的话，你挡不住任何一个真想抓的爬虫。
正确的用法是两层叠加：robots.txt 写清楚你允许谁、禁止谁，边缘层的规则负责真正执行。两层的内容要对得上，robots.txt 里写着允许、边缘层却在拦，这种不一致会让你在排查「为什么 AI 搜索里搜不到我」的时候多花好几天。
电商站的 robots.txt 里有几个路径值得单独写规则，跟 AI 无关也该写：带筛选参数的列表页、站内搜索结果页、购物车和结账页。这几类页面对任何爬虫都没有价值，放开只会把抓取预算浪费在几万个内容几乎一样的 URL 上。产品页、分类页、内容页这三类才是你希望被抓的。
还有个方向值得盯着：IETF 正在制定 Bot Service Index（BSI），做的是一套发现机制，让 agent 能用密码学手段证明自己的身份。现在所有规则都建立在 User-agent 字符串和 IP 段上，这两样都能伪造。BSI 落地之后，「这个请求真的来自某个 AI 助手」才第一次变成可验证的事。这东西还在制定中，现在不用做什么，但如果你在设计未来一年的流量策略，把它当成方向。
三种卖家怎么选
Shopify 店，Cloudflare 免费版。 你能动的就是那三个类别开关加 robots.txt。建议是 Search 放行、Agent 放行、Training 按你对内容被拿去训练的态度来定。产品描述和评价被拿去训练，换来的是模型里有你的品牌，对小店多半是划算的。要确认的是 Agent 这一类没有被挡，挡了就是丢实时的购买咨询流量。
headless 店，跑在 Vercel。 先把 AI bots 托管规则集开起来，别停留在默认没启用的状态。然后盘一遍你的域名，把不在 Vercel 上的那部分单独处理。BotID 建议同时开，它管的是结账和表单接口被脚本刷的问题，跟 AI 流量是两回事但同样要防。
企业级卖家，用 Akamai。 你的优势是能按单个 bot 配策略，用起来。具体做法是先按类别定一个基线，再对高价值的几个 AI 入口单独放宽，对可疑指纹单独收紧。配置前先拉一份自己站点的 AI bot 流量构成，别照搬行业默认值，不同品类的 AI 流量来源差别很大。
还有一种常见情况是叠了两层：站点跑在 Vercel 上，前面又挂了 Cloudflare。这种配置下两套规则都生效，而且 Cloudflare 在前面先判断。排查的时候按从外到内的顺序看，别在 Vercel 的规则里找为什么请求根本没到。两层都配了 AI 规则的话，把其中一层设成全放行，只保留一层做判断，省得以后自己都说不清是哪条规则起的作用。
三种情况下都建议做同一件事。改完规则之后隔一周，用几个 AI 助手实际搜一下自己的品牌词和主推产品，看引用有没有变化。后台的开关状态不会告诉你 AI 那边现在还引不引用你，这件事只有搜一遍才知道。
Read this article in English: AI Traffic Control Compared 2026: How Cloudflare, Akamai and Vercel Classify Bots Differently
相关文章
AI 商品数据富化工具对比 2026：Salsify、Feedonomics、Productsup 到底差在哪
三家名字听着像在干同一件事，实际定位完全不同：Salsify 是产品内容治理，Feedonomics 是托管式 feed 分发，Productsup 是企业级目录管道。选错了就是花钱买了个自己用不上的东西。附一节说明什么情况下这三家你一个都不需要。
电商 MCP Server 横评 2026：哪些能真写，哪些只能读
各家都在宣传 AI 助手直连自家平台，但写权限的天花板差得离谱。这篇把已确认的读写边界摆出来，再给一份自己动手验一遍的清单。
Cloudflare 9 月 15 日改了默认值：帮顾客下单的 AI 代理可能进不来了
Cloudflare 7 月把原来那个拦 AI bot 的单一开关拆成了 Search、Agent、Training 三类，各管各的。9 月 15 日起新接入的域名拿到新默认值：带广告的页面上，归到 Training 或 Agent 的 bot 被拦，Search 照常放行。这篇讲拆分后各类分别管什么、新默认值具体影响谁，以及店主进后台该看哪几处。