我把 Crawl4AI 套用在五種頁面上測試——優勢在哪裡、弱點又在哪裡

有些第三方爬蟲比較文章把「Adaptive Intelligence」——也就是能學習網站、在版面改版後自我修復的選擇器——歸功於 Crawl4AI。但我在實際測試的 API 範圍內，並沒有看到這種行為。Crawl4AI 真正提供的是：基於瀏覽器的 Markdown 生成，以及 CSS/XPath 擷取。 Scrapling 則在其自己的評論中有記載限制下，提供了另一套自適應選擇器功能。

我用 Crawl4AI 0.9.0 跑了五種已知正確答案的頁面類型：靜態商品目錄、JavaScript 渲染的商品目錄、夾在大量版型內容中的文章、刻意製造的 500 錯誤，以及有連結的多頁圖譜。測試中的 Markdown 與 schema 擷取路徑都回傳了預期的 fixture 內容。原始 Markdown 會保留版面雜訊，深度爬取需要針對頁面設定等待條件，而一般的 500 錯誤則被貼上了帶有反爬意味的錯誤標籤。

Crawl4AI 到底是什麼

先從大多數人在安裝時最容易搞錯的地方說起。Crawl4AI 不是一個小型 Python 解析器。第一次執行 crawl4ai-setup 時，它會悄悄下載兩套完整瀏覽器環境——Playwright 和 Patchright——一旦理解這一點，整個工具的定位就很清楚了：它本質上是一個可控的無頭瀏覽器，上面再疊了一層 Markdown 轉換器，披著爬蟲的外衣。

官方定位上，它是一個開源、Apache-2.0 授權的函式庫，用來把網頁轉成 Markdown，供 RAG 流程、代理程式與資料工作流使用。我測試的是 v0.9.0。依照 官方快速開始 的說明，它的核心原語包括 AsyncWebCrawler、BrowserConfig、CrawlerRunConfig、Markdown 生成，以及基於 CSS/XPath 或 LLM 的擷取策略。

真正重要的心智模型是這樣：多數解析函式庫是發出 HTTP 請求後處理回傳的位元組；Crawl4AI 則是直接驅動真實瀏覽器。瀏覽器渲染是內建功能，因此安裝成本比純 HTTP 解析器高得多，而要穩定擷取非同步渲染出的元素，往往還得明確設定等待條件。我在這裡測試到的內容，沒有任何一項會在版面改版後自動重寫選擇器。除非有明確的官方來源與可重現的 API，否則應把「自我修復」的說法視為第三方比較文章的誤植。

核心功能，以及背後怎麼運作

單頁流程是它的核心。你把 AsyncWebCrawler 指向一個 URL，它會在瀏覽器中載入頁面，然後回傳 Markdown。官方 example.com 的快速開始流程中，這個往返耗時 1.81 秒，並回傳乾淨的 200 狀態。沒有什麼花俏技巧，但它證明了最基本的流程在幾乎零設定下就能運作——不需要 schema、不需要等待、不需要額外的瀏覽器設定。

影片教學（1:02:38）：Crawl4AI 官方教學，含快速開始範例的完整 1 小時版本。

結構化擷取是第二根支柱，也是 Crawl4AI 最接近「理解」頁面的地方——更精確地說，不是推理，只是你自己寫好的 schema。它不只是把 Markdown 倒出來，而是透過 JsonCssExtractionStrategy 提供 CSS schema，然後回傳你指定欄位的 JSON 物件。在我本機的靜態商品目錄上，它回傳了 6 筆乾淨的 JSON 記錄——商品名稱、分類、價格、評分、詳情頁 URL——與預期的 6 個商品完全一致。這就是「這是一段文字形式的頁面」與「這是一列列資料」之間的差別，而 Crawl4AI 兩者都能從同一次爬取完成。不過，選擇器仍要由你自己定義；工具只會照你給的規則抓，不會替你推斷 schema。

動態渲染則是瀏覽器支援真正發揮價值的地方。把它指向一個 JavaScript 渲染的商品目錄，並設上 wait_for="css:.product-card"，它就會等到前端渲染完成後再開始擷取。我的本地 JS fixture 在 Markdown 與 schema 輸出中都達到了 8/8 商品召回，耗時約 1.56 秒。至於公開的 Quotes to Scrape JS 頁面，它成功抓到了渲染後的引言，還儲存了可用的截圖——這類內容單純的 HTTP 請求根本看不到，因為初始 HTML 裡面沒有可解析的內容。

再來是規模與爬行能力。arun_many() 以並行方式跑了六個本地詳情頁，完整達成 6/6 召回，耗時 3.76 秒。Crawl4AI 也提供深度爬取策略——BFS、DFS、BestFirst——可沿著連結圖譜進行探索，並設定深度上限、頁面數量上限、過濾條件與評分規則。一次 BFS 深度爬取走訪了我 fixture 首頁的連結圖譜，抓回五個頁面。這也是宣傳說法與實際效果開始出現落差的地方，下面我會再說明。

安裝：沒人會寫在 README 開頭的那段

我這台機器上的安裝體驗，一方面比預期順利，另一方面也比預期更重。pip install -U crawl4ai 與 smoke test 在 macOS arm64、Python 3.14.2 上都成功了。PyPI 的 >=3.10 條件本來就包含 3.14；這個結果只能證明我測試的安裝與流程可行，不能推廣成更廣泛的相容性保證。

真正有阻力的是 setup 步驟。crawl4ai-setup 會為 Playwright 和 Patchright 兩套環境下載瀏覽器資產——包括 Chrome for Testing、FFmpeg、Headless Shell。如果你用的是硬碟空間很緊或流量計費的筆電，這就是實打實的成本，而且官方文件只是順帶提到，並沒有放在最前面。接著 crawl4ai-doctor 通過，並在 14.65 秒 內爬完 crawl4ai.com，這是個不錯的端到端 smoke test，但不能拿來當任何性能基準——我不會從這個數字延伸出速度結論。

如果要自己評估，安裝部分的重點是：不只要預留 pip 安裝時間，也要預留瀏覽器下載成本。這更像是在架起一個無頭瀏覽器環境，而不是把某個函式庫丟進腳本裡。你在抓第一個真實頁面之前，磁碟裡就已經落地兩套瀏覽器堆疊，而這筆一次性的成本，無論你之後用不用得到 Patchright 的隱匿層都要先付出。

實測：哪些地方穩、哪些地方要注意

有四個結果值得仔細記下來，因為它們正是行銷頁通常會簡化掉、甚至在某些情況下誤標的細節。

兩個公開示範頁面也順利跑完了正常路徑。 在 Books to Scrape 首頁，Crawl4AI 在 2.43 秒內產生了 13,476 個字元 的 Markdown。公開的 Quotes JS 頁面則在大約 3.1 秒內回傳了 1,666 個已渲染的 Markdown 字元。這些結果都不能用來證明規模、惡意網站、長時間穩定性、session、proxy、重試或記憶體行為。

文章型 fixture 揭露了 Markdown 品質的一個提醒。 Crawl4AI 抓到了標題與全部 3/3 段落——這很好。但原始 Markdown 也保留了導覽文字、相關連結、訂閱提示與頁尾內容。這不是 bug；如果沒有內容過濾器或目標選擇器，「把這個頁面轉成 Markdown」字面上就是整個頁面都轉出來。重點在於，要把「原始 Markdown 轉換」與「乾淨的文章擷取」區分開來。如果你要的是後者，就會用像 PruningContentFilter 這樣的內容過濾器，或設定目標選擇器——但我還沒有對這部分做壓力測試，所以不會替它下「乾淨度」結論。

那個壞掉的頁面，反而最能說明問題。 我故意回傳了一個只有極小內文的 HTTP 500。Crawl4AI 回傳了 success=false 與 500 狀態，這是對的；但錯誤訊息卻把它描述成 「Blocked by anti-bot protection: Structural: minimal_text on small page」。實際上根本沒有反爬牆，只有一個很小的錯誤頁。Crawl4AI 的結構性 heuristic 看到可見文字很少，就直接套用了反爬解釋。對任何建立在其上的人來說，這很重要：不要直接相信「anti-bot」標籤。先檢查狀態碼與實際回應，再判斷是不是網站真的在擋你。原始結果放在 benchmark repo 的 results/local_failure_500.json。

深度爬取需要刻意設定。 直接對動態頁做爬取並加入 wait_for 後，結果乾淨；但 BFS 深度爬取找到動態商品目錄時卻回傳失敗。這與在渲染完成前讀取頁面的 minimal-text 分類一致，而深度爬取沒有套用直接爬取時的等待條件。在五個頁面中，有三個成功、兩個失敗。由於這裡沒有展示加入等待條件後的重跑，因此這個判斷仍然只是推論，還不是已被證實的因果。

數字最後落在哪裡

這些都是 smoke test 的耗時，不是性能基準：文章沒有說明硬體、重複次數、冷/熱啟動、快取狀態、並行控制或變異範圍。它們只能說明列出的流程在這台機器上確實完成了。完整的執行成果放在 benchmark repo 目錄 裡。

如果要做可用於決策的性能測試，應該在全新的瀏覽器 session 與重複使用的 session 中各跑一遍每個流程，回報分佈而不是只報單一小數點，鎖定瀏覽器版本，並記錄 CPU、記憶體、快取狀態與並行度。這樣才能把函式庫開銷、瀏覽器啟動成本與網路波動分開來看。

優點與缺點

優點：

• 一個函式庫同時支援原始 Markdown 與 CSS schema 結構化 JSON，不需要把兩個工具硬接在一起。
• 內建瀏覽器渲染；對非同步渲染的目標可搭配明確的 wait_for。
• 本次測試中的單頁流程都在上面列出的時間內完成，沒有額外宣稱相對速度優勢。
• Apache-2.0 授權，對商業使用友善，沒有 copyleft 顧慮。
• 專案活躍、近期有更新，社群規模也不小。

缺點：

• 首次安裝很重，兩套瀏覽器環境的成本在導言裡講得太輕。
• 原始 Markdown 會帶入版面雜訊，除非你另外設定內容過濾器。
• 深度爬取不會自動等待動態頁面，你得逐次配置，否則就會失敗。
• 失敗訊息有時會把單純錯誤誤判成「anti-bot」，日誌看起來很混亂。
• 沒有自適應選擇器；雖然某些比較文案這麼暗示，但實際上 schema 是手動撰寫且靜態的。
• 你需要自己運行與維護瀏覽器環境，包括更新與相容性破壞。

適合誰，不適合誰

如果你是正在打造 RAG 或 agent 流程的開發者，能接受無頭瀏覽器環境，並且希望同一次爬取同時拿到 Markdown 與結構化 JSON，那 Crawl4AI 值得評估。這次測試沒有涵蓋惡意網站抗性、長時間穩定性、記憶體、session、重試、proxy 或正式部署，所以這裡的建議只限於本次實測到的工作流。

如果你想要的是一個極小、低依賴的 HTTP 解析器，那就不適合；如果你無法負擔瀏覽器下載所需的磁碟與頻寬，也不適合；如果你不想在正式環境裡自己承擔瀏覽器堆疊的維護責任，也建議跳過。尤其是如果你是衝著自我修復選擇器來的，那更不用考慮——這不是它的能力，把工作流建立在它沒有的功能上，之後只會踩雷。若你的目標只是擷取乾淨的文章文字、並且去除版面雜訊，那麼一個更輕量、專門做這件事的工具可能更適合你。

替代方案，以及 Thunderbit 在哪裡

最誠實的說法是：Crawl4AI 是一個免費、開源、由你自行主機與維護的函式庫。你拿到的是完全控制權與沒有供應商使用費，但也要自己承擔運算、頻寬、儲存、瀏覽器更新、schema 與營運工作。

另一頭則是像 Thunderbit 這類受管理的爬取服務，擷取與抓取都包在 API 後面。Thunderbit 並沒有拿這些 fixture 跑過，所以本文不會對渲染、反爬處理、CAPTCHA、準確度或速度做對應比較。真正相關的比較是營運責任：你是自己架設瀏覽器驅動的函式庫，還是付費讓服務商代管那一層。

差別就在誰來跑瀏覽器。使用 Crawl4AI，你要自己負責渲染、等待條件、schema 與維護。使用受管理 API，則是按次付費，並把一部分營運責任轉交給供應商。本次實驗沒有在結果層面比較這兩條路。

相關 benchmark 評測：完整開源爬蟲比較、Firecrawl 自架評測，以及 trafilatura 文章擷取評測。

試用 Thunderbit 進行網頁資料擷取

結論

如果你想要的是開源、基於瀏覽器的擷取工具，能輸出 Markdown 與 schema 形式的 JSON，而且你也準備好自己承擔瀏覽器環境，Crawl4AI 算是合理的候選。這次測試中的直接靜態流程與加入等待的動態流程都成功了。Apache-2.0 授權也相當寬鬆，不過一般的相依性與散佈審查仍然不能少。

記得預留瀏覽器資產的成本。原始 Markdown 在變成乾淨文章前需要過濾。深度爬取的等待條件要手動設計，而日誌裡寫著「anti-bot」時，應先對照狀態碼與回應內容。schema 選擇器仍然得由你自己撰寫與維護。這些就是本次測試得出的決策邊界；至於正式規模與惡意網站行為，仍有待進一步驗證。

試用 Thunderbit 進行網頁資料擷取 Get Started Free

常見問題

Crawl4AI 有自適應或自我修復選擇器嗎？ 沒有。雖然有些比較文章把它說成具備「adaptive intelligence」，但 Crawl4AI 其實只會對你寫好的 CSS/XPath schema 進行匹配——它不會去辨識元素指紋，也不會在版面改變後自動重新定位。測試中，結構化擷取使用我手動定義的 schema，成功達到 6/6 與 8/8 的召回。若網站的 class 名稱改了，你的 schema 也會跟著壞掉，直到你更新它為止。自我修復式元素追蹤是別的函式庫的能力，不是這個工具。

為什麼安裝體積這麼大？ crawl4ai-setup 會為 Playwright 和 Patchright 下載完整瀏覽器資產——Chrome for Testing、FFmpeg 與 Headless Shell。這就是把真實瀏覽器渲染一起交付所需的成本。你必須為磁碟與頻寬預留空間；它比純 HTTP 解析器重得多，而且即使你的工作根本沒用到隱匿堆疊，這筆成本也一樣要付。

Crawl4AI 支援 JavaScript 渲染頁面嗎？ 可以，因為它驅動的是實際的無頭瀏覽器。測試中，加入 wait_for="css:.product-card" 的動態商品目錄拿到了完整 8/8 商品召回，公開的 Quotes JS 頁面也能正常渲染。要注意的是，深度爬取不會自動把這個等待條件套用到新發現的頁面上——我用 BFS 爬到的一個動態頁面就因為沒等到渲染而失敗。等待條件得由你在每次爬取時自行設定。

Crawl4AI 會給我乾淨的文章文字，還是整頁內容？ 預設是整頁。在測試中，它抓到了全部正文段落，但同時也保留了導覽、相關連結與頁尾內容。如果你要的是乾淨文章擷取，應該使用內容過濾器（例如 PruningContentFilter）或目標選擇器，而不是只靠原始 Markdown。

我能信任 Crawl4AI 的錯誤訊息嗎？ 要保留一點懷疑。那個故意製造、內文很少的 500 錯誤頁面，只因為可見文字太少，就被標成「Blocked by anti-bot protection」——實際上並沒有反爬牆。這個 原始結果 放在 benchmark repo 裡。每次都先檢查真正的 HTTP 狀態碼與回應內容，再判斷網站是不是在擋你。