Cloudflare AI Search 2026：三大 Agent 框架集成横向对比

2026-07-30，Cloudflare 一次性发布了 AI Search 与三个 Agent 框架的官方集成指南：Vercel AI SDK、LangChain、Cloudflare Agents SDK。三个集成将一套原本只暴露 REST API 的托管检索服务，变成三个 agent 框架里可以直接当 model、retriever 或 tool 用的一等公民。

90 秒读懂 AI Search

AI Search 是 Cloudflare 在 Workers 技术栈之上做的托管检索服务。你创建一个 instance、把数据塞进去（Workers 存储 / R2 桶 / 公开网站 / 直接 REST 推送），剩下的切片 → embedding → 建索引 → 混合召回（语义 + 关键词） → 重排 → 格式化输出全部托管。你不用选 embedding 维度、不用部署重排模型、不用为向量 DB 做版本升级。

三个关键原语：

• Namespaces（命名空间） — 按租户 / agent / 项目做的逻辑隔离，每个 namespace 是一份独立可检索语料。
• Search modes（检索模式） — vector、keyword、hybrid（默认；用倒数排序融合把两者合并）。
• MCP endpoint — 每个 instance 都内置 Model Context Protocol 端点，Claude Desktop、Cursor 或任何 MCP 客户端能直接调它。

这才是产品形态。2026-07-30 的升级是：你不用再为这三个框架各自写"胶水代码"——胶水直接以官方包的形式发布。

三个框架集成各自做了什么

Vercel AI SDK — ai-search-provider 包

Cloudflare 单独发了一个 npm 包叫 ai-search-provider，对 AI SDK 的 v6 主线（ai@^6）。它把 AI Search instance 当作语言模型暴露，让 generateText / streamText / tool 这些原语不动即可工作。最关键的调用：

import { createAISearchNamespace } from "ai-search-provider";
import { generateText } from "ai";

const aiSearch = createAISearchNamespace({ binding: env.AI_SEARCH });
const { text, sources } = await generateText({
  model: aiSearch.get("knowledge-base").chat(),
  messages: [{ role: "user", content: "How does caching work?" }],
});

三个细节值得注意：

1. binding 是 Workers binding，不是 REST 凭据。要拿到 env.AI_SEARCH，代码必须跑在 Worker 里。从外部 Node 脚本调可以用，但需要自己写 REST 拼装。
2. 返回结构里 sources 是顶层字段——每一段召回都带 source URL、namespace、相关度分数，可以直接喂给"查看引用" UI 或写日志。
3. 也可以把 instance.search() 暴露成 tool，让模型在工具循环里决定要不要主动查。

已经在 AI SDK 里跑 chat completions、想最低改动接上检索增强，这就是最短路径。包是新的，但写法符合 v5 → v6 时代的常规迁移节奏。

LangChain — CloudflareAISearchRetriever

LangChain 集成落在已有的 langchain-cloudflare 包（PyPI + GitHub，Cloudflare 官方维护）里，作为新 retriever 类发布。它不是 BaseChatModel，而是 BaseRetriever。这个位置选择有讲究：

• 可以独立使用（一个 Python 服务的精简 RAG）。
• 可以用 create_retriever_tool 包成 LangChain agent 的搜索工具。
• 可以直接接进既有的 RAG 链（RetrievalQA、ConversationalRetrievalChain），下游代码完全不动。

支持两种鉴权模式：REST 凭据（ACCOUNT_ID + API_TOKEN）给普通 Python 进程；Workers binding 给 Pyodide + Workers 环境下的 Python Worker。调用形态：

from langchain_cloudflare import CloudflareAISearchRetriever

retriever = CloudflareAISearchRetriever(
    account_id=ACCOUNT_ID,
    api_token=API_TOKEN,
    instance_name="knowledge-base",
    retrieval_type="hybrid",
)
docs = retriever.invoke("How do I configure Workers AI?")

2024 年就标准化在 LangChain 上、还没迁移的团队，这是最低成本接入路径。retriever 尊重 LangChain 标准的 .invoke() / .batch() API，下游不需要任何改动。

Cloudflare Agents SDK — 有状态 agent 模式

Agents SDK 指南和前两个不一样。它假设你在 Cloudflare 上构建有状态 agent——以 Durable Object 为后端、跨多轮对话持久存在——并演示了怎样让这个 agent 自己 provision 一个 AI Search instance、往里塞内容、再让 agent 的工具循环能去 search。核心代码：

import { tool } from "ai";
import { z } from "zod";

const instance = env.AI_SEARCH.get("knowledge-base");

const searchKnowledgeBase = tool({
  description: "Search the knowledge base for relevant content.",
  inputSchema: z.object({ query: z.string() }),
  execute: ({ query }) => instance.search({ query }),
});

AI SDK 和 LangChain 把 AI Search 当作"既有应用里的检索原语"；Agents SDK 指南把它当作"长跑 agent 的持久记忆层"。Durable Object 状态 + AI Search 让 agent 能把整个会话的问题与答案积累在按租户划分的知识库上，不用每轮重建索引。

横向对比

为什么 2026 年默认走 hybrid 检索

三个集成全都默认开 hybrid：向量相似度（语义）+ 关键词匹配（BM25 类），最后用倒数排序融合合并。纯向量检索有一个广为人知的失败模式——高度具体的术语（确切产品名、代码、ID、错误码）会被平均掉当成噪声。纯关键词检索反着来——改写型问句（"怎么让它更快"）词不匹配就漏掉。

Cloudflare 的 hybrid 把重排模型内建在检索调用里，所以你不用再额外采购 Cohere / Voyage 的 cross-encoder。2024 年用过纯向量检索、被"为什么找不到那个错误码"折磨过的团队，hybrid 默认就把这事治了。

周边栈：R2 / Workers / AI Gateway / Vectorize

AI Search 不是孤岛，它处在一个四元组里：

• Workers — 跑 indexer 和 runtime。Worker 推数据，indexer 自动摄取，Workers KV 处理切片元数据。
• R2 — 存原文件（PDF、HTML 抓取）。data source 是 R2 桶时，AI Search 直接读。
• Vectorize — Cloudflare 的独立向量数据库。AI Search 内部就用 Vectorize 做 hybrid 里向量那一半，但外面包装了更高层的 API。
• AI Gateway — LLM 层。AI Search 返文档，AI Gateway 路由合成答案的 LLM 调用。两块拼起来就是一个完整的"检索—生成"闭环，不用离开 Workers 平台。

这也是三个集成读起来都很干净的原因：它们都不拥有存储、不拥有 indexing、不拥有 generation。它们各自拥有一个接缝——托管检索和你使用的框架的 tool/retriever/model 抽象之间的接缝。

价格、免费层、限额

AI Search 在 Cloudflare 文档里被标为所有套餐可用（Free + Paid Workers）。存储、查询、indexing 各自有套餐上限。准确数字会动——以 /ai-search/limits 页面为准——但 2026 年中的大致形态：

• 免费层：几万条向量记录 + 每月查询次数——够做原型和单租户知识库。
• Paid Workers：扩到百万级记录，单次调用价格和其他 Cloudflare 原语同一量级（每千次检索几分之一美分）。

和本站收录的向量 DB 比，AI Search 的定价逻辑更像 Cloudflare 存储和 Workers 计算，不像托管向量 DB。Pinecone / Weaviate / Qdrant / Chroma 在规模化定价上落在同一区间，但它们把 embedding 与重排单独计费；AI Search 把这些都打包进了检索调用本身，所以 vector + keyword + rerank 的 hybrid 实际等于免费。

AI Search 适用 / 不适用的场景

该用 AI Search 时：

• 你已经在 Workers / Pages / R2 上跑、想零新增基础设施。
• 需要开箱即用的 hybrid 检索，不想自己搭重排。
• 数据规模是 RAG 友好型——几十到几百个 namespace，每个几千到几百万条记录。
• 想要内置 MCP 端点，让 Claude Desktop / Cursor / 任何 MCP agent 不用写胶水就调。

继续留在 Pinecone / Weaviate / Qdrant / Chroma：

• 每个 namespace 几千万向量、或需要 Cloudflare 没公开 benchmark 过的分片规模。
• 需要自定义 embedding 模型、需要任意基数元数据过滤（SQL 式跨 namespace join）、或硬性多区域复制合同。
• 检索延迟预算在 50ms p99 以下且查询来源在 Cloudflare 网络之外——独立向量 DB 离你的模型更近。
• 已有 Pinecone / Weaviate / Qdrant / Chroma 现网、短时间内无法迁移。

结论

2026-07-30 这个 changelog 篇幅小、影响面大：对任何已经在 Workers 上跑的应用来说，AI Search 升级为默认的检索层。三个框架集成不是"用三种方式做同一件事"，而是"为三种框架习惯各自定一种形态"（model / retriever / tool）。Cloudflare 在释放信号——未来框架版本会持续把 AI Search 当一等公民对待，而不是又一个要你自己包装的 REST 端点。

如果你之前因为"没有一个包能同时适配 LangChain / AI SDK / Agents SDK 三个框架"而犹豫——这条阻力 2026-07-30 之后就不存在了。挑一个匹配你已用框架的集成就好。

想让 AI Search 与多个 LLM 供应商走同一把密钥？ 如果你同时把 LLM 调用分发到 OpenAI、Anthropic、Gemini、Workers AI，又想要一个面板把"每次搜索成本"和"每次生成成本"汇总看，FreeModel 通过一个 API key 把它们全暴露出来，配有跨模型用量看板——尤其在你需要在"全开 hybrid 检索"和"只开 keyword"之间按 query 动态切换时最有用。