AI 爬虫工具怎么选：从抓取、结构化提取到浏览器 Agent

采集文档、提取商品字段和操作动态页面，需要的能力不同。选工具前，先确定哪一步遇到了困难：页面拿不到、正文不干净、字段不好定位，还是必须执行交互。

这篇比较六个 GitHub 项目的定位，并引用同系列的本地实验。资料与实验更新于 2026 年 10 月 29 日。Crawl4AI、Scrapling 完成了无模型运行；Stagehand 跑通了确定性浏览器流程，模型方法仅做源码和类型核对；另外三个项目依据官方资料比较。

这些证据没有形成统一性能基准，因此不提供“最快”“最抗封”或总分排名。

从你的任务开始

知识库数据不只是 Markdown。来源 URL、获取时间、重复内容和失败页面都影响后续检索质量。

浏览器 Agent 也不自动承担完整的站点级爬虫调度。任务交互、URL 队列和持续更新应分别确认。

把采集链路拆开比较

一条常见的数据流程如下。

加载图表中...

在这条链路外，还需要考虑任务调度、限速、重试和运行记录。某个库具有几项能力，不代表它已经替你完成整套运行系统。

六个项目各自适合什么

下表是能力定位，不是实测评分。

先决定模型是否需要进入采集链路

“给 AI 用的数据”与“让 AI 执行采集”是两个选型条件。前者可以完全不调用模型；后者才需要为语义判断配置推理服务。

例如，你要把文档正文交给后续问答服务，采集阶段只需保留正文与来源。Crawl4AI 的本地示例已经验证了这条无模型路线。

如果你需要判断页面上哪个按钮代表“查看下一批有效商品”，语义动作才可能有价值。先确认固定选择器是否足够，再决定是否增加模型调用。

这个顺序可以避免把每次页面读取都变成推理请求。它是一种按任务缩小方案的做法，不是对模型调用节省比例的实测。

将部署方式与功能清单一起判断

工具选型还取决于谁负责运行。相同的项目名称，可能同时指向本地库、自托管服务和托管产品。

本地库给了你控制权，也把环境问题留给你。示例运行时固定了 Python、Node、浏览器和依赖版本，正是为了让这种控制能够被复查。

托管 API 减少的运维内容，应当按该产品的实际服务约定核对。开源仓库的接口说明不能替代托管服务条款，托管宣传也不能替代自托管验证。

本文对 Firecrawl 和 ScrapeGraphAI 的两种交付方式分别说明；没有假定它们具备完全相同的功能或表现。

把认证、队列和更新责任列出来

即使单页示例已经成功，持续采集仍然需要回答下面的问题。

这张表描述应用需要作出的决定，并不宣称六个项目都缺少相关功能。选型时应逐项核对候选工具的接口，确认哪些由库提供，哪些由你的代码补齐。

后面的实验分别覆盖了其中一部分：Crawl4AI 检查发现与更新，Scrapling 检查记录身份，Stagehand 的确定性流程检查登录与分页。

本地实验提供了哪些证据

Crawl4AI：数据可追溯，需要明确缓存策略

使用 0.9.5 采集本地文档站，首轮得到三篇有效文档，第二轮四篇，正确识别新增一篇、修改一篇、未变两篇。动态正文、代码内容、表格字段和相对链接都进行了检查。

空正文 200 和 404 被单独记录。缓存实验还观察到：未启用 freshness 验证的 CacheMode.ENABLED 继续返回旧正文，BYPASS 才获取到修改。

因此，自托管文档采集可以先考察 Crawl4AI；是否按期更新，仍取决于你的发现、缓存与差异处理策略。

实现与复跑方法见 Crawl4AI 文档采集。

Scrapling：恢复候选不等于恢复完整列表

使用 0.5 测试固定商品数据。改类名后，自适应结果只得到 p1，漏 p2、p3；增加包装层后返回三个无 ID 节点；干扰卡片沿用原类名时，原查询直接命中 ad1。

源码 scrapling/parser.py:662-680 显示，自动保存使用首个元素，且原选择器有结果时不会触发重新定位。这解释了为什么不能只按返回节点数判断成功。

Scrapling 可作为 Python 采集候选，但你应将自适应结果作为需要核对的数据。实验没有验证它的吞吐、Spider 恢复或反爬表现。

完整对照见 Scrapling 改版实验。

Stagehand：确定性流程已运行，AI 效果尚未测量

使用 4.3.0 的本地浏览器，测试账号登录后筛选 active books，读取两页并核对三件商品。在保留稳定 ID、修改按钮文字和增加延迟的变体上，确定性流程也通过。

这证明了示例中的脚本和状态等待可以工作，不能证明模型具备相同表现。observe()、act()、extract() 的配置、返回结构与示例已核对类型和源码，没有调用模型 API。

若你需要把脚本和语义操作组合起来，可从 Stagehand 配置指南 开始，再在自己的模型和页面上验证。

托管 API 与自托管分别比较

Firecrawl 的官方 README 提供 Search、Scrape、Crawl、Map、Batch 等功能说明；SELF_HOST.md 同时说明，本地基线使用浏览器和基础获取，并需要为相关 AI 功能配置模型。

因此，使用托管 API 时，要确认额度、数据处理约定、可用功能与费用。自托管时，则要承担浏览器、队列、存储、代理和运维责任。不要把托管版宣传中的覆盖率和延迟直接套到本地部署。

ScrapeGraphAI 的官方 README 也区分自运行 scrapegraphai 与托管 SDK/API：前者由你配置模型和运行环境，后者将更多获取与运维工作交给服务商。

本文没有调用这两种托管服务，没有验证它们的额度消耗或本地/云端能力一致性。

browser-use 与 Stagehand 如何取舍

从公开接口定位看，browser-use 面向模型驱动的浏览器任务；Stagehand 适合在明确代码流程中加入语义定位、动作和提取。

如果任务步骤基本稳定，可先写确定性流程，再识别确实需要语义判断的位置。若步骤本身依赖模型规划，则应验证任务完成率、动作边界与失败后的处理。

这是基于项目定位的选型判断。本批没有对两者执行同任务、同模型的 AI 对照测试，不能据此比较准确率或 Token 效率。

代理和成本需要单独核算

代理处理访问路径，选择器和模型处理页面内容，两者解决的问题不同。换 IP 不会自动修复缓存中的旧正文，也不会纠正一个仍命中推荐卡片的选择器。

从失败结果反推下一步选择

有了候选工具，先定位失败属于哪个环节，再决定是否更换方案。

这些问题中，有些需要修正配置或定位规则。直接换成模型并不能免除最终的数据核对，也不能证明原来失败的原因已经消失。

例如，Scrapling 的返回数量看起来正常时，业务 ID 检查仍然能阻止错误数据被当成商品列表。这种检查也可以保留到其他采集方案中。

用同一目标计算采集成本

如果比较两个候选方案，应固定目标页面、字段和完成条件。只比较一次 API 响应耗时，可能漏掉清洗、翻页和补采的代价。

可以将一次完整任务的记录按以下层次整理：

1. 本轮发现了多少候选 URL，其中多少属于目标范围。
2. 获取了多少页面，哪些响应为空或失败。
3. 输出了多少完整记录，是否有漏项或错误身份。
4. 为完成同一目标，额外执行了多少次重试或推理。
5. 最终为哪些浏览器、API、模型或网络资源付费。

本批只验证小型本地任务及其输出，没有给出每千页费用。托管价格、模型计费和代理套餐可能变化，不宜把没有测量的数字写成固定成本。

你可以先保留这些记录，再代入自己实际使用的资源价格。字段完整性不达标的结果，也不应仅因请求便宜就算作有效产出。

在自己的任务上做最小验证

先选一小组有答案的页面，包含正常、动态、空结果和页面变化。定义字段、来源和完成条件，再固定依赖版本执行。

记录成功结果，也保留失败原因。尤其检查“状态成功但内容错误”的情况，而不是只统计请求成功率。

开始扩大规模前，再验证并发、会话、重试及运行成本。公开项目的功能清单可以帮助缩小范围，最终选择仍需要你的任务证据。

依次阅读哪篇实战

三篇都给出固定的示例源码版本和运行步骤。运行需要的浏览器或依赖安装与文章写作分开；Stagehand 模型配置由读者按需提供。

先选择最贴近你当前问题的一篇，核对输出后再扩展规模，可以让选型结论建立在任务结果上。

如何复查这份选型结论

先准备 Git 和可访问公开仓库的 GitHub CLI，获取固定版本的实验与证据文件。

gh repo clone 16yun-cn/www-16yun-cn-v3 ai-crawling-examples -- --filter=blob:none --sparse
cd ai-crawling-examples
git checkout --detach bc6828e62c417b1a3459199811fd4e2164137a5f
git sparse-checkout set scripts/blog-ai-crawling docs/blog-research

这个提交固定的是运行过的示例，不是要求你使用某个持续变动的开发分支。三篇实战中的代码行号也指向这个版本。

阅读证据时，要区分它可以支持哪一类结论。

这也是本文没有给六个项目打统一分数的原因。三类证据都保留了用途和限制，方便你决定还需要补做哪些验证。

资料与版本范围

可按以下仓库标识和路径核对来源；源码行号对应所列提交。

• unclecode/crawl4ai，0.9.5，提交 888299f，crawl4ai/async_crawler_strategy.py:1096-1119。
• D4Vinci/Scrapling，0.5，提交 0336400，scrapling/parser.py:662-680；相关 Issue #259。
• browserbase/stagehand，4.3.0，提交 d59afde，packages/sdk-ts/src/stagehand.ts:246-324。
• firecrawl/firecrawl，提交 33f295d，README.md:65-85；另核对自托管说明。
• browser-use/browser-use，提交 2cc7189，README.md:103-173。
• ScrapeGraphAI/Scrapegraph-ai，提交 194055e，README.md:168-180。

本项目源码中的 docs/blog-research/2026-10-ai-crawling-evidence.md 保留完整官方引用与证据说明，scripts/blog-ai-crawling/ 保留可复跑示例。