Agent 要上网，有两条路。一条是给它一个浏览器，让它像人一样点；另一条是干脆不给浏览器，直接把网页变成结构化上下文递过去。Kitesurf 走的是前一条，Firecrawl 走的是后一条。
Firecrawl 自称"给 AI Agent 用的上下文 API"，仓库 firecrawl/firecrawl 截至 2026-11-14 约 201,700 星、10.6k fork、6,862 次提交，11 月 13 日仍有提交。核心代码采用 AGPL-3.0，SDK 和部分 UI 组件是 MIT——两种许可并存，选型时要看清用的是哪部分。
它把"读网页"拆成了几个动词
看它的端点设计，大概能明白这层基础设施在解决什么：
| 端点 | 做什么 |
|---|---|
search | 搜网页，直接返回结果页的完整内容 |
scrape | 把一个 URL 转成 markdown、HTML、截图或结构化 JSON |
interact | 先抓页面，再用提示词或代码点击、滚动、输入 |
crawl | 整站抓取，一次请求 |
map | 快速列出一个站点的所有 URL，可按关键词排序 |
batch | 异步批量抓成千上万个 URL |
parse | PDF、DOCX 等文档转 markdown 或结构化 JSON |
agent | 描述你要什么，它自己搜索、导航、取回结果 |
monitor | 网页内容变化时通知你 |
这个拆分方式值得注意：它把"抓"和"操作"分开了。scrape 是幂等的取数据，interact 才是有副作用的点击和输入。对 Agent 来说，这个区分很重要——大部分任务只需要前者，而前者的成本和风险都低得多。
interact 和 agent：两条不同的自动化路径
interact 的用法是先抓一次，拿到 scrape_id，然后对这个页面发指令：
result = app.scrape("https://amazon.com")
scrape_id = result.metadata.scrape_id
app.interact(scrape_id, prompt="Search for 'mechanical keyboard'")
app.interact(scrape_id, prompt="Click the first result")agent 则是"不给 URL 也行"，直接描述需求，比如"找出 Notion 的定价方案"，返回结果和来源链接；也可以传 schema 拿结构化输出。官方文档里，agent 的 effort 分 low / medium / high 三档，并明确写了：三档跑的都是同一个 spark-2 模型，改的是推理预算，不是换模型。这句话很有用，能挡住一批"高档用的是更强的模型"的误读。
接进 Agent：技能和 MCP 两条
技能方式是一条命令：
npx -y firecrawl-cli@latest init --all --browser装完要重启 Agent。官方列的支持名单包括 Claude Code、Antigravity、OpenCode 等。MCP 方式还是老配置：
{
"mcpServers": {
"firecrawl-mcp": {
"command": "npx",
"args": ["-y", "firecrawl-mcp"],
"env": {
"FIRECRAWL_API_KEY": "fc-YOUR_API_KEY"
}
}
}
}这里有个细节挺有意思：仓库里直接放了一份给 Agent 看的 onboarding 文档，curl https://firecrawl.dev/agent-onboarding/SKILL.md 就能拿到"怎么替用户注册、拿 key、开始用"的步骤。也就是说，它把"Agent 自己会装工具"当成了一条正式入口，而不只是人类照着 README 操作。
几个数字，以及它们的分量
官方宣传里最抓眼的是两个：覆盖 96% 的网页（含 JS 重的页面）、P95 延迟 3.4 秒。两条都附了自家基准页面的链接，也就是说，这是厂商自测口径，不是第三方复现。
这类数字的正确读法是：它说明厂商在这个指标上做过系统测量，不能说明你的目标站点一定在覆盖范围内。真实项目里，决定成败的往往是那几个反爬特别凶、或者必须登录才看得到的页面——这类站点在任何"覆盖率"里都属于长尾。
开源版和云版的差别，别忽略
AGPL-3.0 意味着：如果你改了它并作为服务对外提供，需要按 AGPL 开源你的修改。自己内部用、或者只是调云 API，不受这条影响。
功能上也不是一套东西。官方 README 明确写了云版有额外能力，其中最典型的是 Alexandria——一个接入了 400 多个数据提供方和专门索引的目录，Agent 可以在网页结果旁边发现工具、看输入和价格、再执行拿结构化数据。这条只在 Firecrawl Cloud 上跑，自托管版本不包含；本地版要登录后才行。
所以"开源自托管"买到的是抓取引擎，不是完整的云端能力。选型时如果冲着 Alexandria 去，那就不是"自托管省钱"的问题了。
合规这件事，README 自己写了
原文的意思很清楚：遵守目标站点政策是最终用户的责任；默认会尊重 robots.txt；使用即表示同意这些条件。翻译成人话——工具默认守规矩，但你让它去抓什么、抓多少、抓来做什么，责任不会因为"是工具抓的"而转移。
这一点和 Agent 浏览器那条路线是一组对照：自己搭浏览器，等于自己承担 IP、频率、被封的风险；用这类 API，等于把技术风险外包，把合规责任留在自己身上。
该信多少
- 本文读了仓库 README、端点文档和许可说明，没有注册、没有调 API、没有跑抓取。
- 约 201,700 星、10.6k fork、6,862 次提交为 2026-11-14 抓取；项目创建于 2024 年 4 月，不是新产品。
- 96% 覆盖、P95 3.4s 均为官方基准口径，无第三方复核；不同站点差异会很大。
- 云版与自托管的功能差异，以官方 README 与文档为准，本文只列了 Alexandria 这一处最明显的。
一句话判断
Firecrawl 的 20 万星说明的不是"抓网页"这件事有多新，而是它已经变成 Agent 栈里独立的一层：模型不该为了读一段文字去开一个浏览器。它适合"要内容、不要交互"的任务；一旦需要登录态、需要点、需要等异步渲染完再判断，还是得回到浏览器那条路——两条路不是替代关系，是分层。
来源
- firecrawl/firecrawl（README、端点、SDK、许可与合规说明；约 201,700 星，2026-11-14 读取）
- Firecrawl 文档（agent、interact、Alexandria）
- firecrawl-mcp-server（MCP 接入）
说明：本文为官方文档解读，未调用 Firecrawl 服务；覆盖率与延迟为厂商自测口径。核心代码 AGPL-3.0，SDK 为 MIT。
——诺谱