1. 从搜索框到 Agent 的演进逻辑1.1 为什么传统搜索框模式走到了瓶颈做 Chatbot 的人都有一个共同的体感用户问的问题越来越“不像搜索词”了。早年大家用搜索框输入的是“北京天气”“Python 列表去重”这种短关键词搜索引擎靠倒排索引加 BM25 就能给出不错的答案。但到了 Chatbot 场景用户输入的是“帮我对比一下这三个方案在并发场景下的取舍顺便看看有没有现成的开源实现”这是一整段自然语言里面藏着多个意图、多个约束条件还有隐含的上下文。传统搜索框模式的核心问题是它只负责“找”不负责“答”。它把一堆链接丢给你剩下的信息整合、事实核验、多轮追问全靠人。Chatbot 如果只是把搜索引擎的结果原样贴回来那它本质上就是个带对话框的搜索页用户不会觉得它“聪明”。真正让 Chatbot 有价值的是它能理解意图、能整合信息、能给出结论而这三件事都要求它必须能主动去“联网搜索”而不是被动等用户喂关键词。这就是从搜索框到 Agent 的第一层演进动力交互形态从“关键词匹配”变成了“意图理解加任务执行”。搜索框是被动的Agent 是主动的。搜索框给你原料Agent 给你成品。1.2 联网搜索在 Agent 体系里到底扮演什么角色很多人把联网搜索理解成一个“工具调用”觉得 Agent 需要的时候调一下 web_search 接口就完事了。这个理解太浅。联网搜索在 Agent 体系里其实是感知层的核心组件它决定了 Agent 的知识边界能延伸多远。一个纯靠本地知识库的 Agent它的能力上限就是训练数据的时间戳和覆盖范围。你问它昨天发生的事它不知道你问它某个小众产品的参数它可能编。联网搜索补的就是这块让 Agent 在推理过程中能实时获取外部信息把“我不知道”变成“我去查一下”。但这里有个关键区别搜索框时代的联网是“人驱动”的Agent 时代的联网是“模型驱动”的。人驱动的时候搜索质量取决于人会不会写关键词模型驱动的时候搜索质量取决于 Agent 会不会拆解问题、会不会构造查询、会不会判断结果够不够、要不要再搜一轮。这就把联网搜索从一个简单的 API 调用变成了一个需要编排、需要评估、需要反馈闭环的子系统。1.3 从 RAG 到 Agentic Search 的范式迁移RAG 是这条演进路线上绕不开的一站。RAG 的核心思路是“先检索再生成”把外部知识塞进上下文让模型基于检索结果回答。它解决了大模型知识过时和幻觉的问题但它有个天然局限RAG 的检索通常是一次性的、静态的。你检索一次拿到 top-k 文档然后生成结束。如果检索结果不好模型也只能硬着头皮答。Agentic Search 把这个流程动态化了。Agent 可以决定“我要不要搜”“搜什么”“搜几次”“结果够不够”“要不要换个角度再搜”。它把检索从流水线里的一个固定环节变成了一个可以反复调用的工具。这个转变看起来小实际上影响巨大它让联网搜索从“增强生成”变成了“驱动推理”。我个人的判断是RAG 不会消失它会退化成 Agentic Search 里的一个子能力。未来的主流架构是 Agent 主导编排RAG 作为其中一种检索策略存在而不是反过来。2. 核心技术点拆解与选型考量2.1 web_search 工具的设计要点给 Agent 接一个 web_search 工具看起来就是包一个 HTTP 请求但实际做起来坑很多。第一个要决定的是搜索源。免费的联网搜索 API 有不少选择但免费通常意味着限流、结果质量不稳定、没有 SLA。如果做的是生产级 Agent我建议至少准备两个搜索源做 fallback一个主用一个备用避免单点故障。第二个要决定的是返回格式。搜索引擎原始返回的是一堆 HTML 或者 JSON里面包含标题、链接、摘要、时间戳。直接把这些塞给模型是浪费 token 的因为模型不需要那么多噪音。我的做法是在工具层做一次预处理抽取标题、核心摘要、发布时间、来源域名压缩成结构化文本再返回。这样既省 token又让模型更容易判断信息的相关性和时效性。第三个要决定的是结果数量。top-k 里的 k 不是越大越好。k 太大上下文被噪音淹没模型反而抓不住重点k 太小可能漏掉关键信息。实测下来单次搜索返回 5 到 8 条是比较舒服的区间具体取决于你的任务类型。事实查询类可以少一点调研分析类可以多一点。# web_search 工具层的简化示意 def web_search(query: str, top_k: int 6) - list[dict]: raw search_api.search(query, counttop_k * 2) results [] for item in raw: results.append({ title: item.get(title, ), snippet: item.get(snippet, )[:300], url: item.get(url, ), published: item.get(published, ), source: extract_domain(item.get(url, )) }) return results[:top_k]注意工具层一定要做超时和重试控制。搜索接口偶尔抽风是常态没有超时保护的 Agent 会被一个卡住的请求拖死整个推理链。2.2 查询构造Agent 会不会“问对问题”联网搜索的质量七成取决于查询构造。同一个问题查询写得好和写得差结果天差地别。Agent 构造查询的能力直接决定了它的搜索上限。我观察到的一个常见问题是Agent 倾向于把用户的原始问题直接当查询用。用户问“最近有什么好用的开源向量数据库”Agent 就把这整句话丢给搜索引擎。这其实不是最优的因为搜索引擎对长自然语言句子的处理不如对关键词组合的处理。更好的做法是让 Agent 先把问题拆成几个子查询比如“开源向量数据库 2024”“向量数据库 对比”“Milvus Qdrant 性能”然后并行搜最后合并。这就引出了查询构造的几个实用策略问题拆解把复合问题拆成原子子问题每个子问题单独构造查询关键词提取从自然语言里抽出核心实体和限定词去掉语气词和冗余修饰同义扩展对关键概念做同义词替换提高召回率时间限定如果问题涉及时效性在查询里加上时间词我在实际项目里会让 Agent 在搜索前先输出一个“搜索计划”列出它打算搜什么、为什么这么搜。这个计划本身不一定要给用户看但它能显著提升搜索的针对性也方便调试。2.3 结果评估与多轮搜索的触发条件搜完一轮之后Agent 要判断“够不够”。这个判断能力是 Agentic Search 和普通 RAG 的分水岭。普通 RAG 搜完就生成Agentic Search 要评估结果质量决定要不要再搜。评估的维度我一般看这几个评估维度判断标准不达标时的动作相关性结果是否直接回应了子问题换查询词重搜覆盖度子问题是否都有对应结果补充缺失子问题的搜索时效性信息是否在有效时间范围内加时间限定重搜一致性多个来源是否互相印证找权威来源交叉验证充分性信息量是否足够支撑回答扩大 top-k 或换角度搜这套评估不需要很复杂用模型自己判断就行。关键是给模型一个明确的判断框架让它知道“什么算够”。我试过让模型自由判断结果它经常搜一轮就收手哪怕结果明显不够。后来改成结构化评估让它逐项打分触发多轮搜索的准确率提升很明显。多轮搜索要有上限一般 2 到 3 轮就够了。超过 3 轮还没搜到要么是问题本身无解要么是查询策略有问题继续搜也是浪费。这时候应该让 Agent 诚实地告诉用户“我没找到足够的信息”而不是硬编一个答案。3. 实操搭建一个可复现的联网搜索 Agent3.1 整体架构与模块划分我拿一个实际做过的调研型 Agent 来拆。这个 Agent 的需求是用户给一个话题它自动联网搜索、整合信息、输出一份带来源的简报。整体架构分四层接入层接收用户输入做初步的意图识别和任务分类编排层Agent 主循环负责规划、调用工具、评估结果、决定下一步工具层web_search、网页正文抓取、结果去重、来源可信度打分生成层把整合后的信息组织成结构化输出附上引用来源编排层是核心。我用的是“规划-执行-评估”的循环结构而不是简单的 ReAct。区别在于ReAct 是边想边做容易跑偏规划-执行-评估是先出计划再执行执行完评估评估不过再调整计划。对于搜索这种需要多步的任务规划式结构更稳。3.2 搜索工具链的配置与参数工具链的配置有几个关键参数需要调SEARCH_CONFIG { max_queries_per_round: 4, # 单轮最多并行几个查询 top_k_per_query: 6, # 每个查询返回几条 max_search_rounds: 3, # 最多搜几轮 timeout_seconds: 8, # 单次搜索超时 retry_times: 2, # 失败重试次数 dedup_threshold: 0.85, # 结果去重的相似度阈值 min_relevance_score: 0.6, # 结果相关性的最低分 }max_queries_per_round设成 4 是个经验值。设太小覆盖度不够设太大并行请求多了容易触发限流而且合并结果的成本也上去了。dedup_threshold用 0.85 是因为不同来源经常报道同一件事措辞略有不同相似度在 0.8 到 0.9 之间的基本都是重复内容去重能省不少 token。网页正文抓取这块要注意不是所有搜索结果都值得抓正文。摘要已经能回答问题的就不用抓摘要信息不足的才去抓正文。抓正文也要限制长度一般截取前 2000 字就够了太长的页面抓下来也是噪音。3.3 主循环的伪代码与关键控制点def research_agent(user_query: str) - str: plan generate_search_plan(user_query) all_findings [] for round_idx in range(SEARCH_CONFIG[max_search_rounds]): queries plan.get_queries_for_round(round_idx) results parallel_search(queries) results dedup_and_filter(results) evaluation evaluate_results(results, plan.sub_questions) if evaluation.is_sufficient: all_findings.extend(results) break all_findings.extend(evaluation.useful_results) plan refine_plan(plan, evaluation.gaps) return synthesize_answer(user_query, all_findings)关键控制点有三个。第一generate_search_plan必须把用户问题拆成明确的子问题不能含糊。第二evaluate_results要输出结构化的评估结果包括哪些子问题被覆盖了、哪些还有缺口。第三refine_plan要基于缺口调整查询而不是重复搜同样的东西。我踩过的一个坑是早期版本里refine_plan只是简单地把没搜到的子问题再搜一遍结果第二轮和第一轮结果高度重合。后来改成让模型分析“为什么没搜到”是查询词不对还是信息本身稀缺然后针对性地换策略效果才好起来。3.4 结果整合与引用标注搜完之后整合是最后一道关。整合不是把结果拼起来而是要做信息抽取、冲突消解、结构化组织。信息抽取是把每条结果里的关键事实抽出来形成“事实-来源”的配对。冲突消解是当不同来源说法不一致时判断哪个更可信。我的做法是看来源权威性、发布时间、是否有其他来源印证。结构化组织是按子问题分组每个子问题下面列出找到的事实和对应来源。引用标注很重要它决定了输出的可信度。我的做法是给每条事实标注来源编号输出末尾附上来源列表。这样用户能追溯每个结论的出处也方便后续核验。提示引用标注不要只标链接最好带上来源域名和发布时间。用户判断信息可信度时这两个信息比链接本身更有用。4. 常见问题与排查实录4.1 搜索结果质量差的排查思路搜索质量差是最常见的问题表现是 Agent 搜回来的东西跟问题不相关。排查要按顺序来先看查询词。把 Agent 实际发出的查询打出来看很多时候问题就出在查询词上。如果查询词是用户原话那基本可以确定是查询构造没做好。如果查询词看起来合理但结果还是差那可能是搜索源的问题。再看搜索源。同一个查询在不同搜索源上的结果差异可能很大。如果某个源持续返回低质结果考虑换源或者调整该源的权重。最后看评估环节。有时候结果其实不差是评估环节误判了把好结果过滤掉了。这时候要检查相关性打分的阈值是不是设太高了。4.2 多轮搜索陷入死循环怎么办死循环的表现是 Agent 反复搜同样的内容每轮结果都差不多但就是判断“不够”。这个问题通常出在评估和计划调整的衔接上。我的解决办法是加一个“搜索历史去重”机制每轮搜索前把已经搜过的查询和已经获取的结果做一次比对如果新查询和旧查询相似度超过阈值就强制换策略。同时给评估环节加一个“边际收益”判断如果这一轮新增的有效信息很少就判定为收敛停止搜索。还有一个更根本的办法在计划阶段就把子问题拆得足够细让每个子问题都有明确的“完成标准”。这样评估的时候有据可依不会出现“感觉不够但又说不清哪里不够”的情况。4.3 时效性信息的处理技巧时效性信息是联网搜索的强项但也是容易翻车的地方。搜索引擎的索引有延迟刚发生的事可能搜不到搜到的信息可能是旧的但没标注时间。我的处理技巧是在查询里显式加时间限定词比如“2024年”“最新”“本月”。同时在结果过滤时优先保留带明确发布时间的来源对没有时间标注的结果降低权重。如果问题对时效性要求很高我会在评估环节加一条“时效性检查”确保关键信息来自近期来源。4.4 常见问题速查表问题现象可能原因排查动作解决方向搜不到相关内容查询词太窄或太泛打印实际查询词调整查询构造策略结果重复度高去重阈值太低检查去重配置提高相似度阈值多轮搜索不收敛评估标准模糊检查评估输出细化子问题完成标准信息冲突无法判断缺来源可信度评估检查来源打分逻辑加权威性权重响应太慢并行度不够或超时太长看各环节耗时提高并行、缩短超时token 消耗过大结果未压缩统计上下文长度工具层做结果压缩4.5 几个我踩过的坑第一个坑是过度依赖单一搜索源。早期我只接了一个搜索 API有次那个 API 抽风整个 Agent 直接瘫了。后来改成双源 fallback主源超时就切备源稳定性好了很多。第二个坑是把搜索结果直接塞进上下文。搜索引擎返回的原始结果里有很多噪音直接塞进去不仅浪费 token还干扰模型判断。工具层做预处理这一步绝对不能省。第三个坑是忽略搜索成本。联网搜索是有成本的不管是 API 调用费还是延迟。早期我没做搜索次数控制Agent 有时候一个简单问题搜七八轮用户体验很差。后来加了轮次上限和边际收益判断成本降下来了效果反而更好。第四个坑是评估环节太宽松。模型天生倾向于“觉得够了”如果不给它明确的评估框架它很容易搜一轮就收手。结构化评估加明确的完成标准是解决这个问题的关键。联网搜索这块我的整体体会是它不是一个“接上就能用”的组件而是一个需要精心设计的子系统。查询构造、结果评估、多轮控制、成本管理每一环都有讲究。把这些做扎实了Agent 的信息获取能力会有质的提升做不好它就是个会花钱的搜索框。后续如果要继续扩展我会往“搜索策略自适应”的方向走让 Agent 根据问题类型自动选择搜索深度和广度而不是用一套固定参数打天下。