Firecrawl：Web → Markdown，给 LLM 当上下文

我们已经在 2026 年习惯"让 LLM 读网页"这件事了——但你只要真的让 LLM 去抓一个现代网页（React SPA、需要登录、有反爬、有无限滚动），就会撞上三件事：JS 没渲染就拿到了空壳、HTML 标签噪音淹没 prompt 的有效信息、爬到一半被 Cloudflare 拦下。Firecrawl（146k stars / AGPL-3.0）就是把这三件事兜起来的"web context API"——本文拆它的接口形态和它为什么是 Agent 时代最常被点名的爬虫。

学习目标

读完本文，你应该能够：

• 说清 Firecrawl 在「API 维度」把「读 web」切成哪 4 个端点（search / scrape / crawl / batch scrape），各自对应哪类用户场景
• 区分 Firecrawl（LLM context API）与普通爬虫（Scrapy / Playwright / Crawlee）的边界，说清它在中间层替你做了哪几件事（JS 渲染、Markdown 转换、结构化抽取、绕过反爬）
• 用 MCP server 一行接入的方式，把 Firecrawl 挂到 Claude Code / Cursor / Continue / Cline 等任意 MCP-aware agent
• 判断什么场景该用 Firecrawl、什么场景 jina reader / tavily / Playwright 更合适，以及自托管与 hosted 版本的取舍
• 评估自托管 Firecrawl 的真实成本（内存、token、proxy）与 AGPL-3.0 合规边界（闭源产品为何必须用 hosted 版本）

目录

• 学习目标
• 它在 API 维度做了四件事
• 为什么是 LLM Context API 而不是 Crawler
• 怎么用：4 个最小例子
• Agent 时代的杀手锏：MCP 一行接入
• 与同类工具的边界
• 自托管的现实
• 适用边界
• 仓库地址
• 自测题
• 练习
• 进阶路径
• 常见问题

它在 API 维度做了四件事

Firecrawl 把"读 web"切成 4 个端点，每个对应一类用户场景：

外加一个面向 AI Agent 的 extract——自然语言描述 schema，Firecrawl 自己用 LLM 从页面里抠字段。

为什么是 LLM Context API 而不是 Crawler

普通爬虫（Scrapy、Playwright、Crawlee）给你的是 HTML 字符串或裸 JSON，要你自己 parse 标签、去噪、提取正文。Firecrawl 在中间层替你做了：

1. JS 渲染：headless 浏览器跑 React/Vue/SPA，等 hydration 完成再 snapshot。
2. Markdown 转换：HTML → Markdown，保留代码块、表格、链接、标题层级，去掉 nav/footer/广告。
3. 结构化抽取：extract 端点接受 JSON Schema 或自然语言描述，从页面里抽出结构化字段（产品价格、规格、作者）。
4. 绕过反爬：内置 proxy rotation、UA rotation、stealth 模式。官方 benchmark 声称覆盖 96% 的 web（包括 JS-heavy 页面）。
5. Action 序列：可以先 click / scroll / write / wait / press 再抽取，处理"翻页后才看到列表"这种交互场景。

输出默认是 markdown（保留可读性 + 适配 LLM prompt 长度限制），也可以指定 HTML、screenshot、JSON。

怎么用：4 个最小例子

from firecrawl import Firecrawl

app = Firecrawl(api_key="fc-...")

# 1. Scrape：单 URL → Markdown
result = app.scrape(
    "https://example.com/article",
    formats=["markdown", {"type": "json", "schema": {...}}],
)
print(result.markdown)
print(result.json)

# 2. Search：搜并带全文
results = app.search("LLM evaluation benchmarks 2026", limit=5)

# 3. Crawl：整站爬（异步任务）
job = app.crawl(
    "https://docs.example.com",
    limit=500,
    include_paths=["/guide/*"],
    exclude_paths=["/api/*"],
)
# job.id 用于异步轮询

# 4. Extract：自然语言 schema
schema = {
    "type": "object",
    "properties": {
        "name": {"type": "string"},
        "price": {"type": "number"},
    }
}
extracted = app.extract(
    ["https://shop.example.com/p1", "https://shop.example.com/p2"],
    schema=schema,
)

CLI 也有一行入口：

firecrawl scrape https://example.com --format markdown
firecrawl crawl https://docs.example.com --limit 100

Agent 时代的杀手锏：MCP 一行接入

Firecrawl 的另一个差异化点是 MCP server——你不用写 Python 绑定，直接让 Claude Code / Cursor / Continue / Cline 等 MCP-aware agent 通过 mcp.json 接入：

{
  "mcpServers": {
    "firecrawl": {
      "command": "npx",
      "args": ["-y", "firecrawl-mcp"],
      "env": {"FIRECRAWL_API_KEY": "fc-..."}
    }
  }
}

之后 agent 多了三个 tool：firecrawl_scrape / firecrawl_crawl / firecrawl_search。这是 Firecrawl 能在 2025–2026 增长到 146k stars 的核心驱动——它把"agent 联网"做成了 declarative 的"加 mcp server"而不是 imperative 的"写 Python 调用"。

与同类工具的边界

读到这里你大概想问：这跟 jina reader / tavily / playwright 有什么区别？

Firecrawl 的位置是jina reader 的全栈版+playwright 的 agent 版——你愿意为"开箱即用"付钱就用 Firecrawl，你愿意写代码就 Playwright。

自托管的现实

Firecrawl 主仓库是完整的 TypeScript + Playwright + Redis 队列实现，可以 docker-compose 起来。但有几件事要注意：

1. AGPL-3.0：你 fork / 修改后必须开源，如果你要做闭源产品必须用 hosted 版本（firecrawl.dev）。
2. 反爬 IP 池：自托管版本要自己配 proxy rotation，否则跑几小时就被 Cloudflare 拦。
3. JS 渲染成本：headless Chrome 是吃内存大户，单机起 5 个 worker 就吃 ~8GB RAM。
4. LLM 抽取的 token 成本：extract 端点背后是 LLM 调用，长页面 token 消耗要注意。

对于"我要给内部 agent 做联网功能 + 不在意付费"的场景，hosted 版本是合理选择。对于"我要做 to C 产品 + 想白嫖"——直接用 jina reader + 自己写一层批量调度。

适用边界

• 真要快且免费：jina reader 单页比 Firecrawl 快几倍。
• 真要可控：Playwright + 自己 parse。
• 真要给 agent 用：Firecrawl 的 MCP server 是当前最低摩擦的接入方式。
• 真要做闭源产品：注意 AGPL-3.0，hosted 版本规避风险。
• 真要规模化：Firecrawl hosted 按 credit 计费，1k credits 起卖，超大规模前自己算 TCO。

仓库地址

• 仓库：firecrawl/firecrawl
• 主页：https://firecrawl.dev
• 协议：AGPL-3.0（自托管强制开源）
• 主语言：TypeScript（API server）+ Python SDK + Node SDK
• stars：146k / forks 8.4k

如果你只想快速体验，pip install firecrawl-py + 拿一个 API key 就能在 5 分钟内跑通第一个 scrape 调用——这是它能在 Agent 时代拿下 14 万 stars 的根本原因：摩擦低到接近自然语言查询。

自测题

读完本文后，先自己想 30 秒再展开答案：

练习

练习 1：跑通第一个 scrape（入门，约 15 分钟）

用 Firecrawl Python SDK 把任意一篇博客文章转成 markdown，并统计输出字数：

from firecrawl import Firecrawl

app = Firecrawl(api_key="fc-...")
result = app.scrape("https://example.com/article", formats=["markdown"])
print(len(result.markdown), "chars")

完成后回答：输出的 markdown 和原始 HTML 相比，去掉了哪些噪声（nav / footer / 广告）？保留了哪些对 LLM 有用的结构（代码块 / 表格 / 链接）？

练习 2：用 extract 抽结构化字段（约 30 分钟）

挑一个电商商品页，用 JSON Schema 描述 name / price / rating 三个字段，调用 app.extract([url], schema=schema)，把结果打印成 JSON。

参考要点：schema 里每个 property 要写清 type；如果页面字段是动态加载的，先确认 scrape 能渲染出该字段，再交给 extract。

练习 3：MCP 接入一个 agent（约 30 分钟）

在你的 Claude Code 或 Cursor 的 mcp.json 里加入 Firecrawl MCP server（参考本文「MCP 一行接入」节的配置），重启后让 agent 执行"搜一下 X 的最新文档并总结"。

验收：agent 能成功调用 firecrawl_search / firecrawl_scrape，而不是报"没有联网工具"。

练习 4：Firecrawl vs jina reader 输出对比（约 20 分钟）

对同一篇长文（含代码块和表格），分别用 Firecrawl scrape 和 jina reader 取 markdown，对比：代码块是否完整、表格是否保留、广告/nav 是否被正确剔除。

结论记录：哪个在你常处理的页面类型上更干净？单页延迟差多少？

练习 5：自托管一次小批量 crawl（约 1 天，含环境搭建）

用 docker-compose 起一个自托管 Firecrawl，配好 proxy，对某个 docs 站点跑 crawl（limit 100），观察内存占用和被 Cloudflare 拦截的频率。

交付物：一份"自托管 vs hosted"的 TCO 笔记（含内存峰值、proxy 费用、被拦重试次数）。

进阶路径

读完本文后，按以下顺序动手，而不是只按阅读顺序：

第一步：跑通 4 个最小例子（约 1 小时）

把本文「怎么用：4 个最小例子」节的 search / scrape / crawl / extract 各跑一遍，确认 SDK 和 API key 可用。formats 参数可以组合 markdown 与带 schema 的 json，先试通一种再组合。

验证标准：能拿到非空的 result.markdown 和一个结构化 result.json。

第二步：MCP 接入 agent（约 30 分钟）

按「MCP 一行接入」节把 Firecrawl 挂到你的主力 coding agent。这步让你从"写 Python 调用"切换到"声明式接入"，是理解它增长逻辑的关键。

交付物：一段可用的 mcp.json 配置。

第三步：extract + schema 实战（约 2 小时）

选一个你手头真实要抓的页面，写出稳定的 JSON Schema，把 extract 跑通。重点体会"描述字段"和"写 parse 脚本"的代价差异。

验收条件：对 3 个不同页面，抽取成功率 ≥ 90%。

第四步（可选）：自托管与规模化评估（约 1 天）

docker-compose 起自托管，配 proxy，跑百级 URL 的 crawl，记录内存、token、被拦率。用这份数据决定你的场景该 hosted 还是自托管。

边界提醒：闭源产品别碰自托管——AGPL-3.0 会强制你开源。

常见问题

Q1：Firecrawl 免费吗？

自托管免费，但要自己承担 proxy、内存和 extract 的 token 成本，且受 AGPL-3.0 约束。hosted 版本（firecrawl.dev）按 credit 计费，1k credits 起卖。单页快速验证用 jina reader 的免费层通常更快更省。

Q2：Firecrawl 和 jina reader 怎么选？

要全栈（爬 + 渲染 + 抽取 + 结构化）+ agent ready + 愿意付费，选 Firecrawl。要单页干净 markdown、免费层慷慨、不批量爬，选 jina reader。一句话：Firecrawl 是 jina reader 的全栈版，jina reader 是 Firecrawl 的轻量单页版。

Q3：自托管需要准备什么？

docker-compose 能起主仓库（TypeScript + Playwright + Redis 队列），但三件容易被忽略的事：proxy rotation（否则被 Cloudflare 拦）、充足内存（headless Chrome 是吃内存大户）、以及 extract 的 LLM token 预算。

Q4：extract 的 token 成本怎么估算？

背后每次抽取是一次 LLM 调用，成本随页面长度和字段数上升。长页面（如整篇文档）单次 extract 可能消耗几千 token。建议先 scrape 拿到正文再 extract，而不是对整个原始 HTML 抽。

Q5：AGPL-3.0 对我的产品有什么实际影响？

AGPL 的强点是"网络使用也视为分发"——你 fork / 修改后必须开源。做闭源 to C 产品时，直接用 hosted 版本规避；做内部 agent 联网且不在意付费，hosted 也是合理选择；想白嫖又闭源，走 jina reader + 自己写批量调度。

Q6：爬一半被 Cloudflare 拦了怎么办？

hosted 版本内置 proxy rotation / stealth，通常更稳。自托管必须自己配 proxy 池和 UA rotation；若仍频繁被拦，检查单 IP 请求频率、是否带了合理 UA 与等待间隔。规模化前先算 TCO，超大规模可能 hosted 反而划算。