Scrapling：整合抓取、解析与智能体接入

Scrapling 想把网页采集里几件经常分开做的事接起来：发 HTTP 请求、启动浏览器、解析页面、调度爬虫，再把结果交给文件或 AI Agent。它是 Python 框架，前端开发者可以把它理解成一套围绕网页数据采集组织起来的工具箱。

这份 README 最值得看的，是它如何处理从单页脚本走向持续采集时的工程问题：会话怎么复用、动态页面怎么抓、任务怎么恢复。至于「轻松绕过验证码」「性能领先」等宣传，原文提供的证据还不足以直接下结论。

抓网页，先判断是否需要浏览器

Scrapling 把获取页面分成了两条路径。

普通页面可以用 Fetcher.get()，需要复用 Cookie 和状态时用 FetcherSession。它支持通过 impersonate='chrome' 模拟 Chrome 的 TLS 指纹，也支持 HTTP/3。这里的指纹，指的是连接握手等环节呈现出来的客户端特征，不只是改一个 User-Agent。

依赖 JavaScript 渲染或需要页面交互时，则使用 StealthyFetcher、StealthySession，异步场景还有 AsyncStealthySession。浏览器路径支持 Playwright 的 Chromium 和 Google Chrome，可以通过 cdp_url 连接已有浏览器，也能用 executable_path 指定 Chromium。

这个划分有实际价值：同一个采集任务里，静态页面和动态页面未必需要同样的获取成本。原文的多会话示例用 sid="fast" 和 sid="stealth" 分流请求，并用 lazy=True 延迟初始化浏览器会话。

对熟悉前端网络面板的人，更有用的可能是后台接口捕获。浏览器会话开启 record_requests=True 后，可以用 session.network.search(limit=None) 搜索已保存的响应，读取接口数据和 HTTP 错误，无须再次发送请求。记录会保存文本响应体，但历史有容量限制；limit=None 不代表无限保存。

如果列表数据已经出现在接口响应里，这条路径可能比继续分析 DOM 更直接。

从脚本走向爬虫，难点在任务如何运行

单页提取的核心通常只是请求加选择器。页面数量增加后，才会遇到并发、限速、重试和中断恢复。

下面这段原文代码展示了分页采集：每页产出名言和作者，再跟随下一页链接，最后导出 JSON。

from scrapling.spiders import Spider, Response

class QuotesSpider(Spider):
    name = "quotes"
    start_urls = ["https://quotes.toscrape.com/"]
    concurrent_requests = 10
    
    async def parse(self, response: Response):
        for quote in response.css('.quote'):
            yield {
                "text": quote.css('.text::text').get(),
                "author": quote.css('.author::text').get(),
            }
            
        next_page = response.css('.next a')
        if next_page:
            yield response.follow(next_page[0].attrib['href'])

result = QuotesSpider().start()
print(f"Scraped {len(result.items)} quotes")
result.items.to_json("quotes.json")

要留意 concurrent_requests = 10：这是示例配置，不是适用于所有网站的推荐并发值。原文另一个只抓首页的示例输出 10 条，不能把这个结果套到会继续翻页的版本上。

Scrapling 提供按域名限速、下载延迟和 AutoThrottle。后者会根据网站响应速度调整延迟；遇到封锁或限流时，将延迟翻倍，或者按 Retry-After 等待，情况恢复后再提速。它让调度器参与处理负载变化，减少手工猜延迟的工作。

长任务可以用 QuotesSpider(crawldir="./crawl_data").start() 保存检查点。设置 crawldir 后，按 Ctrl+C 会保存待处理请求和已见 URL，再用同一目录启动即可恢复。

恢复请求队列，不等于已经保存采集结果。

原文明确要求单独保存条目。需要边采边消费时，可以通过 async for item in spider.stream() 获取数据；内置导出支持 JSON、JSONL、CSV、XML。

调试阶段还有一个实用设计：首次运行将响应缓存到磁盘，后续重放响应来修改 parse()，避免每改一次字段提取逻辑就重新访问网站。可选的 robots_txt_obey 则负责遵守 Disallow、Crawl-delay 和 Request-rate。

接上 AI 之前，先把提取和安装弄清楚

Scrapling 的解析器支持 CSS、XPath、文本和正则搜索，也提供类似 BeautifulSoup 的查找方式。已有 HTML 可以直接交给 Selector("<html>...</html>")，不必连同抓取模块一起使用。

作者还强调两种能力：页面变化后，通过相似度算法重新定位元素；根据已找到的元素查找相似元素。这有望缓解选择器随页面改版失效的问题，但原文没有展示具体改版案例，也没有给出误匹配率。

AI 接入分为两层。MCP server 让 Agent 调用 HTTP 请求、浏览器操作、截图、登录状态和后台响应；Agent Skill 则教编码 Agent 使用库的当前 API，减少凭空猜接口。

另一条路线更简单：用 page.markdown() 把页面转换成清理后的 Markdown，或通过 ContentSpider 把整站整理成语料。这一步不需要 LLM 参与。对文档采集任务，可以先用确定的提取流程准备内容，再决定哪些环节需要模型。

只想从终端提取内容，原文给出了这些命令：

scrapling extract get 'https://quotes.toscrape.com/' quotes.md
scrapling extract get 'https://quotes.toscrape.com/' quotes.txt --css-selector '.quote' --impersonate 'chrome'
scrapling extract fetch 'https://quotes.toscrape.com/js/' quotes.md --css-selector '.quote' --wait-selector '.quote' --no-headless
scrapling extract fetch 'https://nopecha.com/demo/cloudflare' captchas.html --css-selector '#padded_content a' --solve-cloudflare

重点看第三行的 --wait-selector '.quote'：动态页面需要等目标元素出现，不能只凭导航完成就开始提取。CLI 还提供 --ai-targeted，用于选择并清理正文内容。

安装有个容易踩的坑。要求是 Python 3.10 或更高版本，但 pip install scrapling 只安装解析器。直接导入 scrapling.fetchers 或 scrapling.spiders 会触发 ModuleNotFoundError。获取页面和运行爬虫需要先执行 pip install "scrapling[fetchers]"，再执行 scrapling install 安装浏览器及相关依赖；强制重装用 scrapling install --force。交互式 shell 则对应 pip install "scrapling[shell]" 和 scrapling shell。

我的判断

我更认可它对采集流程的整合。会话、调度、解析、导出能接在一起，确实比每个项目重新拼装省事。已有 Scrapy 项目也不必直接迁移：原文提供 scrapling_response 装饰器，可以只接入解析器。

但整合程度高，不代表每个项目都需要整套框架。只提取静态 HTML，可以先用解析器；已有成熟浏览器脚本，也要比较迁移收益。原文没有提供这些方案之间的维护成本对照，不能据此判断谁更省时间。

性能部分同样要收住结论。作者称基准取自 100+ 次运行的平均值，包含 5000 个嵌套元素的文本提取测试，还宣称 JSON 序列化比标准库快 10 倍。但输入材料没有具体成绩、环境和完整比较表，解析速度也不能代表整个爬虫的吞吐量。

92% 测试覆盖率、完整类型提示，以及每次变更运行 PyRight、MyPy，是工程质量信号；作者所称过去一年有数百名采集开发者日常使用，也只是项目方陈述，并非独立验证。

对验证码和防护绕过的宣传，更不能当作稳定承诺。solve_cloudflare=True 是功能开关，原文没有给出成功率、失败条件或长期测试数据。MCP 所称的 Prompt-Injection 防护也缺少机制说明。

这份 README 展示了功能范围，尚未证明它在你的目标网站上可靠。

能拿来做什么

• 做动态页面采集时，先检查所需数据是否已经出现在后台接口中，再选择 HTTP、浏览器渲染或后台响应捕获，避免只围着 DOM 写选择器。
• 准备文档检索语料时，可以先验证 page.markdown() 或 ContentSpider 的输出质量，检查代码块、导航噪声和正文是否完整，再接入后续检索流程。
• 编写持续运行的采集任务时，把 crawldir、结果持久化和限速一起设计；中断后既要能续跑，也要能确认哪些条目已经落盘。
• 让 AI Agent 编写 Scrapling 代码时，可以参考配套 Agent Skill，同时核对依赖安装和实际 API；先用少量页面验证提取结果，再扩大采集范围。