零 API Key 白嫖五家搜索引擎：真实限额与 Hermes 环形轮换机制

调研日期：2026-08-24 · 官方文档 + GitHub 源码 + 社区实测交叉验证

一、这是什么

Hermes Agent v0.20.5（2026 年 8 月 19 日发布）引入了一个新特性：零密钥 Web 层（keyless web tier）。简单说，全新安装 Hermes 之后，一个 API key 都不用配，web_search 和 web_extract 工具就能直接用。

它靠的是五家搜索服务商的公开匿名端点，这五家被排成一个环：

exa → parallel → tavily → firecrawl → keenable → （回到 exa）

请求在环上轮着走，某一家被限流就自动跳到下一家。本文结合官方文档、各家开源仓库源码和社区实测讨论，把这五家免费端点的真实速率限制讲清楚，再拆解 Hermes 的轮换机制到底怎么工作。

二、五家真实限额：官方口径 vs 源码与社区

Exa — 文档说一套，代码默认另一套

官方文档口径：匿名 MCP 端点 mcp.exa.ai/mcp 为 3 QPS + 每天 150 次（按 IP），仅对 tools/call 计数。但翻它的开源仓库 exa-mcp-server，api/mcp.ts 里限流环境变量的默认值其实是 2 QPS + 50 次/天——文档数字高于代码默认值，而且官方 2026 年 8 月还在给匿名限流做 A/B 实验（PR #351），阈值处于动态调整中。

社区侧可以确认的是 429 真实高发：oh-my-openagent 项目就有两个 issue（#1627、#1932）记录用户撞上 Exa 免费层限流，其中一个还是因为客户端 bug 没把用户的 EXA_API_KEY 传进 MCP URL，被误当成匿名流量限流。官方 PR #294 也承认"用户是会话中途撞限流了才知道自己在免费层"。注册账号后 Free Tier 每月送 $10 额度。

Parallel — 五家中最不透明

search.parallel.ai/mcp 完全免费无需注册，但官方只说 "lower rate limits"，从未公布任何数字。第三方 API 编目项目（api-evangelist，2026-08 编制）核实：确实没公开，而且 API 不返回任何 RateLimit-* 响应头，程序连自己还剩多少额度都读不到。搜索跑 basic 模式，每次调用摘录封顶约 25,000 字符。

更混乱的是官方自己的免费总量口径都不一致：pricing 页写每月 5,000 次免费请求，产品页又写"最高 80,000 次免费搜索"（$80 迎金额度 + 每月 $5 credit）。社区实测只有一篇 Medium 文章验证零配置可用，没有触发数值。

Tavily — keyless 是黑箱，但有"20 分钟撞墙"实测

Tavily 的 keyless 模式（请求加 X-Tavily-Access-Mode: keyless 头）官方明确不公布限额，只说 "free and rate-limited, ideal for exploration and light use"。SDK 的错误信封里有 window 和 retry_after_seconds 字段——也就是说运行时撞了才知道窗口。

唯一的量化实测来自竞品 Scavio 的博客：连续 agent 使用约 20 分钟即撞限流墙，直到窗口重置前全部被拒。注意作者卖的就是替代品，数字要打折，但"轻量使用很快触顶"这个定性结论与官方 "light use" 的措辞互相印证。注册免费层是硬数据：每月 1,000 credits，Development key 100 RPM / Production key 1,000 RPM，HN 上有用户侧证。

Firecrawl — keyless 确认存在，数值是服务端黑箱

之前有疑问 Firecrawl 是否真有无 key 端点——现在确认：2026 年 6 月 16 日官方正式发布 keyless 功能（联合创始人 Eric Ciarla 署名的博客），MCP/CLI/API 三端免 key 可用。Hermes 用它是有依据的。

限流机制的真相在开源仓库里：apps/api/src/lib/keyless.ts 显示按 IP/天 双重上限（每日请求数 + 每日 credits），任一超限返回 429。但具体数值由服务端环境变量 KEYLESS_REQUESTS_PER_DAY / KEYLESS_CREDITS_PER_DAY 配置，代码里没有默认值——官方刻意不写死，随时可调。社区能查到的都是注册层的吐槽（比如 issue #651 免费层用了约 16 credits 就报错），keyless 层没有可靠实测数字。

Keenable — 数字最透明，但无人交叉验证

面向 AI agent 的搜索基础设施公司（自建独立网页索引）。keyless 公共池限额写得明明白白：每 IP 1,000 次/小时 + 10 次/秒，keyless 调用不消耗 credit。公共端点为 POST /v1/search/public 与 GET /v1/fetch/public，须带 X-Keenable-Title 应用标识头，响应自带 X-RateLimit-Remaining 头。

不过 Reddit、X、HN、GitHub 全平台检索都没有找到任何用户讨论或实测——官方数字是唯一信息源，无法交叉验证。

三、对比总表

厂商官方口径源码/实测可信度备注
Exa3 QPS + 150 次/天代码默认 2 QPS + 50 次/天，A/B 动态调整高429 高发，仅计 tools/call
Parallel"lower rate limits"，无数字无响应头，无实测数值中低免费总量两处官方口径矛盾
Tavily"rate-limited"，无数字~20 分钟连续使用触顶（竞品实测）中注册层 1000 credits/月是硬数据
FirecrawlIP/天双上限，数值不公布env 配置无默认值；2026-06 官方发布 keyless机制高/数值低MCP 只开放 Search/Scrape/Parse
Keenable1000 次/时/IP + 10 RPS全平台零社区讨论无法交叉验证唯一公布完整数字

四、Hermes 的轮换与故障切换机制

1. 环形轮询：负载均摊

每个 Hermes 进程启动时生成随机 session_id，用它决定环上的起始位置。不同机器、不同实例天然错开，整体流量均匀摊在五家身上。进程内每发一次请求游标前进一格，单机也不会一直薅同一家。

2. 限流故障切换：只对限流跳站

请求失败时，Hermes 先判断错误是否为限流特征（429、rate limit、quota exceeded、slow down 等）：

  • 是限流 → 自动跳环上下一家重试；
  • 不是限流（比如查询格式错误）→ 立即停止，不做无效重试。

成功的结果会标注 served_by 字段说明实际服务厂商，全环走完才报错。网页抽取更保守：一批 URL 全部撞限流才切站。这套设计恰好对冲了上面表格里的最大痛点——多数厂商限额不透明，程序化试错式退避是常态，Hermes 把这个过程自动化了。

3. 单次救援：付费层挂了免费层顶上

配了 API key 的调用失败后还有一层保险：one-shot keyless rescue。Hermes 会拿同样的查询走一遍免费环救急，结果标注 rescued_from。关键是无状态：只救当次，下个请求照常先试付费后端，不会因一次失败永久降级。

4. 优先级：免费层永远垫底

解析顺序：显式配置 backend > Tool Gateway > ddgs > 自定义插件 > 免费环。有任何一层配置，免费环都不会抢先。也可按厂商设 free/paid 强制档位，或用 web.keyless_fallback: false 整体关闭。

五、实际能撑多大量

把最可靠的数据放在一起算账（单 IP、无 key）。最坏情况按源码默认值算：Exa 匿名每天可能只有 50 次；Tavily keyless 连续约 20 分钟就触顶（对应 agent 场景大约几十次搜索）；Firecrawl 和 Parallel 数值未知；Keenable 每小时 1,000 次但公共池与同 IP 所有匿名流量共享。

保守估计：单 IP 每天几十到一两百次零 key 搜索是现实的预期，轻度个人使用够用，但远不如第一眼看上去美好——如果按文档口径的 Exa 150 次/天叠加估算会明显高估。另外轮换粒度是"每次请求换一家"，五家额度并行消耗，总容量接近各家之和而非串行接力；云服务器 NAT 出口还会被同 IP 用户分薄 Keenable 的公共池。

六、优点

  1. 零门槛：新装即用，不需要注册任何账号。
  2. 自动容错：限流自动切站，单点故障不影响使用——这在多家限额黑箱的现实下尤其有价值。
  3. 负载友好：随机起点 + 轮询，不集中打爆一家。
  4. 不抢占已有配置：配了 key 的用户完全感知不到它，失败还有单次救援兜底。
  5. 隐私干净：不带用户标识，session_id 随机生成、重启即换。

七、缺点与限制

  1. 单 IP 容量有限：Exa 源码默认值低至 50 次/天，重度使用必须配 key。
  2. 黑箱太多：五家里三家不给数字两家给了也没法验证，撞墙才知道边界。
  3. 官方口径不稳：Exa 在 A/B 调阈值，Parallel 自己两处免费总量数字都矛盾，今天的体验不代表明天。
  4. 公共池不可控：Keenable 的每小时额度和所有同 IP 匿名流量共享，云服务器上尤其吃亏。
  5. 功能缩水：免费端点多为基础 search/extract，Tavily 的 crawl/map、Firecrawl 的 crawl/extract 都要 key。

八、小结

这次调研最大的体会：真实限额不在论坛吐槽里，而在开源仓库的源码注释里。Exa 和 Firecrawl 的关键数字都是从自家代码里挖出来的，比任何二手转述都可靠；而 Tavily 和 Parallel 则是真黑箱，社区连实测数字都拿不出。

对 Hermes 的零密钥 Web 层，评价是工程上干净、定位上清醒：环形轮询解决负载均摊，限流识别避免无效重试，单次救援保护付费用户，免费层永远垫底不抢戏。它是"装完就能搜"的保底方案和付费用户的免费保险，但单 IP 匿名容量有限，重度场景终究要回到 key 上。

参考来源

  • 官方文档：exa.ai/docs/changelog · docs.parallel.ai · docs.tavily.com/documentation/keyless · docs.firecrawl.dev/rate-limits · docs.keenable.ai/api-reference
  • 源码级证据：github.com/exa-labs/exa-mcp-server (api/mcp.ts, PR #351/#294) · github.com/firecrawl/firecrawl (apps/api/src/lib/keyless.ts)
  • 社区实测：Scavio 博客 Tavily 20 分钟实测（利益相关） · Medium Parallel-free 上手文 · oh-my-openagent issues #1627/#1932 · firecrawl issues #651
  • 发布记录：Firecrawl keyless 官方博客（2026-06-16） · Hermes v0.20.5 Release Notes