给自己的 Web AI 接入联网检索：Tavily + 后端上下文注入 + 前端来源展示

很多网站现在都会接一个 AI 助手用户输入问题后端转发给大模型前端流式展示回答。这个流程本身不复杂但用一段时间后很快会遇到一个问题AI 对“最新信息”不敏感。比如问它某个库最新版本怎么用、某个产品最近更新了什么、某个 API 文档是否变了模型往往只能根据训练数据回答。哪怕回答看起来很流畅也可能已经过时。所以我最近给自己的工具站 FuShengTool 的 AI 助手加了一版“联网检索”能力。整体目标不是做一个复杂的搜索引擎而是先完成一个可靠的 MVP用户在前端打开“联网检索”开关后端用搜索 API 查询相关资料把搜索结果整理成上下文注入给大模型模型基于检索结果回答前端展示本次回答参考了哪些来源。这篇文章记录一下整体设计思路。1. 为什么不让前端直接调搜索 API最直接的想法是前端调用 Tavily、Brave Search、Bing Search 之类的 API然后把结果发给模型。但这在真实产品里不合适。原因主要有三个1.1 API Key 不能暴露到浏览器搜索 API 通常需要 Key。只要 Key 放到前端就可能被用户在 DevTools 里看到后续被滥用、刷额度、甚至带来账单风险。所以第一条原则是搜索 API Key 只放后端。前端只告诉后端这次用户是否开启联网检索。1.2 后端更适合做安全控制联网检索不只是“搜一下”这么简单。后面如果要支持读取网页正文就会涉及 SSRF 风险。比如用户传入http://localhost:xxxxhttp://127.0.0.1内网 IP云厂商 metadata 地址这些都不能让后端随便请求。所以 URL 校验、私网地址拦截、超时、最大结果数、最大正文长度都应该放在后端。1.3 后端更方便做缓存和限流搜索 API 是有成本的。一个用户每问一句都联网查成本很快就会上去。后端可以做每个用户每小时最大联网次数同一个 query 短时间缓存默认只返回 3-5 条结果深度检索单独作为高级模式。这些都不适合完全交给前端控制。2. 第一版为什么选 Tavily搜索 API 有很多选择比如TavilyBrave Search APIBing Web Search APISerper / SerpAPI自建 SearXNG我第一版倾向 Tavily主要是因为它是偏 AI 场景设计的搜索 API返回内容更适合喂给大模型。传统搜索 API 通常更像搜索引擎结果页标题、链接、摘要。它当然也能用但如果想进一步读网页正文就要自己再做抓取、清洗、截断、排序。Tavily 的优势是接入成本比较低Python SDK 也比较直接fromtavilyimportTavilyClient clientTavilyClient(api_key...)responseclient.search(query某个问题,search_depthbasic,max_results5,)当然这不代表只能用 Tavily。工程上最好做一层抽象比如search_web(query) - SearchBundle这样未来要换 Brave、Bing 或自建代理不需要重写聊天主流程。3. 后端整体流程后端聊天接口原本大概是用户消息 - 后端 - 大模型 API - SSE 流式返回 - 前端展示加上联网检索后流程变成用户消息 - 判断是否开启联网检索 - 调用搜索 API - 归一化搜索结果 - 构造“联网检索上下文” - 插入到 messages 前面 - 请求大模型 - 同时把来源通过 SSE 发给前端重点是不要把搜索结果直接混在用户消息里而是作为一段明确的系统上下文例如以下是本次联网检索结果。回答时请优先依据这些来源 如果来源不足请明确说明不确定不要编造。然后列出[1] 标题 URL: ... 摘要: ...这样模型更容易知道哪些内容是检索结果哪些内容是用户原始问题。4. 为什么要把来源返回给前端联网检索最怕的问题是用户不知道 AI 到底参考了什么。如果 AI 回答里只是说“根据最新资料”但不给来源那可信度会很弱。所以前端需要展示来源卡片至少包含标题URL站点名摘要发布时间如果有这样用户可以点开核对也能看出回答依据来自哪里。在流式聊天里可以通过自定义 SSE 事件把来源先发给前端比如event: portal_web_search data: {query:...,sources:[...]}前端收到后把来源挂到当前 assistant 消息上。这样回答还在流式生成时用户就能看到“已联网检索”。5. 前端交互怎么做第一版不建议把所有参数暴露给用户比如search_depth、max_results、include_raw_content等。普通用户不关心这些。前端只需要一个简单开关[联网检索]开启后发送请求时带上{webSearchEnabled:true}后端自己决定用什么搜索深度、返回几条、是否走缓存。后续如果要增强可以加三档快速检索结果少速度快成本低标准检索默认模式深入检索结果更多可能更慢、更贵。但第一版一个开关就足够。6. 安全和成本控制联网检索能力上线前至少要考虑这些限制6.1 API Key 只放后端环境变量示例TAVILY_API_KEY你的 Key不要传给前端不要存到浏览器。6.2 限制最大结果数第一版建议max_results 5 search_depth basic不要默认 advanced否则成本会更高。6.3 超时控制搜索和网页读取都要有超时。比如搜索超时5-10 秒单网页读取超时5-8 秒总检索流程超时10-15 秒。用户体验上联网检索慢一点可以接受但不能无限卡住。6.4 SSRF 防护如果后续支持读取用户传入 URL 或搜索结果正文需要禁止访问localhost127.0.0.10.0.0.0内网 IPlink-local 地址云 metadata 地址带用户名密码的 URL这部分一定要在服务端做。7. 第一版可以先不做什么为了尽快上线 MVP有些功能可以先不做不做全网爬虫不做 Crawl 整站抓取不做复杂 Research 报告不开放所有 Tavily 参数不让用户自定义搜索 API Key不让前端直接访问搜索服务商。先把核心链路跑通Search - Context - Answer - Sources这就已经能显著提升 AI 助手处理最新问题的能力。8. 总结给网站 AI 加联网检索不只是“调一个搜索接口”。真正要考虑的是一条完整产品链路前端怎么让用户控制是否联网后端怎么安全地调用搜索 API搜索结果怎么整理成模型能理解的上下文来源怎么展示给用户成本、限流、安全怎么兜住。我的建议是第一版先做轻量、可控、可替换。用 Tavily 这类 AI 搜索 API 快速做 MVP同时把搜索能力封装成后端模块。等需求稳定后再考虑引入网页正文提取、Research 模式、MCP 工具化或多搜索源 fallback。对于很多自建工具站来说这已经是从“普通 AI 聊天”走向“能查资料的 AI 助手”的关键一步。体验地址: https://web.fushengtool.com/chat