如果你的 agent 需要抓一個即時網頁，它通常是怎麼做的？按 Cloudflare 在 2026 年 10 月 2 日發布的說法，多數 agent 是「猜」出網址，然後發一個 tool call 去 curl。猜錯了，你就會看到那次 fetch 回傳 404。這聽起來有點荒謬，但確實是目前很多 agent 系統的常態：模型沒有搜尋，只有回憶和運氣。
Cloudflare 推出的 Web Search API（官方公告）正是針對這個問題：讓 agent 像人一樣先查搜尋引擎，再把結構化的搜尋結果注入 context。首發合作夥伴是 Ceramic.ai、Exa 和 Linkup。
為什麼這對 builder 是實際的改變
模型凍結在訓練時間點之後，就無法討論新事件、新 API 版本或快速變動的文件。過去解法通常是自己串搜尋供應商：簽約、管 key、寫 retry、處理計費，然後在 observability 裡另外開一條追蹤線。現在 Cloudflare 把 web search 放進 AI Gateway，代表搜尋呼叫和模型推論走同一個控制平面——同一份 log、同一套存取控制、同一個 credit 餘額扣款。供應商報 list price，不加價。
這和我之前寫過的 cloudflare/auto 模型路由 是同一個方向：AI Gateway 正在從「幫你轉發請求」變成「幫你管理整條推論管線的周邊」。搜尋是最自然的下一步，因為 grounding 本來就是推論管線的一部分。
接入方式有三條路
按照公告，接入點分成三種：
- AI Gateway 直接用：搜尋請求出現在既有的 observability log 裡，從 AI Gateway credit 扣款，還能控制哪些人有權用哪些搜尋供應商。
- Direct REST API：給已有 backend、mobile app 或外部服務的團隊，帶上 AI Gateway token、在 payload 指定供應商即可。
- Workers Bindings：在 Workers 上建 agent 的話，一行程式碼就能接上，官方也提供了獨立的 binding 範例。
另外，Cloudflare 支援對搜尋供應商的 BYOK，就像對模型推論供應商一樣。如果你公司已經跟 Exa 或 Linkup 有約，可以帶著現有 key 接進 Gateway，不用重簽。
Crawler 標準是這次發布裡容易被忽略的重點
公告裡有一段值得認真讀：合作夥伴承諾符合 Cloudflare 的 Verified Bot 要求——爬蟲必須表明身分、遵守 robots.txt，而且搜尋回應必須附上原始內容的連結。Cloudflare 也會標示哪些夥伴支援 Zero Data Retention，讓你知道查詢資料不會被留存。
對 builder 來說，這不只是公關姿態。當你的 agent 產品要過客戶的資安審查時，「內容來源可追溯、爬蟲合規、資料不留存」是可以直接寫進回答的三件事。選擇供應商時，這些條款比搜尋品質本身更難事後補。
還在路上的部分
Cloudflare 正在把 native Server Tools 直接建進 AI Gateway，web search 會是第一批——目標是你不用自己定義和編排工具，控制平面直接提供。在這之前，如果你想自己把 web search 當 server tool 編排，公告裡有 Worker 程式碼片段可以直接用。
一個實際的起點：先拿你現有的 agent，把「猜 URL 再 fetch」的那段換成一次 web search 呼叫，比較 404 率和答案品質的差異。這是最小的驗證，也最能看出你的 use case 到底需不需要 grounding。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。