Cloudflare 给了一个很硬的数字：过去六个月，bot 已经占 HTTP 流量的 31%。其中，AI 爬虫、搜索引擎和助手大约占 bot 请求的四分之一。

这不等于 AI agent 已经接管互联网。还早。但基础设施公司已经在按机器流量改路。Cloudflare 预计，非人类流量会在 2027 年上半年超过人类流量。

AWS 这次发布的新一代 OpenSearch Serverless，表面是云产品更新。真正值得看的是它承认了一种新负载：不是人慢慢点网页，而是 agent 瞬间拉起一串查询、检索和 API 调用，然后消失。

AWS 发了什么：搜索和向量检索开始为 agent 改底座

OpenSearch Serverless 的关键变化，是计算与存储解耦。

这意味着计算资源可以在任务爆发时秒级扩上去，空闲时缩到零。这里的“零”只指空闲 compute 不再付费，不是存储、请求、数据传输等成本全部归零。

这点很重要。AI agent 的负载不像传统网站。

对比项人类互联网agent 互联网
行为节奏搜索、点击、停留并发查询、连续调用
负载形态相对稳定，有峰谷突然爆发，迅速归零
成本压力页面、带宽、缓存搜索、向量检索、API、数据库
工程难点扛高峰别为闲置 compute 白付钱

一个 agent 接到任务后，可能马上启动多个子 agent：查数据库、搜文档、读企业知识库、调用 API、写入向量库。几秒钟内打出一串请求，任务结束后又没有持续流量。

传统容量规划最怕峰值。agent 时代还多了一个问题：峰值来得更碎、更频、更难预测。你不能只为最猛的几秒长期养一批空闲计算资源。

所以 AWS 这个更新不是“省点钱”的小功能。它是在把搜索和向量检索做成更贴近 agent 调度方式的基础设施。

限制也要说清。OpenSearch Serverless 不是所有 agent 场景的万能解。高频、长期稳定、强定制的负载，未必一定适合完全 serverless。企业还要看延迟、吞吐、权限、数据驻留和账单可预测性。

但方向已经够明确：搜索系统正在从“给人找网页”，变成“给机器找上下文”。

为什么重要：机器不会停下来犹豫，只会继续调用

人类互联网有一个隐含前提：用户会累。

人会停下来读，会犹豫，会关闭页面。哪怕是大促、热点新闻、直播，流量也大体围绕人的节奏展开。

机器不是这样。机器只看任务链路和调用成本。只要权限允许、预算没爆，它可以连续搜索、连续检索、连续请求 API。

这会把很多产品团队的旧账本打穿。

过去，API、数据库、搜索服务的计费模型默认“人类使用频率”在背后兜底。现在如果接入 agent，同一个用户动作背后可能变成几十次检索、几十次 API 调用、多个数据库查询。

模型看着更强，产品反而可能更虚。因为真正的瓶颈会从“回答聪不聪明”，转到四个更硬的问题：调用贵不贵、延迟稳不稳、权限控不控得住、账单能不能解释。

这也是为什么不止 AWS 在动。

公司调整方向指向的问题
AWSOpenSearch Serverless 适配突发检索负载agent 检索与向量搜索成本
Cloudflare为机器流量、持久环境和瞬时扩展做基础设施非人类请求增长后的边缘与执行环境
Databricks / Snowflake把企业数据平台包装成 AI 记忆与检索层企业数据如何被 agent 安全调用
Microsoft在 Azure 侧处理 agent 爆发负载和共享记忆企业 agent 的运行与协作成本
Google推消费者把购物研究、旅行预订等任务委托给 AI人的任务入口被 agent 接管

这不是某一家云厂商在包装新品，而是一批基础设施公司在抢同一个位置：agent 的记忆层、检索层和执行层。

“天下熙熙，皆为利来。”这句话放在这里很合适。谁能让 agent 更便宜、更快、更稳，谁就更靠近下一代应用入口。

浏览器时代，入口是搜索框和网址。移动时代，入口是 App 和应用商店。agent 时代，入口可能更底层：向量数据库、搜索后端、API 网关、权限系统、持久运行环境。

不完全一样，但历史味道很熟。铁路先改了货物流动，电网先改了工厂布局，云计算先改了软件交付。基础设施一旦变便宜，应用形态就会跟着变。

今天的 agent 还没到那个阶段。但云厂商已经开始修路。修路的人，通常不是为了风景。

谁最受影响：开发者要算账，技术负责人要控闸门

这件事最该看的，不是普通用户。普通用户短期只会感到 AI 功能变多。

真正要动手的是两类人：做 agent 落地的开发者，以及负责企业技术采购和架构的技术负责人。

对开发者来说，下一步不是急着把 agent 接满所有系统，而是先把每次任务拆成账本：一次回答查几次向量库、调几次 API、读多少文档、写多少缓存、失败重试几轮。

能缓存的缓存。能合并的调用合并。能限制并发的限制并发。不要等月底云账单来教育团队。

对企业技术负责人来说，更现实的动作是延后“一步到位”的大迁移，先做小范围压测和权限边界设计。尤其要看三件事：峰值成本、延迟稳定性、数据访问权限。

角色现在该做什么最该避开的坑
agent 开发者给每个任务链路算检索、API、数据库调用次数只看模型价格，不看工具调用总成本
企业技术负责人先压测，再采购；先设权限，再放开 agent把 agent 当聊天机器人，而不是自动化调用系统
API / 搜索 / 数据库产品团队重审限流、计费、缓存和机器访问策略继续按人类点击频率设计价格和风控

API 产品团队也要醒得更早一点。过去，一个真实用户一天调几次接口。现在，一个 agent 可能替同一个用户在一分钟内调几十次。

这不是流量变多这么简单。它会逼产品重新设计限流、套餐、反滥用规则和机器访问价格。Cloudflare 的 bot 数据不能直接等同于 agent 流量，但它已经提醒了一个方向：非人类访问会越来越像基础流量，而不是边缘异常。

接下来最该观察两个变量。

第一个，是 agent 任务的单位经济账。一次任务到底要消耗多少检索、推理、API 和存储。只要这个账算不平，agent 就只能留在演示和少数高价值场景里。

第二个，是云和数据平台会不会把“记忆、检索、持久环境、权限”打包成新的默认入口。谁把这套东西做得足够顺，谁就可能变成 agent 部署的收费站。

我不太买账那些把 agent 说成已经统治互联网的叙事。现在还没有。Cloudflare 数据里的 AI 爬虫、搜索和助手，只是 bot 请求的一部分，生产级 agent 流量也还在早期。

但我也不建议低估这次变化。基础设施公司不会为了几张演示幻灯片去改底层计费和扩缩容模型。它们闻到的是下一轮账单。

AWS 这次 OpenSearch Serverless 的意义就在这里：不是宣布机器已经赢了，而是提前把收费口、检索层和弹性计算摆到路边。

人还在点网页。机器已经开始改写网页背后的成本结构。