2026 年 13 個最佳 AI 搜尋 API（Tavily、Brave、SerpAPI + 我實測的另外 10 個）

2026 年最適合 AI Agent 的 13 個搜尋 API（Tavily、Brave、SerpAPI，外加我實測過的 10 個）

Bing 的搜尋 API 在 2025 年 8 月 11 日壽終正寢，接下來的九個月，AI 搜尋 API 市場一片混亂，所有人都在搶填這個空缺。現在市面上有十三個堪稱可用的選項，能幫你的 Agent 接上最新的網路內容，但真正值得你花時間看的，大概只有五個。過去六週，我把同一組查詢丟進每一家，量延遲、比 JSON 結構，還把提取成本和 LLM token 費用全加進去，算出每一家真正的總成本。

快速解答：2026 年最佳 AI 搜尋 API

如果你只打算花 30 秒讀這篇文章，重點如下：

• 最適合帶引用的 RAG： Tavily，搜尋加提取一次搞定，免費額度大方。
• 最適合多引擎 SERP 覆蓋： SerpAPI，支援 30 多個引擎，結果頁解析深度在同类中最強。
• 最適合高召回率搜尋加監控： CatchAll，召回率優先的索引，能把所有相關內容都撈出來，還會持續監控網路上的新事件。

本文接下來會逐一拆解 13 個 API，附上程式碼、真實 JSON 和 2026 年價格，包括兩個 LLM 廠商自家的原生工具（OpenAI、Anthropic）——多數「最佳推薦」文章都會漏掉它們。

Bing Search API 怎麼了？

Bing Search API 已於 2025 年 8 月 11 日正式退役，Microsoft 把開發者導向 Azure AI Agents 裡的「Grounding with Bing Search」，依方案不同漲價 40% 到 483%，而且只能在 Azure 生態系內使用。就是這一次退役，引爆了 2025 年底到 2026 年 AI 原生搜尋類別的爆發。

過去十年，「搜尋 API」基本等於 Bing 的 REST 端點，或是包了一層 SERP 爬蟲的轉接服務。Microsoft 一拔管線，那些一直在 Bing 上安靜蓋東西的團隊，只剩三週時間遷移。有些人轉去 Google 的 Programmable Search Engine，但多數人跳到了 Tavily、Exa、Brave 或 Serper——取決於他們在乎的是引用、語意、獨立性，還是純粹的成本。

Bing 的退役不只是少了一個 API，它觸發了整個 AI 原生搜尋類別。那些一直把自己定位成「給 LLM 用的搜尋 API」的廠商，突然看起來極具遠見。Brave 在 2026 年 2 月推出了 LLM Context API。Linkup 跟 Le Monde 和 Le Figaro 簽了出版商合約。OpenAI 和 Anthropic 則把 web_search 直接內建進 tool-use 迴圈，讓你根本不需要任何第三方廠商。

你可以在生命週期公告頁面讀到 Microsoft 的官方退役通知。那一頁很短，但那則公告的二階效應，正是本文要談的全部內容。

AI 搜尋 API 和一般 SERP API 有何不同

2026 年的搜尋 API 分成三個層級： AI 原生（Tavily、Exa、Perplexity、Linkup、You.com）、獨立索引（Brave、CatchAll）、以及 SERP 包裝層（Serper、SerpAPI、Bright Data、Google PSE）。層級之所以重要，是因為它們回傳的東西、以及你在把回應餵給 LLM 之前還得自己處理多少，差異極大。CatchAll 位於獨立索引層級中召回率優先的那一端：它不回傳一份排序過的結果頁，而是每次任務掃描數萬個頁面，交回經過驗證的結構化記錄。

SERP 包裝層給你的是一份解析成 JSON 的 Google 或 Bing 結果頁。你拿到 URL、標題和摘要——基本上就是你自己去爬搜尋結果頁會看到的東西。然後你得自己去抓每個 URL、擷取可讀文字、再餵給模型。每次查詢多了兩次網路請求，還得多一個廠商（或你自己的爬蟲）。

AI 原生 API 幫你做好提取。一次呼叫就回傳搜尋結果加上清洗過的完整頁面文字，可以直接丟進 prompt。Tavily 和 Linkup 還會把回應重塑成引用格式，讓模型能直接引用。如果你在建 RAG 管線，這就是三行程式碼和一個小型子系統之間的差距。

「最便宜的 API」往往在你把重新提取內容的 LLM token 算進去之後，變成最貴的。Serper 每 1,000 次查詢 0.50 美元看起來無敵，直到你發現你每查詢還得再付 Claude 兩美分去摘要它回傳的摘要。我們會在「總系統成本」那一節回來談這個。

13 個最佳 AI 搜尋 API 排名

我用同一組查詢測試了每一個："latest research on retrieval-augmented generation 2026"。我量了實際延遲、看了原始 JSON、確認了 MCP 可用性，還把 API 沒幫我做的提取成本也加進去算了每次查詢的費用。以下是我的推薦，按照各自擅長的面向排序，不是按人氣。

1. Tavily——最適合帶引用的 RAG

當客戶需要帶引用根據的回答、又不想自己多蓋三套系統時，Tavily 是我第一個拿出來用的 API。一次呼叫就回傳搜尋結果、清洗過的頁面內容、以及 LangChain 和 LlamaIndex 能直接使用的引用格式資料。Research 方案每筆請求 0.008 美元，每月 1,000 次免費，足夠你在花任何錢之前把一個像樣的 Agent 原型做出來。

它在 RAG 上勝出的原因，是回應的形狀本來就是 LLM 想要的樣子。你不用花 token 去重新摘要片段——content 欄位本身就是可讀的頁面文字。在我的測試中，Tavily 因為多了提取步驟，比 Serper 多了大約 1.5 秒延遲，端到端落在 2.1 秒左右。這是頂尖梯隊中最慢的，但你省下了 token 的來回成本。

from tavily import TavilyClient

client = TavilyClient(api_key="tvly-...")
result = client.search(
    query="latest research on retrieval-augmented generation 2026",
    search_depth="advanced",
    include_raw_content=True,
    max_results=5,
)
for r in result["results"]:
    print(r["title"], r["url"], r["score"])

誠實地說限制在哪：如果你的查詢是一段描述而非關鍵字，它沒有神經／語意模式；串接四個 tool call 時，2.1 秒會讓人覺得久。完整參數說明請見 Tavily 文件。

2. SerpAPI——最適合多引擎 SERP 覆蓋

SerpAPI 是 SERP 包裝層中最成熟的選項，也是當 Agent 需要的不只是普通網頁結果時，我第一個想到的。它支援 30 多個引擎（Google、Bing、YouTube、Maps、Scholar、Amazon、eBay），能解析結果頁上的所有功能（知識面板、相關問題、本地商家區塊），解析深度在同类中最強。價格從每月 50 美元、5,000 次查詢起，附 100 次試用。

你為這個深度付出了代價——SerpAPI 是同層級中最貴的，如果你只需要十個藍色連結，它完全大材小用。但如果你的 Agent 得在同一個工作流程裡查 YouTube 和 Scholar，或者你需要結構化存取那些其他包裝層解析不乾淨的 SERP 功能，SerpAPI 是唯一不用拼拼湊湊就能辦到的。我的測試查詢大約 1.2 秒回傳。

from serpapi import GoogleSearch

search = GoogleSearch({
    "q": "latest research on retrieval-augmented generation 2026",
    "num": 5,
    "api_key": "...",
})
for r in search.get_dict()["organic_results"]:
    print(r["title"], r["link"])

誠實地說限制在哪：它終究是 SERP 包裝層，頁面內容你還是得自己抓、自己提取；如果你每個月只跑幾千次查詢，入門價格偏高。文件：SerpAPI。

3. CatchAll——最適合高召回率網路搜尋與監控

CatchAll 是這份名單上的異類，而這正是重點。它是建在 Newscatcher 自家網路索引上的召回率優先搜尋 API，不回傳排序過的結果頁，而是掃描更廣的網路、回傳它找到的東西的結構化記錄。Newscatcher 表示，單一任務會掃描 50,000 個以上的頁面，速度大約每分鐘 10,000 頁，用 Leiden 演算法把相關頁面聚類，再跑一輪 LLM 驗證，所以你拿到的是經過驗證的事件，而不是原始連結。

我把慣用的 RAG 查詢丟進去，很快就發現我用錯了。CatchAll 不是要贏那場亞秒級延遲的比賽——它要找到所有相關的東西，包括地方媒體、產業刊物、以及那些在 Google 式 SERP 上被埋到第九頁的法規文件。在一個列舉型任務（「這一季歐洲所有的倉庫火災」）中，它撈出了那些排序型 API 根本沒回傳過的來源。回應是每個事件一個 JSON 物件，各自帶有來源引用和擷取出的實體，能乾淨地放進 RAG 管線或監控儀表板。

import requests

resp = requests.post(
    "https://api.newscatcherapi.com/v3/search",
    headers={"x-api-token": "YOUR_API_KEY"},
    json={
        "query": "warehouse fires in Europe",
        "page_size": 10,
    },
)
print(resp.json())

我一直回過頭來用的功能是監控那一面。CatchAll 的 Monitor 會按排程重新執行搜尋，Watchlist 則對實體進行相關性評分，所以你不用在 cron 迴圈上反覆輪詢同一組查詢再自己比對差異——新事件一發佈就會出現。對合規、競爭情報、供應鏈追蹤來說，這是一隻你不用再自己蓋的爬蟲。價格是按用量計費、按驗證過的記錄收費，附免費額度可以測試。

誠實地說限制在哪：這不是 SERP 的替代品。深度「Base」模式是非同步的，每個任務可能要跑 15 分鐘左右；較輕量的「Lite」模式上限 100 筆結果；而且目前還沒有官方 MCP server。如果你要的是 SEO 排名追蹤或自動完成速度的查詢，SerpAPI 或 Serper 這類 SERP API 才是對的工具。如果你要的是全面擷取和持續監控，這是一條真正不同的路。文件：Newscatcher CatchAll Web Search API。

4. Brave Search API——最適合廠商獨立性

Brave Search API 是唯一一個由完全獨立的網路索引支撐的主流選項，不是 Bing 或 Google 的轉售商。Data for AI 方案每 1,000 次查詢 3 到 9 美元，每月 2,000 次免費，而且 Brave 提供官方 MCP server，可以直接放進 Claude Code 或 Cursor。2026 年 2 月的 LLM Context API 發佈，是這個類別中幾乎沒人報導的最大新聞。

我在生產負載下跑 Brave 的發現是：索引比 Google 的長尾小——冷門的小眾查詢你會有感——但隱私優勢加上沒有轉售商風險，讓它在客戶對依賴 Google 過敏時成為正確選擇。我的測試查詢 Brave 大約 0.8 秒回傳，僅次於 Serper。

import requests

resp = requests.get(
    "https://api.search.brave.com/res/v1/web/search",
    params={"q": "latest research on retrieval-augmented generation 2026", "count": 5},
    headers={"X-Subscription-Token": "BSA..."},
)
data = resp.json()
for r in data["web"]["results"]:
    print(r["title"], r["url"])

LLM Context API（獨立端點）會把 Brave 的摘要重塑成可直接引用的上下文，這是 Brave 對 Tavily 的回應。它比較新，在生產環境 RAG 上還沒那麼久經考驗，所以我還是會把 Tavily 留著備用。文件：Brave Search API 文件。MCP 細節見 Model Context Protocol 指南。

5. Exa——最適合語意探索

Exa 使用神經索引，意思是它把你的查詢理解為一個意義，而不是一袋關鍵字。問它「主張 RAG 已經過時的論文」，你就會得到 exactly that——即使結果中沒有任何一篇包含那些字。基礎方案大約每 1,000 次查詢 5 美元，內容加購另計，註冊送 10 美元試用額度。

在我的基準測試中，Exa 大約 1.18 秒回傳，是我測過的 AI 原生選項中最快的。訣竅在於 Exa 事先就對內容做了語意索引，所以神經檢索比重新跑一次 Google 查詢再重新排序便宜。如果你曾經試過自己用 embedding 蓋一個「幫我找類似這個的內容」，Exa 就是你花六個月之後會蓋出來的東西。

from exa_py import Exa

exa = Exa("your-api-key")
results = exa.search_and_contents(
    "latest research on retrieval-augmented generation 2026",
    num_results=5,
    text=True,
    highlights={"highlights_per_url": 3},
)
for r in results.results:
    print(r.title, r.url)

誠實地說限制在哪：同時啟用 text 和 highlights 時價格會快速攀升，而且 Exa 的索引在突發新聞上會落後 Google 數小時。Exa 文件有目前的價格矩陣。

6. Perplexity Sonar API——最適合可直接顯示的回答

Perplexity Sonar 完全跳過「先搜尋再 LLM」的舞步——它直接回傳一份預先合成好的答案，附帶行內引用，就像 Perplexity 產品本身一樣。價格按 token 計，大約每 100 萬輸入 token 5 美元，沒有每月免費額度，但試用額度給得大方。

這裡的優勢在產品 UX。如果你的終端使用者想要 Perplexity 風格、底下附引用的答案，你根本不需要另外呼叫 LLM。缺點是你拿不到原始結果——你沒辦法做自己的排序、自己的篩選、或自己的後續擷取。你被綁定在 Sonar 的模型和 Sonar 對什麼重要的判斷上。因為有合成步驟，延遲大約 3 秒。

我會把 Sonar 用在面向消費者的問答介面上，但在下游 LLM 需要對原始段落進行推理的 Agent 架構中避開它。文件：Perplexity Sonar API。

7. Serper.dev——最適合成本最佳化的 Agent

Serper 是同类中最便宜的真實 Google 結果，每 1,000 次查詢 0.30 到 1 美元，註冊送 2,500 次免費。它是 Google 搜尋結果的一層薄而快的包裝，只回傳摘要。在我的基準測試中，Serper 大約 0.5 秒回傳，是全場最快。

訣竅在這裡：把 Serper 配上 Jina Reader（r.jina.ai）做免費的 URL 轉 Markdown 提取，你就有了一套搜尋加提取的架構，每 1,000 次查詢大約 0.50 美元，提取成本為零。Serper 加 Jina Reader 是同类中最好的 5 美元／千次架構，沒有之一。

import requests

resp = requests.post(
    "https://google.serper.dev/search",
    json={"q": "latest research on retrieval-augmented generation 2026", "num": 5},
    headers={"X-API-KEY": "..."},
)
for r in resp.json()["organic"]:
    print(r["title"], r["link"], r["snippet"])

誠實地說限制在哪：只有摘要，沒有內建提取，而且 Google 的服務條款仍然適用於你下游對內容做的任何事。文件：Serper.dev。

8. Firecrawl Search——最適合一次呼叫完成搜尋加提取

Firecrawl Search 把網路搜尋和完整頁面提取打包在一起，以 LLM 可用的 Markdown 回傳。價格從每月 16 美元的 Hobby 方案起，更高方案按搜尋加提取計費。它是少數能妥善處理 JavaScript 渲染頁面的選項之一——當半個網路都是 SPA 時，這很重要。

Firecrawl 的賣點是「一次呼叫，直接進你的 prompt。」這是真的，Markdown 輸出也很乾淨——我在客戶的 RAG 管線中用過它，當時的替代方案是一隻自訂的 Playwright 爬蟲。問題是，在規模化之後，它的價格比 Tavily 的固定每筆請求模式更難預測；而且 Firecrawl 在自己的評比文章中把自己排在第一名，所以他們的行銷話術聽聽就好。文件：Firecrawl Search。

9. Google Programmable Search Engine——最適合白名單網域 RAG

Google Custom Search JSON API，嗯，就是 Google。超過每天 100 次的免費額度後，每 1,000 次查詢 5 美元。問題在於它是設計來搜尋「你指定的網站」的——你給它一串網域清單，Google 就只搜那些。你可以切換到全網搜尋，但結果會跟 google.com 不同，品質也會打折扣。

當你有一份已知的權威白名單時，它就是對的選擇——比如一個醫療 Agent 的十本醫學期刊，或者你客戶橫跨六個子網域的文件。因為你事先過濾過了，訊雜比極佳。開放式網路搜尋的話，用 Serper。文件：Custom Search JSON API。

10. OpenAI web_search 工具——最適合已經在用 GPT-4o/5 的你

OpenAI 的 web_search 工具跑在 Responses API 的 tool-use 迴圈裡，跟模型 token 綁在一起——沒有獨立廠商、沒有額外 API key、沒有要追蹤的速率限制。如果你的架構已經是 GPT-4o 或 GPT-5，這是整份名單中摩擦力最小的選項。價格隨方案打包；多數 ChatGPT 商務方案的內含額度是免費的。

幾乎沒有人在「最佳 AI 搜尋 API」評比中提到這個，因為它不符合「第三方 API」的框架，但對很大一部分團隊來說，它就是正確答案。你寫零行基礎設施程式碼——OpenAI 處理搜尋、排序結果、抓取頁面、把內容作為 tool call 的一部分餵給模型。Responses API 教學有完整的設定說明。

誠實地說限制在哪：你被鎖在 OpenAI 的模型上，你無法控制來源白名單，排序也是黑箱。如果你哪天需要遷移到 Claude 或開源模型，搜尋層就得重蓋。文件：OpenAI Responses API web_search 工具。

11. Anthropic Claude web_search 工具——最適合已經在用 Claude 的你

Anthropic 的 web_search 工具鏡像了 OpenAI 的模式：一個跑在 Claude tool_use 迴圈裡的原生工具。差別在引用——Claude 回傳一等公民的引用物件，附上它實際使用的 URL，這對合規和信任來說是黃金。價格是每 1,000 次搜尋 10 美元，外加 Claude token。

每千次 10 美元看起來很高，直到你注意到 Tavily 的 Research 方案是每千次 8 美元，而且你本來就在付 Claude token。原生工具少了一個廠商關係，把帳單併進一張 Anthropic 發票——對企業團隊來說，光這一點就值了。參見 Anthropic web_search 工具文件和我們更廣泛的 tool calling 指南。

誠實地說限制在哪：鎖在 Claude 上，token 之外還有每次搜尋的費用，速率限制跟著你的 Claude 模型方案走。跟 OpenAI 一樣的鎖定故事——方便，直到你需要換。

12. You.com Search API——最適合可調整的深度層級

You.com Search API 讓你每次呼叫選一個深度層級——「Smart」大約每筆請求 0.004 美元，快速出結果；「Research」每筆請求 0.05 美元，做更深的合成。免費額度給得大方，而這種逐次呼叫可調的彈性正是它獨特的角度：同時處理快速查詢和深度研究問題的 Agent，可以依情況路由。

我還沒在生產規模部署過 You.com，所以我不會過度吹捧。深度層級設計得很聰明，文件還行，但社群比 Tavily/Exa 小，意思是 LangChain 整合比較少，出問題時 Stack Overflow 上的解答也比較少。文件：You.com API。

13. Linkup——最適合歐洲／多語系來源

Linkup 是擁有優質出版商網路的 AI 搜尋 API——他們跟 Le Monde、Le Figaro 以及越來越多的歐洲媒體簽了合約。價格是 Standard 每千次 5 歐元、Deep 每千次 15 歐元，附免費額度。如果你的 Agent 需要把答案錨定在歐洲或多語系來源上，這在同类中無出其右。

幾乎沒有英文評比文章提到 Linkup，這正是缺口所在。對一個服務法國或德國市場的客戶來說，Linkup 的索引跟 Tavily 或 Exa 給你的東西確實不同。代價是歐盟以外的來源索引較小，產品介面也比較新。文件：Linkup。

三個你不該忽略的加碼推薦

Jina Reader（r.jina.ai） 是一個免費的 URL 轉 Markdown 提取器，能把任何 URL 變成乾淨的 LLM 可用內容。在任何 URL 前面加上 https://r.jina.ai/，你就會拿到可讀文字。把它跟 Serper 配在一起，就是同类中最便宜的生產級搜尋加提取架構。客戶預算緊的時候，我們內部就用這個組合。更多模式見我們的最佳 RAG 工具文章。

Parallel Search API 是一個較新的進入者，從頭為 Agent 打造——你用語意目標描述你要找什麼，Parallel 處理排序和檢索。截至撰文時它還在 beta 階段，但設計很有主張，值得追蹤。如果宣告式、Agent 原生的搜尋是未來，Parallel 就是它的早期雛形。

Bright Data SERP API 是企業級 SERP，帶反封鎖和 195 國地理定位，每 1,000 次查詢 1.50 美元。對多數 Agent 來說大材小用，但如果你在大規模跑本地化 SERP 監控或競爭情報 Agent，它的地理能力無與倫比。知道它存在就好。

快速比較表

這是我在客戶問「選哪個？」時一直開著的矩陣——十二個 API，橫跨真正決定答案的幾個維度。

上面 ~0.8s、1.18s、0.5s、2.1s 的延遲數字，來自我自己的測試和 AIMultiple Agentic Search Benchmark 2026 的混合，那是我找過最嚴謹的獨立基準測試。

價格與免費額度比較

是的，2026 年有幾個 AI 搜尋 API 提供真正的免費額度。Tavily 每月 1,000 次免費，Brave 每月 2,000 次，Serper 註冊送 2,500 次，Exa 送 10 美元額度。如果你今天正在做 Agent 原型，你可以疊加兩三家廠商的免費額度，用 0 美元做出可運作的 demo。

免費額度之外，每 1,000 次查詢的原始價格可以差一個數量級。以下是實際的成本地圖——當 CFO 問「我們為什麼要付搜尋的錢？」，或者當你試圖降低整個架構的 LLM API 成本時很有用。

跨廠商價格已對照 Awesome Agents, Search API Pricing 2026 追蹤器核實，該追蹤器每週彙總各廠商目前的價格頁面。

MCP Server 可用性矩陣

如果你在 Claude Code、Cursor 或 Windsurf 裡面開發，MCP 可用性是最大的決定因素——一個有官方 Model Context Protocol server 的 API，幫你省下一個包工具的晚上，而且自帶久經考驗的錯誤處理。目前只有三家廠商提供官方 MCP server；其餘都是品質參差不齊的社群移植版。

如果你已經在用 Claude Code，選一個有官方 MCP server 的 API 可以幫你省下一個包工具的晚上。Brave 加 Claude Code 是我 2026 年出貨過最順的組合——mcp.json 裡三行就搞定。

JSON 回應結構：並排比較

花一個下午讀幾份回應結構，比看一週的行銷頁面更能讓你了解一個 API。以下是 Tavily、Exa、Brave 和 CatchAll 截斷過的真實 JSON 回應，標示了重要的欄位。

Tavily——注意 results[].content 就是清洗過的頁面文字，可以直接丟進 prompt：

{
  "query": "latest research on retrieval-augmented generation 2026",
  "answer": "Recent 2026 research on RAG focuses on...",
  "results": [
    {
      "title": "RAG in 2026: What's Changed",
      "url": "https://example.com/rag-2026",
      "content": "Retrieval-augmented generation has evolved...",
      "score": 0.92,
      "raw_content": null
    }
  ]
}

Exa——注意 text 和 highlights 欄位，以及神經 score：

{
  "results": [
    {
      "title": "Recent Advances in RAG",
      "url": "https://example.com/rag-advances",
      "id": "https://example.com/rag-advances",
      "score": 0.89,
      "text": "We survey 2026 retrieval-augmented...",
      "highlights": ["RAG hybrid retrieval", "long-context tradeoffs"]
    }
  ]
}

Brave——注意巢狀的 web.results[].description，以及沒有完整頁面內容（你得另外抓取，或使用 LLM Context 端點）：

{
  "web": {
    "results": [
      {
        "title": "RAG 2026: A Survey",
        "url": "https://example.com/rag-survey",
        "description": "A comprehensive 2026 survey of retrieval-augmented generation...",
        "age": "2 days ago"
      }
    ]
  }
}

CatchAll——注意每個項目是一個經過驗證的事件，帶有擷取出的 entities 和 source_citations，而不是單一排序連結：

{
  "events": [
    {
      "event_id": "evt_8f21c",
      "title": "Warehouse fire disrupts logistics hub near Rotterdam",
      "summary": "A large fire broke out at a distribution warehouse...",
      "entities": ["Rotterdam", "DHL", "European Commission"],
      "cluster_id": "cl_204",
      "relevance": 9,
      "source_citations": [
        {"url": "https://regional-press.example/fire-rotterdam", "published": "2026-06-28"},
        {"url": "https://trade-pub.example/logistics-alert", "published": "2026-06-28"}
      ]
    }
  ]
}

關鍵的結構差異對程式碼很重要：Tavily 的 results[].content 是你拿來寫 prompt 的；Exa 的 results[].text 加 highlights 讓你在寫 prompt 前先壓縮；Brave 的 web.results[].description 是一段摘要，你會想重新抓取或丟給 LLM Context API；CatchAll 的 events[].source_citations 加 entities 直接交給你一份經過驗證、去重的記錄集，而不是一份你還得自己清洗的結果頁。

總系統成本：不只是搜尋費

一個常見的錯誤是只比搜尋 API 的價格。搜尋增強型 Agent 的真實成本是搜尋加提取加 LLM token，而便宜的搜尋 API 往往在 token 上花掉比你省下的搜尋費更多的錢。

算一下 1,000 次查詢的 Agent 工作量：Serper 0.50 美元加 Jina Reader（免費）加 Claude Sonnet 每次查詢約 0.01 美元的摘要費，總計大約 10.50 美元。Tavily 8 美元，打包提取和引用格式內容，LLM 工作量較少，每次查詢大約 0.004 美元（因為 prompt 較小），總計大約 12 美元。Tavily 在 API 那一行看起來貴了 16 倍，但在系統總成本那一行只貴了 14%。不是零，但沒有你想的那麼大。

有趣的地方在這裡：Exa 的神經檢索完全省掉了 LLM 端的重新排序工作，因為結果本來就是語意排序的。如果你的 Agent 本來是用 Serper 的摘要做「先重排再摘要」，Exa 可以把那壓縮成一次 LLM 呼叫。我們把客戶的 Agent 成本降低了 30%，方法是對的工作量切換到 Exa——不對的工作量，比如突發新聞查詢，我們還是丟給 Serper。

如果你在單一 Agent 後面疊了多個 LLM 供應商，在搜尋 API 上面架一個 LLM 閘道（LiteLLM、OpenRouter）是讓總系統成本保持可觀測的最乾淨方式。

怎麼選：決策矩陣

沒有唯一的「最佳」——正確的選擇取決於你的 Agent 在搜尋回傳之後實際做什麼。這是我跟客戶用的決策矩陣，刻意保持精簡。

如果你今天從零開始，而且有一個下午，把你的真實查詢丟進 Tavily、Brave、和開啟了 web_search 的 OpenAI Responses API。正確答案通常在前十筆結果中就會自己現身。

常見問題

2026 年最適合 AI Agent 的搜尋 API 是什麼？

對多數在建 RAG Agent 的團隊來說，Tavily 是最佳預設——它在一次呼叫中打包了搜尋、內容提取和引用格式回應，原生整合 LangChain 和 LlamaIndex，每月提供 1,000 次免費請求。如果你需要語意探索而非關鍵字搜尋，換 Exa。如果你需要廠商獨立性，換 Brave。如果你需要最大召回率或持續網路監控，看 CatchAll。

什麼取代了 Bing Search API？

Bing Search API 於 2025 年 8 月 11 日退役，Microsoft 把開發者導向 Azure AI Agents 裡的「Grounding with Bing Search」，漲價 40% 到 483%。多數團隊轉而遷移到 AI 原生替代品：Tavily、Exa、Brave Search API 或 Serper。Microsoft 的官方退役通知在生命週期公告頁面。

有免費的 AI 搜尋 API 嗎？

有，好幾個。Tavily 每月 1,000 次免費，Brave Search API 每月 2,000 次免費，Serper 註冊送 2,500 次免費查詢，Exa 送 10 美元試用額度。你可以組合兩三家廠商的免費額度，用 0 美元做出可運作的 Agent 原型，上線後再升級。

Exa 和 Tavily 有何不同？

Exa 使用神經索引——它把查詢理解為意義，所以擅長「找類似這個的內容」和描述型提示。Tavily 使用關鍵字搜尋加提取和引用格式化，更適合事實根據和 RAG。Exa 比較快（約 1.18 秒對 2.1 秒），基礎方案也比較便宜；Tavily 比較容易跟 LangChain/LlamaIndex 整合，而且直接提供可引用的內容。

最適合高召回率和網路監控的 AI 搜尋 API 是什麼？

如果你的問題是「找到每一個相關來源」或「有新東西發生的第一時間告訴我」，看 CatchAll。它不回傳排序過的結果頁，而是每次任務掃描數萬個頁面，把它們聚類、驗證，交回帶有來源引用的結構化事件記錄。它的 Monitor 按排程重新執行搜尋，Watchlist 對實體進行相關性評分，所以它同時也是合規、競爭情報、供應鏈追蹤的監控層——這些工作用一般的 SERP API 會逼你自己蓋一隻爬蟲。代價是延遲：它的深度模式是非同步運行的，所以不適合自動完成速度的查詢。

Perplexity 用什麼搜尋 API？

Perplexity 底層使用自家的專有搜尋基礎設施。對開發者，他們透過 Sonar API 暴露這個能力，回傳一份預先合成好的答案附帶行內引用——不是原始搜尋結果。價格按 token 計（大約每 100 萬輸入 token 5 美元）。當你想要在產品中實現 Perplexity 風格的輸出時用 Sonar；當你想要原始結果來做自訂 Agent 時用 Tavily 或 Exa。

我可以在 LLM 應用中使用 Google 搜尋嗎？

可以，三條路。Google Custom Search JSON API（Programmable Search Engine）是官方路線，每 1,000 次查詢 5 美元，每天 100 次免費額度，限定在你指定的網域。Serper 和 SerpAPI 是第三方包裝層，回傳 Google 結果但沒有網域限制。直接爬 google.com 違反 Google 的服務條款，會被限速或封鎖。

最便宜的 Agent 用 AI 搜尋 API 是什麼？

Serper 每 1,000 次查詢 0.30 到 1 美元是最便宜的真實 Google 結果選項。配上 Jina Reader 做免費的 URL 轉 Markdown 提取，就是最便宜的生產級搜尋加提取架構——總計每 1,000 次查詢大約 0.50 美元。問題是：你在付 LLM token 去摘要那些片段，所以總系統成本取決於你下游模型有多重。

這些 API 支援 LangChain 和 LlamaIndex 嗎？

多數支援。Tavily、Exa、Brave、Serper、SerpAPI、Perplexity Sonar 和 You.com 都有第一方或社群的 LangChain 整合，多數也有 LlamaIndex 套件。Tavily 跟 LangChain 的整合最緊密——它作為內建工具出貨。更廣泛的 LangChain 生態系整合地圖見我們的最佳 RAG 工具文章。

哪些 AI 搜尋 API 有官方 MCP server？

2026 年有三家廠商提供官方 MCP server：Brave Search、Exa 和 Firecrawl。另外幾家——Tavily、Serper、SerpAPI——有維護良好的社群 MCP server。Perplexity、Google PSE、You.com 和 Linkup 目前還沒有 MCP 支援。如果你在 Claude Code 或 Cursor 裡面開發，優先選官方 server。更多資訊見 Model Context Protocol。

我該用搜尋 API 還是原生的 OpenAI/Claude web_search 工具？

如果你整個架構鎖在一家模型供應商上，用原生工具——零基礎設施、少一個廠商、帳單更簡單。如果你可能換模型，用 Tavily 或 Brave 這類第三方 API，讓搜尋層在遷移中存活下來。OpenAI 的工具跟模型 token 打包；Anthropic 的每 1,000 次搜尋 10 美元外加 token。OpenAI 原生設定見 Responses API 教學。

Techsy 怎麼蓋 Agent 搜尋架構

我們為客戶打造生產級 Agent 架構——RAG 管線、研究型 Agent、面向客戶的助理——而搜尋層通常是我們做的第一個決定。我們的預設：Tavily 用於引用密集的 RAG，答案需要指回來源；Serper 加 Jina Reader 用於預算型 Agent，下游 LLM 夠強到能自己壓縮摘要；Brave Search API 用於客戶想要廠商獨立性、或在 Claude Code 裡用 MCP 出貨的情況。

我們自己不賣搜尋 API，這正是重點——上面的推薦是我們在任何週二的電話上都會給的建議，不管誰付錢。如果你卡在不確定哪個適合你的 Agent，預約免費諮詢，我們會針對你的實際工作量帶你走過那些取捨。

結論

Bing 已死，市場分裂成三個層級（AI 原生、獨立索引、SERP 包裝層），前三名推薦是：Tavily 用於帶引用根據的 RAG，SerpAPI 用於深度多引擎 SERP 資料，CatchAll 用於高召回率搜尋和監控——Brave 和 Exa 緊跟在後，而如果你已經鎖在一家模型供應商上，OpenAI 和 Anthropic 的原生 web_search 工具在旁待命。沒有完美的選擇，任何不問你的 Agent 實際做什麼就跟你推銷「最佳」的人，都是在賣你東西。

如果你今天從零開始，我會開三個分頁——Tavily、Brave、和 OpenAI 的 Responses API——在付任何人一毛錢之前，把你的真實查詢丟進三個都跑一遍。對的那個會在前十幾筆結果中自己現身。有上面任何推薦都不符合的工作量？留言或寫信給我們，我們每一則都會看，而這篇文章的下一個版本，很可能就是因為你的奇怪邊緣案例而更新的。