Deep Research Agent 架构实战：从单轮搜索到迭代推理

「帮我研究一下 2026 年 agent 监控市场的竞争格局」——这条 prompt 丢给普通 chat 模型，得到的回答要么是「我无法访问实时数据」，要么是一段拼凑的维基百科片段。真正的 Deep Research Agent 会用 3-7 分钟、调用 30+ 个搜索、读 80+ 篇文章，输出一份带引用的 5000 字报告。本文拆解五个开源项目（GPT Researcher、Open Deep Research、Agents Deep Research、dzhng Deep Research、u14app Deep Research），给你看每家是怎么把「研究」这件事拆成可调度流水线的。

为什么普通 RAG 不足以做"研究"

RAG 解决的是「给定文档回答问题」。Deep Research 解决的是「我不知道答案在哪，先去找，再交叉验证，再组织成报告」。三件事 RAG 都做不到：

1. 动态扩展搜索空间。RAG 的语料是固定的；研究需要根据第一轮发现去决定第二轮查什么。
2. 跨源事实验证。研究需要多源对比，发现冲突时回去追问。
3. 结构化长报告。最终输出是带引用、带章节、带表格的长文，不是 200 字的答案。

把研究拆解开来，Deep Research 流水线有三个核心子阶段：

子阶段	目标	关键能力
迭代检索	不断发现新信息	query 改造、并行搜索、源质量排序
事实验证	排除幻觉与冲突	多源交叉、置信度评分、引文追踪
报告生成	把发现组织成文	大纲规划、章节写作、引文嵌入

下面逐阶段拆解。

子阶段一：迭代检索 —— Query 改造是核心

Deep Research 的搜索质量 80% 取决于 query 改造。最常见错误是「直接拿用户原句搜」——「2026 年 agent 监控市场」在搜索引擎上 90% 是 2023-2024 的旧内容。GPT Researcher 的做法是先生成多个子查询，再分别搜索：

from gpt_researcher import GPTResearcher

researcher = GPTResearcher(
    query="2026 年 AI agent 监控市场的竞争格局",
    report_type="research_report",
)
# 内部自动拆分成 5-8 个子 query
context = await researcher.conduct_research()
report = await researcher.write_report()

Open Deep Research 的 query 改造走得更深，先用一次 LLM 调用生成「研究大纲」，再按章节生成搜索 query：

from open_deep_research import DeepResearchAgent

agent = DeepResearchAgent(
    model="anthropic:claude-sonnet-4-20250514",
    search_provider="firecrawl",   # 或 tavily, exa
    max_iterations=5,              # 最多迭代 5 轮
)

# 用户原句 -> 研究大纲 -> 5-8 个子 query -> 3 轮反思 -> 最终报告
report = agent.research("2026 年 AI agent 监控市场的竞争格局")

Query 改造的三种策略：

1. 关键词展开：把抽象概念（"agent 监控"）展开成具体厂商名（"Langfuse Phoenix Helicone Arize"）。
2. 时间限定：强制加上 "2025 2026" 时间窗口，过滤旧内容。
3. 对比维度：明确要比较的轴（"市场份额 客户类型 定价 部署方式"）。

实用的 query 改造 prompt 模板：

你是一个研究助手。给定用户的原始问题，请生成 3-5 个子查询以覆盖不同角度。

原始问题：{user_query}

要求：
1. 每个子查询应聚焦一个具体子主题
2. 包含 2025-2026 时间限定
3. 优先使用具体名词而非抽象概念
4. 至少一个子查询关注反方观点

返回 JSON: {"sub_queries": [...], "search_angles": [...]}

子阶段二：事实验证 —— 多源交叉是底线

拿到 80 个搜索结果后，直接喂给 LLM 让它写报告 = 100% 产生幻觉。必须做多源交叉。Agents Deep Research 用「多 Agent 分工」做这件事：每个 Agent 负责一个事实维度的验证：

from agents_deep_research import CoordinatorAgent, FactCheckerAgent, SourceRankerAgent

coordinator = CoordinatorAgent(
    sub_agents=[
        FactCheckerAgent(role="verify_company_facts"),     # 验证公司基本信息
        SourceRankerAgent(role="rank_source_credibility"), # 给源打分
        SynthesizerAgent(role="merge_findings"),           # 合并到统一 schema
    ],
)
findings = coordinator.run(query="2026 年 agent 监控市场")

事实验证的三个核心动作：

1. 冲突检测。同一事实出现 2+ 个不同表述时，标红并暂停，要求 Agent 进一步搜索。
2. 来源分级。给搜索源打 0-1 分（官方文档 0.9、维基 0.7、博客 0.4），报告生成时按权重引用。
3. 引文锚定。每个事实必须挂载具体 URL，写作时禁止无引用声明。

dzhng Deep Research 的实现是「带置信度的检索」：

from dzhng_deep_research import ResearchEngine

engine = ResearchEngine(min_source_credibility=0.5)
result = engine.research(
    query="对比 Langfuse 与 Phoenix 的部署模式",
    require_min_sources=3,        # 至少 3 个独立源
    verify_against_official_docs=True,  # 优先用官方文档验证
)
# result.findings 包含 verified / unverified / conflicting 三类

子阶段三：报告生成 —— 大纲先行，章节后写

拿到 verified findings 后，不要一次性让 LLM 写完 5000 字。先规划大纲，再分章节写，最后合并。

u14app Deep Research 的写作流程：

from u14app_deep_research import ReportWriter

writer = ReportWriter(
    style_guide="academic",  # 或 "business" "technical"
    target_length=5000,      # 目标字数
    citation_style="footnote",  # 脚注式引用
)

# 第 1 步：基于 findings 生成大纲
outline = writer.generate_outline(findings)
# 返回: [{title, sub_sections, supporting_findings}, ...]

# 第 2 步：分章节写
chapters = []
for section in outline:
    chapter = writer.write_section(section, findings)
    chapters.append(chapter)

# 第 3 步：合并 + 检查引文完整性
final_report = writer.merge_and_verify_citations(chapters)

写作阶段最容易出问题的不是「写得不好」而是「引文掉链」——LLM 写到一半忘了在哪句该加引用。实用的解法是分章节检查 + 强制模板：

5 个项目的横评

维度	GPT Researcher	Open Deep Research	Agents Deep Research	dzhng Deep Research	u14app Deep Research
搜索后端	Tavily	Firecrawl/Tavily/Exa	自带	通用	多 provider
反思迭代	1 轮	最多 5 轮	多 Agent 协作	3 轮	3 轮
多源验证	弱	中	强	强	中
报告结构	固定模板	自适应	可配置	固定模板	大纲驱动
部署难度	低	中	中	中	高
最强项	开箱即用	query 改造	多 Agent	事实验证	长报告质量
最弱项	报告同质化	Firecrawl 依赖	协调开销	性能	配置复杂

决策框架：四步选

1. 你需要多少控制权？
   • 高（自定义搜索、报告样式）→ 选 dzhng 或 u14app
   • 低（开箱即用即可）→ 选 GPT Researcher
2. 你的搜索源是私有的吗？
   • 是 → 选支持自定义后端的 Open Deep Research / u14app
   • 否 → 任意
3. 报告需要学术风格还是商业风格？
   • 学术 → u14app
   • 商业 → Open Deep Research
4. 团队对多 Agent 模式熟悉吗？
   • 熟悉 → Agents Deep Research
   • 不熟悉 → GPT Researcher / dzhng

三个常见失败模式

失败 1：直接用用户原句搜索。 「2026 年 agent 监控市场」90% 是旧内容。必须做 query 改造——拆分子问题、加入时间限定、加入具体名词。

失败 2：单源信以为真。 一个博客说「Langfuse 被 Datadog 收购」不代表是真的。强制 3 源以上交叉，官方文档优先。

失败 3：让 LLM 一次性写 5000 字。 写到 1500 字时它就开始编造引用。必须分章节写 + 每章后做引文检查。

总结

• Deep Research = 迭代检索 + 事实验证 + 长报告生成，缺一不可。
• Query 改造是搜索质量的命门——直接拿原句搜等于在垃圾堆里找答案。
• 多源交叉 + 置信度分级是反幻觉的硬约束，每个事实必须挂源。
• 报告分章节写 + 引文检查是质量底线，不要让 LLM 一次性写完。

下一步可以先从 GPT Researcher 跑通：起一个 5 分钟的小研究任务，把 query 改造的 prompt 模板套上去，对比「原句直接搜」和「改造后搜」的结果差异，你会立刻理解 query 改造的威力。