如果想让手里的 AI Agent 回答今天刚发生的事，或者查阅特定领域的实时资料，光靠模型自带的训练数据肯定不够。要让 Agent 具备实时的信息获取能力，通常的做法是给它接一个搜索 API。它的工作是：把 Agent 给出的查询词发出去，去网上检索相关网页，抓取正文并清洗，再整理成结构整齐的内容喂回给模型。
在这条路线上，Firecrawl 和 Tavily 是目前比较主流的两个选择。两家都按调用量收费，计量单位叫 credit（中文常称作积分，口语里也简称点）；很多人第一次看到它们，下意识会去翻定价表，算算每次请求或者每个积分对应几分钱，觉得哪家单价更低就选哪家。
我最初也是这么想的。但在真实环境里把它们接进系统、跑了一批实际任务之后，最终账单给我的反馈却完全打破了这种预想。给 Agent 选搜索工具，实际花销远不止看单价这么简单；同样的查询任务，两家最后结算出来的账单可能差得很远。
直到我做了一次针对社交媒体的端到端测试，同样的查询，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 点 |
相比之下，Tavily 更像一张固定票价的地铁通票，刷卡进站之后不论拎几重行李都不会加收额外费用；Firecrawl 则像按盘算钱的自助餐厅，入门费很低，但盘子里每夹一块肉都会单独上秤。如果直接用 Tavily 的积分单价去乘 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 的单次扣费恰好能在本地完全复现：照官方文档搭一个计费规则模型，把本地日志里数百次搜索和抽取调用逐条验算，算出的积分和每条记录里返回的消耗完全吻合。底层的单次扣费是确定的。
文中所有事实都来自 2026 年 10 月的实测，依据是 Firecrawl 与 Tavily 的官方计费文档，以及本地工作区里数千个近期调用日志，计费推演与对比都可在日志中复现。一个外部 API 的总账如果在控制台里无法自圆其说，即便它在价格表上看起来便宜，系统上线之前也必须在本地把请求日志记录焊死，并为对不齐的账目预留额外的工程防御预算。