Cloudflare Web Search API开放测试：三家搜索接入同一网关，原生服务端工具仍在开发

昨天 2阅读

2026年10月2日，Cloudflare发布Web Search API。官方文档将其标为公开测试，开发者可经AI Gateway使用Ceramic.ai、Exa与Linkup的网页搜索，把结果带入模型上下文。它为智能体增加一个可管理的搜索入口，但搜索与最终事实判断仍是两个环节。

搜索服务接入网关的已有管理面

接口返回标题、URL与描述等结构化结果。三家提供商使用统一结果格式，通过provider参数选择，后端可直接调用REST，Workers则可用AI binding。对于已有模型网关的应用，这让搜索请求与推理请求更容易放在一起观察。

搜索消耗AI Gateway余额，按提供商列出的API价格计费，Cloudflare表示不额外加价；也可使用现有提供商密钥。无加价并不等于免费：一次用户提问如果被拆成多轮检索，搜索次数和模型用量仍可能共同增加。日志统一后，开发者更容易看清成本发生在哪一步。

AI模型生成的概念插图：不同搜索来源通过同一入口返回带来源的资料卡片；不是Cloudflare真实界面，也不代表实测检索结果。

Cloudflare要求合作方遵守其Verified Bots相关要求，并为搜索结果提供抓取内容的来源链接。官方强调爬虫身份、robots.txt及来源可见性，这些规则使网站经营者的选择和检索结果的出处更清楚。

对应用而言，链接是继续核对的入口。搜索摘要可能压缩上下文，也可能引用已经更新的网页；涉及价格、版本或开放范围时，仍应打开对应正文，辨认事件发生时间和当前状态。统一搜索格式解决了接口差异，并没有自动解决来源之间的矛盾。

例如用户问某项服务是否已经正式开放，模型可以先搜索官方公告，再读取文档核对预览标记。若公告说“即将上线”、文档仅有申请入口，答案就应保留这个边界。把搜到标题直接当成上线证明，只会让较新的检索入口重复旧的判断错误。

公告中的REST与Workers调用已经可以使用，但AI Gateway原生Server Tools仍在开发。官方给出的现阶段示例，是应用定义web_search函数、执行搜索，再把结果交回模型；不能据此宣称网关已替所有模型自动完成工具选择和整个检索循环。

这也解释了接入时要验收什么：参数是否传给预期提供商、错误是否被应用识别、结果能否保留链接，以及模型是否真的用到了返回资料。搜索服务故障时，应用应说明没有获得最新信息，而非默默退回旧知识后继续给出确定结论。

隐私条件同样按提供商核对。Cloudflare说会标识支持零数据保留的合作方，并不等于所有搜索路线都默认ZDR。查询本身可能包含用户或公司的敏感细节；选服务商、日志策略和发送内容时，应把这一点与模型调用一起考虑。

资料核对：2026年10月3日（北京时间）。本文未调用服务；核验流程与故障处理讨论为原创分析。