Exa、Tavily、Brave Search 与 Firecrawl：智能体该如何搜索网页的四种下注

速览

四个都在回答"搜索网页"的产品，各自占着这层栈下面四个不同的层。

这些是撰稿时的标价，而且它们会变——这个市场上，免费额度尤其常在很短的通知下被撤走。请把这一列读作"四家价格差不多"，而不是一张排行榜。

问题之前的那个问题

在这四家之间做选择之前，先确认你是否需要其中任何一家。如今每一家前沿模型厂商都提供了跑在模型调用内部的托管网页搜索工具——你打开一个开关，模型自行决定何时去搜，结果带接地与引用，你这边一行检索代码都不用写。对于一个回答"这周发生了什么"的通用助手，那几乎总是正确答案；转而去接第三方 API，买来的是你要永远维护下去的复杂度。

用专门搜索 API 的理由更窄，值得说准确：当你需要看见并塑造结果时才用它——按域名过滤、控制时效窗口、给进入上下文的文本量设硬上限、激进地做缓存、把同一个查询跨厂商跑一遍，或者从内置工具够不到的地方去搜。那是一个检索工程问题，也正是本文余下部分要谈的问题。

Brave Search——深入

它拥有什么

Brave 跑自己的爬虫和自己的索引——官方宣称超过 400 亿页面——并且不转售别家引擎的结果。在一个不少"独立"搜索 API 其实是 Bing 或 Google 数据之上的聚合层的市场里，这是那个值得为之付费的结构性事实：别人的转售协议改了，你的检索不会因此消失。

你拿回什么

经典形态的网页结果：标题、URL、几十个词的摘要，外加元数据。它是关键词加排序的搜索，针对时效性做过调优、针对 SEO 垃圾做过对抗，而且在各家评测中稳定处于速度最快的一端——在有些竞品要花好几秒的场景里，它做到了亚秒。

它让什么变难

下游的一切。如果你的智能体需要页面正文，就得自己去取、必要时渲染 JavaScript、剥掉导航栏、处理那些拦你的站点。那是一个真实的工程面，而它恰恰就是 Firecrawl 存在着要卖给你的那个面。

Exa——深入

它拥有什么

自己的爬取，并且按语义而非关键词匹配来建索引。实际后果是一种这里别家都没有的查询模式：把一个 URL 交给 Exa，让它找出像它的页面。对于"再帮我找十二家在做这家公司同样事情的公司"，这不是关键词搜索的更好版本——它是另一种操作，而它的替代方案是一个开着四十个浏览器标签页的人。

你拿回什么

默认是链接；按需返回页面正文或由模型抽出的高亮片段。高亮是那个有意思的中间档：只给相关段落而不给整篇文档，而这正是智能体上下文真正想要的形态。

它让什么变难

对普通网页的覆盖。Exa 的爬取偏向信息密度高的内容——论文、博客、新闻、代码仓库——这就是它做研究极好、而回答"某家店的营业时间"不靠谱的原因。拿长尾事实问题去问它，等于要求一个专业索引去当通用索引。

Tavily——深入

它拥有什么

检索之后的那一层。Tavily 有自己的爬虫，但也聚合第三方索引数据，然后在上面架一个模型阶段来重排、浓缩、并可选地作答。它按额度计费——基础搜索 1 个额度、高级搜索 2 个——这把那段额外处理老老实实地标了价，而不是藏起来。

你拿回什么

已经为 LLM 塑好形的内容：清洗过、裁剪过、便于引用，需要的话还附一个合成答案。这是四家里跑通最快的一个；对一个直白的研究型智能体来说，它省掉了一周的检索管道活儿。

它让什么变难

知道自己丢了什么。浓缩这一步是一个模型在你的模型看到之前就替你决定了什么要紧——所以一个明明在页面上的事实，可能在结果里消失得毫无信号。等你的智能体答错了，你现在有两级检索要调试，而你只能给其中一级插桩。

Firecrawl——深入

它拥有什么

把一个页面变成干净的 Markdown——渲染 JavaScript、剥掉导航与 Cookie 横幅、搞定那些别扭的站点。搜索是通往这条管线的一条路，而不是它的目的所在；定价也体现了这个侧重：按页一个固定额度，量一大就明显压过按查询计费的那几家。

你拿回什么

整页。这是它的特性，也是它的问题：当你需要整篇文档时，八千令牌的 Markdown 妙不可言；当你只需要其中一句话时，它是灾难。

它让什么变难

克制。用 Brave，你必须自己建抽取；用 Firecrawl，你必须自己建截断，而截断是更容易被跳过的那一件。一次返回五个整页的搜索，会把好几万令牌塞进一份接下来每一步都要重发的对话记录里——为什么这是复利而不是加法，见智能体成本控制。

横向比较

上下文开销才是真正把它们分开的那根轴

给一个搜索三次的十步智能体算一算。用 Brave 的摘要，检索给对话记录添上几千令牌。用 Firecrawl 的整页，同样三次搜索添上十万令牌以上——并被此后每一步一路带着走，按输入价计费，而两者的搜索账单相差还不到两倍。你因为便宜而选的那个 API，可能成为你模型账单上最贵的一行，而搜索发票上永远看不到它。

推论是：这些产品互为补充的时候，比互为替代的时候多。先用便宜的宽搜，再对通过相关性检查的那两三条做深度抽取。这与重排序是同一套"先宽后窄"的纪律，只是往上提了一层。

究竟谁真的拥有一个索引

四家里有三家有自己的爬取；Tavily 与 Firecrawl 在搜索这一步都倚重聚合数据。这件事对质量的影响，小于对连续性的影响——一个聚合方的覆盖面与定价，取决于你看不见的合同。如果你产品的核心循环依赖网页搜索，让组合里至少有一个独立索引是笔便宜的保险，而符合条件的是 Brave 和 Exa。

延迟，以及评测没有测的那件事

公开的比较把这一品类的延迟拉开了约 20 倍，从几百毫秒到远超十秒。快的那一端由返回摘要的索引型 API 占据，慢的那一端则是任何要渲染页面或对结果跑模型的东西——那不是缺陷，那正是你点的活儿。该拿来做规划的数字，不是搜索 API 的中位延迟，而是把它算进去之后你智能体的单步延迟：因为一次五秒的搜索放进十五步的循环里，就是用户眼睁睁看着的一分多钟。

该选哪一个

延伸阅读

本站：

• 什么是 RAG——这些 API 插入的那个检索模式。
• 智能体式检索——让智能体自己决定搜什么、何时停。
• 混合检索与重排序——同一套"先宽后窄"的纪律，往下一层。
• 智能体成本控制——为什么一个臃肿的工具结果会在此后每一步被再收一次费。
• 研究型智能体——这个选择所处的那本实战手册。

项目来源：

• Brave Search API
• Exa
• Tavily
• Firecrawl