AI TOOL PUSH01. 为什么每次让 AI “联网查一下”，都像让一辆手推车去撞墙？
让 AI agent 去”读个网页”，听起来是最自然不过的请求，但真动手你就会发现，这门生意的水太深了。很多现代网页离了 JavaScript 渲染根本就是一张白纸，稍微复杂一点的站点还有反爬、验证码、频率限制、IP 封锁等着你，更别提各种反人类的 HTML 结构和铺天盖地的广告弹窗。我自己以前写爬虫，80% 的时间都不是在分析数据，而是在跟这些基础设施较劲：维护代理池、调 Playwright、处理 Cloudflare、写 XPath 兜底。到最后，一个原本只想”帮我看看这篇文章写了啥”的小需求，能折腾成一个小工程。
所以当我第一次看到 Firecrawl 的时候，第一反应不是”又一个爬虫工具”，而是”终于有人愿意把这套脏活打包成一个 API 了”。它不像传统爬虫框架那样给你一把螺丝刀就让你自己造车，而是直接给你一个整车：你只需要告诉它”我要什么”，它帮你解决”怎么拿到”的绝大多数问题。这种体验上的差别，可能比功能列表上的差别更重要。
02. Firecrawl 的定位：不是爬虫，是”网页上下文 API”
Firecrawl 的官方 slogan 是 “The context API to search, scrape, and interact with the web at scale”，翻译成人话就是：它把自己定位成给 AI agent 用的”网页上下文 API”。它的任务不是帮你存一堆原始 HTML，而是把网页转成 AI 能直接消化的东西——干净的 Markdown、结构化的 JSON、关键页面的截图，以及可以被 LLM 理解的元数据。这个定位很精准：传统爬虫面向的是人，Firecrawl 面向的是 agent。
项目本身也够硬。仓库有 17.5 万 star、9600 多个 fork，从 2024 年 4 月开源到现在一直保持高频迭代，最新版已经到 v2.11.0。代码主体是 TypeScript，采用 AGPL-3.0 协议开源，同时运营着一个云端托管服务 firecrawl.dev。也就是说，它既给了开源社区一条自托管的路，也给了不想折腾基础设施的人一个开箱即用的选择。这种”两条腿走路”的打法，我觉得是它能在短时间内起量的关键原因之一。
03. 五个核心端点，对应五种常见需求
Firecrawl 的 API 设计得很直接，核心端点就五个，每个解决一类典型场景。你不需要翻厚厚的文档去配参数，基本上看到端点名字就知道该用哪个。这种设计其实特别对 agent 的胃口：agent 不需要理解底层抓取策略，只需要在决策时选对工具。对开发者来说，它也省了很多”到底该用 scrape 还是 crawl”的纠结——场景和端点基本一一对应。下面是我在实际试用和读文档之后做的归纳：
| 端点 | 解决什么问题 | 典型用法 |
|---|---|---|
/search |
先搜网页，再拿内容 | 让 agent 像人一样”百度一下”，返回搜索结果并把每个结果抓取成 Markdown |
/scrape |
抓单个 URL | 给你一篇文章、一个商品页、一份文档，吐出干净 Markdown 或 JSON |
/crawl |
整站爬取 | 给一个起始 URL，自动递归抓取整站内容，适合 FAQ、文档站 |
/map |
发现全站链接 | 不深入抓取内容，只快速列出目标网站的所有 URL 清单 |
/agent |
让 AI 自己决定怎么抓 | 描述你要什么数据，agent 自动规划搜索、抓取、提取步骤 |
这里最让我感兴趣的是 /agent，它其实是从旧的 /extract 端点演化来的。你不需要提前知道数据藏在哪个 URL 里，只需要描述”我要查某公司的创始人”或者”我要列出这个电商页的所有商品”，它会自己决定搜什么、抓什么、怎么解析。这种”目标驱动”的抓取方式，跟传统爬虫”URL 驱动”的思维方式完全不一样，也更适合 LLM agent 的调用链路。另外 /scrape/{id}/interact 还能在抓取之后对页面做进一步交互，比如点击、滚动、输入文字，这对需要登录态或动态加载的页面特别有用。
04. LLM 提取：给 schema，直接吐结构化 JSON
光把网页变成 Markdown 还不够，很多时候我们需要的是结构化的字段。Firecrawl 的做法是让你定义一个 schema——用 Pydantic 模型最方便——然后它把网页内容往里套。这个能力在 /agent 里尤其好用，因为你不需要自己写正则、XPath 或者 CSS 选择器去抠字段，只需要描述每个字段的含义。
举个官方例子，如果你想查一家公司的创始人，可以这么写。注意这里的关键不是 prompt 写得多复杂，而是 schema 把输出格式提前定死了：模型不管怎么推理，最终都必须按字段填进去。Pydantic 的 Field 描述还能引导模型理解每个字段该填什么，列表、可选字段也都能直接声明。这让下游代码处理起来非常稳：
from firecrawl import Firecrawl
from pydantic import BaseModel, Field
from typing import List, Optional
app = Firecrawl(api_key="your-api-key")
class Founder(BaseModel):
name: str = Field(description="创始人全名")
role: Optional[str] = Field(description="职位")
class FoundersSchema(BaseModel):
founders: List[Founder] = Field(description="创始人列表")
result = app.agent(
prompt="Find the founders of Firecrawl",
schema=FoundersSchema
)
print(result.data)
返回的就是规整的 JSON，每个字段都在 schema 里预先定好了。这种方式的好处显而易见：第一，不用维护脆弱的解析逻辑；第二，LLM 可以直接消费结果，不用再做一次”文本理解”；第三，schema 本身就是一份文档，团队交接的时候看一眼就知道这个 agent 在抓什么。我自己的体会是，它把”抓取”和”理解”这两个步骤之间的边界打通了——你不再只是”拿到网页”，而是”拿到已经理解好的网页”。
05. 自托管还是上云？两条路，两种账
Firecrawl 提供两条使用路径。第一条是直接用 firecrawl.dev 的云端 API，注册拿 key 就能跑；第二条是把仓库 clone 下来，用 Docker Compose 在本地或自己的服务器上跑。如果你只是做几个小脚本、低频次抓取，云端是最省事的；但如果你对数据隐私、成本控制、或者定制化有要求，自托管就值得认真考虑。
自托管的最小启动步骤大致如下，以官方文档推荐的 v2.11.162 为例。整个流程就是 clone、checkout、写 .env、docker compose up，大概十分钟能把本地 API 跑起来。这个默认栈会拉起 API、PostgreSQL、Redis、RabbitMQ 和 Playwright 等一堆服务，所以本地资源要留够。不过别急着把它挂到公网——默认配置是评估环境，没有认证和 TLS：
git clone https://github.com/firecrawl/firecrawl.git
cd firecrawl
git checkout v2.11.162
cat > .env <<'EOF'
USE_DB_AUTHENTICATION=false
POSTGRES_USER=postgres
POSTGRES_PASSWORD=replace-with-at-least-32-random-characters
POSTGRES_DB=postgres
EOF
docker compose up --build -d
curl http://localhost:3002/v0/health/readiness
启动后，本地 API 监听在 http://localhost:3002，可以直接用 /v2/scrape 做测试。不过官方也强调得很清楚：这个默认配置是**评估环境**，没有持久化存储、没有 TLS、没有认证，不能拿到公网上直接用。生产环境需要自己加数据库卷、反向代理、TLS 和身份认证。这一点很诚实，也避免了很多人一上来就踩坑。
| 能力 | 自托管 | Firecrawl Cloud |
|---|---|---|
| 基础 scrape / crawl / map / search | 支持 | 支持 |
| JS 渲染与基础反爬 | 默认已包含 Playwright | 支持 |
| LLM 提取 / agent | 需接入 OpenAI 兼容或 Ollama | 开箱即用 |
| 截图、页面交互、Fire-engine 高级反爬 | 默认不支持，需额外配置 | 云端能力 |
做这张表的时候我特别注意了一下：自托管并不是云的”阉割版”，而是需要你额外把 LLM provider、代理、反爬引擎这些外部服务接进来。接不接、怎么接，完全看你的预算和合规要求。这种设计其实挺合理——它把”必须开源”的部分给你，把”需要基础设施规模”的部分留成云服务，两边都有饭吃。反过来也说明，如果你打算重度使用 agent 提取或者大规模反爬，要么花钱上云，要么花人运维自托管，没有免费的捷径。
06. 生态：SDK 多得离谱，MCP 也上了桌
除了 REST API，Firecrawl 的 SDK 覆盖也相当广。官方支持 Python、Node.js、Go、Java、Elixir、Rust、Ruby、.NET、PHP 九种语言，基本上主流后端语言都包含了。它还提供了一个 firecrawl-cli 命令行工具，以及一个 firecrawl-mcp MCP server。MCP 这条线值得单独提一句：有了它，任何支持 MCP 的 AI agent 或 IDE 插件，都能直接调用 Firecrawl 去联网查资料，而不需要你写任何桥接代码。
我用 Python SDK 试了一个最简单的场景——抓取一篇博客转成 Markdown。这个例子很能说明它的体验优势：你不需要手动处理请求、轮询、重试这些脏活，传一个 URL 和 formats 参数，拿到手的直接就是干净文本。比起自己写 requests + BeautifulSoup + html2text 那一套，代码量和心智负担都小很多：
from firecrawl import Firecrawl
app = Firecrawl(api_key="your-api-key")
doc = app.scrape("https://firecrawl.dev", formats=["markdown"])
print(doc.markdown[:500])
代码就两行核心业务逻辑，剩下的异步轮询、重试、错误处理 SDK 都包好了。作为一个平时不太愿意在工具链上花太多时间的人来说，这种”传个 URL 就给我干净文本”的体验，确实比传统爬虫舒服太多。而且因为它输出的是 Markdown， downstream 的 LLM 提示词可以直接用，不需要再写”请忽略导航栏和广告”之类的脏 prompt。
写在最后：别只盯着”方便”，也得算清楚账单和协议
Firecrawl 确实把网页抓取这件事的体验往前推了一大步，尤其是对那些不想维护爬虫基础设施、又需要给 agent 喂实时网页上下文的人来说，它的价值非常直接。但越是好用的工具，越需要你在冲动上线前把几笔账算明白。第一笔是成本账：云端是按 credits 计费的，单次抓取看起来便宜，一旦上量——比如做整站监控、批量竞品跟踪、每日新闻聚合——credits 会像水表一样哗哗转，账单可能比你预想的跑得快得多。所以在决定用它之前，最好先用小批量跑一个星期的费用曲线，再决定是否切自托管。
第二笔是运维账。自托管看起来很美好，数据不出门、成本可控，但它也把基础设施的责任完全交给你了：PostgreSQL、Redis、RabbitMQ、Playwright、worker 扩展、TLS、认证、备份、升级，哪一项都不能撒手。如果你团队里没有专门的人负责运维，自托管的快乐可能只会持续到你第一次遇到生产事故为止。官方文档里也反复强调默认配置不是生产架构，这不是客套，是真话。
第三笔是协议账。Firecrawl 开源代码是 AGPL-3.0 协议，这个协议的网络传染性很强：如果你基于它修改并对外提供网络服务，理论上需要开源你的衍生代码。直接用它的云端 API、或者直接运行它的二进制来给自己的内部脚本用，一般不构成传染性；但如果你想拿它二开做一个闭源 SaaS 产品，建议先让法务或合规过一遍。最后还想提醒一点：无论用云还是自托管，抓取网页都要尊重目标站的 robots.txt 和使用条款，工具再方便，法律责任也还是要落到使用者自己身上。
