做过 RAG 或者 Agent 的人，多半都卡在同一个地方：模型本身很聪明，但你喂给它的网页数据脏得没法看。
随便抓一个现代网页，原始 HTML 里塞满了导航栏、广告位、cookie 弹窗、内联脚本、追踪像素和层层嵌套的 <div>。这些噪声不仅干扰模型理解，还在白白烧 token——而 token 是要花钱的。更麻烦的是，现在很多页面的正文是 JavaScript 在浏览器里渲染出来的，你用 requests 抓回来只能拿到一个空壳；就算上了 Playwright，紧接着又要面对 IP 封锁、验证码、速率限制这些反爬机制。
Firecrawl 想解决的就是这条链路：把任意一个 URL 变成干净的、LLM-ready 的 markdown（或结构化 JSON、截图），中间所有脏活——JS 渲染、代理轮换、速率限制、抓取编排——都替你处理掉，零配置。官方给的一个关键数字是：markdown 输出相比原始 HTML，大约能省 67% 的 token。对于要把网页内容批量灌进上下文窗口的场景，这个比例直接决定了你的成本曲线。
这篇文章会把 Firecrawl 讲透：它的五个核心 endpoint 各自干什么、怎么三行代码跑起来、云端免费额度和 credit 怎么算、以及怎么用 Docker Compose 在自己机器上把它跑起来——还有自部署版本相比云端到底缺了哪些能力。如果你正在搭 RAG 知识库或者 Agent 的数据管道，这套抓取层值得认真评估。关于 Agent 该不该自己造这类底层设施，可以先看为什么不建议自研 Agent 基础设施这篇的论证。
Firecrawl 是什么：一句话和五个 endpoint
Firecrawl 的官方定位是 “The API to search, scrape, and interact with the web at scale”——一个用来大规模搜索、抓取、与网页交互的 API。它在 GitHub 上有 110k+ stars，主代码采用 AGPL-3.0 许可证，SDK 和部分 UI 组件则是 MIT。官方提供了覆盖 Python、Node.js、Java、Rust、Go、Elixir、PHP 的多语言 SDK，基本主流后端语言都能直接接。
它的能力被组织成几个清晰的 endpoint，理解这几个就理解了 Firecrawl 的全貌：
- Scrape：抓单个 URL，返回 markdown、HTML、截图或结构化 JSON。这是最常用的原子操作。
- Crawl：一个请求爬取整站。给一个起始 URL，它会顺着链接把整个站点的页面都抓下来。
- Map：秒级发现一个网站的所有 URL。不抓正文，只给你一张覆盖全站的地图。
- Search：搜索网页，并直接把结果页的全文取回来——相当于”搜索 + 抓取”合一。
- Extract：基于 LLM 的结构化抽取，按你定义的 schema 从页面里把字段提出来（需要配置
OPENAI_API_KEY）。
除此之外还有 Interact / Agent 这一类能力：浏览器自动化，以及按自然语言描述自动采集。这里要先记一个坑——/agent 和 /browser 这两个 endpoint 在自部署版本里是不支持的，只有云端能用。后面讲自部署时还会再强调。
这套 endpoint 设计的好处是粒度分明：要单页就 Scrape，要全站就 Crawl，只想知道有哪些页面就 Map，想边搜边抓就 Search，想要结构化字段就 Extract。你不用在一个万能接口里堆一堆参数。
快速上手：拿 API key，第一次 Scrape 出 markdown
最快的路径是用云端。去 firecrawl.dev 注册，免费起步不需要信用卡，拿到一个 fc- 开头的 API key 就能跑。
Python SDK 的最小示例：
from firecrawl import Firecrawl
app = Firecrawl(api_key="fc-YOUR_API_KEY")
doc = app.scrape("https://firecrawl.dev", formats=["markdown"])
print(doc.markdown)
三行就拿到了一个网页的干净 markdown。formats 参数控制你要什么——markdown、html、截图、结构化 JSON 都在这里指定。
Node.js 的等价写法：
import { Firecrawl } from 'firecrawl';
const app = new Firecrawl({ apiKey: 'fc-YOUR_API_KEY' });
const doc = await app.scrape('https://firecrawl.dev', { formats: ['markdown'] });
如果你不想引 SDK，或者要在 shell 脚本、其他语言里调，直接打 HTTP 也行。这是 v2 的 curl 示例：
curl -X POST 'https://api.firecrawl.dev/v2/scrape'
-H 'Authorization: Bearer fc-YOUR_API_KEY'
-H 'Content-Type: application/json'
-d '{"url": "firecrawl.dev"}'
注意 endpoint 路径里的 v2——这是当前的 API 版本。整个调用模型很直白：POST 一个 URL，拿回结构化结果。你不需要去管目标站点用没用 JS 框架、需不需要等待渲染、会不会被风控拦——这些 Firecrawl 在服务端都处理了。
值得单独说一句 formats。同一个 URL，你可以一次要多种格式：要 markdown 喂 LLM、要 HTML 留档、要截图做视觉留证、要结构化 JSON 直接入库。把格式作为参数而不是不同的 endpoint，意味着你的抓取逻辑只写一遍，输出形态按下游需求切换。对于既要做 RAG 又要做归档的混合管道，这一点能省掉不少重复代码——抓一次，多路分发。
Crawl / Map / Search / Extract：从单页到整站
Scrape 解决单页，真实项目里你往往要批量。
Crawl 整站爬取。当你想把一个文档站、博客、产品手册整体灌进知识库，Crawl 是入口：给它一个起始 URL，它会自动顺着站内链接发现并抓取所有页面，每一页都按 Scrape 的逻辑清洗成 markdown。这正是构建 RAG 语料的典型动作——把官方文档整站抓下来，切块、向量化、入库。要把这些语料真正用好，可以参考Haystack 与 LangChain 在生产级 RAG 上的取舍，以及Java 全流程把外部 wiki 接入知识库的实践。
Map 快速发现 URL。有时你并不想立刻抓全文，只想先知道一个站点到底有哪些页面、结构长什么样。Map 能秒级返回一个网站的全部 URL 列表。常见用法是先 Map 拿到 URL 清单，人工或程序筛掉不需要的（比如归档页、标签页），再针对性地 Scrape——这样比无脑 Crawl 整站更省额度也更可控。
Search 搜索并取回全文。普通搜索 API 只给你标题和摘要，你还得自己再去抓每个结果页。Firecrawl 的 Search 把这两步合并：搜索一个查询，直接把结果页的全文取回来。对于需要”现搜现喂”的 Agent——比如回答时事问题、查最新文档——这一步省掉了大量胶水代码。
Extract 结构化抽取。前面几个都是把整页转成文本，Extract 则更进一步：用 LLM 按你给的 schema 把页面里的特定字段提出来。比如从一堆商品页里抽出名称、价格、库存，输出成规整的 JSON。这一步需要 OPENAI_API_KEY 来驱动背后的模型。
这里要回到那个 67% 的数字。无论 Crawl 还是 Search，最终喂给 LLM 的都是 markdown 而非原始 HTML。省下的 token 是双重收益：一方面直接降低 API 账单，另一方面让有限的上下文窗口装下更多真正有用的内容，而不是被 </div> 和内联样式填满。当你的管道每天处理成千上万个页面时，这个比例不是优化项，是成本结构本身。如果想系统地度量不同方案对 token 的影响，LLM 评测矩阵那篇给了一套可参考的指标框架。
自部署：Docker Compose 起一个本地实例
云端方便，但有些场景你会想把 Firecrawl 跑在自己机器上：数据合规要求不能把内容外发、要抓内网站点、或者量大到自部署更划算。仓库自带了 docker-compose，路径很短。
构建并启动：
docker compose build
docker compose up
跑起来后，实例监听在 http://localhost:3002。它底层用 Bull 做队列管理，有一个队列监控 UI 在 http://localhost:3002/admin/{BULL_AUTH_KEY}/queues——{BULL_AUTH_KEY} 是你在环境变量里设的那个值。
必需的环境变量有这么几个：
PORT=3002
HOST=0.0.0.0
USE_DB_AUTHENTICATION=false
BULL_AUTH_KEY=CHANGEME
USE_DB_AUTHENTICATION=false 表示自部署时关掉数据库鉴权（自己内网用，不需要云端那套账号体系）；BULL_AUTH_KEY 务必从 CHANGEME 改成你自己的值，否则队列 UI 就裸奔了。
可选的环境变量则决定你能解锁哪些进阶能力：
OPENAI_API_KEY——启用 JSON 格式输出、/extract结构化抽取、以及内容摘要。OLLAMA_BASE_URL=http://localhost:11434/api——实验性地接本地模型，配合MODEL_NAME、MODEL_EMBEDDING_NAME使用；OPENAI_BASE_URL则用来接其他 OpenAI 兼容的 API。REDIS_URL=redis://redis:6379——队列和缓存依赖的 Redis。PLAYWRIGHT_MICROSERVICE_URL——浏览器渲染微服务地址。PROXY_SERVER/PROXY_USERNAME/PROXY_PASSWORD——配置你自己的代理。MAX_CPU=0.8/MAX_RAM=0.8——资源占用上限，防止抓取把机器吃满。
把这些写进 .env（或 compose 文件的环境段），就能跑起一个功能基本齐备的本地 Firecrawl。
自部署 vs 云端：缺的是什么
这是决策时最该看清的一点。自部署不是云端的等价复制，有几个明确的功能差异：
- 没有 Fire-engine。这是云端处理 IP 封锁、反爬检测的那套核心机制。自部署版本不带，意味着抓那些风控严格的站点时，你得自己上代理、自己想办法，成功率和稳定性不如云端。
/agent和/browserendpoint 不支持。前面提过的浏览器自动化、自然语言驱动采集这类高阶能力，自部署用不了。- 截图和本地 LLM 可用。好消息是基础的截图功能在自部署里保留，本地模型（通过 Ollama 等）也能接。
换句话说，自部署适合”目标站点不太设防、且你愿意自己管代理”的场景；一旦要对抗强反爬，云端的 Fire-engine 才是你掏钱买的核心价值。这种”自建底层 vs 用托管服务”的权衡，本质上和 Agent 工程里反复出现的自主 Agent 该托管还是自控是同一类问题。
免费额度与计费：什么时候该自部署省钱
云端 firecrawl.dev 的计费单位是 credit。免费档（Free tier）给的是：
- 每月 1,000 credits，并发 2，速率限制为 low。
- 1 credit = 1 页，适用于 Scrape / Crawl / Map / Monitor。
- Search 是 2 credits / 每 10 条结果。
- Interact 是 2 credits / 每浏览器分钟。
也就是说，1,000 credits 大致够你抓 1,000 个页面。对个人项目、原型验证、小规模知识库，免费额度往往就够跑通整条链路了。
往上是付费档（credits 为每月额度）：
- Hobby：$16/月，5,000 credits。
- Standard：$83/月，100,000 credits。
- Growth：$333/月，500,000 credits。
- Scale：$599/月，1,000,000 credits。
- Enterprise：定制。
怎么判断该用云端还是自部署？一个朴素的算法是：把你的月抓取量换算成 credits，对照档位看月费，再和自部署一台机器的成本（服务器 + 代理 + 你的运维时间）比。量小、要抗反爬、不想运维 → 云端。量大、目标站点不设防、有合规/内网需求 → 自部署。中间地带就看你的代理资源和工程精力。别忘了把”自己维护反爬”的隐性成本算进去——这部分恰恰是云端 Fire-engine 替你承担的。
接进 AI 工作流：MCP、RAG 与 Agent 数据管道
Firecrawl 真正的价值在于它是管道的一环，而不是孤立工具。
通过 MCP 接入 AI 编程环境。Firecrawl 提供了官方的 MCP server，可以接进 Claude Code、Cursor、Antigravity 等支持 Model Context Protocol 的客户端。配置就是一段 JSON：
{
"mcpServers": {
"firecrawl-mcp": {
"command": "npx",
"args": ["-y", "firecrawl-mcp"],
"env": { "FIRECRAWL_API_KEY": "fc-YOUR_API_KEY" }
}
}
}
配好之后，你的 AI 助手就能在对话里直接抓网页、查文档、取最新资料，不用你手动复制粘贴。想理解 MCP 这套协议怎么把工具喂给模型，可以看Coze 配合 Python 与 MCP 协议打通的拆解，以及 Agent Skill 如何跨工具复用的思路——MCP server 本质上就是一种可复用的能力单元。
作为 RAG 知识库的数据源。这是最自然的用法：Crawl 抓整站 → markdown 切块 → 向量化入库 → 检索增强生成。Firecrawl 负责的是这条链路最脏的第一段，让进库的语料从一开始就是干净的。在更复杂的多步推理里，抓取常常只是图里的一个节点，比如基于 LangGraph 编排的论文工作流就把检索、抽取、综合串成了一张图。
作为 Agent 的数据管道。Agent 要感知外部世界，靠的就是抓取和搜索。把 Firecrawl 的 Scrape / Search 挂到 Agent 的工具集里，它就有了”上网读资料”的能力。要把这条能力嵌进一套成型的 Agent 系统，AI Agent 框架全景梳理了 LangChain、LangGraph、n8n、Dify 的定位差异；如果你走低代码路线，n8n 低代码工作流实战和扣子智能体开发全攻略是更易上手的入口。而当抓取数据要在前端流式渲染时，Dify 图文流式混排的工程实践有现成的处理范式。
管道一旦复杂，可观测性就变成刚需。抓取节点失败、返回空内容、token 异常超标，这些都得能追溯。把 Prompt / Tool Call / Token 全链路追踪接上，再配合像 HALO 这样的 Agent 调试器，你才能在生产环境里定位”为什么这次抓回来是空的”。
和自写 requests + BeautifulSoup / Playwright 比
老派做法是 requests + BeautifulSoup：拉 HTML、解析 DOM、写选择器提正文。简单页面够用，但遇到 JS 渲染就抓到空壳，遇到反爬就被封 IP，而且每个站点的 DOM 结构不同，选择器得一个个调、还会随对方改版而失效。维护成本会随站点数量线性增长。
进阶做法是 Playwright / Puppeteer：起一个真浏览器，等 JS 渲染完再取内容。这解决了渲染问题，但你得自己管浏览器实例的生命周期、内存、并发，还要自己搭代理池、处理验证码、做速率控制——等于在自建一套抓取基础设施。
Firecrawl 的取舍是：把这些都收进托管服务（或一个 Docker 镜像），你只管发 URL、收 markdown。它直接输出 LLM-ready 格式，省掉了”HTML → 提正文 → 转文本”这一段你本来要自己写的清洗逻辑。代价是引入一个外部依赖（云端）或一套要运维的服务（自部署），以及前面说的自部署反爬能力的缺失。
要不要换，取决于你的规模和场景。只抓几个结构稳定的页面，自写脚本可能更轻；要抓几百个站点、还要喂给 LLM，Firecrawl 省下的清洗和反爬工程量通常能覆盖它的成本。这里不列具体的 benchmark 数字——真实表现高度依赖目标站点，自己拿代表性页面跑一轮对比，比看任何宣传数字都靠谱。
一个常被忽略的成本是”维护”。自写抓取脚本的真正开销不在第一次写出来，而在对方改版后你要不断修选择器、补反爬对策、处理新出现的边界情况。这种维护负担会随着你接入的站点数量和时间推移持续累积，而且很难量化进项目排期里。托管方案把这部分波动收敛成一个相对固定的月费，对小团队来说，省下的是注意力——你可以把工程精力放在检索质量、prompt 设计、Agent 编排这些真正产生差异化价值的地方，而不是和别人的反爬系统拉锯。这也是”少造轮子、把底层交给专门方案”这一工程取向在抓取场景里的具体体现。
相关阅读
- AI Agent 框架全景：LangChain / LangGraph / n8n / Dify——抓取层之上，怎么选编排框架。
- Claude Agent SDK 的多用户适配挑战——把抓取能力接进真实 Agent 产品时会踩的坑。
- 为什么 AI Agent 不应该自研基础设施——理解”用 Firecrawl 还是自己造”的底层逻辑。
- AI Agent 学习路径与资源清单——从零搭建 Agent 数据管道的系统性入门。
- LLM 评测矩阵——量化不同抓取/喂数据方案对模型表现的影响。
FAQ
免费额度够用吗？
对个人项目、原型和小规模知识库，每月 1,000 credits（约等于 1,000 页）通常够跑通整条链路，而且起步不需要信用卡。一旦进入日常批量抓取，就要按月抓取量对照付费档位算账，或者考虑自部署。
自部署能用 Extract 吗？
能，但有前提。/extract 这类基于 LLM 的结构化抽取需要你在环境变量里配 OPENAI_API_KEY（或通过 OLLAMA_BASE_URL / OPENAI_BASE_URL 接本地或兼容模型）。真正在自部署里用不了的是 /agent 和 /browser endpoint，以及云端的 Fire-engine 反爬机制——这两点和 Extract 无关。
和 LangChain 怎么配？
把 Firecrawl 当数据源用：Crawl 或 Scrape 出 markdown，切块后进 LangChain 的向量库做 RAG；或者把 Scrape / Search 包成 Agent 的工具。它负责”拿干净数据”，LangChain 负责”用数据推理”，职责清晰互补。具体取舍可对照生产级 RAG 的框架选型。
AGPL 商用要注意什么？
Firecrawl 主代码是 AGPL-3.0，SDK 和部分 UI 组件是 MIT。AGPL 的关键约束在于：如果你修改了它的服务端代码并对外提供网络服务，通常需要把对应修改后的源码也开放出来。直接调用云端 API、或用官方 MIT 协议的 SDK 接入，一般不触及这条；但如果你 fork 了服务端自己改了再对外开放服务，务必让法务确认合规边界。
结语
Firecrawl 把”网页变干净 markdown”这件脏活做成了一个 endpoint。先用免费额度在云端跑通你的链路，再按规模和反爬需求决定要不要落到自部署——这是最稳的上手顺序。
评论前必须登录！
立即登录 注册