「每个智能体都需要搜索」——Cloudflare的产品博客用这句话开场时，我愣了一下。不是搜索过时了吗？不是都说大模型能记住一切吗？
但细想确实如此。代码智能体要搜百万行代码库，客服智能体要翻历史工单，就连智能体自己的「记忆」，本质上也是个检索问题。问题是：让开发者自己搭这套东西，太痛苦了。
为什么搜索成了AI的隐形瓶颈
如果你从零开始做过RAG（检索增强生成，Retrieval-Augmented Generation），就知道这潭水有多深。
向量索引得自己搭，文档解析和分块得自己写，数据更新了得同步重索引。想要关键词搜索？那是另一套系统，还得写融合逻辑。每个智能体都要独立的可搜索上下文？全部配置重来一遍。
Cloudflare这次把这套东西打包成了「AI Search」（前身叫AutoRAG），定位很清晰：搜索即基础设施，像调API一样简单。
核心卖点就几个：混合搜索（语义+关键词并行）、内置存储与索引、运行时动态创建实例。不需要先接R2桶，不需要配外部数据源，上传文件自动索引。
混合搜索不是噱头，是刚需
AI Search的混合搜索让向量检索和BM25（一种经典的关键词评分算法）同时跑，结果再融合。这不是技术炫技，是真实场景的妥协。
纯向量搜索对专有名词、型号编号、错误代码经常抓瞎。你搜「ERR_CONNECTION_RESET」，向量语义可能把你带偏到「网络连接问题」的泛泛文档，而BM25能精准命中包含这个字符串的页面。
Cloudflare自己的博客搜索已经切过去了，右上角放大镜可以试试。
更实用的是元数据过滤和跨实例查询。你可以给文档打标签，查询时按标签加权；也能一次调用搜多个知识库。这对多租户场景很友好——每个客户一个实例，查询时统一入口。
一个客服智能体的完整配置
文档给了一个很具体的例子：客服智能体需要两类知识，共享的产品文档和每个客户的历史记录。产品文档太大塞不进上下文，客户历史又在持续增长，都必须靠检索。
配置流程被压得很短：
第一步，脚手架项目：npm create cloudflare@latest -- --template cloudflare/agents-starter
第二步，在wrangler.jsonc里绑定AI Search命名空间，指定支持知识库（SUPPORT_KB）绑定到support命名空间。同时配好AI绑定和Durable Object绑定。
如果产品文档存在R2桶product-doc里，可以创建一个一次性的AI Search实例product-knowledge，直接对接这个桶。
动态实例是架构层面的解放
ai_search_namespaces这个绑定允许运行时创建和删除实例。这意味着你可以按智能体、按客户、甚至按语言动态隔离搜索空间，不用重新部署。
这个设计击中了多租户AI应用的一个痛点：以前要么所有客户数据混在一个索引里靠权限过滤（有泄露风险），要么每客户一套基础设施（运维地狱）。现在可以按需 spinning up，用完后清理。
Cloudflare的算盘也很清楚：把搜索变成和Workers、R2一样的基础设施原子，开发者就会在这个生态里越陷越深。这不是某个功能点的竞争，是平台黏性的加固。
检索增强生成正在分层
AI Search的推出，说明RAG这个领域正在快速分层。底层是Cloudflare这样的基础设施玩家，把索引、存储、混合检索打包成黑箱；上层是应用开发者，只关心「给我的智能体接个搜索能力」。
中间层可能最难受——那些做向量数据库、做文档解析工具、做RAG框架的创业公司，现在要和云厂商的免费/低价基础设施直接竞争。Pinecone、Weaviate们得证明自己的差异化价值在哪里。
对开发者来说，这是个好消息。搭智能体的门槛又低了一截，你可以把精力放回业务逻辑，而不是调BM25的k1参数。
坏消息是，如果你刚花了三个月自研了一套RAG pipeline，现在可能得想想：这算不算重复造轮子？
Cloudflare的博客搜索已经用上了。你的呢？
热门跟贴