當 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，因此搜尋呼叫會出現在 Gateway 日誌中，並依所選供應商的目錄 API 價格從 AI Gateway credits 扣款，不額外加價。
對開發者來說，變化不在「搜尋」這個動作本身，而在於邊界被收攏了。以前你可能要分別管理 Ceramic.ai、Exa 或 Linkup 的 SDK、金鑰、錯誤處理和帳單；現在可以把供應商選擇變成請求參數，把搜尋呼叫放進同一個 Gateway 觀察。
這個抽象就像替團隊裝了一部總機：對外只撥一個號碼，後面接哪一家線路可以切換。但總機不會替你判斷哪條線路最適合，也不會自動把搜尋結果變成事實。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 的 Gateway，或者預先建立自己的 Gateway，並準備 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 存到 Gateway，供應商會依你與它的協議直接計費。方案、稅費、重試、上層模型和應用程式運行成本，都不能從這張表直接推導。
統一入口不會替你做來源核驗
Web Search API 回傳的是搜尋結果清單，不是已經核實過的結論。Agent 如果拿一個過時頁面、行銷文案或彼此矛盾的報導直接生成答案，統一 Gateway 不會自動把它變成可靠事實。
因此，接入時要把「搜尋」和「回答」拆開看。搜尋工具負責取得 URL、標題、描述和請求中繼資料；你的應用程式還需要決定是否抓取原文、是否要求多個來源相互印證、哪些網域可以作為高信任來源，以及最終答案要不要展示引用。
日誌是這套方案比較有價值的一層。請求經過 AI Gateway 後，搜尋呼叫會出現在 Gateway 日誌中，回傳的 requestId 和延遲資訊也能幫助你追蹤一次 Agent 任務。但日誌只能告訴你請求發生了什麼，不能代替業務側評估：例如某個問題到底找到多少有效來源，結果是否被模型正確使用。
資料策略也不能只看「Cloudflare 統一接入」這幾個字。Cloudflare 公告稱，三家供應商都支援透過 Cloudflare 發起請求時的 Zero Data Retention；供應商頁面的表格則分別列出各自狀態，其中 Exa 目前標為 No，而 Ceramic.ai 和 Linkup 標為 Yes。具體到你的帳號、請求路徑和協議，正式接入前仍應查看最新條款。
如果使用 BYOK，金鑰管理還有一個容易被忽略的行為：請求指定了 byokAlias 後，如果這個別名沒有在 Gateway 中設定，呼叫會直接失敗，不會自動回退到 AI Gateway credits。這避免了金鑰失效時悄悄切換到另一種計費方式，但你必須為設定錯誤準備清晰的告警。
上線前先按任務選供應商，再決定是否切換
穩妥的試用順序，是先用預設的 Ceramic.ai 跑通鏈路，再用同一批真實問題比較三家的結果。比較時不要只看「有沒有搜到」，還要記錄結果是否能直接提供給模型、來源是否適合展示、延遲是否影響使用者體驗，以及日誌和成本是否足夠透明。
如果 Agent 會在一次任務中頻繁查網頁，低價和低延遲會更重要；如果需要把短而相關的原文片段塞進上下文，Exa 的 highlights 可能更順手；如果想拿到快速、帶來源的結果，再由自己的工具鏈完成後處理，Linkup 的回傳方式更貼近這種工作流程。以上是匹配關係，不是 Cloudflare 對效果的保證。
接入前，建議把三個問題寫進評審單：
- 我們要的是長頁面描述、相關 highlights，還是原始結果加片段？
- 這次請求走 AI Gateway credits，還是走 BYOK？目錄價之外，還有哪些應用層成本？
- Agent 的查詢和回傳內容適用哪種資料保留策略，誰負責定期複核供應商條款？
Cloudflare 這次發布的價值，確實在於減少了更換供應商和接入 Gateway 的工程摩擦。但它更適合被當成一個可觀測、可切換的搜尋基礎設施，而不是「接上就可靠」的答案機器。先把供應商差異、計費邊界和來源核驗寫進系統設計，再把 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 統一計費文件
