Scrapling：面向结构漂移站点的抓取框架

网站改版是抓取脚本最隐蔽的敌人。昨天还能用的 CSS 路径，今天可能因为一个 div 包装层失效。Scrapling 想解决的不是“抓取本身有多难”，而是“脚本为什么这么容易坏”。

它自称 Web Scraping framework，但更准确的定位是：把请求、解析、爬取、导出和 AI 接入放进同一个 Python 库里。仓库 README 给出的场景从单页抓取到整站 Markdown 语料生成，跨度很大。

站内简介把它归到 MCP 协议主题，说明这个项目在当前 AI 工具链里找到了位置。但 MCP 只是它的一个出口，不是全部。真正值得看的，是它如何处理页面结构漂移，以及它把浏览器自动化和 HTTP 请求塞进同一套会话抽象后，开发者要承担什么代价。

自适应解析：用相似度算法对抗 DOM 漂移

Scrapling 的解析层提供 CSS、XPath、文本和正则搜索。这些不是差异点。差异点在于它宣称的 Smart Element Tracking 和相似元素匹配。

当一个元素因为页面改版而失配时，框架会尝试用相似度算法在 DOM 里重新定位它。README 没有披露算法细节，只提到“intelligent similarity algorithms”。这意味着它的准确性取决于相似度阈值和页面改动幅度。

这种机制的价值是减少人工干预。代价是引入了不确定性：你无法百分之百确定抓回来的元素就是原来那个。对于价格、库存这类强一致性数据，自动重定位可能带来静默错误。对于新闻标题、商品描述这类容错场景，这个代价可以接受。

把自适应能力放在解析层而不是请求层，是它的一个有意思的设计判断。很多库把自适应理解为重试或换代理，Scrapling 把自适应理解为“选择器失效后还能找到目标”。这更接近抓取脚本的真实痛点。

会话抽象：HTTP 与浏览器共用一套入口

Fetcher 负责快速 HTTP 请求，StealthyFetcher 负责无头浏览器自动化。它们各自都有 Session 版本，可以保持 cookie 和状态。

这种双轨设计的实际效果是：开发者可以在同一个 Spider 里，让大部分请求走 HTTP，只把需要渲染或过盾的请求路由到浏览器。README 里明确写到“route requests to different sessions by ID”，说明这是它有意支持的工作方式。

ProxyRotator 可以跨会话类型工作，支持 cyclic 或自定义轮换策略。DNS-over-HTTPS 可以防止代理场景下的 DNS 泄漏。这些细节说明它假设用户会面对反爬，而不是只抓友好站点。

浏览器会话还有一个值得注意的设计：background API capture。开启 record_requests 后，你可以在页面加载完后，搜索浏览器捕获到的后台 API 响应。这比直接解析 DOM 更稳定，因为它绕过了前端渲染层。代价是内存占用和响应体存储边界，README 只说了“history is bounded”，没有给出具体上限。

Spider 层：给 Scrapy 用户一个迁移理由

Scrapy-like API 是它降低迁移成本的手段。start_urls、async parse 回调、Request/Response 对象，这些命名直接对标 Scrapy。它还提供了 scrapling_response 装饰器，让现有 Scrapy 项目可以复用 Scrapling 的解析器。

这种兼容策略很务实。Scrapy 用户不需要重写整个爬虫，只需要在解析环节切入。但要注意，这个装饰器只解决解析问题，不解决请求和调度问题。如果你想要并发、代理轮换、AutoThrottle，还是得用 Scrapling 自己的 Spider 类。

AutoThrottle 的机制值得单独说。它会根据目标站点的响应速度自动调整每个域名的延迟。当站点开始限流或封禁时，延迟翻倍或等待 Retry-After 指定的时间；站点恢复后，延迟再降回来。这与 Scrapy 的 AutoThrottle 思路一致，但 Scrapling 把它和 blocked request detection 绑在一起，增加了自动重试逻辑。

开发模式是一个被低估的功能。第一次运行时把响应缓存到磁盘，之后重放缓存来迭代 parse 逻辑。这解决了“调试解析器时反复打目标站点”的问题，也降低了被目标站点标记的风险。代价是缓存可能过期，你需要接受开发环境与生产环境的数据差异。

MCP 与 Agent Skill：AI 是入口，不是核心

MCP server 让 Claude、Cursor 这类 AI 工具可以调用 Scrapling 抓取页面、执行浏览器操作、截图、搜索后台 API 响应。README 提到它会减少发给模型的内容量、屏蔽广告、防护 prompt injection。

这些防护措施说明作者清楚一个风险：把网页内容直接塞给 LLM，可能触发提示注入。降低内容量和屏蔽广告，既是为了省钱，也是为了减少攻击面。

Agent Skill 则走另一条路：它教编码代理如何正确使用这个库的当前 API，而不是让模型凭记忆猜。这在 API 快速迭代的项目里很实际。很多 AI 生成代码的问题不是逻辑错误，而是用了过时参数。

RAG-ready Markdown 是第三个 AI 相关能力。page.markdown() 可以把页面转成干净的 Markdown，ContentSpider 可以整站爬取并生成 Markdown 语料。这个过程没有 LLM 参与，说明它把“准备语料”和“使用语料”分开了。这个分层是合理的，因为抓取阶段引入 LLM 会增加成本和不确定性。

边界与判断

Scrapling 的野心很大：HTTP、浏览器、爬虫、CLI、MCP、Docker 镜像都在一个库里。这种全包策略的代价是依赖复杂度和维护成本。浏览器自动化依赖 Playwright，反爬绕过依赖指纹模拟和 Cloudflare 处理，这些都不是稳定接口，随时可能因上游更新而失效。

92% 测试覆盖率只能覆盖库内部逻辑，覆盖不了目标站点的反爬变化。Cloudflare 或 Akamai 的策略调整，可能让 StealthyFetcher 的某些能力短期内失效。这是所有反爬库的共同风险，Scrapling 没有例外。

另一个边界是自适应解析的静默失败问题。Smart Element Tracking 在失配时重新定位元素，但文档没有说明它如何报告重定位结果。如果开发者不检查，可能拿到错误数据而不自知。对于金融、医疗等场景，这种不确定性不可接受。

它适合的场景很明确：抓取结构频繁变动的内容型站点，或者需要把抓取结果直接喂给 AI 工作流的团队。它不适合的场景也很明确：对数据准确性有硬性要求的业务，或者没有精力维护浏览器依赖的小项目。

如果你正在维护一个因站点改版而频繁报错的抓取脚本，值得拿 Scrapling 的自适应解析和开发模式做一次对照实验。如果你只需要稳定的单页解析，直接用它做替代品前，先评估一下自己是否真的需要它带来的那套浏览器和爬虫依赖。