从"Deep Research"这个词被各家AI产品做成按钮之后，社区里其实一直在悄悄折腾一件事：把这种"给一个问题，自动查资料、交叉验证、写长报告"的能力打包成一个能自己部署、能换模型、能改提示词的开源技能。
我见过太多人上来就问"哪个仓库最好用"，结果扎进GitHub搜了一圈，被几百个star的demo项目晃花了眼，部署半小时、跑起来全是坑。这篇文章不打算给你列一百个仓库，而是把我实际用过、在社区里被反复验证过的几个真正能打的Deep Research仓库讲透，包括它们各自藏在哪、解决什么问题、坑在哪里，以及怎么把它们组装成一套自己能用的研究流水线。适合想自己搭深度研究Agent的开发者，也适合刚接触"AI研究助手"、想搞懂这类工具底层逻辑的读者。看完至少能少走两三个礼拜弯路。
1. 先搞清楚：社区里说的"Doing Deep Research技能"到底在找什么
很多人找仓库的时候，其实并不清楚自己要找的是哪一层东西。Deep Research不是一个单一的开源项目，它是一套完整的工程链路。如果这一步没想清楚，后面看仓库会越看越乱。
拆开来看，一个能跑通的Deep Research技能，至少包含四个核心模块：
- 任务规划与拆解层：把"帮我调研一下某技术方向"这种模糊提问，拆成"搜索哪些关键词、访问哪些来源、需要回答哪几个子问题"。这套逻辑在学术上叫Plan-and-Execute或者Task Decomposition。
- 信息检索层：决定用什么方式抓资料。可以是搜索API（如Bing、Tavily、Exa等），也可以是爬虫直接抓网页，甚至可以是RAG（检索增强生成）方式对接你自己的知识库。
- 推理与写作层：由大模型驱动，负责分析检索回来的资料、判断信息可信度、生成最终的长篇报告。模型的选择直接决定了报告质量和成本。
- 编排与状态管理层：把上面三步串起来，管理任务队列、控制并发、记录中间状态。这层决定了整个流程是"一次性跑完"还是"可断点续跑"，也决定了你修改每一步逻辑的难易程度。
社区里那些被反复推荐的项目，绝大多数都是在这四层中某一两层做得极其出色，而不是全栈通吃。所以"最好用的Deep Research技能"这个问题，本质上是在问：你更看重哪一层，以及你打算用什么模型、什么检索源来喂它。
另外有个很容易被忽略的点：Deep Research技能和普通聊天机器人的最大区别在于多轮自我反思。好的研究Agent会先做一轮初步检索，发现信息不足后主动修正搜索词继续深挖，最后让另一个"审稿人"角色检查报告漏洞。你在挑仓库的时候，重点要看它的Prompt设计里有没有这层"迭代-反思"机制，没有的话只能算高级搜索引擎包装器，不能被称作Deep Research。
2. 社区里真正值得翻的仓库：四个方向各有代表
GitHub上挂着"deep research"名字的仓库一抓一大把，但多数要么停留在"一个Python脚本+一个Prompt"的Demo层级，要么文档缺失、更新停滞。根据我自己的使用体验和社区反馈，下面这四个方向基本覆盖了社区里最有价值的开源沉淀。
2.1 gpt-researcher：社区生态最完整的全能选手
仓库地址：`github.com/assafelovic/gpt-researcher*
这是目前社区里认可度最高、迭代最活跃的Deep Research开源项目之一。它把上面说的四层全部做成了一套产品级实现，前端、后端、Agent逻辑都有，支持Docker一键部署。
它的核心亮点在于信息检索层做得非常丰富。内置了Tavily、Bing、Google、Exa、Boolan、Arxiv、PubMed等多个搜索与学术检索源，并且允许你自己注册搜索API的key写进配置。这意味着什么？意味着你不用改代码，只是改配置文件，就能切换检索后端，这在中文资料调研里特别重要——你可以把检索源换成适合中文内容的搜索引擎。
推理层方面，gpt-researcher默认支持OpenAI系模型，但社区配置里也大量使用DeepSeek、Qwen这类国产模型跑通，效果相当不错。整个项目的"技能"沉淀在几个核心模块里：先生成搜索Query列表，再对每个Query做检索并总结，然后聚合所有子研究结果，最后带反思机制生成完整报告。
如果说缺点，就是这个项目功能太全，新手直接部署容易在环境依赖上栽跟头。后面第4节我会讲怎么把它跑起来。
2.2 dzhng/deep-research：OpenAI官方都转发过的极简实现
仓库地址：github.com/dzhng/deep-research
这个仓库曾经被OpenAI官方账号在社交媒体上翻过牌子，属于"官方认证过思路"的那种。最大特点是TypeScript编写、代码结构极其清爽，整个核心逻辑几百行就讲清楚了Deep Research的工作流。
它实现了一套很有意思的迭代算法：先让模型生成一组带依赖关系的研究问题，然后逐层回答，每回答一层就把结果作为下一轮提问的上下文，最终汇总成结构化的研究报告。这种"iterative research loop"的思路非常值得学习，如果你想自己写一套Deep Research的Prompt流程，直接读这个仓库的源码比读任何教程都管用。
但它的问题也很明显：默认没有配很丰富的检索源，依赖用户提供一个搜索API的key，且更偏"Demo级工具"，不太适合做产品化部署。不过正因如此，它反而成了很多人学习Deep Research工作流的最佳入门材料。
2.3 STORM：学术派长文生成代表
仓库地址：github.com/stanford-oval/storm
斯坦福出品的STORM（STOrmer小写）系统，全称是"STandford Open-source Research Machine"，学术味道很重。它解决的问题和商业Deep Research不太一样：重点在于写一篇像维基百科那样结构完整的长文。
它的杀招是"多角度提问+模拟人类专家对话"。系统会先让大模型扮演不同视角的"专家"（比如历史学家、技术专家、产品经理），围绕主题互相提问和回答，从多轮对话中提炼需要检索的信息，最后基于这些信息生成带引用的长文。这套"Multi-perspective Question Asking"机制目前仍是社区里做长文生成最值得借鉴的思路之一。
这个仓库的定位非常适合调研报告、综述文章这类场景。但它同样存在部署门槛高、对模型要求高的问题，需要使用质量不错的模型才能发挥出优势。
2.4 基于DeepSeek系模型的工作流仓库：国内社区的最爱
搜索"deepseek 和wtm 相关的源码仓库"这类关键词时，你会看到一批基于DeepSeek模型重新实现的Deep Research工作流项目。这类仓库的特点非常鲜明：全部围绕DeepSeek的API做适配，有大量中文注释，部署文档写得通俗。
从实际使用体验来说，DeepSeek系模型（特别是推理型模型）在"拆解问题、判断资料相关性"这些环节上的表现非常出色，成本又远低于GPT-4级别模型，所以国内很多开发者都把它当成Deep Research的默认推理底座。相关仓库通常在gpt-researcher等主流项目基础上做了二次封装，把默认模型改成DeepSeek，并配好了国内可以直接访问的接口地址，对中文场景友好得多。
你在找这类仓库时要注意一个鉴别点：看它是否只是简单改了模型名，还是针对中文检索、中文长文写作做了Prompt层面的调优。只改模型名的仓库，实际跑起来通常还是会出中英文混杂、引用格式错乱的问题。
3. 仓库选型对照表：从实际场景倒推该用哪个
新手最容易犯的错是挑star最多的仓库直接开跑，结果发现和自己的场景根本不匹配。我先给出一张选型对照表，再解释每个场景背后的取舍逻辑。
| 仓库/方向 | 最适合的场景 | 语言栈 | 部署难度 | 检索源丰富度 | 报告质量 |
|---|---|---|---|---|---|
| gpt-researcher | 产品化部署、多检索源、长期维护 | Python + React | 中高 | 高 | 高 |
| dzhng/deep-research | 学习工作流原理、自研代码 | TypeScript | 低 | 低 | 中 |
| STORM | 学术综述、长文生成 | Python | 高 | 中 | 高 |
| DeepSeek改造系仓库 | 中文场景、低推理成本 | 多种 | 低~中 | 中 | 中高 |
怎么理解这张表？我根据自己的实际踩坑经验给出以下几个判断维度：
- 如果你是产品经理或想快速搭一个内部工具，不要纠结dzhng或STORM，直接上gpt-researcher。因为它是唯一把"前端交互、后端任务队列、检索适配、报告生成"全部做成一键部署的项目，你只需要关注业务场景本身，不用从零开始拼轮子。
- 如果你是开发者，想彻底搞懂Deep Research的原理，以便在公司里做定制开发，首选dzhng/deep-research。它的代码量最小，核心逻辑可以一行行读懂。读完之后你对"研究Agent"的理解会直接上一个台阶，再去看其他重型仓库会轻松很多。
- 如果你的目的是写一份高质量综述、行业研究报告，STORM的专家模拟机制会给你惊喜，但需要准备好性能不错的模型API和足够的耐心调参。
- 如果你主要处理中文资料、且在意API成本，在gpt-researcher基础上改造，或者直接用社区里基于DeepSeek的工作流仓库，是性价比最高的选择。
这里多提醒一句：star数量和实际体验不完全挂钩。有些仓库star高是因为上线早、宣传多，不代表它在你的场景里就是最优解。真正决定好不好用的，是它的编排逻辑是否灵活、检索层是否支持替换、Prompt是否针对你的需求场景调过。与其迷信star，不如拉下来跑一遍看效果。
4. 把仓库搬回本地：克隆、环境准备与最小可运行装配
选定仓库只是第一步，真正决定你能否用起来的往往是部署环节。这里我以gpt-researcher为例，给出一套完整的本地装配流程，其他仓库的核心逻辑大同小异，学会一套就能举一反三。
4.1 获取代码：GitHub克隆与国内镜像的取舍
git clone https://github.com/assafelovic/gpt-researcher.git cd gpt-researcher如果你的网络环境不太好，clone超时是家常便饭。两条替代路径：
- 用Gitee镜像仓库搜索该项目的搬运副本，直接克隆镜像地址，再把这个镜像仓库添加为remote。
- 用代理工具走系统代理后再clone（但这类配置不在本文讨论范围内）。
我个人更推荐第一种。Gitee上不少人会定期同步热门项目，虽然偶尔有延迟，但至少能稳定拿到代码。拿到代码后建议先切到最新的release tag，避免直接用main分支踩到未稳定代码的坑：
git fetch --tags git checkout $(git describe --tags $(git rev-list --tags --max-count=1))4.2 创建Python虚拟环境与安装依赖
gpt-researcher是Python项目，强烈建议使用虚拟环境，不要直接装进系统Python。我用过python3.12实测下来没问题，Python 3.10以上基本都兼容。
python3 -m venv venv source venv/bin/activate pip install -r requirements.txt这里有个关键细节：requirements.txt里的依赖版本更新比较激进，偶尔会有版本冲突。如果安装时报某个包编译失败，优先尝试降低Python的小版本号（比如3.11换成3.10），不要去手动改依赖版本，否则后面跑起来容易出更隐蔽的问题。
4.3 最少配置：只调两个必须项
gpt-researcher提供了.env.example文件，复制成.env后需要配置的最少项目有两类：
- 模型配置。默认是OpenAI。如果你用DeepSeek，要改成兼容OpenAI SDK的base_url，并把模型名设置成DeepSeek对应的版本。大致写法：
OPENAI_BASE_URL=https://api.deepseek.com/v1 OPENAI_API_KEY=你的key OPENAI_MODEL=deepseek-chat- 检索配置。至少配置一个搜索API的key。比如用Tavily的话：
TAVILY_API_KEY=tvly-你的key或者用Bing搜索的key也行，看哪个方便注册。不要一上来把所有检索源都填满，一个能通就可以先跑通全流程，后面再逐步加。
4.4 最小运行测试和前后端跑通
后端启动：
python -m uvicorn main:app --reload前端（如果不需要可视化界面可跳过）：
cd frontend npm install npm run dev启动后用浏览器打开前端页面，输入一个简单的研究问题（比如"比较Python和Rust在Web开发中的适用性"），观察日志。如果能看到生成Query、搜索、总结、再聚合这些步骤，说明核心链路已经通了。
5. 从"能跑"到"好用"：把仓库里的技能拧成自己的工作流
部署跑通只是第一步。说实话，很多repo默认配置跑出来的效果只能算"能用"，距离"好用"还有明显差距。我自己在调整过程中总结了几条比较通用的优化路径，也顺带解释一下背后的原理。
5.1 检索源按场景做减法，别贪多
很多人跑通后会兴奋地把所有搜索API都填进配置，觉得检索源越多效果越好。实测下来并不是这样。检索源过多会导致报告里有大量重复信息，而且不同来源的置信度权重不同，反而干扰模型的判断。
更好的做法是：先看你的调研场景，再决定保留哪两个检索源。比如行业报告类调研，保留通用网页搜索加一个专业数据源就够了；学术类调研，把Arxiv、PubMed这类学术源开起来，通用搜索作为补充。在gpt-researcher里，这个选择在.env里配置，在自研工作流里，就是控制检索源列表的长度。
5.2 给工作流加"审稿人"角色
大多数开源Deep Research仓库默认生成的报告是"一次性输出"的，缺少质量检查环节。我自己在调优时，会在最终生成报告前加一步：让模型以审稿人的视角重新审视之前生成的提纲与结论，标出"论据不足""来源冲突""逻辑断层"这几个问题，再回炉重写一遍。
这步操作的成本很低——只是多一次模型调用——但对最终报告质量的提升非常明显。社区里不少基于DeepSeek的工作流仓库也默认内置了这个反思环节，你去找这一类仓库时，可以把"有没有反思机制"当成一个重要筛选条件。
5.3 控制深度与成本的平衡：限制迭代轮数
Deep Research最花钱的地方在于无休止的深入检索。每个子问题都再拆出一堆搜索词，一轮轮迭代下去，一个简单的调研问题跑出几万个token的调用很正常。我在实验中发现一个实用的做法：给子问题深度设置最大层级。比如一级问题允许拆出5个子问题，每个子问题最多只做两轮迭代搜索，超出后自动汇总。这个限制在gpt-researcher里需要在代码层面修改迭代逻辑，而在自研工作流里就是初始化队列时加一个depth字段。别怕限制会损失质量，实际测试下来大部分问题用两层迭代已经足够，超过三层的边际收益非常低。
5.4 本地私有知识的接入
如果你调研的是公司内部产品、团队文档这类互联网上搜不到的内容，纯靠在线搜索肯定不行。这时候需要给Deep Research技能加一个RAG入口：先把内部文档向量化，存到本地向量库，在检索阶段同时搜索网络和本地知识库，把两路结果一起交给模型。
gpt-researcher有专门的knowledge模块可以接向量库，社区里像LangChain、LlamaIndex也都有类似的方案。个人项目的话，用一个轻量级的向量库（比如Chroma）就够了。
6. 社区仓库的"陷阱"识别与避坑记录
最后一个部分，分享几条我在翻社区仓库时的筛选经验，也把实际踩过的坑列出来，能帮你省下不少时间。
6.1 常见"伪Deep Research仓库"的三个特征
- 只挂了一个Prompt文件。真正的Deep Research技能是工程问题，不是一个大模型Prompt能搞定的。如果仓库里只有一个
prompt.md，没有任何编排代码，基本可以绕道。 - README吹得很大，代码结构一塌糊涂。几十个文件全堆在根目录、没有README的安装步骤、没有任何配置文件示例，这类仓库通常维护得不好，跑起来大概率是灾难。
- Model Name写死。有些仓库代码里直接把模型名写死在业务逻辑中，换个模型还要改源码。好仓库一定会用环境变量或配置文件来管理模型。
6.2 依赖冲突的经典场景
我在本地装gpt-researcher时踩过一个很典型的坑：pydantic版本冲突。项目依赖要求pydantic>=2.0，但某个传递依赖偷偷装回了1.x版本，导致启动时接口一直报校验错误。解决方法是安装完依赖后立刻检查：
pip show pydantic确保版本是2.x系列。如果发现版本不对，手动执行pip install pydantic>=2.0 --upgrade即可。这类兼容问题在迭代快的开源项目里经常遇到，装完依赖先验证核心库版本，能免掉后面大量的排查时间。
6.3 检索API的配额坑
用Tavily这类搜索API时，新用户通常有每月一千次的免费额度，听着不少，但Deep Research一次完整调研可能就要消耗几十到上百次搜索请求，跑上几次深度研究就触顶了。我在测试时经常遇到"报告写到一半突然所有搜索都失败"的情况，就是因为配额耗尽。建议在正式跑大批量任务前，先去API后台确认当前剩余额度，或者直接接一个有较高限额的搜索服务，免得跑一半断掉。
6.4 中文环境的特殊处理
直接用社区通用仓库跑中文调研，最容易出现两个问题：一是搜索引擎返回的中文网页质量参差不齐，模型容易被低质内容带偏；二是生成报告时中英文夹杂、术语混乱。我的处理方法是：在检索环节配一个以中文内容为主的搜索引擎源（或者给搜索词加lang:zh限制），再在Prompt里明确要求"所有输出必须为中文，专业术语保留英文原文并附中文翻译"。
如果用的是DeepSeek系模型，中文写作问题会轻很多。这也是为什么我始终建议做中文场景的读者优先考虑DeepSeek改造系仓库，而不是强行用默认的英文模型工作流。
6.5 仓库同步与二次开发的心得
最后一条经验：如果你基于某个开源仓库做了二次开发，一定要在本地保留一份纯净的上游备份，并且定期拉取上游更新。社区项目迭代快，经常会有安全修复和新功能，你自己改过代码之后merge起来会比较头疼。我现在的习惯是fork一份到自己账号下，日常修改都提交到fork仓库，需要同步上游时用GitHub的fetch upstream功能拉取合并。这样做还有一个额外好处：你本地的改动备份在云端，换电脑重新clone就能继续开发。
说到fork，这里顺便提醒一个国内开发者容易忽略的操作：GitHub上直接创建自己的仓库并推代码，这个流程很多人不熟。先把本地项目关联到远端仓库：
git init git add . git commit -m "init" git remote add origin git@github.com:你的用户名/你的仓库名.git git branch -M main git push -u origin main如果你用的是Gitee，流程完全一致，只是远端地址换成Gitee的地址。这套基础操作看起来简单，但我在社区里见过不少人卡在这一步——代码改完了不知道怎么同步到自己的仓库，更没法用CI/CD自动化部署。
说实话，Deep Research技能在社区里已经不算什么"黑科技"了，真正拉开差距的是你有没有把它当成一套工程系统去调试和打磨。仓库只是起点，把检索、反思、成本控制、中文适配这些细节调到你自己的场景里，才算是真正拥有了这门技能。
