Deep Research Agent 架构拆解：从 RAG 到多源数据分析助手

Deep Research（深度研究）可以理解为一种面向复杂研究任务的 AI Agent（智能体）系统。它不只是把问题丢给搜索引擎，也不只是把检索结果塞进大语言模型，而是会围绕目标主动拆解任务、制定计划、连续检索、验证证据、修正方向，并生成带有结构和依据的研究报告。

普通问答系统擅长回答局部问题，例如“某个概念是什么意思”。Deep Research 更适合处理需要多步骤判断的问题，例如：

• “2025 年美联储降息会怎样影响美股？”
• “某个行业最近三年的竞争格局发生了什么变化？”
• “某项技术在学术界和工业界分别进展到什么阶段？”
• “某个业务指标异常，可能由哪些内部数据和外部事件共同导致？”

这些问题有一个共同点：答案不在单个网页里，也不一定存在于模型参数记忆中。系统必须像研究助理一样，先判断要查什么，再决定去哪里查，查到之后还要分辨哪些证据可信、哪些证据互相冲突，最终把结论组织成可读、可追溯的报告。

1. Deep Research 解决的核心问题

大语言模型（Large Language Model，LLM）的知识主要来自训练语料。只依赖模型参数会遇到三个问题：

检索增强生成（Retrieval-Augmented Generation，RAG）解决了一部分问题。RAG 会先从外部知识库或搜索引擎取回相关资料，再让 LLM 基于资料回答问题。

flowchart LR
    A[用户问题] --> B[查询改写或向量化]
    B --> C[(知识库 / 搜索引擎)]
    C --> D[相关文档片段]
    D --> E[LLM 生成答案]
    E --> F[返回结果]

RAG 的价值很明确：它把“模型记得什么”扩展成“系统能查到什么”。但传统 RAG 往往是一次性流程：查询一次，取回一批片段，然后生成答案。遇到复杂问题时，它缺少主动探索能力。

例如用户问：

在 2024 巴黎奥运男子 100 米决赛结束后，当晚赶去伦敦看音乐剧，最晚能坐哪趟 Eurostar？

这个问题至少包含几个子问题：

1. 男子 100 米决赛几点结束？
2. 从比赛场馆到巴黎北站需要多久？
3. 当晚巴黎到伦敦的 Eurostar 末班车是几点？
4. 入境、安检、提前到站时间是否允许？
5. 最终行程是否可行？

传统搜索可能只查到“100 米决赛时间”。RAG 可能把“Eurostar 末班车时间”也查出来，但如果没有任务拆解和推理，它仍然可能给不出真正可执行的判断。Deep Research 的关键差异就在这里：它会先把问题拆开，再逐项查证，最后综合成决策。

2. 从 RAG 到 Deep Search，再到 Deep Research

Deep Research 不是凭空出现的，它可以看作 RAG 和 Deep Search 继续演化后的结果。

2.1 RAG：外部知识补充

RAG 的基本模式是“检索一次 + 生成一次”。它适合回答事实型、资料型问题，例如：

• “某篇论文的主要贡献是什么？”
• “某个接口参数怎么配置？”
• “某个产品版本更新了哪些功能？”

它的短板也很明显：如果检索结果不相关，系统通常不会自己意识到“查错了”，也不会自动换关键词继续查。

2.2 Deep Search：让检索变成循环

Deep Search 增加了反思与迭代。系统不再满足于一次检索，而是会判断当前证据是否足够。如果不够，就继续生成新查询。

flowchart TD
    A[用户问题] --> B[初始检索]
    B --> C[阅读检索结果]
    C --> D{证据是否足够?}
    D -- 否 --> E[生成新的查询]
    E --> B
    D -- 是 --> F[生成答案]

Deep Search 的重点是“把信息找全、找准”。它会主动探索 Web 信息空间，直到满足终止条件，例如：

• 已找到足够证据；
• 达到最大检索轮次；
• 多个来源给出一致结论；
• 新检索无法带来增量信息。

2.3 Deep Research：搜索之外，还要规划和写报告

Deep Research 在 Deep Search 的基础上继续扩展，加入了更明确的任务规划和报告生成能力。它不只追求“查到答案”，而是追求“完成一项研究任务”。

flowchart LR
    A[用户研究问题] --> B[任务规划]
    B --> C[问题演化]
    C --> D[网页探索 / 数据检索]
    D --> E[证据阅读与验证]
    E --> F{是否需要补充信息?}
    F -- 是 --> C
    F -- 否 --> G[报告生成]
    G --> H[结构化研究报告]

这条链路对应四个核心模块：

3. Deep Research 的通用架构

一个可用的 Deep Research Agent 通常不是单个提示词，而是一套带状态的工作流。系统需要记录任务目标、当前计划、已检索证据、未解决问题、工具调用结果和生成报告草稿。

flowchart TD
    U[用户目标] --> P[Planning<br/>任务规划器]
    P --> Q[Question Developing<br/>问题演化器]
    Q --> W[Web Exploration<br/>网页与数据探索]
    W --> R[Evidence Store<br/>证据库]
    R --> V[Verifier<br/>证据验证与冲突处理]
    V --> P
    V --> G[Report Generation<br/>报告生成]
    G --> O[带引用的研究报告]

这个架构的核心不是“LLM 很会写”，而是“LLM 被放进了一个能检索、能执行、能反馈、能纠错的闭环里”。

4. Planning：把研究问题拆成可执行计划

Planning 是 Deep Research 的起点。用户输入的问题通常是高层目标，不能直接拿去搜索。规划模块要把目标拆成一组可执行步骤。

例如：

分析 2025 年美联储降息对美股的影响。

一个合理计划可能是：

1. 确认 2025 年美联储降息的时间点、幅度和政策表述；
2. 获取降息前后主要美股指数走势，例如 S&P 500、Nasdaq、Dow Jones；
3. 分析不同行业板块的反应，例如科技、金融、消费、公用事业；
4. 区分短期市场情绪和中期盈利预期；
5. 结合历史降息周期，判断当前环境是否类似；
6. 输出结论，并说明不确定性。

4.1 Planner、Executor 与 Environment

规划模块通常包含三个角色：

flowchart LR
    A[Task Planner<br/>任务规划器] --> B[Plan Executor<br/>计划执行器]
    B --> C[Environment<br/>环境 / 工具 / 数据源]
    C --> D[执行反馈]
    D --> A

复杂任务不可能一次规划到底。一个更稳的做法是“先粗后细”：先生成总体路线，再根据中间证据动态改计划。比如系统一开始以为问题主要是货币政策影响，检索后发现市场反应更多受 AI 龙头公司财报驱动，就应该把研究计划调整为“降息影响 + 财报因素 + 行业权重变化”的组合分析。

4.2 三种常见规划交互方式

如果用户只说“分析一下某行业”，系统最好不要直接开始检索，因为“分析”可能指市场规模、竞争格局、技术路线、投资机会，也可能指风险因素。先提出澄清问题，往往比盲目执行更可靠。

5. Question Developing：让 Agent 学会“问对问题”

规划模块给出的是研究路线，Question Developing 要把路线变成可执行查询。它决定系统能不能找到真正有价值的证据。

假设子目标是：

分析 2025 年降息前后科技股的表现。

这个子目标可以演化成多类查询：

问题演化不是简单的关键词扩展，而是带上下文的动态生成。系统需要根据已有证据继续追问：

flowchart TD
    A[子目标] --> B[生成初始查询]
    B --> C[获得证据]
    C --> D{是否覆盖关键维度?}
    D -- 缺少时间点 --> E[查询政策发布时间]
    D -- 缺少市场数据 --> F[查询价格与成交量]
    D -- 存在冲突 --> G[查询权威来源验证]
    D -- 覆盖充分 --> H[进入证据整合]

5.1 好查询的四个标准

在 Deep Research 里，“会提问”直接影响最终结果质量。一个普通查询可能只找到新闻标题，一个经过演化的查询能找到政策原文、市场数据、历史对照和专家解释。

6. Web Exploration：从互联网和工具里获取证据

Web Exploration 是信息获取引擎。它负责把查询变成实际证据，包括网页、论文、公告、新闻、PDF、表格、数据库记录等。

常见方式有两类：基于应用程序接口（Application Programming Interface，API）的检索，以及基于浏览器的交互式检索。

6.1 API 检索

API 检索通过搜索引擎 API、学术数据库 API、金融行情 API 等结构化接口获取数据。

flowchart LR
    A[查询请求] --> B[Search API / arXiv API / 数据 API]
    B --> C[结构化结果]
    C --> D[排序与去重]
    D --> E[证据抽取]

API 检索适合高吞吐、结构稳定的场景，比如查论文、查新闻列表、查行情、查企业公告。它的优点是速度快、格式稳定、成本可控；缺点是拿不到某些动态网页内容，也无法完成登录、点击、滚动、表单填写等复杂交互。

6.2 浏览器检索

浏览器检索会模拟人的网页操作，例如打开网页、点击链接、滚动页面、展开折叠内容、下载 PDF、读取动态渲染数据。

flowchart LR
    A[查询请求] --> B[启动浏览器实例]
    B --> C[搜索 / 打开网页]
    C --> D[点击 / 滚动 / 填表]
    D --> E[抽取正文和文件]
    E --> F[证据解析]

浏览器检索能覆盖 API 触达不到的内容，但代价也更高：

成熟的系统通常会先用 API 做大范围召回，再对高价值结果进行浏览器深挖。这样既能控制成本，也能获取更多细节。

6.3 证据质量过滤

Web Exploration 不能只管“找到”，还要判断“能不能用”。证据质量可以从几个维度评估：

一个可靠的 Deep Research 系统应该维护证据台账，而不是把网页内容直接拼进提示词。

{
  "claim": "2025 年某次降息幅度为 25 个基点",
  "source": "Federal Reserve official statement",
  "url": "https://example.com/fed-statement",
  "published_at": "2025-xx-xx",
  "evidence_text": "...",
  "confidence": 0.92,
  "used_in_sections": ["政策背景", "市场反应分析"]
}

这种结构能让报告生成阶段追踪每个结论来自哪里，也方便后续复核。

7. Report Generation：把零散证据合成研究报告

Report Generation 不是普通摘要。它要把多轮检索得到的证据组织成清晰报告，并保证结论与证据一致。

一个稳健的报告生成流程通常包含四步：

flowchart TD
    A[证据库] --> B[生成报告大纲]
    B --> C[按章节合成内容]
    C --> D[引用绑定与事实校验]
    D --> E[冲突处理]
    E --> F[最终报告]

7.1 结构控制

长报告最容易出现两个问题：结构混乱和主题漂移。结构控制的目标是让报告从大纲到章节都围绕研究问题展开。

例如市场分析报告可以采用这样的结构：

# 研究结论
# 背景与关键事件
# 数据表现
## 指数层面
## 行业层面
## 个股层面
# 影响机制
# 历史对照
# 风险与不确定性
# 参考来源

生成长文本时，系统不应该一次性要求 LLM 输出完整报告，而应该按章节合成，并在每章绑定对应证据。类似 LongWriter 这类方法的核心思想，就是把超长生成任务拆分成多个章节级子任务，再分别生成和整合。

7.2 事实完整性

事实完整性要求生成内容忠实于证据。系统需要避免三类错误：

一些 RAG 信任增强方法会在检索和生成之间插入验证层，让系统判断应该信任内部知识、外部证据，还是拒绝回答。这个思路对 Deep Research 很重要，因为研究任务经常会遇到证据不足或证据冲突。

7.3 引用不是装饰，而是可追溯接口

报告里的引用应该能支撑具体句子，而不是堆在末尾。理想状态下，每个关键结论都能映射到一个或多个证据对象。

flowchart LR
    A[关键结论] --> B[证据 1: 官方公告]
    A --> C[证据 2: 市场数据]
    A --> D[证据 3: 新闻报道]

当用户质疑某个结论时，系统可以回溯到原始网页、数据库查询结果或代码计算过程，而不是只能回答“根据检索结果可知”。

8. Deep Research 应该怎么评测

评测 Deep Research 比评测普通问答更难，因为它不仅要回答对，还要过程可靠、证据充分、成本可控。

可以把评测分成两类：面向 Search 的评测和面向 Research 的评测。

8.1 面向 Search 的评测

这类评测关注系统的信息寻找能力，重点是“能不能找到需要的信息”。

Search 评测能判断网页探索模块强不强，但它不一定能评估完整研究报告质量。

8.2 面向 Research 的评测

Research 评测覆盖规划、检索、证据整合和报告生成，目标更接近真实深度研究任务。

8.3 关键指标

一个 Deep Research 系统至少应该从这些维度评估：

只看最终答案容易掩盖问题。一个系统可能偶然答对，但过程里引用了错误来源，或者用了不可复现的数据。生产环境更需要过程级评测。

9. 主流 Deep Research 系统的共性与局限

OpenAI、Google、Perplexity、Qwen、Manus 等系统都在 Deep Research 方向上做了探索。它们的外在形态不同，但核心能力大体围绕几件事展开：

这些系统能显著降低资料搜集和初步分析的时间成本，但仍有一些常见局限。

9.1 数据源过度依赖公开互联网

很多 Deep Research 系统主要依赖公域网页。互联网信息覆盖广，但它不一定包含企业内部经营数据、用户行为数据、实时业务指标、私有知识库和结构化报表。

对于企业分析场景，这会产生明显问题：

• 能分析行业新闻，但无法结合内部销售数据；
• 能查政策变化，但无法计算业务影响；
• 能总结市场观点，但缺少定量验证；
• 能生成看似完整的报告，但结论无法落到企业自身数据上。

9.2 数据质量不稳定

公开网页存在噪声、过期、转述错误和观点偏差。Deep Research 如果没有证据验证机制，就可能把错误信息包装成研究结论。

尤其在金融、医疗、法律等场景里，错误证据会被 LLM 放大，形成更难发现的幻觉。

9.3 工具调用成本高

浏览器检索、PDF 解析、代码执行、多轮验证都会消耗时间和算力。一个研究任务如果无节制地打开几十个网页、反复检索相似问题，用户体验和成本都会失控。

9.4 长上下文不等于可靠推理

把大量网页全部塞进上下文，并不能保证模型正确理解。上下文越长，噪声越多，模型越可能忽略关键证据或混淆来源。证据筛选、结构化存储和引用绑定，比单纯扩大上下文更重要。

10. 多源数据融合：让 Deep Research 进入数据分析场景

要解决“只依赖公开互联网”的问题，Deep Research 需要接入更多可信数据源，尤其是结构化私域数据。

Dola 是一个面向数据分析场景的 AI 助手设计案例。它的目标不是替代搜索引擎，而是把企业内部数据、结构化数据库、报表、API 结果与外部公域信息结合起来，让 Agent 能完成更接近数据分析师的工作：取数、写 SQL、修 SQL、运行 Python、做可视化、生成分析报告。

10.1 数据源分层

多源 Deep Research 可以把数据源分成两层：

当两个来源冲突时，系统不能简单平均处理。业务指标通常应以内部数仓为准，外部网页只作为背景解释或交叉验证；宏观事件和政策信息则应优先参考官方公告和权威来源。

10.2 条件式调用 Web

不是所有问题都需要联网。一个数据分析 Agent 应该判断 Web 是否有增量价值。

这个判断能同时降低延迟和减少噪声。

10.3 典型执行链路

flowchart TD
    A[用户提出分析问题] --> B[任务规划]
    B --> C{是否需要外部实时信息?}
    C -- 是 --> D[Web 探索<br/>新闻 / 公告 / 政策]
    C -- 否 --> E[内部知识库检索]
    D --> F[证据库]
    E --> F
    B --> G[生成 SQL]
    G --> H[(数据仓库)]
    H --> I[结构化数据结果]
    I --> J[Python 分析与可视化]
    F --> K[结论融合]
    J --> K
    K --> L[分析报告]

这条链路把 Deep Research 从“网页研究”扩展成“数据研究”。系统不仅会查资料，还能计算指标、做统计分析和生成图表。

11. 案例：分析美联储降息对美股的影响

以“分析 2025 年美联储降息对美股的影响”为例，一个多源数据分析 Agent 可以这样执行。

11.1 规划任务

研究目标拆成四类子任务：

11.2 用 Web 获取事件信息

系统先检索降息日期和政策文本，形成结构化事件表：

这里的 bp 表示基点，1 个基点等于 0.01 个百分点。

11.3 用 SQL 获取行情数据

假设内部数据库已经有美股日行情表 us_stock_daily_price，可以按事件窗口取数。

SELECT
    trade_date,
    symbol,
    close_price,
    volume,
    sector
FROM us_stock_daily_price
WHERE trade_date BETWEEN DATE_SUB('2025-xx-xx', INTERVAL 30 DAY)
                    AND DATE_ADD('2025-xx-xx', INTERVAL 30 DAY)
  AND symbol IN ('SPY', 'QQQ', 'DIA', 'XLK', 'XLF', 'XLY');

也可以计算事件日前后的收益率：

WITH price_window AS (
    SELECT
        symbol,
        sector,
        trade_date,
        close_price,
        LAG(close_price, 5) OVER (
            PARTITION BY symbol ORDER BY trade_date
        ) AS close_5d_before
    FROM us_stock_daily_price
    WHERE trade_date BETWEEN DATE_SUB('2025-xx-xx', INTERVAL 30 DAY)
                        AND DATE_ADD('2025-xx-xx', INTERVAL 30 DAY)
)
SELECT
    symbol,
    sector,
    trade_date,
    close_price,
    ROUND((close_price / close_5d_before - 1) * 100, 2) AS return_5d_pct
FROM price_window
WHERE trade_date >= '2025-xx-xx';

11.4 用 Python 做事件窗口分析

SQL 负责取数，Python 适合做进一步统计和可视化。

import pandas as pd

# df 字段：trade_date, symbol, close_price, volume, sector
df["trade_date"] = pd.to_datetime(df["trade_date"])
event_date = pd.Timestamp("2025-xx-xx")

df["days_from_event"] = (df["trade_date"] - event_date).dt.days

# 取事件前后 10 个自然日窗口
window = df[(df["days_from_event"] >= -10) & (df["days_from_event"] <= 10)].copy()

# 以事件日前一个交易日价格为基准，计算累计收益
base = (
    window[window["days_from_event"] <= 0]
    .sort_values(["symbol", "trade_date"])
    .groupby("symbol")
    .tail(1)[["symbol", "close_price"]]
    .rename(columns={"close_price": "base_price"})
)

window = window.merge(base, on="symbol", how="left")
window["cum_return_pct"] = (window["close_price"] / window["base_price"] - 1) * 100

summary = (
    window.groupby(["symbol", "sector"])
    .agg(
        max_return=("cum_return_pct", "max"),
        min_return=("cum_return_pct", "min"),
        avg_volume=("volume", "mean")
    )
    .reset_index()
)

print(summary)

这一步能回答“涨没涨”“哪个板块反应更明显”“成交量是否放大”等定量问题。

11.5 融合定量和定性证据

报告生成阶段不应只给一句“降息利好美股”。更可靠的输出应该区分多个层次：

最终结论应该同时包含数据和证据来源，例如：

• 如果 Nasdaq 在事件窗口内上涨，但金融板块走弱，需要解释为成长股估值受益与银行净息差压力并存；
• 如果指数没有明显上涨，可能是降息已提前反映在价格中，或者市场更关注经济放缓信号；
• 如果成交量放大但收益不明显，说明分歧加剧，不能简单判定为单边利好。

这种分析比单纯总结网页观点更接近专业研究流程。

12. 工程落地中的关键坑

12.1 不要让 Agent 无限搜索

Deep Research 很容易陷入“再查一点”的循环。需要设置明确停止条件：

max_search_rounds: 8
max_pages_per_query: 5
stop_when:
  - key_questions_answered
  - evidence_confidence_above_threshold
  - no_new_information_in_last_two_rounds

12.2 证据库比长上下文更重要

把所有网页塞给 LLM 会增加噪声。更稳的方式是抽取证据，形成结构化记录，再按章节取用。

12.3 SQL 和代码执行必须可审计

数据分析型 Agent 生成的 SQL、Python 代码和中间结果都应保留。否则报告结论无法复现。

12.4 公域信息不能直接覆盖私域指标

企业内部经营数据、交易数据、用户行为数据通常比网页转述更可信。外部信息适合解释背景，不适合替代内部指标。

12.5 引用要绑定结论

引用放在报告末尾价值有限。更好的方式是让每个关键结论都能追踪到证据对象、查询语句或计算代码。

13. 关键判断

Deep Research 的本质是把 LLM 从“回答器”变成“研究流程调度器”。它的能力不只来自模型本身，还来自规划、检索、浏览、验证、工具调用和报告生成之间的闭环。

RAG 解决了外部知识接入问题，Deep Search 解决了多轮主动检索问题，Deep Research 进一步解决了复杂任务规划和结构化研究输出问题。进入企业和专业分析场景后，单靠公域网页仍然不够，结构化私域数据、SQL、Python、可视化和证据审计会成为关键基础设施。

一个真正可靠的 Deep Research 系统，需要同时做到三件事：

1. 会拆问题，知道研究路径怎么走；
2. 会找证据，能区分权威信息、噪声和冲突；
3. 会用数据，把公开信息和私域结构化数据结合起来，生成可复核的结论。