AI 爬虫把 CDN 缓存搅成一锅粥：Cloudflare 终于承认，真人和机器人已经不能共用一套餐桌了
过去大家聊 AI 流量，很多时候焦点都在两个方向：
- 模型会不会抓你的内容
- 网站该不该拦 AI 爬虫
但 Cloudflare 这两天发的一篇文章，真正让我觉得值得拿出来单聊的，不是“要不要拦”，而是一个更底层的问题：如果 AI 爬虫和真人用户访问网站的方式压根不是一回事，那 CDN 还继续按同一套逻辑缓存，真的顶得住吗？
我觉得这篇文章最有价值的地方，是它终于把一个很多基础设施团队已经隐约感到、但没被讲透的现实说清楚了：
AI 流量不是普通的新流量类型，它正在改写缓存系统原本默认依赖的统计规律。
说白了，传统 CDN 特别擅长服务“很多人反复看差不多的热门内容”这种模式；AI 爬虫则更像一群不知疲倦、东翻西找、专挑长尾页面扫的访客。两者混在一起以后，缓存系统最信任的那套经验值，就开始失灵了。
先说结论：这不是流量变多，而是流量变“怪”
Cloudflare 给出的数据很直白：他们网络里 32% 的流量来自自动化流量，而在已识别的 AI 机器人里，绝大多数又是为了训练和搜索而来的抓取请求。更关键的是，AI crawler 已经成了他们观察到的最活跃 AI bot 类型，占自识别 AI bot 流量的 80%。
很多人看到这里第一反应可能是：
“那不就是机器人更多了吗？”
但问题真不只是“更多”。
更麻烦的是，它们访问内容的方式和人完全不像。
真人用户大多会反复看热门页面、停留在有限路径里、带着会话和浏览器缓存继续访问；AI 爬虫却经常：
- 并发拉很多请求
- 顺着整站扫很深
- 专挑过去很少被访问的长尾内容
- 一轮一轮重复抓不同页面
- 还经常打到 404、跳转和无效 URL
这就像什么？
像一家餐馆本来是按正常午饭客流备菜，结果突然来了一批人，不坐下点招牌菜，反而把后厨冰箱、储藏间和角落里每个抽屉都翻一遍。人还是在店里活动，但系统压力的形状已经完全变了。
为什么传统缓存策略会被 AI 流量带偏
缓存这件事，本质上一直在赌一个概率：
接下来被访问的内容，大概率和刚才、或者最近热门的内容有关。
这个假设对真人流量通常挺成立。
比如热点新闻、产品详情页、首页、某个教程文档，很多用户会在相近时间内反复访问同一批资源。于是 CDN 把这些内容留在边缘节点里，就能拿到很高的命中率。
但 AI 爬虫的麻烦在于，它们经常打的是另一套牌：
- 高唯一 URL 比例
- 内容分布更散
- 复用率低
- 抓取路径不一定高效
Cloudflare 引用的公开抓取统计提到，超过 90% 的页面内容本身就是唯一的。而他们对 AI agent 循环检索行为的建模显示，这类请求在迭代式搜索中，独立访问比率常常能维持在 70% 到 100%。
这意味着什么？
意味着缓存里刚放进去的很多东西，还没等第二次被用上，就可能已经只是“为了某个机器人的一次性经过”而占了位置。
对缓存系统来说，这种模式特别烦。因为它不是单点突刺，而是持续把“原本给真人热门内容留的座位”换成“刚来过一次、下次未必再来的长尾页面”。
Cloudflare 文里那句判断我觉得很关键：AI 对长尾内容的反复访问，会搅乱原本服务真人用户的缓存。
这话其实比“AI 流量增加了成本”更严重。因为它说的不是单纯贵一点，而是 缓存命中逻辑本身开始被污染。
为什么站长越来越想一刀切封掉 AI 爬虫
如果只从站点运营角度看，这事的现实后果非常直接：
- 缓存命中率下降
- 回源请求变多
- 源站负载变重
- 带宽和 egress 成本上去
- 真人用户响应变慢
Cloudflare 还在文章里列了一些真实案例。比如 Wikimedia 因批量图片抓取，出现了 50% 的多媒体带宽增长；SourceHut、Read the Docs、Fedora、Diaspora 这些服务，也都遇到过被 AI 抓取流量拖慢、挤压甚至逼到要封锁部分机器人流量的情况。
所以很多站点后来做出的选择也很现实：
先封。
因为继续放开，受伤的是真人用户和自己账单。
但 Cloudflare 这篇文章真正想推进的，不是“大家一起封爬虫”，而是另一个更微妙的问题：
有些网站其实并不想完全拒绝 AI 流量。
比如文档站希望被模型搜索和引用，电商站希望产品信息出现在 AI 搜索里，媒体又希望未来能通过按抓取收费的方式变现。
这就让问题变成了一个很现实的工程矛盾：
- 不让抓，可能损失 AI 时代的新分发入口
- 让它随便抓，又可能把真人流量体验一起拖烂
于是核心问题不再只是“要不要允许”，而是：
能不能用不同的缓存和调度逻辑，分别服务真人用户、实时 AI 请求，以及大规模训练抓取。
Cloudflare 真正想做的，不只是挡流量，而是分层对待 AI 请求
我觉得这篇文章最值得关注的一点，是 Cloudflare 提出的方向并不只是传统的 rate limit，而是更像一种 AI-aware caching 思路。
翻成人话就是：
- 真人请求，继续优先走低延迟、高命中的边缘缓存
- 实时 RAG / 总结类 AI 请求，可以走容量更大、稍慢但仍然新鲜的缓存层
- 训练和大规模抓取，则可以进一步下沉到更深的缓存，甚至排队、延迟、节流处理
这个思路为什么重要？
因为它等于承认了一件事：
不是所有“机器流量”都该被同等对待。
一个正在给用户实时回答问题的 AI assistant，和一个凌晨批量扫全站做训练的 crawler，时延容忍度、重复访问模式、对后端的压力，根本就不是一个等级。
如果全塞进同一个缓存策略里，最后只会互相伤害。
这有点像高速公路。你不能拿同一套限速和车道规则，同时服务救护车、通勤轿车和超重货车，然后指望所有人都满意。
这件事对开发者和内容网站意味着什么
如果你只是普通开发者，可能会觉得“缓存策略不是 CDN 厂商的事吗，和我有什么关系？”
其实关系不小。
因为随着 AI 搜索、RAG、agent browsing 越来越常见，越来越多站点会碰到几个新问题：
- 文档站是不是该给 AI 提供更轻量的页面版本
- 哪些资源允许被实时抓取，哪些只适合节流
- robots.txt、AI crawl policy 和缓存策略要不要联动
- 你的站点热点内容和长尾内容，是否该分开做缓存预算
- 计费模型到底该按人类 PV 设计，还是开始把 AI 请求单独核算
Cloudflare 前面推的 AI Index、Markdown for Agents 这些产品动作，其实已经在铺这条路了：不是简单把 AI 当成普通访客，而是承认它是一种需要单独优化和治理的新访问主体。
我觉得接下来很多基础设施能力都会往这个方向演化：
- AI bot 的识别更细
- 训练型 / 搜索型 / 实时问答型请求分层
- 面向 Agent 的轻量内容格式更普遍
- AI 请求单独计费、单独缓存、单独限流
以前网站面对的主要矛盾是“真人多不多”；现在慢慢变成“真人和机器怎么共处”。
这不只是 CDN 的问题，而是整个 Web 规则在重写
我觉得这篇文章最深的含义还不是缓存，而是它再次提醒了一件事：
AI 正在把 Web 上很多原本默认成立的基础假设一条条拆掉。
过去默认成立的是：
- 热门内容有稳定复用
- 访客大多像人
- 会话和浏览器缓存能减少重复请求
- 长尾访问量天然不会太高
但 AI crawler 一进来，这些假设都开始松动。
你会发现，原来那些“看起来是底层细节”的东西——缓存淘汰算法、边缘命中率、回源成本、带宽模型——突然都成了前台问题。
这也是我觉得这条新闻特别值得开发者关注的原因：
它不是在聊某个新功能，也不是哪家模型又多强了，而是在讲 AI 如何反过来改写整个互联网基础设施的经济学和工程学。
我的判断
Cloudflare 这篇文章最值得记住的，不是某张命中率曲线，而是一句更大的现实判断：
AI 流量和真人流量，正在变成两种需要分开治理的网络物种。
如果还继续假设它们能自然共享同一套缓存、同一套成本模型、同一套优先级，后面只会越来越别扭。
短期里，很多站点可能还是会优先靠封锁、限流和 robots 规则自保；但长期看，真正更像正解的，可能还是 Cloudflare 提到的这条路：
- 承认 AI 请求存在
- 识别它们的差异
- 给不同机器流量不同层级的缓存和时延待遇
- 尽量别让真人用户为机器的访问习惯买单
说到底，Web 不是不能服务 AI。
只是如果继续拿服务真人的那套旧桌子，硬让越来越多机器人一起上桌，最后翻掉的多半还是盘子。