痛點：agent 要的 context，往往卡在好幾個整合上
你的 agent 能力夠強，缺的常常只是 context。但要把 context 餵進去，可能得先寫一個 scraper、解析一份 PDF、再接上另一個資料 API，繞了一圈才回到真正想做的產品。Firecrawl 在 2026 年 10 月 8 日發表的 Universal Scrape，就是針對這段前置工：把網頁、檔案和 provider 資料收進你已經在用的 /scrape 端點。
它實際涵蓋了什麼
根據 Firecrawl 的公告，原本的強項——動態網頁渲染、重試、解析 PDF 和圖片——都保留不變，另外新增了 Word 文件、試算表和簡報（透過 URL 提供）。重點擴充在 Alexandria 這邊：
- 人和公司資料：透過 Apollo、FullEnrich、Data Legion 等 provider 取得專業與公司資訊
- 財務資料：透過 Fiscal.ai、Benzinga 等取得公司財務與市場資訊
- Podcast：透過 Particle 搜尋相關節目、查詢單集、取得逐字稿
Alexandria 目前有超過 200 個 provider，Universal Scrape 先支援其中持續增加的一部分。
對 builder 的意義：整合數從 N 變成 1
這類發布真正的價值不在功能列表，而在維護成本。以前每多一種資料來源，就多一組 API key、多一份錯誤處理、多一個要盯著的供應商。Universal Scrape 的做法是全部走同一把 Firecrawl API key，provider 呼叫以 credits 計價（依各工具標示的價格）。用法也一致：網頁和支援的文件直接傳 URL，provider 資料則透過同一個端點呼叫支援的 Alexandria capability，部分支援的 profile URL 甚至會自動路由到已設定的 enrichment provider。
讀一個頁面再搜尋 podcast，同一個 client 就夠：
import { Firecrawl } from "firecrawl";
const firecrawl = new Firecrawl({
apiKey: process.env.FIRECRAWL_API_KEY,
});
const page = await firecrawl.scrape("https://www.firecrawl.dev", {
formats: ["markdown"],
});
const podcasts = await firecrawl.scrape({
alexandria: {
provider: "particle",
capability: "podcasts/episodes/search",
options: {
semantic_search: "AI agents",
limit: 2,
},
},
});注意一個部署細節：跑 podcast 呼叫之前，org 管理員必須先接受 Particle 的 provider 條款。跨 provider 時權限和法務同意是分開管理的，這點要排進上線流程。
從 API 到 agent 工具的幾條路
除了 SDK，Firecrawl 也提供 ChatGPT 和 Codex 的 plugin、Claude 和 Claude Code 的整合、MCP 連接，以及 CLI。也就是說同一份資料能力，可以出現在你的後端程式碼裡，也可以直接掛在現成的 agent 環境上。Firecrawl 自己的說法是：新資料來源應該給 agent 更多素材，而不是多一個要維護的整合。
這個思路其實和先前寫過的方向一致——Firecrawl Alexandria 把 people enrichment 塞進同一把 key，用一個 API 就拿到人名和 work email。Universal Scrape 可以看作同一條路的延伸：從「人」擴到財務、podcast 等更多類別。
值得留意的地方
單一端點換來的是簡化，但也意味著你對個別 provider 的議價和替換彈性綁在 Firecrawl 的選擇上；credits 計價是否划算，要對照你目前直接呼叫 provider 的成本。實際動手前，建議先看 Scrape 文件的 URL 路由規則和 Alexandria 文件的 capability 查找方式，確認你要的資料類型已經在支援清單裡。