如果一个 AI Agent 为了回答用户的问题，会在几分钟内连续读取几十甚至上百个网页，那么网站面对的就不只是“访问量变大”，还包括请求从哪里来、每次请求消耗多少源站资源，以及谁来承担这些成本。Cloudflare 在 9 月 27 日发布的年度公开信中称，AI Agent 和爬虫让其自动化流量超过人工流量的时间，从原先预计的 2027 年下半年提前到了 2026 年 5 月。
这个数字值得关注，但它仍是 Cloudflare 的估计，不是对所有网站的统一测量。对工程团队更有用的问题是：当机器读取成为常态，怎样让公开内容易于获取，同时避免每次读取都触发昂贵的后端工作？
先把这项判断的边界说清楚
Cloudflare 的公开信把时间变化归因于 Agent 和 AI 爬虫的增长，也举例说明，一个 Agent 可能为了推荐一家餐馆而读取大量菜单页面。信中还预测，如果当前趋势延续，自动化流量未来可能继续快速增长。
不过，这不是一篇测量方法论文。公开信没有在相关段落给出“自动化流量”的完整分类规则、样本范围或计算细节，也没有说明不同行业和网站的流量分布。因此，不能把“自动化流量超过人工流量”理解成每个站点都已经如此，更不能把所有机器请求都归为 AI Agent。搜索引擎、监控探针、预取服务、集成程序和恶意脚本，都会产生自动化访问，目的与资源消耗也不相同。
这次讨论与机器人攻击检测也不是一回事。重点不在于怎样识别并拦截更多机器请求，而在于公开页面和接口如何承接机器读取，且不让一次查询无意间放大成数据库、搜索或第三方服务的多次调用。
请求数不等于实际成本
一个静态页面命中 CDN 缓存，可能几乎不触达源站；另一个看似普通的搜索请求，却可能执行全文检索、拼装多个服务的数据，再调用外部 API。两者在访问日志里都只是“一次请求”，对系统造成的工作量却相差很大。
所以，单看总访问量或 User-Agent 分类，难以回答容量问题。更实用的观察单位是路由和工作负载：哪些路径可以在边缘缓存，哪些请求会访问数据库，缓存未命中会带来多少回源，搜索和聚合接口的尾延迟如何，以及高峰期每秒请求会消耗多少连接、CPU 或外部调用配额。
这里也要避免过度依赖 User-Agent。它可以作为线索，不能单独证明请求身份。无法确认来源时，把流量记为“未知自动化”比贸然归入可信 Agent 或恶意爬虫更稳妥；容量规划则应基于服务端实际发生的工作，而不是客户端自我声明的身份。
给机器可读的路径，也给后端设上限
如果一类公开内容经常被重复读取，可以先让它更适合缓存和增量获取。对不含个性化信息的页面或数据接口，合理设置 Cache-Control，并提供稳定的 ETag 或 Last-Modified，让客户端在内容未变化时进行条件请求。缓存键要包含真正影响响应的维度；若响应依赖用户身份、语言或权限，就不能为了提高命中率而把不同用户的数据混在共享缓存里。
搜索、推荐、报告生成等较重接口则应有明确预算，例如每个调用方的请求速率、并发数、最大页数、查询时间上限和可触发的下游调用数。达到限制时，用 HTTP 429 Too Many Requests 告知客户端稍后重试；可以同时返回 Retry-After，避免对方立刻用重试把拥塞放大。公开网页可以保持易读，昂贵的计算接口则不必无限量免费执行。
另一种做法是为高频机器读取提供稳定、范围清楚的数据出口，例如分页 API、站点地图、内容 Feed 或静态数据文件。接口应明确更新频率、字段含义和配额。这样既能减少 Agent 反复抓取整站的需要，也能让维护者估算成本、监控异常，并在需要时调整服务等级。
监控要从“谁访问”走向“访问做了什么”
建议把仪表盘拆到路由层，并至少同时观察请求量、缓存命中率、源站 CPU/数据库负载、下游调用数、响应延迟和错误率。对已验证的搜索爬虫、公开 API 客户端、浏览器用户和无法分类的自动化流量，可以分别统计；但身份分类要保留可信度，不要让一个标签替代实际资源数据。
规则调整时也要留出观察窗口。先为新的流量类别记录基线，再小范围调整缓存和速率限制，确认正常用户的成功率、延迟没有变差后再扩大。尤其不要仅因某一类请求增长，就直接封禁整个 User-Agent 或 ASN；这可能同时挡住搜索索引、无障碍工具或合法集成。
对多数团队而言，起步不必先采购新的 Agent 管理产品。先找出最贵的几个公开路径，确认哪些内容能共享缓存，哪些操作必须经过授权，再为计算密集型接口设定并发和速率上限，往往就能减少机器访问对核心业务的意外挤压。
结语
Cloudflare 的最新判断提醒网站团队：自动化读取正在变得更频繁，但“机器流量”不是一个单一群体，也不意味着所有网站都应照着同一比例扩容。真正需要提前做的，是把访问次数换算成源站工作量，并把公开内容、可缓存响应和昂贵接口分别管理。
当 Agent 能高频读取网页时，网站既要让有用内容找得到，也要让每次请求的成本可解释、可限制。先把缓存边界、接口预算和观测指标做好，比单纯追逐一个流量预测数字更能解决眼前的问题。
参考来源
- Cloudflare Blog：Cloudflare’s 2026 Annual Founders’ Letter，2026 年 9 月 27 日。
- IETF：RFC 9111: HTTP Caching。
- IETF：RFC 6585: Additional HTTP Status Codes（含 429）。