webclaw 自架評測：Rust 寫的網頁轉 Markdown 引擎，離線能跑到什麼程度

它想解決的是「餵給模型之前的髒資料」

README 開頭把問題講得很直白：多數爬蟲工具給 agent 的輸出非黑即白。一種是被封鎖的頁面、登入牆或空殼 SPA，抓回來等於什麼都沒有；另一種是原始 HTML，塞滿導覽列、script、樣式、廣告與重複的樣板文字，模型讀完還得自己濾一遍。webclaw 的定位就在這兩者之間：把 URL 換成乾淨的 Markdown、JSON 或 LLM 格式。目標使用者寫在標題底下，是 AI agent 與 RAG pipeline 的開發者，也就是需要把網頁內容塞進上下文視窗、又不想自己寫清理邏輯的那群人。這個問題本身不新鮮，新鮮的是它把整條鏈路用 Rust 重寫，並同時提供 CLI、MCP server、REST API 與 SDK 四種接入面。

擷取引擎與四種接入面的分工

從 repo 說明可以看出元件切分：開源部分是 CLI、MCP server、擷取引擎與可自架的 server，hosted 的 webclaw.io 則是另一條商業服務。工具層列出八個動作。scrape 處理單一 URL，輸出 markdown、text、JSON、LLM 格式或 HTML；crawl 沿同源連結往下走並擷取發現的頁面；map 只做 URL 探索、不逐頁擷取；batch 平行處理多個 URL；extract 把頁面內容轉成結構化資料；summarize 做摘要；diff 比對頁面內容快照；brand 抽品牌素材。表格的 Local 欄標示前幾項為 Yes，extract 與 summarize 則註明需要本地或已設定的 LLM。這代表一件事：結構化擷取與摘要不是純規則引擎，背後要接模型，離線與否取決於你把模型放在哪裡。crawl 走的是同源連結，跨網域的文件站不會自動展開，這是設計上的收斂。

安裝路徑與實際會敲到的指令

最省事的一條是 npx create-webclaw，README 說它會偵測支援的客戶端並自動寫好 MCP 設定。想要系統級安裝可用 brew tap 0xMassi/webclaw 再 brew install webclaw，或直接抓 GitHub Releases 的 macOS、Linux、Windows 預編譯檔。容器派的話 docker run --rm ghcr.io/0xmassi/webclaw https://example.com 就能跑一次擷取。從原始碼編譯則用 cargo install --git https://github.com/0xMassi/webclaw.git webclaw-cli，MCP 版本把結尾換成 webclaw-mcp。README 也列了各平台的建置前置套件，例如 Debian 與 Ubuntu 要 pkg-config、libssl-dev、cmake、clang、git、build-essential，macOS 則是 xcode-select --install。這份清單的存在本身就說明它不是純 Rust 無依賴的專案，OpenSSL 與 cmake 是硬需求。日常用法上，webclaw https://stripe.com --format markdown 是最短路徑，--format llm 換成模型最佳化文字，--only-main-content 只留主體，--include 與 --exclude 吃 CSS 選擇器，例如 --include "article, main, .content" 搭配 --exclude "nav, footer, .sidebar, .ad"。爬整站是 webclaw https://docs.rust-lang.org --crawl --depth 2 --max-pages 50，這兩個旗標同時存在是有意義的：深度與頁數各自設上限，避免一個連結密集的站台把佇列撐爆。MCP 端可用 npx -y @webclaw/mcp 當 command，或走 npx skills add 0xMassi/webclaw-skill 把 scrape、crawl、map、extract、summarize、diff、brand、search 掛成 agent 的原生工具。

本地優先的邊界畫在哪裡

README 對這點的措辭很節制：多數站台不需要 API key 就能在本地擷取，設定 WEBCLAW_API_KEY 則用來處理有機器人防護與需要 JavaScript 渲染的頁面。這句話就是整個專案最重要的限制。反爬與前端渲染這兩類頁面，在純本地模式下拿不到完整內容，得把請求導向 hosted 服務。repo 的 topics 裡有 tls-fingerprinting，examples 目錄下有 cloudflare-diagnostics 與 proxy-backed-crawling，可見團隊清楚這條戰線的存在，也提供了代理與診斷的範例路徑，但 README 沒有說明自架 server 是否同樣具備這些能力。另一個要留意的是 extract 與 summarize 依賴 LLM，本地或自帶皆可，代價是你得自己準備模型與算力。還有一個容易被忽略的失敗模式：SPA 空殼。README 把它列為現有工具的典型壞輸出之一，而這正是需要渲染的那一類，也就是最可能落到 hosted API 的案例。如果你的目標站台多半是這種，本地優先的賣點對你幾乎不成立。

授權是 AGPL-3.0，不是 MIT

LICENSE 指向 AGPL-3.0。這對內部工具或自架服務通常不構成問題，但如果你打算把 webclaw 包進自家產品再散布，或讓使用者透過網路與你修改過的版本互動，AGPL 的傳染性條款就會啟動，衍生作品的原始碼得跟著開。這是採用前該和法務確認的事，本文不提供法律意見。另一層成本是維護。release 節奏看起來相當密集，v0.6.20 與 v0.6.21 同一天發布，v0.6.22 在兩週後跟進，版本號還停在 0.6.x。這代表介面與旗標仍可能變動，把它寫進 CI 或包裝成內部服務時，得留升級測試的空間。從原始碼安裝還綁定 Rust 工具鏈與前述的系統套件，團隊若沒有 Rust 維護能力，長期得依賴預編譯二進位或容器映像。

和 Firecrawl 這類託管 API 的取捨

repo 的 topics 直接把自己標成 firecrawl-alternative、crawl4ai-alternative、jina-alternative 與 apify-alternative，README 也附了 firecrawl-compatible-api 的範例。差別在架構位置而非功能清單。Firecrawl 這一類是託管 API：你把 URL 送出去，對方負責代理池、瀏覽器渲染與反爬繞行，你付費換取不必維運。webclaw 反過來，把引擎放進你的機器或你的容器，資料不出去，代價是反爬與渲染的難題回到你手上，除非你另外接 hosted 服務。所以真正的分水嶺不是誰抽得比較乾淨，而是你願不願意讓頁面內容經過第三方。若你的來源是公開文件站、內部 wiki 或自家可控的網站，本地路徑的隱私與成本優勢成立；若來源是電商、社群或任何會擋爬蟲的站台，託管服務的價值就在那些你不想自己維護的代理與瀏覽器上。crawl4ai 走的是另一條路，Python 生態、與既有資料處理流程貼合，但語言與部署形態和 webclaw 的 Rust 單一執行檔是兩種取捨。

誰該先用，誰該再等

最合適的採用者是已經在用 Claude Code、Cursor 這類 MCP 客戶端的團隊，因為 npx create-webclaw 這條路徑把設定成本壓到幾乎為零，先讓 agent 能抓網頁，再決定要不要深入。其次是來源可控、重視資料不出境的團隊，例如把自家文件站轉成 RAG 索引。不該用的情況也明確：需要大規模繞過反爬、或頁面幾乎都是 JavaScript 渲染的場景，本地模式會頻繁落到 hosted API，那不如直接評估託管方案；產品必須閉源散布的團隊則要先過 AGPL 這一關。要驗證的第一件事，是拿你最在意的那幾個 URL，在不設 WEBCLAW_API_KEY 的情況下跑一次 --format markdown 與 --only-main-content，看抽出來的內容夠不夠餵模型。第二件是確認自架 server 涵蓋的工具集是否與 CLI 一致，README 對這點著墨不多。第三件是 AGPL 條款對你散布方式的實際約束。這三項驗完，採用與否會自己浮出答案。

編輯結論

如果你要的是一條跑在自己機器上的 URL 轉 Markdown 管線，而且願意接受 AGPL-3.0 的傳染性條款，webclaw 值得放進候選名單：CLI、MCP server 與可自架伺服器都在同一個 repo，安裝路徑清楚。反之，若你的產品必須閉源散布、或團隊沒人能維護 Rust 工具鏈，這個授權與建置成本會先擋住你。動手前先確認三件事：目標站台在沒有 WEBCLAW_API_KEY 的情況下能抽出多少內容、self-host 的 server 是否涵蓋你需要的工具集、以及 AGPL 對你散布方式的實際約束。這三項沒驗過，其他都不用談。

官方來源

1. 0xMassi/webclaw on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases