OpenClaw 永久免费的提取任何网页的终极方案

用 AI 写文章，最大的隐藏成本不是模型调用次数，而是每次抓网页时塞进去的 token。今天做了一次完整的实测，对比了 Jina、Scrapling、web_fetch 三个方案------发现差别大到出乎意料。

问题是怎么暴露的

在用 AI 做内容创作时，流程大概是这样的：找到一篇参考文章 → 读取全文 → AI 消化后写稿。

web_fetch 是最直接的工具，给一个 URL 就返回内容。但用着用着发现不对：

一篇普通技术博客，轻松返回 8000-15000 token
遇到 GitHub README 或文档页，可能更多
一篇文章采集 3-5 个信息源，光读内容就烧掉几万 token

更麻烦的是，web_fetch 返回的是整个页面，包括：导航栏、侧边栏、页脚、广告、"相关推荐"......真正有用的正文可能只占 30%。

三个方案的实测对比

拿了一篇 Substack 文章做测试：《How I Dropped Our Production Database》，同条件（max 12000字符）横向对比三种提取方式。

方案一：Jina Reader

用法：

ini 复制代码

web_fetch("https://r.jina.ai/原始URL", maxChars=30000)

Jina 是专门做网页内容提取的服务，会自动渲染页面、抽取正文、去掉导航和广告，返回干净的 Markdown。

实测效果：

markdown 复制代码

Title: How I Dropped Our Production Database and Now Pay 10% More for AWS

I'm working on expanding the [AI Shipping Labs website](https://aishippinglabs.com/) ...

My gradual plan was:

1.   Move the current static site from GitHub Pages to AWS S3
2.   Move DNS to AWS so the domain is fully managed there
...

标题、正文、链接、图片、列表------格式全保留，干净利落。速度约 1.4 秒。

**缺点：每天免费限额 200 次。**高产时期两三天就能跑完。

方案二：web_fetch 直接抓

ini 复制代码

web_fetch(url, maxChars=30000)

测试同一篇文章------直接报错：fetch failed。

Substack 有反爬机制，web_fetch 根本进不去。对于 Medium、部分付费博客、微信公众号，同样的问题。

即使是能抓到的页面，返回的也是全页 HTML 转 Markdown，噪音多、token 浪费严重。

结论：只适合静态页面（GitHub README、普通技术博客），不适合有反爬的主流平台。

方案三：Scrapling + html2text

Scrapling 是一个开源 Python 爬虫框架（GitHub: D4Vinci/Scrapling），项目定位是"为现代 Web 设计的自适应爬虫"。核心特性：

原生绕过反爬：StealthyFetcher 能绕过 Cloudflare Turnstile 等主流反爬系统，不需要额外配置
自适应选择器：网站改版导致 selector 失效时，能自动重新定位元素，不需要手动维护
零依赖启动 ：pip install scrapling，没有复杂的浏览器驱动配置

用法：

bash 复制代码

python3 scrapling_fetch.py <url> 30000

脚本逻辑：

用 Fetcher.get() 拿到页面 HTML
按优先级尝试正文选择器：article → main → .post-content → [class*="body"]
找到正文后，用 html2text 把 HTML 转成 Markdown
截断到指定字符数

实测效果：

markdown 复制代码

# How I Dropped Our Production Database and Now Pay 10% More for AWS

### A Terraform command executed by an AI agent wiped the production infrastructure...

I'm working on expanding the [AI Shipping Labs website](https://aishippinglabs.com/) ...

1. Move the current static site from GitHub Pages to AWS S3
2. Move DNS to AWS so the domain is fully managed there
...

和 Jina 几乎一样干净，标题层级、链接、图片 URL、列表都保留了。速度约 3 秒，无限制，不需要 API Key。

意外发现：微信公众号文章

测试微信公众号链接（mp.weixin.qq.com）时：

Jina → 直接 403 拦截，内容为空
web_fetch → 请求被中断
Scrapling → 完整拿到正文，Markdown 格式，图片链接也保留

微信公众号有专门的反爬，Jina 和 web_fetch 都进不去，但 Scrapling 的 StealthyFetcher 能绕过去。

这个发现意义很大------之前我们读公众号文章要么靠搜索工具（只能拿摘要），要么靠浏览器渲染（慢且复杂），现在一行命令就能拿全文。

微信公众号文章：Scrapling 直接能拿全文，Jina 403，这一条就值得把 Scrapling 装上。

最终推荐策略

经过实测，确定了这套分级策略：

优先级	方案	适用场景	限制
1	Jina Reader	大部分英文博客、Substack、Medium	200次/天
2	Scrapling	Jina 超限、微信公众号、反爬平台	无限制
3	web_fetch	静态页面、GitHub、技术文档	全页噪音多
4	Browser Firefox	需要登录态、极端反爬	最慢

域名快捷路由： mp.weixin.qq.com 直接用 Scrapling，跳过 Jina，不浪费配额。

关于 maxChars： 统一设 30000，既保证完整正文，又不会塞爆 context。

坑：Scrapling 必须配合 html2text

最开始用 Scrapling 时，直接调 get_all_text() 提取文本，以为可以省事。结果发现：

erlang 复制代码

How I Dropped Our Production Database and Now Pay 10% More for AWS A Terraform command executed by an AI agent wiped the production infrastructure...

纯文字流，段落消失，链接消失，图片消失，标题层级消失。对 AI 写稿来说，链接和图片 URL 都是有价值的素材------引用图片、追溯信息源都要用。

正确做法是先拿 html_content，再用 html2text 转换：

python 复制代码

import html2text
h = html2text.HTML2Text()
h.ignore_links = False
h.ignore_images = False
h.body_width = 0  # 不自动折行
md = h.handle(element.html_content)

这一步加上去，输出就和 Jina 一样干净了。

总结

Jina：最好用，格式最干净，但每天 200 次限额
Scrapling + html2text：效果和 Jina 相当，无限制，能读微信公众号（Jina 做不到）
web_fetch：有反爬的平台直接失败，只适合静态页面
maxChars 统一设 30000：省 token 的同时保留完整正文
微信公众号直接走 Scrapling，不要浪费 Jina 配额

三个工具不是竞争关系，是互补关系。组合起来用，覆盖 99% 的内容提取场景。

🦞 获取完整 Skill 文件

关注公众号「石臻说AI」，回复「scrapling」获取本文完整的 OpenClaw Skill 配置文件和 scrapling_fetch.py 脚本。

进群交流：回复「进群」加入小龙虾养殖交流群，和更多 OpenClaw 用户一起折腾 AI 自动化。

参考链接

Scrapling GitHub：github.com/D4Vinci/Scr...
Jina Reader 文档：jina.ai/reader
html2text PyPI：pypi.org/project/htm...