深度研究代理技术解析：架构、工具与优化方法

1. 深度研究代理技术概述

2025年2月，OpenAI正式发布Deep Research功能，标志着深度研究/深度搜索（Deep Research/Deep Search）作为一种新型信息检索和知识工作范式开始崭露头角。这种由多步推理驱动的系统能够进行大规模网络检索、跨源证据聚合和结构化写作，最终生成带有引用的研究级成果。到2月底，该功能已向Plus用户开放；4月又推出了"轻量版"，覆盖Plus/Team/Pro等级，进一步降低了使用门槛。

与此同时，Google在I/O 2025大会上将AI Mode从实验性功能升级为正式能力，并引入"Deep Search"：为复杂问题提供带有可追溯来源的综合报告，同时增加了自主搜索和引导餐厅预订等"代理式"操作能力。从7月开始，该功能已深度集成到Gemini 2.5系列中，并逐步向付费层级推出。

总体来看，以OpenAI和Google为代表的行业巨头已将能够自主检索、综合并执行后续任务的深度研究代理推向了主流，重塑了2025年的搜索标准。这一时期也涌现了大量初创企业、开发者贡献的开源项目和研究论文。

1.1 深度研究代理的核心定义

深度研究代理可以定义为两种版本：

版本1：围绕LLM为核心构建的应用系统，旨在解决广义研究任务的自动化和能力增强问题。

版本2："由LLM驱动的AI代理，集成了动态推理、自适应规划、多轮外部数据检索和工具使用，以及针对信息研究任务的综合分析报告生成能力。"

1.2 核心能力边界

深度研究代理具备三大核心能力：

智能知识发现：能够跨不同数据源自主进行文献综述、假设生成和研究模式识别；
端到端工作流自动化：通过AI驱动的流程完成端到端解决方案设计（实验性或调查性）、数据收集/分析和结果报告生成；
协作智能增强：提供用户友好的界面促进人机协作，包括基于自然语言的交互、可视化和动态知识表示。

与通用模型/代理的区别在于：自动化工作流、专门的研究工具以及端到端的研究规划和编排能力；
与单一功能研究工具的区别：如引文管理器、文献搜索引擎和数据分析工具都是孤立组件，而深度研究代理能将模型的推理能力与单个工具的能力相结合，通过编排和规划解决问题；
与简单LLM应用的区别：相比早期仅为语言模型提供研究导向提示的应用，它具备环境交互、工具集成和工作流自动化能力。

2. 核心架构与工作流设计

2.1 静态与动态工作流对比

随着模型能力的持续演进，代理架构和工作流的设计也在不断发展。基于对LLM自主规划和动态调整能力的依赖程度，主流架构大致可分为静态工作流和动态工作流两类。

静态工作流主要依赖人工定义的任务流水线。例如，将一项研究任务分解为需求处理、信息检索、内容解析和摘要输出四个阶段。每个阶段预定义要调用的工具组件和执行子流程（如条件判断、迭代优化等），随后由代理承担各阶段的部分或全部流程以获得最终所需输出。

静态工作流的优势在于结构清晰、易于实现。由于每个阶段覆盖的任务范围有限，开发者能更容易设计良好的容错机制，避免因模型能力不稳定导致整个工作流链崩溃。这种方法在任务交付稳定性要求高、难度不大且链条较长的场景中具有一定优势。其劣势在于泛化能力有限，固定的处理步骤使工作流难以有效迁移到不同任务场景。例如，面对金融和计算机科学等不同领域的工作时，可能需要分别定制不同的流水线。

动态工作流支持动态任务规划，允许代理根据任务执行过程中获得的反馈和变化的上下文调整未来任务执行步骤。模型自主完成任务规划、执行、反思和调整的闭环链，交付最终结果。动态工作流的优势在于有效解决了静态工作流在灵活性和泛化能力方面的问题，对复杂任务具备更强的处理能力。其劣势在于对LLM能力要求更高带来的不稳定性。由于整个任务由模型自主规划和执行，开发者将更难设计合理的容错机制来防止任务崩溃，错误排查的难度也会增加。

工程实践中，静态流水线和动态自主规划并非完全互斥。在代理框架中合理协调由代理自主完成的部分和预定义流程的部分，能有效平衡框架的稳定性和灵活性。

2.2 单代理与多代理架构

动态工作流可进一步细分为单代理架构和多代理架构。

单代理架构通过单个代理的规划、执行和反思循环完成任务，通常依赖模型自身强大的推理能力和较长的上下文窗口。在接收任务需求后，模型自主决定任务的所有步骤，并根据当前上下文优化任务规划、调用合适工具和接收反馈。

单代理架构的优势一方面在于对上下文历史的完整记忆，不存在信息不透明或协调困难；另一方面在于支持端到端强化学习，使推理、规划和工具调用等流程都能得到优化。其劣势在于这种范式对基础模型能力提出了更高要求，包括需要足够长的上下文窗口、良好的上下文理解/推理能力、稳定的工具调用能力等。此外，如果想有针对性地优化特定环节或模块，这种端到端黑盒架构会变得更加困难。典型作品如Agent-R1、ReSearch和Search-R1都基于类似ReAct框架的推理、执行和反思循环执行任务。

多代理架构通过多个专业化代理实现灵活的任务分配，将任务完成的各个方面以更细粒度分配给不同代理，模拟人类团队协作过程。例如，这种架构通常包含用于任务理解、分解和分配的规划者代理，随后由多个子任务代理（如代码、搜索、分析等）接管子任务的执行，最后由特定代理以指定格式交付结果。

多代理架构的优势在于出色的可扩展性和灵活性。处理复杂任务时，能根据任务分解选择不同的执行工作流，通过顺序或并发执行协调实现更丰富的任务编排。在资源充足条件下，多个子代理的并行处理也能提高任务完成效率。劣势包括一方面多代理间协调机制设计困难——例如由于多个代理无法同时共享所有上下文，设计合理的上下文/记忆管理机制对多代理协作过程至关重要；另一方面端到端训练优化存在困难。典型作品如OpenManus和deerflow都采用了分层规划者-子任务执行者架构。

3. 工具使用与优化方法

3.1 常用工具类型解析

无论是之前的工具调用还是最近兴起的mcp，开发者一直在尝试通过类似人类的工具调用过程使模型能处理复杂现实任务。以下介绍一些常用工具，包括搜索、代码解释器、多模态处理等。

3.1.1 网络搜索

对深度研究任务而言，搜索质量几乎直接决定了生成报告的质量和成本。如何以最低成本召回最相关、高质量的信息是需要关注的核心问题。模型集成搜索的主要方式是通过搜索API和浏览器模拟。

基于搜索API的方式通过向搜索引擎（Google、Bing、Tavily等）或科学数据库提供的检索API发送请求，直接获取结构化返回数据供后续处理。这通常包括与搜索请求关联的网站URL和摘要，并根据调用次数支付一定费用。获取搜索结果后，还需进一步过滤URL并请求特定URL的网页内容。一些常见解决方案总结如下：

主要缺点：受限于API提供的功能和返回数据的格式，无法灵活完成表单填写和网页操作，也无法获取需要动态加载的内容。

基于浏览器模拟的方式直接模拟人类在本地或沙箱环境中运行的浏览器中的操作，模拟点击、滚动、表单填写、JavaScript执行并实时提取网页内容。下图显示了在ChatGPT代理模式中使用沙箱浏览器进行检索的示意图。

主要缺点：资源消耗高、延迟高，解析动态多样的网页内容容易遇到瓶颈。

3.1.2 代码解释器（数据分析）

通常在沙箱环境中执行Python代码，为智能代理提供数据处理、算法验证和模型模拟能力。可执行任务包括：自动计算均值、方差、中位数等；创建图表、热图等；从文本或表格中提取指标并进行比较。

CoSearchAgent：集成SQL查询能力，对数据库执行聚合分析并生成报告。
AutoGLM：可直接从网页表格中提取结构化数据并进行分析。

3.1.3 多模态处理与生成

支持图像、音频和视频的处理，如完成语音转录、视频摘要、图像标注等任务以满足后续需求。也能基于TTS技术实现各种模态输出，文本到图像/视频生成，并能利用mermaid语法绘制各种常见流程图和表格。

目前仅有少数成熟商业或开源项目支持此功能，如Manus、OWL、OpenAI Deep Research、Gemini Deep Research、Grok DeepSearch等。但大多数仍无法支持端到端的多模态报告生成。Ms-Agent项目中的Agentic Insight和Doc Research是开源社区中少数具备端到端图文报告生成能力的作品。它们的实现主要基于以图表为核心节点的分层信息提取策略，能有效关联图表与上下文，以较低成本高效率地产出高质量的图文报告。

3.2 优化方法比较

3.2.1 提示工程

成本最低、迁移速度最快的方法，但受限于LLM自身的泛化能力，在复杂多变的任务设置中鲁棒性有限。适合快速原型设计但难以系统优化复杂工作流，需要反复调试。常用方法包括ReAct（推理与行动）、CoT（思维链）、ToT（思维树）等。

3.2.2 监督微调

通过构建高质量的专门微调数据，能专门优化代理在深度研究特定方面的表现，如优化搜索查询重写、工具调用和结构化报告生成能力。

Open-RAG：在数据构建中融入检索标记、相关性标记、基础标记和工具标记等不同监督信号，通过对抗训练提高过滤无关信息的能力。
AUTO-RAG：构建基于推理的指令数据集，使模型在生成过程中能自主规划检索查询并执行多轮交互。
DeepRAG：采用基于二叉树的搜索机制，递归生成子查询并构建多轮检索轨迹，在提高检索效率的同时平衡内外知识。使用基于拒绝采样的微调方法降低对SFT数据的依赖，如CoRAG、Start和ATLAS，通过从现有Q&A数据中提取检索链，在生成过程中监控工具调用信息，鼓励模型学习自主工具调用。

3.2.3 强化学习

通过与环境的真实交互和获得的奖励信号优化代理的信息检索、动态工具调用和复杂推理能力。

Agent-R1：代表端到端RL训练的综合框架，支持API、搜索引擎和数据库等多种工具调用，实现自动化多步任务执行和计划优化。
WebThinker：引入用于多跳网络搜索的网络资源检索器模块，使用Iterative Online DPO实现检索、导航和报告编写的无缝交错。
Pangu DeepDiver：采用两阶段SFT+RL课程训练，通过搜索强度调节机制在开放网络环境中自适应调整搜索深度。

在奖励模型选择上，大多数开源实现使用基于规则的奖励模型，明确定义任务特定目标如检索相关性、信息准确性和工具调用成功率；部分作品也使用PPO和GRPO等策略优化方法。

3.2.4 非参数持续学习

通过持续交互优化代理能力来改进外部记忆库、工作流和工具配置。

CBR（基于案例的推理）：代理从构建的案例库中检索、调整和重用现有的结构化问题解决轨迹。例如，DS-Agent在自动化数据科学中引入CBR，从构建的案例库执行近似在线检索；AgentRxiv模拟可更新的arXiv风格平台作为综合案例库，允许研究代理共享和重用先前的研究报告。由于不需要调整模型参数，CBR特别适合在数据稀缺或计算资源有限的场景中实现代理能力的持续改进。

4. 主流闭源与开源作品分析

4.1 闭源作品特性对比

4.2 开源作品实现解析

4.2.1 deep-research

作者：David Zhang @ Aomni (aomni.com)
GitHub：https://github.com/dzhng/deep-research
Star：17.6k

主要架构：

1. 基础配置
   搜索引擎：Firecrawl API（用于网络搜索和内容提取）
   模型：OpenAI API（用于o3 mini模型）

2. 架构分类
   静态工作流

3. 工作流
   查询和参数输入：需要输入查询、深度（迭代次数）、广度（每轮搜索查询数）和isReport（报告或简单回答）。
   人在回路（报告模式）：调用模型生成问题请用户澄清研究问题，设问题数量上限；将初始查询、后续问题和用户答案组合作为输入查询。
   深度研究递归：
   搜索查询生成：输入前述查询和现有研究学习成果，要求模型生成serp搜索查询和相应研究目标，确保多样性和特异性同时推进研究深度；
   并发检索和解析：使用firecrawl搜索和爬取内容，输入模型要求总结学习成果和后续问题；
   管理深度和广度状态：depth = depth - 1; breadth = breadth / 2;
   生成新输入查询：组合历史研究目标和生成的后续问题；
   判断深度条件：(1) 如果大于0，递归调用Deep Research；(2) 如果等于0，递归返回所有learnings信息和URL访问历史；(3) 出错时丢弃节点，同层级其他节点返回前驱节点的learnings信息。
   后处理：
   去重和合并：搜索树形成后，保留所有learnings和URL访问历史并去重。
   结果生成：
   调用模型生成报告或直接回复：输入learnings、人在回路阶段获得的组合查询、系统提示、历史URL（直接回复模式不使用，主要用于报告生成引用）。

核心特性：
迭代搜索：基于自定义深度和宽度递归构建搜索树，根据历史学习成果持续生成搜索查询并爬取新内容；
查询生成：使用代理根据研究目标和先前学习成果生成针对性搜索查询；
深度/广度控制：显式暴露搜索树参数，允许用户决定如何权衡；
并发处理：并行处理多个搜索和结果处理（但受API调用影响，非付费用户可能不允许太高并发）。

总结：
使用LLM总结和提取学习成果：在不过度考虑预算和可能幻觉（假设模型能力满足要求）情况下，独立总结大量搜索结果可能降低最终报告生成的上下文压力，并能提高信息覆盖率同时为报告生成阶段提供相对干净的上下文，从而提升生成效果。
构建搜索树：扩展简单线性或基于循环的搜索流水线的方法可参考递归构建搜索树，在过程中使用相同历史信息和研究目标自动生成搜索查询。优势在于树状搜索历史相比循环优化或线性搜索历史似乎具备更好多样性，避免无法召回理想来源的场景；但劣势在于大规模增长的搜索内容可能导致上下文爆炸，必须结合LLM总结和提取学习成果。
暴露控制选项：向用户暴露成本和时间控制选项以供权衡，避免难以平衡token消耗、操作效率和结果质量。
代码实现：作者提供了非常轻量简洁的实现，支持API和命令行调用。

4.2.2 DeerFlow

作者：ByteDance deerflow团队
GitHub：https://github.com/bytedance/deer-flow
Star：16.7k

主要架构：

1. 基础配置
   搜索引擎：Tavily（默认）、DuckDuckGo、Brave Search、Arxiv
   个人知识库：RAGFlow、vikingdb
   模型：OpenAI兼容API接口，可集成Qwen等开源模型、litellm可集成模型

2. 架构分类
   多代理

3. 工作流
   协调员判断：
   接收用户问题响应和工具调用
   简单问候或闲聊：正确响应；
   安全/道德风险：礼貌拒绝；
   需要更多信息：正确询问；
   其他情况：(1) 调用handoff_to_planner，生成research_topic和locale，不做任何进一步思考；(2) 如果设置了enable_background_investigation，则交给background_investigator。
   Background_investigator搜索：
   搜索：使用coordinator传递的研究主题作为查询直接执行搜索；
   移交：搜索完成后移交给planner。
   规划者确定研究计划：
   背景信息获取：如果存在background_investigation，在输入planner前从state添加到context；
   检查循环边界：检查计划计数是否大于最大计数，否则移交给reporter；
   计划生成：根据上下文以json格式输出计划，如果json生成失败，根据是否存在上下文信息决定移交给reporter或__end__节点；
   计划检查：(1) 如果上下文已足够满足回答需求，移交给reporter；(2)否则移交给human feedback（正常执行流中强制，planner不直接导致researcher）。
   人工反馈修改计划：
   拒绝计划：将用户反馈传回planner重新生成计划，如果正常生成则总是返回human feedback；
   接受计划：检查state中的计划json是否能正常加载，如果失败则根据是否存在上下文信息决定移交给reporter或__end__；如果正常加载则移交给research team。
   研究团队执行计划：
   如果研究计划解析遇到问题，返回planner；
   根据研究计划中的步骤信息，依次调用researcher和coder进行数据收集或代码执行，两者都是react-style代理；每次researcher或coder执行结束，返回research team，然后根据计划决定下一步调用哪个：(1) researcher：网络搜索，本地数据库搜索；(2) coder：可以执行python工具。
   完成计划后，移交回planner的操作逻辑（同上）：(1) 如果Planner认为研究完成，将移交给Reporter；(2) 否则继续规划（Re-plan）并移交给Research Team进行下一轮研究迭代直至最终完成。
   报告者输出报告：
   获取计划和观察结果（researcher和coder）等上下文信息生成报告（支持多模态）。

核心特性：
人在回路：支持计划修改（类似gemini deep research）。
报告后编辑：支持报告生成后继续修改。
内容生成：支持包括播客和PPT演示在内的多种形式输出。

总结：
工具实现参考：
检索工具：仅实现简单搜索引擎包装器，调用依赖模型能力生成输入参数（prompts）；
内容解析和多模态：(1) 依赖jina api解析获取文本和图像内容，由reporter模型生成对图像的引用；(2) jina能获取图像URL和图像描述，由模型解析此内容而非直接理解图像。
全局状态管理：使用state记录每个节点所需和产生的核心上下文信息，在所有节点间传递；
总体评价：以模型能力为核心的多代理实现，工具以工具形式传递给react-style代理，提供大量标准化prompts供参考。

4.2.3 sicra(mini-perplex)

注意：仅extreme search部分可能有些面向deep search，其他仍较接近对标perplexity。但extreme search部分的生成长度目前相当有限，存在与perplexity中类似的问题。

作者：Zaid Mukaddam（独立开发者）
GitHub：https://github.com/zaidmukaddam/scira
Star：10.5k

主要架构：

1. 基础配置
   搜索：exa、tavily、x、reddit
   工具：Google Maps、OpenWeather、Daytona、TMDB、Aviation Stack
   模型：xAI、Google、Anthropic、OpenAI、GRoq

2. 架构分类
   基于流水线

3. 工作流（extreme模式）
   搜索模式分组：
   前端显式指定搜索模式和使用的模型；
   执行用户信息验证、模型权限验证等；
   根据搜索模式分配可用工具组和指令，如extreme模式对应deep search使用extreme search工具和相应sys prompts。
   模型流式调用：
   传入sys prompt、用户查询和工具（如Extreme Search Tool，要求模型立即调用搜索工具而不修改用户信息）。
   Extreme Search Tool内部：
   plan：使用原始prompt + 内置模型scira-x-fast进行分解。
   要求研究主题下需要研究的不同关键方面
   要求为每个方面生成具体、多样的搜索查询
   research：使用plan结果 + 内置模型scira-x-fast-mini + 工具（代码和搜索）进行search-driven research。

• 要求顺序执行查询
• 要求对目标主题进行一定数量的搜索
• 要求丰富研究视角：广泛概述→具体细节→近期发展→专家意见
• 要求指定不同类别：新闻、研究论文、公司信息、财务报告、github
• 要求渐进式搜索细化
• 要求多样性和交叉验证
  search tool：接收搜索查询和类别（可能为空）执行搜索；解析URL内容。
  Search：exa + keyword
  Parsing：exa的get_content接口
  coding tool：接收代码并使用沙箱运行代码返回结果（可视化、数学计算、数据分析）。

核心特性：
为不同需求分配多种搜索模式：Web（通用）、Memory、Analysis、Chat、X、Reddit、Academic、Y