1. 项目概述当搜索代理学会“先谋后动”最近在折腾大模型应用特别是那些需要从外部知识库比如文档、网页、数据库里找答案的智能体Agent时我发现一个挺普遍的现象很多系统一上来就让模型直接去搜搜到什么算什么然后基于这些零散的信息去拼凑答案。结果呢要么答非所问要么逻辑混乱特别是面对那些需要多步推理的复杂问题时简直是一场灾难。这让我想起了那句老话“谋定而后动”。没错对于搜索代理Search Agent来说一个清晰的“计划”Plan恰恰是它能否精准、高效完成任务的关键。这个“Plan Before Search”的理念简单说就是让智能体在真正执行搜索动作之前先花点“心思”规划一下。别急着一头扎进信息的汪洋大海而是先分析问题拆解任务想清楚“我需要找什么信息”、“这些信息应该按什么顺序找”、“第一步找A找到A之后我才能基于A去问B”。这个过程在学术上常被称为“多跳问答”Multi-hop QA或“推理链”Chain-of-Thought在检索增强生成RAG场景下的前置应用。它解决的痛点非常明确提升复杂问题回答的准确性、逻辑性和效率避免盲目检索带来的信息噪音和逻辑断层。无论是构建一个企业内部的知识库问答机器人还是开发一个能进行深度研究的AI助手甚至是设计一个自动化处理客户复杂咨询的流程这个“先计划后搜索”的框架都至关重要。它适合所有正在或打算将大模型与检索系统结合起来的开发者、产品经理和技术决策者。接下来我就结合自己的实操经验拆解一下如何为搜索代理注入“计划”能力让它从“莽夫”变成“军师”。2. 核心思路拆解为什么“计划”如此重要2.1 盲目搜索的典型困境在没有计划的情况下一个搜索代理的工作流通常是“用户提问 - 模型生成搜索查询 - 执行检索 - 模型合成答案”。这个流程对于事实型单跳问题比如“珠穆朗玛峰有多高”可能还行但一旦问题变复杂弊端立现信息过载与噪音干扰对于“比较A产品和B产品在能耗和性价比上的差异”这种问题直接生成一个搜索词去搜返回的可能是成千上万条包含A或B的网页其中大量信息不相关。模型需要从海量噪音中筛选极易丢失关键点或产生幻觉。逻辑链断裂多跳问题如“特斯拉CEO马斯克创办的第一家公司的名称是什么”需要先知道“马斯克创办的第一家公司是Zip2”然后才能去搜索“Zip2”的详细信息。如果直接搜索“马斯克第一家公司的名称”可能得到的是“特斯拉”或“SpaceX”这类更知名的错误答案因为检索系统通常返回最流行的关联而非最精确的事实链。查询表述不精准模型可能生成一个模糊或包含歧义的搜索查询。例如对于问题“Python中如何处理‘public key retrieval is not allowed’这个MySQL连接错误”模型可能直接搜索整个错误信息而更有效的计划是先拆解这是一个MySQL Connector/Python的特定错误计划第一步应搜索“MySQL public key retrieval not allowed原因”第二步根据找到的原因如服务器参数allowPublicKeyRetrieval搜索“Python MySQL connector allowPublicKeyRetrieval 设置方法”。2.2 “计划”带来的范式转变引入“计划”环节意味着在“生成搜索查询”之前插入一个“任务规划与分解”模块。思维模式从“直接回答”转变为“先设计解题路径”。问题理解与分解首先模型需要深度理解用户意图并将一个复杂问题分解为一系列有序的子问题。每个子问题都应该是原子性的、可通过一次检索较好解决的。查询策略生成为每个子问题规划最有可能找到答案的搜索查询词。这可能包括考虑使用不同的关键词组合、限定搜索范围如特定网站、文档类型、甚至决定使用哪种检索工具向量数据库、全文搜索引擎、API调用。执行与信息整合按照计划顺序执行检索。关键点在于后续检索可以依赖于前序检索的结果。例如先检索“马斯克创办的第一家公司”得到“Zip2”后将“Zip2”作为已知事实融入下一个查询“Zip2公司详细资料”中形成上下文关联的检索。验证与迭代计划并非一成不变。在执行过程中如果某个子问题检索结果不理想如置信度低、信息矛盾计划模块应能触发重新规划或调整查询策略。这个转变的核心价值在于将不确定性前置。把复杂的推理负担从“检索后混乱的信息处理”阶段提前到“检索前清晰的任务规划”阶段。后者在纯文本推理层面进行成本更低可控性更强。注意这里的“计划”不同于简单的关键词扩展。它是一个基于对问题语义深度理解的、结构化的行动蓝图包含了步骤、依赖关系和预期产出。3. 架构设计与核心组件要实现一个具备规划能力的搜索代理我们需要设计一个模块化的系统。下图展示了一个典型的、包含计划模块的搜索代理架构注此处用文字描述架构图实际部署中可用绘图工具绘制用户输入 ↓ [问题理解与计划生成模块] ├── 意图识别 ├── 问题分解子问题生成 └── 查询策略规划为每个子问题生成搜索指令 ↓ [计划执行引擎] ├── 按顺序处理子计划 ├── 调用 [检索器]向量检索/关键词搜索/API ├── 管理上下文将前序结果注入后续查询 └── 结果评估与计划调整 ↓ [答案合成模块] ├── 汇总所有检索到的片段 ├── 基于完整上下文生成最终答案 └── 可能包含溯源引用 ↓ 最终答案输出3.1 计划生成模块的实现要点这是整个系统的“大脑”。我们可以用一个大语言模型LLM来驱动通过精心设计的提示词Prompt让它扮演“规划师”的角色。核心Prompt设计示例你是一个专业的任务规划师。请将用户的复杂问题分解为一系列必须按顺序执行的搜索子任务以确保能准确、完整地回答原问题。 **原问题** {用户输入的问题} **请按以下格式输出计划** 1. 第一个子问题[清晰、具体的子问题1]。搜索查询建议[针对该子问题最有效的1-3个搜索关键词或短语]。 2. 第二个子问题[子问题2可能依赖于问题1的答案]。搜索查询建议[关键词/短语]。 ... **规则** - 每个子问题应尽可能原子化目标是通过一次搜索就能找到核心答案。 - 明确子问题间的依赖关系。如果问题B需要问题A的答案才能提出请按顺序排列。 - 搜索查询建议要具体、无歧义优先使用可能出现在权威文档中的专业术语。举例用户输入“帮我制定一个为期一周的Python数据分析入门学习计划需要包含必要的库和实战项目。”计划生成模块输出可能为子问题Python数据分析最核心的库有哪些搜索查询建议“Python数据分析 核心库 NumPy Pandas Matplotlib”。子问题针对零基础学习者为期一周的Python数据分析学习路径或课程大纲是怎样的搜索查询建议“Python数据分析 一周 入门 学习路径 大纲”。子问题适合新手的、小型Python数据分析实战项目案例。搜索查询建议“Python数据分析 入门 实战项目 案例 Kaggle Titanic”。子问题依赖于1和3如何将NumPy和Pandas用于Titanic数据集的分析搜索查询建议“Titanic 数据集分析 Pandas NumPy 教程”。3.2 计划执行引擎的关键逻辑这个模块是“四肢”负责忠实地、灵活地执行计划。顺序与依赖处理引擎顺序执行子计划。对于有依赖关系的子问题它需要将前序步骤检索到的关键答案动态地插入到后续的搜索查询或检索上下文中。这通常通过一个“工作记忆”或“上下文管理器”来实现。检索器适配引擎需要能调用不同的检索工具。例如向量检索适用于语义搜索从知识库中查找相关段落。查询词由计划模块提供的“搜索查询建议”转化而来。关键词搜索调用传统搜索引擎如Elasticsearch或网站站内搜索适合查找具体事实、最新动态。工具/API调用对于“查询天气”、“计算汇率”等计划可能直接生成调用特定工具的指令。结果评估与重规划不是所有检索都能一次成功。引擎需要对检索结果进行快速评估例如通过LLM判断检索片段是否相关、是否足够回答子问题。如果评估失败可以触发“重规划”比如让计划模块基于当前失败情况生成替代查询或者跳过该子问题并记录信息缺口。3.3 上下文管理策略这是连接计划与执行的“粘合剂”。当执行“子问题2”时如何利用“子问题1”的答案查询增强最简单的方式是将前序答案中的关键实体直接拼接到后续查询中。例如前序得到“马斯克的第一家公司是Zip2”后续查询就从“马斯克的公司详情”变为“Zip2公司详情”。上下文窗口注入在进行后续检索时将前序的问题与答案作为上下文一并输入给检索模型或重排序模型让它们能更好地理解当前查询的语境。结构化状态跟踪维护一个全局的“事实列表”或“知识图谱片段”随着计划执行不断更新。所有后续步骤都可以查询这个状态表来获取已知信息。实操心得在初期实现“查询增强”就能带来显著效果。更复杂的上下文管理如基于向量的状态记忆虽然强大但也会引入额外的复杂度和延迟。建议从简单开始验证价值后再迭代。4. 实战构建一个多跳问答搜索代理让我们抛开理论动手搭建一个简易版但功能完整的“计划式”搜索代理原型。我们将使用Python、LangChain框架用于编排和一个开源的LLM如通过Ollama本地运行的模型来演示。4.1 环境准备与工具选型核心工具栈语言模型我们选择Qwen2.5-Coder7B版本通过Ollama在本地运行。它代码和推理能力均衡适合做规划。你也可以使用OpenAI的GPT-4o或Claude的API但本地模型更可控、无成本。框架LangChain。它提供了完善的Agent、Chain和Tool抽象能极大简化编排逻辑。检索工具我们模拟两个工具一个用于通用网页搜索用DuckDuckGo搜索API一个用于检索本地知识库用Chroma向量数据库。开发环境Python 3.9。安装依赖pip install langchain langchain-community langchain-chroma ollama duckduckgo-search初始化关键组件import os from langchain.agents import AgentExecutor, create_react_agent from langchain.tools import Tool from langchain_community.utilities import DuckDuckGoSearchAPIWrapper from langchain_chroma import Chroma from langchain_community.embeddings import OllamaEmbeddings from langchain_community.llms import Ollama from langchain.prompts import PromptTemplate # 1. 初始化本地LLM规划与生成核心 llm Ollama(modelqwen2.5-coder:7b) # 2. 初始化检索工具 # 工具A网页搜索 search DuckDuckGoSearchAPIWrapper() def duckduckgo_search(query): return search.run(query) web_search_tool Tool( nameWeb_Search, funcduckduckgo_search, descriptionUseful for searching current information from the internet. Input should be a clear search query string. ) # 工具B本地知识库搜索假设已构建好 embeddings OllamaEmbeddings(modelnomic-embed-text) vectorstore Chroma(persist_directory./my_knowledge_db, embedding_functionembeddings) retriever vectorstore.as_retriever() def knowledge_base_search(query): docs retriever.get_relevant_documents(query) return \n\n.join([doc.page_content for doc in docs]) kb_search_tool Tool( nameKnowledge_Base_Search, funcknowledge_base_search, descriptionUseful for searching internal documentation or specific knowledge base. Input should be a question or keyword. )4.2 实现计划生成器我们不直接使用LangChain的Agent而是先构建一个独立的“计划生成”链以更精细地控制规划过程。# 定义计划生成的Prompt模板 planning_prompt_template PromptTemplate( input_variables[question], template 你是一个高级信息检索规划师。面对用户的复杂问题你的任务不是直接回答而是制定一个分步检索计划。 用户问题{question} 请将解决这个问题所需的信息检索过程分解为一系列顺序执行的搜索步骤。每个步骤应该目标明确且通常通过一次搜索就能获得关键信息。 输出格式必须严格遵循以下JSON格式 {{ plan: [ {{ step: 1, sub_question: 第一个子问题是什么, search_query: 针对这个子问题建议的搜索词, preferred_tool: Web_Search 或 Knowledge_Base_Search // 建议使用的工具 }}, {{ step: 2, sub_question: 第二个子问题是什么可能依赖于第一步的结果, search_query: 搜索词可以包含如第一步的结果的占位符, preferred_tool: Web_Search 或 Knowledge_Base_Search }} // ... 更多步骤 ] }} 请确保 1. 子问题间逻辑连贯后一步可以依赖前一步的答案。 2. 搜索查询词具体、精准。 3. 根据问题性质合理选择建议的工具Web_Search用于通用/最新信息Knowledge_Base_Search用于内部/特定领域知识。 4. 计划步骤数量适中通常不超过5步。 现在开始为上述问题制定计划。 ) # 创建计划生成链 from langchain.chains import LLMChain planning_chain LLMChain(llmllm, promptplanning_prompt_template, verboseFalse) # 测试计划生成 test_question 特斯拉CEO埃隆·马斯克创办的第一家公司的名称是什么这家公司的主要业务是什么 plan_result planning_chain.run(questiontest_question) print(生成的计划) print(plan_result)预期输出示例{ plan: [ { step: 1, sub_question: 埃隆·马斯克创办的第一家公司是什么, search_query: Elon Musk first company founded, preferred_tool: Web_Search }, { step: 2, sub_question: 这家名为Zip2的公司主要业务是什么, search_query: Zip2 company business model what did it do, preferred_tool: Web_Search } ] }4.3 构建计划执行引擎现在我们需要一个引擎来解析这个计划并依次执行。import json import re class PlanExecutionEngine: def __init__(self, tools_dict): # tools_dict: 工具名到工具对象的映射例如 {Web_Search: web_search_tool, ...} self.tools tools_dict self.context {} # 用于存储每一步的执行结果 def execute_plan(self, plan_json_str, initial_question): 执行整个计划 try: plan_data json.loads(plan_json_str) except json.JSONDecodeError: # 如果LLM输出不是完美JSON尝试用正则提取 match re.search(r\{.*\}, plan_json_str, re.DOTALL) if match: plan_data json.loads(match.group()) else: return {error: Failed to parse plan from LLM output.} execution_results [] for step in plan_data.get(plan, []): step_num step.get(step) sub_q step.get(sub_question) raw_query step.get(search_query) tool_name step.get(preferred_tool) # 1. 查询预处理替换上下文中的占位符 # 假设上一步的结果存储在context中key为step_{n}_answer for key, value in self.context.items(): placeholder f{key} if placeholder in raw_query: raw_query raw_query.replace(placeholder, value) # 2. 选择并调用工具 tool self.tools.get(tool_name) if not tool: print(fWarning: Tool {tool_name} not found. Using default Web_Search.) tool self.tools.get(Web_Search) try: search_result tool.run(raw_query) except Exception as e: search_result fTool execution error: {e} # 3. 提炼答案简化处理取结果前一段 # 在实际应用中这里可以再加入一个LLM调用来从搜索结果中精确提取答案 answer_snippet search_result[:500] # 截取一段 # 4. 存储到上下文供后续步骤使用 context_key fstep_{step_num}_answer self.context[context_key] answer_snippet execution_results.append({ step: step_num, sub_question: sub_q, executed_query: raw_query, tool_used: tool_name, result_snippet: answer_snippet }) # 所有步骤执行完后汇总结果 final_context \n\n.join([fStep {r[step]} Q: {r[sub_question]}\nA Snippet: {r[result_snippet]} for r in execution_results]) return { original_question: initial_question, execution_steps: execution_results, final_context_for_answer: final_context } # 初始化引擎 tools_dict {Web_Search: web_search_tool, Knowledge_Base_Search: kb_search_tool} engine PlanExecutionEngine(tools_dict) # 执行测试 execution_report engine.execute_plan(plan_result, test_question) print(\n计划执行报告) print(json.dumps(execution_report, indent2, ensure_asciiFalse))4.4 答案合成与最终输出最后我们将计划执行后收集到的所有信息片段final_context_for_answer交给LLM让它合成一个连贯、完整的最终答案。# 定义答案合成的Prompt模板 answer_synthesis_prompt PromptTemplate( input_variables[question, context], template 你是一个专业的问答助手。请基于以下分步检索到的信息直接、准确地回答用户的问题。 用户问题{question} 分步检索到的信息如下 {context} 请根据以上信息生成最终答案。要求 1. 答案必须严格基于提供的信息。 2. 如果信息不足或存在矛盾请明确指出。 3. 答案应组织良好逻辑清晰。 4. 无需提及检索过程直接给出答案。 最终答案 ) synthesis_chain LLMChain(llmllm, promptanswer_synthesis_prompt, verboseFalse) final_answer synthesis_chain.run( questionexecution_report[original_question], contextexecution_report[final_context_for_answer] ) print(\n *50) print(【最终答案】) print(final_answer) print(*50)通过以上步骤我们就完成了一个具备“Plan Before Search”能力的搜索代理原型。它首先将复杂问题规划成有序的检索步骤然后依次执行并积累上下文最后综合所有信息生成答案。5. 高级技巧与优化策略基础框架搭建起来后要让它真正强大、可靠还需要一些进阶的优化策略。5.1 动态重规划与自我修正计划不可能永远完美。当某个步骤检索失败如返回结果不相关、为空或矛盾时系统应能自我修正。失败检测在计划执行引擎中加入对search_result的简单评估如检查长度、关键词匹配度或调用一个小型LLM进行相关性判断。重规划触发一旦检测到失败将当前状态原问题、已执行步骤及结果、当前失败步骤反馈给“计划生成模块”要求它重新规划剩余的步骤。Prompt可以设计为“之前的计划在执行到第X步时失败原因是检索结果不相关。请基于已获得的信息[列出信息]重新规划从第X步开始的后续步骤...”查询改写对于轻微的检索不精准可以不重做整个计划而是只对当前步骤的搜索查询进行多次改写尝试如使用同义词、变换句式。5.2 多工具协同与路由我们的例子中只有两个工具。在实际系统中可能有数十个工具数据库查询、计算器、天气API、专业领域搜索引擎等。工具描述精细化每个工具的description字段至关重要。计划生成LLM主要依据描述来决定使用哪个工具。描述应清晰说明工具的用途、输入格式和擅长领域。例如“Search_Internal_Wiki: 用于检索公司内部Confluence知识库中的技术文档和流程指南。输入应为具体的技术问题或文档名称。”路由网络可以训练一个轻量级分类器或使用LLM本身在计划生成阶段或执行前对子问题进行工具路由分类提高工具选择的准确性。5.3 计划评估与验证不是所有生成的计划都是好计划。可以在执行前或执行中对计划进行评分。可行性评估让LLM评估计划中每个步骤的搜索查询是否具体、可行工具选择是否合理。可以过滤掉查询过于模糊或工具明显不匹配的步骤。成本/效率预估估算执行整个计划需要的大致时间API调用次数、检索耗时和成本如果使用付费API。对于简单问题过于复杂的计划可以被简化。5.4 处理“Token Plan Quota Exhausted”类问题在集成商业LLM API如GPT-4时常会遇到配额或速率限制错误类似热词中的“token plan quota exhausted”。重试与退避机制在执行引擎中对API调用添加指数退避的重试逻辑。计划步骤的Token预算在规划时为每个步骤的查询和预期答案长度设定粗略的Token预算避免生成会导致长上下文溢出的复杂查询。备用模型降级当主模型配额用尽时自动切换到备用可能能力稍弱但可用的模型继续执行计划。本地模型兜底正如我们原型中使用的本地模型对于规划这类对实时性要求不高、但对可控性要求高的任务本地模型是绝佳的、无成本限制的兜底方案。6. 常见问题与实战排坑指南在实际开发和调优过程中我踩过不少坑。这里总结几个典型问题及其解决方案。6.1 计划生成质量不稳定问题LLM生成的计划有时步骤冗余有时又遗漏关键步骤格式也可能不统一。排查与解决Prompt工程这是最主要的手段。确保你的规划Prompt指令清晰、格式要求严格如必须输出JSON并提供1-2个高质量的示例Few-shot Learning。在Prompt中强调“原子化”、“依赖关系”、“具体查询词”。模型选择规划任务需要较强的逻辑分解和指令遵循能力。如果发现小模型如7B效果不佳可以尝试更大的模型如14B, 34B或专门在规划任务上微调过的小模型。后处理校验增加一个“计划校验”步骤。用另一个简单的LLM调用或规则脚本检查生成的计划是否符合基本逻辑如步骤数是否合理、查询词是否非空、工具是否存在对不合格的计划要求重生成。6.2 检索结果质量差导致后续步骤跑偏问题即使计划很好如果某一步检索到的信息是错误或无关的会污染整个上下文导致最终答案错误。排查与解决增强检索器对于知识库检索确保嵌入模型适合你的领域并对检索到的文档进行重排序Re-ranking。对于网页搜索考虑使用更精准的搜索API或对搜索结果进行清洗和摘要。结果验证与过滤在执行每一步后加入一个快速的“事实性校验”。可以用一个非常轻量的文本匹配或另一个小LLM来判断检索片段是否“可能包含子问题的答案”。如果置信度过低则触发重试或标记该步骤信息缺失。多路径检索对于关键步骤可以同时用多个查询词或不同工具进行检索然后综合或选择最佳结果提高鲁棒性。6.3 执行效率低下延迟高问题多步计划意味着多次LLM调用和多次检索串行执行导致总响应时间很长。排查与解决并行化可能步骤仔细分析计划中的依赖关系。如果某些步骤之间没有依赖可以尝试并行执行。例如在查询“A产品和B产品”的对比时获取A产品特性的步骤和获取B产品特性的步骤可以并行。缓存机制对相同的子问题查询结果进行缓存。很多通用问题如“Python列表推导式语法”的答案是固定的无需每次检索。异步执行使用异步编程模型如Python的asyncio来并发执行网络I/O密集的检索和API调用。简化计划对于实时性要求高的场景可以限制计划的最大步骤数如3步或者让LLM生成更“粗粒度”但步骤更少的计划。6.4 最终答案合成时忽略部分信息或产生幻觉问题LLM在合成最终答案时可能只关注了最后几步的信息或者自行编造了未检索到的内容。排查与解决强化指令在答案合成Prompt中反复强调“严格基于提供的信息”、“如果信息不足请说明”。结构化上下文提供不要简单地将所有检索结果拼接成长文本。可以按步骤结构化地提供“Step 1 问题: ... 答案片段: ...”。这有助于LLM更好地理解和引用来源。引用溯源要求模型在答案中注明关键信息来源于哪个步骤例如“根据第一步检索到的信息...”。这不仅能提高可信度也便于后期调试和验证。后验检查用一个简单的规则或另一个模型调用检查最终答案中的核心事实是否都能在提供的上下文中找到对应支持。如果存在无法支持的“裸断言”则触发告警或要求重新生成。构建一个真正智能、可靠的“计划式”搜索代理是一个持续迭代的过程。它不仅仅是技术组件的堆砌更是对问题理解、任务分解和信息整合逻辑的深度建模。从最简单的查询增强开始逐步引入动态规划、结果验证和优化策略你会发现你的智能体在面对复杂问题时越来越显得从容不迫有条不紊。这就是“先谋后动”的力量。