ScrapeGraphAI：用提示詞取代 CSS 選擇器的抓取管線，以及它的代價

它解決的是解析器維護，不是抓取本身

傳統抓取的工作量幾乎都花在選擇器上。你要先讀目標網站的 DOM，寫出 XPath 或 CSS selector，然後在對方改版時回頭修。ScrapeGraphAI 把這段換掉：README 的說法是「Just say which information you want to extract and the library will do it for you」，你描述要什麼欄位，由模型判斷頁面上哪一段文字對應到哪個欄位。

目標讀者因此很明確。手上有一批結構各異、欄位語意卻一致的頁面，例如公司介紹頁、產品規格頁、活動公告頁，而且這些頁面的模板不統一，寫通用選擇器的成本高於呼叫模型的成本。反過來說，如果你抓的是自家後台或合作方提供的固定 API 回應，選擇器一次寫好能用三年，就沒有理由引入模型。這個工具的適用邊界取決於頁面變動頻率，不是取決於頁面數量。

SmartScraperGraph 的資料流：提示詞進，字典出

README 把 SmartScraperGraph 定義為「Single-page scraper that only needs a user prompt and an input source」。實際運作時，你提供兩個輸入：prompt 描述要抽取什麼，source 是網址或本地檔案。函式庫先把頁面內容取回來，再交給 LLM 依 prompt 產生結構化結果，run() 回傳的是 Python 字典，README 的範例用 json.dumps(result, indent=4) 印出巢狀結構，包含 description 字串、founders 陣列、social_media_links 物件。

值得注意的是輸出形狀由 prompt 決定，而不是由程式碼定義。範例中 founders 的每一項有 name、role、linkedin 三個鍵，其中一筆的 name 是空字串。這說明模型會忠實回報它找不到的欄位，而不是省略該鍵。對下游程式來說這是好事，因為鍵的集合穩定；但同時也意味著你必須自己判斷空字串代表「頁面上真的沒有」還是「模型漏看」。

除了單頁抓取，README 的管線表還列出 SearchGraph（從搜尋引擎前 n 筆結果跨頁抽取）、SpeechGraph（抽取後產生音訊檔）與 ScriptCreatorGraph。這些是不同 Graph 類別，不是同一個類別的參數切換。

安裝與最小可執行設定

安裝分兩步，第二步不能省。README 的指令是 pip install scrapegraphai，接著 playwright install，並註明後者「for fetching websites content」。只裝 pip 套件而不裝瀏覽器執行檔，抓取階段會失敗。README 另外建議裝在虛擬環境中，理由是避免與其他函式庫衝突。

graph_config 是設定的核心。以本地 Ollama 為例，llm 區塊放 model 為 ollama/llama3.2、model_tokens 為 8192、format 為 json，外層再放 verbose 與 headless。改用 OpenAI 時只需要替換 llm 區塊，放入 api_key 與 model 為 openai/gpt-4o-mini，其餘不變。這個切換成本低是設計上的優點：模型是可替換的依賴，不是綁死的供應商。

headless 這個鍵值得單獨看。範例設為 False，代表會開出可見的瀏覽器視窗。開發階段方便觀察流程，放進容器或 CI 就會出問題，因為那裡沒有顯示伺服器。format 設為 json 則是要求模型輸出結構化格式，README 只在 Ollama 範例中示範這個鍵，OpenAI 範例沒有帶，是否所有模型後端都支援同一組鍵，README 沒有說明。

確定性消失之後，抓取變成推論問題

選擇器抓取是確定性的：同樣的 HTML 進去，同樣的結果出來，你可以寫測試斷言。ScrapeGraphAI 把這一步換成模型推論，於是同一頁面重複執行不保證得到位元組相同的輸出。欄位順序、措辭、甚至某個欄位是否被判為空，都可能變動。README 的範例輸出中有一筆 founders 的 name 為空字串，正好說明了這種不穩定性：你無法從程式碼層面判斷那是頁面缺漏還是模型判斷差異。

第二個限制是成本結構。每一次 run() 都是一次 LLM 呼叫，token 消耗隨頁面長度上升。model_tokens 設為 8192 是範例給的值，超過這個長度的頁面會發生什麼，README 沒有交代。對需要每日重抓數萬頁的情境，這個成本模型和選擇器抓取完全不在同一個量級。

第三個限制更根本：這個工具不處理反爬。它依賴 playwright 取得頁面內容，登入牆、驗證碼、需要點擊才載入的內容，都不在它宣稱的範圍內。README 也沒有提到重試、代理輪換或速率控制。如果你的目標站點有這些防護，換掉解析層並不會讓抓取變得可行。

和 Firecrawl 這類託管服務的差別在哪

專案自己的 topics 裡列了 firecrawl-alternative，把 Firecrawl 當作對照組。兩者的差異不在功能清單，而在執行位置與責任歸屬。ScrapeGraphAI 是 MIT 授權的 Python 套件，跑在你的機器上，模型可以是你自己的 Ollama，也可以是你的 OpenAI 金鑰。Firecrawl 這類服務則把抓取與解析放在對方的基础設施上，你呼叫 API 拿結果。

選擇的關鍵是資料邊界。如果目標頁面涉及內部系統或不能外送的內容，本地執行是硬需求，此時 ScrapeGraphAI 的架構是對的。如果團隊沒有人想管瀏覽器依賴、模型金鑰與版本升級，託管服務省下的維運時間可能大於 API 費用。README 自己也把 scrapegraphai.com 的雲端版本放在最上方推廣，並說那是「an even faster and simpler way to scrape at scale」，這等於承認本地套件在規模化上不是最省事的路徑。

另一個對照是直接用 LangChain 或 LlamaIndex 自己串。ScrapeGraphAI 的 README 列出與這些框架的整合，代表它並不打算取代它們，而是提供已經組好的圖。差別在於你要自己維護那張圖，還是接受它既有的節點設計。

授權、升級與維護成本

授權是 MIT，這對商業使用友善，沒有 copyleft 傳染問題。但要注意 README 同時推廣商業雲端服務，程式庫本身與雲端 API 是兩套東西，採用套件不等於採用服務，反之亦然。

版本節奏偏快。近期發布包含 v2.2.3、v2.2.4-beta.1 與 v2.2.4，時間集中在同一天。這種節奏表示專案活躍，也表示你如果鎖定某個版本，升級時要預期行為變動。加上 LLM 供應商的模型本身也會更新，同一個 model 字串在不同時間可能指向不同權重，抓取結果的穩定性因此有兩層不確定性疊加。

維護成本還有一項容易低估：playwright 的瀏覽器執行檔需要跟著環境更新，容器映像會因此變大。若你的部署流程對映像大小或啟動時間敏感，這一項要在評估階段就量測，而不是上線後才發現。

先驗證什麼再決定採用

第一步是跑通最小範例。用 README 的 SmartScraperGraph 程式碼，把 source 換成你自己的一個目標頁面，prompt 換成你要的欄位，verbose 保持 True 觀察流程。headless 在本地可以設 False，但要記得在部署設定中改回 True。

第二步是測穩定性。同一個頁面連續跑五次，比對輸出字典的鍵集合與值。如果鍵集合穩定而值有出入，那是可接受的語意層波動；如果鍵本身會消失或改名，你的下游程式會壞掉，此時應該在 prompt 中把欄位名稱寫死，而不是依賴模型自行命名。

第三步是測長頁面。找一個明顯超過範例 model_tokens 值的頁面，看它是被截斷、報錯，還是照常處理。README 沒有給出這方面的行為說明，只能自己確認。這三項測完，你對這個工具在你場景中的實際成本與風險就有具體數字了，而不是停留在「用 AI 抓取」的印象。

編輯結論

如果你的目標頁面經常改版、欄位語意比 HTML 結構穩定，而且你能接受每次執行都呼叫 LLM，ScrapeGraphAI 值得先用 SmartScraperGraph 跑通一條管線；若你需要毫秒級、可重現、可稽核的抓取結果，或頁面本身有反爬與登入牆，這個工具不是對的選擇。採用前請先確認三件事：playwright install 是否在你的部署環境可行、你選的模型是否支援 format: json 的結構化輸出、以及 graph_config 中 model_tokens 對你要抓的頁面是否夠用。

官方來源

1. License: MIT
2. Project website
3. README
4. Releases
5. ScrapeGraphAI/Scrapegraph-ai on GitHub