Firecrawl 网页提取:一条命令验证单页到整站
【免费下载链接】firecrawlThe context API to search, scrape, and interact with the web at scale. 🔥项目地址: https://gitcode.com/GitHub_Trending/fi/firecrawl
Firecrawl 是一个开源的网页提取 API:把任意网页转成干净的 markdown 或结构化 JSON,直接喂给 LLM 或 agent 流水线。它解决的不是"能不能抓到 HTML",而是"抓来的东西还能不能用"——导航栏、广告、JS 噪音都替你清掉。适合做 RAG 语料、竞品监控、数据聚合的开发者和技术爱好者。
能力边界与核心设计
LLM-ready 是输出标准。scrape 的默认产物是干净 markdown,也可以一次请求要 HTML、截图、links、结构化 JSON 多种格式。输出干净意味着 prompt 里的无效 token 更少,这是它和"下载 HTML 再自己正则"路线的根本差异。
脏活被封装在服务端。代理轮换、限速、JS 渲染页面、反爬拦截由服务端处理,调用方不写任何代理逻辑。代价是:自托管时这些能力取决于你配的抓取引擎,开箱自带的 Playwright 只覆盖基础场景。
抓取之后还能继续操作。scrape 拿到页面后,可以用自然语言指令对同一个页面会话执行搜索、点击、滚动,再取结果,适合登录态或动态加载的内容。
| 方式 | 适用场景 | 限制 |
|---|---|---|
| 单页 scrape | 已知 URL,要页面内容 | 一次一个 URL |
| map | 只想知道站点有哪些 URL | 不返回正文 |
| crawl | 整站正文,异步任务 | 必须给页面数上限,大站耗时长 |
| agent | 只有自然语言需求,无确切 URL | 需要模型提供方,成本最高 |
跑起来:最小可用路径
容器化和本地开发是两条独立路径,别混用配置文件:前者用根目录docker-compose.yaml,后者在apps/api下用 pnpm 启动并自管依赖容器。最短路径是 Compose 起一套自托管服务,再发一个 scrape 请求验证:
git clone https://gitcode.com/GitHub_Trending/fi/firecrawl cd firecrawl && docker compose up -d curl -X POST http://localhost:3002/v2/scrape -H 'Content-Type: application/json' \ -d '{"url": "https://example.com"}'预期输出是success: true且带markdown字段的 JSON。默认配置不启用 API 认证(USE_DB_AUTHENTICATION=false),API 只监听 3002 端口,内网验证没问题,别直接暴露公网。
从单次调用到批量任务
单页抓取:scrape 直接返回 markdown
要解决的问题:一个已知 URL,拿干净的正文进 prompt。
from firecrawl import Firecrawl app = Firecrawl(api_key="fc-YOUR_API_KEY") # 自托管改为 http://localhost:3002 doc = app.scrape("https://firecrawl.dev", formats=["markdown"]) print(doc.markdown)这张图展示的是一个站点被转成 llms.txt 标准结构后的网页提取结果,每行对应一个页面的路径与说明:
整站爬取:crawl 用 limit 控制规模
要解决的问题:文档站、博客这类多页站点要整库入库,但大站不设上限会把时间和配额烧光。
job = app.crawl("https://docs.firecrawl.dev", limit=50) for doc in job.data: print(doc.metadata.source_url, doc.markdown[:80])SDK 会自动轮询异步任务直到完成;如果直接打 HTTP,返回的是 job id,需要自己去轮询状态接口。
批量与结构化提取:agent 配 schema 约束字段
要解决的问题:需求是一句话("找某公司定价"),且要按字段落库,而不是回传一大段 markdown。
from pydantic import BaseModel class Plan(BaseModel): name: str price: str class Pricing(BaseModel): plans: list[Plan] result = app.agent(prompt="Find Notion pricing plans", schema=Pricing)这张图展示 search 接口一次调用同时返回标题、URL 和 markdown 正文的完整链路:
仓库里也有一套现成的参考实现:examples/blog-articles/amazon-price-tracking/,定时抓取商品价格并画趋势线。下图就是该示例的价格追踪面板:
选哪种语言 / 哪种接入方式
| 语言 / 接入方式 | 优势 | 注意点 |
|---|---|---|
Python(apps/python-sdk/) | 和 LLM/RAG 生态无缝 | 异步接口另开 Async 客户端 |
Node.js(apps/js-sdk/) | TS 类型完整,前后端通用 | 注意 v1/v2 端点差异 |
Go(apps/go-sdk/) | 轻量嵌入服务端 | 功能跟进较慢 |
| 直接 HTTP | 零依赖,serverless 可用 | crawl 等异步任务要自己轮询 |
SDK 的通用价值在于替 crawl、batch 这类异步任务自动轮询。各 SDK 的完整用法看仓库根目录README.md的 SDKs 一节。
落地时容易踩的坑
- crawl 超时或跑不完:先 map 看站点规模,再给 limit 定值,别对大型站点无上限爬。
- 内容为空:多为 JS 渲染页面,先确认走了 Playwright 抓取端点,再考虑调大 timeout,而不是盲目重试。
- AI 功能不生效:agent、interact 依赖模型提供方,自托管没配 OpenAI 或 Ollama 时这些端点不可用。
- 代理和反爬:托管版自带代理池;自托管默认没有,受保护的站点要自己接代理。
下一步
当前自托管默认不启用认证、队列与 Redis 也未配持久化,暴露公网前必须先补齐这两项;Kubernetes 与 Helm 清单在examples/kubernetes/。先看 SELF_HOST.md 和根目录 docker-compose.yaml。建议先用一个手头真实的数据源跑 scrape,确认输出格式后再上 crawl。
【免费下载链接】firecrawlThe context API to search, scrape, and interact with the web at scale. 🔥项目地址: https://gitcode.com/GitHub_Trending/fi/firecrawl
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考