Firecrawl 19.7 万 Star，可它跟我 agent 里那个联网搜索到底差在哪？
我把同一篇公众号文章分别丢给我的联网搜索和 Firecrawl，前者还我一段摘要，后者还我 3.5 MB HTML 里那 2051 个字的原文。
这就是全部差别的起点。不是「一个能上网一个不能」，是「一个替你消化，一个给你原料」。
先摆数据，再说人话。
一、它到底是个啥
Firecrawl 是个 HTTP 接口。你 POST 一个 URL，它回你一份干净的 markdown。就这么朴素。
我查了它今天的仓库状态：197,808 star，10,453 fork，176 个贡献者，745 个 open issue，2024 年 4 月建的库，TypeScript 写的，AGPL-3.0。
下载量比 star 更能说明问题：
npm 包 firecrawl 一个月 306 万次；@mendable/firecrawl-js 454 万次；PyPI 的 firecrawl-py 534 万次。三个加起来一个月一千三百万。
这个量级说明是真有人在用，不是刷出来的 star 空转。
接口核心三个：
Scrape，给一个 URL，出 markdown / HTML / 截图 / 结构化 JSON。
Search，搜一个词，出的是每条结果的完整正文，不是链接加两行摘要。
Interact，抓完页面还能点、能滚、能填表单。
往外扩还有 Crawl（整站爬）、Map（秒列全站 URL）、Batch Scrape（几千个 URL 异步跑）、Monitor（内容变了通知你）、Agent（连 URL 都不用给，说清楚要啥它自己去翻）、Parse（PDF / DOCX 转 markdown）。
最实在的是它把脏活打包了：代理轮换、等 JS 加载完、频率控制。它自己发的基准是一千个网址 96% 成功率，对手 Puppeteer 79%、cURL 75%。这个数字我后面要泼冷水，先记住。
· · ·
二、跟我 agent 里的联网搜索，到底差在哪
这是你最该问的问题，也是这篇文章最值钱的一段。
我干活的时候手上就有两个工具：一个搜，一个抓。它们的输出长这样——搜索给我十条结果，每条一句半摘要；抓取给我「我问什么它答什么」。
问题就在这：中间有个模型。
模型决定搜什么 → 搜索引擎返回链接 → 模型去读 → 模型给你一段话
你拿到的从来不是网页，是网页被模型消化之后的产物。消化是好事，省 token；但消化是有损的，而且不可复现——同一个 URL 问两遍，措辞不一样。这东西没法入库，没法 diff，没法当证据。
Firecrawl 的 scrape 这条路，中间没有模型。HTTP 进，markdown 出。你要原文就是原文，要什么格式给什么格式。
差别摊开是这张表：
| 维度 | Agent 的 web-search | Firecrawl |
|---|---|---|
| 谁在用 | 模型在对话里顺手调 | 你的代码直接发请求 |
| 中间有没有模型 | 有，搜→读→摘要→答 | scrape 这条路上没有 |
| 你拿到什么 | 一段被消化过的答案 | 原文、JSON、截图 |
| 可复现吗 | 不能，每次措辞都变 | 能，同一个 URL 同样输出 |
| 能入库吗 | 存摘要意义不大 | 原文加元数据，能检索能 diff |
| 结构化输出 | 靠模型「照着答」，会飘 | JSON schema 硬约束 |
| 整站 / 批量 | 做不到 | Crawl / Map / Batch |
| 变更监控 | 无状态，做不到 | Monitor 端点 |
| 谁维护反爬 | 平台方 | 云版平台方，自托管你自己 |
| 成本 | 含在模型调用里，感知不到 | 按 credit 算，真金白银 |
再补一句最本质的：你调 web-search 的时候你是用户，你调 Firecrawl 的时候你是开发者。
用户解决「我现在想知道」，开发者解决「我的系统得一直知道」。
这就是为什么 star 数那么高——写 agent 的那帮人真的需要这个，而用 agent 的那帮人不需要。你在哪一边，决定你要不要用。
· · ·
三、那你为什么该用它
三条，不多。
第一，你要原文。要把别人的东西存进自己的库、要在自己的代码里二次处理、要能溯源。摘要满足不了这个，摘要的本质是别人嚼过一遍。
第二，你要「一直知道」，不是「现在知道」。Monitor 这个端点是 web-search 结构上做不到的——它是无状态的，它记不住上次这个页面长什么样。
第三，你不想自己维护 Playwright 加代理池。这东西你自己搭能搭，搭完三个月不管就烂，烂了还得你半夜起来看。
反过来说，你要只是想问 AI 一个问题，明天就忘，别折腾，用自带的搜索。
· · ·
四、我能拿它干的五件事
站在我这个位置——PHP 服务端，写 Workerman / Webman，维护一个 Z-Blog 博客，嘴上天天说数据驱动——具体能干的活是这些。
① 选型对比表别再手抄了
我这两年一直在干一件事：比 PHP 的库。request-sdk 对 Guzzle，Workerman 对 Swoole，这个 ORM 对那个 ORM。每次比完都得手动去 Packagist 查下载量、去 GitHub 查 star，抄进文章里。过俩月有人问起，数据又旧了。
现在的写法：一个 cron，每月 1 号跑。Scrape 打 Packagist 的包页面，给个 schema（包名、总下载、月下载、收藏数），再打一次 GitHub API，写进 MySQL 一张对比表。博客那个页面直接读表渲染。
以前是半小时手工活，现在是一次性写 80 行代码，之后零成本。这才叫「数据驱动」——数据自己会来，不靠我勤快。
② 博客几百篇的外链，该体检了
jiangtian.top 从 2023 年写到现在，几百篇文章。文里引的外链，死掉的肯定不止一两个，我自己都不知道有几个。
先用 Map 一次拉出全站 URL（一秒的事），再用 Batch Scrape 把每篇正文抓回来，正则提 href，去重，批量发 HEAD 看状态码。出一张死链清单，我慢慢补。
这个活 web-search 干不了——它连你站里到底有哪些 URL 都不知道，它只能搜到「别人转载了你的哪篇」。
③ 把别人的技术文章「存进库」
比如我这次要评的这篇公众号文章。web-search 给我一段摘要，我存摘要没意义，三个月后我自己都看不懂那几句话在说什么。
Firecrawl 给我全文 markdown，能进 SQLite，能进向量库，以后搜「Firecrawl 自托管 限制」能直接召回来。写文章要引别人的观点，能点回原文，这是底线。
补一句：自己看随便存，整站搬别人的东西不行，这条线别越。
④ 盯上游变更，防事故
PHP 8.4 的 changelog、Workerman 的 release notes、Webman 的版本号、某个依赖的 breaking change。这些我平时靠刷群，经常刷到的时候线上已经踩了。
Monitor 给它一个 URL，内容一有变化就推给我。这套东西自己写要维护 diff 加去噪（导航栏换个日期就能触发误报），它一行配置。
这个场景最值钱，因为它不是「查资料」，是「防事故」。
⑤ 给 Webman 服务加个「URL 转正文」的接口
假设要给客户做个内容聚合，或者客服机器人要能读用户甩过来的链接。这事不需要 agent，需要一个接口。
PHP 这边就是 Guzzle 发个 POST：
$resp = $client->post('https://api.firecrawl.dev/v2/scrape', [
'headers' => [
'Authorization' => 'Bearer fc-你的KEY',
'Content-Type' => 'application/json',
],
'json' => ['url' => $url, 'formats' => ['markdown']],
]);
$data = json_decode($resp->getBody(), true);
$md = $data['data']['markdown']; // 字段名以官方文档为准官方有 PHP SDK（firecrawl/firecrawl-sdk），但底下包的也是 Guzzle。我倾向直接发请求，少一层依赖，少一个版本冲突。两百行以内能上线。
上面五条之外，还送一条：不知道数据在哪个页面的时候，用 Agent。描述一句「XX 站 PHP 版本的月下载量」，它自己去搜、去点、去翻，省掉写选择器的两小时。不过这功能按次计费（每天 5 次免费），别放线上，当一次性工具用。
· · ·
五、挑刺：九条
好话到此为止。以下是我站在「PHP 服务端、抠成本、讨厌营销话术」的立场挑的。
1. Star 数在这个项目上是营销数字，不是技术指标。
Firecrawl 2024 年 4 月建库，两年半 19.7 万 star。Playwright 2019 年就有了，至今 99,091。Puppeteer 2017 年，95,789。crawl4ai 86,760。Crawlee 26,315。
它用两年半干了 Playwright 七年的两倍 star——而它自己底下跑的就是 Playwright。
更直白的两件事：README 里明写着「Pst. Hey, you, join our stargazers :)」，还专门做了个 Agent Onboarding 接口，让 AI agent 自己去注册账号。
这不是技术胜利，这是增长手段。star 数能说明「这东西被看见了」，说明不了「这东西写得好」。
2. AGPL-3.0。这条比 star 重要一万倍。
主项目 AGPL，只有 SDK 和部分 UI 是 MIT。你拿它改成对外服务，改动部分得开源。内部工具随便用；要包装成产品卖，先把协议读完，或者直接去谈商业授权。这跟「能不能用」是两回事。
3. PHP 是末等公民。
官方 PHP SDK 一个月下载 1.75 万次。Guzzle 一天 60 万次。差着三个数量级。
意思是：PHP 这边踩坑，没人替你踩。翻 issue 全是 Python 和 Node 的。而且那个 SDK 底下包的就是 Guzzle——那我为什么不直接发 POST？
4. 自托管是个体力活。
docker-compose 里七个服务：api、playwright-service、worker、redis、rabbitmq、nuq-postgres、foundationdb，还得单独一个 init。
我这台是 4 核 Intel Mac。这套东西跑起来，风扇能起飞。
更气人的是：自托管的 Search 还得自己接第三方搜索 API（SearchApi 或者他们自己的 Fire-engine），因为搜索这一层没开源。你以为省了钱，其实省的正好是最值钱的那部分能力。
5. 免费额度是钩子。
1000 credits：1 页 1 credit，搜 10 条结果 2 credits，用 JSON 输出每页再加 4，Interact 按浏览器分钟算 2 credits。写两篇文章就见底。
真要用，$19 一个月才 5000 credits，10 万 credits 要 $99 一个月。对个人开发者不算便宜。
6. 96% 成功率是他们自己发的榜。
对手 Puppeteer 79%、cURL 75%，数据全在他们自己博客上，没有第三方复现。不是造假，但它也不是你能拿去当证据的东西。真在意就自己拿二十个目标站跑一遍，比看榜靠谱。
7. 745 个 open issue。
迭代快是好事，也是坏事。API 从 v1 到 v2 动过 breaking change，你今天写死的调用，明年可能要改。上线前锁版本，别用 latest。
8. 「藏在登录后面的它都能处理」是话术。
技术上也许能。但你拿别人登录态抓数据，合规责任全在你身上。那篇文章后面自己也补了一句「责任落在用的人身上」——那前面就别吹那么响。
9. 它不解决「搜得准」。
Search 只是把搜索引擎的结果抓回来洗干净。搜索本身给你一堆烂页面，它给你的就是一堆烂页面的漂亮 markdown。垃圾进，垃圾出，只是垃圾变整齐了。
· · ·
六、所以到底用不用
四句话，对号入座：
你要的是「一直知道」，不是「现在知道」——用。
你要原文不要摘要，要结构化字段不要一段话——用。
你只是问 AI 一个问题，明天就忘——别用，自带的搜索够了。
你要做成对外卖的 SaaS——先把 AGPL 读完再说。
我自己的结论：这钱值得花，但不是花在「让 AI 能上网」上。那是它宣传的卖点，也是它最被高估的部分。
值得花在「我的系统需要一个稳定的、可复现的、能存能 diff 的网页数据管道」上。
19.7 万 star 说明它被看见过。用不用，看你手上有没有那个管道。
发表评论: