Firecrawl 评测：把网页抓取打包成 API，但自托管前先看清 AGPL 和成本
用于大规模搜索、抓取网络并与网络交互的 API。 🔥
秒懂
- 它是什么？
- Firecrawl 把搜索、抓取、交互和爬取统一成一个 API，输出为 Markdown 或结构化 JSON，面向 AI 代理和自动化脚本。本文基于仓库文档和发布记录，拆解它的机制、上手方式、限制，以及它和自建爬虫方案的差异。
- 适合谁用？
- Firecrawl 适合需要快速把网页转成 LLM 可用数据的团队，尤其是 AI 代理、RAG 管道和需要处理 JS 重页面的场景。它把代理轮换、限流和内容清洗都封装在 API 后面，省去自建爬虫的运维负担。
- 能商用吗？
- 可以，但条件严格。AGPL-3.0 是网络 copyleft 许可证：如果别人通过网络使用你修改过的版本（例如作为托管服务），你必须以同一许可证向他们提供源代码。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决什么问题，给谁用
Firecrawl 解决的是把网页变成结构化数据的重复劳动。普通爬虫要处理代理轮换、限流、JS 渲染、反爬检测，还要把 HTML 转成干净的 Markdown 或 JSON。Firecrawl 把这些封装成 API，调用方只需要传一个 URL 或查询词。它面向的是 AI 代理开发者、RAG 管道搭建者，以及任何需要从大量网站提取文本和元数据的自动化脚本。README 里反复强调「LLM-ready output」，说明设计目标不是给传统数据采集，而是给语言模型提供上下文。
核心机制：从 Search 到 Interact 的完整链路
Firecrawl 不是一个单一抓取工具，它是一组端点。Search 走搜索引擎，返回结果页的完整 Markdown 内容，而不仅仅是链接列表。Scrape 把任意 URL 转成 Markdown、HTML、截图或结构化 JSON。Interact 在 Scrape 之后继续操作页面，先抓取拿到 scrape_id，再对同一个页面执行点击、滚动、输入等动作，用自然语言提示词控制，比如「Search for mechanical keyboard」。Crawl 和 Map 处理整站，Map 快速发现所有 URL，Crawl 逐个抓取。Batch Scrape 支持异步处理数千个 URL。这些端点共享一个设计思路：把浏览器自动化隐藏在后端，前端只暴露简单的 HTTP 调用。
上手方式：一个 API key 走天下
快速开始只需注册 firecrawl.dev 获取 API key，然后调用 Python 或 Node.js SDK。Python 示例是 `from firecrawl import Firecrawl`，然后 `app.search("firecrawl", limit=5)` 或 `app.scrape('firecrawl.dev')`。Node.js 用 `import { Firecrawl } from 'firecrawl'`，同样传 apiKey。cURL 和 CLI 也覆盖了，CLI 命令如 `firecrawl search "firecrawl" --limit 5` 和 `firecrawl scrape https://firecrawl.dev`。Interact 端点需要先 Scrape 拿到 scrape_id，再调用 `/v2/scrape/SCRAPE_ID/interact`，请求体里带 prompt。安装 Agent 技能用 `npx -y firecrawl-cli@latest init --all --browser`，MCP 配置则通过 JSON 声明 mcpServers。所有示例都指向托管服务，没有给出自托管部署的具体命令。
性能承诺与真实限制
README 宣称「Covers 96% of the web」和「P95 latency of 3.4s across millions of pages」。这些数字来自项目自己的博客，不是独立基准。作为评测，我只能说这些是供应商声明，不能当作客观事实。真正的限制在于 Interact 端点：它依赖 scrape_id，意味着必须先抓取一次才能交互，而且交互结果通过 liveViewUrl 返回，这暗示页面状态是远程维护的，不是本地浏览器。另一个限制是，对于需要登录、有复杂反爬策略或高度动态的网站，Firecrawl 的通用方案可能失效。文档没有说明如何处理这些情况，也没有提供自定义浏览器指纹或代理配置的选项。
替代方案：自建 Playwright 与托管服务的取舍
最直接的替代是自建 Playwright 或 Puppeteer 脚本。你可以自己控制浏览器实例、处理 cookies、注入自定义 JavaScript，完全掌握抓取逻辑，且没有每千次请求的费用。但你要自己写代理轮换、限流、HTML 清洗和 Markdown 转换，这些正是 Firecrawl 封装好的部分。另一个方向是 Scrapy，它适合大规模结构化爬取，有成熟的中间件生态，但学习曲线陡峭，且不原生支持 JS 渲染，需要额外接 Splash 或 Playwright。Firecrawl 的差异在于它把「搜索加抓取」合并成一个 API，Search 端点直接返回内容，这是自建方案需要自己拼接搜索引擎结果和抓取逻辑才能实现的。
许可与维护成本
Firecrawl 采用 AGPL-3.0 许可。这意味着如果你自托管并修改代码，且通过网络提供服务，需要开源你的修改版本。对于内部工具，影响可能较小，但如果对外提供 API 服务，就必须考虑合规。托管服务是另一条路，但按用量计费，成本会随调用量线性增长。维护方面，仓库活跃，最近 v2.11.0 在 2026 年 6 月发布，v2.10 在 5 月，v2.9.0 在 4 月，说明迭代频繁。频繁发布意味着 API 可能变化，升级时需关注 changelog。自托管还需要自己维护浏览器依赖、代理池和反爬策略，这些在托管服务中由 Firecrawl 团队处理。
谁该用，谁该绕开
如果你在做 AI 代理，需要快速获取网页内容作为上下文，Firecrawl 的 Search 和 Scrape 能省掉大量样板代码。如果你处理的是公开网站，且对抓取频率不敏感，托管服务开箱即用。如果你的需求是高频、大规模、深度定制的爬取，比如电商价格监控或社交媒体数据采集，Firecrawl 的通用 API 可能不够灵活，且成本会失控。同样，如果项目需要完全离线运行或数据不出内网，自托管是唯一选择，但 AGPL 和运维负担会找上门。先跑通一个 POC，用你的目标网站测试 Scrape 和 Interact，再看输出质量是否达标。
编辑结论
Firecrawl 适合需要快速把网页转成 LLM 可用数据的团队，尤其是 AI 代理、RAG 管道和需要处理 JS 重页面的场景。它把代理轮换、限流和内容清洗都封装在 API 后面，省去自建爬虫的运维负担。不适合对数据管道有严格审计要求、需要完全控制抓取逻辑、或者预算敏感且流量大的项目，因为 AGPL-3.0 许可要求自托管修改后开源，且托管服务按用量计费。采用前先验证三件事：一是用你的目标网站跑一遍 Scrape 和 Search，确认输出质量，特别是 JS 渲染页面；二是检查 AGPL 许可对内部服务分发是否构成影响，必要时咨询法律意见；三是对比自托管 Firecrawl 与直接使用 Playwright 加解析库的成本，确认额外抽象是否值得。
社区笔记