AI agent 用什麼抓網頁？四個主流爬蟲工具，多數時候你只需要最便宜那個

上一篇我寫了件讓人有點不安的事：在 Cloudflare 的觀測範圍裡，對網頁的請求已經有超過半數來自機器、不是人。那篇談的是需求側——誰在抓。這篇換個角度，談供給側：這些機器，到底拿什麼在抓？

問題是我自己的。我有一套夜班工作流，每天清晨讓 Claude Code 自動撈財經新聞、AI 文章、社群討論，整理成一份報告。撐起它抓取層的，目前主要是兩樣東西：Jina Reader 把網頁轉成乾淨 markdown，Agent-Reach 串各家平台。用了一陣子，我開始想——市面上那些更炫的 AI 爬蟲，Firecrawl、Crawl4AI、ScrapeGraphAI，要不要換、或該加進來？於是花了點時間把四個主流工具攤開比。結論有點反直覺：多數時候，你需要的是最便宜、最笨的那個。

先搞清楚：功能重疊，但預設路線不同

把它們擺在一起比，第一個陷阱是硬切成四個互不重疊的類別。這幾套工具都在增加功能：Jina Reader 已能按 schema 抽 JSON，Crawl4AI 也有 LLM extraction，Firecrawl 同時能 scrape、crawl 和 extract。比較時應該看各自最順手的預設路線：

單頁轉換優先（Jina Reader）：最短路徑是把一個 URL 變成乾淨 markdown，也可選擇結構化抽取。
託管平台（Firecrawl）：雲端 SaaS，幫你把爬取、反爬、proxy 這些髒活全包了。
自架引擎（Crawl4AI）：開源、跑在你自己機器上的完整爬蟲框架。
LLM pipeline 優先（ScrapeGraphAI）：用自然語言與 graph pipeline 組合抓取、理解和結構化輸出。

它們不是「能不能做」的差別，而是要花多少設定、運算、代管費與維運時間。下面一個個拆。

Jina Reader：最笨，但你八成只需要它

Jina Reader 的用法笨到一句話講完：在任何網址前面加上 r.jina.ai/。

1 2	# 把一篇文章變成乾淨 markdown，沒了 curl https://r.jina.ai/https://example.com/some-article

基本用法不需要 API key 或設定檔；要提高 rate limit 才需要 key，並依 token 用量計費。它把網頁正文抓出來、轉成 markdown 丟回給你。我的夜班流程裡，「撈某篇文章全文餵給模型摘要」這種需求，九成都是它在扛。

它的核心仍是「給 URL、拿內容」，不是完整的整站排程與資料管線。ReaderLM-v2 已支援 x-json-schema、x-instruction 做結構化抽取，所以「Jina 完全不能抽欄位」已經過時；但遇到網站擋 bot 時，付費 key 只會提高流量與效能，不會替你繞過存取控制。我的需求若只是把一頁餵給 LLM，仍不需要先扛一套爬蟲平台。

Firecrawl：要省事、要整站爬，給錢買託管

Firecrawl 定位是 API 優先的託管平台。它的賣點是把 JS 渲染、proxy、整站爬取與結構化抽取包成服務，你只管打 API。GitHub 星數每天都會變，拿它當能力證據沒有意義，這裡不列。

它的能力清單確實齊：scrape 抓單頁、crawl 爬整站、map 快速列出全站 URL、extract 按 schema 抽資料，還有官方 MCP server 能直接接 Claude、Cursor。要做「給一個網域、把整站內容灌進 RAG」這種事，它幾乎是開箱即用。

但有兩個地方我研究時才注意到，這裡幫你踩在前面：

第一，自架不等於完整複製託管服務。Firecrawl 核心可以自架（AGPL-3.0），但官方託管環境的瀏覽器基礎設施與進階抓取能力不保證全部出現在自架版。決定自架前要逐項對照官方 self-host 文件，不能只看到同一個 repo 就假設功能與成功率完全相同。

第二，credit 不能簡單等同頁數。不同端點、格式與進階功能可能有不同消耗，方案和價格也會改。評估時拿自己的 URL 數、更新頻率與端點跑一輪估算，再看 Firecrawl pricing；不要把某天的月費與「1 頁 = 1 credit」寫死進長期架構決策。

Crawl4AI：要省錢、要資料主權，自己架

如果 Firecrawl 是「給錢買省事」，Crawl4AI 就是反過來——「花力氣換省錢和掌控」。它是 Apache 2.0 的開源框架，核心完全免費，設計上就是要你自架。你付的只有自己的運算和 proxy 成本，資料不經過任何第三方。

能力上它不輸託管方案：底層用 Playwright 做完整 JS 渲染、支援深度爬取（BFS／DFS／Best-First 幾種策略）、有 stealth mode 和 proxy 輪換。抽取這塊它給了兩條路，這個區分很關鍵：

# 路線一：規則式抽取（CSS selector + schema）
# 不呼叫 LLM，快、零 token 成本，適合版型固定的頁面
schema = {
    "name": "文章列表",
    "baseSelector": "article.post",
    "fields": [
        {"name": "title", "selector": "h2", "type": "text"},
        {"name": "link", "selector": "a", "type": "attribute", "attribute": "href"},
    ],
}
strategy = JsonCssExtractionStrategy(schema)  # 把 schema 餵給規則式抽取策略

# 路線二：LLM 抽取策略（LLMExtractionStrategy）
# 版型不固定、需要「讀懂」才能抽時才用，代價是 token 成本與速度

它還有個好用的輸出叫 Fit Markdown，會用啟發式規則把導航、側欄那些雜訊砍掉，只留正文。官方也有 MCP server 跟 Docker image，要接進現有 agent 工具不費事。

有一點我得提醒，因為它直接關係到自架安全：不要把 Crawl4AI 的 Docker API server 直接暴露到網際網路。爬蟲本來就會接收 URL、執行瀏覽器與處理不可信內容，SSRF、檔案存取與容器邊界都要自己防。鎖來源、加驗證、限制出站網段，並在升級前查看專案的 security advisories。自架省的是服務費，維運責任會留在自己手上。

ScrapeGraphAI：最聰明，但聰明要付錢

前面三個主要都在做「把內容乾淨地抓回來」。ScrapeGraphAI 更強調抓回來之後，怎麼變成業務需要的結構。

它的路線是 LLM + graph pipeline。你不寫 CSS selector、不寫 XPath，而是用一句自然語言描述要什麼：

from scrapegraphai.graphs import SmartScraperGraph

graph = SmartScraperGraph(
    prompt="抽出這頁所有商品的名稱、價格和庫存狀態",
    source="https://example.com/products",
    config={"llm": {"model": "ollama/llama3"}},  # 可接本地模型省 token
)
result = graph.run()  # 回傳 Python dict，已是結構化資料

它相對不依賴固定 selector，網站小幅改版時有機會繼續抽到資料；這是容錯空間，不是「改版不壞」保證。欄位名稱、語意或頁面內容一變，LLM 一樣會漏抓或誤判。它能用 Pydantic 或 Zod schema 約束輸出，也能接 Ollama 本地模型；本地模型省掉第三方 token 帳單，仍有 GPU／CPU、延遲與維運成本。

代價也很實在，而且是三筆一起來：每抽一頁就要做 LLM 推論，所以比純格式轉換慢、貴；而且 LLM 抽取偶爾會飄移甚至幻覺，確定性不如固定 selector。它最不適合的場景，恰恰是「大規模、版型固定、追求每頁極低成本」——那種情況用 Crawl4AI 的規則式抽取又快又便宜又可預測，犯不著請一個 LLM 來慢慢讀。

攤開來比

工具	路線	授權	反爬	計價	殺手鐧
Jina Reader	單頁轉換優先	服務／部分開源元件	不主動繞過存取控制	基本額度／token	最短的 URL→內容路徑
Firecrawl	雲端託管優先	AGPL-3.0 核心	依方案與部署	credit，規則依官網	整站工作流與代管
Crawl4AI	開源自架優先	Apache 2.0	自行配置 proxy／browser	軟體免費、付運算與維運	控制權與資料留在自己環境
ScrapeGraphAI	LLM pipeline 優先	MIT 核心	不是主要賣點	模型／雲端服務成本	自然語言驅動抽取流程

那到底怎麼選

我把選型收斂成一個問題開頭，比記四個工具的功能表好用得多：

先問：你要不要結構化抽取？

不要，只是要把單頁內容餵給 LLM —— 先用 Jina Reader。要整站排程、重試與代管，再評估 Firecrawl。
要，而且規則明確（版型固定的商品頁、表格）—— Crawl4AI 的規則式抽取，又快又便宜又零 token。
要，但版面雜亂多變 —— Jina、Firecrawl、Crawl4AI、ScrapeGraphAI 都有不同程度的 LLM 抽取能力。用 20～50 個真實頁面做欄位正確率與成本測試，再選工具，不要只看 demo。

網站拒絕自動抓取時，先確認 robots.txt、服務條款、授權與 API 選項。付費方案不等於取得繞過存取控制的權利，技術上抓得到也不代表應該抓。這條是選型條件，不是抓取成功率之外的附註。

照成本由低到高排，務實的組合大概是：原型和單頁即查用 Jina，產線大量轉內容用 Firecrawl 或 Crawl4AI，只在複雜頁面要特定欄位時才動用 ScrapeGraphAI。

我自己的結論

回到我夜班工作流那個原始問題——要不要換、要不要加？

答案是：暫時不動。我的需求九成是「把這頁餵給模型摘要」，Jina Reader 的基本額度與速度目前夠用，硬要換成 Firecrawl 反而多一層成本和依賴。等哪天真要做「整站爬下來建索引」或「從一堆雜亂頁面抽特定欄位」，我會先拿真實樣本比正確率，再決定加 Crawl4AI、Firecrawl 或 ScrapeGraphAI；工具功能一直變，現在不能先把答案寫死。

研究這四個工具最大的收穫，反而不是記功能表。功能會追上彼此，部署方式和責任不會：資料交給誰、失敗誰維修、每月有多少量，才是長期差別。我的預設仍是從最短路徑開始，直到真實樣本證明它不夠用再升級。