从RAG到Agent：联网搜索与工具调用式搜索的工程实践-北京尧图网络

1. 从搜索框到 Agent 的演进逻辑1.1 为什么传统搜索框模式走到了瓶颈做过 Chatbot 的人都有一个共同体会用户问“今天有什么值得关注的科技新闻”如果机器人只能从训练数据里翻答案那它给出的内容大概率是几个月前的旧闻。这就是纯生成式模型的硬伤——知识截止日期。早期大家用 RAG 来补把文档切片塞进向量库检索回来再让模型组织语言。这套方案在垂直知识库场景下确实能跑但一旦面对开放域的实时信息RAG 的短板就暴露得很明显。RAG 的本质是“先检索、后生成”检索的质量直接决定生成的上限。而检索依赖的是预先构建好的索引索引之外的东西一概看不见。用户问“某公司昨天发布了什么新品”你的向量库里没有这条数据检索结果就是空的模型只能硬编或者拒答。更麻烦的是RAG 对多跳推理的支持很弱。用户问“A 公司的 CEO 上个月在 B 会议上说了什么关于 C 技术的观点”这需要先找到 CEO 是谁、再找到会议记录、再定位到具体发言传统 RAG 很难把这条链路串起来。所以行业里开始出现一个共识光靠静态知识库不够Chatbot 需要“联网搜索”的能力。这就是 web_search 被引入的直接原因。但联网搜索本身也不是终点它只是 Agent 能力的一个子集。从搜索框到 Agent中间经历了几个关键阶段每个阶段解决的问题不同技术选型也不同。1.2 三个阶段的技术分水岭第一个阶段是“搜索增强生成”也就是 Search-Augmented Generation。做法很直接用户提问后先调用搜索引擎 API 拿到网页摘要把摘要拼进 prompt 里让模型回答。这个阶段的核心问题是“怎么把搜索结果塞进上下文”工程上主要处理截断、排序、去重。优点是实现快缺点是模型对搜索结果几乎没有控制权搜到什么就用什么。第二个阶段是“工具调用式搜索”模型开始具备决定“要不要搜、搜什么、搜几次”的能力。这时候 Function Calling 机制成熟了模型可以输出一个结构化的搜索请求系统执行后再把结果喂回去。这个阶段的关键变化是搜索从“固定流程”变成了“模型自主决策”。但问题也随之而来——模型经常该搜的时候不搜不该搜的时候乱搜搜索词的质量也参差不齐。第三个阶段就是现在大家说的 Agent 化搜索。Agent 不只是调用一次搜索而是把搜索当成一个可编排的工具配合规划、记忆、反思等能力形成“搜索-阅读-推理-再搜索”的循环。比如用户问一个复杂问题Agent 会先拆解成子问题逐个搜索发现信息冲突时主动追加搜索验证最后综合多源信息给出带引用的答案。这个阶段的核心技术点包括任务规划、工具编排、上下文管理、结果验证。注意很多团队一上来就想做第三阶段结果连第一阶段的检索质量都没打磨好。我的建议是先把搜索结果的清洗和排序做扎实再往上叠 Agent 能力否则就是在沙地上盖楼。1.3 一张表看清三个阶段的差异维度搜索增强生成工具调用式搜索Agent 化搜索决策主体固定流程模型单次决策模型多轮规划搜索次数通常 1 次1-3 次动态多轮上下文管理简单拼接结果回填记忆压缩引用典型问题信息过时搜索时机不准编排复杂度高适用场景简单问答中等复杂度查询研究型任务这张表不是要说明哪个阶段更高级而是帮助你在做技术选型时快速定位你的业务到底需要哪一档能力。很多客服场景其实第一阶段就够了硬上 Agent 反而增加延迟和成本。2. 联网搜索的核心技术拆解2.1 搜索 API 的选型与免费方案做联网搜索第一步是解决“搜什么”的问题。市面上可选的搜索接口大致分几类通用网页搜索、垂直领域搜索、学术搜索、新闻搜索。选型时重点看三个指标结果质量、调用延迟、配额限制。免费方案里常见的有基于开源搜索引擎自建、调用公开的搜索接口、以及一些平台提供的免费额度。自建的话可以用开源的爬虫框架配合索引引擎但维护成本不低尤其是反爬策略变化频繁。调用公开接口相对省事但要注意稳定性和结果格式的统一。我的经验是如果只是做原型验证先用免费额度跑通流程如果要上生产一定要准备至少两个搜索源做兜底避免单点故障。搜索结果的返回格式通常包括标题、摘要、URL、发布时间。这里有个容易被忽略的点发布时间。很多搜索接口不返回这个字段或者返回得不准确。但对于时效性要求高的场景没有时间戳就没法做结果过滤。我的做法是在结果清洗阶段用启发式规则从摘要或 URL 里提取时间信息提取不到的就标记为“未知时间”在排序时降权。2.2 搜索结果如何喂给模型截断、排序与去重搜索结果拿到手之后不能直接一股脑塞进 prompt。原因很简单上下文窗口有限而且无关信息会干扰模型判断。这里要做三件事。第一是去重。不同搜索源返回的结果经常高度重叠尤其是热门话题。去重不能只看 URL因为同一篇文章可能被多个站点转载。我的做法是计算标题和摘要的相似度超过阈值的只保留一条。相似度可以用简单的 Jaccard 或者编辑距离不需要上 embedding省时省力。第二是排序。搜索接口返回的顺序未必适合模型阅读。我会综合几个信号重新排序来源权威性、时间新鲜度、摘要与问题的语义相关度。语义相关度可以用一个轻量级的交叉编码器算也可以用关键词覆盖率做近似。实测下来加一层重排序能让最终答案的准确率提升不少。第三是截断。每条结果不能全文塞入通常只保留标题加前 200-300 字摘要。如果摘要本身就不完整可以考虑抓取网页正文再做摘要。但抓取正文有延迟和失败风险需要设置超时和降级策略。def prepare_search_context(results, max_tokens2000): # 去重 seen set() unique [] for r in results: key r[title][:50] if key not in seen: seen.add(key) unique.append(r) # 排序时间新鲜度来源权重 unique.sort(keylambda x: (x.get(freshness, 0), x.get(authority, 0)), reverseTrue) # 截断拼接 context for r in unique: snippet f标题{r[title]}\n摘要{r[snippet][:300]}\n来源{r[url]}\n\n if len(context) len(snippet) max_tokens * 4: break context snippet return context这段代码是个简化版实际用的时候还要考虑 token 计算方式、多语言处理等细节。但核心思路就是先去重、再排序、后截断三步不能省。2.3 让模型学会“什么时候该搜”这是工具调用式搜索最核心的问题。模型如果太保守该搜的时候不搜答案就会过时如果太激进每句话都搜延迟和成本都受不了。解决办法是在系统提示里明确搜索的触发条件。我常用的触发规则有这么几条涉及具体时间点的事件、涉及实时数据股价、天气、比分、涉及训练数据截止日期之后的信息、涉及需要验证的事实性陈述。反过来常识性问题、纯推理问题、创意写作类请求就不需要搜。但光靠提示词还不够稳。更可靠的做法是加一个轻量级的分类器判断当前 query 是否需要联网。这个分类器可以用小模型微调也可以用规则加关键词匹配做冷启动。我的经验是规则覆盖 80% 的常见情况剩下的交给模型自己判断同时在提示里给出 few-shot 示例效果比纯规则好很多。还有一个细节搜索词的质量。用户的原话往往不适合直接拿去搜需要改写成更精准的查询。比如用户问“那个新出的手机怎么样”直接搜这句话效果很差应该先让模型改写成“某品牌最新型号评测”再去搜。这个改写步骤可以放在工具调用之前作为 Agent 规划的一部分。3. 从 RAG 到 Agent 搜索的实操路径3.1 RAG 知识库与联网搜索的边界划分很多团队纠结一个问题我已经有 RAG 知识库了还需要联网搜索吗答案是看场景。RAG 知识库适合存私有数据、领域知识、历史文档这些内容搜索引擎搜不到或者搜到的版本不对。联网搜索适合获取公开的、实时的、开放域的信息。两者不是替代关系而是互补关系。我的做法是做一个路由层先判断用户问题属于哪一类。如果问题涉及内部文档、产品手册、历史记录走 RAG 检索如果涉及实时新闻、公开数据、外部事件走联网搜索如果两者都涉及就并行执行再合并结果。路由的判断可以基于关键词也可以用一个小的意图分类模型。这里有个坑要注意RAG 知识库和联网搜索的结果格式不一样合并时要做归一化。RAG 返回的是文档片段联网搜索返回的是网页摘要两者的粒度、可信度、时效性都不同。合并时我会给 RAG 结果更高的权重因为私有数据的准确性通常更高联网结果作为补充标注来源和时间让用户自己判断。3.2 Agent 搜索的编排流程设计一个完整的 Agent 搜索流程通常包含这几个环节意图理解、任务规划、搜索执行、结果阅读、信息综合、答案生成。每个环节都可以独立优化。意图理解阶段要判断用户到底想要什么。是想要一个事实答案还是想要一份综述还是想要对比分析不同的意图对应不同的搜索策略。事实型问题可能一次搜索就够综述型问题需要多轮搜索加信息聚合。任务规划阶段把复杂问题拆成子问题。比如“对比 A 和 B 两个方案的优缺点”可以拆成“A 方案的优缺点”“B 方案的优缺点”“两者的差异点”三个子任务。每个子任务独立搜索最后汇总。拆解的好处是每个子问题更聚焦搜索结果质量更高。搜索执行阶段要注意并发控制。多个子任务可以并行搜索但要注意 API 的速率限制。我的做法是用一个任务队列控制并发数失败的任务自动重试重试超过次数就降级为“未找到相关信息”。结果阅读阶段模型需要从搜索结果里提取关键信息。这一步可以用模型直接读也可以用抽取式方法先筛一遍。对于长网页我倾向于先做段落级的相关度打分只把最相关的段落喂给模型减少干扰。信息综合阶段要把多个来源的信息整合成连贯的答案。这里最大的挑战是处理冲突信息。不同来源说法不一致时Agent 应该标注出来而不是随便选一个。我的做法是让模型输出时附带置信度低置信度的部分明确说明“存在不同说法”。3.3 上下文管理与记忆机制Agent 多轮搜索会产生大量中间结果上下文很快就会爆。所以必须有压缩和记忆机制。我的做法是分三层短期记忆存当前轮次的搜索结果中期记忆存已经提取的关键事实长期记忆存用户偏好和历史交互。短期记忆用滑动窗口管理只保留最近几轮的结果。中期记忆用结构化的形式存储比如“事实某公司于某日发布某产品来源某链接置信度高”。长期记忆可以存到外部存储需要时再检索回来。压缩的策略有两种一种是摘要式压缩让模型把长文本缩成短摘要另一种是抽取式压缩只保留关键句子。摘要式压缩信息损失小但成本高抽取式压缩成本低但可能漏掉重要信息。我通常混合使用先抽取关键句再对关键句做摘要。提示上下文压缩是有损的压缩比例越高信息损失越大。建议在压缩后保留原始结果的引用链接方便需要时回溯。4. 常见问题与排查技巧实录4.1 搜索结果质量差的排查思路搜索结果质量差是最常见的问题表现是模型给出的答案和搜索结果对不上或者答案明显过时。排查时按这个顺序来先看搜索词是否准确再看搜索接口是否正常返回再看结果清洗是否过度最后看模型是否忽略了搜索结果。搜索词的问题最常见。用户的原话直接拿去搜往往搜不到想要的东西。解决办法是加一层查询改写让模型把口语化的问题转成关键词组合。改写时要注意保留时间、地点、实体等关键约束不要改得面目全非。搜索接口的问题通常是配额用完或者接口变更。建议加监控记录每次调用的返回状态和耗时异常时及时告警。另外不同接口的结果格式可能不一样解析逻辑要写得健壮一些遇到字段缺失要有默认值。结果清洗过度也会导致问题。比如去重阈值设得太低把相关但略有差异的结果误删了或者截断太狠把关键信息截掉了。这些参数需要根据实际数据调没有万能值。模型忽略搜索结果通常是因为提示词没写清楚。要在系统提示里明确要求“优先使用搜索结果中的信息”“如果搜索结果与你的知识冲突以搜索结果为准”。同时搜索结果在 prompt 里的位置也很重要放在靠前的位置模型更容易注意到。4.2 延迟与成本的平衡技巧联网搜索会显著增加响应时间因为要等搜索接口返回、要抓取网页、要多轮推理。优化延迟的手段有几个并行搜索、缓存结果、预取、降级。并行搜索是最直接的多个子问题同时搜总耗时取决于最慢的那个。缓存结果适合高频重复的查询比如热门新闻缓存几分钟就能省掉大量重复调用。预取是在用户还没问之前就提前搜好可能相关的内容适合有明确上下文的多轮对话。降级是在搜索超时或失败时退回到不搜索的模式至少给用户一个回复。成本方面搜索 API 通常按调用次数计费所以要控制搜索次数。我的做法是设置一个上限比如单次对话最多搜 5 次超过就停止搜索用已有信息回答。另外结果清洗阶段尽量用轻量级方法不要每个结果都调大模型那样成本会失控。4.3 常见问题速查表问题现象可能原因排查方法解决建议答案过时未触发搜索检查触发规则补充时效性关键词答案与搜索无关搜索词质量差打印实际搜索词加查询改写层响应超时搜索接口慢记录接口耗时设超时降级信息冲突多源结果不一致检查来源权重标注冲突置信度上下文溢出结果未压缩统计 token 数加压缩滑动窗口重复搜索规划不合理检查任务拆解合并相似子任务这张表是我在实际项目中踩坑后整理的基本覆盖了八成以上的常见问题。遇到新问题时先对照这张表排查能省不少时间。4.4 几个容易被忽略的细节第一个细节是搜索结果的时效标注。很多搜索接口不返回发布时间但用户对时效很敏感。我的做法是在结果展示时如果时间未知就标注“时间未知”不要假装是新的。这样用户自己会判断可信度。第二个细节是引用格式。Agent 给出的答案最好附带来源链接方便用户核实。引用格式要统一不要一会儿是 URL 一会儿是标题。我通常用“来源标题 ”的格式简洁清晰。第三个细节是失败处理。搜索失败是常态不能假设每次都成功。失败时要给用户明确的反馈比如“暂时无法获取最新信息以下回答基于已有知识”而不是假装搜到了。第四个细节是多语言处理。如果用户用中文问但搜索结果主要是英文需要做翻译或者跨语言检索。跨语言检索可以用多语言 embedding也可以先翻译查询再搜。翻译查询的成本更低但可能损失一些语义细节。5. Agent 搜索的进阶方向5.1 多 Agent 协作搜索单 Agent 搜索能力有限复杂任务可以拆给多个 Agent 协作。比如一个 Agent 负责规划一个负责搜索一个负责阅读一个负责综合。每个 Agent 专注自己的环节通过消息传递协作。这种架构的好处是每个环节可以独立优化坏处是通信开销大调试复杂。我的经验是不要一上来就搞多 Agent。先把单 Agent 的搜索流程跑通找到瓶颈在哪再决定要不要拆。很多时候瓶颈在搜索质量拆成多 Agent 也解决不了。只有当任务确实需要并行处理、或者不同环节需要不同模型时多 Agent 才有明显收益。5.2 搜索结果的验证与反思Agent 搜到信息后应该有一个验证环节。验证的方式包括交叉验证多个来源是否一致、逻辑验证信息是否自洽、时效验证信息是否过时。发现可疑信息时Agent 应该主动追加搜索而不是直接采用。反思机制是让 Agent 回顾自己的搜索过程判断是否有遗漏或偏差。比如问“还有哪些角度没搜到”“搜索结果是否偏向某一方”。这个机制能显著提升答案的全面性但会增加延迟和成本适合对质量要求高的场景。5.3 与知识库的深度融合联网搜索和 RAG 知识库的融合是未来的方向。理想状态下Agent 能自动判断信息应该从知识库取还是从网上搜取回来后统一做冲突检测和置信度评估。这需要统一的知识表示格式和检索接口目前还没有特别成熟的方案但已经有一些框架在尝试。我的建议是先把两条链路分别跑通再考虑融合。融合的难点不在技术而在数据治理——知识库的更新频率、搜索结果的可靠性、两者的优先级规则这些都需要业务侧明确。5.4 安全与合规的边界Agent 联网搜索会接触到大量外部内容其中可能包含不准确、不适宜的信息。所以必须有内容过滤机制在结果进入模型之前做一轮筛查。筛查的维度包括来源可信度、内容合规性、是否包含敏感信息。这一步不能省否则一旦出问题影响很大。另外Agent 的搜索行为要有日志记录方便追溯。记录内容包括搜索词、返回结果、模型决策、最终输出。这些日志既能用于排查问题也能用于优化搜索策略。6. 我个人的实操体会做联网搜索这个方向有一段时间了最大的体会是搜索质量决定上限编排逻辑决定下限。很多人把精力花在 Agent 框架的选型上纠结用哪个编排工具但真正影响效果的是搜索词的质量和结果的清洗。我见过太多项目框架用得很花哨但搜索词就是用户原话结果自然好不了。另一个体会是不要追求一步到位。从最简单的搜索增强开始跑通流程收集 bad case逐步优化。每次只改一个变量观察效果变化。这样虽然慢但每一步都扎实。我见过一些团队一上来就搞多 Agent 加反思加验证结果调试成本极高最后不了了之。还有一点延迟和质量的平衡要尽早考虑。用户对延迟的容忍度是有限的超过几秒就会流失。所以搜索策略要设计降级路径宁可给一个稍差但快的答案也不要让用户等太久。我的做法是设一个总超时超时就用已有信息回答同时标注“信息可能不完整”。最后分享一个小技巧把搜索结果当成“参考材料”而不是“标准答案”。模型的任务是综合这些材料给出回答而不是照抄。所以在提示词里要强调“综合多源信息”“如果信息冲突要说明”这样能减少模型被单一来源误导的概率。这个方向还在快速演进新的工具和框架层出不穷。但底层逻辑是不变的理解用户意图、获取相关信息、综合给出答案。把这三步做好用什么工具都是次要的。

从RAG到Agent：联网搜索与工具调用式搜索的工程实践

相关推荐

多模态情感分析大作业实战：从Jupyter到可复现模型全流程

基于机器学习的Web日志异常检测工具：配置、实战与避坑指南

LangGraph.js+Next.js构建可解释AI求职智能体

更多资讯

十分钟从零开始开发一个自己的MCP server（二）：用TaoToken统一Key打通stdio与Claude Desktop

openclaw可以控制手机吗？Android 端接入 TaoToken 的可行路径与配置验证

Coding Agent的底层运行逻辑是什么？从一次401报错拆解到TaoToken统一Key

书霸：把问卷设计从空白变成方案

从下单到签收，一票货要闯 7 道关：物流管理论文别再写“现状-问题-对策“三段式了

2026年AI编程助手如何选：TaoToken统一Key接入与选型评测指南

今日更新

Agent Skills 完全指南：原理、写法、安装与实战避坑

Agent Skills 实战：从 Genkit 定义到 GKE 部署与排查

Agent Skills 实战：从设计到调试的完整指南

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？