Web Scraping 軍備競賽：fastCRW 用 Rust 8MB binary 打贏 Firecrawl

Firecrawl 有 180K GitHub stars、五個 Docker container、一套完整嘅 Node.js + Playwright + PostgreSQL + RabbitMQ + Redis stack。fastCRW 只有一個 8MB 嘅 Rust binary。但喺 Firecrawl 自己公佈嘅 Hugging Face benchmark 數據集上面，fastCRW 嘅 truth-recall 係 63.74%，Firecrawl 係 56.04%。呢個結果唔係 fastCRW 團隊自己測嘅——佢哋用緊 Firecrawl 嘅 scrape-content-dataset-v1，一千條 URL，八百一十九條有 ground truth 標註，用 diagnose_3way.py 跑出嚟嘅數字。呢個唔係細微嘅差異，呢係架構哲學嘅根本分歧。

Truth-recall 呢個數字點解重要

我哋做 AI agent 嘅人，對 web scraping 嘅要求同傳統 SEO 爬蟲完全唔同。傳統爬蟲嘅 KPI 係「爬到幾多頁」，AI agent 嘅 KPI 係「攞到嘅內容有幾準」。一個 scraper 俾你 HTTP 200，但返回嘅係 cookie banner、登入牆、或者一堆 tracking script 嘅 JSON——呢個唔叫 scrape 成功，呢叫 noise。

fastCRW 嘅 63.74% truth-recall 意思係：喺八百一十九條有標註嘅 URL 入面，佢成功返回正確內容嘅有五百二十二條。Firecrawl 只做到四百五十九條。差嘅六十三條，喺 agent workflow 入面就係六十三次 hallucination 嘅根源——你個 agent 以為佢睇到咗網頁嘅真實內容，但其實佢睇到嘅係垃圾。

呢個差距嘅來源唔係 Rust 跑得快咁簡單。fastCRW 嘅核心架構係一個 renderer escalation ladder：先試 HTTP fetch（靜態頁面直接攞），失敗就升級到 LightPanda（輕量級 JS 渲染器，五十到一百 MB RAM），再失敗就升級到 Chrome over CDP，最後仲有 Camoufox stealth renderer 做最難嘅反爬蟲場景。每一層都內建 anti-bot 能力——十二種信號偵測、user-agent rotation、fingerprint stealth、residential proxy rotation。唔係分開嘅服務，唔係額外嘅微服務，係同一個 binary 入面嘅自動升級鏈。

Firecrawl 嘅架構係另一條路：Playwright 服務做渲染，PostgreSQL 用 pg_cron 做 job queue，RabbitMQ 做 fan-out，Redis 做 cache。每個組件都係獨立嘅 container。呢個設計喺 scaling 上面有優勢，但喺 latency 同部署複雜度上面付出代價。Firecrawl 嘅 p90 latency 係 6937ms，fastCRW fast mode 係 4348ms——差咗百分之三十七。

8MB binary 嘅底層邏輯

一個 8MB 嘅 Docker image 同一個 2-3GB 嘅 multi-container stack，差距唔止係 disk space。呢個代表嘅係完全唔同嘅部署心智模型。

fastCRW 嘅 Dockerfile 係經典嘅 multi-stage build：用 rust:1.93-bookworm 做編譯，strip 完 binary，淨係將 stripped artifact 搬去 debian:bookworm-slim。冇 Redis、冇 Node.js runtime、冇 message queue、冇獨立嘅 worker process。一個 command 就跑起。idle RAM 係十四 MB。

Firecrawl 嘅 self-hosted 版本，最少要跑五個 container。每個 container 都有自己嘅 memory footprint。Playwright service 要至少 1GB shared memory 嚟跑 Chromium。整個 stack 嘅 idle RAM 起碼幾百 MB。部署一個 self-hosted Firecrawl，你要 manage Docker Compose、Playwright 版本、PostgreSQL schema migration、RabbitMQ queue config。呢個唔係「複雜雜啲」咁簡單，係完全唔同嘅 operational complexity tier。

呢個差距嘅根源係語言選擇。Rust 編譯出嚟嘅係 static binary，冇 runtime、冇 GC、冇 VM overhead。Node.js 同 TypeScript 編譯出嚟嘅係 JavaScript，需要 Node runtime，而 Chromium 本身係一個巨大嘅 native dependency。Firecrawl 嘅 Rust component（anydoc library 做 PDF parsing）只係成個 stack 嘅一小部分——佢嘅核心 rendering pipeline 仍然係 Node.js + Playwright。

呢個唔係「Rust vs Node.js」嘅語言 wars。呢個係「single binary vs microservices」嘅架構選擇。當你嘅用戶係一個 indie developer，想喺自己嘅 VPS 上面跑一個 scraping service，一個 8MB binary 同一套 five-container stack 之間嘅差距，就係「五分鐘部署」同「半日 setup」嘅差距。

AI Agent 生態嘅基礎設施戰爭

Web scraping 之所以重新變得重要，係因為 AI agent 嘅崛起。每一個 RAG pipeline、每一個 web-browsing agent、每一個 research assistant，底層都需要 scraping infrastructure。呢個唔係一個 optional feature，呢係基礎設施。

fastCRW 嘅策略好清晰：佢唔係要做一個更好嘅 scraping API，佢係要做 AI agent 嘅 scraping infrastructure layer。佢內建 MCP server，直接對接 Claude、Cursor、Windsurf、Gemini CLI。佢已經被 BerriAI/litellm、ByteDance/deer-flow、Mintplex-Labs/anything-llm 集成。呢個唔係 demo project，係有真實 production adoption 嘅 infrastructure。

Firecrawl 嘅護城河係 ecosystem——180K stars、官方 LangChain 同 LlamaIndex integration、成熟嘅 managed service。呢個優勢唔可以忽視。但 fastCRW 嘅 approach 係用 Firecrawl 自己嘅 benchmark 數據集打 Firecrawl 嘅臉，然後俾你一個 Firecrawl-compatible API——migration 只係改 base URL。呢個係 aggressive 嘅竞争策略。

值得留意嘅係，fastCRW 嘅 benchmark 仲顯示佢獨家 recovery 咗三十四條 URL——呢啲 URL 其他兩個 competitor（Firecrawl 同 Crawl4AI）都搞唔掂。呢個代表嘅唔止係 accuracy 更高，而係 coverage 更廣。你嘅 agent 需要爬嘅唔止係 easy pages，仲有嗰啲反爬蟲嚴重嘅動態內容頁面。

對開發者嘅建議

如果你係一個 indie developer 或者 small team 嘅 tech lead，正在為你嘅 AI agent project 揀 scraping infrastructure，我嘅建議好直接：

第一，唔好只睇 GitHub stars。Firecrawl 嘅 180K stars 代表嘅係 legacy adoption 同 ecosystem momentum，唔代表佢係你嘅最佳選擇。用你自己嘅 use case 做 benchmark——fastCRW 嘅 diagnose_3way.py harness 係 open source 嘅，你可以自己跑。

第二，考慮你嘅 operational complexity budget。如果你嘅 infra team 係你自己一個人，一個 8MB binary 嘅 deployment cost 同一套 five-container stack 嘅 deployment cost，差距係数量级嘅。fastCRW 嘅 self-hosted version 係 zero-cost 嘅（AGPL-3.0），而 Firecrawl 嘅 managed service 起步係 $16/月。

第三，諗清楚你嘅 agent 對 scraping accuracy 嘅 tolerance。如果你嘅 agent 係做 research、做 fact-checking、做任何需要 high-fidelity content extraction 嘅任務，63.74% 同 56.04% 嘅 truth-recall 差距，喺 scale 上面會放大成幾十次、幾百次嘅 hallucination 差異。

Web scraping 嘅軍備競賽先至開始。當每一個 AI agent 都需要 reliable web access 嘅時候，scraper 嘅架構選擇會成為 agent infra stack 入面最重要嘅 decision 之一。8MB 同 2GB 之間嘅差距，唔止係 disk space——呢個係 operational philosophy 嘅差距。