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

> 如果你现在要接入 Brave Search API，第一步不是去找一个“唯一入口”，而是先分清 Search 和 Answers。Search 更适合你自己掌控应用逻辑，只拿搜索结果或 grounding；Answers 则适合让 Brave 直接返回带依据的最终答案。

- URL: https://blog.laozhang.ai/zh/posts/brave-search-api
- Published: 2026-04-01
- Updated: 2026-04-01
- Author: AI Free API Team (https://blog.laozhang.ai/zh/about)
- Category: API Guide
- Tags: Brave Search API, Brave Answers API, LLM Context API, 搜索 API, API 指南

---
如果你现在要用 **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 官方发布文章。_

![展示 Brave Search、LLM Context、Answers 与 Place Search 四条构建路径的路线图](https://blog.laozhang.ai/posts/zh/brave-search-api/img/cover.jpg)

## TL;DR

最短可用结论如下。

| 如果你的真实任务是 | 应该从这里开始 | 为什么 | 最大的注意点 |
| --- | --- | --- | --- |
| 你想拿到原始网页结果、摘要、分页、过滤和搜索控制 | **Search plan + `/res/v1/web/search`** | 这是最核心的搜索底层能力 | 排序逻辑、结果处理、以及上层 answer layer 仍要你自己负责 |
| 你想给自家模型或 agent 提供 grounding | **Search plan + `/res/v1/llm/context`** | Brave 会把相关网页上下文压缩成更适合模型消费的形态 | 它仍然是 substrate，不是成品答案 API |
| 你想让 Brave 直接返回 grounded answer | **Answers plan + `/res/v1/chat/completions`** | OpenAI 兼容路径，支持引用、实体和 research mode | 高级元数据特性要求流式输出，而且默认吞吐更低 |
| 你想找附近商家、地标或 POI | **Search plan + `/res/v1/local/place_search`** | 它搜索的是地点，不是网页 | 数据形态不同，不应该默认先用普通 Web Search 硬套 |
| 你看到旧的 Summarizer 教程 | **不要从那里开始** | Brave 现在明确把 Summarizer 标为 deprecated，并让新工作流转向 Answers | 老 Pro AI 用户可能还能继续用，但它已经不是新项目默认路径 |

最简单的一条规则是：**如果你还想自己掌控模型层，就用 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 数据、地理感知搜索和更丰富的明细端点。这跟网页排序根本不是同一类工作负载。

![展示什么时候该从 Web Search、LLM Context、Answers 或 Place Search 开始的决策图](https://blog.laozhang.ai/posts/zh/brave-search-api/img/endpoint-map.jpg)

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

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

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

| Plan | 当前公开价格 | 每月 credits | 默认容量 | 最适合的场景 |
| --- | --- | --- | --- | --- |
| Search | `$5 / 1,000 requests` | `$5` | `50 requests/sec` | 搜索结果、grounding context、新闻、图片、视频、地点搜索 |
| Answers | `$4 / 1,000 queries` + `$5 / 1M` input tokens + `$5 / 1M` output tokens | `$5` | `2 requests/sec` | 通过 OpenAI 兼容 chat completions 返回成品 grounded 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 月的公开材料也是按这个接口分工来说明的。

![展示 API key、Search quickstart、LLM Context 和 Answers 请求路径的流程图](https://blog.laozhang.ai/posts/zh/brave-search-api/img/quickstart-flow.jpg)

## 第一条 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 指南](https://blog.laozhang.ai/zh/posts/openclaw-api-guide) 讲的是那条完全不同的架构选择。

最后还得再提一次 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 通常才是更干净的第一步。

![展示价格、速率限制、存储权限与 Summarizer 弃用提醒的护栏图](https://blog.laozhang.ai/posts/zh/brave-search-api/img/production-guards.jpg)

## 最短也最稳的起步方式

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

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

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