从搜索框到 Agent：Chatbot 联网搜索的技术演进面向普通 AI 用户与应用开发者：理解 Chatbot 为什么

当用户问“今天发生了什么”、“这份文档的最新配置是什么”、“比较两家刚发布财报的公司”时，语言模型仅依赖训练数据无法可靠回答。它需要访问实时信息。

表面上，这像是给 Chatbot 加一个 Google、Bing 或百度搜索框；实际上，现代 Chatbot 需要的是一条完整的“证据生产线”：决定是否搜索、把自然语言问题改写成可检索的查询、阅读网页正文、控制上下文长度、标注来源，并在失败时安全地降级。

这也是为什么今天的联网能力不再只是传统搜索引擎 API，而逐渐形成了 AI 搜索 API、网页读取 API、模型原生搜索和自托管元搜索等不同层次的服务。

1. 搜索没有消失，只是不再是最终界面

传统搜索产品的链路是：

Google、Bing、百度等产品首先服务的是人：结果页要适合浏览、广告展示、点击跳转和后续搜索。链接排序、摘要、富结果和网页展示都是围绕人的浏览行为设计的。

Chatbot 的目标不同。它要把答案直接交给用户，因此需要将“检索—阅读—归纳—引用”接入模型推理过程：

搜索在这里从最终交互界面，变成了模型的一项工具能力。

这并不意味着传统搜索引擎被取代。它们依旧可能是上游数据源：AI 搜索服务可能使用自己的索引、第三方索引或多个传统引擎的聚合结果。变化在于，Chatbot 需要的是面向程序和模型的接口，而非面向人类浏览的搜索结果页。

2. 第一阶段：把传统搜索 API 接入聊天机器人

早期 Chatbot 的联网实现通常很直接：

将用户问题直接或简单改写后提交给 Google、Bing、百度等搜索接口；
取得标题、URL、摘要；
把摘要拼入提示词，或展示成链接列表；
让模型给出总结。

这种做法足以覆盖“搜索后总结”的基础需求，但很快会暴露问题。

搜索摘要不是完整证据

搜索摘要是索引系统为点击决策生成的短片段，不保证覆盖用户问题的关键上下文。模型若只看到摘要，容易补全不存在的细节，或遗漏限定条件、时间范围和例外情况。

网页正文是另一项工程

拿到 URL 不等于拿到网页内容。应用还要处理：

HTML 中的导航、广告、推荐、评论和脚本；
单页应用的动态渲染；
PDF、文档、图片和付费墙；
重定向、超时、反爬和地区网络差异；
恶意 URL、内网地址和 DNS 重绑定等安全风险。

因此，“搜索”与“抓取并提取可读正文”应被看作两项独立能力。

模型上下文不是无限的

把十个页面的原文全部塞进 Prompt 往往比不联网更糟：成本上升、响应变慢，模型还可能在海量噪音中抓错重点。比较稳妥的接法，是先从训练数据以外的资料里检索相关片段，挑过以后放进当前回合的上下文，再让模型据此生成回答。
这个做法叫 RAG，英文全称 Retrieval-Augmented Generation，中文一般译成检索增强生成。开放互联网上，一次搜索带回的正文往往超过一轮回答用得上的篇幅，所以还得决定留下哪些片段、各留多长，并整理成模型读得了的格式。

3. 第二阶段：RAG 让搜索成为上下文构建的一部分

检索到的片段会写进模型这一轮回答所用的上下文。来源链接可以同时留在界面上，供用户核对。

对于企业内部知识库，RAG 通常可以预先完成解析、切分、Embedding 和向量索引；对于开放互联网，数据持续变化、页面结构各异且难以提前建立完整索引。因此互联网 RAG 往往按需运行：

这也解释了现代联网 Chatbot 的两个基本工具：

web_search(query)：回答“有哪些可能相关的来源？”
web_fetch(urls)：回答“这些来源的正文具体说了什么？”

好的系统不会把这两个动作强行合并。模型可能只需要搜索摘要，也可能需要先搜索，再抓取其中两篇权威文章的正文。

4. 新服务并非同一类产品

传统搜索 API 接到 Chatbot 上，交出来的仍是标题、链接和摘要。正文怎么抽出、一轮上下文放得下多少，都还要应用自己处理。2023 年起，一批新服务对着这两件事出现。它们要交付的是模型读得了的材料，程序拿回来就能放进当前回合。

把 Tavily、Exa、SearXNG、智谱、Jina、Firecrawl、Parallel、Serply 都称为“AI 搜索引擎”，说着方便。里面有直接为模型准备的，也有更早的搜索接口后来才被接进这条链路。顺着上一节的两个工具看下去，这个统称就盖不住了。有的服务回答 web_search，有的服务回答 web_fetch，还有的两边都沾，重心却完全不同。

4.1 AI 搜索引擎时间线

谈“诞生时间”之前，得先把几个日期拆开。公司成立、开源项目创建、首次公开 API、产品改名、某个功能上线，往往不是同一天。下面只记开发者真正能调用到的公开节点，并按它们进入这条链路的先后往下看。

最早出现的，并不是给 LLM 准备的。SearXNG 在 2021 年中由原 SearX 的部分维护者 fork 出来，当时要解决的是上游搜索引擎适配修得太慢，同时把隐私优先的元搜索继续维护下去。生成式 AI 这波热潮还没起来。它后来能当自托管 Agent 的搜索后端，是用途挪过来了。

紧接着，Serply 从另一侧进来。公司大约成立于 2022 年，Python SDK 最早的公开记录是 2023 年 3 月。它起初就是面向开发者的搜索 / SERP 数据 API，不是从“AI 搜索”这个概念起家的。等 Agent 需要稳定的 JSON、Markdown 和 MCP，同一套搜索数据才被改成模型能接的形状。

真正把“连接 LLM 与互联网”说成产品的，是再往后一点。Exa 的前身 Metaphor 在 2023 年 8 月公开 API，2024 年 1 月改名 Exa。动机很具体：关键词检索和 SEO 结果很难直接喂给 LLM，所以它把神经语义检索和可读取的页面内容放在前面。Tavily 可以追到 2023 年的开源项目 GPT Researcher，产品则在 2024 年前后商业化。它的公开说法对准的是另一处：Agent 得在一次调用里同时完成搜索、抓取、过滤和上下文压缩。各处资料对成立年份说法不一致，这里就不把它收成一个“创立日”。

搜索接口有了之后，缺口转到网页本身。2024 年 4 月，Jina 的 r.jina.ai 把 URL 转成 LLM 能读的文本；同年 5 月，s.jina.ai 把搜索结果也转成 Markdown。它不打算做通用搜索门户，要解决的是网页怎样变成模型读得了的上下文。几乎同一时间，Firecrawl 公开发布，在开源抓取和托管服务之间给一套 API，把网页、站点和需要交互的页面收成 Markdown 或结构化数据。

再晚一拍，索引本身被重新做了一遍。Parallel 的公司成立于 2023 年，面向开发者的商业 Web API 到 2025 年才公开。路线是给 Agent 建索引：高密度摘录、检索、抽取、深度研究和持续监控放在一起。中国市场则走出另一条。智谱 Web Search 的公开资料里找不到一个能核对的首次发布日。它是开放平台上的工具 API，把网页读取、排序、意图识别、多搜索引擎和模型生成做成可配置的一层。与其追那一天，不如看它已经把 Web Search、Chat 内搜索和 Search Agent 分成同一条产品线的不同层。

排在一起看，这些就不是同一批替代品。SearXNG 来自元搜索和隐私社区，Serply 来自 SERP 数据；Exa、Tavily、Parallel 面向 LLM / Agent 的检索和研究；Jina 和 Firecrawl 补的是网页怎么读；智谱把搜索嵌进模型平台和中文生态。下一节先看检索这一层，阅读和自托管放到后面。

4.2 AI 检索 API：为模型提供结构化、可消费的结果

时间线把“找链接”和“读网页”拆开了。Tavily、Exa、Parallel、Serply，以及智谱的 Web Search API，站在前一半：根据查询找到相关的互联网信息。

它们返回的东西通常接近：

[
  {
    "title": "页面标题",
    "url": "https://example.com/article",
    "content": "与查询相关的摘要、片段或提取内容"
  }
]

人用的结果页要能点、能扫。这些 API 把同一件事收成程序调用：格式稳定，方便映射成模型工具；摘要、相关片段、语义检索或重排，比一条蓝色链接更接近模型要的输入；计费按请求数、credits、token 或结果数拆开；Agent 可以改查询再搜一轮，并把引用追回去。

这不等于它们比 Google 或 Bing 更能搜到所有网页。适合的是被编排进一次推理回合。链接拿到了，正文往往还是空的，所以下一类服务补的是阅读。

4.3 网页阅读与抓取 API：把 URL 变成模型可读文本

检索 API 停在“可能相关”。模型已经有 URL 时，问题换成链接里面写了什么。Jina Reader 和 Firecrawl 做的就是这一步：获取网页，再把噪音洗掉。

原始 HTML 不适合直接进上下文：

<html>
  <head>...</head>
  <body>
    <nav>...</nav>
    <script>...</script>
    <article>真正正文</article>
  </body>
</html>

洗完之后更接近：

# 文章标题

正文段落……

## 小节

更多正文……

导航、广告和脚本少了，token 也少。两边的拼法仍不一样。Jina Reader 以“一个 URL 转成 LLM 能读的文本”出名；Firecrawl 则把抓取、爬取、搜索和结构化提取收进同一套 API。如果连第三方阅读服务都不想依赖，就回到可以自己托管的元搜索。

4.4 元搜索与自托管：SearXNG

SearXNG 接的是这个空档，但它不是 AI 专用搜索。它是开源、可自托管的元搜索引擎，从多个上游搜索服务聚合结果。

部署在本地网络或自己的服务器上，上游引擎自己选，隐私、网络路径和可用性留在自己手里，对应用露出的是可预期的 JSON。读到这里容易把它当成“免费的 Tavily”。自托管省掉的是厂商账单，服务器、带宽、维护、上游限流和结果质量还在。公开实例如果直接拿去生产，认证、防滥用和稳定性也得自己补。

这些差异先记在路线上。下一小节按“它实际补哪一层”再走一遍，避免选型时只比名字。

4.5 技术路线速览：它们分别解决哪一层

产品页上的词很接近，内部路线差很多。下面仍是简化：排序算法、索引从哪来、反爬怎么做，厂商一般不公开。别把 API 的外在行为当成完整实现。

如果希望少搭流水线，Tavily 把搜索、抓取、过滤、相关性排序和摘要包成一次 Agent 调用。公开文档强调一次请求可以聚合多个站点，再用内部相关性机制筛内容。

若检索本身就要比关键词更贴近查询，Exa 走神经 / 语义搜索。公开介绍里，Highlights 会把网页切块、做 embedding，再配合段落预测模型，返回更相关的片段，而不只是 URL 和搜索摘要。

检索可以外包，也可以自己聚合。SearXNG 用适配器向多个上游发请求，再把结果收成统一格式。它没有专有的 LLM 重排；要正文的话，还得自己抓页面、接 Reader，或让 Agent 调 web_fetch。智谱 Web Search 则把意图识别、多个搜索引擎、时间与域名过滤、结果条数和摘要长度做成参数，返回结构化结果。它更像搜索平台，不像单一爬虫。到了中文生态，这一层往往比“再接一个全球索引”更先碰到。

检索有了结果，页面仍可能打不开、洗不干净。Jina Reader 在服务端抓 URL、抽正文，JavaScript 页面可以走浏览器渲染；s.jina.ai 再把检索结果直接转成可阅读内容，搜索和阅读就接上了。Firecrawl 以网页数据为中心：单页、整站、搜索、浏览器里交互，输出 Markdown 或结构化数据。复杂网页被收成应用能调用的工作流。

还有两条不想被前面几家盖住。Parallel 维护给 Agent 用的网页索引，把结果压成密度更高的 excerpts，上面还有 Search、Extract、Task、FindAll、Monitor，从即时问答延伸到深度研究、实体发现和持续追踪。Serply 则说明不一定要换一套新索引：Google、Bing 和市场 / SERP 数据仍可走程序化入口，代理、重试、验证码和结构化输出把调用细节挡在外面。

走完这一圈，下一节的两条联网路径才有着落。应用侧工具调用，就是在这些层里挑 Provider；厂商原生搜索，则是把其中几层交回模型供应商。

5. 当前 Chatbot 的两条联网路径

当用户启用联网搜索后，应用通常会在两条路径中选择一条，而不是同时启用所有搜索工具。

路径 A：应用侧工具调用

这条路径的优势是可控性：

可切换 Tavily、Exa、SearXNG、Jina、Firecrawl 等 Provider；
可为搜索和网页抓取分别配置服务；
可统一进行域名黑名单、结果截断、故障降级和引用格式处理；
可跨不同聊天模型复用；
可通过本地 fetch 或自托管 SearXNG 减少第三方依赖。

代价是模型必须能调用工具，且一次搜索通常会增加至少一轮工具调用延迟。

路径 B：模型厂商原生搜索

OpenAI、Anthropic、Gemini、xAI 和部分聚合 Provider 都有不同形式的原生联网能力。

它的优势是集成紧密：模型厂商可以在自身协议内处理检索、引用和生成；应用不必单独维护一个搜索 Provider。

限制也很明显：

强绑定模型与 Provider；
各厂商的参数、定价和引用格式不同；
结果控制、调试和替换空间较小；
某些模型不能将原生搜索与 MCP、知识库或其他函数工具混用。

实际产品往往根据模型能力、用户偏好、已启用工具和网络配置动态路由。例如，若模型的原生搜索与函数工具冲突，应用侧 web_search 可能反而是更可靠的选择。

6. `web_search` vs `web_fetch`

在应用侧工具模式中，两者最终都可被统一为：

type WebResult = {
  id: string
  title: string
  url: string
  content: string
}

区别在于 content 的来源。

`web_search`

web_search 返回多个候选结果。每条结果的 content 通常是：

搜索 Provider 返回的摘要；
与查询最相关的页面片段；
部分服务返回的 Markdown 内容或较长摘要。

它适合快速建立信息面、比较多个来源和选择下一步应读取哪些页面。

`web_fetch`

web_fetch 接收已知 URL，获取其可读内容。根据配置不同，它可能：

由应用主进程直接下载 HTML，再提取正文并转 Markdown；
调用 Jina Reader 等 URL 阅读 API；
调用 Firecrawl 等 Scrape API，直接请求 Markdown。

因此，web_fetch 给模型的通常不是原始 HTML，也不是网页的完整 DOM，而是清洗后的标题、URL 和正文型文本。

无论来源如何，应用都应在结果进入模型上下文前执行：

URL 与域名安全校验；
域名黑名单过滤；
内容长度限制或 token 截断；
统一的 citation ID 分配；
出错时区分“无结果”“网络错误”“未配置 Provider”。

7. Cherry Studio 案例：将搜索能力编排为可替换的工具系统

前面的模型看起来抽象，Cherry Studio 的实现提供了一个具体参照：它没有把“联网搜索”绑定为某一家服务的开关，而是把它拆成工具、能力、Provider 和模型路由四层。这样用户可以换搜索服务，模型也可以换，而对话层仍然面对同一套 web_search、web_fetch 和引用体验。

7.1 搜索和阅读是两项工具，不是一个大开关

Cherry Studio 将联网能力拆为 web_search 与 web_fetch：

web_search 让模型用查询词发现候选来源；
web_fetch 让模型读取已经知道的 URL 的可读正文。

这项拆分看似简单，却决定了 Agent 的工作方式。模型可以先搜宽一点，比较多个来源后只抓取少数页面；也可以在用户直接给出链接时跳过搜索。它避免了“每次搜索都自动下载所有网页”的成本和上下文浪费。

在应用侧路径中，两种工具最终都被归一化为同一个结果形状：

{
  title: string
  url: string
  content: string
}

不同 Provider 返回的是搜索摘要、网页正文、Markdown 或私有格式都没有关系。对模型而言，它最终只需要可阅读的标题、来源地址和内容；对 UI 而言，它最终只需要可以展开和跳转的来源信息。

7.2 两类能力可分别配置，也可分别降级

Cherry Studio 不假设一家 Provider 同时擅长“找链接”和“读网页”。配置层将联网能力分为：

searchKeywords：关键词检索；
fetchUrls：网页内容读取。

用户可为这两项能力分别选择默认 Provider。例如，可以用擅长检索的服务寻找候选来源，再用 Jina、Firecrawl 或本地直接抓取读取正文。

服务端也按能力分别判断 Provider 是否已配置、是否支持当前操作、是否缺少 API Key 或 API Host。若主 Provider 失败，系统不会把整批请求直接判定失败：它会针对失败的查询词或 URL，尝试该能力的 fallback Provider。这样一批 URL 中某一页失败时，其他成功页面仍然可以进入回答。

这是一种比“全局备用搜索引擎”更细的降级模型：搜索和抓取有不同的失败模式，也应该有不同的备用路径。

7.3 应用侧工具与模型原生搜索动态路由

同一个“启用联网搜索”的助手，在不同模型、不同 Provider 甚至不同回合中，可能走不同路径：

如果当前模型的 Provider 提供原生 web search / grounding，Cherry Studio 可以把搜索作为模型请求的一部分交给 Provider；
如果原生能力不可用，或用户偏好应用侧工具，则向模型注入 web_search 和 web_fetch；
如果模型原生搜索与 MCP、知识库、附件等函数工具存在兼容冲突，系统会重新评估路由，避免把一个必然失败的工具组合发给模型。

这里最重要的约束是：同一轮中不会同时把两条同名或语义重叠的搜索能力交给模型。否则模型可能重复搜索，或因工具协议冲突而无法调用。对用户而言，工具栏仍只是一个“联网搜索”开关；复杂性被留在请求编排层。

7.4 结果进入模型前仍要经过治理

Provider 的返回不能原样塞进 Prompt。Cherry Studio 在统一结果后继续执行几层处理：

按用户配置的域名黑名单移除不希望使用的来源；
按 token 预算截断每条 content，避免长网页吃掉整轮上下文；
将每条结果映射为本轮唯一的 citation ID；
将成功结果、临时网络失败和永久配置错误区分开来。

最后一点会直接影响 Agent 行为。若 API Key 缺失、Host 非法或某 Provider 根本不支持当前能力，系统应告诉模型这是不可通过重试解决的配置错误；如果只是网络波动，模型才可以考虑重试或改用其他查询。否则，Agent 很容易陷入“调用失败—原样重试”的循环。

7.5 主进程负责密钥、可靠性与网页抓取安全

Cherry Studio 将实际搜索调用放在主进程服务中，而不是让渲染页面直接访问第三方 API。这样做不只是为了隐藏 API Key，还使以下能力有统一的归属：

在多把 API Key 之间轮换，降低单 Key 限流或失效的影响；
记录并处理部分失败，按能力尝试 fallback；
即使窗口关闭，也能让已开始的工具调用完成其主进程生命周期；
对本地直接抓取的 URL 执行 SSRF 防护。

本地 web_fetch 不是简单的浏览器 fetch。它需要校验协议、限制私网和危险地址、解析 DNS 并防范重绑定、限制重定向与响应体大小，然后才下载 HTML、提取正文并转换为可读 Markdown。第三方 Reader/Scrape Provider 虽然能降低自建抓取器的复杂度，但 URL 和查询仍可能离开用户设备；这也是产品在隐私设置中必须说明的边界。

7.6 这个案例说明了什么

Cherry Studio 的价值不在于同时接入很多搜索厂商，而在于将它们放到稳定的抽象之后：

用户意图
  → 搜索或抓取工具
  → 能力级 Provider 选择与降级
  → 统一结果与安全治理
  → 模型回答与来源引用

因此，未来新增一个搜索 Provider 时，产品不必重写聊天 UI、引用组件或模型工具协议；它只需适配相应能力，并将输出收敛到统一的结果契约。这正是 Agent 基础设施和“在聊天框里接一个搜索 API”之间的差别。

7.7 引用不是装饰，而是联网回答的可信度边界

联网回答最容易出现的误解是：只要显示了几个链接，就等于答案有依据。
真正有价值的引用机制需要让模型的具体陈述和来源结果建立关联：

“某公司于某日发布了某功能。[cite:source-2]”

系统至少应做到：

每个检索结果在当前回答中拥有唯一 ID；
模型被明确要求在事实陈述后附上对应 ID；
UI 可以将 ID 映射回标题、URL 与结果内容；
搜索或抓取失败时，模型不会把空结果误当作“没有发生”；
结果超过上下文预算时，仍尽量保留 URL、标题和引用标识。

引用不能从根本上保证网页内容正确，但它让用户能够检查模型的证据路径，并在来源失效、片面或过时时自行判断。

8. 开发者最容易低估的五个问题

前面几节把搜索、阅读、引用串成一条链路。真正开始接的时候，成本、网页内容和失败方式会从链路外面冒出来。下面五件事是一件牵出下一件，不是五条并列的检查项。

8.1 成本会在两处发生

联网回答的账单拆在两处。一处是搜索或抓取 Provider 的 API，另一处是模型读完这些结果之后的 token。

只搜一轮、只看摘要时，两笔都还不显眼。一旦改查询再搜、抓长网页、把大段正文灌进上下文，API 调用和 token 会一起上去。所以要先设最大结果数、每条内容的 token 上限、每回合工具调用上限，以及缓存。上限设完，下一个问题才出现：省下来、送进模型的那段网页，并不能当指令用。

8.2 网页内容是不可信输入

网页里可能写着让模型忽略系统指令、泄露数据、调用工具或改掉任务的文字。它来自搜索结果，Prompt Injection 也不会因此消失。

应用得把网页当成不可信数据。系统提示里写明，它的优先级低于用户指令和系统指令；敏感工具要审批；不要让网页文本直接触发外部副作用。文本这一层挡住了，请求本身仍可能有问题。模型或用户给出的 URL，服务端如果照单访问，攻击面就从提示词挪到了内网。

8.3 URL 抓取需要 SSRF 防护

这个 URL 可能指向 localhost 和内网管理面板，也可能指向云环境的元数据服务、私有 IP、链路本地地址、保留地址，或者一个用 DNS 重绑定伪装过的内部目标。

所以安全抓取至少要限制 HTTP(S)，拒绝 URL 里嵌的凭据，解析并校验 DNS，固定真正连接的地址，并限制重定向次数和响应体大小。协议和地址都校验过之后，外部 Provider 仍会自己失败。那是下一层，和 SSRF 不是同一个故障。

8.4 Provider 失败必须可降级

搜索服务会限流，Key 会失效，区域会不可达，也会单纯暂时挂掉。可靠一点的做法是轮换 API Key；搜索和抓取各自留备用 Provider；多个 URL 里失败的那几条单独降级，不让整轮一起失败；给模型的状态要写明可重试还是配置错误；配置已经永久错误时，不要让模型反复打同一个工具。

降级能保住这一轮回答，挡不住账单。很多团队是在备用 Provider 和重试都接上之后，才发现“免费额度”已经不够付这条链路。

8.5 “免费”通常只是起步额度

Tavily、Exa、Jina、Firecrawl、Parallel、Serply 通常给的是免费 credits、试用额度或限速。智谱这类服务可能按次计费。SearXNG 的软件可以免费自己托管，机器和上游并不免费。

所以对用户要说清楚：桌面客户端或开源 Chatbot 可以不收费，联网用的外部账号、配额和账单一般得用户自己管。下一节的选型按这个约束来分，而不是先找一家“最好的搜索”。

9. 如何为产品选型

没有一家通吃。上一节的成本、不可信内容和失败方式，会先把场景切开。部署在哪、用户在哪、要的是链接还是正文、钱怎么算，答案会不一样。

个人用户和轻量应用可以先用带免费额度的 AI 搜索或抓取 API，把体验跑通。如果只是偶尔读公开网页，本地直接抓取可以当 web_fetch 的便宜后备。这条路适合验证，不适合当成最终架构。一旦隐私、局域网或部署边界变得重要，免费 API 的便利就会和数据离开本机碰到一起。

这时更合适的是自建 SearXNG，再配本地 URL 抓取。认证、限流、上游引擎是否还活着，都得自己盯。没加保护的实例不要放到公网。自建解决的是“谁持有查询”，还没解决“模型有没有读到正文”。搜索结果只负责找到候选页，正文提取才决定证据在不在上下文里。

所以如果质量卡在网页正文，要换的是 Reader / Scrape，例如 Jina Reader 或 Firecrawl，同时把 token 截断和域名策略做严。这一步和第 4 节的分工是同一件事：检索 API 和阅读 API 不要因为都叫搜索，就绑死在一家。

前面的选择若主要依据英文基准或全球索引，到中文互联网和中国网络环境会再转一次。智谱、博查，以及能配中文上游的 SearXNG，都要单独看，还要看 Provider 在目标区域能不能连上。

这些条件叠到生产级 Agent 上，就不能再按场景各挑一条。质量、延迟、配额、账单上限、可观测性、隐私条款、数据放在哪、失败怎么降级、有没有 SLA，会同时起作用。免费额度大，撑不起稳定的生产服务。

10. 结语：联网能力的本质是证据编排

从 Google、Bing、百度等传统搜索引擎，到 Tavily、Exa、Jina、Firecrawl、Parallel、Serply 等面向 AI 的服务，变化的核心不是搜索本身，而是搜索结果的消费者变成了模型。

现代 Chatbot 不只是“替用户搜网页”，而是在完成一项证据编排任务：

未来的差异化也将不只来自某个搜索 API，而来自产品能否在质量、成本、安全、隐私和可解释性之间，稳定地完成这条链路。

从搜索框到 Agent：Chatbot 联网搜索的技术演进