Cloudflare 通过 AI Gateway 推出 Web Search API，将搜索转变为基础设施

Cloudflare 正通过 AI Gateway 推出 Web Search API，引入三家搜索服务商，将实时网络检索纳入与模型推理相同的控制平面。该测试版支持通过统一接口使用 Ceramic.ai、Exa 和 Linkup。开发者可从后端、Cloudflare Worker 或智能体工作流中调用该服务。

重要的变化并非又多了一个网络搜索端点。Cloudflare 正将搜索与模型路由、日志、安全控制、凭据和用量管理置于同一层级。这种定位将检索从孤立的集成转变为受管 AI 基础设施。

这一举措也形成了清晰的竞争格局。开发者可以使用模型平台内置的搜索工具，直接连接专业搜索公司，或将检索置于独立网关之后。Cloudflare 押注于团队会选择第三种方案，尤其是在一个应用同时使用多种模型和搜索服务商的情况下。

通过 AI Gateway 推出 Web Search API 改变了控制点

Cloudflare 现为开发者提供一条受管路由，可接入三项独立搜索服务，同时不将检索绑定到特定语言模型。

该公司于 2026 年 10 月 2 日宣布推出测试版。根据发布公告，请求可使用 Ceramic.ai、Exa 或 Linkup。当应用未指定服务商时，Ceramic.ai 将成为默认选项。

每项响应都遵循统一结构，为每个结果提供标题、URL 和描述。元数据还可包含查询、请求标识符和延迟信息。这种一致性很重要，因为服务商特有的差异常会渗入应用代码。

开发者可通过标准 REST 端点访问该服务。Cloudflare Workers 用户则可通过 AI 绑定调用 env.AI.websearch()。两种方法都会经由现有的 AI Gateway 发送请求。

REST 路由接受查询、服务商名称、结果数量上限和网关配置。Workers 绑定通过 JavaScript 或 TypeScript 提供等效控制。Cloudflare 的实施指南称，查询最长可包含 1,024 个字符，单个请求最多返回 10 项结果。

这一限制揭示了产品的设计目标。它是面向模型调用的上下文检索层，而非传统搜索结果页面的替代品。应用会收集一组聚焦的来源，并将相关片段置入模型的工作上下文。

该服务支持两种凭据路径。团队可以消耗其 AI Gateway 积分，也可以存储服务商密钥，并通过自带密钥别名进行选择。Cloudflare 会在网关内部获取该凭据，而无需应用在每次搜索请求中传输它。

这种架构为团队提供了统一的认证边界。它还减少了分散在应用、部署系统和开发者机器中的外部凭据数量。被攻破的应用令牌仍会带来风险，但凭据蔓延会更容易得到控制。

Cloudflare 表示，网络搜索请求会出现在常规 AI Gateway 可观测性日志中。团队可以与模型流量一同检查请求活动，而无需运行独立的监控栈。访问策略还可以决定哪些应用能够访问特定搜索服务商。

这种集成形成了本文的核心张力。直接搜索 API 的中间环节更少，而网关则提供更多运营控制。Cloudflare 必须证明，控制层节省的复杂性多于其引入的复杂性。

搜索正成为 AI Gateway 技术栈的一部分

竞争压力将落在模型平台和专业搜索厂商身上，因为 Cloudflare 正将实时检索与使用它的模型分离。

许多模型已经提供原生网络搜索。Cloudflare 现有的网关文档列出了来自 OpenAI、Anthropic、xAI 和 Alibaba 的受支持搜索工具。这些工具仍附属于各自的服务商接口和模型能力。

当团队确定采用单一模型家族时，原生搜索可能很方便。模型决定何时搜索，服务商负责组织证据，同一服务生成答案。对于直接的助手场景，这一路径可以减少编排工作。

但当应用更换模型时，这种方式就不那么方便了。工具模式、受支持模型、引用格式、区域可用性和保留条款可能各不相同。即使每条路径执行的是相同的基础检索任务，团队也可能需要为每个服务商分别实施。

Cloudflare Web Search API 改变了这一边界。搜索成为由应用控制的步骤，并采用统一的响应格式。检索到的材料可供通过 Workers AI 提供的模型、经由 AI Gateway 路由的模型，或其他推理服务使用。

这种分离对智能体很重要，因为智能体通常会在生成一个答案前执行多次搜索。研究型智能体可能先发起宽泛查询，识别出公司或文档后，再进行更聚焦的后续查询。由于这些调用的数量可能超过最终模型请求，因此需要可预测的日志和权限控制。

网关方法也支持显式选择服务商。开发者可以将一个工作负载路由至 Ceramic.ai，另一个则路由至 Exa 或 Linkup。每当所选服务商变化时，应用无需改变整体集成方式。

Cloudflare 将各服务商描述为面向不同检索画像。其服务商文档称，Ceramic.ai 运营着一个超过 400 亿页面的独立索引。它返回较长的描述，可为智能体提供充足上下文。

Exa 将关键词方法与基于嵌入的搜索相结合，后者比较语义表示，而非仅依赖术语匹配。Cloudflare 将其配置为返回检索页面中与查询相关的高亮内容。这种格式适合需要简洁证据的提示词。

Linkup 通过快速搜索模式返回带来源的片段，而不生成综合答案。这使检索与推理保持分离。应用可以决定由哪个模型分析结果，以及如何呈现引用。

这些差异为 Cloudflare 支持多家服务商提供了理由。搜索质量并非单一维度。新鲜度、索引覆盖度、语义相关性、延迟、片段长度和来源选择，对于不同任务都可能更为重要。

同样的多样性也让产品更复杂。统一的响应并不意味着服务商是等效的。开发者仍需进行评估，以衡量每项服务是否为其领域检索到了正确证据。

因此，Cloudflare 从两个方向对搜索公司施压。它们可以通过成熟的开发者平台获得分发，但也被呈现为统一接口背后可互换的选项。这可能会将部分客户关系转移至网关。

模型服务商面临的是另一项挑战。其集成式搜索工具可以共同优化检索与生成。Cloudflare 的方法则认为，许多团队会比起紧密耦合的体验，更重视可移植性、独立的服务商选择和集中化策略。

Vercel 正在采取相关策略。其 AI Gateway 最近新增了可跨支持工具调用模型使用的搜索和抓取工具。这些发布在时间上的接近，表明网关正从模型路由扩展为完整的智能体工具层。

这并不是一场关于谁最先将模型连接至搜索的竞争。这是一场关于哪个平台掌控这种连接的竞争。胜者将控制凭据、日志、路由决策、保留设置以及开发者的集成界面。

机制很简单，但架构转变更为深远

Cloudflare 将搜索转化为可复用的检索原语，应用可在模型调用之前、期间或之间调用它。

一个基础工作流始于用户问题。应用将该问题或派生查询发送至 Web Search API。它接收结构化结果，并将选定描述放入模型提示词中。

智能体也可以决定何时调用该服务。开发者定义一个 web_search 函数工具，即向模型描述的可调用操作。当模型请求使用该工具时，应用代码会执行搜索并返回结果。

随后，模型会接收第二次推理调用，其中包含原始问题和检索到的证据。这种模式通常被称为工具增强生成，因为模型在完成任务时会收集外部信息。这不同于仅依赖存储在模型参数中的知识。

Cloudflare 表示，原生服务器工具将在稍后推出。这些工具会将更多编排工作转移至 AI Gateway 本身。目前，开发者仍必须实施接收工具调用、执行搜索并将结果返回模型的循环。

这一区别很重要。当前测试版提供的是搜索服务和通用网关控制。它尚未提供一个完全受管的研究型智能体，能够决定查询、筛选证据、解决相互冲突的来源，并撰写带引用的答案。

独立设计仍具备实用优势。团队可以在结果到达模型前检查原始结果。他们可以拒绝被屏蔽的域名，要求采用获批来源，去除重复页面，或将检索限制在符合内部信任策略的文档范围内。

客户支持助手提供了一个实际例子。当客户询问最近变更的 API 时，智能体可以搜索当前文档，而不是基于较旧的训练快照作答。应用可以保留检索到的 URL 以供审查。

软件智能体在排查错误时也可采用相同模式。它可能搜索新的发布说明、已变更的配置选项或当前兼容性警告。搜索结果构成证据，而模型仍负责解释这些证据。

研究和监控产品可以发起多项聚焦查询。一个请求可能定位官方公告，另一个可能查找文档，第三个则可能核查独立报道。好的工作流会比较这些来源，而非接受第一个结果。

知识工作者在私有材料中也面临相关问题。系统必须将外部动态与笔记、文档和既有的组织背景结合。这一过程类似于知识融合：新证据只有在与用户已信任的信息建立关联后才会真正发挥作用。

网关可以记录此类工作流涉及的检索调用。当答案出现问题时，这会为运营人员提供更清晰的记录。他们可以判断：是查询质量不佳、服务商遗漏页面、片段缺少上下文，还是模型误读了良好证据。

这种分离支持更好的评估。检索质量和答案质量可以独立衡量。若没有这种拆分，低质量响应几乎无法说明问题究竟由搜索还是生成造成。

它还支持分阶段回退。应用程序可以先查询一家提供商，检查结果数量，并在覆盖不足时改用另一家提供商重试。Cloudflare 并未声称该 beta 版会自动作出此类质量判断，因此开发者必须自行构建并测试这些机制。

缓存也是如此。一些时事问题会很快过时，而稳定的文档查询可以复用结果。负责任的应用程序需要针对过期、来源更新和重复请求制定相应策略。

Cloudflare 现有的网关搜索支持已经能够代理多个模型提供商的原生工具。新 API 则提供了另一条路径：一种独立于这些原生工具、与提供商无关的检索调用。

这意味着，团队如今在更广泛的 Cloudflare 平台内拥有两种搜索模式：既可以保留模型提供商原生工具的行为，也可以使用新的独立 API。正确选择取决于可移植性、控制能力，以及团队愿意自行承担多少编排工作。

这一机制看似只是一次小幅 API 增加，但从架构角度看，它赋予搜索与推理、存储、队列及其他可组合服务同等的地位。智能体可以将实时网络信息视为基础设施，而非某一模型附带的特殊功能。

AI Gateway Web Search 提高了可观测性的要求

当团队能够将生成的主张关联到为其提供支撑的确切检索步骤时，集中式日志的价值最高。

Cloudflare 将 AI Gateway 定位为模型应用的控制平面。它已提供请求可见性、安全控制和用量管理。加入检索功能后，可观测性延伸至一个通常决定回答是否及时的环节。

即使模型推理严谨，只要证据不完整，仍可能生成错误回答。搜索可能返回过时页面、转载文章，或使用了正确词汇却讨论其他主题的结果。运营人员必须先获得可见性，才能区分这些故障。

请求标识符和延迟元数据提供了起点。它们可以帮助将缓慢或失败的搜索与特定智能体运行关联起来。日志还可以揭示应用是否在发出不必要的查询，或反复检索同一页面。

不过，记录搜索流量本身也带来了治理问题。用户查询可能暴露机密计划、客户名称、安全事件、医疗顾虑或内部项目细节。因此，集中式网关必须明确访问边界和数据保留行为。

Cloudflare 表示，所有三家首发合作伙伴都支持通过该服务路由的请求实行 Zero Data Retention。Zero Data Retention 意味着，在适用安排下，提供商不会在处理后保留请求数据。但这并不能自动解答整个应用程序中的所有隐私问题。

开发者仍控制着哪些信息进入查询。Cloudflare 仍在运营网关及其日志。最终模型提供商会收到应用程序发送的所有检索上下文。每个环节都需要经过审慎设计的数据策略。

自带密钥支持同样需要仔细配置。Cloudflare 的文档称，若使用明确指定的别名，而对应密钥不可用，请求将会失败。若未指定明确别名，网关可以使用已配置的默认密钥或可用的网关额度。

这种行为带来了便利，但团队应决定是否接受回退。受监管的工作负载可能要求特定的提供商协议。即使技术结果有效，静默切换至另一条商业路径也可能与内部控制相冲突。

可观测性还必须保留足够细节以便评估，同时避免存储过多敏感数据。仅有数量和延迟无法解释相关性失败。完整查询和结果摘要具有更高诊断价值，但也会增加暴露风险。

不同应用的恰当平衡并不相同。公共新闻助手可以记录比内部法律研究系统更多的检索细节。Cloudflare 的优势取决于管理员能否通过易于理解的策略表达这些差异。

运营控制还包括防止滥用。陷入工具循环的智能体可能会发出大量重复搜索。速率限制、请求预算和按应用划分的权限非常重要，因为检索可能占据智能体活动的很大比例。

集中式日志有助于识别这种行为，但本身无法阻止它。团队仍需要在其智能体框架中设置工具调用最大次数、超时、域名策略和明确的停止条件。

安全也是同样的道理。搜索结果包含不受信任的文本，而网页可能含有试图操纵智能体的指令。提示注入是指外部内容试图覆盖应用程序既定规则的情况。

标准化的搜索响应并不能中和恶意内容。模型仍可能将敌意摘要解读为指令。开发者应将检索材料标记为证据，限制检索后可执行的操作，并避免在启用工具的上下文中放置机密信息。

新 API 让这些实践更容易集中管理，但无法取代它们。Cloudflare 销售的是一个更好的控制点。客户仍要对在该控制点之后运行的智能体行为负责。

爬虫规则带来有益承诺，也带来严峻考验

Cloudflare 将此次发布与负责任爬取绑定，但合规并不能保证搜索结果完整、准确或具有代表性。

该公司要求参与的提供商识别其爬虫、遵守 robots.txt，并包含指向检索内容的链接。它还表示，提供商爬虫必须满足 Cloudflare 对已验证机器人的要求。

已验证机器人是指身份已获 Cloudflare 确认的自动化服务。验证让网站运营者在决定允许还是阻止爬虫时获得更明晰的信号。与声称代表搜索公司却身份不明的流量相比，它减少了模糊性。

Cloudflare 将此描述为 AI 搜索服务与发布者建立更公平关系的标准。该政策让内容创作者更清楚地了解谁在访问其页面。来源链接也使用户能够查看底层材料。

这些承诺使此次发布区别于不透明的抓取行为。鉴于发布者日益质疑 AI 系统如何获取、总结并商业化网络内容，这一点尤其重要。搜索提供商需要访问权限，而网站所有者则希望获得可执行的控制权。

代价在于，尊重规则的爬取可能减少覆盖范围。有些网站会阻止自动化访问、限制特定机器人，或将材料置于认证之后。搜索结果只能反映提供商已建立索引且仍获准使用的页面。

因此，三家提供商可能返回不同的网络视图。它们运营着独立的索引、排序系统、刷新计划和摘要生成流程。共享 API 模式隐藏了这些实现细节，却无法消除其影响。

来源归属带来了另一项挑战。返回 URL 是必要的，但不能证明生成的回答准确反映了页面内容。应用程序必须保留每项主张与其支撑结果之间的联系。

最终模型可以将多个摘要组合成没有任何来源明确支持的陈述。它也可能忽略发布日期，或将更新后的文档与旧版本混淆。不应将存在引用误认为引用准确。

搜索排序进一步增加了不确定性。高度优化的页面可能排在一手来源之前。转载副本可能比原始报道更突出。检索到的描述可能省略在完整页面中显而易见的限定条件。

Cloudflare 当前的 API 返回搜索结果，而非整页验证。需要高置信度的应用程序应抓取重要页面、检查其内容、比较日期，并优先采用一手文档。一次搜索调用用于发现，而非证明。

延迟同样会影响质量决策。智能体通常面临响应时间预算，因此开发者可能选择较快的提供商，或在获得第一个看似合理的结果后停止。这种优化可能与通过多个来源验证敏感主张的需求相冲突。

beta 状态在此很重要。Cloudflare 已记录接口和提供商特性，但关于相关性比较的公开证据仍然有限。开发者应将提供商描述视为设计指导，而非经独立验证的性能排名。

也不存在适用于所有应用程序的通用基准。某家提供商可能在软件文档方面表现良好，却难以处理本地新闻、科学文献或冷门公司申报文件。团队需要根据自身预期查询构建测试集。

有效的评估应记录正确页面是否出现、排名高低、时效性，以及摘要是否保留关键上下文。还应测试对抗性页面、歧义名称和答案会变化的查询。

即使确切商业条款有所不同，成本也应纳入评估。智能体工作流可能将一个用户问题扩展为多次搜索和模型调用。团队应衡量任务总成本，而不是比较单次孤立请求。

Cloudflare 的无加价定位减少了一项顾虑，但并不决定价值。如果更昂贵的检索路径能够避免额外调用或提高回答准确性，那么它可能是值得的。较便宜的路径在较弱结果触发重试时也可能变得昂贵。

爬虫标准仍是此次公告的重要组成部分。Cloudflare 正利用其位于网站与自动化客户端之间的地位，设定参与要求。真正的考验在于，这些规则能否实现可追责的检索，同时不制造开发者未能察觉的盲区。

开发者应在 Beta 发布后关注什么

下一阶段将显示，Cloudflare Web Search API 会成为持久的网关原语，还是仍只是一层便捷的合作伙伴端点封装。

第一个信号是原生服务器工具的到来。Cloudflare 表示，网络搜索将成为最早直接集成到 AI Gateway 控制平面的工具之一。该发布将减少开发者目前维护的编排代码。

有用的服务器工具实现不能只隐藏一次函数调用。开发者应关注其如何处理工具权限、最大使用次数、重试、超时、结果溯源和提供商选择。这些控制决定团队能否在生产环境中的智能体里安全使用它。

如果服务器工具能在不同模型间保留共同的行为，Cloudflare 的网关论点将更具说服力。平台将同时掌控模型访问和检索编排。若每个模型仍需要大量定制处理，其收益就会收窄至计费和可观测性。

第二个信号是可衡量的提供商可移植性。Cloudflare 的共享响应格式让 API 层面的切换看起来很简单。真正的可移植性则需要可比较的结果质量、可预测的错误处理，以及在生产负载下稳定的行为。

团队应使用同一批查询分别测试 Ceramic.ai、Exa 和 Linkup。应比较来源覆盖、时效性、排序、延迟和摘要实用性。还应检查结果在歧义或对抗性问题下如何变化。

只有当开发者能够有意识地选择提供商时，提供商特定优势才有价值。如果大多数应用程序未经评估便停留在默认选项上，市场化元素就不那么有意义。若团队按工作负载进行路由，Cloudflare 将获得一个可辩护的协调角色。

第三个信号是竞争对手的反应。Vercel 已经提供网关级搜索工具，而模型公司仍在持续改进原生浏览能力。其他云平台可以在自身控制平面中整合搜索、模型和 Agent 运行时。

关注这些竞争对手是否会增加更多独立检索服务商、更强的评估工具，或统一的引用格式。这种反应将揭示，与服务商无关的搜索会成为标准网关功能，还是仅仅是暂时的差异化优势。

开发者还应关注机器人策略和发布者控制机制的变化。检索质量依赖于能否持续访问有价值的来源。可抓取内容与受限内容之间日益扩大的鸿沟，将影响所有服务商，即使每个爬虫都遵守既定规则。

在初步试用时，应选择答案经常变化且拥有可识别一手来源的任务。与宽泛的观点类问题相比，发行说明、服务状态、产品文档和公开披露文件能提供更清晰的评估目标。

在将搜索集成到面向用户的 Agent 之前，先建立一个小型基准测试。记录预期来源、可接受的发布日期，以及正确答案必须包含的事实。随后分别测试检索与生成。

应尽可能在应用界面中保留来源 URL。用户应能够核查证据，尤其当答案会影响重要决策时。引用应支撑具体主张，而非为整段回答作装饰。

为每项任务设定搜索预算。限制重复查询，停止循环工具调用，并要求 Agent 在采取外部行动前进行额外确认。搜索能为模型带来新信息，但不会赋予这些信息权威性。

通过 AI Gateway 推出 Web Search API 这一发布，最终要求开发者重新思考搜索应处于何处：它是模型的一项功能、与供应商的直接关系，还是由应用平台控制的共享服务？

Cloudflare 为共享服务模式提出了可信的论据。该 Beta 版本整合了三家服务商、一个统一界面、网关日志、凭据管理和明确的爬虫标准。它的价值将取决于可靠性、检索质量，以及承诺中的服务器工具层。

对于已经在使用 AI Gateway 或 Workers 的团队而言，下一步的实际行动是在真实查询上开展受控评估。比较这三家服务商，检查每一个来源，并衡量完整的任务结果。独立搜索层会改善你的 Agent，还是会让另一道网关边界带来的工作量超过其减少的工作量？