--- layout: post.njk source: https://yage.ai/share/agent-search-api-firecrawl-tavily-20261009.html speaker: yage.ai title: |- 给 Agent 选搜索 API：Firecrawl 和 Tavily 的差别到底在哪里 date: '2026-10-09' summary: 文章对比了 Firecrawl 和 Tavily 两款搜索 API 的计费逻辑与适用场景。Firecrawl 按内容逐页计费，适合标准网页抓取；Tavily 按请求次数计费，适合长文档与社交媒体。选型需结合业务负载类型及下游清洗成本，而非仅看单价。 area: tech-engineering category: ai-application tags: - search-api - firecrawl - tavily - cost-analysis - ai-agent people: [] companies_orgs: - firecrawl - tavily products_models: - grok media_books: [] draft: true status: evergreen --- ## 给 Agent 配一个搜索 API 如果想让手里的 AI Agent 回答今天刚发生的事，或者查阅特定领域的实时资料，光靠模型自带的训练数据肯定不够。要让 Agent 具备实时的信息获取能力，通常的做法是给它接一个搜索 API。它的工作是：把 Agent 给出的查询词发出去，去网上检索相关网页，抓取正文并清洗，再整理成结构整齐的内容喂回给模型。 在这条路线上，Firecrawl 和 Tavily 是目前比较主流的两个选择。两家都按调用量收费，计量单位叫 credit（中文常称作积分，口语里也简称点）；很多人第一次看到它们，下意识会去翻定价表，算算每次请求或者每个积分对应几分钱，觉得哪家单价更低就选哪家。 我最初也是这么想的。但在真实环境里把它们接进系统、跑了一批实际任务之后，最终账单给我的反馈却完全打破了这种预想。给 Agent 选搜索工具，实际花销远不止看单价这么简单；同样的查询任务，两家最后结算出来的账单可能差得很远。 ## 同一个查询，积分消耗能差 61 倍 直到我做了一次针对社交媒体的端到端测试，同样的查询，Firecrawl 扣了 122 个点，Tavily 只扣了 2 个点，整整差了六十多倍。后来我把生产环境的大批真实调用放进两家的规则里重算，结果又拐了个弯：在以常规网页为主的日常流量里，Firecrawl 换算成钱反而更省。单次消耗差几十倍、平均下来反而更省，造成这种反差的根本原因，在于两笔钱买到的东西其实并不相同。 当时查的是一个发在 x.com 上的产品发布推文。Firecrawl 命中推文后直接走 Grok，每条推文算 30 个点，光这一项就占了大头。 高溢价换来的是能直接落库的结构化字段。Firecrawl 用 Grok 直接拿到了发帖作者、发布时间戳、点赞与转发互动量，以及完整的回帖楼层，页面里没有多余的杂质。Tavily 只花了 2 点积分，拿回来的是抓取到的原始网页文本。它也拿到了推文正文与回复，没有彻底栽在登录墙上，但大半结果是空页面（列表页或他人主页），有内容的文本还混着登录与注册界面的导航噪声。单看单价根本算不清账，两家服务的计费逻辑处在完全不同的维度上，一个积分在两边代表的工程交付物截然不同。 ## 两家不是同一种计价方式 选择困难症的根源是两家的计费模型完全不在一个频道上：Tavily 按请求次数收费，Firecrawl 按返回的内容逐页计价。这种底层设计差异决定了它们对同一抓取任务的报价完全不同。 Tavily 只认请求类型：不管是基础搜索还是高级搜索，按预置操作扣固定点数，网页抽取也是按批打包计费。哪怕抓回来的是一篇短博客、一份上百页的研报，还是一条推文，扣费只看发了什么操作，和内容形态无关。 相比之下，Firecrawl 是内容驱动的逐页计费。Firecrawl 计费文档显示它的起步门槛很低，搜索只按结果数量收取少许基础积分。但一旦接口返回了文档，就会按抓到的形态逐页累加费用：常规网页按页计费，哪怕撞上 403、404 这类错误页，只要接口返回了文档就算进账单；遇到长篇 PDF 会按页加收，处理 X/Twitter 内容走 Grok 更是单条收取高额溢价，部分大模型解析选项还会继续累加点数。 计费维度 Tavily 机制 Firecrawl 机制 计费核心 按发起的 API 操作类型扣费 基础调用费叠加返回内容逐页计费 搜索调用 基础搜索 1 点，高级搜索固定 2 点 每 10 个搜索结果收取 2 点基础积分 网页抽取 每 5 个成功网页扣除 1 至 2 点 返回文档每页扣除 1 点积分 长篇 PDF 不加价，计入常规搜索或抽取配额 每页在基础费用上额外加收 1 点 X/Twitter 内容 不加价，返回包含页面噪声的原始文本 经由 Grok 提取结构化字段，单条计 30 点 两家搜索 API 的两种计费模型：Tavily 像一张固定票价的地铁通票，按发出的请求收费；Firecrawl 像按盘称重的自助餐厅，按返回内容的形态逐页加价。 相比之下，Tavily 更像一张固定票价的地铁通票，刷卡进站之后不论拎几重行李都不会加收额外费用；Firecrawl 则像按盘算钱的自助餐厅，入门费很低，但盘子里每夹一块肉都会单独上秤。如果直接用 Tavily 的积分单价去乘 Firecrawl 的调用量，从算式建立的那一刻起就已经失真了。 ## Firecrawl 的隐性成本藏在内容类型里 按内容点菜的时候，长文档和社交媒体是吃掉 Firecrawl 积分的两大杀手锏。很多开发者在估算成本时只盯着基础搜索，却忘了这两类内容才是真正吞掉调用量的主力军。 首先是多页PDF。Firecrawl对PDF解析完全按页数收费。我之前测试过Visa支付网络的商户争议处理规范，Firecrawl返回了两份PDF，其中一份长达67页，加上基础费用，单次查询扣了将近80点积分。同样的查询扔给Tavily，只花了固定的2点，而且同样完整返回了长文档文本。 如果你经常抓取行业白皮书、财报或学术文献，每篇动辄几十页甚至上百页。在 Firecrawl 里拉取几篇完整研报，花掉的积分可能比你做一百次普通网页搜索还多。 社交媒体是另一个成本高峰。Firecrawl 在处理 x.com 内容时必须使用 Grok，未启用结构化 JSON 抽取时，每条请求固定 30 个积分，启用则为 34。因此，只要搜索结果里命中若干相关推文，单次调用的积分就会迅速冲到上百点。 这种高溢价购买的是清洗工时。Grok 返回的结果直接剥离了网页杂质，省去写正则表达式、剔除登录浮层、对抗反爬虫这类工作，喂给下游大模型时占用的上下文窗口也更小。Tavily 单次只需固定低点数，但拿回来的原始文本混着大量界面文字，下游管道得自己过滤和重试。如果系统本身已经有了完善的本地文档解析和社交媒体清洗逻辑，为 Firecrawl 的逐页解析与 Grok 字段付费，等于重复购买清洗能力；如果希望抓回来的数据直接组装进大模型上下文，这笔溢价买到的则是更短的开发链路。 ## 真实负载交叉回放：平均跑下来谁更划算 单次的极限测试可以展示二者的边界，但评估月度预算要回到混合负载的真实调用。我调取了截至 2026 年 10 月 3 日过去一周生产环境的真实记录，把双方的实际任务互换计费规则交叉测算。这批负载横跨常规 HTML 网页、社交媒体推文和技术文档。结果呈现出明确的方向：日常网页为主的负载里，Firecrawl 换算成钱更省；长文档和社交动态的占比一旦上去，Tavily 会反超。把两组真实流量放到对方平台重算，账单走向直观反映了这种差异： 负载来源 实际任务量 原平台实际账单 交叉换算到对方平台账单 Firecrawl 生产流量 406 次搜索，342 次抽取（搜索结果 90% 以上为普通网页） 10,129 点积分（折合 Standard 档 $8.41 / Scale 档 $6.07） 折算 Tavily 为 1,508 点积分（折合 Bootstrap 档 $10.05 / Growth 档 $7.54） Tavily 生产流量 121 次搜索，36 次抽取 282 点积分（折合 Bootstrap 档 $1.88 / Growth 档 $1.41） 折算 Firecrawl 为 1,284 点积分（折合 Standard 档 $1.07 / Scale 档 $0.77） 表中 Firecrawl 按年付套餐单价折算；Tavily 流量换算到 Firecrawl 时，PDF 按每份 30 页估算。在这批以普通网页为主的任务里，Firecrawl 换算成钱比 Tavily 便宜 16% 到 20%。 但在 Tavily 接的那些任务里，即使调用量小，折合成 Firecrawl 的积分也会成倍增多。一旦长文档或社交动态的占比足够高，Firecrawl 每页、每条的附加费就会盖过它的低价优势。所以到底谁更省钱，完全看业务管线抓取的文档类型。 ## 按照内容形态与清洗容忍度做选型 在理解实际计费规则后，选型主要看两点：一是每天抓取的内容类型，二是下游对数据质量的敏感度。单纯比价并不准确，要结合业务场景。 优先选用 Firecrawl 的场景： 1. 抓取对象主要是标准网页，尤其是大规模抓取文章、博客和技术文档。在这种情况下，基础低价版本可以发挥最大价值。 2. 需要频繁抓取社交媒体，且下游系统不愿意额外投入开发抓取规则。此时用 Grok 可直接获取作者、互动量、整理好的回帖楼层，能省下清洗流程和清洗提示词的开销。 优先选用 Tavily 的场景： 1. 抓取对象经常是几十页、几百页的长 PDF、论文或政府财报。Tavily 的固定价格能完全抹平长文档带来的页数膨胀，避免一次查询扣掉几十上百点积分的极端账单。 2. 对社交媒体仅做粗粒度热度扫描和线索监控，下游管线有基础的文本过滤能力，可以容忍抓取结果中夹杂登录界面和空页面。 选型决策时，必须把下游大模型消耗的 Token 数量和清洗管道的运维时间一并计入。只看 API 账单的数字常常会漏掉这些隐蔽且昂贵的工程成本。 按内容构成选搜索 API：负载以普通网页为主时选 Firecrawl，长文档与社交动态占比高时选 Tavily。 ## 账单能不能自解释，也是选型的一部分 按量计费的 API，账单不仅要算得准，还要看得懂。Firecrawl 的单次扣费恰好能在本地完全复现：照官方文档搭一个计费规则模型，把本地日志里数百次搜索和抽取调用逐条验算，算出的积分和每条记录里返回的消耗完全吻合。底层的单次扣费是确定的。 文中所有事实都来自 2026 年 10 月的实测，依据是 Firecrawl 与 Tavily 的官方计费文档，以及本地工作区里数千个近期调用日志，计费推演与对比都可在日志中复现。一个外部 API 的总账如果在控制台里无法自圆其说，即便它在价格表上看起来便宜，系统上线之前也必须在本地把请求日志记录焊死，并为对不齐的账目预留额外的工程防御预算。