本地部署了大模型之后，很多人都会遇到同一个尴尬：模型写代码、做总结、处理文档都很稳，但你问它“今天北京天气怎么样”“最近有什么新发布的AI模型”，它要么一本正经地编一个不存在的答案，要么抱歉地说自己知识截止在某一天。这时候你就明白，本地模型再强，本质上也是一个离线的大脑，它没有眼睛，看不到实时世界。
解决这个问题的思路其实很简单，就是给LLM接上“外挂眼睛”——联网搜索。本地知识库查不到，就让模型自己去网上找，找到之后再基于搜索结果组织回答。这是一套近几年很流行的“LLM + 联网兜底”架构，在智能客服、行业情报分析、知识库问答、个人AI助手这些场景里非常实用。今天我就用一套基于Ollama本地模型 + 搜索API的实践方案，把整个思路和落地步骤拆开讲清楚，从原理到代码，从坑点到排查，一次性说透。
1. 为什么本地模型必须做“联网兜底”
1.1 离线模型的三块硬伤
先说痛点。本地部署的LLM看起来什么都能聊，但深入用一段时间你会发现它有三个绕不过去的短板。
第一，知识截止日。几乎所有开源模型都有训练数据的截止时间。比如某些蒸馏版模型，它的知识可能只到2024年，之后发布的工具、产品、技术方案，它一概不知。你问它“2025年的某个新框架怎么用”，它只能把相近的历史知识拼凑出来，看起来句句通顺，实际上全是幻觉。
第二，私域数据与实时数据够不着。本地模型只能引用训练时见过的公开语料，你的企业内部的报表、实时库存、最新竞品动态，这些它都拿不到。即使你做了知识库RAG，检索的内容也是静态导入的，没办法每次问答都去抓最新网页。
第三，答非所问时很容易嘴硬。离线模型没有自我纠错机制。当它不知道答案时，极大可能会用一个“合理的”假答案填上，这在中文互联网的环境下有个通俗的说法叫“一本正经地胡说八道”。你如果不另开一个搜索页面去核对，很容易被骗过去。
1.2 “联网兜底”到底是什么逻辑
把联网能力接进来之后，整个问答流程从“模型单方面猜测”变成了“模型调用工具获取事实”。
核心逻辑可以拆成四步：
- 用户提问，本地LLM先理解意图。
- 如果模型判断这个问题涉及实时信息、最新动态、或自身知识覆盖之外的数据，它就生成一个结构化的“搜索请求”。
- 程序捕获这个请求，调用搜索API（比如Bing Search API、SerpAPI、博查等），拿到网页标题、摘要、链接，甚至正文片段。
- 把搜索到的内容拼接成上下文，再喂回给LLM，让模型基于真实检索结果重新组织回答。
整个过程里，LLM的定位从“万事通”变成了“聪明的信息加工者”，它不需要知道所有事情，只需要知道“什么时候该上网”以及“怎么把搜到的内容整理成答案”。这种设计在工程上还有一个好处：搜索失败不影响模型本身，你随时可以降级为纯离线模式。所以我管它叫“联网兜底”，而不是“强制联网”。
1.3 本地模型挂搜索，和RAG知识库到底什么关系
很多人会混淆“联网搜索”和“RAG知识库”这两个概念。
RAG是把你的私有文档切块、向量化，存进向量数据库，问答时先做相似度检索，再把命中的片段加进提示词。它的强项是稳定、可控、领域聚焦，适合处理企业内部资料、固定文档。
但RAG有一个致命短板：知识库的更新必须靠人手动维护。业务方不导入新文档，模型就永远看不到新内容。而联网搜索恰恰补上了这个动态缺口，它能实时抓取互联网上的最新信息，覆盖的是RAG够不到的开放世界。
所以在真正的生产系统里，这两者通常搭配使用：RAG负责私有知识仓库，联网搜索负责动态知识兜底，本地模型负责把两边的信息融合成最终答案。这是一种很常见的混合检索架构，比单纯依赖任何一边都稳得多。
2. 方案选型：自己写还是用现成框架
2.1 三条主流路线对比
动手之前，先选路线。目前给本地LLM接联网搜索，主流有三条路：
| 方案 | 优点 | 缺点 | 适合谁 |
|---|---|---|---|
| 自研Python代码 + Function Calling | 灵活可控，逻辑透明，容易调试 | 需要有一定编程基础 | 想深入理解原理、准备上生产的开发者 |
| 现成平台（Dify、Open WebUI、FastGPT等） | 开箱即用，有图形界面，插件市场丰富 | 定制受限，排障黑盒 | 业务人员、快速验证想法的团队 |
| LangChain / LlamaIndex等框架 | 组件化，生态成熟 | 框架封装较重，版本更新频繁 | 已经依赖框架的项目团队 |
我自己走得比较多的是第一条路线。原因很朴素：自研代码时每一步都能看到输入和输出，出了问题你能准确知道是哪一环挂了。用平台虽然方便，但一旦出现“模型就是不上网”“搜索内容没被用上”这类问题，排查起来特别痛苦，你只能一层层翻日志。
2.2 为什么选Ollama做本地推理
热词里出现频率很高的“Ollama本地部署”，我在实际项目里用得也比较多。选它有几个现实原因。
首先，Ollama把模型下载、量化、加载、API服务这些琐碎事情都封装好了。你在命令行里两条命令就能跑起一个开源模型，还自动兼容OpenAI的API格式。这对后续接工具调用非常友好。
其次，Ollama原生支持工具调用（tool calling）。自2024年底的版本开始，它在API里加入了工具调用的能力，模型可以返回结构化的JSON，告诉我们“我要调用某个工具，参数是什么”。这就为联网搜索留好了标准接口。
最后，Ollama对硬件要求相对友好。带量化版本（GGUF格式）可以让你在消费级显卡上跑7B、13B甚至更大参数的模型，跑不起来的时候还有CPU模式兜底，虽然慢但不至于没法用。
2.3 搜索API怎么选
搜索API是整个链路里唯一要花钱的环节，但花得值得。选择的核心指标有三个：返回速度、稳定性、文档质量。
我用过的方案里，SerpAPI返回的结构最干净，它直接解析Google搜索结果的JSON，字段很好用；Bing Web Search API在国内网络环境下的连通性更好，而且Azure有免费额度；博查是国内团队做的搜索API，对中文支持好，返回速度快，如果想规避国际网络问题，它是个很实际的备选。
不管用哪家，你拿到的核心信息都是一样的：每条搜索结果包含标题、URL、摘要，有部分API还能返回正文快照。对我们的场景来说，标题+摘要足够用，正文快照可以作为高级选项，后面我讲细节时会展开。
3. 手把手实现：Ollama + Python + 搜索API的联网问答
3.1 准备工作与环境搭建
第一件事，把基础环境弄好。假设你已经装好了Ollama，并且能正常运行本地模型，接下来需要准备的是Python环境和一个搜索API的Key。
pip install requests openai这里要注意，我们用的openai库不是真的去连OpenAI官方，而是利用它兼容Ollama的API格式。Ollama本身暴露的接口是http://localhost:11434/v1，你可以直接用OpenAI SDK来对接，省去自己封装http请求的麻烦。
from openai import OpenAI client = OpenAI( base_url="http://localhost:11434/v1", api_key="ollama" # 本地服务不需要真实key，占位即可 )搜索API这里我用SerpAPI举例，因为你只需要一个Key就能拿到结构化的搜索结果。随便注册一个账号，复制你的API Key，放到环境变量里备用：
export SERPAPI_KEY="你的key"3.2 先让模型拥有“工具意识”
联网搜索的本质是让模型学会“请求外部工具”。在OpenAI兼容协议里，这通过tools参数实现。你需要先给模型声明一个工具，说清楚工具的名字、作用、参数格式。
tools = [ { "type": "function", "function": { "name": "web_search", "description": "当用户的问题涉及实时信息、最新动态、网络资源时，搜索互联网并返回相关网页标题、链接和摘要", "parameters": { "type": "object", "properties": { "query": { "type": "string", "description": "搜索关键词，必须是能直接提交给搜索引擎的简洁查询语句" } }, "required": ["query"] } } } ]这段JSON就是给LLM看的“工具说明书”。模型会在内部判断：当前这个问题是否需要调用这个工具。如果需要，它不会直接给出最终答案，而是返回一个特殊的结构，告诉你它想调用web_search，并且query里放什么内容。
这一步是整个方案里最核心的架构设计：把搜索的决策权交给模型，而不是预设规则。实践下来，这种方式比硬编码关键词匹配要聪明得多。模型能判断“今天发生了什么大事”该搜，“帮我写一段Python代码”不用搜。
3.3 实现真正的搜索函数
模型声明了工具，但我们必须在代码里真正写一个web_search函数。我建议把它封装在类里，后面方便扩展和复用。
import os import requests class WebSearchTool: def __init__(self): self.api_key = os.getenv("SERPAPI_KEY") self.base_url = "https://serpapi.com/search" def run(self, query: str, num_results: int = 5) -> list: params = { "engine": "google", "q": query, "api_key": self.api_key, "num": num_results, "hl": "zh-cn" # 中文用户建议指定语言 } resp = requests.get(self.base_url, params=params, timeout=10) resp.raise_for_status() data = resp.json() results = [] for item in data.get("organic_results", [])[:num_results]: results.append({ "title": item.get("title", ""), "link": item.get("link", ""), "snippet": item.get("snippet", "") }) return results这里有两个细节值得强调。
第一个是timeout=10。搜索接口如果超时，整个问答体验会很糟糕。我踩过很多次坑，发现10秒是一个还不错的阈值：既给足了网络请求时间，又不至于让用户等太久。
第二个是num参数。我一般控制在5条左右。搜索返回太多结果，上下文会变得冗长，模型在组织答案时反而容易失焦，而且token消耗也会暴涨。少而精的搜索结果比一堆杂物有用得多。
3.4 核心循环：让模型决定要不要上网
现在到了整个程序最关键的部分：把用户问题发给模型，拿到模型返回结果，判断它是不是要调用工具。
def chat_with_search(user_query: str, max_search_rounds: int = 3): messages = [{"role": "user", "content": user_query}] search_tool = WebSearchTool() search_count = 0 while True: response = client.chat.completions.create( model="qwen2.5:7b", # 替换成你本地Ollama里实际拉取的模型名 messages=messages, tools=tools, tool_choice="auto" ) content = response.choices[0].message.content tool_calls = response.choices[0].message.tool_calls if not tool_calls: # 模型没有请求工具，说明它可以基于现有知识回答，直接返回 return content # 模型请求调用工具 search_count += 1 if search_count > max_search_rounds: # 防止模型陷入循环调用，设置上限 return "搜索次数超限，无法生成可靠回答，请缩小问题范围后重试。" for call in tool_calls: func_name = call.function.name args = json.loads(call.function.arguments) if func_name == "web_search": search_results = search_tool.run(args["query"]) # 把搜索结果作为工具返回消息，追加到对话历史中 messages.append(response.choices[0].message) messages.append({ "role": "tool", "tool_call_id": call.id, "content": json.dumps(search_results, ensure_ascii=False) })这段代码是整套方案的骨架。每轮循环都让模型重新看一遍包含搜索结果的对话历史，这样模型就可以基于搜索结果继续推理。如果你追问，模型还可以继续再搜一次，形成多轮搜索交互。
我在实际部署中会给max_search_rounds设成3。因为本地模型有时候会在“搜索-回答-再搜索-再回答”之间打转，限制轮数能避免无限循环和API费用失控。
3.5 把搜索结果“喂”给模型时，千万别偷懒
搜索API返回的是裸JSON结构，包含一堆字段。我强烈建议你在把它塞回上下文之前，先格式化成一个清晰、精简的纯文本块。
def format_results(results: list) -> str: lines = [] for idx, r in enumerate(results, start=1): lines.append(f"[{idx}] {r['title']}") lines.append(f" URL: {r['link']}") lines.append(f" 摘要: {r['snippet']}") lines.append("") return "\n".join(lines)然后把format_results(search_results)作为工具消息的content传入。
为什么我不直接塞原始JSON？因为本地模型的上下文有限，而且token窗口里塞满JSON括号、键名会让模型抓不到重点。把它整理成人类阅读习惯的文本格式，模型理解和提炼信息的效率会高很多，回答质量也会有肉眼可见的提升。
3.6 一个完整可跑的示例
为了方便你直接复制测试，我整理了一个最小可运行的版本。把上面几段代码拼在一起，再加一个命令行入口就可以了。
import json import os import requests from openai import OpenAI client = OpenAI( base_url="http://localhost:11434/v1", api_key="ollama" ) MODEL_NAME = "qwen2.5:7b" tools = [ { "type": "function", "function": { "name": "web_search", "description": "当用户的问题涉及实时信息、最新动态、网络资源时，搜索互联网并返回相关网页标题、链接和摘要", "parameters": { "type": "object", "properties": { "query": { "type": "string", "description": "搜索关键词，必须是能直接提交给搜索引擎的简洁查询语句" } }, "required": ["query"] } } } ] class WebSearchTool: def __init__(self): self.api_key = os.getenv("SERPAPI_KEY") self.base_url = "https://serpapi.com/search" def run(self, query: str, num_results: int = 5) -> list: params = { "engine": "google", "q": query, "api_key": self.api_key, "num": num_results, "hl": "zh-cn" } resp = requests.get(self.base_url, params=params, timeout=10) resp.raise_for_status() data = resp.json() results = [] for item in data.get("organic_results", [])[:num_results]: results.append({ "title": item.get("title", ""), "link": item.get("link", ""), "snippet": item.get("snippet", "") }) return results def format_results(results: list) -> str: lines = [] for idx, r in enumerate(results, start=1): lines.append(f"[{idx}] {r['title']}") lines.append(f" URL: {r['link']}") lines.append(f" 摘要: {r['snippet']}") lines.append("") return "\n".join(lines) def chat_with_search(user_query: str, max_search_rounds: int = 3): messages = [{"role": "user", "content": user_query}] search_tool = WebSearchTool() search_count = 0 while True: response = client.chat.completions.create( model=MODEL_NAME, messages=messages, tools=tools, tool_choice="auto" ) content = response.choices[0].message.content tool_calls = response.choices[0].message.tool_calls if not tool_calls: return content search_count += 1 if search_count > max_search_rounds: return "搜索次数超限，无法生成可靠回答，请缩小问题范围后重试。" for call in tool_calls: func_name = call.function.name args = json.loads(call.function.arguments) if func_name == "web_search": print(f"[ToolCall] 搜索关键词: {args['query']}") search_results = search_tool.run(args["query"]) messages.append(response.choices[0].message) messages.append({ "role": "tool", "tool_call_id": call.id, "content": format_results(search_results) }) if __name__ == "__main__": while True: query = input("请输入你的问题（输入 exit 退出）: ") if query.lower() == "exit": break answer = chat_with_search(query) print("\n===== 答案 =====\n") print(answer) print("\n==================\n")这个脚本足够支撑日常个人用了。启动后你问它“今天北京天气怎么样”，它会先打印一行[ToolCall] 搜索关键词: 今天北京天气，然后给你一个带来源链接的回答。你问它“如何用Python读CSV”，它判断不需要搜索，就直接用本地知识回答。整个过程干净利落。
4. 密钥管理与安全防护：兜底功能不能成为泄密窗口
4.1 为什么不把密钥直接写进代码
热词里有一条“使用LLM时如何防止密钥等鉴权信息泄露”，这问题在联网方案里尤其关键。因为你一旦把搜索API的Key写进代码里，提交到Git仓库，那这个Key就彻底裸奔了。别人只要看过你的仓库，就能拿着Key去调用付费API，产生大量费用。
正确做法是永远不要硬编码密钥。用环境变量或者.env文件来承载敏感信息。
from dotenv import load_dotenv load_dotenv() api_key = os.getenv("SERPAPI_KEY")把.env文件加入.gitignore，确保它不会提交到版本库。这一步虽然听起来基础，但我在很多团队代码评审里都见过把密钥写死的案例，每次都要提醒。
4.2 系统提示词里不要放置敏感信息
另一个常见风险是，把API密钥或其他鉴权信息放在系统提示词里告诉模型。这非常危险，因为模型的输出可能会无意中复述这些信息。尤其是当模型联网搜索时，如果用户通过巧妙的Prompt注入让模型“忽略之前的安全指令”，模型就可能把提示词里的密钥泄露给外部接口。
我的原则是：所有敏感信息都只存在于程序运行环境里，绝不让LLM“看见”。模型需要知道的是“你会调用web_search工具”，而不是“你的搜索API Key是xxxx”。
4.3 为工具调用加一层权限白名单
生产环境里，我们通常会给工具调用加上细粒度控制。不是所有工具都能被模型随意调用。比如，你可以定义一个工具注册表，每个工具都有调用条件：
TOOL_REGISTRY = { "web_search": { "allowed_models": ["qwen2.5:7b"], "max_calls_per_session": 5, "require_confirmation": False } }当模型请求调用某个工具时，程序先查注册表，确认当前模型是否被允许调用，再确认本次会话的调用次数有没有超限。这相当于给模型加了一道权限门，防止它滥用外部接口。
5. 常见问题与排查技巧实录
5.1 模型就是不触发工具调用，怎么办
最常遇到的问题就是：模型明明该去搜索，却偏要凭记忆硬答。
第一反应先确认模型本身支持不支持工具调用。Ollama上有些模型（尤其古老的参数量小的模型）对工具调用的支持很弱。我建议优先选近期发布的、指令跟随能力强、专门优化过function calling的模型，比如qwen2.5:7b、llama3.1:8b这类。
第二个排查点是工具描述写得太含糊。模型对工具的感知完全依赖你的描述文字。描述里一定要说明“什么时候用”和“怎么用”。比如web_search的描述就该包括“当问题涉及实时信息、最新动态、网络资源时”。描述写得越明确，模型触发工具的准确性越高。
第三个办法是你在发起请求时手动指定tool_choice。如果某个业务场景确定要联网，直接把tool_choice设为{"type": "function", "function": {"name": "web_search"}}，强制模型第一轮就调用搜索工具。这种方式虽然牺牲了一些灵活性，但结果可控，适合做定时任务或特定API。
5.2 搜索返回的内容太多，导致回答不稳定
这个坑我踩过很多次。把大量搜索内容一股脑塞进上下文后，模型反而不知道该信哪条，生成出来的答案前言不搭后语，甚至开始胡编。
解决思路有两个。
一是控制搜索结果数量。前面代码里我把num_results设为5，这个值不是随便拍的。经过多轮测试，5条结果对大多数问题足够覆盖核心信息，又不至于冲垮模型注意力。如果你做的是深度调研类任务，可以放宽到10条，但需要配合第二条方案。
二是对搜索结果做一个“摘要提取”中间层。调用一个参数量更小的模型，先把搜索结果压缩成200字以内的要点，再交给主模型组织答案。这种做法有点类似“搜索摘要→知识浓缩→最终回答”的三级管线，实现稍复杂，但对回答质量的提升非常明显。我在处理长文档检索和开放域问答时，就经常用这个思路。
5.3 LLM返回的JSON格式损坏，怎么修复
本地模型在生成工具调用参数时，偶尔会返回损坏的JSON，常见现象是多了一个逗号、缺少右括号、或者返回了Markdown代码块包裹。如果你直接用json.loads，程序会当场抛异常，整个会话就崩了。
对这种问题，我的处理思路是先清洗再解析。写一个健壮的JSON提取函数，把模型返回的字符串里的代码块、前后缀都剥掉，再尝试解析。
import re def extract_json(text: str) -> dict: # 去掉可能的markdown代码块包裹 text = re.sub(r"^```(?:json)?|```$", "", text.strip(), flags=re.MULTILINE) # 去掉常见的前后缀说明文字 try: return json.loads(text) except json.JSONDecodeError: pass # 尝试提取最外层的JSON对象 match = re.search(r"\{.*\}", text, re.DOTALL) if match: return json.loads(match.group()) raise ValueError("无法从模型输出中解析JSON")再不行，还可以用一些开源的容错解析库，比如json-repair，它能把常见格式错误自动修复。我把这招放进生产代码后，工具调用的成功率从70%左右直接提升到95%以上，非常管用。
5.4 搜索API限流和超时怎么处理
搜索API毕竟是外部依赖，不可控因素很多。我实际项目里遇到过的典型情况有：并发调用超限、网络抖动超时、免费额度耗尽。
在代码层面要做的核心防御是重试机制。首次请求失败后，不能立刻放弃，等待1-2秒再重试。重试两次仍失败，就必须降级——返回一个明确提示，告诉用户“联网搜索暂时不可用”，而不是让模型继续信口开河。
retry_count = 0 while retry_count < 3: try: resp = requests.get(self.base_url, params=params, timeout=10) return parse_response(resp) except requests.RequestException: retry_count += 1 time.sleep(2) return []不要小看这个降级逻辑。生产系统里，“宁可返回空搜索结果，也不要在没搜索结果的情况下让模型硬编答案”是一条铁律。
5.5 本地算力不足，可以用远程模型混合调度
最后提一个实际部署中很常见的折中方案。如果你的本地机器跑不了足够大参数的模型，导致工具调用能力比较弱，可以做一个“本地模型 + 云端模型”的混合架构。
具体做法是：用本地小模型做路由和意图识别，判断是否需要联网，然后把搜索任务交给本地模型完成工具调用；搜到结果后，再调用云端大模型（比如DeepSeek的API）做最终答案生成。这种方案兼顾了数据隐私和回答质量。对于企业用户来说，如果选用的开源模型效果不够，混合调度是性价比非常高的替代思路。
我个人的经验是，技术选型不必非此即彼。本地模型做敏感数据的过滤和初筛，云端模型做深度推理和表达，再加上联网搜索做动态知识补充，三者结合往往能发挥最大的效果。
6. 几点实操心得
最后分享几个我在持续使用这套方案过程中的个人体会。
第一个体会是：联网搜索是“兜底”，不是“主力”。我之前试图让模型对每个问题都先搜索一遍，结果回答速度慢，还经常过载。后来改成只让模型在自身知识不足时触发搜索，整体体验反而顺畅很多。让模型自己判断要不要搜，是这套设计里最聪明的部分。
第二个体会是：调试工具调用，一定把中间步骤打出来。我在脚本里加的print(f"[ToolCall] 搜索关键词: {args['query']}")这行，在前期调试时帮了大忙。你能一眼看出模型到底有没有触发搜索、搜索了什么词、搜回来的内容长什么样。不加这行，出了问题你只能瞎猜。
第三个体会是：搜索结果的“可信度分级”很重要。从官方渠道、权威媒体来的内容，和从个人博客、论坛来的内容，权威性完全不同。目前我们简单地把所有搜索结果平等看待，但在生产系统里，建议给搜索来源打标签，并在系统提示词里提醒模型优先采用权威来源。这会显著降低错误信息传播的风险。
这套“联网兜底”的方案，我已经在个人知识库问答、行业动态播报、自动化情报整理等多个项目里跑了一段时间。不能说它完美，但在本地模型离线的硬约束下，它确实把“实时信息缺失”这个最大的短板补上了一大块。你可以先按上面的代码跑通一个最小版本，再根据自己的场景调整工具描述、搜索结果数量和提示词策略。试过之后你大概率会发现，本地部署的LLM，终于不再是个“装在外壳里的过时大脑”了。
