> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# Scrapling MCP：告别Token浪费
- URL: https://www.hubwiz.com/blog/scrapling-mcp-say-goodbye-to-token-waste/
- Published: 2026-04-21T01:17:49.000Z
- Updated: 2026-10-13T16:17:09.000Z
- Description: 页面有 50,000 个 token。我们想要的内容只有 200 个。模型做了 99% 的苦力活来获取我们要求的 1%。
- Author: admin
- Tags: MCP, SCRAPLING, #Import 2026-10-14 14:41

我们的 agent 请求一个产品价格，却收到了 50,000 个 token 的 HTML，而实际需要提取的内容只有 200 个 token。Scrapling 的 MCP 服务器在服务端提取内容，其自适应解析器在网站更改标记时仍能继续工作。

这是大多数 agent 构建者直到账单到来时才会注意到的一个条目。每次我们的 agent 获取网页时，我们都在以前沿模型的价格来解析 HTML。

页面有 50,000 个 token。我们想要的内容只有 200 个。模型做了 99% 的苦力活来获取我们要求的 1%。

将这个数字乘以每个用户的每一天中每个推理循环中的每次工具调用，就变成了真正的钱，而且这完全是可避免的。

> *之前*

[Scrapling](https://github.com/D4Vinci/Scrapling?ref=hubwiz.com) 是使这成为默认模式的 Python 库。它内置了 MCP 服务器，因此 Claude Desktop、Cursor 和任何其他兼容 MCP 的客户端都可以将其作为原生工具调用。

我们的 agent 使用 CSS 选择器请求特定数据，Scrapling 在服务端获取并提取，LLM 得到干净的结构化响应，通常是 500 个 token 而不是 50,000 个。

以 Claude Opus 的价格计算，这大约是**每次检索 $0.008 而不是 $0.75**。对于一个会话中执行 100 次检索的 agent，这两个数字之间的差异决定了这个功能能否上线。

## 1、MCP 配置

在 Claude Desktop 配置中添加一个块：

```
{
  "mcpServers": {
    "scrapling": {
      "command": "scrapling",
      "args": ["mcp"]
    }
  }
}

```

重启 Claude Desktop，agent 就拥有了抓取作为原生工具。服务器暴露了九个工具，但对于 agent 工作流来说重要的四个是：

- **`get`**：带有浏览器指纹伪装的快速 HTTP 获取
- **`bulk_get`**：跨多个 URL 的并发请求
- **`fetch`**：用于阻止普通 HTTP 的网站的隐身浏览器
- **`bulk_fetch`**：并发浏览器请求

这四个工具都在内部处理 Cloudflare Turnstile 和其他反机器人系统，并且都接受 CSS 选择器。

> agent 请求特定数据（"获取每个产品卡片的价格和名称"），Scrapling 只返回该数据，LLM 永远不会处理原始 HTML。

## 2、为什么成本节省是持久的

手工编写的 CSS 提取抓取器的问题在于，一旦网站更改了标记，它们就会失效。

类名变了，div 结构变了，我们的 agent 静默地什么也不返回。这就是为什么大多数团队放弃并直接将整个页面交给 LLM——这比维护选择器更省事。

Scrapling 的自适应解析器通过在首次抓取时对元素进行指纹识别来解决这个问题：它们的文本内容、属性、在 DOM 中的位置。

在后续运行中，如果选择器失败，它会搜索页面中匹配该指纹的元素，通常能重新定位到它们。

一行代码即可启用：

```
from scrapling.fetchers import StealthyFetcher

StealthyFetcher.adaptive = True
page = StealthyFetcher.fetch('https://example.com')
products = page.css('.product', auto_save=True)

```

`auto_save=True` 对匹配的元素进行指纹识别。

之后，当网站发布 A/B 测试并且我们的选择器失效时，解析器会悄悄地找到产品。

这就是使成本节省持久化的原因。没有自适应重定位，我们能节省一周的 token，然后把节省的时间花在调试损坏的抓取器上。

有了它，模式在网站变更后仍然有效，这是经济学在生产环境中唯一可行的方式。

## 3、适用场景和不适用场景

当我们的 agent 以大规模从已知页面类型提取**结构化数据**时，Scrapling 是正确的选择。

产品页面、文档网站、列表页面，任何我们知道自己在找什么的地方。CSS 选择器模式在这里表现出色，因为我们可以精确描述提取。

> **探索性浏览**

与最接近的替代方案相比：**Firecrawl** 是这个的托管管理服务版本，URL 到干净的 markdown，他们的 MCP 服务器，他们的定价。当我们想外包基础设施并按 URL 付费时很好。

Scrapling 在大规模和提取控制方面胜出。

**原始 Playwright** 是如果我们想要完全控制并愿意自己构建自适应解析器、反机器人层、爬虫框架和 MCP 服务器时会使用的。

Scrapling 就是那个已经组装好的栈，这正是"面向 agent 的生产级网页抓取"实际上所需要的大部分内容。

## 4、诚实的局限性

该库主要由一个人维护。

> 对于依赖持续维护的生产部署，这是一个真实的巴士因子问题。

> 它是 BSD-3-Clause 许可的，所以如果需要我们可以分叉，但"可以分叉"和"不需要分叉"是不同的。

> 自适应解析器处理增量网站变更（类重命名、div 重构、A/B 测试），但不处理全面重设计。

重大的结构性重写仍然会破坏匹配。

我们会偶尔更新选择器；其价值在于我们偶尔更新而不是每周更新。

基于浏览器的抓取器需要单独的安装步骤（`scrapling install`），下载 Chromium 和系统依赖——在小容器中有显著的开销。

通常的注意事项也适用：尊重 robots.txt，阅读服务条款，不要使用反机器人绕过来规避明确禁止抓取的网站上的保护。

反机器人功能的存在是因为机器人检测经常阻止合法的研究和可访问性工具——而不是为了启用滥用。

> 对于构建以任何实际规模与网络交互的 agent 的团队来说，"将原始 HTML 交给 LLM"模式之所以是默认的，是因为它是最容易的集成方式，而不是因为这是个好主意。

Scrapling 的 MCP 服务器使更好的模式几乎同样简单。自适应解析器是使其持续工作足够长时间以真正发挥作用的关键。

---

原文链接: [Scrapling: Stop Paying Claude to Read HTML](https://medium.com/@pankaj%5Fpandey/scrapling-stop-paying-claude-to-read-html-a44c7a471e9c?ref=hubwiz.com)

汇智网翻译整理，转载请标明出处

> **这是「RAG / 数据 / 文档智能」专题的一部分。**完整地图见：[RAG / 数据 / 文档智能完全指南](https://www.hubwiz.com/blog/rag-data-stack/)