万字长文深度解析最新Deep Research技术：前沿架构、核心技术与未来展望

本文将回答什么

问题1：Deep Research / Deep Search 的定义和能力边界是什么？

问题2：Deep Research 的核心技术架构是什么？经历了什么样的快速迭代？

问题3：主流方法的架构与设计有什么特点与共性？我们可以得到什么样的 Insight？

版本1：一种 LLM 为核心构建的应用系统，试图解决研究（广义）任务的自动化与能力增强问题

版本2：“AI agents powered by LLMs, integrating dynamic reasoning, adaptive planning, multi-iteration external data retrieval and tool use, and comprehensive analytical report generation for informational research tasks.”

A.deep research

• 作者：David Zhang Co-founder & CEO @ Aomni (aomni.com)

• github：https://github.com/dzhng/deep-researchstar 17k

1）基础配置

• 搜索引擎：Firecrawl API (for web search and content extraction)

• 模型：OpenAI API (for o3 mini model)

2）架构分类

• static workflow

3）工作流程

• query与参数输入：

• 要求输入 query、depth（循环次数）、breadth（单轮搜索 query数目）以及isReport（报告还是简单回答）。

• human-in-the-loop（report模式）：

• 调用模型生成问题询问用户用于澄清研究问题，设置问题数量上限；

• 组合初始 query、follow-up question 和用户回答为输入 query。

• Deep Research 递归

• 搜索 query 生成：输入前述 query、已有的研究 learnings要求模型生成 serp 搜索 query 和对应的研究目标，要求确保多样性和具体、并随着研究深入递进；

• 并发检索与解析：使用firecrawl搜索并抓取内容，输入模型要求总结 learnings 和follow up questions；

• 管理 depth 与 breadth 状态：depth = depth - 1；breadth = breadth / 2；

• 生成新的输入 query：组合历史的研究目标和生成的follow up questions；

• 判断depth条件：（1）大于0 则递归调用Deep Research；（2）等于 0 则递归返回所有 learnings 信息和 url 访问历史；（3）出现错误时丢弃该节点，前序节点的 learnings 信息由同层的其他节点返回。

• 后处理

• 去重合并：搜索树形成后，保留所有 learnings 和 url 访问历史并且去重。

• 结果生成

• 调用模型生成报告或者直接回复：输入 learnings、human-in-the-loop 环节得到的组合query、系统提示词、历史 urls（直接回复模式不用，主要用于报告生成引用）。

• 迭代搜索：根据自定义深度和宽度递归构建搜索树，不断基于历史learning迭代生成搜索 query、抓取新内容；

• query生成：使用智能体根据研究目标和先前learning生成有针对性的搜索query；

• 深度/广度控制：显式的暴露搜索树参数，用户决定如何 trade-off；

• 并发处理：并行处理多个搜索和结果处理（但这会受到 API 调用的影响，非付费用户可能不允许太高的并发量）。

• 使用 LLM 总结提炼 learnings：在不过度考虑预算和可能引入的幻觉（假设模型能力满足要求）的情况下，对于大量的搜索独立进行总结可能能减少最终生成报告的上下文压力，也可以在提升信息的覆盖度的同时交付比较干净的上下文给报告生成环节，带来生成环节的效果提升。

• 构建搜索树：扩展简单的线性或循环式的搜索pipeline的方法可以参考递归的构建搜索树，过程中采用同样的历史信息和研究目标自动生成搜索 query。好处在于树状的搜索历史比循环优化或线性的搜索历史感觉有更好的多样性，避免部分场景无法召回理想的来源；但劣势是大量增长的搜索内容可能导致上下文爆炸，就必须跟 LLM 总结提炼 learnings 相配合了。

• 暴露控制选项：暴露成本和时间控制的选项给用户进行trade-off，避免在token消耗、运行效率和结果质量之间平衡困难。

• 代码实现：作者提供了非常轻量简洁的实现，支持 api 和命令行调用。

B.DeerFlow

• 作者：字节 deerflow 团队

• github：https://github.com/bytedance/deer-flowstar 15.2k

1）基础配置

• 搜索引擎：Tavily (default)、DuckDuckGo、Brave Search、Arxiv

• 个人知识库：RAGFlow、vikingdb

• 模型：OpenAI-compatible API interface、open source models like Qwen、litellm可集成模型

2）架构分类

• Multi-Agent

3）工作流程

• coordinater判断：

• simple greeting or small talk：正确回复；

• security/moral risk：礼貌拒绝；

• 需要更多信息：正确询问；

• 其他情况：（1）调用handoff_to_planner，生成 research_topic 和 locale，不做任何进一步思考；（2）如果设置了enable_background_investigation，那么转向 hands off 给background_investigator。

• 接收用户问题进行回复和工具调用

• background_investigator搜索

• 搜索：使用coordinater传递的 research topic 作为 query 直接进行搜索；

• 转移：搜索完成后hands off 给 planner。

• planner确定研究计划

• 背景信息获取：如果存在background_investigation 则从 state 中添加到上下文后输入planner；

• 检查循环边界：检查 plan 次数是否大于最大次数，否则 hands off 给 reporter；

• 计划生成：基于上下文输出 json 形式的计划，如果生成正确 json 失败则根据是否有过上下文信息决定 hands off 给 reporter 或者 __end__节点；

• 计划检查：（1）如果上下文已经足够满足回答要求，hands off 给 reporter；（2）否则 hands off 给human feedback（正常执行流程中强制的，planner 并不直接通往 researcher）。

• human feedback修改计划

• 拒绝计划：传递用户反馈返回 planner 重新进行计划生成，如果正常生成则一定返回human feedback；

• 接收计划：检查state 中 plan 的 json 是否可以正常加载，失败则根据是否有过上下文信息决定 hands off 给 reporter 或者 __end__；正常加载则 hands off 给 research team。

• Research Team执行计划

• 如果研究计划的解析出现问题，返回 planner；

• 根据研究计划的 step 信息依次调用researcher 和 coder进行资料收集或者代码执行，两者均为 react 风格的agent；每次 reseacher 或者 coder 执行结束返回 research team，再按照计划决定下次调用两者的某一个：（1）researcher：网络搜索、本地数据库搜索；（2）coder：可以执行python 工具。

• 完成计划后 hands off 回到 planner的运行逻辑（上方）：（1）若 Planner 认为研究已完成，会 handoff 给 Reporter；（2）否则会继续规划（Re-plan）并 handoff 回 Research Team 进行下一轮研究迭代，直到最终完成。

• Reporter输出报告

• 获取plan、observation（researcher 和 coder）等上下文信息，生成报告（支持多模态）。

• human-in-the-loop：支持计划修改（类似gemini deep research）。

• Report Post-Editing：支持报告生成后继续修改。

• 内容生成：支持播客与 PPT 多种形式的结果输出。

• 工具实现参考

• 检索工具：只做了简单的搜索引擎封装，调用依赖于模型能力生成输入参数（prompt）；

• 内容解析与多模态：（1）依赖于 jina api 进行解析获取图文内容，reporter模型生成对图像的引用；（2）jina 可以获取图像 url、图像描述，模型解析这些内容而非直接理解图像。

• 全局状态管理：使用一个 state 记录每个节点所需和产出的核心上下文信息在所有 node 间传递；

• 整体评价：以模型能力为核心的多智能体实现，工具都是 tool 的形式传递给 react 形式的 agent 的，提供大量规范的 prompt 可参考。

C.sicra(mini-perplex)

备注

• 只有 extreme search 部分可能比较偏向于deep search，其他还是比较接近于对标 perplexity，不过extreme search 部分的生成篇幅目前也比较有限，和 perplexity 存在的问题相似。

• 作者：Zaid Mukaddam（独立开发者）

• github：https://github.com/zaidmukaddam/scirastar 9.9k

1）基础配置

• 搜索：exa、tavily、x、reddit

• 工具：Google Maps、OpenWeather 、Daytona、TMDB、Aviation Stack

• 模型：xAI、Google、Anthropic、OpenAI、GRoq

2）架构分类

• pipeline-based

3）工作流程（extreme mode）

• 搜索模式分组

• 前端显式指定搜索模式和使用模型；

• 进行用户信息校验、模型权限校验等等；

• 按照搜索模式分配可用工具组和instruction，比如对应deep search的extreme模式使用extreme search工具、对应的sys prompt。

• 模型流式调用

• 传入sys prompt、user query和工具（例如Extreme Search Tool，要求模型立刻调用搜索tool并且不修改用户信息）。

• Extreme Search Tool内部

• 搜索：exa + keyword

• 解析：exa的get_content接口

• 要求顺序运行query

• 要求为目标topic进行一定次数范围的search

• 要求丰富调研视角：broad overview → specific details → recent developments → expert opinions

• 要求指定不同分类：news, research papers, company info, financial reports, github

• 要求渐进式完善搜索

• 要求多样性和交叉验证

• 要求主题下需要研究的不同关键方面

• 要求为每个方面生成具体、多样的搜索查询

• plan：使用原始prompt+内置模型scira-x-fast进行breakdown。

• research：使用plan结果+内置模型scira-x-fast-mini+tools（code和search）进行search-driven research。

• search tool：接收 search query 和 category（可能空）进行搜索；对url进行内容解析。

• coding tool：接收code使用沙盒运行代码返回结果（可视化、数学计算、数据分析）。

• 多种搜索模式分配不同需求：Web（通用）、Memory、Analysis、Chat、X、Reddit、Academic、YouTube、Extreme。

• 为多种功能提供工具适配：Core Search & Information、Academic & Research、Entertainment & Media、Financial & Data Analysis、Location & Travel、Productivity & Utilities。

• 按照不同场景制定搜索模式（tool、prompt等等）：交由用户指定，进一步为场景匹配针对性的工具；不识图只用单一pipeline解决所有场景的需求。

• 框架依赖 prompt engineering 和简单的模型流式调用进行任务分层，不涉及react等框架：

• 对不同环节和组件按照不同的原则选择模型，用户指定模型（工具调度、分析、报告产出）、工具内模型（plan、research等环节独立调用LLM，同样只用prompt、tool和普通生成）；

• deep search功能工具化，使用成本更低、特定能力不错的小模型执行具体过程并提供上下文，使用用户指定的能力较强的模型进行分析和调用。

• 搜索优化的逻辑可能无法单纯依赖于找到足够强大的搜素引擎：

• 单纯的key word搜索也可以配合prompt实现不错的效果（diversity、category）；

• 更多依赖于Agent能力（提示词、relection），单纯的api更换、搜索引擎更换可能不能带来确定性收益；

• 场景明晰的问题可以依赖于专用引擎作补充：arxiv、x、reddit、semantic scholar等等。

D.open_deep_research

• 作者：langchain-ai

• github：https://github.com/langchain-ai/open_deep_researchstar 7.2k

• 博客：https://blog.langchain.com/open-deep-research、https://rlancemartin.github.io/2025/07/30/bitter_lesson

1）基础配置

• 搜索：Tavily(默认)、支持anthropic和openai的原生网络搜索、支持MCP

• 工具：支持大量的MCP工具兼容

• 模型：Summarization(openai:gpt-4.1-mini)、Research/Compression/Final Report Model(openai:gpt-4.1)

2）架构分类

• Multi-Agent

3）工作流程

• 研究范围->确认研究意图

• 用户意图澄清：要求模型询问用户获取额外的上下文来clarify（可以多轮、few-shot之类）。

• 研究概要生成：生成一段涵盖研究问题、调研要求、调研思路、报告要求之类的重点概要，作为研究全程需要参考的概要。

• 

• 执行研究->获取上下文

• 基于Supervisor分发的子主题、通过toool-caling循环（搜索工具or其他MCP工具）进行调研，不关注全局信息；

• 完成调研后，基于收集的信息（网页、tool call信息）和当前要解决的主题问题进行信息总结、引用形成findings，返回Supervisor。

• Research Supervisor：接收研究概要、并拆分为多个独立的子主题，每个子主题分配给一个sub-agent（上下文隔离）进行并行信息收集。

• Research Sub-Agents：

• Research Supervisor Iteration：基于Sub-Agents的findings和研究概要进行反思，确定是否需要进一步的信息收集，需要的话产生子主题并分发，直到任务完成。

  

• 撰写报告->形成产出

• 基于前述过程所积累的findings和最初的研究概要，直接生成最终报告。

  

• 完整的研究意图澄清：在类似于OpenAI式的询问问题后主动做了一个不是breakdown计划的总结和reflction。

• 更干净的上下文交付：三个环节之间、agent之间靠处理后的内容进行交互，具体来说，确认研究意图环节向执行研究环节交付的是模型生成的研究概要，supervisor收到研究概要、生成子主题分发给sub-agent，sub-agent以回复子主题为目的总结检索到的信息将learning总结交付给supervisor，研究概要、所有learnings一起交付给负责报告生成的agent。

• 保持deep research工作流的动态特性：对于不同难度和类型的问题，架构最好是可配置的或者可以自动扩展、动态调整的，比如模型自主调节并发的子topic数量、研究深度。

• tool-calling循环与workflow需要trade-off：需要实验验证两者的比例和设计方式，从当前工作给出的结论来看，在sub-agent这一层级放开了模型自主进行tool calling，全局仍然保持了supervisor做规划、反思是可以更好兼顾稳定与灵活的，是一种静态workflow和LLM自主tool calling循环的合理trade-off。即在一个小而聚焦的任务上由子任务智能体完全接管，在全局层面人为定义流程。

  

• multi-agent之间的信息不通、结果连贯性问题可以通过替换中间交付内容的办法来解决：作者的博客里面提到，如果让每个sub-agent独立完整一个章节再尝试合并，会很难协调连贯性；但是如果让sub-agent只交付搜索、整理得到的信息，让最后的report生成agent来写文章，连贯性问题就会得到解决。

• 上下文的合理设计可以降低对模型能力的过高要求、提高结果质量：这个工作中用的sub-agent向supervisor提供learnings其实在前文David Zhang的deep research中也有类似操作，加上最近调试智能体在workflow中表现的实验观察，一个初步的结论是觉得干净的、易处理的上下文设计可以提升能力不够强的模型的表现，例如生成报告时避免交付逻辑混乱、结构混乱的上下文可以减少报告出错。

E.Open Deep Search

• 作者：Sentient团队（开源AI 平台）

• github：https://github.com/sentient-agi/OpenDeepSearch?tab=readme-ov-filestar 3.5k

• arxiv：https://arxiv.org/abs/2503.20201

1）基础配置

• 搜索引擎：serper.dev、SearXNG

• reranking：Jina AI、infinity+Qwen2-7B-instruct（自己部署）

• 模型：OpenAI、Anthropic、Google（gemini）、OpenRouter、HuggingFace、FireWorks

2）架构分类

• Multi-Agent

3）工作流程

• Open Search Tool流程

• 使用 LLM 获取处理后的所有上下文生成响应。

• 使用 crawl4ai 解析各种格式的信息（未使用多模态信息）；

• 对于召回的前 m 个网页，每个chunk后进行 rerank（使用相似度、topk）；

• 所有处理后的内容按照顺序和内容标题用'\n'拼接；

• 在 LLM 的系统提示词中强调对内容相关性的考虑。

• 使用SERP（Google）进行搜索召回、来源合法性检验：（1）对于非 pro 模式，只处理 wiki 来源的第一个网页；（2）对于 pro 模式，才会处理召回的来源中所有可访问内容。

• 保留元数据用于后续生成：标题、url、描述、授权日期（如果有）。

• 在 LLM 的系统提示词中强调按照可靠性对来源进行排序使用。

• 基于原始的 query 生成 k个适合搜索的重构 query，要求模型保持语义上下文、适配 Google 等搜索引擎、缩小范围明确目的。

• 查询改写：

• 网络检索：

• 内容解析：

• 回答生成：

• Open Reasoning Agent

• Codeact 框架：完全基于smolagents，直接用的CodeAgent接口，使用 Chain-of-Code；

• few-shot prompt 设计：使用 smolagents 内置的structured_code_agent.yaml 中的 prompt；

• 支持一个 tool 和内置的 python 解释器：web_search（前面的 Open Search Tool）。

• React 框架：完全基于smolagents，直接用的ToolCallingAgent接口，无法正常生成回复时使用Chain-of-Thought Self-Consistency调用 r 次、聚类、随机采样最大的聚类；

• few-shot prompt 设计：从社区活动中总结获得（https://github.com/sentient-agi/OpenDeepSearch/blob/main/src/opendeepsearch/prompts.py）；

• 支持三个tool action：Continue thinking、Search internet（前面的 Open Search Tool）、calculate（Wolfram Alpha）。

• ODS-v1 with ReAct Agent

• ODS-v2 with CodeAct Agent

• 语义搜索：使用 Craw4AI 和语义搜索reranker（qwen2-7b-instruct 或者 jina）提供搜索结果。

• 模式选择：

• 默认模式：最小 latency 的快速高效搜索（过于浅度）；

• pro 模式：需要额外处理时间来获取更深入、更精确结果（其实本质上召回量也不大）。

• 可以以工具形态接入 Agents：可以无缝接入 SmolAgents（比如 CodeAgent）。

• 搜索部分是一套简洁的 pipeline，可以参考的思想：（1）prompt 中的来源排序要求和内容相关性筛选：https://github.com/sentient-agi/OpenDeepSearch/blob/main/src/opendeepsearch/prompts.py；（2）显式保留网站元数据辅助来源排序。

• 参考与react 集成的逻辑：在框架设计时，可以通过封装子任务智能体为支持tool call或者MCP的工具来提高复用和便于扩展。

F.OpenDeepResearcher

• 作者：Matt Shumer（AI应用开源贡献者、HyperWriteAI/OthersideAI CEO）

• github：https://github.com/mshumer/OpenDeepResearcher?tab=readme-ov-filestar 2.6k

1）基础配置

• 模型服务：OpenRouter API（anthropic/claude-3.5-haiku）

• 搜索服务：SERPAPI API

• 解析服务：Jina API

2）架构分类

• static workflow

3）工作流程

• query改写：

• 要求模型生成 4 个独立的、精确的搜索query来覆盖全面的信息。

• 异步搜索

• 对于每个独立的搜索 query 使用 SERP API 进行 Google 搜索，维护一个全局的 search query 列表；

• 聚合所有的搜索结果（按照默认数量应该总共 40 个召回来源）并进行来源去重。

• 内容获取与处理

• 获取：使用 Jina READER API 直接完成网页解析与内容获取；

• 过滤：单独调用一次 LLM 进行网页内容与初始 query 的关联度和有用度判断，直接要求模型回复 yes or no（注意此时是一次新的对话，没有做连续的上下文管理）；

• 提取：要求 LLM 对过滤后（经过上一步筛选）的 page content逐个进行相关内容/信息的提取，要求模型不做任何评论，输入侧给user query、search query 和 page content；

• 记忆：将提取到的有效检索内容（获取、过滤、提取后）合并到全局的记忆中（aggregated contexts）。

• 重新搜索

• 将记忆、user query、search query 输入模型要求其判定是否需要进行新的搜索，如果需要进行新的搜索的话，给出 4 个新的 search query 并且添加到search query 中；否则的话直接回复 done之类的内容。

• 循环迭代

• 回到“异步搜索”环节；

• 退出条件：1.最大迭代次数 或 2.llm未输出新的 search query。

• 报告生成

• 传入user query 和 aggregated contexts进行报告生成。

• 异步搜索与提取：链接去重、API 处理内容、相关性过滤、关联信息抽取；

• 迭代优化：维护一个全局记忆模块来迭代地完善和记录搜索召回的内容；

• 报告生成：生成报告依赖于全局记忆模块记录的相关搜索内容与 user query。

• 高度依赖 LLM 能力：搜索 query改写、内容提取、迭代优化等过程均依赖于 LLM 能力。

• 记忆组件简洁：不涉及对过去状态的追溯管理，只维护对搜索内容的记忆，无全局状态上下文。

• pipeline 设计简单：只做搜索、总结（没有显式的 planning 等环节）。