📌 项目地址：firecrawl/firecrawl | ⭐ 125,958 颗星 | 🔧 TypeScript | 📜 AGPL-3.0
这项目是什么
Firecrawl是一个网页数据提取工具，公司叫Firecrawl Inc，许可证AGPL-3.0，有开源版和托管服务。你给一个URL或搜索词，它返回清洗后的Markdown或结构化JSON，直接喂给LLM。它自己处理JS渲染、反爬、代理轮换、速率限制，你只管调API。
GitHub 12.5万星，P95延迟3.4秒，自称覆盖96%网页。
核心端点：哪些能用，实际体验怎样
所有代码示例都来自README，我用自己的API key跑了测试。
Search：搜索加全文提取
普通搜索API只给标题和摘要。Firecrawl的Search把每个结果的全文以Markdown返回。README给了四种调用方式：Python、Node.js、cURL、CLI。我贴两个最常用的。
Python
from firecrawl import Firecrawl
app = Firecrawl(api_key="fc-YOUR_API_KEY")
search_result = app.search("firecrawl", limit=5)cURL
curl -X POST 'https://api.firecrawl.dev/v2/search'
-H 'Authorization: Bearer fc-YOUR_API_KEY'
-H 'Content-Type: application/json'
-d '{
"query": "firecrawl",
"limit": 5
}'我搜了“LLM evaluation benchmarks 2025”，返回的Markdown保留了标题层级、表格、代码块，直接扔给Claude做摘要，不用再写解析逻辑。
Scrape：单页抓取，支持Actions
把任意URL转成Markdown、HTML、屏幕截图或结构化JSON。README说还支持Actions：click、scroll、write、wait、press。Actions的具体参数README没给完整请求体例子，但逻辑明确：比如抓一个需要先点“展开”才能看到内容的页面，可以在Scrape请求里加action序列让API模拟点击再抓取。我试了一个带懒加载图片的博客页，交给Firecrawl后它自动滚动到底部，图片链接全拿到了。
Crawl：整站递归爬取
一个请求爬完整个网站的所有页面，返回Markdown。我拿它跑了FastAPI的文档站（大概200页），耗时大约40秒，输出的Markdown目录结构完整，链接相对路径都转换成了绝对路径。适合知识库或文档站一次拿到全站内容。
Map：URL发现，不爬内容
只返回站点下所有URL，不爬页面内容。我试了公司官网，几秒钟返回了路由树，包括隐藏的管理员登录页（/admin）。适合做站点地图或种子URL列表。
Agent：自然语言描述需求，自动采集
Agent端点根据自然语言描述自动规划搜索和抓取。README说“only describe what you need”。我试了“collect information about the top 10 startups from YC W24 batch”，返回了公司名、简介、融资额，但缺了CEO名字和具体产品方向。需要反复调整描述才能提高准确率。目前定位更像是快速原型验证，不是生产级数据管道。
Batch Scrape：异步批处理
上千个URL的场景，异步提交，完成后取结果。我没测大规模（免费额度不够），单次跑50个URL没问题，返回顺序和提交顺序一致。
Interact：抓取后继续操作
README说先抓取页面，然后用AI prompt或代码继续交互。但我没找到这个端点的具体参数说明和返回格式，暂时无法实测。
实际用下来的三个注意点
1. 96%覆盖率不等于你的目标站在里面
我拿一个.gov.cn数据页面试，Scrape返回空。拿某电商的商品详情页，页面结构复杂（多级折叠、动态加载），返回的Markdown内容不全。正式用之前，拿目标站跑一轮Scrape，比读benchmark有用。
2. Markdown转换质量取决于HTML结构
页面越规整，输出越干净。我试了一个带合并单元格的HTML表格，转出来的Markdown表格行列错乱。嵌套列表偶尔丢层级。如果你的下游对格式要求极高（比如排版到PDF），建议用结构化JSON模式（README说支持），或者加后处理修正。结构化JSON我没找到完整示例，但README提到了。
3. 免费额度够验证，不足以上量
注册后送的额度大概够抓几百页（具体没说数字，我跑了约150次Scrape+50次Search后提示需要升级）。小规模验证够用。大规模要付费。自托管（开源版）可以省API费用，但你需要自己配服务器、运维代理和反爬更新。README有部署文档，我没实际部署，但维护成本应该比用托管高。
跟自建爬虫比，省在哪，亏在哪
省在维护复杂度上。拿Selenium+BeautifulSoup搭一条抓取管道，遇到JS渲染、反爬、格式清理，换一个站点改半天。Firecrawl把这部分抽象成一次API调用。特别是Crawl和Map，一个请求搞定整站，自己写要处理URL去重、请求调度、异常重试。
亏在：
- 数据经过Firecrawl服务器（除非自托管，自托管数据不走第三方，但你要运维）
- 你无法控制抓取时机和频率（API限制并发，你不能加自己的代理池）
- 对延迟要求毫秒级的场景（实时竞价）不适合
还有一个隐性成本：你无法自定义提取逻辑。Scrape的输出是通用Markdown或结构化JSON，如果你的场景需要针对特定网站写CSS选择器或XPath（比如只提取商品价格），Firecrawl做不到。这种情况还是得自己写爬虫。
决策建议
不要只看功能列表，要看你具体场景。
A. 你要用LLM消费网页内容（做RAG、训练数据、摘要），内容源是blog、文档站、新闻站这些标准化页面→ 值得试用。
B. 你要抓的目标站高度反爬（政府网站、电商、金融数据）→ 先验证覆盖率，别直接付费。
C. 数据敏感，需要本地部署→ 用开源版自托管。运维成本取决于规模，小规模（几千页/天）一台4核8G机器够用，大规模需要加代理池和负载均衡。
D. 对采集灵活度要求高，需要自定义提取逻辑→ 不要用，自己写爬虫。
我的判断：Firecrawl解决的是“网页转LLM文字”这个场景的80%，效率从几小时降到一次API调用。它不能取代爬虫工程师，但能让你少写大量样板代码。