当 Agent 被问到“今天发生了什么”，模型的训练截止日期帮不上忙。真正麻烦的也不只是加一个搜索框：你要接供应商 API，处理实时结果，记录请求，控制费用，还要让模型知道答案依据了哪些页面。
Cloudflare 现在把这串工程工作收进了一个入口。2026 年 10 月 2 日，Cloudflare 宣布 Web Search API 进入 Beta：开发者通过 AI Gateway 发起一次搜索请求，就能在 Ceramic.ai、Exa 和 Linkup 之间选择，把实时互联网结果交给 Agent 使用。它解决的是接入和治理问题，不是重新造一个搜索引擎。
这对正在做联网 Agent 的团队很实际：供应商可以换，调用位置和一部分治理逻辑不用跟着重写；但“统一 API”也不等于“三家搜索结果一样”。真正上线前，仍要看结果长什么样、每次请求多少钱，以及数据保留策略是否符合你的要求。
它把搜索变成了 Agent 的一个工具调用
Cloudflare 官方对 Web Search API 的定位很明确：让 AI Agent 和应用搜索互联网，用实时信息支撑回答，避免猜 URL，也避免只依赖模型的训练截止日期。请求统一经过 AI Gateway，因此搜索调用会出现在网关日志里，并按所选供应商的目录 API 价格从 AI Gateway credits 中扣费，不额外加价。
对开发者来说，变化不在“搜索”这个动作本身，而在边界被收拢了。以前你可能要分别管理 Ceramic.ai、Exa 或 Linkup 的 SDK、密钥、错误处理和账单；现在可以把供应商选择变成请求参数，把搜索调用放到同一个网关里观察。
这个抽象像给团队装了一个总机：外部只拨一个号码，后面接哪家线路可以切换。但总机不会替你判断哪条线路最适合，也不会自动把搜索结果变成事实。Cloudflare 的官方公告说的是统一入口，而不是统一搜索质量。
这一点值得警惕。当前产品仍是 Beta，官方没有公布搜索质量、排名稳定性或回答准确率指标，所以“接通实时互联网”不能直接翻译成“Agent 已经可靠地查证事实”。
REST 和 Workers 都能接，前置配置比代码更重要
如果你的 Agent 跑在自己的后端，可以直接调用 REST API。端点是 POST /client/v4/accounts/{account_id}/ai/websearch/，请求体至少需要 query，还可以指定 provider、limit 和 AI Gateway ID。
Cloudflare 文档给出的参数边界很清楚：query 长度为 1 到 1024 个字符；limit 默认是 10，允许值为 1 到 10；provider 可选 ceramic、exa 或 linkup，不填写时默认使用 Ceramic.ai。
权限是容易卡住的地方。REST 请求所用的 Cloudflare API Token，需要同时拥有 Account 下的 Workers AI Read 和 AI Gateway Read 权限；账号还要有名为 default 的网关，或者提前创建自己的网关，并准备 AI Gateway credits 或供应商密钥。完整参数和响应定义见 How to use Web Search API。
如果 Agent 本来就运行在 Cloudflare Worker 中，接入路径更短：给 Worker 配置 AI binding，然后调用 env.AI.websearch()。它返回标准的 Response 对象，接着用 response.json() 读取结果。REST 和 Workers 的差别主要是运行位置，不是两套不同的搜索能力。
最小调用大致是这样：
const response = await env.AI.websearch({
gatewayId: "default",
query: "本周影响供应链的最新事件有哪些？",
provider: "exa",
limit: 5,
});
const results = await response.json();
返回值也没有神秘的“最终答案”。核心是 items 和 metadata：每个结果通常包含 url、title 和 description，元数据可能带有查询词、请求 ID 和延迟信息。后续如何筛选来源、如何把结果交给模型、如何在回答中保留引用，仍然是你的应用逻辑。
三家供应商的差别，藏在结果怎么喂给模型
统一参数很简洁，但供应商并不是同质替换。Cloudflare 的供应商文档列出的差别，首先体现在索引、返回文本、搜索方式和价格上。
| 供应商 | 结果特点 | 更适合的工作流 | 目录价 / 1000 次 | Zero Data Retention |
|---|---|---|---|---|
| Ceramic.ai | 页面描述最长 8000 字符 | 高频、低成本搜索 | $0.25 | Yes |
| Exa | 关键词与 embedding 搜索，返回 highlights | 把相关片段直接放进上下文 | $7.00 | No |
| Linkup | fast 搜索，返回原始结果和文本片段 |
快速获取带来源的结果 | $5.00 | Yes |
Ceramic.ai 是默认供应商。Cloudflare 文档称，它维护一个超过 400 亿页面的独立网页索引，面向 Agent 和大语言模型应用，重点是低延迟、低成本，并能返回较长的页面描述。对于一次任务会反复搜索的 Agent，默认选它有明显的预算优势，但这不代表它在你的领域一定最合适。
Exa 的思路更偏“把最相关的几段文字递给模型”。它把传统关键词搜索和 embedding 搜索结合起来，Web Search API 使用 Exa 的 auto 搜索类型，并把页面中与查询最相关的 highlights 作为描述返回。如果上下文窗口紧张，相关片段可能比大段页面描述更方便；代价是官方列出的目录价明显更高，而且文档中的 Zero Data Retention 标记为 No。
Linkup 使用 fast 搜索深度，返回原始搜索结果和文本片段，不替你生成答案。它更像一个快速的 Agent 工具调用：拿结果、保留来源，再由自己的工具链完成后处理。它的目录价低于 Exa、高于 Ceramic.ai，官方标记支持 Zero Data Retention。
这里要特别警惕一个常见误读：表里的价格是供应商目录 API 价格，不是你的完整账单。通过 AI Gateway credits 付费时，Cloudflare 表示不加额外 markup；如果使用 BYOK，也就是把自己已有的供应商 API key 存到网关，供应商会按你与它的协议直接计费。套餐、税费、重试、上层模型和应用运行成本，都不能从这张表直接推出。
统一入口不会替你做来源核验
Web Search API 返回的是搜索结果列表，不是已经核实过的结论。Agent 如果拿一条过时页面、营销文案或彼此矛盾的报道直接生成答案，统一网关不会自动把它变成可靠事实。
因此，接入时要把“搜索”和“回答”拆开看。搜索工具负责拿到 URL、标题、描述和请求元数据；你的应用还需要决定是否抓取原文、是否要求多个来源相互印证、哪些域名可以作为高信任来源，以及最终答案要不要展示引用。
日志是这套方案比较有价值的一层。请求经过 AI Gateway 后，搜索调用出现在网关日志里，返回的 requestId 和延迟信息也能帮助你追踪一次 Agent 任务。但日志只能告诉你请求发生了什么，不能代替业务侧评估：例如某个问题到底找到了多少有效来源，结果是否被模型正确使用。
数据策略也不能只看“Cloudflare 统一接入”这几个字。Cloudflare 公告称，三家供应商都支持通过 Cloudflare 发起请求时的 Zero Data Retention；供应商页面的表格则分别列出各自状态，其中 Exa 当前标为 No，而 Ceramic.ai 和 Linkup 标为 Yes。具体到你的账户、请求路径和协议，正式接入前仍应查看最新条款。
如果使用 BYOK，密钥管理还有一个容易被忽略的行为：请求指定了 byokAlias 后，如果这个别名没有在网关中配置，调用会直接失败，不会自动回退到 AI Gateway credits。这避免了密钥失效时悄悄切换到另一种计费方式，但你必须为配置错误准备清晰的告警。
上线前先按任务选供应商，再决定是否切换
稳妥的试用顺序，是先用默认的 Ceramic.ai 跑通链路，再用同一批真实问题比较三家的结果。比较时不要只看“搜到了没有”，还要记录结果是否能直接提供给模型、来源是否适合展示、延迟是否影响用户体验，以及日志和成本是否够透明。
如果 Agent 会在一次任务里频繁查网页，低价和低延迟会更重要；如果需要把短而相关的原文片段塞进上下文，Exa 的 highlights 可能更顺手；如果想拿到快速、带来源的结果，再由自己的工具链完成后处理，Linkup 的返回方式更贴近这个工作流。以上是匹配关系，不是 Cloudflare 对效果的保证。
接入前，建议把三个问题写进评审单：
- 我们要的是长页面描述、相关 highlights，还是原始结果加片段？
- 这次请求走 AI Gateway credits，还是走 BYOK？目录价之外，还有哪些应用层成本？
- Agent 的查询和返回内容适用哪种数据保留策略，谁负责定期复核供应商条款？
Cloudflare 这次发布的价值，确实在于减少了换供应商和接入网关的工程摩擦。但它更适合被当成一个可观测、可切换的搜索基础设施，而不是“接上就可靠”的答案机器。先把供应商差异、计费边界和来源核验写进系统设计，再把 Beta API 放进真实流量里验证，才是这项能力目前更稳妥的用法。
来源
- Introducing Web Search API：Cloudflare 官方公告，2026 年 10 月 2 日
- How to use Web Search API：Cloudflare 官方使用文档
- Providers：Cloudflare 官方供应商、价格与数据保留说明
- AI Gateway unified billing：Cloudflare AI Gateway 统一计费文档
