Agent 的手和眼：Web 爬虫工具全景

一、Web 数据获取的完整链路

今天来聊聊 Web 数据获取，也就是俗称的“爬虫”。在 AI Agent 时代，让大模型长出“眼睛”去看互联网、长出“手”去操作网页，已经不是锦上添花，而是刚需。

1.1 核心理念：从“找到”到“拿到”再到“结构化”

Web 数据获取并不是调用一个单一的 API 那么简单，它的完整链路包含三个截然不同的阶段：

阶段一：Search（搜索） — 找到相关内容的入口

目标：从海量网页中找到与你需求相关的 URL 列表 输入：自然语言查询，如“最新 AI 框架对比” 输出：结构化的搜索结果（标题、摘要、URL） 本质：这不是“爬取”，而是“发现”。你不需要解析 HTML，而是依赖已经建好索引的搜索引擎。 代表工具：Tavily、Brave Search、Perplexity、Exa、SerpAPI、DuckDuckGo

阶段二：Fetch（抓取） — 拿到网页的原始内容

目标：根据 URL 获取网页的完整 HTML/渲染后内容 输入：URL 输出：网页的原始内容（HTML 或渲染后的 DOM） 本质：这是真正的“抓取”环节。你需要应对各种反爬虫机制。 代表工具：Playwright、Firecrawl、Scrapling、Crawl4AI

阶段三：Extract（提取） — 结构化、清洗、输出可用格式

目标：从原始 HTML 中提取有用的信息，转换为 LLM 可直接消费的格式 输入：HTML 或 DOM 输出：Markdown、JSON、纯文本等结构化数据 本质：这是“数据清洗”环节。去除广告、导航、脚本，保留核心内容。 代表工具：Readability、Jina Reader、Crawl4AI

关键认知：完整的 Web 数据获取 = 这三个阶段的组合。不同工具在不同阶段有优势。

1.2 为什么需要这么多工具？

如果在 Github 上搜索爬虫，你会发现成百上千个项目。为什么不能一个工具打天下？

答案在于：Web 环境的复杂性和业务需求的多样性，导致根本没有“一刀切”的解决方案。

问题复杂度谱系

类型	说明
静态博客	无防护，直接 HTTP 即可
动态网站	轻度防护，需处理 JS
JS 渲染	中度防护
反爬虫	强防护
验证码	顶级防护

总成本谱系

方案	金钱成本	人力成本
API 服务（开箱即用）	高	低
开源框架（需维护选择器）	中等	中等
底层定制（需维护所有）	低	高

核心结论：选型的本质是做 Trade-off（权衡） ，在不同维度间找到最适合你场景的平衡点。

二、搜索：如何让 Agent 找到想要的信息？

2.1 这类工具解决什么问题？

当 Agent 需要“了解某个主题的最新信息”时，它面临的问题不是“如何解析 HTML”，而是 “如何找到相关的网页” 。

搜索类工具的本质：不是“爬虫”，而是搜索引擎的 API 化。 你调用它们的 API，它们返回已经索引好的结果： 输入：自然语言查询 输出：结构化搜索结果（标题、URL、摘要）

2.2 四种模式与 AI 原生搜索

四种技术模式（按数据来源分类）

模式	数据来源	代表工具	优缺点
代理调用	调用第三方搜索 API	SerpAPI、Serper	✅ 覆盖全 ❌ 依赖第三方、费用高
爬虫类	模拟浏览器解析搜索结果页	DuckDuckGo MCP、orz-mcp	✅ 完全免费 ❌ 稳定性无保障
自建索引	自己爬网页建倒排索引	Brave Search、DuckDuckGo	✅ 独立可控、隐私好 ❌ 覆盖面较小
AI 模型内置	模型内置搜索能力	OpenAI、Anthropic	✅ 无需配置 ❌ 仅限该模型生态
AI 原生工具

最近几年出现了一类“专为 AI 设计”的搜索工具，它们与传统搜索的核心区别：

特性	传统搜索	AI 原生搜索
优化目标	人类点击率	LLM 语义理解
返回格式	HTML 片段	结构化 JSON + Markdown
内容质量	包含广告、SEO 内容	清洗后的正文
深度提取	❌	✅ 自动提取完整页面
答案生成	❌	✅ 总结答案

核心能力：深度提取（Depth Extraction）

这是搜索工具最重要的区分点，直接影响 Agent 的使用体验：

• 没有深度提取：Agent 需要 search → 判断相关性 → fetch，三次交互
• 有深度提取：Agent 一次 advanced search 即可获取全部所需内容

2.3 主流工具对比

工具	模式	免费额度	付费价格	深度提取	Fetch	接口形式	限流	注册难度
Serper	代理调用	2,500 次（一次性）	1美元/1,000 次	❌	❌	REST, MCP	未明确	邮箱
SerpAPI	代理调用	250 次/月	25美元/1,000 次/月	❌	❌	REST	免费 50q/h	邮箱 + 手机
searchAPI	代理调用	100 次（一次性）	40美元/10,000 次	❌	❌	REST	免费 20q/h	邮箱 + 手机
DuckDuckGo	爬虫类	完全免费	-	❌	❌	REST	未明确	无需注册
Tavily	自建索引	1,000 次/月	8美元/1,000 次	✅	✅	REST, MCP	免费 1qps	邮箱
Exa	自建索引	匿名免费（不稳定）	7美元/1,000 次	✅	✅	REST, MCP	匿名 1qps	邮箱（可选）
Brave	自建索引	1,000 次/月（需信用卡）	5美元/1,000 次	✅	❌	REST, MCP	50qps	邮箱 + 信用卡
Perplexity	自建索引	无	5美元/1,000 次	✅	✅	REST, Builtin	3qps（付费）	邮箱 + 信用卡
火山引擎	自建索引	个人 500 次/月 企业 5,000 次	按调用计费	✅	✅	REST	未明确	实名认证
百度千帆	自建索引	1,000 次/天	按调用计费	✅	✅	REST	未明确	实名认证
Linkup	自建索引	1,000 次/月	5欧元/1,000 次	✅	✅	REST	10qps	邮箱
OpenAI	AI 模型内置	无	10美元/1,000 次	✅	✅	Builtin	-	-
Anthropic	AI 模型内置	无	10美元/1,000 次	✅	✅	Builtin	-	-

注：

• “深度提取” = 搜索后自动提取完整页面正文（Markdown 格式）
• “Fetch” = 工具提供独立的网页内容抓取能力
• 限流数据基于 2025 年实测，可能随服务政策变化

从夯到拉锐评

等级	工具	点评
夯	百度千帆、Exa	千帆每天 1000 次，Exa 匿名直接用
顶级	Tavily	注册就送 1000 次/月，深度提取开箱即用
人上人	Perplexity、Brave、Linkup	能力在线，但要么没免费额度，要么要绑信用卡，食之有味弃之可惜
NPC	DuckDuckGo MCP、火山引擎	中规中矩
拉	Serper、SerpAPI、searchAPI	代理转售，只转发搜索结果没有深度提取，免费额度用完还得掏钱

选好了搜索工具，拿到了 URL 列表，下一步就是抓取页面内容。但这一步远比想象中困难——你发出去的 HTTP 请求，很可能连真实的 HTML 都拿不到。

三、为什么网页越来越难爬？

目标：理解为什么简单的 curl 或 requests.get() 经常只能抓到 403 Forbidden 或要求验证的假页面。

3.1 现代网站的几道防线

防线	检测点	绕过方式	绕过难度
基础风控	User-Agent、IP 频率、Headers 完整性	代理池 + UA 伪装	容易
TLS 指纹	TLS ClientHello（JA3/JA4）	需要真实浏览器	中等
JS 挑战	混淆 JS 计算（Cloudflare 5 秒盾）	需要浏览器自动化	困难
验证码	reCAPTCHA、hCaptcha、Turnstile	打码平台 / AI 视觉	非常困难

TLS 指纹为什么绕不过？

TLS 指纹在 TLS 握手阶段生成，无法通过修改 HTTP Headers 伪装。Python requests、Node.js axios 的 TLS ClientHello 与真实浏览器不同，会被 Cloudflare 等系统直接拦截（JA3/JA4 覆盖率接近 100%）。

JS 挑战（Cloudflare 5 秒盾）

服务器返回混淆的 JS 代码，要求浏览器执行后返回正确答案。传统 HTTP 库没有 JS 引擎，会被卡在“Checking your browser...”验证页面。

验证码

这是最后一道防线，常见类型包括：

• reCAPTCHA v3：无感知，通过行为分析判断
• hCaptcha：需要选择图片中的物体
• Cloudflare Turnstile：声称“无摩擦”的新验证码

绕过方式：打码平台（付费）或 AI 视觉（成本高）。

3.2 传统 HTTP 抓取为什么不够用了

第 1 次：403 Forbidden。没事，加个 User-Agent 试试。
第 2 次：加了 UA，返回 200 了！一看内容——是假页面。没事，上 TLS 伪装。
第 3 次：TLS 过了，拿到 "Checking your browser..."——5 秒盾。没事，用 Playwright。
第 4 次：Playwright 等完了，弹出验证码。行吧，打扰了。

传统 HTTP 抓取的困境

import requests
response = requests.get("https://protected-site.com")

面对现代反爬虫，传统 HTTP 抓取已经不够用。你需要：

• 浏览器自动化：用真实浏览器执行 JS
• TLS 指纹伪装：使用专门的库修改 TLS 指纹
• 代理池：使用大量 IP 分散请求
• 验证码解决：付费服务或 AI 视觉

或者...使用托管服务，让别人帮你搞定这些脏活累活。

四、破防三板斧：HTTP、浏览器、托管服务

为了突破上述防线，爬虫领域的兵器谱演化出了三条截然不同的技术路线：HTTP 直接请求绕不开 JS 挑战和 TLS 指纹，浏览器自动化能扛住大部分防线，托管服务则把攻防压力交给专业团队。

4.1 三条路线，三种代价

特性	HTTP 直接请求	浏览器自动化	API 托管服务
原理	发 GET 请求，解析 HTML	控制真实浏览器渲染	委托给第三方处理
速度	极快（~100ms）	慢（1~3s+）	中等（0.5~2s）
破防能力	弱	较强	极强
资源占用	极低	高	无（第三方）
成本	免费	服务器成本	API 费用
运维复杂度	低	中等	低
适用场景	静态网站、无防护	动态网站、轻度防护	强防护、不想维护

4.2 路线一：HTTP 直接请求（轻量派）

原理：直接发起 HTTP GET 请求，不执行任何 JS，直接用正则或 DOM 树解析 HTML。

优缺点：

• 极快（几十毫秒）、资源占用极低
• 但遇到 JS 渲染页面直接抓瞎
• 极易被 TLS 指纹拦截

代表工具：Scrapy，BeautifulSoup，Readability

适用场景：静态内容为主，毫无防护的网站（如爬静态博客，维基百科）

代码示例（Readability） ：

Readability 是 Mozilla 开发的正文提取算法，能从杂乱的 HTML 中自动提取标题、正文、作者等核心信息，过滤导航、广告等噪音。

# 使用 Readability 自动提取正文
import requests
from readability import Document
​
# 获取网页内容
response = requests.get('http://example.com')
doc = Document(response.text)
​
# 提取信息
print("标题：", doc.title())
print("作者：", doc.author())
print("正文：", doc.summary())

4.3 路线二：浏览器自动化（重型装甲）

原理：通过 CDP（Chrome DevTools Protocol）协议，在内存里真实启动一个 Chrome（通常是 Headless 模式），让网页像在真实用户电脑上一样加载完 JS。

CDP 协议简介

CDP（Chrome DevTools Protocol）是 Chromium 内核原生提供的调试与通信协议，允许外部程序通过 WebSocket 或管道实现对浏览器的双向控制。现代自动化与爬虫工具（如 Playwright、Puppeteer、Crawl4AI）均深度基于此协议构建，而 Selenium 等传统工具也已引入对它的支持。

通过 CDP，我们不仅能实现自动化测试与前端性能监控（如获取 DOM、执行 JS、分析网络与内存），还能触达浏览器底层，完成高级爬虫操作（如拦截网络请求、绕过反爬、修改浏览器指纹等）。

代码示例（Playwright）

from playwright.sync_api import sync_playwright
​
with sync_playwright() as p:
    browser = p.chromium.launch(headless=True)
    page = browser.new_page()
    page.goto("https://example.com")
    print(page.title()) # 拿到的已经是 JS 执行后的 DOM
    browser.close()

优缺点：

• 所见即所得，能绕过绝大多数 JS 挑战
• 可以模拟各种指纹
• 但速度较慢（几秒到十几秒）
• CPU/内存资源消耗较大

代表工具：Playwright，Puppeteer，Selenium，Crawl4AI

适用场景：页面严重依赖 JS 动态渲染

4.4 路线三：API 托管服务（钞能力派）

原理：将 URL 通过 API 发给专门的商业公司，他们在云端维护庞大的浏览器集群、IP 代理池、打码 AI。你只管收干净的数据。

优缺点：

• 100% 开箱即用，免维护
• 但需要付费
• 且存在隐私和黑盒风险

代表工具：Firecrawl，Jina Reader，Apify，BrowserBase

适用场景：强反爬拦截，不想自己搞运维

代码示例（Firecrawl） ：

from firecrawl import Firecrawl
​
firecrawl = Firecrawl(api_key="your-api-key")
​
# 抓取单个页面
scrape_result = firecrawl.scrape('https://www.baidu.com/', formats=['markdown', 'html'])
print(scrape_result.markdown)

五、爬虫兵器谱：谁有什么绝活

本章按技术分层介绍工具，从底层引擎到上层服务逐层展开。每层工具解决不同的问题——引擎层提供浏览器自动化能力，增强层叠加反爬伪装和 AI 原生提取，服务层开箱即用。工具的本质差异 = 在哪一层解决问题。每个工具能覆盖 Search（搜索）、Fetch（抓取）、Extract（提取）中的哪些阶段，在对应小节有标注。

5.1 技术分层与攻防映射

防线	解法	引擎层	增强层	服务层
IP/UA 风控	代理池 + UA 伪装	Playwright、agent-browser	Scrapling、Crawl4AI	Jina Reader、Firecrawl
TLS 指纹	真实浏览器或 curl_cffi 伪装	Playwright（真实浏览器）	Scrapling（curl_cffi 指纹伪装）	Firecrawl（云端浏览器）
JS 挑战	浏览器执行 JS	Playwright、agent-browser	Scrapling（Patchright 自动处理）	Firecrawl
验证码	打码服务 / AI 视觉	—	—	—
网站改版	自适应重定位	—	Scrapling（SequenceMatcher）	—

说明：同一能力在不同层由不同技术实现。如 TLS 指纹，引擎层靠真实浏览器（Playwright/agent-browser 启动 Chrome），增强层靠协议伪装（Scrapling 用 curl_cffi 模拟 Chrome 的 TLS ClientHello），服务层靠云端基础设施（Firecrawl 维护浏览器集群）。

5.2 Playwright — 浏览器自动化的基石

定位：Microsoft 开发的浏览器自动化测试框架，已成为现代爬虫的基础设施。相比老牌工具 Selenium，Playwright 基于 CDP 协议，速度更快、稳定性更高，现代爬虫工具（如 Scrapling、Crawl4AI）均选择它作为底层引擎。

覆盖阶段：Fetch（抓取）· Extract（提取）

核心原理

0. CDP 协议层

Playwright 通过 CDP（Chrome DevTools Protocol）直接与浏览器进程通信，无独立驱动进程：

Selenium:  你的代码 → chromedriver.exe（独立进程，HTTP 协议）→ chrome.exe
Playwright: 你的代码（内含 client/server 层）← pipe/WebSocket → chrome.exe

优势：

• 少一个中间进程，通信路径更短
• 通过 pipe/ws 直连而非 HTTP，延迟更低
• 原生支持网络拦截、性能指标等底层能力

2. Browser-Context-Page 三级架构

Playwright 采用三级对象模型，实现灵活的会话隔离和资源管理：

Browser（浏览器进程）
  - 启动浏览器实例
  - 管理全局资源
  Context（会话上下文）
    - 独立 Cookie 和存储
    - 可创建多个隔离上下文
    - 模拟多用户场景
    Page（标签页）
      - 具体页面的交互
      - 导航、点击、输入等操作

设计优势：

• 会话隔离：每个 Context 有独立的 Cookie 和存储状态
• 资源复用：单个 Browser 可运行多个 Context
• 并发支持：可同时操作多个 Page

3. 关键设计

• 自动等待：所有操作（click/fill/navigate）执行前自动等元素可见、可操作、不被遮挡，无需手写 wait 逻辑。
• 存储状态管理：context.storageState() 一键保存/恢复 cookies + localStorage，跨次抓取保持登录态。
• 多上下文隔离：一个浏览器实例可开多个隔离 Context（独立 cookies/存储），并发爬取不同站点不串数据。
• Accessibility Tree：辅助功能树，浏览器的标准特性，从 DOM 提取语义化结构，关注元素的“角色”而非样式。例如 <button class="btn-primary"> → accessibility tree 中识别为“可点击的按钮”。Playwright 的 ariaSnapshot() 将 DOM 转换为结构化文本 + 元素引用（如 e15），比 CSS 选择器更稳定，是 AI Agent“看懂”页面的核心机制。

核心能力清单

0. 真实浏览器渲染 — 在真实浏览器环境（Chromium/Firefox/WebKit）中执行，自动处理 JS 渲染，获取完整页面内容。
1. 交互能力 — 支持点击、滚动、输入等用户操作，可处理动态加载内容（如懒加载、无限滚动）。
2. 存储管理 — 可管理浏览器存储状态（Cookie/LocalStorage），用于保持登录状态，避免重复登录。
3. 快照与元素引用 — 基于 Accessibility Tree，Playwright 生成结构化快照 + 元素引用，比 CSS 选择器更稳定。

Agent 接入 & 实操案例

方式 1：playwright-cli（推荐）

# 安装（--skills 将命令文档复制到 .claude/skills/，让 Agent 学会使用 CLI）
npm install -g @playwright/cli@latest
playwright-cli install --skills
​
# Agent 调用示例
playwright-cli open --headed --browser=chrome https://www.baidu.com
playwright-cli fill e23 "国内新闻"
playwright-cli click e25
playwright-cli screenshot
playwright-cli close

# 处理动态 JS 网页
playwright-cli open https://example.com

# 点击加载更多
playwright-cli click "button.load-more"
​
# 滚动到底部
playwright-cli eval "window.scrollTo(0, document.body.scrollHeight)"
​
# 填写表单
playwright-cli fill "input[name='email']" "user@example.com"

# 保存当前状态（包括 cookies）
playwright-cli state-save auth-state.json
​
# 加载已保存的状态
playwright-cli state-load auth-state.json

# 获取快照（包含元素引用）
playwright-cli snapshot
# 输出页面结构，每个元素有唯一引用
​
# 使用引用进行交互（推荐）
playwright-cli click e15
​
# 或使用 CSS 选择器（备用）
playwright-cli click "#submit-button"

方式 2：playwright-mcp

# Claude Code 配置
claude mcp add playwright npx @playwright/mcp@latest

局限性

问题	说明
❌ 没有反爬虫能力	不内置 Cloudflare 绕过、验证码解决等功能
⚠️ ref 在页面结构大改后可能失效	比传统 CSS 选择器稳定，但非零维护
💰 资源占用高	每个实例 200-500MB，不适合高并发场景
⏱️ 速度相对慢	需要等待 JS 渲染，比 HTTP 请求慢

结论：Playwright 是“引擎”，但不是“整车”。 适合动态 JS 渲染和交互场景，强反爬需配合 Scrapling/Firecrawl 等上层方案。

5.3 agent-browser — AI 原生的浏览器自动化 CLI

定位：纯 Rust 实现的浏览器 CLI，通过直接 CDP 协议操控 Chrome，为 AI Agent 提供轻量、快速的浏览器交互能力。

覆盖阶段：Fetch（抓取）

核心差异：Daemon 直接通过 CDP 协议操控 Chrome（不经过 Playwright 协议层），专为 AI Agent 设计了 Snapshot-Ref 交互模式和安全控制。

核心原理

agent-browser CLI（Rust 原生二进制）
    ↕ Unix Socket / TCP Socket
Daemon 进程（常驻，直接 CDP 连接 Chrome）
    ↕ CDP WebSocket
Chrome/Chromium

双进程模型：CLI 发命令，Daemon 常驻维持浏览器实例，避免每次命令重启浏览器 直接 CDP：不经过 Playwright 中间层，直接通过 CDP 通信 多后端：支持本地 Chrome、Browserless、Browserbase 等云端浏览器

核心工作流：Snapshot-Ref 模式

agent-browser 的核心交互模式是 snapshot → ref → act：

# 1. 打开页面
agent-browser open https://github.com/login
​
# 2. 获取可交互元素快照（带引用标记 @e1, @e2...）
agent-browser snapshot -i
​
# 3. 通过引用标记操作（无需 CSS 选择器）
agent-browser fill @e1 "username"
agent-browser fill @e2 "password"
agent-browser click @e3

与 Playwright CLI 的对比：

维度	Playwright CLI	agent-browser
启动开销	需加载 Node.js 运行时 + 模块	原生二进制，直接执行
浏览器通信	Playwright 协议层	直接 CDP
元素定位	CSS 选择器 / 文本 / Ref	Ref 引用标记 / 语义定位器 / CSS
快照格式	Accessibility Tree + Ref（e15）	Accessibility Tree + Ref（@e1）
安全控制	无内置	Action Policy、域白名单、内容边界

会话管理

支持三种会话持久化方式：命名会话（自动保存 cookies + localStorage）、持久化 Profile、手动状态文件。同时提供 AES-256-GCM 加密的认证保险库，一键保存和恢复登录凭证。

多步骤工作流

支持 Batch 模式：通过 JSON 数组顺序执行多条命令，避免逐条启动进程的开销。

echo '[  ["open", "https://example.com/login"],
  ["fill", "@e1", "user@test.com"],
  ["fill", "@e2", "password"],
  ["click", "@e3"],
  ["wait", "Dashboard"],
  ["screenshot", "result.png"]
]' | agent-browser batch --bail

语义定位器

用人类语言描述要操作的元素，而非 CSS 选择器。find 后面依次是：定位方式 → 操作 → 参数。例如 agent-browser find text "Sign In" click 即可点击"Sign In"按钮。

Agent 接入

npx skills add vercel-labs/agent-browser

局限性

局限	说明
❌ 不支持验证码自动解决	无内置验证码检测/破解，需人工介入或第三方服务
⚠️ 生态较新	491 commits，社区规模小于 Playwright
⚠️ 仅 Chrome/Chromium	移动端仅支持 iOS Simulator 中的 Safari

5.4 Scrapling — 不对抗，只融入：协议级伪装的爬虫框架

定位：在 Playwright 基础上，解决选择器脆弱性和 Cloudflare 绕过两大痛点的开源框架。

覆盖阶段：Fetch（抓取）· Extract（提取）

核心问题：比 Playwright 多了什么？

三大模块架构

Scrapling 的架构设计哲学是 “系统思维” ，将“被识别、被挑战、被封禁、DOM 改版”视为常态。

Scrapling Framework
  Fetcher（抓取器）    — 网络请求入口
  Selector（解析器）   — 自适应数据提取
  Storage（存储器）    — 元素特征持久化
  curl_cffi / Playwright / Patchright

四层体系

为应对不同场景，Scrapling 提供四层工具：

层级	名称	相当于	解决的核心问题
第 1 层	Fetcher	requests + BeautifulSoup	快速抓取静态内容
第 2 层	DynamicFetcher	Playwright	JS 渲染
第 3 层	StealthyFetcher	Playwright + 反爬虫伪装	Cloudflare 绕过
第 4 层	Spider	Scrapy	大规模任务调度

各层原理与特点：

• 第 1 层 Fetcher：纯 HTTP 请求，速度快（毫秒级），资源占用最低。适合静态网页、API 接口。
• 第 2 层 DynamicFetcher：启动 Playwright 浏览器，等待 JS 执行完成。适合 React/Vue 单页应用、懒加载、动态渲染。
• 第 3 层 StealthyFetcher：在 DynamicFetcher 基础上，从协议层"融入"真实环境。伪装 TLS 指纹、HTTP/2/3 协议特征、浏览器行为模式，专门针对 Cloudflare 等反爬虫保护。
• 第 4 层 Spider：完整爬虫框架，适合几百到几万页面的大规模任务。内置代理轮换（ProxyRotator 加权/随机策略）、并发控制（全局和单域名独立限制，自动检测 403/429/503 并重试）、流式抓取（async for item in spider.stream() 逐条返回，内存友好）、Session 路由（同一次爬取混合使用 Fast HTTP 和 Stealthy 浏览器，按规则自动切换）。

反检测原理

大多数反爬虫绕过方案是“猫鼠游戏”：网站加强检测 → 爬虫找到绕过方法 → 网站再次升级。这种方式本质上是对抗式的，需要持续维护。

Scrapling 的解法：从协议层“融入”真实环境——不是对抗，而是让爬虫请求看起来和真实用户一模一样。

核心差异：

• ❌ 传统：破解验证码、伪造 headers（对抗式）
• ✅ Scrapling：从协议层伪装成真实浏览器（融入式）

四个维度

维度	伪装内容	对应引擎
传输侧	TLS 指纹、HTTP2/3 协议特征	curl_cffi（第 1 层）、Patchright（第 3 层）
运行态	viewport、locale、时区等浏览器环境	Patchright（第 3 层）
行为模式	鼠标轨迹、滚动行为、操作间隔	Patchright（第 3 层）
挑战处理	Cloudflare JS 挑战自动等待通过	Patchright + solve_cloudflare=True（第 3 层）

JS 挑战本质可以看作这些都是服务器在“挑战”你：证明你是真实用户，不是机器人。

Cloudflare 的保护有多层：

第 1 层：TLS 指纹、HTTP 行为检测
    ↓
Scrapling 伪装得好，通过这一层
    ↓
第 2 层：JavaScript 挑战（PoW 计算题、环境检测）
    ↓
Scrapling 等待 JS 执行，自动通过
    ↓
第 3 层：真正的验证码（reCAPTCHA、hCaptcha）
    ↓
Scrapling 无法处理，需要打码服务

Scrapling 的策略：

• 主要依靠伪装避免触发：从协议层伪装成真实浏览器，大部分情况 Cloudflare 直接放行
• 能处理简单的 JS 挑战：如果触发了 JS 计算题或环境检测，会等待 JS 执行完成
• 不能处理真正的验证码：如果网站要求点“I'm not a robot”或选择图片，Scrapling 无能为力

代码示例

from scrapling.fetchers import StealthyFetcher, StealthySession
​
# Session（推荐，保持浏览器打开）
with StealthySession(headless=True, solve_cloudflare=True) as session:
    page = session.fetch('https://cloudflare-protected-site.com')
    data = page.css('.content').getall()

自适应解析

问题：网站改版后，传统 CSS 选择器失效。

Scrapling 的解法：通过相似度算法跟踪页面元素，自动重定位目标数据。

from scrapling import Fetcher
​
# 全局启用自适应
Fetcher.adaptive = True
page = Fetcher.get('https://example.com')
​
# 首次选择并保存
element = page.css('#p1', auto_save=True)
​
# 网站改版后，自动重定位
element = page.css('#p1', adaptive=True)

关键设计：

• 特征存储：默认 SQLite，可扩展为 Redis/Firebase
• 相似度算法：加权匹配（标签 > 属性 > 文本），无需 AI
• 持久化：元素特征跨爬取任务共享

适用场景

• 需要爬取频繁改版的网站
• 遇到 Cloudflare 保护
• 希望控制成本，可以接受一定维护工作

Agent 接入 & 实操案例

Scrapling 支持两种 Agent 接入方式：

方式 1：MCP 服务器。提供 6 个工具：get、bulk_get、fetch、bulk_fetch、stealthy_fetch、bulk_stealthy_fetch。

# 安装
pip install "scrapling[ai]"
scrapling install
​
# Claude Code 配置
claude mcp add ScraplingServer "$(which scrapling)" mcp

方式 2：Skill

clawhub install scrapling-official

Skill 包含了完整的文档内容，Agent 可以根据 skill 自动编写爬虫代码或执行 CLI 命令。

实操示例：抓取受保护的电商网站

以爱尔兰电商 www.arnotts.ie 为例，该网站有反爬虫保护：

抓取这个页面的所有产品名称和价格，
使用 stealthy_fetch： https://www.arnotts.ie/men/clothing/casual-shirts/

5.5 Crawl4AI — AI 原生爬虫框架

定位：专为 LLM、AI Agent 和数据管道设计的开源 Python 爬虫框架。

覆盖阶段：Fetch（抓取）· Extract（提取）

核心差异：这不是传统爬虫的简单升级，而是“AI 原生”设计理念的全新范式。

核心特性

专为 LLM 和 AI Agent 设计，输出格式直接适配 AI 消费：

• 多种分块策略：7 种可插拔策略，从固定长度到主题分割（TextTiling），适配 RAG 等不同场景
• Markdown 输出：自动过滤广告、导航栏等噪音
• LLM 驱动提取：用自然语言指令驱动数据提取
• 智能缓存：SQLite 缓存，重复抓取大幅提速

技术架构

核心设计：策略驱动的异步爬虫框架。

AsyncWebCrawler（引擎）
    ↓ 策略层（可配置）
  ├── 爬取策略：Playwright（默认）/ HTTP（轻量级）
  ├── 提取策略：Cosine 相似度 / LLM 指令 / CSS / XPath / 正则
  ├── 分块策略：Regex / 句子 / 主题 / 固定字数 / 滑动窗口
  └── 深度爬取：BFS / DFS / Best-First
​
  核心功能
  ├── Markdown 生成（HTML → Markdown + 链接转引用）
  └── 内容过滤（BM25 / Pruning / LLM）

技术栈：asyncio + Playwright + SQLite 缓存

策略配置示例：

from crawl4ai import AsyncWebCrawler, CrawlerRunConfig, CacheMode
from crawl4ai.extraction_strategy import CosineStrategy, LLMExtractionStrategy
from crawl4ai.markdown_generation_strategy import DefaultMarkdownGenerator
from crawl4ai.content_filter_strategy import BM25ContentFilter, PruningContentFilter
​
config = CrawlerRunConfig(
    # 策略可插拔：选择提取策略（Cosine / LLM / CSS / XPath / 正则）
    extraction_strategy=CosineStrategy(semantic_filter="价格"),
    # extraction_strategy=LLMExtractionStrategy(prompt="提取产品信息"),  # 切换策略
​
    # 策略可组合：Markdown 生成 + 内容过滤
    markdown_generator=DefaultMarkdownGenerator(
        content_filter=BM25ContentFilter()      # ← 可切换为 PruningContentFilter
        # content_filter=PruningContentFilter(),
    ),
​
    # 其他配置项
    cache_mode=CacheMode.ENABLED,
    screenshot=True
)
​
async with AsyncWebCrawler() as crawler:
    result = await crawler.arun(url="...", config=config)

核心原理

为什么叫“Crawl4AI”？

传统爬虫工具抓取的是原始 HTML，LLM 消费时需要额外处理：

0. 清洗 HTML 标签
1. 提取主要内容
2. 语义分块（RAG 应用）

Crawl4AI 的核心思想：输出格式直接适配 LLM 消费。

传统流程：网站 → 原始 HTML → [额外处理] → LLM
Crawl4AI：网站 → Markdown + 语义分块 → LLM 直接消费

设计哲学：基础能力基于 Playwright 浏览器自动化，支持代理轮换、会话管理等通用反爬能力（与 Scrapling 等工具类似）。

核心技术：

• BM25 内容清洗：计算文本块与页面元数据的相关性，过滤低分区块（导航、广告等），保留核心内容
• Markdown 转换器：HTML → Markdown 转换，保留标题/表格/代码结构，链接转为引用格式，输出 LLM 可直接消费的格式（无需额外清洗）
• LLM 提取策略：用自然语言指令驱动提取（如“提取所有产品价格”），支持 Block（分块）和 Schema（JSON）两种模式，无需编写复杂的 CSS/XPath 选择器
• 多种分块策略：7 种可插拔策略，从固定长度到主题分割（TextTiling），适配 RAG 等不同场景，配合 Cosine 相似度检索只提取与查询最相关的内容，减少 LLM 输入量

适用场景

核心场景：

• RAG 系统知识库构建：为 AI 应用准备干净、结构化的 Markdown 文档源
• AI Agent 工具链：作为 Agent 的“眼睛”，提供实时、精准的网页信息获取能力
• 大规模 AI 语料采集：高效完成从爬取、清洗到分块的全流程

Agent 接入 & 实操案例

Crawl4AI 提供 Docker 服务器，支持 MCP 协议。

# 拉取 Docker 镜像
docker pull unclecode/crawl4ai:latest
​
# 运行服务器
docker run -d \
  -p 11235:11235 \
  --name crawl4ai \
  --shm-size=1g \
  unclecode/crawl4ai:latest
​
# Claude Code 配置
claude mcp add --transport sse c4ai-sse http://localhost:11235/mcp/sse

核心工具：

• md — 生成 Markdown（核心工具）
• crawl — 多 URL 深度爬取
• ask — 查询文档库（基于 Cosine Similarity）
• 其他常规工具：html， screenshot， pdf， execute_js

实操示例：

抓取新浪新闻并转换为 Markdown

局限性

局限性	说明
❌ 不支持真正验证码	无法处理 reCAPTCHA、hCaptcha 等需要人类交互的验证
❌ 资源占用较高	基于 Playwright，每个实例 200-500MB
❌ 速度相对慢	需要等待 JS 渲染，比纯 HTTP 请求慢

核心权衡：用速度和资源换 AI 友好度（语义分块、Markdown 输出、LLM 提取）。

5.6 Jina Reader — HTTP 直接请求的极简 API

覆盖阶段：Extract（提取）

定位

提供网页到 Markdown 的极简转换 API，推测底层为 HTTP 直接请求 + Readability 正文提取的托管服务。

核心特性

• 极简使用：URL 前加上 https://r.jina.ai/ 即可
• LLM 友好：输出清洗完毕的 Markdown 格式
• 零配置：无需 SDK，无需注册（有免费额度）
• MCP Server：支持 MCP 协议接入 Agent

什么是 MCP？ MCP（Model Context Protocol）是 Anthropic 提出的开放协议，让 AI Agent 通过标准化接口调用外部工具。支持 MCP 的工具可以通过 claude mcp add 一键接入 Claude Code 等 Agent 平台，无需自己写集成代码。

实操案例

# 最简单的使用方式
curl "https://r.jina.ai/https://example.com"
# 直接返回 Markdown

适用场景

• 静态博客、新闻网站、维基百科等无防护站点
• Agent 需要快速获取简单网页内容
• 作为更重工具（Playwright/Firecrawl）的前置过滤器

能力边界

遇 Cloudflare 等 JS 挑战会失败，需降级到浏览器方案。

定价

• 免费额度：20 次/分钟（无 API Key）
• 付费：~$0.045/1M tokens（2025）

5.7 Firecrawl — 全栈 Web 数据 API

定位：商业 Web 数据 API。SaaS 版的核心差异化是 Interact API（AI 驱动的云端浏览器沙箱，内置 agent-browser + Live View 实时观看）和 Fire-engine（高级反检测代理）。开源自部署版免费但只相当于 Playwright + HTTP 的薄封装，没有 Interact、Fire-engine、Search，能力不如本地开源工具。

覆盖阶段：Fetch（抓取）· Extract（提取）

核心问题：自部署版免费但弱于本地工具，SaaS 版强但要付费——Firecrawl 的价值在哪里？

三大核心 API

API	用途	特点
/search	搜索 + 获取结果页内容	一次调用完成“搜索→抓取→清洗”
/scrape	抓取单个 URL	支持 Actions 预定义步骤、多种输出格式
/interact	抓取后持续交互	AI 驱动，自然语言描述操作意图

Interact API（核心差异化能力）

Interact 是 Firecrawl 独有的能力：抓取页面后，保持浏览器会话不关闭，通过自然语言 prompt 继续操作页面。

工作流：scrape → 拿到 scrapeId → interact(scrapeId, prompt) → 继续操作 → stop

两种交互模式：

• AI Prompt：自然语言描述操作，Firecrawl 内部 AI 自动执行

• 代码执行：直接在云端沙箱运行代码，支持三种语言：

  • Node.js（Playwright）— page 变量已连接浏览器
  • Python（Playwright）— 设置 language="python"
  • Bash（agent-browser）— 沙箱预装 agent-browser，60+ 命令可用

Live View：每次 interact 返回 liveViewUrl，可嵌入 iframe 实时观看浏览器画面。interactiveLiveViewUrl 支持交互式操控（点击、输入），适合登录流程（用户手动输密码）等场景。

与 Actions 的区别：Actions 是预定义步骤（抓取前就知道要做什么），Interact 是动态的（根据页面内容决定下一步）。

注：Interact API 仅限 SaaS 版，自部署版不可用。

Actions 交互

支持传入 Actions 数组执行预定义的浏览器操作（click、scroll、write、press、screenshot、executeJavascript、pdf 等 9 种），适合抓取前就知道交互步骤的场景（如“点加载更多→等 2 秒→截图”）。

输出格式与多引擎

10 种输出格式：markdown、summary、html、rawHtml、screenshot、links、json（Schema 驱动的结构化数据）、images、branding、audio（从视频提取音频）

多引擎自动降级：按优先级依次尝试，第一个失败就自动切换下一个。

引擎	说明	自部署可用
index	预建索引缓存	❌
fire-engine;chrome-cdp	SaaS 专用 Chrome CDP	❌
fire-engine;tlsclient	SaaS 专用 TLS 客户端	❌
playwright	Playwright 微服务	✅
fetch	纯 HTTP 请求	✅
pdf / document	文档解析	✅

系统根据请求的 feature 需求（actions、screenshot 等）和 quality 分数自动选择引擎，失败后降级到下一级。

注：自部署版只能用 playwright + fetch，无 Fire-engine（SaaS 专属的高级反检测 IP 处理）。

实操示例

from firecrawl import Firecrawl
​
app = Firecrawl(api_key="your-api-key")
​
# 1. 抓取页面，获得 scrapeId
result = app.scrape("https://www.amazon.com", formats=["markdown"])
scrape_id = result.metadata["scrapeId"]
​
# 2. 用自然语言与页面交互
app.interact(scrape_id, prompt="Search for iPhone 16 Pro Max")
​
# 3. 继续交互（同一会话）
response = app.interact(scrape_id, prompt="Click on the first result and tell me the price")
print(response.output)
​
# 4. 结束会话
app.stop_interaction(scrape_id)

# 代码执行示例：用 agent-browser 操作
app.interact(scrape_id, code="agent-browser snapshot -i", language="bash")
app.interact(scrape_id, code='agent-browser fill @e1 "firecrawl" && agent-browser click @e2', language="bash")

局限性

局限	说明
自部署版能力受限	无 Fire-engine、无 Interact API、无 Index 缓存，只有 Playwright + fetch
不支持验证码	无验证码解决能力，遇到会报错
黑盒	SaaS 版无法控制浏览器细节（等待策略、执行时机等）
数据过第三方	SaaS 版请求内容经 Firecrawl 服务器

适用场景

• 强反爬站点（Cloudflare 等），需 SaaS 版的 Fire-engine 代理能力
• 需要 AI 驱动的页面交互（Interact API）
• 不想自建基础设施，直接 API 调用

定价（SaaS 版）：

• 免费计划：500 积分/月
• Hobby：$16/月，3,000 积分
• Standard：$83/月，100,000 积分
• 自部署版免费，但能力受限（无 Fire-engine、无 Interact）。

5.8 工具选型总览

能力矩阵

能力	Jina Reader	Playwright	agent-browser	Scrapling	Crawl4AI	Firecrawl
部署方式	SaaS	本地	本地	本地	本地/Docker	SaaS/Docker
单页抓取	✅	✅	✅	✅	✅	✅
Markdown 输出	✅	❌ 需自处理	❌	❌	✅	✅
结构化 JSON	❌	❌	❌	❌	✅ LLM 提取	✅ Schema 驱动
JS 渲染	❌	✅	✅ CDP	✅ Patchright	✅ Playwright	✅ Playwright
反检测/Stealth	❌	⚠️ 需配置	⚠️	✅ stealthy_fetch	⚠️	✅ SaaS 专属
自适应解析	❌	❌	❌	✅	❌	❌
会话保持	❌	⚠️ storageState	✅ session/profile	❌	❌	✅
AI 动态交互	❌	❌	❌	❌	❌	✅ Interact
验证码	❌	❌	❌	❌	❌	❌

部署选择的取舍：SaaS（Jina、Firecrawl）零运维但数据过第三方、按量付费；Docker 自部署数据不出服务器但部分能力受限；本地安装完全可控但需自行处理反爬。

关于验证码：以上六个工具均不内置验证码解决能力。但可通过集成第三方打码平台（CapSolver、2Captcha、Anti-Captcha 等）实现自动过码，reCAPTCHA 约 $0.8/千次，Turnstile 约$1.2/千次，1~9 秒返回结果。

选型决策矩阵

选型前先确认五个维度：网站反爬强度、是否需要 JS 渲染、有没有人运维、成本预算、速度/并发要求。然后按场景查表：

场景	HTTP 直接请求（Readability / Scrapy）	浏览器自动化（Playwright / Scrapling）	托管 API 服务（Firecrawl / Jina）
静态网站，无防护	✓ 首选	✗ 杀鸡用牛刀	✗ 成本浪费
动态 JS 渲染，轻度防护	✗ 拿不到数据	✓ 首选	△ 备选
强反爬（CF 盾 / 验证码）	✗ 直接失败	△ 需要 Stealth	✓ 首选
大规模并发批量爬取	✓ 首选	△ 资源消耗大	△ 成本高
Agent 实时对话场景	✓ 优先	△ 延迟偏高	△ 降级兜底
无运维资源，不想维护	✗ 需要自维护	✗ 需要自维护	✓ 首选
LLM 直接消费输出	△ 需额外处理	✓ Crawl4AI / Scrapling	△ Jina Reader

图例：✓ 首选 / △ 备选 / ✗ 不适合

六、总结

6.1 核心框架回顾

Web 数据获取 = Search × Fetch × Extract

这三个阶段不是互斥的，而是层层递进的关系。大多数工具覆盖其中一或两个阶段，只有少数（如 Firecrawl、Crawl4AI）能做到从抓取到提取的一体化。

反爬的本质是防机器。 从最简单的 IP 频率检查，到 TLS 指纹识别、JS 环境检测，再到验证码，防线逐层升级。绕过的代价也随之递增：代理池 → 浏览器自动化 → 打码服务。

抓取层没有银弹。 HTTP 直接请求快但脆弱，浏览器自动化全能但重，托管服务省心但贵。选型的本质是在速度、破防能力、成本、运维复杂度四个维度间做 Trade-off。

6.2 选型速查

你的场景	推荐路线	首选工具
静态博客、文档站、无防护	HTTP 直接请求	Readability / Scrapy
动态 SPA、需 JS 渲染	浏览器自动化	Playwright
需反爬绕过（Cloudflare 等）	增强层 Stealth	Scrapling
输出给 LLM 消费	AI 原生框架	Crawl4AI
零运维、API 调用	托管服务	Firecrawl / Jina Reader
需交互操作（登录、填表单）	浏览器自动化	agent-browser

6.3 一条完整的数据流