自愈爬虫工具PyScrappy上线，但我更看好它背后的MCP重构时机

这篇文章最有价值的信息是，PyScrappy这个自愈式爬虫工具选在MCP协议无状态重构之后发布，时机比工具本身更值得琢磨。它直接把网站变成LLM-ready结构化数据，可以用Python库方式调用，也能作为MCP工具暴露给AI Agent。上周二我帮客户做技术尽调，正好在Hacker News上刷到这个项目，顺手跑了一下。

先说使用体验。我拿了一两个信息架构比较乱的行业站点试了试，自愈机制确实能处理页面上经常变动的结构和反爬策略调整。解析失败会自动重试，不用人工干预，数据清洗后出来的结构还算干净。但说实话，这个功能本身不新，CrawlForge、purify这些工具早就做了类似的事，PyScrappy的差异化在于它把MCP协议作为一等公民，Agent可以直接调用。

这就要说到我这边测下来，最有意思的一个观察了。八月初我关注到Anthropic对MCP做了史上最大规模的重构，从有状态全面转向无状态，initialize握手整个过程都被移除了。当时很多人把这个当成技术细节，觉得只是传输层精简。但放在PyScrappy这个项目里看，这种架构变化的真正含义就显现出来了。无状态之后，MCP工具的接入成本大幅下降，Agent调用外部工具就像调用函数一样轻量，整个生态的开发者门槛是在系统性降低的。

短期看，PyScrappy这类工具解决的是AI Agent吃数据的最后一公里问题。去年这时候，我帮一个客户搭知识库，光是清洗网页数据就占掉整个项目的六成工时。那时候做爬虫是写死规则，每换一个目标站点就是一轮新开发。自愈爬虫把这一块的边际成本压下来了，对大模型应用落地是个实打实的基建红利。不过短期维度上，我觉得有个坑得提一句，无状态协议本身是有代价的。之前的MCP有会话ID，能保存状态，长连接管理在复杂流程里更方便。换到无状态，每次请求都要重新建立上下文，对一次性抓取是好事，但对那些需要多轮交互的Agent任务，我测下来延迟反而上去了。

长期看，真正值得关注的其实不是爬虫工具本身，而是MCP协议重构之后，工具生态会往哪个方向走。从2024年底Anthropic推出MCP到现在，这个协议一直在快速演进，现在又走到无状态的拐点。这一点很像当年Unix管道设计哲学在AI时代的回归，工具的组装逻辑变简单了，但组装出来的东西可以更复杂。我上周写过一篇关于GuidedReview的帖子，当时就提到AI生成代码的审查工具接入方式很重要，现在看其实整个AI工具链都在往同一个方向收敛，用MCP统一入口，各干各的活。

不过作为咨询顾问，我还是得说一句，这个赛道的问题不在技术，在市场格局。PyScrappy面对的局面很像三年前的RPA市场，工具能力趋同，真正的壁垒不在爬虫本身，而在调度稳定性和规模化的运维能力。刚看到一个数据，Anthropic重构MCP也就是这两周的事，GitHub上相关工具的数量涨得很快，但大部分都是浅层封装。能在无状态协议下把数据质量做稳定的厂商，才有资格谈长期。

另外我想提醒一点，这类工具在国内落地还有个本地化问题。海外站点的反爬压力相对温和，国内不少数据源在合规层面有更多约束，技术能做和业务能跑是两回事。这个判断不一定对，但我在项目里踩过类似的坑，还是值得拿出来说。

最后用一句话总结，PyScrappy让我看到的，是AI Agent工具链正在从数据采集的粗放时代走向协议标准化的精细时代，谁能在无状态MCP的框架里把数据管道做得更稳，谁才是这场竞赛的赢家。

---

本文编译自 Hacker News，原文：GitHub - mldsveda/PyScrappy: Adaptive Python web scraping toolkit + MCP server for AI agents. Self-healing selectors that survive site changes, TLS-fingerprint stealth to bypass anti-bot filters, CSS/XPath parsing, and 24 built-in scrapers, clean, structured, LLM-ready data from any URL. · GitHub
版权归原作者所有，本文为基于公开报道的编译与独立分析。