ScrapeGraphAI 评测：用 LLM 和图逻辑替代传统抓取规则

它解决的问题：把抓取从 CSS 选择器变成一句话

传统网页抓取的核心痛点是选择器维护。页面结构一改，CSS 路径和 XPath 就失效，代码得跟着改。ScrapeGraphAI 想用 LLM 绕开这一层。你告诉它要什么信息，它自己决定怎么从页面里找。README 给出的例子是：prompt 写“提取公司描述、创始人和社交媒体链接”，source 给一个 URL，run 之后返回一个结构化的字典。这个库面向的是不想为每个站点写定制解析器的 Python 开发者，尤其是需要快速从多个异构页面抽取同类信息的场景。它不是一个通用爬虫，它不负责抓取整个网站，只负责从给定源里抽取你点名要的字段。

管线机制：图逻辑如何编排一次抓取

库的核心抽象是“图”。每个抓取任务被组织成一个有向图，节点代表抓取步骤，边代表数据流动。SmartScraperGraph 是最简单的单页管线，输入是 prompt 和 source，输出是 JSON。SearchGraph 则把搜索、抓取、抽取串成一条链：先跑搜索引擎取前 n 个结果，再对每个结果页执行类似 SmartScraper 的抽取，最后汇总。SpeechGraph 在抽取之后接一个文本转语音节点，直接生成音频文件。ScriptCreatorGraph 更特殊，它不直接返回数据，而是生成一段 Python 脚本，脚本本身执行抓取。这种设计把 LLM 的职责分成了两类：一类是理解 prompt 并决定抽取逻辑，另一类是生成代码。README 里没有给出图的具体实现细节，比如节点之间如何传递上下文、是否有缓存层，但从配置项看，每个管线都接受一个 graph_config，里面至少包含 llm 和 headless 两个键。

跑起来：两条命令和一个配置字典

安装分两步。先用 pip install scrapegraphai 装库，再跑 playwright install 来获取浏览器内核，因为抓取需要 headless 浏览器渲染页面。代码层面，你只需要构造一个 graph_config 字典和一个 SmartScraperGraph 实例。字典里 llm 键是核心，它决定用哪个模型。README 给了两种写法：本地模型用 ollama/llama3.2，同时指定 model_tokens 为 8192 和 format 为 json；云端模型则换成 openai/gpt-4o-mini 并填入 api_key。format 设成 json 很关键，它要求模型输出合法 JSON，管线才能解析成 Python 字典。headless 键控制浏览器是否无头运行，开发调试时可以设成 False 以便观察。最后调用 run()，返回的就是一个字典，可以直接 json.dumps 打印。整个过程没有自定义选择器，没有正则，没有 HTML 解析代码。

真正的限制：成本、延迟和不可控的抽取质量

ScrapeGraphAI 的短板恰好是它的卖点带来的。每次 run 都至少调用一次 LLM，这意味着单次抓取的成本远高于纯 requests 加 BeautifulSoup 的方案。如果目标页面有 100 个商品条目，传统代码一次循环就搞定，而 LLM 要么把所有内容塞进一个超长 prompt，要么分多次调用，token 费用和延迟都会线性上涨。另一个问题是输出结构不稳定。模型返回的 JSON 字段名和嵌套层级可能随 prompt 措辞变化，也可能随模型版本变化。README 的示例输出里 founders 数组中的 name 字段就是空字符串，这说明模型在抽取时可能漏掉信息，而且不会报错。你无法判断空值是页面本来就没有，还是模型没找到。此外，抓取依赖 headless 浏览器，对 JavaScript 重的站点是优点，但对反爬严格的站点，Playwright 的指纹很容易被识别。这些限制没有在 README 里展开，但从配置项和输出样例可以推断出来。

替代方案：Firecrawl 与直接调用 LLM 的差异

项目自己的话题标签里写着 firecrawl-alternative，说明它把自己定位成 Firecrawl 的开源对手。Firecrawl 是一个商业服务，提供抓取 API，同样用 LLM 做结构化抽取，但它是托管式的，你不需要自己装 Playwright，也不用管模型配置，发 HTTP 请求就行。ScrapeGraphAI 则把整个管线放在你的进程里，模型可以接本地 Ollama，数据不出机器。这个差异是实质性的：如果你要抓取的数据涉及隐私或合规要求，本地部署的 ScrapeGraphAI 有优势；如果你只想要一个稳定的 API 且不想维护浏览器环境，Firecrawl 更省事。另一个更朴素的替代方案是绕过抓取库，直接把你从页面里拿到的 HTML 文本塞给 LLM，自己写 prompt 要 JSON。这样做少了一层抽象，但你需要自己处理 HTML 清洗、截断和重试。ScrapeGraphAI 的价值在于把这些步骤封装成了管线，代价是你得接受它的配置约定和黑盒行为。

维护成本与许可证：MIT 下的双轨陷阱

开源版本采用 MIT 许可证，你可以自由修改和商用，这一点没有法律负担。但 README 顶部和集成章节反复推销 scrapegraphai.com 的云版本，说它“更快更简单，只要 5 行代码”。这意味着项目本身是商业公司的引流入口。开源库的更新节奏看起来活跃，最近一次推送是 2026 年 9 月，版本号到 v2.2.4，但 README 没有提供变更日志或迁移指南。维护成本主要在三处：一是 Playwright 浏览器版本需要跟随库的更新而升级，否则可能遇到渲染不兼容；二是 LLM 模型迭代快，今天用的 gpt-4o-mini 可能明天被弃用，你的 graph_config 得跟着改；三是图管线的行为可能随版本调整，比如某个节点增加了缓存或改变了输出格式，你的下游解析代码就得适配。如果你只是抓个静态页，用 requests 加一个 LLM 调用可能更省心。

编辑结论

ScrapeGraphAI 适合两类人：一类是原型验证阶段，需要快速从单个页面抽取非结构化信息的开发者，另一类是已经接受 LLM 调用成本、愿意用自然语言替代选择器维护的团队。不适合对抓取延迟敏感、需要精确控制每一次请求、或者预算有限且目标页面结构长期稳定的生产环境。采用前先验证三件事：第一，你的目标网站是否允许 headless 浏览器访问，README 明确要求 playwright install，许多反爬严格的站点会拦截；第二，所选 LLM 的 JSON 输出稳定性，因为管线依赖 format: json 来解析结果，模型一旦返回非法 JSON，整个 run 就会失败；第三，多页抓取时 SearchGraph 的搜索引擎结果质量，它决定最终抽取的上限。最终判断：ScrapeGraphAI 的价值在于把抓取从选择器维护变成提示词调优，但这也意味着你的抓取逻辑从此绑定在某个 LLM 的行为上，模型升级或替换都可能改变输出结构，这是一个需要提前接受的边界。

官方来源

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