【2026 最新】AI Agent 搜尋 API 怎麼選？10 題小型 Eval 比較 Tavily、Exa、Parallel、Firecrawl

同一個 AI Agent 搜尋 API，只換供應商，答案就可能跟著變。問題往往不在模型突然變笨，而是 Tavily、Exa、Parallel、Firecrawl 各自交給模型的網址、排序、片段、快取與抓取結果不同。你若只抄一張總排行榜，很可能替別人的英文題庫選到冠軍，卻替自己的繁中任務選錯工具。

這篇專為第一次替 Agent 接網路搜尋的讀者寫。我們不假裝有一個永遠有效的第一名，而是帶你做一份可重跑的 10 題小型 Eval：固定同一條 search→fetch→cite 流程，分開量 citation correctness、coverage、freshness、latency 與單題成本，再把失敗樣本變成日後的回歸測試。本文的供應商規格查核至 2026 年 8 月 19 日；第三方數字則保留原始日期、模式與限制。

先說結論：AI Agent 搜尋 API 沒有脫離任務的總冠軍

🧭 記憶把手：搜尋 API 選型＝自己的 10 題 × 同一條 Agent loop × 可重跑紀錄。
排行榜適合提出候選人；真正的錄取通知，應由你的題目、證據門檻、延遲預算與帳單共同決定。

• 先測 retrieval：四家都只回搜尋結果或等量片段，暫時關掉供應商生成答案，避免把搜尋與寫答案混成一項。
• 再測 retrieval＋fetch：用共同抓取器做公平比較；進入決選後，再重播各家的原生抓取能力，確認正式架構的效果與成本。
• 先設引用硬門檻：來源無法支持答案，就算讀起來再流暢也不能通過。
• 10 題只做初篩：小樣本用中位數、範圍與逐題紀錄；累積真實流量後，才談穩定的 p95 與故障率。

為什麼只換搜尋 API，Agent 就像換了一個腦？

把 Agent 想成一位很會讀資料、但不能親自走進圖書館的研究員。搜尋 API 是館員：有人先給最像答案的三段摘要，有人帶回十個網址，有人偏好即時抓頁，有人把長頁面壓成任務相關片段。研究員沒變，桌上的證據卻變了；後續推理、引用與工具呼叫自然會改變。

一篇 2026 年 7 月的原始研究把這件事稱為「decision surface」。研究固定 GPT-5.4 Agent、共同抓取器與 100 題 SEALQA-HARD，只切換 Brave、Tavily、Firecrawl；三組最終語意正確題數接近（25、25、26），但命中證據的階段、取用網址與探索路徑不同。這不是四家產品的勝負表，而是很重要的警告：相似的最終分數，背後也可能消耗不同的搜尋與抓取預算。

若你還不熟悉外層控制邏輯，可先讀AI Agent Harness 是什麼。搜尋供應商只是工具之一；真正固定提示詞、重試、抓取、引用與停止條件的，是 harness。

四家 AI Agent 搜尋 API，官方介面各自強調什麼？

以下比較的是截至 2026 年 8 月 19 日的官方介面與計價單位，不是品質排名。功能存在只代表可以測，不代表一定做得比較好。

• Tavily：Search API直接暴露搜尋深度、主題、日期、網域與結果數等控制。官方計價文件目前把 basic、fast、ultra-fast 列為 1 credit，advanced 為 2 credits；若開啟 auto_parameters，它可能自動選 advanced，因此測試時要關掉自動切換或完整記錄實際用量。
• Exa：Search API可在同一 schema 要求 text、highlights、subpages 或結構化輸出，並以 maxAgeHours控制快取與 live crawl。官方 API 價格頁目前列一般 Search 每千次 7 美元、含最多 10 個結果；額外 contents 依頁面與內容類型計費。
• Parallel：現行 GA Search以 objective、2～3 個聚焦 query 與 LLM-ready excerpts 為核心，另有 Extract。basic、advanced 目前每千次 5 美元、預設 10 個結果；模式一定要寫進測試紀錄，不能拿 fast 的價格替 advanced 算帳。
• Firecrawl：Search先回 URL、標題與 query-relevant description；加上 scrapeOptions可在同一次請求帶回 Markdown 等頁面內容。官方目前以 credits 計價：每 10 個搜尋結果 2 credits，抓取頁面另計，因此不能只比較 search request 的表面價格。

白話選型假設可以先這樣寫：需要簡潔 reranked chunks 與明確搜尋參數，先把 Tavily 放進候選；需要同一介面內控制正文、子頁與快取年齡，測 Exa；想把 query objective 壓成精簡 excerpts，測 Parallel；搜尋後常要直接把網頁轉成 Markdown，測 Firecrawl。這四句只是測試優先順序，不是錄取結論。

第三方快照告訴我們什麼？又不能告訴我們什麼？

Artificial Analysis Search API Index在 2026 年 8 月 18 日發布時，固定 GPT-5.6 Luna medium、同一套 Stirrup Agent、共同 web_fetch、最多 25 turns，並把 DeepSearchQA 900 題、BrowseComp hard subset 200 題、私有 Omniscience 600 題的三項指標等權合成指數。它比較的是特定 provider surface：Parallel advanced、Exa auto＋highlights、Firecrawl search-only（scrape_format=none）與 Tavily basic；這比把四家自家 benchmark 拼在一起公平，但不是四套相同搜尋模式。

但它仍不能替你的正式環境下結論。第一，繁中冷門資料不是三套題庫的專門主體。第二，方法把不同供應商回傳內容正規化後交給共同抓取器，刻意測「搜尋表面」，不等於各家原生 search＋extract 組合。第三，fatal 429、5xx 與 timeout 會重試到成功，所以榜上時間與分數不是 production reliability SLA。第四，launch snapshot 的模式並不相同；Parallel advanced 對 Tavily basic，本來就不是最低成本設定的對打。

因此，下圖與指數只負責一件事：證明供應商與模式值得進入你的候選清單。AlphaLab 本篇沒有呼叫四家付費端點，這些數字不是本站重跑；實際錄取要靠接下來的私有 10 題。

10 題怎麼出：別讓題庫只會考英文熱門新聞

小型 Eval 的目標不是做論文，而是用最少成本找出「哪一類題最容易翻車」。每題先寫答案檢查表、允許來源、資料截止時間與應該拒答的條件，再讓四家看到完全相同的任務。

1. 最新新聞：指定 24 小時內事件，要求發布時間與兩個獨立來源。
2. 官方文件：找目前 API 參數、預設值與 canonical reference。
3. 版本變更：用 changelog 判斷某欄位是否已 deprecated。
4. 冷門繁中：找地區性組織、活動或小型站點的一個可核實事實。
5. 繁中同義詞：題目不用英文產品術語，觀察 query expansion 是否仍找對實體。
6. 長 PDF：答案藏在報告內頁，不只出現在摘要。
7. 多步查證：先找實體或型號，再到第二個官方頁核對規格。
8. 衝突來源：舊文件與新 changelog 不一致，答案必須選對時間線。
9. 網域限制：只允許官方 domain，測 filter 是否真的落在預期來源。
10. 應該拒答：故意放入查無可靠證據的問題，測 Agent 會不會硬湊答案。

若正式 workload 有財報、醫療或法規，就用自己的高頻題替換其中幾題；不要增加題數卻降低相關性。完整的 Eval 思維可搭配AI Evals 新手教學，而混合 keyword／semantic retrieval 的差異可參考Hybrid Search 教學。

實作：固定同一條 search→fetch→cite loop

真正公平的 adapter 不該把四家 JSON 硬壓成「只有 URL」。至少保留排名、標題、片段、發布時間、供應商 usage 與原始 response；跨商不可比的自有 score 則只存檔，不直接相減。

for case in frozen_cases:
    for provider in shuffled(providers):
        started = monotonic_time()
        hits = provider.search(case.query, limit=10, native_answer=False)
        pages = common_fetch(top_urls(hits, 5), text_budget=1500)
        answer = same_model(case.prompt, pages, require_citations=True)
        save_jsonl(case, provider, hits, pages, answer,
                   wall_ms=elapsed(started), usage=provider.usage)
        score(case.gold, answer, pages)

這段是語言無關的骨架，不是可直接連四家上線的 SDK 範例。正式程式還要處理 timeout、429、重試上限、URL canonicalization、robots／權限、內容型態與金鑰管理。可先照Agent Harness 實作把 adapter、trace 與 verifier 分開；這樣換供應商時，不必把整個 Agent 重寫。

第一輪：共同抓取器，只測搜尋表面

四家都取 10 個 web results，先關閉供應商的生成答案、summary 與深度研究能力，再選前 5 個唯一 URL 交給同一抓取器，每頁同樣 1,500 字元上下文。這一輪回答：「誰先把好證據送到門口？」

第二輪：原生抓取器，測你真的會部署的組合

只讓第一輪前兩名進入決選，再按正式架構開啟 Tavily Extract、Exa contents、Parallel Extract 或 Firecrawl scrapeOptions。此時可以比較 end-to-end 品質與成本，但名稱要寫成「provider＋mode＋fetch policy」，不能只寫品牌。

五個分數怎麼算，才不會只獎勵會寫作文的 Agent？

1. Citation correctness：把答案拆成可驗證 claim；每個 claim 都檢查「引用頁真的包含這個意思」與「來源身分符合題目」。無引用或引用不支持，該 claim 計 0。
2. Coverage：gold checklist 有幾項被正確回答且有證據。四項命中三項就是 3／4；不是用文章長度代替完整度。
3. Freshness：需要最新資料的題目，檢查事件日、發布日、文件版本與抓取時間。普通常識題不必硬加新鮮度分數。
4. Latency：量從送出 query 到取得最終帶引用答案的 wall-clock。10 題先報中位數、最快、最慢與 timeout 次數；不要拿十個樣本假裝有穩定 p95。
5. 單題成本：搜尋、抓取、內容處理、生成模型與重試都加總。每家 credit 單位不同，最後統一換成「這題實際消耗多少美元」並保留原始 usage。

總分可以有，但硬門檻要先於加權平均。例如 citation correctness 低於 0.9 的 provider 不進 production，即使速度很快；新聞 Agent 可再提高 freshness 權重，內部知識庫則提高 coverage。這種按任務路由的做法，可接著看AI Model Routing Eval，原理完全相通。

一題完整走法：查「目前官方 API 的預設模式」

假設題目是：「截至 2026 年 8 月 19 日，Parallel Search 的預設 mode 是什麼？請引用官方文件。」出題前先存 gold：答案 advanced、允許來源為 docs.parallel.ai、證據必須同時包含 mode 名稱與 default 語意、資料截止時間為當日。

1. 四家用相同 query 與 10-result 上限搜尋。
2. 共同抓取器讀前 5 個唯一 URL，每頁固定文字 budget。
3. 同一模型只能根據抓到的頁面回答，並輸出 claim→citation mapping。
4. 若只找到官方 pricing 卻沒找到 default 語意，答案就算猜對，也只拿到部分 coverage，citation correctness 不通過。
5. 把 query、mode、HTTP 狀態、URL 順序、頁面內容 hash、答案、grader 理由、時間與 usage 寫進一列 JSONL。

這個例子刻意很小，因為它能暴露一個常見錯覺：answer correctness 不等於 evidence correctness。Agent 猜中「advanced」不是成功；它必須把讀者帶到真正支持結論的官方頁。

最後怎麼選：單一供應商、任務路由，還是 fallback？

• 選單一供應商：10 題各類都過引用硬門檻，差距小，而且團隊更在意維運簡單。先從這裡開始通常最省事。
• 選任務路由：某家穩定贏官方文件，另一家穩定贏最新新聞或長頁抓取，而且題型能在搜尋前可靠分類。
• 加 fallback：主 provider timeout、0 results、沒有任何 citation 通過，或新鮮度不合格時，才呼叫備援；不要每題四家全跑，把成本放大四倍。

primary = route_by_task_type(case.type, winners_by_slice)
result = run(primary, case)

if result.timeout or result.valid_citations == 0 or not result.fresh_enough:
    result = run(fallback_for(case.type), case)

return result

把每次 fallback 的原因也存起來。連續四週後，你會得到比任何公開總榜更有價值的資料：自己的失敗分布。若 Agent 還要接企業內部文件，則可延伸到企業 AI 知識庫的權限、更新與引用設計。

七個最容易讓小型 Eval 失真的坑

1. 不同模式卻只寫品牌：Exa auto、Parallel advanced才是可重跑設定；「Exa vs Parallel」資訊不足。
2. 把 search 與 answer 混測：一家開生成答案、另一家只回 snippets，贏的是產品包裝而非同一層能力。
3. 忽略 fetch：只看第一頁 URL，不知道正文是否抓得到；反過來用不同抓取器，又不知道勝負來自 search 還是 fetch。
4. 用供應商自有 score 跨商比較：不同尺度沒有共同校準；看排序與你的 verifier，不要直接相減。
5. 永遠固定執行順序：快取、網路與索引更新可能偏袒後跑者；每題隨機 provider 順序，資源允許再重複三次。
6. 只存平均分：平均 8 分掩蓋「繁中全錯」或「PDF 全 timeout」；一定保留逐題 trace 與 slice 分數。
7. 把 10 題當永久真理：每次供應商版本、價格或正式 workload 改變，就重跑；把 production 失敗樣本加入題庫，但也保留舊題防止回歸。

長期保存 trace 時也別讓內容無限膨脹。可為原始 response 與頁面正文保留 hash／物件儲存位置，在主紀錄只放必要欄位；對上下文縮減後要重新找資料的代價，可參考Context Compaction 驗收。

FAQ：AI Agent 搜尋 API 選型最常見的 8 題

1. 10 題真的夠嗎？

夠初篩，不夠證明長期穩定。它適合淘汰明顯不合需求的設定；production 決策還要持續收集真實 query、錯誤率、p95 與成本。

2. Artificial Analysis 第一名就直接選嗎？

不要直接選。它是特定日期、模型、題庫、mode 與共同抓取器的獨立快照；拿來縮小候選範圍，再用自己的題目驗收。

3. 一定要四家都付費才能開始嗎？

不一定。先依官方介面與第三方研究挑 2～3 家，再用當期可用額度做小樣本。本文沒有把未呼叫的端點寫成本站結果。

4. 可以只比 API latency 嗎？

不夠。Agent 真正等待的是 search、fetch、生成、重試與引用驗證的總時間；單次 search 很快，若後面多抓五頁，整題仍可能更慢。

5. Citation correctness 可以交給另一個 LLM 打分嗎？

可以輔助，不能完全放任。先做可重複的 claim→citation rubric，抽查判分爭議；最重要的 10 題由人建立 gold，避免 grader 和 answer model 一起犯同一種錯。

6. 為什麼要安排一題「查不到」？

為了測拒答。搜尋結果永遠有東西不代表有可靠證據；能在證據不足時停止，比湊出一篇漂亮答案更適合 production。

7. Provider score 能直接正規化成 0～1 再比較嗎？

不能只靠算術。各家 score 定義與回傳方式不同；跨商比較應用共同 verifier 評 relevance、證據與結果排序。

8. 最後一定需要 router 嗎？

不一定。若單一 provider 已過所有硬門檻，簡單架構通常更可靠；只有 slice 差距穩定、路由規則清楚，才值得增加第二家與 fallback。

給新手的 5 個重點

1. 先固定問題、模型、提示詞、結果數、抓取字數與重試，再談供應商差異。
2. 先用共同 fetch 比搜尋表面，再用原生 fetch 比正式部署組合。
3. citation correctness 是硬門檻；coverage、freshness、latency、cost 才是後續取捨。
4. 10 題報逐題結果、中位數與範圍，不把小樣本包裝成穩定 SLA。
5. 公開榜只負責提名；你的失敗樣本與回歸紀錄，才負責錄取與路由。