一个普通电商详情页的原始 HTML，塞满导航栏、cookie 弹窗和埋点脚本，能轻松跑到 1.2 万到 4 万 token。你的 Agent 要跑一个"调研 100 个竞品页面"的任务，光是把网页塞进上下文，预算就先烧掉一大半，模型还没开始推理。
这不是模型不够聪明，是喂给它的东西太脏。过去两年大家忙着卷模型能力，卷到今年才发现，真正卡住 Agent 落地的常常是最不起眼的那一步：把开放网页变成可控的结构化输入。
firecrawl 就是在赌这件事会变成基础设施。它在 GitHub 上已经攒了超过 16.4 万颗星，被 Shopify、Zapier 这类公司用在生产环境里。这篇文章拆开看看它到底解决了什么问题，值多少钱，什么时候你该自己动手写爬虫。
一、Agent 的上下文瓶颈到底在哪
先说清楚一个容易被忽略的事实：Agent 执行任务时，每一步都要把累积的上下文重新喂给模型一遍。任务越深，token 消耗不是线性增长，是接近平方级增长的。这意味着抓取阶段哪怕只多塞 20% 的噪音，放大到十几步的任务链条里，成本可能翻倍不止。
而多数原始网页抓取工具，扔给你的就是没洗过的 HTML 页面全量转储，导航栏、脚本标签、样式代码全都在里面，真正有信息量的正文可能不到 10%。你要么自己写一层清洗逻辑，要么让模型花 token 去从垃圾里挑金子，两个选择都是成本。
行业内的说法是，用 Readability 之类的清洗手段把原始 HTML 转成干净 markdown 后，同一批页面能省下 80% 到 95% 的 token 开销。这不是玄学，是实打实的账本问题。
所以"抓取层"这几年悄悄从一个爬虫工具的定位，升级成了 context engineering 里的前置工程。它不再只是"能不能拿到数据"，而是"拿到的数据能不能被模型高效消化"。firecrawl 的定位很直白，官方把自己叫做"context API"，管的就是搜索、抓取、网页交互这三件事，专门给 Agent 供料。
这也是为什么它的增长曲线这么陡。它的前身是 Mendable，一个做 RAG 平台的团队，服务过 Coinbase、Snap、MongoDB 这些客户。2024 年 4 月，团队把底层的抓取基础设施拆出来单独发布，三个月攒了 8000 多颗星，同年 7 月正式登上 Y Combinator。到今天，官方口径是服务超过 35 万开发者，仓库星数破了 16 万4 千。
二、firecrawl 能力清单与踩坑点
firecrawl 的能力边界比一个"爬虫库"要宽不少，按官方仓库的划分，核心有七块：
| 能力 | 干什么 | 备注 |
|---|---|---|
| Scrape | 单页转 markdown / HTML / 截图 / 结构化 JSON | 最基础的调用，1 credit/页 |
| Crawl | 一次请求抓完整个站点的所有 URL | 会自动跟随内部链接 |
| Map | 秒级列出网站所有 URL，不抓内容 | 适合先摸清站点结构再决定抓哪些页 |
| Search | 联网搜索并直接拿到结果页正文 | 2 credit/10 条结果 |
| Interact | 用 AI 指令或代码动作操作页面 | 处理登录、点击、滚动这类交互场景 |
| Agent | 用自然语言描述任务，自主完成数据采集 | 目前是 Preview 阶段，每天 5 次免费额度 |
| Batch Scrape | 批量异步处理多个 URL | 适合大规模任务 |
调用方式很轻，一段 Python 代码就能跑起来：
from firecrawl import Firecrawl
firecrawl = Firecrawl(api_key="fc-YOUR-API-KEY")
doc = firecrawl.scrape("https://example.com", formats=["markdown", "html"])
print(doc)
也能直接用 cURL，甚至不用 API key 就能试跑基础请求：
curl -s -X POST "https://api.firecrawl.dev/v2/scrape" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer fc-YOUR-API-KEY" \
-d '{"url": "https://example.com", "formats": ["markdown", "html"]}'
这套东西对付静态站点毫无压力，真正的价值在于它内置了动态渲染和反爬处理，你不用自己配 Playwright、维护浏览器实例、处理验证码重试逻辑。这部分省下来的工程时间，往往比 API 调用费本身值钱得多。
不过几个坑得提前知道。
第一，它是开源的，核心仓库用的是 AGPL-3.0 协议，SDK 和部分 UI 组件是 MIT。AGPL 对商用有传染性条款，如果你把它魔改后作为对外服务提供，理论上要开源你的修改。用官方托管的 API 没这个顾虑，但如果打算自托管并二次开发对外卖服务，这一条得让法务过一遍，别等上线了才发现。
第二，Search 和 Interact 的计费方式跟 Scrape 不一样，一个按结果条数，一个按浏览器分钟数。如果你的 Agent 任务里大量用到需要登录态或者要滚动加载的页面，Interact 的分钟计费很容易比纯 Scrape 贵出好几倍，得提前估算。
第三，免费额度是每月 1000 credit，对应大概 1000 页。个人验证想法够用，一旦进入生产环境批量抓取，很快就得升级付费档位。
一个容易被忽略的细节：Map 这个功能不占用抓取成本，先用它摸清一个站点有多少个 URL、结构长什么样，再决定用 Crawl 全量抓还是用 Scrape 精准抓几页，能省下不少无谓的 credit 消耗。
三、价格对照表
抓取这条赛道玩家不少，计费逻辑差异很大，直接摆开对比更直观。以下价格均为各家官网 2026 年 8 月的公开数据。
| 服务 | 免费额度 | 入门付费档 | 计费单位 | 备注 |
|---|---|---|---|---|
| firecrawl Free | 1,000 credit/月 | 无 | 1 credit ≈ 1 页 scrape | 2 并发请求 |
| firecrawl Hobby | 含在付费内 | $16/月（年付口径） | 5,000 credit/月 | 5 并发 |
| firecrawl Standard | 含在付费内 | $83/月（年付口径） | 100,000 credit/月 | 50 并发，标准支持 |
| firecrawl Growth | 含在付费内 | $333/月（年付口径） | 500,000 credit/月 | 100 并发，优先支持 |
| firecrawl 自托管 | 不限量 | 服务器成本自理 | 无 credit 上限 | AGPL-3.0，需自己扛反爬和渲染 |
| Jina Reader (r.jina.ai) | 无 key 约 20 次/分钟 | 按 token 计费 | $0.02 / 百万输出 token | 新 key 另送千万级免费 token |
| Apify | $5 免费额度/月 | $29/月起 | 按 Compute Unit 计费，$0.20~$0.30/CU | 适合跑现成的社区 Actor |
| Browserbase | 1 浏览器小时 | $20/月起 | 100 浏览器小时/月起 | 侧重完整浏览器会话而非单页抓取 |
从这张表能看出几个定位差异。Jina Reader 走的是极简路线，一个前缀 URL 就能白嫖，适合轻量、临时性的单页转 markdown，但它不管爬全站、不管交互。Apify 是平台型打法，卖的是几千个现成的社区 Actor（爬虫脚本），你缺什么直接买现成的跑，但要熟悉它的生态才划算。Browserbase 本质是"云浏览器"而不是"抓取 API"，按浏览器会话时长计费，更适合需要真实浏览器环境跑复杂交互流程的场景，比如自动化测试或者需要保持登录态的长会话任务。
firecrawl 卡在中间，把 Scrape / Crawl / Search / Interact 打包成一套 API，价格按页和按分钟混合计费，胜在开箱即用的完整度。自托管这条路径也留着，AGPL 协议下代码全部公开，服务器成本自己扛，换来的是没有 credit 天花板。
四、什么时候该自己写爬虫
不是所有场景都该用现成 API。判断标准其实很简单，看你的抓取需求落在哪个象限。
如果目标网站数量少、结构固定、更新频率可预期，比如你只盯着 3 个竞品的价格页做每日监控，自己写一个 requests + BeautifulSoup 的轻量脚本，成本可能比按月订阅任何一个 API 都低，而且没有第三方服务的依赖风险。
如果目标是大规模、结构不可预测的开放网页，尤其涉及大量动态渲染、反爬对抗、验证码处理，自己维护这套基础设施的边际成本会迅速超过订阅费用。反爬规则天天在变，专门养一个团队跟这场军备竞赛，对大多数团队来说不划算。这正是 firecrawl 这类服务的核心卖点：把你从这场军备竞赛里解放出来。
还有一种情况是数据敏感度和合规要求特别高，比如涉及内部系统或者需要严格的数据留存审计，这时候自托管开源版本比调用任何第三方 API 都稳妥，虽然要自己扛运维，但数据不出你的边界。
一个务实的判断方式：先算清楚你的抓取任务里，“处理边缘情况”（反爬、动态渲染、异常重试）占了多少工程时间。如果这部分超过整个任务一半的开发精力，大概率该交给专门的抓取层来做，自己的团队应该把时间花在业务逻辑上。
Agent 时代对抓取层的要求，已经从"能拿到数据"变成"拿到能直接喂给模型的数据"。这个门槛看着不高，做扎实了却是一整套工程。firecrawl 选择把这件事做成标准化 API，赌的就是这层需求会持续存在，而且会随着 Agent 数量增长而增长。
写在最后
抓取层这两年悄悄从"爬虫工具"升级成了"Agent 基础设施"，这个判断本身值得留意。选型上没有标准答案：轻量单页用 Jina Reader，大规模开箱即用选 firecrawl，需要现成脚本生态用 Apify，需要完整浏览器会话用 Browserbase，数据敏感或者规模小到可控就自己写。关键是先算账，再选工具。
参考资料：