核心内容摘要
别再为 PDF 转图片付费了！这个永久免费的“神仙网站”，建议每个打工人收藏-FastDo.tools
在AI技术飞速迭代的今天智能Agent已经成为连接用户需求与复杂信息处理的核心载体。
其中深度搜索Agent凭借其高效的信息检索、分析与整合能力在科研攻关、商业调研、日常问答等多个场景中发挥着不可替代的作用。
很多人在接触深度搜索Agent时往往会被“架构设计”“模块协作”“递归迭代”等专业术语劝退其实这些架构的核心逻辑都是为了解决一个核心问题如何让Agent更高效、更精准地处理不同复杂度的用户需求。
本文将从基础架构出发逐步深入到进阶设计系统拆解深度搜索Agent的四种主流架构基础迭代式搜索、Planner-Only、带评估反馈的双模块设计及递归式ROMA。
我们不纠结于晦涩的理论推导而是聚焦于每个架构的设计初衷、工作逻辑、适用场景和实操要点同时融入实用的prompt模板和落地建议让无论是入门新手还是有一定经验的开发者都能清晰理解并灵活运用这些架构解决实际问题。
需要说明的是这四种架构并非相互割裂、非此即彼的关系而是一种从简单到复杂、从基础到进阶的演进关系实际落地时可以根据需求灵活组合叠加平衡系统复杂度与实用性。
基础迭代式搜索Agent从ReAct范式开始的入门之路想要理解复杂的Agent架构我们首先要从最基础的迭代式搜索Agent入手。
这类Agent是所有深度搜索架构的基石其核心遵循ReActReasoning and Acting范式简单来说就是“思考-行动-观察-再思考”的循环过程。
可能有人会问为什么要设计这样的循环其实答案很简单人类在解决复杂问题时本身就是这样一步步推进的。
比如我们想知道“2025年国内新能源汽车行业的Top3企业及核心竞争力”不会一下子就能得出答案而是会先思考“需要先确认2025年的行业排名”然后去搜索相关数据再根据搜索结果思考“这些企业的核心技术是什么”再进一步搜索直到获取完整信息。
基础迭代式搜索Agent的工作流程可以概括为四步接收用户问题→基于现有知识进行推理明确需要补充的信息→调用搜索工具获取关键信息→观察搜索结果判断是否需要进一步搜索。
如果信息足够就整理成答案输出如果信息不足就重复“推理-搜索-观察”的循环。
这种架构的优势非常明显就是实现简单、调试方便不需要复杂的模块协作只需要定义好基本的循环逻辑和工具调用规则就能快速搭建起一个可用的搜索Agent。
比如在实际应用中我们可以用Python结合LangChain框架快速实现一个基础迭代式Agent。
核心逻辑就是通过循环控制让Agent每次都判断当前信息是否充分不充分就调用搜索工具。
这种架构特别适合处理简单的事实查询类问题比如“珠穆朗玛峰的最新海拔高度”“2024年诺贝尔物理学奖的获得者”等。
这类问题通常只需要
轮搜索就能获取足够信息用基础迭代式架构完全可以满足需求。
但随着需求复杂度的提升这种简单架构的短板也逐渐显现出来。
最突出的问题就是效率低下因为它是单线程的一步步搜索面对复杂问题时会浪费大量时间。
比如用户问“对比2025年国内外三款主流旗舰手机的性能、价格、续航及拍照能力并给出不同需求用户的购买建议”这个问题需要拆分多个维度的信息单线程迭代会依次搜索每个维度的信息耗时很长。
于是工程师们就想到了并行工作流的思路把一个大问题拆成多个子查询让多个搜索任务同时进行以此提升效率。
不过并行工作流也存在一个明显的缺陷子查询的数量是预先写死的。
实际场景中问题的复杂度是动态变化的简单问题可能拆
个子查询就够了复杂问题可能需要拆
个甚至更多。
如果预先固定子查询数量要么会让简单问题多跑不必要的搜索任务浪费资源要么会让复杂问题的子查询拆分不充分无法获取完整信息。
这个时候就需要一个“智能大脑”来动态判断问题复杂度并合理拆分任务Planner-Only架构应运而生。
Planner-Only架构用“智能规划”破解动态任务拆分难题Planner-Only架构的核心创新点就是引入了一个专门负责“规划”的模块——Planner。
这个模块就像一个项目管理器它不直接参与搜索和信息整理而是专注于分析用户问题的复杂度动态拆分出合适的子任务明确每个子任务的目标、输出格式和所需调用的工具然后让下游的执行Agent按照计划去执行搜索任务。
简单来说Planner的作用就是“运筹帷幄”确保整个搜索过程高效、有序。
为什么Planner能实现动态任务拆分关键在于它是基于大语言模型LLM实现的具备强大的推理和分析能力。
通过合理的prompt设计Planner可以识别出问题的复杂度比如判断一个问题是简单的事实查询、直接的对比类查询还是复杂的研究类查询然后根据不同的复杂度制定对应的任务拆分策略。
比如简单的事实查询只需要1个子任务搭配
次工具调用对比类查询可能需要
个子任务每个子任务搭配
次工具调用而复杂的研究类查询可能需要10个以上的子任务每个子任务都有明确的职责划分。
一个实用的Planner提示词模板通常包含四个核心部分工具说明、复杂度指导原则、子Agent角色定义格式和工具使用启发。
工具说明部分需要明确告诉Planner有哪些工具可用以及每个工具的输入参数是什么避免Planner调用不存在的工具或传入错误的参数。
复杂度指导原则部分则给出不同类型问题的任务拆分参考标准让Planner有明确的判断依据。
子Agent角色定义格式部分要求Planner为每个子任务明确目标、输出格式、工具使用指导和设计理由确保下游执行Agent能清晰理解并执行任务。
工具使用启发部分则相当于“工具RAG”引导Planner优先匹配工具与子任务目标优先使用专业工具而非通用工具提升搜索效率。
举个例子如果用户问题是“分析2025年中国人工智能行业的政策环境、市场规模、核心技术突破及未来三年发展趋势”Planner会先判断这是一个复杂的研究类查询需要拆分多个子任务。
比如拆分成“2025年中国AI行业政策梳理”“2025年中国AI市场规模及增长数据统计”“2025年AI领域核心技术突破大模型、自动驾驶等”“基于政策、市场、技术的未来三年趋势预测”四个子任务。
然后为每个子任务定义目标比如第一个子任务的目标是“梳理2025年国家及各省市发布的与AI相关的政策文件提炼核心支持方向和约束条件”输出格式是“政策名称-发布部门-发布时间-核心内容”工具使用指导是“优先调用政府官网搜索工具、政策数据库工具辅以通用搜索工具补充信息”设计理由是“政策信息具有权威性和时效性需要优先获取官方来源确保信息准确性”。
需要特别注意的是Planner作为整个架构的核心节点承担着复杂的任务分析和拆分工作其性能直接决定了整个Agent系统的效率和效果。
因此强烈建议选用推理能力强的大模型作为Planner比如GPT-4o、Claude
5 Sonnet或者专门的推理模型如o
DeepSeek-R1等。
如果选用推理能力较弱的模型可能会出现任务拆分不合理、工具调用指导不清晰等问题反而影响整个系统的运行效果。
Planner-Only架构很好地解决了任务动态拆分的问题让Agent能够根据问题复杂度灵活调整子任务数量和职责相比基础迭代式架构和固定并行工作流效率和适应性都有了显著提升。
这种架构特别适合入门开发者尝试实现难度适中调试方便能够满足大多数中等复杂度问题的处理需求比如商业调研、行业分析、多维度对比等场景。
但随着应用场景的进一步复杂另一个老问题又逐渐凸显出来Agent的搜索循环什么时候该停止
解决停止条件难题评估器的引入与优化设计无论是基础迭代式架构还是Planner-Only架构都面临一个共同的问题搜索循环的停止条件如何设定传统的做法是手动设置一个固定的迭代阈值比如最多允许搜索5轮超过5轮就强制停止并输出当前答案。
这种做法虽然简单但显然不够灵活存在很大的局限性。
比如一个简单的事实查询可能2轮搜索就已经获取了足够信息但因为阈值设置为5轮会继续进行3轮不必要的搜索浪费资源而一个复杂的研究类问题可能需要8轮搜索才能获取完整信息但因为阈值限制5轮后就强制停止导致输出的答案不完整存在知识缺口。
为了解决这个问题工程师们引入了“评估器”模块这也是带评估反馈双模块设计的核心。
评估器的作用很简单就是在每轮迭代或每个子任务执行完成后对当前生成的答案进行评估判断是否已经足够充分是否存在知识缺口。
如果答案足够充分就触发停止条件输出最终答案如果存在知识缺口就反馈给Planner或执行Agent指导其进行下一步的搜索。
这种设计让Agent的停止条件从“固定阈值”变成“智能判断”大大提升了系统的灵活性和答案的完整性。
一个标准的评估器提示词模板通常包含任务说明、用户问题、当前生成的答案和输出格式四个部分。
任务说明部分明确评估器的核心职责即分析当前信息是否充分识别知识缺口并给出推理过程。
用户问题和当前生成的答案部分需要准确传入让评估器有明确的评估对象。
输出格式部分则要求评估器以结构化的方式输出结果通常包含三个字段is_sufficient布尔值判断答案是否充分、reasoning评估推理过程说明为什么充分或不充分、knowledge_gap知识缺口若答案不充分明确需要补充的信息。
其中knowledge_gap字段是评估器设计的关键它不仅能判断答案是否充分还能为下一步搜索提供明确的指导方向。
比如用户问题是“推荐一款适合大学生使用的笔记本电脑预算5000元左右主要用于编程和轻度游戏”当前生成的答案只推荐了一款电脑说明了配置和价格但没有对比其他可选机型也没有说明是否满足编程和游戏需求。
评估器会判断is_sufficient为falsereasoning为“当前仅推荐了一款机型缺乏同类产品对比且未明确说明该机型是否适配编程和轻度游戏场景无法让用户做出全面判断”knowledge_gap为“
5000元左右适合大学生编程和轻度游戏的其他笔记本电脑机型
推荐机型及同类机型在编程如运行编程软件、多任务处理和轻度游戏如运行主流网游的流畅度方面的表现”。
这样一来执行Agent就可以根据knowledge_gap精准补充搜索而不是盲目搜索。
但在实际应用中又出现了新的问题有些特别刁钻或定义模糊的问题无论评估器如何判断Agent反复搜索都无法得到充分答案导致搜索循环无限进行。
比如用户问“最好的笔记本电脑是哪个”这里的“最好”没有明确的定义是性价比最高、性能最强、便携性最好还是续航最长不同的定义会导向完全不同的搜索方向Agent如果无法明确用户的核心需求再怎么搜索也无法给出让用户满意的答案。
针对这个问题OpenAI提出了“澄清问题机制”这是一种human-in-the-loop人机协作的设计思路。
其核心逻辑是当评估器发现Agent反复搜索后答案仍然无法达到充分标准且知识缺口始终无法填补时判断问题可能源于用户需求定义不清晰此时Agent会主动向用户提出澄清问题引导用户明确需求。
比如对于“最好的笔记本电脑是哪个”这个问题Agent会主动询问用户“为了给你精准推荐想确认一下你所说的‘最好’主要关注哪些方面比如性价比、性能、便携性、续航等另外你的预算大概是多少主要用于什么场景呢”通过这种方式把人拉进决策流程快速明确需求打破无限搜索循环。
除了OpenAI的澄清问题机制SamayaAI还提出了另一种针对长文本答案的评估思路——检查清单评分法。
传统的评估器面对长篇幅答案时很容易出现“上下文丢失”的问题单个LLM很难在一大段文本中保持完整的推理链容易遗漏关键信息导致评估结果不准确。
而检查清单评分法的核心思路是不要求评估器理解和评判整个答案的内容质量而是让评估器对照预设的检查清单判断答案是否满足预设的结构和内容规范。
比如用户问题是“对比A和B两款智能家居控制系统的优缺点、安装难度、兼容性及价格给出不同户型用户的选择建议”预设的检查清单可能包括
是否分别介绍了A和B两款系统的核心功能
是否明确列出了A和B的优点和缺点
是否详细说明两款系统的安装难度及所需条件
是否梳理了两款系统与主流智能设备的兼容性情况
是否给出了两款系统的价格及套餐信息
是否根据不同户型一居室、两居室、三居室给出了针对性的选择建议。
评估器只需要逐一对照清单检查判断当前答案是否满足每个条目不满足的条目就是知识缺口。
这种方式大大降低了评估器的工作难度提升了长文本答案评估的准确性和稳定性特别适合报告类、对比类、建议类等需要长篇幅输出的场景。
Planner Plan Evaluator双模块架构让计划更可靠执行更高效前面我们介绍的评估器主要是针对搜索结果和最终答案进行评估但在实际应用中Planner生成的计划本身也可能存在问题。
比如Planner可能会拆分出不合理的子任务或者调用不存在的工具或者子任务之间存在逻辑冲突这些问题如果在执行前没有被发现就会导致执行过程中出现错误浪费大量的时间和资源。
为了解决这个问题工程师们在Planner的基础上又引入了Plan Evaluator计划评估器模块形成了Planner Plan Evaluator双模块架构。
这种架构的核心工作流程是用户提出问题→Planner生成初步的任务执行计划→Plan Evaluator对计划进行审核评估→如果计划合格就交给执行Agent执行→执行完成后由结果评估器对答案进行评估判断是否需要进一步优化如果计划不合格就反馈给Planner让Planner根据评估意见修改计划直到计划合格后再执行。
简单来说就是在计划执行前增加了一道“审核关卡”确保计划的合理性和可行性从源头避免执行错误。
Plan Evaluator的设计思路主要有两种各有优劣实际应用中可以根据需求选择。
第一种思路是多计划竞争让Planner并行生成多个执行计划比如同时生成3个不同的任务拆分方案然后Plan Evaluator从这3个计划中挑选最优的一个。
这种思路的优势是能够显著提升计划的质量因为多个计划之间可以相互补充Plan Evaluator有更多的选择空间更容易选出最优方案。
但缺点也很明显就是成本和延迟都会上升生成多个计划需要消耗更多的token也会增加计划生成的时间导致整个流程的延迟变长。
这种思路适合对计划质量要求极高且对成本和延迟不敏感的场景比如高端科研项目、重要商业决策调研等。
第二种思路是单计划审核Planner先生成一个初步计划Plan Evaluator对其进行审核如果审核通过就直接执行如果审核不通过就给出具体的修改意见让Planner重新生成计划直到审核通过。
这种思路的优势是成本可控延迟较低不需要生成多个计划只需要对单个计划进行审核和修改适合大多数常规场景。
但缺点是计划质量可能不如多计划竞争需要Planner和Plan Evaluator之间进行多轮交互才能生成合格的计划。
那么Plan Evaluator主要审核计划的哪些方面呢根据实际应用经验计划出现问题主要集中在三个方面目标失败、工具失败和逻辑冲突。
目标失败是指Agent的计划没有围绕用户问题的核心目标或者完成目标时违反了约束条件。
比如用户让Agent规划一趟“从旧金山到印度的两周旅行预算5000美元”结果Planner生成的计划是去越南旅行这就是目标偏离或者计划确实是去印度但总预算超过了8000美元这就是违反了约束条件。
工具失败则分为三种情况一是调用不存在的工具比如Planner让执行Agent调用“bing_search”工具但系统工具库里根本没有这个工具二是工具选择正确但传入的参数个数错误比如“lbs_to_kg”工具磅转千克只需要传入一个重量参数Planner却让执行Agent传入了两个参数三是参数个数正确但参数值错误比如需要传入的重量是120磅结果传入了100磅。
这些工具失败都会导致执行过程中断无法获取有效的搜索结果。
逻辑冲突则是指子任务之间存在前后依赖关系但计划中没有明确执行顺序或者执行顺序错误。
比如某个子任务需要用到另一个子任务的搜索结果作为输入但计划中让两个子任务并行执行导致前一个子任务的结果还没出来后一个子任务就已经开始执行无法获取必要的输入信息。
Plan Evaluator需要针对这些
常见问题设计专门的检查逻辑在计划执行前就把这些明显的错误拦住确保计划能够顺利执行。
Planner Plan Evaluator双模块架构相比Planner-Only架构可靠性和稳定性有了显著提升能够有效避免因计划错误导致的执行失败特别适合处理复杂度较高、约束条件较多的问题比如旅行规划、项目方案设计、多约束条件下的产品推荐等场景。
但这种架构的复杂度也有所增加需要同时维护Planner和Plan Evaluator两个模块调试时也需要考虑两个模块之间的交互逻辑。
递归式搜索AgentROMA架构的深度突破应对层次化复杂问题前面我们介绍的基础迭代式、Planner-Only、双模块这三种架构本质上都是迭代式的设计思路核心都是通过多轮循环或多子任务并行的方式逐步获取信息并整合答案。
但从算法角度来看迭代能解决的问题递归也能解决而且递归天然适合处理可分解的层次化问题。
所谓层次化问题就是一个复杂问题可以拆分成多个子问题每个子问题又可以进一步拆分成更小的子问题直到子问题简单到可以直接解决。
比如“分析AI大模型在医疗诊断中的应用现状、技术瓶颈及未来趋势”这个问题不仅可以拆分成三个子问题每个子问题还能再拆分比如“技术瓶颈”可以拆分成“数据质量瓶颈”“模型泛化能力瓶颈”“算力成本瓶颈”等每个小瓶颈又可以进一步分析原因和解决思路。
Sentient Labs基于递归思想设计出了ROMARecursive Open Meta Agent架构这是一种全新的递归式搜索Agent架构专门用于处理层次化的复杂问题。
ROMA的核心思想是把复杂问题递归地分解成子问题每个子问题独立处理处理完成后将结果向上回溯整合成为父问题的答案最终形成整个复杂问题的完整答案。
与传统的并行拆分不同ROMA的子问题之间可以存在依赖关系某个子问题的答案可能是另一个子问题的输入这种设计更符合复杂研究任务的实际结构。
为了更清晰地理解ROMA的工作流程我们可以以“分析2025年中国新能源汽车行业的投资价值”这个问题为例。
首先ROMA会把这个核心问题拆分成三个一级子问题“行业政策环境分析”“市场供需现状及增长预测”“核心企业竞争力分析”。
其中“市场供需现状及增长预测”这个一级子问题又可以拆分成“市场需求规模及增长数据”“市场供给格局主要车企产能”“供需平衡分析”三个二级子问题“核心企业竞争力分析”可以拆分成“头部企业市场份额”“核心技术对比电池、自动驾驶等”“财务状况分析”三个二级子问题。
在处理这些子问题时ROMA会根据依赖关系确定执行顺序。
比如“供需平衡分析”这个二级子问题需要依赖“市场需求规模”和“市场供给格局”两个子问题的答案因此ROMA会先执行后两个子问题获取结果后再执行“供需平衡分析”。
每个子问题处理完成后都会将结果回溯给父问题父问题整合所有子问题的结果后再向上回溯最终整合所有一级子问题的结果形成核心问题的完整答案。
ROMA的完整架构还包含一层基于依赖图的信息抽取机制依赖图用来管理所有子问题之间的前后依赖关系确保有依赖的任务按正确顺序执行无依赖的任务可以并行执行兼顾效率和正确性。
依赖图的核心作用是可视化子问题之间的关系避免出现循环依赖或执行顺序错误的问题。
比如如果子问题A依赖子问题B的结果子问题B又依赖子问题A的结果就会形成循环依赖导致任务无法执行依赖图可以提前识别这种问题并反馈给Planner进行调整。
递归架构的优势非常明显理论上可以处理任意深度的复杂查询只要问题能被合理分解无论多么复杂的问题都能通过递归拆分的方式逐步解决。
而且这种架构的灵活性极高能够适应各种层次化的问题结构特别适合科研调研、深度行业分析、复杂决策支持等场景。
但工程实现上递归架构也面临更多的挑战比如递归深度的控制如果递归深度过深可能会导致栈溢出或系统崩溃子问题结果的合并难度较大需要设计合理的合并逻辑确保整合后的答案连贯、准确错误传播问题某个底层子问题的错误可能会向上传递影响整个问题的答案质量需要设计错误检测和修正机制。
因此ROMA架构虽然理论上性能强大但工程实现的门槛相对较高适合有一定Agent开发经验、具备复杂系统设计能力的团队或开发者尝试。
对于入门新手来说不建议一开始就上手实现ROMA架构而是应该先从Planner-Only或双模块架构入手积累一定的开发和调试经验后再逐步尝试递归式架构的开发。
落地实践建议从简单到复杂逐步构建高效搜索Agent通过前面的介绍我们已经详细了解了深度搜索Agent的四种主流架构每种架构都有其设计思路、优势、缺点和适用场景。
很多人在落地Agent项目时都会陷入一个误区追求最复杂、最先进的架构认为架构越复杂性能就越好。
但实际上Agent系统的核心目标是解决实际问题架构的选择应该以需求为导向而非盲目追求复杂度。
盲目采用复杂架构不仅会增加开发和调试的难度还可能导致系统冗余、效率低下反而无法满足实际需求。
结合实际落地经验我给大家的建议是从简单架构开始实现根据需求逐步叠加模块平衡系统复杂度与实用性。
具体来说可以分为三个阶段推进第一阶段入门验证阶段采用基础迭代式搜索Agent。
这个阶段的核心目标是验证需求的可行性快速搭建一个可用的原型系统不需要追求高性能和高稳定性。
比如如果你的需求是处理简单的事实查询、FAQ问答等场景基础迭代式架构完全可以满足需求。
这个阶段的重点是熟悉Agent的核心工作流程掌握工具调用、循环控制等基础技术积累初步的开发经验。
在实现过程中可以结合LangChain、LlamaIndex等开源框架快速搭建原型验证需求后再进行优化。
第二阶段优化提升阶段引入Planner模块升级为Planner-Only架构或进一步引入评估器升级为带评估反馈的双模块架构。
当需求复杂度提升简单的迭代式架构无法满足效率或准确性要求时就可以进入这个阶段。
比如需求从简单的事实查询升级为行业分析、多维度对比等场景就需要引入Planner进行动态任务拆分提升搜索效率如果需要提升答案的完整性和准确性就可以引入评估器模块实现智能停止和知识缺口补充。
这个阶段的重点是优化Planner和评估器的prompt设计选择合适的模型调试模块之间的交互逻辑确保系统的稳定性和高效性。
第三阶段深度突破阶段尝试递归式ROMA架构。
当需求涉及层次化的复杂问题比如深度科研调研、复杂决策支持等场景前面的架构无法满足需求时就可以进入这个阶段。
这个阶段的核心目标是处理高复杂度、多层次的问题提升Agent的深度推理和信息整合能力。
在实现过程中需要重点解决递归深度控制、子问题依赖管理、结果合并、错误传播等工程难题可以参考ROMA的设计思路结合依赖图、错误检测等技术逐步构建递归式架构。
除了架构选择在落地过程中还有两个关键要点需要注意一是模型的选择与优化不同的模块对模型的要求不同Planner和评估器需要选用推理能力强的模型执行Agent可以选用性价比更高的模型同时可以通过模型微调、prompt工程等方式提升模型的性能和效率二是调试技巧Agent系统的调试相对复杂建议采用“分模块调试端到端测试”的方式先分别调试每个模块的功能确保单个模块正常工作后再进行端到端的测试逐步排查问题提升调试效率。
最后需要强调的是深度搜索Agent的架构设计是一个持续优化的过程没有一成不变的最优架构。
在实际落地过程中需要根据用户反馈、需求变化、技术迭代等因素不断调整和优化架构平衡系统的复杂度、效率、准确性和成本最终构建出能够高效解决实际问题的Agent系统。
结语深度搜索Agent的架构演进本质上是一场“效率与准确性”的平衡之旅从基础的迭代式架构到复杂的递归式架构每一种架构的出现都是为了更好地应对不同复杂度的用户需求。
对于开发者来说掌握这些架构的核心逻辑不仅能够灵活应对各种应用场景还能为后续的Agent创新设计奠定坚实的基础。
希望本文的介绍能够帮助大家清晰理解深度搜索Agent的四种主流架构破除对复杂架构的恐惧找到适合自己需求的落地路径。
无论你是刚入门的新手还是有一定经验的开发者都建议从简单架构开始逐步积累经验不断优化提升最终构建出高效、稳定、实用的深度搜索Agent系统。
在AI技术飞速发展的今天Agent的应用场景还在不断拓展架构设计也会不断创新期待大家能够在实践中不断探索打造出更具竞争力的Agent产品。