在为 AI Agent 构建网络检索能力时，开发者往往要在事实召回率、速度、成本和接口稳定性之间做取舍。开发者 Sravya Dangeti 在一套基于 Gemini 原生工具调用循环的竞对调研 Agent 上，对 Tavily 与 Firecrawl 两种检索后端进行了对比测试。结果显示，Firecrawl 在事实召回上达到 97%，高于 Tavily 的 82%，但其运行速度约为 Tavily 的 1/5.6，按公开价格计算单页积分成本也约为 Tavily 的 5 倍。
这套 Agent 的任务并不复杂：输入一家公司的 URL，系统自动查找并验证该公司的竞争对手。作者特别强调，该 Agent 没有使用任何框架，仅依赖原始工具调用循环，并内置了一个确定性的“虚构引用检查”机制：Agent 最终引用的每一个页面，都必须出现在代码实际抓取过的页面账本中。因此，这项测试关注的重点不只是模型是否“答得出来”，还包括其引用是否真正来自已获取的网页内容。
Firecrawl 召回更高，但代价是更慢、更贵
从核心指标看，Firecrawl 能够找到更多与任务相关的事实。素材给出的对比结果是：Firecrawl 事实召回率约 97%，Tavily 约 82%。对于需要尽量覆盖公开网页信息、再交由 Agent 推理和验证的场景，这一差距具有直接意义。
但更高的召回并非没有成本。作者指出，Firecrawl 的端到端运行速度大约慢了 5.6 倍；如果按照公开定价估算，其单页积分成本约为 Tavily 的 5 倍。这意味着在高频调用、批量抓取或对延迟敏感的 Agent 工作流中，Firecrawl 可能不再是默认选项。
- Firecrawl 事实召回率：约 97%
- Tavily 事实召回率：约 82%
- Firecrawl 速度：约慢 5.6 倍
- Firecrawl 单页积分成本：约为 Tavily 的 5 倍
作者同时提到，Firecrawl 并非在所有环节都占优。在部分场景中，它的网页内容清洗策略反而造成了关键信息丢失。
Tavily 高级抽取收益有限，Firecrawl 内容过滤存在边界问题
测试还观察了两个服务的具体功能表现。Tavily 的 advanced extract 层级并未带来明显增益。作者在 20 个页面中发现，有 19 个页面返回的内容与 basic 层级完全一致；在唯一出现差异的页面 docs.firecrawl.dev/billing 上，advanced extract 返回了 404，而 basic 模式成功获取内容。作者还通过代码外部的原始 API 调用复现了这一结果。
Firecrawl 的 only_main_content=True 参数则呈现出另一种典型问题。该参数用于剥离导航栏和页脚等非正文内容，在多数页面中确实可以减少无关信息；但在 notion.com 页面上，它把导航菜单中的产品名称也一并移除了，而这恰恰是作者在该任务中需要保留的关键事实。为了重新获取这一信息，页面中混入了约 45% 的模板化内容。作者将其概括为：这类过滤在多数时候是“免费收益”，但偶尔会带来较高代价。
低来源运行时更容易出现未检索引用，问题指向检索宽度
这次测试中更值得 Agent 开发者注意的，是端到端运行阶段暴露出的“低来源”问题。作者将所有模式按 Agent 实际参考来源数量汇总后发现，全部低来源运行都来自同一个配置：使用 Firecrawl 搜索并配合整页抓取，但为了节省积分，将每次搜索结果上限设为 3 条。
在该配置下，Agent 可获得的来源数量更少，于是它进行了更多搜索，更频繁触达 9 次调用预算，并引用了从未实际抓取过的页面。由于作者设置了确定性检查，这些引用全部被拦截，没有进入最终报告。
作者由此得出一个谨慎结论：当 Agent 被限制可访问来源数量时，它更容易引用未读页面。这类现象表面上像模型幻觉，实质上更接近检索供给不足带来的问题。不过，作者也明确说明，所有 9 次低来源运行都来自同一配置，因此该数据只能说明“检索宽度”与结果之间存在关联，尚不能将其与具体配置完全拆开，形成独立因果证明；这更多是作者自身设置下的发现，而不是对 Firecrawl 产品质量的直接判定。
对 Agent 开发者的启示：别只看模型，也要看检索供给
这项测试的价值，并不在于简单判断“谁更强”，而在于呈现了 Agent 检索系统常见的权衡结构：更高的召回往往伴随更慢的响应和更高的成本；内容过滤可以减少噪声，但也可能误删关键事实；而为了节省预算限制来源数量，则可能让 Agent 在推理阶段出现未验证引用。
作者还测试了一种混合方案：使用 Tavily 搜索，配合 Firecrawl 抓取。结果显示，该模式成本与纯 Tavily 相同，但没有带来可测量的收益。这说明不同检索服务的组合并不天然产生增益，实际效果仍取决于具体任务、配置和调用链路。
目前，作者已将测试方法、原始结果、答案对照和变更记录公开在 GitHub 仓库中。对于正在搭建研究型、验证型或自动化网页浏览 Agent 的团队而言，这组数据提醒开发者：在评估 Agent 质量时，不能只盯着模型输出，还要同时审视检索层能覆盖多少来源、以什么成本覆盖，以及是否保留了完成任务所需的关键信息。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/agent-jian-suo-shi-ce-firecrawl-shi-shi-zhao-hui-you-yu
