如何设计能检索、整合证据并生成报告的 Deep Research Agent？

核心回答

我会把研究任务拆成查询规划、并发资料采集、上下文筛选和报告写作，并让来源随内容一起传递。GPT Researcher 的普通网页研究就是这条路线：先初搜了解主题，再生成子查询，读入初搜来源，并用 asyncio.gather 并发处理各个子查询；同一研究实例共享已访问 URL 集合，减少重复抓取。最后将相关内容汇总到 context，交给报告生成器写作并引用来源。

这样能把一次开放式调研组织为可执行的有限任务。若还要求反复发现证据缺口、追查争议和决定何时停止，我会在此基础上增加证据状态与补查控制；不能把“并发搜完一批问题”直接当成已经完成了事实交叉验证。

1. 先用初搜校准研究问题，再执行子查询

GPTResearcher 用 Python 协调检索器、网页抓取器、上下文筛选器和 LLM 报告生成器。以 report_source="web" 的普通 research_report 为例，ResearchConductor 先用第一个检索器搜索原问题，将初搜结果交给 plan_research_outline 生成子查询。普通研究还会把原问题加入待研究列表；subtopic_report 则不再追加它，避免子主题又展开成整个主问题。

初搜不只是规划材料。在执行子查询前，这条链还会通过正常的正文获取路径读取初搜来源，形成 initial_context，再并发运行各个 _process_sub_query。这样，规划时看到的重要来源不会仅因后续换了关键词而被遗漏。所有非空子查询上下文连同初搜上下文一起合并。普通研究编排源码。

asyncio.gather 调度的是子查询协程，并不意味着每个查询都拥有一个独立的多代理工作流。它本身也不提供并发上限。若用于持续运行的服务，我会结合搜索配额设置并发限制、单来源超时和失败状态，而不是只增加子查询数量。当前 _process_sub_query 会把常见异常记录后转换为空字符串，汇总时过滤空值，因此有报告产出也可能仍有部分研究问题没有资料。

2. 获取正文、控制重复，再挑选相关上下文

每个子查询遍历已配置的检索器，获得待抓取链接或检索器已取回的正文。当前实现优先看检索器的 requires_scraping 声明：明确需要抓取的结果，即使带长摘要也仍需获取网页；明确已提供内容的结果可以直接复用。未声明的旧检索器才沿用 raw_content 长度启发式，不能一概把搜索摘要当成已读正文。

对需要抓取的 URL，_get_new_urls 检查共享的 visited_urls，先加入集合，再交给抓取器。这能减少并发子查询重复抓同一链接，但它按 URL 字符串判断，不会自动识别不同地址的转载；预取正文分支也不能据此推定绝无重复。并且“已加入集合”早于抓取成功，不能把访问集合直接当作成功读取的证据清单。来源获取与 URL 去重源码。

网页内容随后进入 ContextManager 的 select_context。它按配置选择相关片段，而不是必须先建向量库：auto 在有 TYPESAFE_API_KEY 时选择 Jev，否则使用关键词排序；也可显式选择 embeddings 或不过滤的 none。进入上下文的文档保留来源 URL、标题与内容，方便报告引用。筛选是在控制相关性和上下文体积，不能代替对来源可信度、时效和矛盾事实的判断。

3. 报告基于已收集内容写，证据不足要留下缺口

普通入口先调用 conduct_research()，再调用 write_report()。报告生成器把研究问题、上下文、报告类型、格式、语言等组装成写作请求；上下文为空时会直接说明未取得来源材料。默认报告提示词要求重要论断、数字和引文带文内链接，并在末尾列出采用的来源。报告生成器源码。

如果目标是可核验的研究报告，我会再保存“子问题、论断、原文片段、URL、发布时间、核验状态”的证据表，写作前检查关键问题的覆盖情况，对冲突或缺证据的部分定向补搜。以调研固态电池商业化进展为例，可分别查技术指标、试产与量产、企业公告和独立测试；同一新闻的多处转载不能算多个独立证据，“计划量产”也不能被整合成“已经量产”。这些证据表、补查与逐论断核验属于增强设计，当前默认提示词要求引用，并不等于程序已逐条验证引用能支持结论。

停止条件也应明确：关键问题已有足够证据，或达到轮数、时间、费用预算；停止时输出仍未解决的问题。验收则分别看子问题覆盖、引用是否支持结论、冲突是否交代，以及耗时和调用成本，不能仅以报告篇幅或 URL 数量判断质量。

4. 普通研究、详细研究和深度研究怎样选？

• 普通 research_report：围绕一份查询计划采集和筛选资料，再写报告，适合范围清楚的调研。
• detailed_report：先做初步研究并规划子主题，再由 DetailedReport 逐个生成子主题报告，共享 URL 集合，并传入已有章节及相关已写内容，最后组装长报告；子主题的外层循环是串行的。
• deep：GPTResearcher.conduct_research 单独分流到 DeepResearchSkill，有广度、深度和并发配置，继续递归追查研究方向。
• multi_agents：后端转到另一套多代理入口，组织规划、研究、审阅与写作等协作；不能将它的角色和审阅步骤写成普通子查询链默认执行的步骤。

选型取决于问题是否需要层层追查或多轮审阅。先让普通路线的来源获取和报告引用可靠，再按任务需要增加深度与协作；更多搜索与更多代理都会增加费用、延迟和汇总难度。

参考资料

• 国内：Datawhale：第十四章 自动化深度研究智能体：参考规划、执行、报告三阶段与子任务保留来源的组织方法，解释研究问题怎样转化为可执行任务和最终报告。
• 国内：JavaGuide：上下文工程：参考动态证据筛选、原始引用保留与摘要丢失的处理，说明上下文选择为何要兼顾相关性、关键条件和回查入口。
• 国内：adongwanai：Agentic RAG / Deep Research 备战手册：参考显式搜索规划、独立来源交叉验证和关键矛盾保留，解释证据表与缺口补查的增强设计。
• 国内：ranxi2001：评估与全局观：参考检索质量与最终回答质量分开评估的方法，说明报告验收为何要检查覆盖、引用支持和失败归因。
• 国外：Assaf Elovic：How we built GPT Researcher：参考有限查询计划、异步采集与汇总写作的设计动机；本文具体调用顺序与模式划分依据所选版本源码，不采用旧文中的效果数字。
• 国外：Python：Running Tasks Concurrently：依据 gather 的并发调度和结果汇总语义，说明子查询协程怎样共同执行，以及为何并发上限和失败策略需要另外设计。