深度解析：4种主流Agent搜索架构详解与Prompt模板

深度搜索Agent需要解决的核心问题主要有两个：如何合理地将复杂问题拆解，以及如何判断搜索到的信息是否足够。近年来，Agent的发展非常迅速，各个团队的实现思路也愈发成熟。围绕这两个核心问题，业界逐渐沉淀出了几种主流的架构模式：从基础的Planner-Only，到融入评估反馈的双模块设计，再到像Sentient Labs提出的递归式方案。本文将系统梳理这几种架构，并附上可直接使用的实用Prompt模板。

迭代式搜索Agent

在探讨更复杂的架构之前，我们先回顾一下最基础的迭代式搜索Agent。这类Agent通常基于ReAct（推理与行动）范式，其工作流程非常直观：接收问题→进行思考→调用工具（如搜索）→观察结果→继续思考→再次搜索...如此循环，直至得到满意的答案。

然而，这种简单的单步迭代模式存在一个明显问题：当面对复杂的查询时，一步步顺序搜索的效率太低。因此，并行工作流的思路应运而生，即将一个大问题拆分为多个子查询，让多个搜索任务同时进行。

Planner-Only架构

但并行工作流本身也存在一个短板：子查询的数量通常是预先写死的。实际情况是，简单问题可能只需要拆分成2-3个子查询，而复杂问题则可能需要拆分成5-6个甚至更多。这意味着，子查询的拆分应该是动态的、由问题复杂度决定的，而非预先固定。

Planner LLM（规划器大语言模型）正是为解决这个问题而设计的。它的作用很明确：分析用户问题的复杂度，决定应该拆分成多少个子任务、每个子任务负责什么内容，以及应该调用哪些工具。

一个典型的Planner提示词结构如下：

# MAKE A STRATEGY/PLAN, YOU HAVE ACCESS TO FOLLOWING TOOLS  
↳ describe tools & their input parameters here

# GUIDELINES FOR QUERY COMPLEXITY, TOOL CALLS & #SUBAGENTS  
↳ simple fact finding queries requires just 1 subtask with 3-10 tool calls.  
↳ direct comparison queries might need 2-5 subtasks with 10-15 tools call each.  
↳ complex research might use more than 10 subtasks with clearly divided responsibilities

# CLEARLY DEFINE EACH SUBAGENT'S ROLE IN FOLLOWING FORMAT  
{  
  objective :-  
  output_format :-  
  tool_guidance :-  
  rationale :-  
}

# HEURISTICS FOR TOOL GUIDANCE (basically here we are doing Tool RAG)  
examine all available tools first, match tool usage to subagent objective,   
search the web only for broad external information or prefer specialized tools   
over generic ones.

这个提示词模板的设计思路值得注意：首先告知Planner有哪些工具可用，然后给出不同复杂度问题的拆分参考标准，最后要求它为每个子Agent明确定义目标、输出格式和工具使用指导。这样，Planner输出的计划才足够具体，下游的执行Agent才能准确无误地照此执行。

由于Planner承担着高复杂度的核心规划任务，强烈建议使用推理能力更强的模型来担任此角色，例如GPT-4o、Claude 3.5 Sonnet，或者专门的推理模型如o1、DeepSeek-R1等。

停止条件的处理

有了Planner，问题拆分的问题得到了解决，但另一个经典问题依然存在：基于ReAct的循环应该在何时停止？

传统的做法是手动设置一个固定的迭代次数阈值，依靠经验来调整参数，例如最多运行5轮。但这显然不够灵活，因为复杂查询需要更多轮迭代才能收敛，而简单查询可能几轮就足够了。固定的阈值要么会导致简单问题浪费计算资源，要么会让复杂问题提前结束，无法获得完整答案。

因此，更优的解决方案是引入一个评估器LLM（Evaluator LLM）。在每轮迭代之后，让评估器来判断当前收集到的答案是否已经足够好。如果足够好，就停止循环；如果不够，则继续下一轮搜索。

评估器的提示词可以这样设计：

# TASK  
Your task is to analyse and determine if following information is sufficient   
or there are knowledge gaps?? Provide reasoning for your answer

# Question  
add here the user question

# Generated Answer  
add here the answer generated by this iteration of ReAct

# OUTPUT FORMAT  
{  
  "is_sufficient": true/false  
  "reasoning":   
  "knowledge_gap":  
}

评估器需要完成两件事：判断当前答案是否充分，以及如果不够充分，具体缺少什么信息。其中的 knowledge_gap（知识缺口）字段非常关键，它可以指导下一轮迭代的搜索方向。

澄清问题机制

OpenAI在基础评估器之上又增加了一层巧妙的设计。他们观察到，对于一些特别刁钻或模糊的问题，LLM无论如何搜索都难以找到令人满意的答案，导致评估器一直返回 is_sufficient = false，陷入无限循环。

这种情况往往不是搜索能力的问题，而是问题本身定义不清。例如，用户询问“最好的笔记本电脑是哪个？”这里的“最好”标准是什么？是性价比最高、性能最强，还是便携性最好？不同的理解会导致完全不同的搜索方向。

因此，OpenAI的方案是：当评估器发现经过多轮反复搜索（例如3次迭代）后，仍无法获得充分答案时，就让Agent主动向用户提出几个澄清问题，将人类拉入循环以帮助明确需求。这就是所谓的“人在环中”（human-in-the-loop）设计。

检查清单评分

而SamayaAI则提出了另一种评估思路：检查清单评分（Checklist Scoring）。这种方案对于评估长篇幅答案特别有效。

传统的评估器在面对长篇答案时容易“迷失”，单个LLM很难在一大段文本中保持完整的推理链条，上下文过长时容易丢失信息，导致评估结果不可靠。SamayaAI的想法是，与其让评估器去理解和评判整个答案的内容质量，不如换个角度，评估答案是否符合预设的结构规范，这个结构规范就是检查清单。

例如，如果用户的问题是“对比A和B两个产品”，检查清单可能包括：是否分别介绍了A和B的特点？是否进行了价格对比？是否总结了优缺点？是否给出了推荐建议？评估器只需要逐项检查并打分，这比从头到尾阅读整个答案再进行综合评判要简单得多。

# TASK  
Your task is to analyse and determine if the answer follows following checklist  
or not. If not the identify knowledge gaps. Provide reasoning for your answer.

# Question  
add here the user question

# Generated Answer  
add here the answer generated by this iteration of ReAct

# Checklist  
add your checklist here

# OUTPUT FORMAT  
{  
  "is_sufficient": true/false  
  "reasoning":   
  "knowledge_gap":  
}

Planner + Plan Evaluator双模块架构

前面讨论的评估器主要用于评估搜索得到的答案，但实际上，Planner生成的执行计划本身也可能存在问题。于是，就衍生出了Planner + Plan Evaluator（计划评估器）的双模块设计：先由Planner生成一个计划，再由专门的评估器来审核这个计划是否可靠，只有审核通过的计划才会被交付执行。

Plan Evaluator通常有几种设计思路。

思路一：多计划竞争。让Planner并行生成多个（例如3个）不同的执行计划，然后由评估器从中挑选出最优的一个。这种方式可以提高最终计划的质量，但代价是成本和延迟都会增加——生成多个计划意味着数倍的Token消耗。

思路二：单计划审核。先由Planner生成一个计划，评估器判断其好坏。如果计划良好，则批准执行；如果不好，则打回让Planner重新生成。这种思路的成本更可控，但可能需要经过多轮“打回-重生成”的循环才能得到一个合格的计划。

计划出现问题通常表现为以下几种情况：

目标失败：Agent未能完成任务，或者虽然完成了任务但违反了约束条件。例如，要求模型规划一趟从旧金山到印度的两周旅行，预算5000美元，结果它规划到了越南；或者确实规划了印度行程，但总预算超过了规定。

工具失败：这又分为几种子情况。可能是生成了根本不存在的工具名称（例如调用 bing_search，但工具库里根本没有这个工具）；可能是工具选择正确但参数数量不对（例如 lbs_to_kg 工具只需要一个参数，它却传了两个）；也可能是参数数量正确但参数值填错了（应该传120却传成了100）。

Plan Evaluator需要针对这些常见问题设计检查逻辑，在计划执行前就拦住明显的错误，避免浪费后续的执行资源。

递归搜索Agent

前面介绍的所有架构本质上都属于迭代式。但从算法角度看，迭代能做的事情，递归同样可以做到，而且递归天然适合处理那些可以层层分解的层次化问题。

Sentient Labs就按照这个思路，提出了ROMA（递归开放元智能体）。

ROMA的核心思想是：将复杂问题递归地分解成子问题，每个子问题再被独立处理。与普通的并行拆分不同，ROMA允许子问题之间存在依赖关系——某个子问题的答案可能是另一个子问题求解所需的输入。这种设计更符合复杂研究任务的实际结构。

上图展示的是ROMA的简化版本，其完整架构还包括一层基于依赖图的信息抽取机制。依赖图用于管理子问题之间的前后依赖关系，确保有依赖的任务能够按照正确的顺序执行。

递归架构的优势在于，理论上它可以处理任意深度的复杂查询，只要问题能够被合理分解。但它在工程实现上也面临着更大的挑战，需要妥善处理递归深度控制、子问题结果合并、错误传播等问题。

总结

这几种架构模式并非相互排斥、非此即彼的关系。Planner-Only架构适合入门，实现简单、调试方便；加入评估器后，系统变得更加智能，但复杂度和成本也随之上升；检查清单评分这类方案对长文档输出场景效果显著，值得在特定需求下尝试；而ROMA的递归思路理论上能处理更深层次的复杂查询，不过其工程实现的门槛也相对更高。

在实际项目落地时，一个稳妥的策略是先从简单的架构跑通流程，再根据具体遇到的实际问题，逐步叠加所需的模块。毕竟，Agent系统的调试本身就不是一件容易的事，一开始就设计得过于复杂，很容易把自己绕进去。