1. 从搜索框到 Agent 的演进逻辑1.1 为什么传统搜索框模式走到了瓶颈做过 Chatbot 的人都有一个共同体会用户问“今天有什么值得关注的科技新闻”如果只靠模型内部的知识回答要么是过时的要么是编造的。早期做法很简单在对话框旁边挂一个搜索框用户自己搜完再把结果贴回来。这个模式本质上把联网这件事外包给了用户Chatbot 只负责“聊天”不负责“找信息”。后来大家开始尝试让 Chatbot 自动调用搜索。最早的一批实现非常粗糙把用户问题直接拼成搜索词抓回前几条网页摘要一股脑塞进 Prompt 里让模型总结。问题立刻暴露出来——搜索结果里大量导航栏、广告、重复内容模型被噪声淹没回答质量反而下降。更麻烦的是有些问题需要多轮搜索才能回答比如“对比一下今年三款主流折叠屏手机的续航”单次搜索根本拿不到完整信息。这个阶段的根本矛盾在于搜索是“检索”逻辑Chatbot 是“生成”逻辑两者之间缺少一个能理解意图、拆解任务、筛选信息的中间层。RAG 的出现部分缓解了这个问题但 RAG 本身也有瓶颈后面会细说。1.2 Agent 模式带来的范式转变Agent 的核心变化在于它不再把联网搜索当成一个“工具调用”而是当成一个“可规划、可迭代、可验证”的任务流程。用户问“帮我找一下最近三个月内发布的、支持本地部署的开源 RAG 框架并对比它们的文档完整度”一个成熟的 Agent 会这样拆解先搜索“开源 RAG 框架 本地部署 2024”拿到候选列表。对每个候选框架分别搜索其官方文档、GitHub 仓库、社区评价。判断哪些框架满足“最近三个月发布”这个时间约束。对满足条件的框架抓取文档页面评估完整度。汇总成对比表格标注信息来源。这个过程中Agent 会多次调用 web_search每次调用的查询词都不一样而且会根据上一次的结果动态调整下一次的搜索策略。这就是从“搜索框”到“Agent”的本质跃迁搜索不再是单次动作而是嵌入在推理循环里的持续行为。1.3 联网搜索在 Agent 架构中的位置在一个典型的 Agent 架构里联网搜索通常作为 Tool 层的一个核心能力存在。Tool 层上面是 Planning 层负责决定“什么时候搜、搜什么”下面是 Memory 层负责存储“搜到了什么、哪些有用”。这三层的关系可以用一个简单类比理解Planning 是大脑Tool 是手脚Memory 是笔记本。联网搜索 Tool 的输入输出设计很关键。输入不应该只是“查询词”这一个参数还应该包括时间范围、结果数量、域名白名单/黑名单、是否需要全文抓取等。输出也不应该只是“网页摘要列表”而应该结构化标题、URL、发布时间、正文片段、可信度评分。这些设计细节直接决定了 Agent 的搜索质量和最终回答的可靠性。注意很多团队在初期会把搜索 Tool 设计得过于简单只接受一个 query 字符串结果 Agent 在复杂任务中反复搜到相同内容浪费 token 和时间。建议从一开始就把搜索 Tool 的参数设计得足够丰富。2. 核心细节解析与实操要点2.1 查询改写让 Agent 搜得更准用户的问题往往不适合直接作为搜索词。比如“那个很火的 AI 编程工具最近更新了什么”直接搜这句话效果很差。Agent 需要先做查询改写把口语化问题转成搜索引擎友好的关键词组合。常见的改写策略有三种关键词提取从问题中抽出核心实体和动作比如“AI 编程工具 更新 2024”。同义扩展把“AI 编程工具”扩展为“AI coding assistant”“Copilot”“Cursor”等。时间约束显式化把“最近”转成“2024年10月”或“past week”。我在实际项目里试过查询改写这一步能提升搜索命中率 30% 以上。具体做法是在 Agent 的 Planning 阶段加一个轻量的改写节点用一个小模型或者规则引擎完成成本很低但收益明显。2.2 结果筛选从噪声里捞出信号搜索引擎返回的结果天然包含大量噪声。Agent 需要一套筛选机制把真正有用的内容留下来。我常用的筛选维度包括筛选维度判断标准处理方式域名可信度官方文档、知名技术社区优先白名单加权发布时间超过一定时限的降权时间衰减函数内容重复度与已选结果高度相似的丢弃SimHash 去重正文完整度只有标题没有正文的丢弃长度阈值过滤广告标识带“广告”“推广”字样的丢弃关键词黑名单这套筛选逻辑不需要很复杂但一定要有。我见过太多项目直接把搜索结果前五条塞给模型结果模型被广告带偏回答里出现根本不存在的产品功能。2.3 多轮搜索的终止条件设计Agent 做多轮搜索时最大的风险是“搜不停”。如果没有合理的终止条件Agent 可能陷入无限循环或者搜了十几轮还在纠结细节。我一般会设置三个终止条件满足任意一个就停止信息充分性当前已收集的信息足以回答用户问题由 Planning 层判断。边际收益递减连续两轮搜索没有新增有效信息。硬性轮次上限最多搜索 N 轮N 通常设为 3 到 5。这里有个经验硬性轮次上限不要设得太高。我试过设 10 轮结果 Agent 在简单问题上也会搜很多次浪费资源。后来改成 3 轮复杂问题通过“信息充分性”判断来放行整体效果更好。2.4 搜索结果与 RAG 知识库的协同联网搜索和 RAG 知识库不是替代关系而是互补关系。RAG 知识库适合存储稳定、结构化的领域知识比如产品文档、内部规范联网搜索适合获取实时、动态的外部信息比如新闻、价格、版本更新。在实际架构里我通常会让 Agent 先查 RAG 知识库如果知识库能回答就直接用如果知识库信息不足或过时再触发联网搜索。这样既能保证回答的准确性又能控制搜索成本。两者的协同逻辑可以总结为RAG 优先知识库有答案时不搜网。搜索兜底知识库没有或置信度低时才搜网。结果融合把知识库内容和搜索结果合并标注来源。提示RAG 知识库能存储图片吗可以但需要额外的多模态处理。如果 Agent 需要理解图片内容建议把图片转成文字描述后再存入知识库或者使用支持多模态的向量模型。3. 实操过程与核心环节实现3.1 搭建一个最小可用的联网搜索 Agent下面是我在一个实际项目中搭建的最小可用方案技术栈是 Python LangChain 一个免费的联网搜索 API。整个流程分为四步定义搜索 Tool、构建 Agent、设计 Prompt、测试调优。第一步定义搜索 Tool。核心是把搜索 API 封装成 Agent 可以调用的函数输入输出都做结构化处理。import requests from langchain.tools import Tool def web_search(query: str, num_results: int 5, time_range: str any): 调用搜索 API返回结构化结果列表。 time_range: any / day / week / month / year params { q: query, num: num_results, time_range: time_range } resp requests.get(SEARCH_API_URL, paramsparams, headersHEADERS) raw resp.json() results [] for item in raw.get(results, []): results.append({ title: item.get(title, ), url: item.get(url, ), snippet: item.get(snippet, ), published: item.get(published, ), source: item.get(source, ) }) return results search_tool Tool( nameweb_search, funcweb_search, description当需要获取实时信息、新闻、最新版本号时使用。输入应为搜索关键词。 )第二步构建 Agent。这里用 LangChain 的 ReAct 模式让 Agent 在“思考-行动-观察”循环里自主决定何时搜索。from langchain.agents import initialize_agent, AgentType from langchain.chat_models import ChatOpenAI llm ChatOpenAI(modelgpt-4, temperature0) agent initialize_agent( tools[search_tool], llmllm, agentAgentType.ZERO_SHOT_REACT_DESCRIPTION, verboseTrue, max_iterations5 )第三步设计 Prompt。Prompt 里要明确告诉 Agent什么时候该搜索、搜索结果怎么用、什么时候停止。你是一个联网搜索助手。当用户问题涉及实时信息、最新动态、具体数据时你必须调用 web_search 工具。 搜索时先提取核心关键词不要直接使用用户原话。 拿到搜索结果后先判断信息是否充分。如果充分直接回答如果不充分可以再次搜索但最多搜索 3 次。 回答时必须标注信息来源的 URL。第四步测试调优。我用一组标准问题测试 Agent 的表现记录每次搜索的查询词、返回结果数量、最终回答质量。根据测试结果调整 Prompt 和搜索参数。3.2 搜索 API 的选型与参数调优免费的联网搜索 API 有不少选择但质量和限制差异很大。我对比过几个常用方案API 方案免费额度结果质量延迟适用场景某搜索开放平台每日 100 次高低通用搜索某开发者搜索 API每月 1000 次中中技术内容某聚合搜索每日 50 次中高中多源聚合选型时重点看三个指标结果相关性、响应延迟、免费额度是否够用。如果 Agent 每天处理几百个请求100 次/天的免费额度肯定不够需要考虑付费方案或者做缓存。参数调优方面num_results不要设太大。我试过设 10结果大量无关内容涌入模型反而抓不住重点。后来改成 5配合筛选逻辑效果更好。time_range参数在问“最新”类问题时一定要用能显著提升结果时效性。3.3 搜索结果的结构化处理与 Prompt 注入搜索结果不能直接拼成字符串塞给模型需要做结构化处理。我的做法是对每条结果提取标题、URL、发布时间、正文片段。按可信度和时效性排序。截断过长的正文片段保留前 500 字符。用固定格式拼接方便模型解析。def format_search_results(results): formatted [] for i, r in enumerate(results, 1): formatted.append( f[{i}] {r[title]}\n fURL: {r[url]}\n f发布时间: {r[published]}\n f摘要: {r[snippet][:500]}\n ) return \n---\n.join(formatted)注入 Prompt 时把格式化后的结果放在“参考资料”区块里并明确告诉模型“以下是从网络搜索到的参考资料请基于这些资料回答不要编造。”3.4 多轮搜索的编排与状态管理多轮搜索需要状态管理。我通常用一个简单的字典来记录每轮搜索的查询词、结果、是否已使用。search_state { round: 0, queries: [], results: [], used_urls: set() }每轮搜索前检查round是否超过上限搜索后把新结果追加到results把已使用的 URL 加入used_urls。下一轮搜索时把used_urls传给搜索 Tool让它过滤掉已经看过的结果。这个状态管理逻辑不复杂但能有效避免重复搜索和无限循环。我在实际项目里踩过的坑是没有记录已用 URL结果 Agent 反复搜到同一篇文章浪费了两轮搜索机会。4. 常见问题与排查技巧实录4.1 搜索结果质量差怎么办这是最常见的问题。排查思路按优先级排列检查查询词是不是直接用了用户原话如果是先做查询改写。检查时间范围问“最新”类问题时有没有设置time_range检查结果数量是不是设得太大导致噪声过多检查筛选逻辑有没有做域名白名单、去重、广告过滤检查 API 本身换个 API 试试有些 API 的结果质量确实差。我遇到过一次Agent 搜“Python 异步编程最佳实践”返回的全是广告和低质量博客。后来发现是查询词太宽泛改成“Python asyncio best practices 2024 site:realpython.com”之后结果质量立刻提升。4.2 Agent 陷入无限搜索循环这个问题的根源通常是终止条件没设计好。排查步骤检查max_iterations是否设置建议 3 到 5。检查“信息充分性”判断逻辑是不是太严格导致 Agent 总觉得信息不够。检查搜索结果是否被正确注入 Prompt如果模型看不到搜索结果它会一直搜。我试过一种情况搜索结果格式不对模型解析不了以为没搜到东西就反复搜。后来把格式改成固定模板问题解决。4.3 搜索结果与模型知识冲突有时候搜索结果和模型内部知识矛盾模型会倾向于相信自己“记住”的东西。解决办法是在 Prompt 里明确优先级“当搜索结果与你的内部知识冲突时以搜索结果为准并标注来源。”如果冲突频繁发生说明模型内部知识可能过时需要考虑用 RAG 知识库做补充或者换一个知识更新更及时的模型。4.4 常见问题速查表问题现象可能原因排查方法解决方案回答里出现不存在的信息搜索结果噪声大模型编造检查搜索结果质量加强筛选Prompt 强调“不要编造”搜索次数过多终止条件缺失查看 Agent 日志设置 max_iterations 和信息充分性判断搜索结果重复未记录已用 URL检查 search_state加入 used_urls 过滤回答时效性差未设置时间范围检查搜索参数设置 time_range搜索延迟高API 响应慢测试 API 延迟换 API 或加缓存模型忽略搜索结果Prompt 未强调检查 Prompt明确“基于参考资料回答”4.5 实操心得与避坑技巧第一个心得搜索 Tool 的 description 要写清楚。Agent 靠 description 判断什么时候调用这个 Tool。如果写得太模糊Agent 可能在该搜的时候不搜不该搜的时候乱搜。我一般会写“当问题涉及实时信息、最新动态、具体数据、新闻事件时使用。输入应为搜索关键词不要使用完整句子。”第二个心得缓存搜索结果。同一个查询词在短时间内可能被多次搜索加一层缓存能显著降低 API 调用量和延迟。我用 Redis 做缓存TTL 设为 1 小时效果很好。第三个心得记录搜索日志。每次搜索的查询词、返回结果、Agent 的决策过程都记录下来。出问题时日志是唯一的排查依据。我见过太多项目没有日志出了问题只能靠猜。第四个心得不要迷信单次搜索。复杂问题一定要允许多轮搜索但轮次上限要控制。我的经验是 3 轮足够覆盖 90% 的场景超过 3 轮还没搜到要么是问题太偏要么是搜索策略有问题。第五个心得搜索结果的可信度要标注。官方文档、知名社区、个人博客的可信度不一样。在 Prompt 里告诉模型“优先使用官方文档和知名社区的内容个人博客的内容仅作参考。”这样能减少模型被低质量内容带偏的概率。4.6 从 RAG 到 Agent 搜索的迁移经验如果你已经有 RAG 知识库想加上联网搜索能力我的建议是不要推翻重来而是在现有架构上做增量。具体做法保留 RAG 检索链路作为第一优先级。新增 web_search Tool作为兜底。在 Planning 层加一个判断节点RAG 置信度低于阈值时触发搜索。搜索结果和 RAG 结果做融合排序统一注入 Prompt。这样迁移成本最低而且能复用已有的 RAG 基础设施。我试过在一个已有 RAG 项目上加联网搜索两天就完成了效果比预期好很多。注意RAG 知识库和结构知识库的区别在于RAG 知识库通常是非结构化的文本向量库适合语义检索结构知识库是图数据库或关系数据库适合精确查询和推理。Agent 搜索场景下两者可以结合使用比如先用结构知识库做实体识别再用 RAG 做语义补充。4.7 Agent 安全与搜索边界联网搜索 Agent 有一个容易被忽视的风险搜索内容可能包含不安全或不可信的信息。我一般会做三层防护域名黑名单过滤掉已知的低质量或风险域名。内容过滤对搜索结果做敏感词和风险内容检测。Prompt 约束明确告诉模型“只基于可信来源回答遇到不确定的信息要标注”。这三层防护不需要很复杂但一定要有。我见过一个项目Agent 搜到了一条错误的产品价格信息直接回答给用户造成了客诉。后来加了域名白名单问题再没出现过。4.8 性能优化与成本控制联网搜索的成本主要来自两块API 调用费用和 token 消耗。优化方向缓存相同查询词直接返回缓存结果减少 API 调用。结果截断搜索结果只保留前 500 字符减少 token 消耗。按需搜索不是所有问题都需要搜索Planning 层要做好判断。批量搜索如果多个子问题可以合并成一个查询词就合并。我实测下来加缓存和结果截断之后整体成本降低了约 40%而回答质量没有明显下降。4.9 后续扩展方向这个架构后续可以往几个方向扩展。一是加入多模态搜索让 Agent 能搜图片和视频二是加入垂直领域搜索比如学术搜索、代码搜索三是把搜索能力封装成独立的 Agent Skill方便在不同项目间复用。我个人比较看好的是把联网搜索和 Agent 记忆结合。Agent 每次搜索的结果如果有长期价值就存入记忆库下次遇到类似问题直接调用不用重新搜。这样既能提升响应速度又能降低搜索成本。