简介：深度搜索Agent的核心能力体现在任务拆解与搜索充分性判断两个环节。本文围绕Planner-Only、Evaluator-Enhanced、递归式与并行工作流四类主流架构，从任务规划、反馈机制、扩展方式、适用场景等维度进行系统对比，帮助开发者和架构师理解不同方案的技术差异与选型依据，并附可复用的Prompt模板示例。
深度搜索Agent与传统单轮问答系统的本质区别在于：它需要在一个开放的信息环境中，通过多次工具调用、结果观察和策略调整，逐步逼近用户真正想要获得的答案。这个过程中存在两个难以回避的技术挑战。
第一个挑战是复杂问题的合理拆分。当用户提出“对比过去三年国内主要云服务商在AI训练基础设施上的投入变化，并分析对行业定价的影响”这类问题时，Agent不能只做一次搜索就给出结论。它需要先将问题拆解为多个可执行的子任务：历年投入数据采集、基础设施类型分类、定价趋势提取、因果关联分析等。拆得太粗，搜索结果会缺乏针对性；拆得太细，又会产生大量冗余调用和结果拼接困难。
第二个挑战是搜索充分性的判断。Agent在获取一批搜索结果后，需要判断这些信息是否已经足够支撑最终答案。如果判断过于宽松，可能基于片面信息给出错误结论；如果判断过于严格，则会陷入无限搜索循环，推高延迟和资源消耗。
近两年行业内在解决这两个问题时，逐渐沉淀出几种有代表性的架构思路。本文将这些思路归纳为四类：Planner-Only架构、Evaluator-Enhanced架构、递归式架构和并行工作流架构，并从技术机制、优缺点和适用场景三方面展开对比。
在展开分析前，需要先明确四个对比对象各自的基本含义与技术边界。
并行工作流架构是最早出现的改进方案之一。它的核心逻辑是：将用户问题预先拆分为固定数量的子查询，然后让多个搜索任务同时执行，最后汇总结果。这类架构通常基于ReAct范式扩展而来，以“并行执行”替代“串行逐步搜索”，目的是缩短整体搜索耗时。
Planner-Only架构在并行工作流基础上引入了动态规划能力。它增加了一个专门负责策略制定的规划模块，由该模块分析用户问题的复杂度，动态决定子任务数量、每个子任务的职责边界以及对应的工具调用策略。与并行工作流最大的区别是：子任务数量不再预先固定，而是由规划模块根据实际需求弹性生成。
Evaluator-Enhanced架构在Planner-Only基础上进一步加入了评估反馈环节。它由两个核心模块构成：规划模块负责生成搜索策略，评估模块负责在每轮搜索完成后对结果质量进行判定。如果评估模块认为信息不足或相关性不够，会触发补充搜索或策略调整，形成“规划—执行—评估—修正”的闭环。
递归式架构是近年来讨论较多的一种方案。它的核心特征是：搜索任务本身可以被递归地分解。当某个子任务在执行过程中暴露出新的复杂问题时，系统可以在该子任务内部继续启动更深层的规划与搜索过程，而不是将所有分解工作都集中在最初的规划阶段。
需要说明的是，这四类架构并非严格的互斥关系。实际系统中常常出现混合设计，例如在递归式架构的某一个递归层级中使用Evaluator-Enhanced的逻辑，或在Planner-Only的某个子任务内部采用并行工作流。但为了对比清晰，本文按照各架构的核心特征进行区分。
尽管四类架构在实现机制上差异明显，但它们共享几个关键的设计目标和技术基础。
第一，都以工具调用为基本执行单元。 所有架构都假设Agent可以通过调用搜索工具、数据查询接口或内容抓取工具来获取外部信息。工具调用的输入输出格式、错误处理机制和调用频率控制，是四类架构共同面对的基础工程问题。
第二，都遵循“规划—执行—汇总”的宏观流程。 即使在最简单的并行工作流中，也隐含了一个初步的规划动作：将问题拆成若干子查询。而递归式架构虽然将规划能力下沉到了多个层级，但就整体而言，仍然符合“先规划、再执行、最后汇总”的框架。
第三，都追求在搜索充分性和资源消耗之间取得平衡。 没有一种架构会无条件地持续搜索下去。所有方案都需要设置某种停止条件——无论是固定搜索轮次、结果数量阈值，还是评估模块的判定信号。这个共性说明：深度搜索Agent的设计核心不是“搜得越多越好”，而是“在合理成本下获得足够好的答案”。
第四，都依赖Prompt工程来约束规划行为。 对于基于大语言模型的Agent实现来说，规划模块的能力边界很大程度上由Prompt定义。如何描述可用工具、如何规定子任务输出格式、如何给出复杂度判断的参考标准，是四类架构都需要解决的Prompt设计问题。
并行工作流的任务拆解发生在代码层面，子查询数量由开发者预先设定。这种方式实现简单，但面对用户问题的复杂度波动时适应性较差。一个简单的日期查询和一个涉及多维度对比的研究型问题，如果使用相同的子任务数量配置，必然出现资源浪费或拆分不足。
Planner-Only架构将任务拆解从代码层提升到了模型推理层。规划模块根据问题的语义复杂度、涉及的时间范围、对比维度数量和可用工具类型，生成动态的子任务列表。这种方式显著提升了拆解的合理性，但也引入了新的不确定性：规划的稳定性依赖于模型对问题的理解能力和Prompt约束的清晰程度。
递归式架构则进一步打破了“一次性拆解”的假设。它允许在子任务执行过程中发现新的复杂度，并在子任务内部继续分解。这种设计在面对层级化问题（例如“分析某项政策的行业影响”需要先搜索政策内容，再搜索行业反应，再搜索历史类比案例）时具有明显优势，但实现复杂度也最高。
并行工作流和Planner-Only的共同短板是缺少对搜索结果的系统性评估。并行工作流在汇总阶段会合并结果，但不会对结果质量进行独立判定；Planner-Only虽然规划更精细，但一旦子任务执行完毕，也缺乏纠正偏差的机制。
Evaluator-Enhanced架构正是针对这一短板设计的。它在架构中显式加入了一个评估模块，对每轮搜索结果进行相关性、覆盖度和信息充分性判断。评估结果可以驱动规划模块调整策略，触发补充搜索或重新拆解。这种闭环机制显著提升了最终答案的可靠性，但代价是引入了额外的模型调用轮次和延迟。
递归式架构的反馈机制有所不同。它不设立独立的全局评估模块，而是将评估逻辑内嵌在递归过程中——当一个子任务执行到一定深度时，系统会判断是否需要继续递归分解。这种设计将评估从“全局判断”变为“局部判断”，每个递归层级只评估自己范围内的搜索充分性。
从实现难度来看，四类架构大致呈递增关系：并行工作流最简单，Planner-Only次之，Evaluator-Enhanced需要增加评估模块的Prompt设计和状态管理，递归式架构则需要处理递归终止条件、跨层级状态传递和结果合并等复杂机制。
从扩展性来看，递归式架构理论上具有最强的复杂问题处理能力，但也最容易出现失控递归和调用发散的问题。并行工作流虽然扩展性有限，但在简单查询和高吞吐场景下具有稳定可靠的优势。
并行工作流的延迟优势在于多个子查询同时执行，总耗时受最慢子查询制约。Planner-Only由于增加了规划步骤，在简单问题上反而可能增加一次额外的规划调用延迟。Evaluator-Enhanced的闭环机制会带来多轮评估调用开销，在简单场景下可能显得冗余。递归式架构的延迟取决于递归深度，在最坏情况下可能产生较长的调用链条。
| 对比维度 | 并行工作流 | Planner-Only | Evaluator-Enhanced | 递归式 |
|---|---|---|---|---|
| 子任务数量 | 预先固定 | 动态生成 | 动态生成+评估调整 | 层级递归生成 |
| 反馈机制 | 无独立评估 | 无独立评估 | 独立评估模块 | 递归层级内嵌评估 |
| 简单查询效率 | 高 | 中等（多一步规划） | 偏低（多轮评估） | 中等 |
| 复杂问题处理 | 弱 | 中等 | 较强 | 强 |
| 实现复杂度 | 低 | 中等 | 较高 | 高 |
| 调用超支风险 | 低 | 低 | 中等 | 较高 |
| 适用团队规模 | 小团队快速验证 | 中等团队生产使用 | 对答案质量有较高要求的团队 | 研究型或复杂分析场景 |
简单事实查询和实时性要求高的场景，如“查询某城市明天的天气”“获取某公司最新财报摘要”，适合采用并行工作流或轻量级Planner-Only方案。这类问题不需要深度推理，过度复杂的架构反而增加延迟和成本。
多维度对比类场景，如“对比两个技术方案在性能、成本和运维上的差异”，适合Planner-Only架构。规划模块可以针对每个对比维度生成专门的子任务，并行执行后汇总为结构化对比结果。
信息充分性敏感的场景，如法律条文解读、医疗信息查询、金融数据分析等，适合Evaluator-Enhanced架构。这类场景对答案的完整性和准确性要求极高，独立的评估模块可以有效降低信息遗漏风险。
层级化研究型场景，如行业分析报告生成、技术趋势研判、政策影响评估等，适合递归式架构。这类问题天然具有“总—分—子”的层级结构，递归分解能够更好地匹配问题的内在逻辑。
选型决策应综合考虑三个因素：问题复杂度分布、答案质量要求和工程资源投入。
如果团队面对的问题复杂度分布较窄，大部分查询都集中在相似类型上，并行工作流或Planner-Only通常足够。此时选择更复杂的架构并不能带来显著的答案质量提升，反而会增加维护成本和不稳定性。
如果答案质量是核心关注点，且团队能够接受一定的延迟增加，Evaluator-Enhanced架构是合理选择。独立评估模块的价值在高风险场景中尤为明显，它可以系统性地降低“基于不完整信息给出自信错误答案”的概率。
如果团队同时面对高度复杂的层级化问题，且具备较强的工程能力来管理递归过程，递归式架构值得考虑。但需要提前设计好递归深度上限、总调用次数预算和异常终止策略，避免失控。
一个务实的策略是：从Planner-Only起步，根据实际使用中暴露的评估不足问题，逐步引入评估反馈或递归机制。这种渐进式演进路径比一步到位采用最复杂架构更稳健。
如果从简单架构迁移到复杂架构，需要注意以下几点：
Prompt模板的重构。 不同架构对规划模块Prompt的要求差异显著。Evaluator-Enhanced需要为评估模块设计独立的Prompt，明确评估维度（相关性、覆盖度、信息充分性）、判定标准和输出格式。递归式架构还需要在Prompt中定义递归终止条件和子任务边界。
状态管理与上下文传递。 递归式架构需要处理跨层级的状态传递问题，包括已搜索内容摘要、剩余待探索方向和预算消耗情况。上下文窗口管理在递归深度较大时可能成为瓶颈。
调用预算控制。 所有架构都需要设置总调用次数上限和单次搜索的超时机制。Evaluator-Enhanced和递归式架构由于天然存在多轮循环的可能，更需要严格的预算控制策略。
监控与可观测性。 架构复杂度越高，越需要完善的日志记录和调用链路追踪能力。建议在每次规划、搜索和评估节点记录结构化日志，便于事后分析策略质量和定位异常。
深度搜索Agent的四种主流架构在核心设计目标上一致，但在实现路径上代表了不同的权衡取舍。并行工作流以牺牲拆解灵活性换取实现简单和低延迟；Planner-Only通过引入动态规划提升拆解合理性，但缺少对结果质量的独立判断；Evaluator-Enhanced补齐了反馈闭环，以额外调用开销换取答案可靠性；递归式架构则在处理层级化复杂问题上展现出独特优势，但工程实现和稳定性控制的要求也最高。
没有一种架构是普适最优解。正确的选型思路是：先明确场景中的核心约束——是延迟、答案质量还是工程维护成本——再选择与之匹配的架构复杂度。在实际落地中，渐进式演进的策略往往比一步到位更可持续。