先说结论GitHub 上叫 deep-research 的仓库没有一千也有八百但真正值得花时间看、能直接抄作业的掰着指头数也就那么五六个。我最近帮团队做技术选型把这些仓库从上到下翻了一遍有的跑通了、有的跑到一半放弃了踩了不少坑也攒了一些心得。这篇文章我就直接按“哪个仓库解决什么问题、适不适合你、怎么用”来讲不整虚的。先说清楚一件事Deep Research 这个能力本质上不是“搜索”而是“把搜索变成一项工程”。它要求模型自己判断需要找什么信息、拆成哪些子问题、去哪里找、找到之后怎么判断可信度、要不要追查更深的来源最后再组织成一份有引用、有逻辑、有侧重点的报告。这套东西看着简单做起来很吃工程细节所以社区里那些做得好用的仓库几乎都不是靠一个花哨的模型撑着而是靠一套设计得比较顺的流程在跑。理解了这一点你再看下面这几个仓库就会明白它们各自的取舍在哪里。1. Deep Research 技能到底是什么以及“技能”这个词拆开看1.1 一句话讲清它的工作逻辑我习惯把 Deep Research 理解为“一个会自己列提纲、自己查资料、自己写综述的研究助理”。它和你直接丢给 ChatGPT 一个问题让它是“随便聊两句”完全不是一回事。真正做得好的 Deep Research 流程通常包含这么几个环节把用户问题拆解成若干个可以检索的子问题针对每个子问题构造搜索关键词并调用搜索接口抓取搜索结果正文做内容提取对提取到的内容做相关性判断决定是要深挖还是跳过综合所有信息生成带引用的完整报告。这一步一步串起来就是一个典型的 Agent 工作流。仓库与仓库之间的差别主要就在于每一步用什么组件去实现以及流程编排得是否精致。有的仓库只在“搜索”和“生成”之间做了一次串联有的则加入了反思、重写查询、去重、溯源等复杂机制体验差距就这么拉开了。1.2 “技能”在 AI 工具链里的两种理解关于“技能”这个词我发现社区里其实有两种用法混在一起讨论就容易乱。一种是指大模型能力本身比如“具备 Deep Research 能力的技能包”另一种是指集成在 Cursor、Trae、扣子这类工具里的自定义技能也就是你写一套提示词模板加工作流说明让 Agent 在特定场景下自动调用。比如去看 Cursor 的规则文件本质就是一个 Markdown 文档里面写清楚“你是一个研究员遇到复杂问题要按以下步骤操作”再配上可执行的工具调用说明。所以当你问“Deep Research 技能藏在哪几个仓库里”的时候实际上可以拆成两个层面的答案代码仓库层面有上面说的那些可以直接部署的开源项目技能封装层面你也可以把这些项目里沉淀出来的 Prompt 流程提炼成自己工具里的一个 Skill 文件。这一点后面我会专门讲怎么做因为它才是让 Deep Research 能力真正融进你日常工作流的关键。2. 社区里真正值得看的六个仓库2.1 官方思路参考OpenAI 的示例代码OpenAI 官方开源过一个 Deep Research 的参考实现代码量不多但它很有价值因为它是市面上质量最高的“教学样例”。仓库地址就是 openai/deep-research整体结构非常清晰解析任务、规划搜索、并行执行、结果汇总每一步都写得规规矩矩。这个仓库给我最大的启发是它对“搜索规划”的处理。它不会让模型一次性把所有搜索都做完而是边搜边看根据已有的搜索结果显示下一步要查什么。也就是说搜索策略是动态生成的不是一次性列好几个 query 然后机械执行。我后来跑了一下发现它在处理那种需要多角度交叉验证的问题时这个动态规划能力非常关键。不过这个仓库官方定位就是示例没有做太多工程化处理没有现成的 Web UI也没有任务队列适合有一定经验的开发者当参考不适合小白直接拿去部署。2.2 老牌全能选手gpt-researcher如果说社区里要选一个“最好用的 Deep Research 技能”那大概率是 gpt-researcher。这个项目最早在 2023 年就有了作者 assafelovic 是从 GPT-4 时代就开始折腾 Agent 搜索的人项目生命周期非常长迭代也极其活跃。它支持极多的模型后端OpenAI、Anthropic、Ollama 本地模型都行还提供了前后端一体化的 Web 界面配好 API Key 直接就能在浏览器里用对新手极其友好。gpt-researcher 相对官方案例的重要升级在于它加了一层“多 Agent 协作”的机制不同子任务由不同角色的 Agent 来处理比如有的负责生成搜索计划、有的负责信息提取、有的负责最终写作。这听起来挺复杂但作者把配置做得很好绝大多数操作都是在配置文件里改改模型名、改改搜索 API 就完事了。我自己用下来它在报告质量上比较稳定而且支持输出 PDF、Word 等多种格式拿来直接当内部调研工具用完全够。如果非要说缺点就是依赖安装稍微多一点对网络环境要求比较高首次部署需要耐心。2.3 极简主义代表dzhng/deep-research这个仓库在社区里火得很早原因很简单——它代码量极少整个核心逻辑就一个 Prompt 加一个循环但你跑起来之后发现它居然能完成全部研究流程。它最初的设计思路很有意思与其把复杂的决策交给代码逻辑不如把决策全交给模型自己代码只负责循环调用模型和搜索引擎然后把结果拼起来。这个思路的优缺点都很明显。优点是代码量少意味着非常容易改你可以把里面的搜索接口换掉、把 Prompt 改成中文甚至把它塞进你自己的 Agent 框架里当一个小模块用。缺点是它对模型能力的要求很高如果用能力一般的模型跑你会发现它在复杂任务上容易偏题或者写着写着就丢了前面的信息。我的看法是这个仓库最好的用法不是直接当生产工具而是当“教材”来读读完你就知道 Deep Research 的最小实现可以有多精简这对于后面自己设计技能非常有帮助。2.4 工程化模板LangChain 的 open_deep_researchLangChain 官方也做了一个 Deep Research 的实现仓库名叫 langchain-ai/open_deep_research。它跟 LangGraph 深度绑定换句话说它不是一个独立产品而是一个你可以直接修改和扩展的图编排模板。它的特色是“把研究过程可视化”在 LangSmith 的界面里你可以看到 Agent 每一步在做什么搜索了什么网站、提取了什么内容、做了多少次反思整个执行轨迹一览无余。这个特性在生产环境里其实特别重要因为 Deep Research 是一个多步骤长流程一旦报告质量出问题你根本不知道是从哪一步开始崩的。有了可视化追踪排障效率能高一个量级。我对这个仓库的评价是它不是最简单的方案也不是最强的方案但它是最适合“二次开发”的方案。如果你团队的技术栈本来就用了 LangChain想在公司内部搭一个可以观测、可以审计的研究 Agent这个仓库可以直接作为底座。2.5 搜索侧强化Jina AI 的 deep-searchJina AI 出的 deep-search 仓库也值得一看它的侧重点跟前面几个都不太一样更强调怎么通过“更好的检索”来提升最终报告质量。Jina 本身就是做搜索基础设施的所以他们把自己在嵌入模型、重排序、Reader API 上的积累做进了这个研究工具里比如用它抓取网页正文时能把杂乱的网页结构清理得异常干净后面模型读到的信息密度就高很多。我自己因为主要做中文场景研究其实很看重文本提取这一步。很多英文开源工具对中文网页的正文提取做得很粗糙导航、广告、杂乱样式一堆模型根本没耐心读完。Jina 的 Reader API 在这一块表现好不少。当然它的缺点也很直接部分高级功能需要商用 API Key 或者有配额限制纯免费使用会受一定约束。但就算不直接用它的整套方案单独把它的内容提取模块借过来也值了。2.6 轻量到可以塞进口袋Hugging Face 的 smolagents 示例最后提一个比较特殊的Hugging Face 官方在 smolagents 里带过一个 Deep Research 的示例。这个示例比前面几个都要轻量核心就是几行代码加一个模型循环能跑起来也具备基础的研究能力。它的定位更像一个起点教你怎么用 smolagents 这个极简 Agent 框架实现研究任务。2.7 仓库速览对比不是让你们全部署一遍而是先有个整体概念后面按需查表仓库核心特色最适合谁上手难度工程完整度openai/deep-research官方参考思路清晰想理解原理的开发者中低gpt-researcher全能界面完善想开箱即用的个人/团队低高dzhng/deep-research极简单 Prompt 驱动想学习的初学者低低langchain-ai/open_deep_researchLangGraph 模板可观测需要二次开发的技术团队中中jina-ai/deep-search搜索与内容提取强对检索质量要求高的用户中中smolagents 示例几百行代码跑通流程极客玩家和教学场景低极低3. 怎么选型怎么跑通我的一些实操参考3.1 选型前先回答三个问题网上对比这些仓库的文章很多但大多列完参数就结束没告诉你真正的决策点。我实操下来觉得选型只需要回答三个问题第一个问题你是个人用还是团队用个人用追求省心直接上 gpt-researcher 就好团队用以后免不了要定制和观察执行过程LangChain 那个模板更符合长期利益。第二个问题你能接受多少成本Deep Research 是一个高消耗任务跑一次深度研究可能消耗几万到几十万 token如果你用 API 按量付费这绝对不是一个可以随意玩的功能。选型时要认真考虑哪些环节可以省成本比如搜索接口选便宜的、模型选推理能力中等偏上的。第三个问题你要研究的内容以中文为主还是英文为主这直接影响要不要换内容提取组件以及 Prompt 是否要保持中文语境。这一点很多英文仓库默认做得不好需要自己调。3.2 部署时的关键配置项跑通一个 Deep Research 项目表面上看只是“填个 API Key然后运行”实际上有几个配置项会直接决定最终效果我逐个说一下。模型配置是最重要的。不要迷信“越贵越好”而是要看“推理能力与成本的平衡”。最好用的方案是让“规划模型”和“总结模型”分开配置规划环节用推理强一点的最终写作可以稍微降档。这在 gpt-researcher 里是可以配置的值得花时间研究。搜索 API 的选择也很关键。Tavily 是目前社区集成度比较高的搜索 API返回结构清晰也支持直接返回网页内容但配额有限。你也可以选择 SerpAPI、Bing Search 或者自建 SearxNG只要项目支持替换搜索提供方。我个人的建议是第一次跑通用 Tavily 最省事后面要规模化再考虑自建。提取和重排方面前文中对 Jina 的看法在这里就用得上了。如果你主要研究中文内容建议单独把网页正文提取这一环拎出来测一测找到对中文处理好的方式再换回主流程里。别小看这一步提取质量差报告里就会出现大量“幻觉式引用”来源链接和事实对不上这是很影响可信度的问题。3.3 从零跑通一个最小示例的心智模型如果你是第一次碰这类项目我建议不要一上来就追求完整部署而是先用 dzhng/deep-research 这种最小实现跑一遍获得一个“程序替你干活”的直观感觉。它需要的配置很少核心环境变量就是模型 API Key 和搜索 API Key。跑通后用一份需要两三步交叉验证的题目试一下比如“帮我调研一下 2024 年主流的开源向量数据库比较它们的发展趋势”然后观察程序生成的查询列表和报告质量。跑通之后再去接触 gpt-researcher你会立刻理解它多出来的那些模块意义所在。先跑最小的再跑全的心里有底得多遇到报错也能快速定位是你哪一步配置的问题。4. 实操中一定会遇到的四个坑4.1 成本失控一次调研烧掉几十万 token这是最常见的坑而且几乎每个新手都会踩一次。原因很简单Deep Research 的流程决定了它要反复搜索、反复阅读网页、反复生成中间结果任何一个环节失控token 消耗都会暴涨。我见过最夸张的一次一份报告跑完花了将近两百万 token最后生成质量还一般。我的建议是做 Token 预算限制。现在主流仓库都支持设置最大搜索轮数、最大网页访问数一定要把这些参数压到一个合理范围。另外可以在 Prompt 里显式要求模型“不要重复浏览已访问页面、不要在低质量来源上过度展开”这样的提示对控制成本有实际作用。4.2 搜索接口被限流跑着跑着就挂了无论你用的是 Tavily 还是其他搜索 API都有配额限制。Deep Research 一次任务会发起大量搜索请求免费额度常常撑不过几次深度调研。有一次我连续跑了三四次任务第四次跑到一半就收到限流报错任务直接中断前面生成的中间结果全丢了。解决方案也比较朴素一是把搜索并发数调低尽量避免瞬时并发触发限流二是给任务加断点续跑机制不过大部分开源仓库不支持这个所以更现实的办法是“小步快跑”把单次任务的主题范围缩小不要一个问题里塞太多子问题。如果条件允许给搜索 API 配一个备用 Key 做自动切换。4.3 报告质量不稳同一问题跑两次一次好一次差这个坑本质上是大模型随机性和检索过程动态变化导致的。同一个问题换个时间跑搜索结果变了模型关注点也变了报告质量就有波动。这很难完全消除但可以缓解。我试过最有效的方式是提升检索阶段的多样性。让系统不只搜关键词还要搜同义词、上位词、英文原文关键词这样哪怕某一次搜索结果有变化整体的信息覆盖还是足够的。另一个办法是控制生成温度研究报告这类任务温度设置得低一些反而更稳毕竟它要的是准确性和逻辑性不是天马行空。4.4 中文内容支持差来源是中文报告却大量依赖英文资料很多开源项目默认的 Prompt 和检索策略都是英文优先导致你明明想研究中文社区里的内容最后报告引用的反而是一堆英文二手资料。这不是说英文资料不好而是它可能漏掉中文一手信息这对国内场景来说是很致命的。解决办法是在 Prompt 里明确加上检索语言要求比如“优先搜索中文来源其次才是英文来源”并且把质量判断标准写清楚。同时针对中文网页做一次内容提取的测试如果默认提取器不行就换掉。这一步花的时间不多但对报告质量的影响非常大。5. 把它变成属于你自己的“技能”5.1 把开源仓库里的流程抽成 Skill 文件GitHub 上的仓库终究是别人的工程你要想在 Cursor、Trae、扣子这些日常工具里随时用上 Deep Research 能力最好的做法是把它提炼成一个你自己的技能。所谓技能在大多数 Agent 工具里本质就是一套提示词加工作流定义。以 Cursor 的规则机制为例你可以写一个文档内容大概是“当用户要求进行深度调研时你应当按照以下流程执行第一步将问题拆解为 3 到 6 个子问题第二步为每个子问题制定搜索关键词第三步逐个检索并提炼要点第四步交叉验证后生成带引用的报告”。然后再配上输出格式要求比如“Markdown 格式每个章节末尾列出参考链接”。5.2 参考仓库中的 Prompt 设计我提炼技能的时候通常会直接借鉴 gpt-researcher 里的系统提示词再根据自己需求改一改。现有仓库的 Prompt 其实已经经过了大量实践优化尤其是“如何判断来源可信度”“如何避免重复信息”“如何组织长报告”这几段拿来就用可以省很多试错成本。不过要注意直接抄英文 Prompt 会有一个问题就是模型在中文语境下表现可能打折。我的习惯是保留英文 Prompt 的逻辑框架但把具体要求改成中文还要补一句“如果搜索结果包含中文来源优先使用”这样整体效果会自然很多。5.3 技能也可以放进“仓库”里管理最后再说一个容易被忽略的点技能本身也应该像代码一样放进仓库管理。你在 Cursor、Trae 里写好的 Prompt 和工作流定义完全可以存到一个 Git 仓库里用版本管理跟踪每次修改团队协作时也能复用它。很多团队把“公司内部的研究方法论沉淀成一整套技能包”然后推到私有仓库新员工拉下来就能用效果非常好。这个做法把“技能”和“仓库”这两个词彻底打通了。我个人在实际操作中还有一个习惯每次从这些开源仓库里学到新的 Prompt 写法或流程设计我都会顺手更新到自己的技能文件里让技能包保持“活”的状态。这样你手里的 Deep Research 能力就不再是某一次跑完就扔的命令行脚本而是一个能跟你的业务一起沉淀的方法库。想清楚这一点比多部署十个仓库都管用。