Brave Search API 2026 指南：Search vs Answers、价格与第一条可用请求

如果你现在要用 Brave Search API，第一步应该先在 Search 和 Answers 之间做选择。Search 更适合你想拿到原始网页结果、通过 LLM Context 获取可直接喂给模型的 grounding，或者使用 Place Search 这类专门端点，同时仍由你自己掌控应用逻辑。Answers 更适合你想让 Brave 直接返回带依据的最终答案，而且希望接入面尽量接近 OpenAI 兼容 的调用方式。

Brave Search API 不是一个“万能端点”。到了 2026 年，它更像一张小型路线图：Search 负责搜索底层能力，Answers 负责成品级 grounded output，LLM Context 适合你想保留自家模型层但借用 Brave 的 grounding 层，Place Search 适合你要找的是现实世界中的地点而不是网页。

时效说明：本文于 2026 年 4 月 1 日重新核对了 Brave 公共落地页、价格页、认证文档、Search 文档、Answers 文档、Place Search 文档，以及 2026 年 2 月 12 日的 Brave 官方发布文章。

TL;DR

最短可用结论如下。

最简单的一条规则是：如果你还想自己掌控模型层，就用 Search；如果你希望 Brave 多承担一层答案生成逻辑，就用 Answers。

现在的 Brave Search API 到底是什么

最容易迷路的方式，就是把 Brave Search API 想成一个端点再加上一长串可选功能。Brave 当前公开合同比这更清晰。价格页现在把这个产品拆成了两个最核心的公开主路径：Search 和 Answers。

Search 是底层能力 plan。它提供 agent、chatbot、搜索产品或 retrieval 系统真正需要的搜索数据：Web Search、LLM Context、News Search、Video Search、Image Search，以及较新的 Place Search。当前公开价格是 每 1,000 次请求 5 美元，每月 5 美元 credits，默认容量 50 requests per second。Brave 落地页也把它描述成“给 chatbot 和 agent 生成答案所需的实时搜索数据”，这个描述本身就很准确：它给你的是搜索层，不是整套成品应用。

Answers 是成品答案 plan。它建立在 Brave 的搜索基础设施之上，通过 OpenAI 兼容接口返回 grounded AI answers。当前公开价格是 每 1,000 次 query 4 美元，再加上 每百万 input tokens 5 美元 和 每百万 output tokens 5 美元，同时附带 每月 5 美元 credits，默认容量是 2 requests per second。这个吞吐更低不是偶然，而是因为 Brave 在这条路径里替你做了更多工作。

还有两个事实必须尽早讲清楚。第一，Summarizer Search 现在已经被 Brave 标记为 deprecated，并推荐转向 Answers。文档仍然为已停产的 Pro AI plan 用户保留了这条路径，但这只是历史兼容，不是新项目的默认建议。第二，Brave Search API 不是 Google 或 Bing 的 scraper。Brave 落地页明确说服务建立在自家索引之上，并把它描述为 超过 300 亿页面、每天超过 1 亿页面更新 的体系。如果你是在认真评估这个产品，这个独立索引的事实，比大多数 benchmark 口号都更重要。

先按合同选路径，不要只看品牌名

这里最重要的判断，就是别一开始就选错层。

如果你需要的是 经典搜索底层能力，就从 /res/v1/web/search 开始。它适合你想拿 URL、snippet、分页、search operators、过滤器，或者任何还要由你自己继续加工的原始结果。它的行为就像搜索基础设施：你请求搜索结果，然后由你的系统决定后续怎么做。

如果你需要的是 给自家模型或 agent 提供 grounding，那就从 /res/v1/llm/context 开始。Brave 在 2026 年 2 月那次改版里把 LLM Context 变成了对外公开的一等路径，而不是藏在文档里的次要功能。Brave 对它的描述是 data-first ranking，会把最相关的网页内容压缩成更适合模型消费的上下文。这意味着它的价值不是“换个名字的搜索”。真正的价值是：模型层仍然由你掌控，但 Brave 替你把 retrieval output 做得比普通 Web Search 更像可直接拿去推理的上下文。

如果你需要的是 尽快拿到成品 grounded answer，就从 Answers 开始。这条路更适合那些不想自己处理 answer synthesis，或者只是想尽快做出一个带引用的 answer engine 的团队。文档通过 OpenAI 兼容的 /res/v1/chat/completions 端点暴露这条能力，并使用 model="brave"。对于已经在用 OpenAI 客户端库的团队来说，这条接入路径短得出奇。

如果你的对象是 现实世界中的地点，那就不要在没有特殊理由的情况下先硬套普通 Web Search。Brave 的 Place Search 端点是为商家、地标、酒店、博物馆和附近发现这类任务设计的。公开文档把它描述为一个超过 2 亿地点 的索引，配套结构化 POI 数据、地理感知搜索和更丰富的明细端点。这跟网页排序根本不是同一类工作负载。

判断方式很简单：先决定 answer layer 由谁负责。如果答案是“你的应用自己负责”，就留在 Search 里，在 Web Search、LLM Context 和 Place Search 之间做选择。如果答案是“让 Brave 负责”，就用 Answers。

当前价格、速率限制，以及最容易被误读的地方

价格表本身不复杂，但真正影响接入判断的还有合同细节。

关键不在于哪个 plan “便宜” 或 “贵”。真正关键的是：Answers 的价格包含了 Brave 代你承担更多应用层逻辑的成本。如果你已经确定要自己持有模型栈、retrieval layer 和 synthesis pipeline，Search 往往是更自然的默认起点。反过来，如果你就是想让 Brave 直接完成 search-to-answer 这一步，那即使多了 token 成本，Answers 反而更干净。

一个实际门槛在于注册流程本身。Brave 当前落地页 FAQ 仍然写着：订阅 free plan 需要信用卡，这是为了反欺诈，而且卡本身不会因此被收费。与此同时，当前价格页又把它描述成带每月 credits 的收费计划。更稳妥的操作性解读是：每月 credits 的确存在，但不要把它想成一个完全无门槛、无卡的公共试玩沙盒。

还有两个会直接影响生产环境的限制。Brave 的 rate-limiting 文档说明，限制是按 1 秒滑动窗口 执行的，响应里还会返回 X-RateLimit-* 头。真正要上线的人，不应该等到第一次 429 才开始关注这些值。Brave 还明确写了：如果你要 存储结果的全部或部分内容，包括拿去训练或调优 LLM，就必须购买明确授予 storage rights 的计划。这种约束，不应该等到架构已经成型了才发现。

对企业买家来说，Brave 公开页面还给出了两个有意义的信号：SOC 2 Type II attestation 和 Zero Data Retention 路径。如果你的采购逻辑里包含隐私或合规，这是真正的加分项。如果你还只是原型阶段，那它至少说明 Brave 的搜索合同并不是只为玩具项目准备的。

第一条可用请求：普通搜索还是模型可用的上下文

如果你想先验证 Search 这一侧，最短路径就是带上 X-Subscription-Token 头，先发一个基础 Web Search 请求。

js
const query = new URLSearchParams({
  q: "best open source vector database for hybrid search",
  count: "10",
  country: "US",
  search_lang: "en",
  extra_snippets: "true",
});

const response = await fetch(
  `https://api.search.brave.com/res/v1/web/search?${query}`,
  {
    headers: {
      Accept: "application/json",
      "Accept-Encoding": "gzip",
      "X-Subscription-Token": process.env.BRAVE_API_KEY,
    },
  },
);

const data = await response.json();
console.log(data.web?.results?.[0]);
console.log(data.query?.more_results_available);

这个基础 Web Search 请求会把搜索层的返回形态直接展示出来。你拿到结果后，可以先判断有没有更多页面，再决定继续翻页，还是把当前结果送入自己的后续逻辑。Brave 的 Web Search 文档还明确给出了几个很值得先学会的旋钮：extra_snippets=true 可以为单个结果返回 最多 5 条额外摘录；search operators 直接写在 q 里，而不是单独字段；分页也不是无限的，所以应该先看 more_results_available，而不是盲目递增 offset。

如果你的真实工作负载是一个需要 紧凑 grounding 的模型或 agent，那么从 Search 这一侧看，LLM Context 往往是更好的第一步：

bash
curl -s --compressed \
  "https://api.search.brave.com/res/v1/llm/context?q=best+open+source+vector+database+for+hybrid+search" \
  -H "Accept: application/json" \
  -H "Accept-Encoding: gzip" \
  -H "X-Subscription-Token: $BRAVE_API_KEY"

两者的区别在于返回形态。Web Search 仍然以 URL 和 snippet 为中心，因为它本来就是搜索结果接口。LLM Context 则是为 grounding 设计的。 如果你的下一步是把结果喂给自家模型、coding agent 或推理管线，它通常比普通 Web Search 更适合作为默认起点。Brave 2026 年 2 月的公开材料也是按这个接口分工来说明的。

第一条 grounded answer：通过 OpenAI SDK 接 Brave Answers

如果你的任务不是“给我 retrieval substrate”，而是“给我成品级 grounded answer”，最短验证路径就是通过 OpenAI 客户端接 Answers 端点。

python
import asyncio
from openai import AsyncOpenAI

client = AsyncOpenAI(
    api_key="YOUR_BRAVE_SEARCH_API_KEY",
    base_url="https://api.search.brave.com/res/v1",
)

async def main():
    stream = await client.chat.completions.create(
        model="brave",
        stream=True,
        messages=[
            {
                "role": "user",
                "content": "Compare Brave Search API Search vs Answers for an internal research assistant",
            }
        ],
        extra_body={
            "country": "us",
            "language": "en",
            "enable_citations": True,
            "enable_research": False,
        },
    )

    async for chunk in stream:
        if chunk.choices and chunk.choices[0].delta.content:
            print(chunk.choices[0].delta.content, end="", flush=True)

asyncio.run(main())

这条路径里有一个很多二手文章都会漏掉、但实际很重要的约束：如果你要 citations、entities 或 research mode，就必须开启 streaming。这不是小细节，因为 Answers 返回的内容比普通 chat completion 更丰富。Brave 文档明确描述了 <citation>、<enum_item> 和 <usage> 这类特殊标签。如果你想把 UX 做干净、把监控做可靠，就应该真的去解析这些结构。

research mode 也值得在默认打开之前先想清楚。Brave 说默认的 single-search mode 是为了速度优化，通常平均会在 4.5 秒以内开始流式返回；而 research mode 可能触发多次搜索，在复杂问题上持续 数分钟。这说明它更适合后台任务，而不是默认就“更高级”的选项。如果你的产品看重交互延迟，就应该先停留在默认模式，除非你能明确说出为什么值得为更高成本和更长等待时间买单。

Brave 真正强的地方，不只是“又一个搜索 wrapper”

当你不再把 Brave 看成一个“又一个搜索框”，而是把它看成可以被你控制的搜索基础设施时，它会有意思得多。

第一个差异点是索引本身。Brave 的公开材料反复强调同一句话：它是 独立索引，不是套在 Google 或 Bing 之上的 scrape-and-repackage 层。这个说法只有在它改变了你能构建什么时才有意义，而实际上的确如此。Brave 把独立索引和一组更像 operator tools 的能力绑在了一起，包括 Goggles 这种 reranking / filtering 能力、给单个结果补更多上下文的 extra snippets，以及适合结构化结果的 schema-enriched results。这些都不是抽象营销词，而是当你的 agent 或搜索工作流总在同一类 retrieval blind spot 上翻车时，真正有价值的控制杆。

第二个差异点是 Brave 现在同时公开了 substrate layer 和 answer layer。很多搜索相关产品会逼你只选其中一层，但 Brave 允许你自己决定：你要的是原始搜索结果、压缩后的模型上下文，还是已经生成好的 grounded answer。所以更准确的比较方式往往不是“Brave 的答案比某家强不强”，而是“你的系统到底要不要自己拥有 answer layer”。

第三个差异点是生态适配。Brave 的官方 tools 页面现在已经公开列出了 MCP Server，以及 LangChain、LlamaIndex、Dify、Flowise、Postman 等一系列集成。如果你现在最快的验证路径是“今天下午就把搜索接到 agent 工具里跑起来”，这件事就很重要。如果你随后又决定自己想在 Brave 之上再套一层 relay/gateway，而不是把 Brave 直接放在最顶层，那么我们的 OpenClaw API 指南 讲的是那条完全不同的架构选择。

最后还得再提一次 Place Search，因为它改变了整个产品的形状。很多文章仍然把 Brave 讲成“网页搜索 + AI answers”，但现在它已经有了一条真正可用的本地发现路径。如果你的任务是“找某个坐标附近的咖啡店”“巴黎的博物馆”或任何地点对象为中心的功能，那么 /local/place_search 本身就是一级产品判断，不是脚注。

最容易浪费第一周的错误

很多人接 Brave Search API 的早期挫败感，并不是因为少了哪个冷门特性，而是因为一开始就假设错了一件事。

• 在新项目里从 Summarizer Search 开始。 Brave 已经明确把它标成 deprecated，并建议转向 Answers。你不该因为旧教程还在，就把它当成新工作的默认路径。
• 明明只需要 grounding substrate，却一上来就用 Answers。 如果你的应用已经自带模型层，直接跳进 Answers 可能会让合同更贵、控制力更弱。
• 忽略 Answers 富输出对 streaming 的要求。 如果你想拿 citations、entities 或 research mode，就应该从架构上接受流式处理，而不是把 Answers 当成一个普通同步 chat response。
• 把每月 credits 理解成无门槛公共沙盒。 公开页面仍然提示存在 signup/card friction。这不是说它不能评估，而是说你该按真实 onboarding 成本规划。
• 把 rate-limit 和 storage-rights 检查拖到后面。 X-RateLimit-* 头和明确的 storage-rights 约束，应该在第一版 integration checklist 里，而不是上线后补作业。
• 明明要做本地发现，却还强行走普通 Web Search。 当目标对象是商家、地标或附近地点时，Place Search 通常才是更干净的第一步。

最短也最稳的起步方式

如果你现在还在犹豫从哪条路开始，就先记住这条规则：想要控制，就用 Search；想要成品，就用 Answers。

对大多数工程团队来说，更稳的第一轮评估通常是 Search plan 下的 Web Search 或 LLM Context，因为这两条路径能让架构保持诚实。你可以先看清 retrieval layer 的表现，再决定 Brave 是继续停留在 substrate 层，还是往 answer layer 再走一步。如果你的产品从一开始就是“尽量少集成、直接拿 grounded answer”，那就不要绕远路，直接从 Answers 开始。

真正不该做的，是让旧教程或只讲价格的摘要替你做判断。Brave 当前公开合同其实已经足够清楚，只是前提是你把它当成一张路线图来读，而不是把“Brave Search API”当成某个单一端点的名字。