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

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

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

先搞清楚：這四個根本不是同一種東西

把它們擺在一起比，第一個陷阱是以為它們在搶同一個位子。其實它們站在四條不同的路線上，先分清楚再談取捨：

格式轉換（Jina Reader）：把一個 URL 變成乾淨 markdown，僅此而已。
託管平台（Firecrawl）：雲端 SaaS，幫你把爬取、反爬、proxy 這些髒活全包了。
自架引擎（Crawl4AI）：開源、跑在你自己機器上的完整爬蟲框架。
語義抽取（ScrapeGraphAI）：用 LLM 讀懂頁面，你用一句話描述要什麼，它回結構化資料。

搞混它們，你會拿牛刀殺雞、或拿水果刀砍樹。下面一個個拆。

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

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

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

沒有 SDK、沒有 API key（要不要登入看用量）、沒有設定檔。它把網頁正文抓出來、轉成 markdown 丟回給你。我的夜班流程裡，「撈某篇文章全文餵給模型摘要」這種需求，九成都是它在扛。

它的代價也很誠實：只做單頁、不做整站爬取、不做結構化抽取、遇到狠一點的反爬就投降。但你回頭想想——「把這頁內容餵給 LLM」這個最常見的需求，根本不需要前面那些。為了用不到的功能去扛一套複雜系統，是工程師很容易犯的浪費。

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

Firecrawl 是這裡面聲量最大的（GitHub 上 12 萬多顆星），定位是 API 優先的雲端平台。它的賣點是「髒活我全包」：JS 渲染、反爬、proxy 輪換、整站爬取、甚至用 schema 幫你抽結構化欄位，你只管打 API。

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

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

第一，它的反爬能力鎖在雲端。Firecrawl 可以自架（AGPL-3.0），但自架版拿不到它那套叫 Fire-engine 的反爬引擎。也就是說，你想「自己架、又要打硬反爬目標」，這條路是斷的——最值錢的能力被留在付費雲端。

第二，它的計價是包月 credit、沒有按量付費。1 credit 大約抓一頁，免費方案每月 1000 credit，再上去 $16、$83 一路漲；而且標準的月配額用不完不會滾存到下個月（自動加值購買的 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 近期在密集修安全漏洞——就在我研究它的這幾天，它還在補一個 SSRF，再往前翻還有 sandbox 逃逸 RCE、寫死的 JWT secret 這些。它本身很活躍是好事，但如果你把它的 Docker API server 開出去自架，務必鎖好存取、跟緊版本。自架省的是錢，扛的是維運責任，這筆帳要算清楚。

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，已是結構化資料

這帶來一個傳統爬蟲沒有的優點：對網站改版有韌性。規則式爬蟲綁死在 DOM 結構上，對方一改版你的 selector 就全壞；ScrapeGraphAI 靠 LLM 理解語義，版面動了通常還抓得到。它還能用 Pydantic 或 Zod 的 schema 約束輸出欄位，且支援接 Ollama 本地模型，把 token 成本壓到零。

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

攤開來比

工具	路線	授權	反爬	計價	殺手鐧
Jina Reader	URL→MD 輕量	—	弱	免費 / 按 token	零設定、秒級、最快
Firecrawl	雲端託管	AGPL-3.0	強（鎖雲端）	credit 包月不滾存	省事、一站式、整站爬
Crawl4AI	開源自架	Apache 2.0	自架 stealth	軟體免費、付運算	省錢、資料主權
ScrapeGraphAI	LLM 語義抽取	MIT	雲端為主	credit / 自付 token	不綁 DOM、改版不壞

那到底怎麼選

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

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

不要，只是要把網頁內容餵給 LLM —— Jina Reader 轉 markdown 就夠了，別想太多。整站量大、需要託管省事，才升級到 Firecrawl。
要，而且規則明確（版型固定的商品頁、表格）—— Crawl4AI 的規則式抽取，又快又便宜又零 token。
要，但版面雜亂多變 —— 這時候才輪到 ScrapeGraphAI 的 LLM 抽取出場，把它貴的推論用在真正需要「理解」的刀口上。

反爬硬目標是另一條獨立的軸：要省事就用 Firecrawl 雲端，要自架可控就用 Crawl4AI；遇到強瀏覽器指紋偵測或 Cloudflare Turnstile，再往下疊反偵測那層——runtime 級的 Scrapling，或直接重編譯 Chromium、把指紋編進 binary 的 CloakBrowser。反偵測跟抓取工具不同層，可以疊著用：底層拿反偵測瀏覽器進門，上層再接你選的抓取工具。

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