Newscatcher CatchAll API：我實測了專為 AI Agent 打造的召回優先網頁搜尋

Newscatcher CatchAll API：我實測了專為 AI Agent 打造的召回優先網頁搜尋

我向 Newscatcher CatchAll API 提出了一個頑固的問題：找出本季歐洲發生的每一場倉庫火災。不是前十名，而是每一場。一般的搜尋 API 只會給你一頁按排名排序的連結，並悄悄捨棄長尾結果；這對於「附近最好的披薩」這類查詢沒問題，但對於需要完整列舉的任務來說則毫無用處。大約 15 分鐘後，在 Base 模式下，CatchAll 回傳了區域媒體和行業出版物中的事件，這些是我們在 best-ai-search-apis-2026 測試中基於排名的 API 從未發現的。每個結果都以一個結構化的 JSON 物件形式呈現，而非單純的連結。這種差異就是整個故事的核心。

在深入技術細節之前，先來看重點摘要。

重點摘要

• CatchAll 是一個**召回優先（recall-first）**的網頁搜尋 API：它回傳結構化的事件記錄，而非按排名排序的搜尋引擎結果頁面（SERP）。
• Newscatcher 報告在 32 個查詢中達到 79.8% 的召回率和 0.705 的 F1 分數；首頁則將此數據四捨五入為 86%。
• 兩種模式：Lite（數秒內完成，約 100 個結果上限）和 Base（非同步，約 15 分鐘，無上限）。
• 最適合列舉任務（合規性檢查、競爭情報、供應鏈監控）；它不是 SERP 排名追蹤工具。

召回優先搜尋優化的是找到所有內容，而排名優先搜尋優化的是對其呈現的少量內容進行排序。記住這句話，本篇評測的其餘部分就會變得清晰易懂。

什麼是 CatchAll？（解釋召回優先網頁搜尋）

CatchAll 是 Newscatcher 推出的一款召回優先網頁搜尋 API：它不回傳前 ~10 個連結的排名列表，而是回傳一組去重複後的結構化事件記錄，每個記錄都是一個包含引用來源和提取實體的單一 JSON 物件。所謂召回優先，意味著目標是完整性——找到每一個相關事件，而不是對短列表按相關性進行排序。

Newscatcher 用一個直觀的例子來說明：如果存在 200 個有效事件，而你的系統只呈現了 5 個，那麼你的召回率僅為 2.5%。對於「哪款筆記型電腦最好」這類問題，這沒問題。但對於「今年歐盟金融科技領域的所有監管行動」這類問題，2.5% 的答案比沒有更糟糕，因為你無法知道自己遺漏了什麼。

這就是 CatchAll 旨在填補的類別差距，即使你不註冊使用，了解這一點也很有價值。其在 YC 的發布宣傳稱其為「召回優先網頁搜尋 API」，你可以直接從 Newscatcher 的 CatchAll 網頁搜尋 API 產品頁面看到其定位。誠實的說法是：SERP API 回答的是「我應該先讀什麼？」，而 CatchAll 回答的是「完整的清單是什麼？」

CatchAll 如何運作：檢索 + 驗證管線

CatchAll 運行一個五階段管線：查詢規劃將你的提示重寫為多個檢索角度，大規模檢索掃描每個任務超過 50,000 個頁面，Leiden 演算法將相關頁面聚類為單一事件，LLM 根據你的查詢驗證每個聚類，倖存者則以結構化 JSON 形式回傳。召回率來自掃描；精確度來自驗證。

讓我們快速分解這些步驟：

1. 查詢規劃。 你的一個查詢會變成幾個涵蓋不同措辭和事件類型的檢索提示，因此「倉庫火災」也能捕捉到「物流倉庫大火」。
2. 大規模檢索。 Newscatcher 表示，單一任務以每分鐘約 10,000 頁的速度抓取 50,000+ 頁面，且無結果上限，能夠觸及主流 SERP 所埋沒的區域媒體、行業出版物和監管文件。
3. 聚類。 Leiden 演算法將密集連接的頁面分組為社群。簡單來說：關於鹿特丹同一場火災的 30 篇文章會合併為一個事件，而不是 30 行數據。
4. LLM 驗證。 每個聚類都會根據你的查詢進行評分，不相關的會被丟棄。此階段涉及真實的 LLM 呼叫，因此在生產環境的 Agent 堆疊中，你會希望透過 LLM 閘道器 來路由這些呼叫，以控制成本和處理備援。
5. 結構化輸出。 每個經過驗證的事件對應一個 JSON 物件，具有動態架構。

Newscatcher 報告每天索引超過 200 萬個真實世界的事件，新事件在數小時內即可收錄。技術文章《完整性的架構》（The Architecture of Completeness）涵蓋了 Leiden 和驗證的內部細節，如果你想深入了解可以閱讀。

我的倉庫火災測試正是在這裡進行的。我在 Base 模式下運行了列舉查詢，任務耗時約 15 分鐘，價值確實如管線承諾的那樣顯現出來：來自區域和行業來源的內容，被聚類為離散事件，這些內容在排名 SERP 中通常會被埋在頁面下方或完全跳過。

關鍵功能：監控器、觀察名單與事件提取

除了單次搜尋，CatchAll 還提供監控器（Monitors）和觀察名單（Watchlists）。監控器是定期重新運行的任務（最低每小時一次），僅回傳自上次運行以來新的、去重複的事件。觀察名單則按實體過濾，提供 1-10 的相關性評分，並具備實體解析功能，能夠跨語言和司法管轄區匹配同一家公司。

監控器將單次搜尋轉變為常駐監控：每次運行僅回傳自上次以來的新事件。這就是「今天搜尋網路」與「當發生變化時通知我」之間的區別。

關於「即時事件監控 API」這一說法，有一個誠實的注意事項：這裡的「即時」意味著每小時重新運行，而非亞秒級串流。如果你需要毫秒級的推送通知，這不是該工具的強項。對於每天檢查兩次的合規團隊來說，每小時更新已經綽綽有餘。公司觀察名單是競爭情報的亮點功能，因為它能將「Acme GmbH」、「Acme Inc」和「Acme Holdings」解析為一個追蹤實體，而不是三個雜訊實體。

結構化 JSON 輸出（含真實範例）

每個結果都是一個事件對應一個 JSON 物件：包含 cluster_id、title、relevance 評分、entities 陣列和 source_citations 陣列。無需 HTML 爬取，也無需解析連結列表。這使得 CatchAll 成為真正的結構化網頁搜尋 API，而不僅僅是 SERP 的外殼。

以下是我倉庫火災運行中的一個截斷事件範例，經過輕微清理但保持真實結構：

{
  "events": [
    {
      "cluster_id": "evt_8f21a",
      "title": "Fire at logistics warehouse near Rotterdam",
      "relevance": 9,
      "entities": [
        {"name": "Rotterdam", "type": "location"},
        {"name": "Maasvlakte", "type": "facility"}
      ],
      "source_citations": [
        {
          "url": "https://...",
          "publisher": "regional trade press",
          "published_at": "2026-..."
        }
      ]
    }
  ]
}

注意 source_citations 陣列指向一家區域行業媒體，這正是排名 API 會降低優先級的來源類型。由於每個事件已經是結構化的，你可以將經過驗證的記錄直接放入 RAG 管線 或 儲存並嵌入向量資料庫，中間無需任何爬取或清理步驟。這個省去的步驟帶來了靜默的生产力提升。

如何在 Python 中呼叫 CatchAll？（程式碼快速入門）

你獲取一個 API 金鑰，將查詢 POST 到 /v3/search 並带上 x-api-token 標頭，然後解析 events 陣列。這就是整個流程。以下是一個最小的 Python 呼叫範例：

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},
)
events = resp.json()["events"]
for ev in events:
    print(ev["title"], "—", ev["relevance"])

專業提示與常見陷阱合二為一：Lite 模式在數秒內回傳，但限制在大約 100 個結果；而 Base 模式是非同步的，深度任務大約需要 15 分鐘。對於 Base 模式，你需要提交並輪詢，而不是阻塞在單一呼叫上，因此設計你的 Agent 時應採用「發送並檢查」策略，而非等待。如果你將 CatchAll 整合到 Agent 中，通常會 透過函式呼叫將其作為工具呼叫。在發布前，請務必对照 CatchAll 文件 確認準確的請求參數和 Lite 與 Base 模式的標誌；認證標頭為 x-api-token。

CatchAll 費用多少？有免費層級嗎？

定價基於使用量，按每個經過驗證的記錄收費，大約每條記錄 $0.10，零結果意味著零費用。註冊時有約 2,000 點積分的免費層級，加上每月約 10 次搜尋，無需信用卡，因此你可以在承諾付費前運行真實的列舉測試。

這種零結果零收費模式對於列舉工作至關重要：一個確實沒有匹配事件的查詢不會消耗預算。關於 Google 搜尋 API 是否免費的常見問題，原生的 Google 和 Bing 搜尋並非如此。它們回傳排名連結，而非經過驗證的結構化事件，且 Bing 的搜尋 API 正在退役，這也是獨立索引服務受到關注的部分原因。

實際應用案例

CatchAll 適合任何遺漏單一項目即視為失敗的任務。合規性和監管追蹤依賴於監控器及其對監管文件的覆蓋範圍。競爭情報運行於公司觀察名單之上。供應鏈監控則是倉庫火災模式的應用，監控中斷事件。市場研究則利用對行業媒體的列舉。

這四種應用的共同模式是：你正在建立一個完整清單，然後據此採取行動，通常是在自動化的 AI Agent 網頁搜尋 API 工作流程中。以下是一些具體形態：

• 合規性： 對你所在領域的執法行動設立常駐監控器，每小時更新。
• 競爭情報： 對三個競爭對手實體設立觀察名單，並解析其法律名稱。
• 供應鏈： 列舉供應商設施附近的中斷事件（火災、罷工、召回）。
• 市場研究： 對本季利基市場中的每個產品發布進行一次性 Base 模式掃描。

基準測試：CatchAll 真的比 Exa 好 3 倍嗎？

在 Newscatcher 自己於 2026 年 3 月進行的 32 個查詢基準測試中，CatchAll 報告 F1 為 0.705，召回率為 79.8%（4,807 個事件），在與 Exa Websets、Parallel AI FindAll 和 OpenAI Deep Research 的對比中，贏得了 32 個查詢中的 27 個。Newscatcher 將此描述為比競爭對手多出約 3 倍的相關事件。這裡的所有數字均來自供應商自身。

現在來說說誠實的部分。Newscatcher 自己的嚴謹基準測試顯示召回率為 79.8%；首頁則將其四捨五入為 86%。我們將引用較低的數字。79.8% 的數字來自 dated、詳細的 32 查詢產品頁面表格，而 86% 的標題則是首頁和部落格文章中不同切片的較圓整說法。兩者皆出自 Newscatcher。我選擇較低的一個，因為引用供應商自身更保守的內部數字是行銷頁面無法做到的信任舉動。無論如何，方向性的發現在我的測試中得到了證實：召回率確實高於排名優先工具。關於完整領域的情況，請參閱 CatchAll 在我們 最佳 AI 搜尋 API roundup 中與其他 12 個 AI 搜尋 API 的排名，並在 Newscatcher 的產品頁面 自行查看原始表格。

誠實的局限性：CatchAll 不適合什麼

行銷頁面隱藏了 CatchAll 的四個真實局限性，在構建之前你應該權衡這些因素。它不具有低延遲特性，在快速模式下並非無上限，尚未為 Agent 提供插即用支援，也不是排名追蹤工具。這些都不是致命缺點，但每個都排除了一些用例。

• Base 模式是非同步的（每個任務約 15 分鐘）。 對於需要在兩秒內獲得答案的聊天機器人來說，這是錯誤的工具。
• Lite 模式限制在大約 100 個結果。 想要快速的深度召回？你無法兩全其美；深度召回需要支付延遲稅。
• 尚無官方 MCP 伺服器。 你需要自行包裝 REST 端點。如果你想將其作為原生 Agent 工具使用，可以 將 REST 端點包裝為 MCP 伺服器，就像我們構建 我們已經使用的 MCP 伺服器 一樣。
• 它不是 SERP 或排名追蹤工具。 它不會告訴你在 Google 上的排名。這是完全不同的工作。

這部分是任何第一方頁面都不會為你撰寫的內容。如果非同步延遲或缺失的 MCP 伺服器扼殺了你的用例，最好在整合之前就在此處了解到，而不是之後。

CatchAll 替代方案及選擇時機

CatchAll 在列舉的原始召回率方面獲勝，但並非每個搜尋任務都適合它。以下是七個真實的替代方案，每個都帶有誠實的「選擇這個代替」條件。沒有虛假目標。

快速啟發式方法：列舉和監控指向 CatchAll，對話式 RAG 指向 Tavily，語義發現指向 Exa，排名追蹤指向 SerpAPI。

Techsy 如何在 Agent 構建中使用召回優先搜尋

在 Techsy，我們為 B2B 客戶交付 AI Agent，而召回優先搜尋非常適合列舉和監控任務：例如需要完整執法行動清單而非前五名的合規 Agent。在這種情況下，我們會選擇像 CatchAll 這樣的召回優先 API，而當任務是對話式 RAG 或語義查找時，則誠實地選擇 Tavily 或 Exa。選擇錯誤的搜尋原語是我們修復的最常見的 Agent 構建錯誤之一。需要幫助選擇嗎？獲取免費諮詢。

關於作者

Mert Batur Gurbuz 是 Techsy.io 的聯合創始人，該團隊為 B2B 客戶交付 AI Agent、自動化系統以及語音/SDR 管線。他就讀於伯明翰大學，並撰寫有關 Techsy 團隊在生產環境中實際使用的 LLM 工具堆疊的文章。通過 LinkedIn 聯繫。

常見問題

什麼是 Newscatcher CatchAll API？

CatchAll 是 Newscatcher 推出的召回優先網頁搜尋 API。它不回傳排名連結列表，而是回傳結構化事件記錄，每個真實世界的事件對應一個 JSON 物件，每個物件都包含來源引用和提取的實體。它專為 AI Agent、企業研究和監控任務而打造，在這些任務中，找到每個相關事件比對短列表進行排序更重要。

CatchAll 與普通（SERP）搜尋 API 有何不同？

SERP API 對頂部少數連結進行排名並回傳，優化的是「我應該先讀什麼」。CatchAll 優化的是完整性，每個任務掃描 50,000+ 頁面並將它們聚類為去重複的結構化事件。你獲得的是每個事件對應一個包含引用和實體的物件，而不是一個需要你自行爬取和解析的 HTML 結果頁面。

CatchAll 真的比 Exa Websets 好 3 倍嗎？

Newscatcher 在其 own 2026 年 3 月的 32 個查詢測試中報告了這一數據：CatchAll 的召回率為 79.8%，F1 為 0.705，而 Exa Websets 為 19.6%，在 32 個查詢中贏得了 27 個，他們將其描述為多出約 3 倍的相關事件。請注意，首頁從不同的切片將召回率四捨五入為 86%。所有數據均來自供應商自身；請將其視為歸因數據，而非獨立審計數據。

CatchAll 費用多少？有免費層級嗎？

定價基於使用量，按每個經過驗證的記錄收費，大約每條記錄 $0.10，當查詢無結果時不收費。免費層級在註冊時提供約 2,000 點積分，加上每月約 10 次搜尋，無需信用卡。這足以在承諾預算之前，針對你自己的用例運行真實的列舉測試。

CatchAll 有多快？

這取決於模式。Lite 在數秒內回傳，但限制在大約 100 個結果。Base 是非同步的，每個任務大約需要 15 分鐘，無結果上限，適合深度列舉。對於 Base 任務，你需要提交並輪詢，而不是阻塞在單一呼叫上，因此它不適合任何需要亞秒級答案的应用，如即時聊天機器人。

CatchAll 有 MCP 伺服器嗎？

目前還沒有官方的。要在今天將其用作原生 Agent 工具，你需要自行包裝 REST 端點，這與我們的 MCP 指南 中介紹的模式相同。它只是圍繞對 /v3/search 的單一 POST 請求的薄包裝，因此如果你的堆疊已經支持該協議，圍繞它構建一個小型 MCP 伺服器是很直接的。

什麼是監控器和觀察名單？

監控器是定期重新運行的任務，最低每小時一次，僅回傳自上次運行以來新的去重複事件，將單次搜尋轉變為常駐監控。觀察名單按實體過濾結果，提供 1-10 的相關性評分，並解析跨語言和司法管轄區的同一家公司。它們共同覆蓋了合規追蹤和競爭情報，無需每次都重新查詢整個網路。

我可以將 CatchAll 用於 SEO 排名追蹤嗎？

不可以。CatchAll 回傳經過驗證的結構化事件，而非搜尋引擎排名，因此它不會告訴你的頁面在 Google 上的位置。對於排名追蹤、SERP 功能或完全鏡像 Google 顯示的內容，請改用 SerpAPI 或 Serper。儘管兩者都涉及「網頁搜尋」，但 CatchAll 和排名追蹤器解決的是真正不同的問題。

CatchAll 最適合哪些用例？

完整性至關重要的列舉和監控任務：合規性和監管追蹤、競爭情報、供應鏈中斷監控以及針對行業媒體的市場研究。共同點是遺漏單一相關事件即是失敗模式，這正是召回優先搜尋旨在防止的。對於對話式 RAG 或語義查找，排名優先工具更合適。

底線：召回優先不等於排名，而這正是重點所在。CatchAll 以延遲換取完整性，對於列舉任務來說，這是正確的權衡。在決定之前，使用免費層級在你自己最困難的查詢上進行測試，因為你可以 試用 CatchAll 的免費層級 而無需信用卡。如果非同步等待或缺失的 MCP 伺服器是致命缺點，上述表格中的替代方案將更好地服務於你。