Firecrawl vs Tavily评测: 事实召回率97% vs 82%

我在运行一个竞品调研 Agent：给它一个公司 URL，它会找到并验证该公司的竞品。整个系统不依赖任何框架（就是跑在 Gemini 上的原始工具调用循环），并且有一个确定的伪造检查机制：Agent 引用的每个页面都必须在我代码实际抓取过的页面台账里。

最初只用了 Tavily 做检索。后来我把 Firecrawl 加进来，作为第二个后端接入 Provider 开关，并对两者做了基准测试。以下是我的发现，包括 Firecrawl 失利的地方。

测试了 10 家公司、20 个页面，选取标准是网站类型多样化：JS 重度应用、以文档为主的开发者工具网站、定价页面、早期初创公司页面（内容稀疏）。

一份标准答案，用每个官网页面做了交叉验证（定价层级、产品名称、标语、YC 批次）。每条事实都通过纯 HTTP 请求直接查原始 HTML 做审计，不经过任何 Provider。修正记录在仓库里。

两组实验：A，纯检索：每次抓取页面两次，不涉及 LLM，打分哪些事实在内容里出现了。B，端到端：保持模型、Prompt 和温度不变，跑完整 Agent。

A，纯检索：每次抓取页面两次，不涉及 LLM，打分哪些事实在内容里出现了。

B，端到端：保持模型、Prompt 和温度不变，跑完整 Agent。

实验 A：检索质量

Firecrawl 找到了更多重要事实。它大约慢 5.6 倍，按官方定价来看每页面 credit 成本大约是 5 倍。

Tavily 的高级提取档没起作用：在 20 个页面中的 19 个上，它返回的内容和基础档完全一致（字节级相同），有一个页面（docs.firecrawl.dev/billing）它返回了 404 而基础档成功了。我用原始 API 调用（不经过我的代码）复现了这个问题。

样板内容过滤有真实代价

Firecrawl 的 only_main_content=True 会去除导航栏和页脚。我测了开关两种情况：

有三个页面是免费的。在 notion.com 上它把导航菜单里的产品名称去掉了，而那恰恰是我需要的那一条事实。要找回它意味着要承受 45% 的样板内容。通常免费，偶尔代价高昂。

实验 B：检索广度决定落地效果

惊喜来自端到端运行。按 Agent 参考了多少个来源来汇总所有模式：

每次低来源调用都来自我的同一种配置：Firecrawl search + 全页面抓取，每次搜索最多 3 条结果以节省 credit。来源越少，Agent 搜索次数越多，越容易触发 9 次调用的预算上限，也越容易引用从未实际检索过的页面。

伪造检查捕获了所有这些引用。没有任何一条进入最终报告。

教训：让 Agent 缺乏来源，它就会引用从未读过的页面。看起来像是幻觉问题，实际上是检索问题。

有一点我需要明确：所有 9 次低来源运行都使用了同样的 3 结果配置，所以在这个数据里广度和配置无法分离。它展示的是相关性而非孤立因果关系，这是关于我的设置的发现，而非关于 Firecrawl 质量的结论。

Firecrawl 的缺点

p50 延迟高约 5.6 倍。

每页面和每次端到端运行的 credit 消耗更高。

在 brickanta.com 上它丢弃了英雄区标题和段落，却保留了 YouTube 嵌入的外框，可复现。

样板内容异常值更差（最高 23% 对比 15%）。

上述 Notion 导航的权衡。

用 Tavily search 搭配 Firecrawl 抓取（我的"混合"模式）成本和纯 Tavily 一样，但没有测得的好处。

给选型者的建议

如果事实覆盖在混乱的真实页面上最重要，Firecrawl 值得付出延迟和成本。

如果需要速度和低成本，Tavily basic 很强。

无论如何，给你的 Agent 足够的每次搜索来源数。广度对落地效果的影响比选哪家供应商更大。

局限性

10 家公司、20 个页面：样本量小。

端到端运行横跨两天，网站可能在此期间发生变化。

部分运行因 Gemini 免费配额限制被排除。排除数量按模式计入结果。

Tavily 的成本对比使用官方定价，非实测消耗。

标准答案措辞在根据原始 HTML 审计后做了修正，然后才做最终运行。每次变更都有记录。

我用 Firecrawl 本身抓取了 firecrawl.dev。

方法、原始结果、标准答案和变更日志都在仓库里：https://github.com/sravya520/competitor-research-agent/blob/main/docs/firecrawl_vs_tavily.md

欢迎反馈，尤其是调过 Firecrawl 或 Tavily 配置用于 Agent 工作负载的朋友。