最近社区里聊 Deep Research 聊得特别凶各种在线工具、付费插件、一键生成的报告满天飞。但如果你真去 GitHub 上翻一圈就会发现真正能拿来自用、能改、能塞进自己工作流的 Deep Research 技能全藏在几个仓库里。这些仓库不是那种“点个 star 吃灰”的收藏品而是把整个深度调研流程做成了可以复用、可以二次开发的技能包。我花了两周时间把社区里热度最高的十几个仓库都过了一遍今天直接说结论好用的不多但确实有几个藏得也不算深就看你会不会挑。这篇文章主要写给谁一类是正在用 Claude、GPT 这类大模型工具觉得“单轮问答不够深、写出来的东西像综述不像调研”的人另一类是自己写 Agent、想给应用加上深度研究能力的开发者。我会把仓库怎么选、怎么跑起来、踩过哪些坑全讲清楚不绕弯子。1. Deep Research 技能到底是什么为什么都“藏”在仓库里1.1 从“一个按钮”到“一套流程”的认知转变很多人第一次接触 Deep Research是在 ChatGPT 或 Perplexity 里点了一下那个按钮然后看着它自己搜索、自己读网页、自己生成一份带引用的报告。体验确实惊艳但你关掉页面之后会发现一个问题你没法改它的研究策略没法控制它搜索几个来回也没法把它整合进自己日常的内容流程里。社区里说的“Deep Research 技能”本质上就是把这一整套东西拆开、开源、模块化。一个标准的开源技能通常包含三块一是任务的拆解逻辑也就是拿到一个宽泛问题后怎么把它分成几个子问题、按什么顺序去研究二是检索和执行策略比如先搜什么关键词、读哪些类型的页面、搜几轮之后停止三是结果的整理与输出模板包括引用格式、结论结构、不确定信息的标注方式。这三块合在一起就是一套可以脱离特定产品运行的深度调研能力。你不用再依赖某个在线工具里的一个按钮而是可以在自己的环境里调用搜索 API、把结果喂给模型、控制迭代深度、最后产出一份符合你自己格式要求的报告。这就是“技能”和“功能”最大的区别功能是别人定好的技能是你自己能改的。1.2 仓库为什么成了技能最好的载体这里有个很实际的原因技能本身是一堆文本和脚本它的定义文件比如 SKILL.md、提示词模板、搜索脚本、输出示例全部是纯文本结构。纯文本天然适合用 Git 管理所以 GitHub 这类仓库就成了 Deep Research 技能最自然的聚集地。而且仓库这种载体有另外两个在线商店替代不了的好处。一个是可评审性一个技能好不好用你可以直接看代码、看 prompt、看 issue 里别人反馈的问题而不是靠几张截图来判断。另一个是可继承性你找到一个好仓库Fork 一份改成自己的研究模板后续官方更新了还能 merge 回来这种迭代方式在封闭平台里根本做不到。所以你要找“社区里好用的 Deep Research 技能”不用去逛各种应用市场直接去仓库里挖就对了。关键只在于哪些仓库值得挖、怎么挖。2. 社区里值得收藏的几类 Deep Research 技能仓库先说结论没有一个仓库能通吃所有场景不同定位的仓库解决不同层次的问题。我按用途把它们分成四类每类挑了一两个代表作你们按自己的需求对号入座。2.1 聚合类先看全景再决定深耕哪里如果你想快速了解 Deep Research 这个领域到底有哪些工具、哪些论文、哪些开源实现最值得看的是 awesome 系列聚合仓库。这类仓库本身不写代码但它们的价值在于帮你建立地图。比如 awesome-deep-research 这类仓库维护者会把社区里分散的项目按“Agent 框架”“提示词工程”“评估基准”“相关论文”“在线服务”等分类整理好每个条目带一句话简介和链接。我这个月翻了一遍最大的收获不是找到了某个现成工具而是发现这个领域其实已经分化出了几个流派有走多智能体协作路线的有靠搜索迭代路线的还有纯靠提示词硬刚的。搞清楚这些流派之后你再去看具体项目就会有判断力知道某个仓库说的“深度研究”到底是指哪一种深度。聚合类仓库的筛选标准很简单看最近一次更新时间超过半年没动的直接略过再看条目数量和质量如果只是机械堆链接、没有分类说明收藏价值也要打个折。2.2 框架类能直接跑通全流程的 Agent 项目如果你要的是“能真正跑起来、生成一份完整研究报告”的东西那就得看 Agent 框架类仓库。这类仓库通常是一个完整的项目包含搜索工具封装、模型调用逻辑、迭代研究循环、报告生成模板你配置好 API Key 就能跑。这一类里我最常推荐的是 dzhng/deep-research它是个用 TypeScript 写的开源项目核心逻辑是用 AI 生成搜索查询、并行执行搜索、读取结果、再生成下一轮查询循环几次后汇总成报告。整个项目不依赖重型框架代码量不大读一遍能完全搞懂它的研究循环是怎么设计的。我自己复现的时候大概花了半小时就跑通了第一个完整的研究任务体验非常顺。另一类是 LangChain 官方出的 open_deep_research它的定位更偏向 Python 生态适合你本身就在用 LangChain 做 Agent 开发的情况。相比 dzhng 那个项目open_deep_research 的抽象层级更高可定制性更强但相对的新手上手门槛也更高一点。两个项目的核心思路一致让模型自己决定搜什么、搜完读什么、读完再决定要不要继续搜。2.3 技能包类给 Claude 一类助手直接加装研究能力如果你的用法不是写代码而是用 Claude 这类 AI 助手来辅助工作那你要找的不是 Agent 项目而是技能包仓库。所谓技能包就是按特定格式写好的一套文件里面包含技能描述、提示词、脚本和示例放进指定目录后助手就能在需要时自动加载对应能力。现在社区里比较有代表性的两个仓库一个是 anthropics/skills这是官方维护的技能示例库里面包含文档处理、图像理解、深度研究等几个技能格式规范注释详细最适合当学习模板另一个是 obra/superpowers这是 Claude Code 社区里口碑很好的一套技能集合其中 Deep Research 技能的设计很讲究它会把一个研究任务拆成“先列问题、再逐个攻破、最后汇总交叉验证”几步产出的报告结构明显比一次性生成的要扎实。技能包类仓库的正确使用方式不是整个克隆下来直接用而是读懂它的 SKILL.md 是怎么写的学习它怎么定义任务的触发条件、怎么规划研究步骤、怎么处理中间结果然后改写成适合自己场景的版本。这类仓库的价值在“配方”不在于“成品”。2.4 提示词类轻量但上限不低的选择如果你不想引入任何代码依赖也不想换工具链就想在现有的聊天界面里获得接近 Deep Research 的效果那提示词类仓库是性价比最高的选择。这类仓库里通常躺着一份结构化的 Prompt 模板长度从几百字到几千字不等。质量高的模板会把研究任务拆成“初步探索—深度挖掘—信息交叉验证—生成草稿—标注不确定性”几个阶段并且明确要求模型在每一步输出中间结果、保存研究笔记而不是直接给最终答案。用这类仓库要注意一个误区不要指望复制粘贴一份长 Prompt 就能得到和 DeepAgent 一样的效果。Prompt 只是研究流程的“剧本”没有搜索引擎配合模型只能依赖自己的记忆和训练数据来推理效果上限明显受限。但它有一个别人替代不了的优势零成本、零配置、在任何模型上都能试适合你先拿来找感觉。2.5 四类仓库选型对照仓库类型代表方向技术门槛适合谁主要产出聚合类awesome-deep-research 等无刚开始接触、想建立全局认知的人项目地图与选型参考框架类dzhng/deep-research、open_deep_research中想独立运行研究 Agent 的开发者可运行的全流程研究报告技能包类anthropics/skills、obra/superpowers低用 Claude 等助手、想扩展能力的重度用户可复用的技能文件与流程模板提示词类各类 Deep Research Prompt 集合无不想改工具链的普通用户即插即用的研究提示词脚本这个表格不是让你只选一个实际上最好的用法是组合用聚合类建地图用框架类理解原理用技能包类做日常增强用提示词类快速验证想法。四者并不冲突。3. 怎么判断一个 Deep Research 技能仓库到底值不值得收藏GitHub 上搜 deep research 能出来几百个结果名字一个比一个唬人。我这两周踩了不少坑之后总结了一套筛选方法分硬指标和软指标两层按照这个标准筛下来真正值得收藏的其实不到十个。3.1 三个硬指标先排除明显不靠谱的第一个硬指标是更新时间。Deep Research 这个领域受模型能力和搜索工具影响极大半年前的实现很可能因为模型接口变化或搜索 API 调整而完全失效。我的标准是核心代码最近三个月内有过提交或者至少 issues 里有人在最近一个月内反馈并得到回复。超过半年没动的项目哪怕 star 数很高我也会先放一边。第二个硬指标是示例完整度。好的仓库一定会自带 example 目录或至少有一个可运行的 demo 脚本能让你在 README 指引下从零把它跑起来。如果一个仓库只说原理、贴架构图、展示结果截图却没有给你可以复现的路径那我基本可以断定它的作者并不真的在乎使用者能否跑通。第三个硬指标是依赖的克制程度。一个深度研究技能本质上只需要三样东西模型调用能力、搜索能力、文本处理能力。如果某个仓库为此引入了一整套重量级编排框架那你要慎重因为依赖越重未来升级维护的麻烦越大。相反依赖越克制说明作者是在认真控制复杂度这个项目的生命周期往往更长。3.2 两个软指标决定长期值不值得跟硬指标过了之后再看两个软指标。第一个是扩展友好度。具体来说就是作者有没有提供清晰的扩展点比如自定义搜索源、自定义输出模板、自定义研究轮次。拿我自己举例我平时写技术调研报告需要固定的章节结构包括背景、现状、方案对比、推荐结论。我收藏的一个仓库里有一份 research-template.md我可以直接改这一份文件就完成输出格式的定制完全不用动核心代码。这种设计就非常友好它把“常用改动”和“核心逻辑”做了很好的隔离。第二个是社区的二次开发现状。一个项目如果只有作者一个人在提交那个人维护风险就比较大如果能看到多个贡献者的 commit或者有人在讨论区分享自己的 fork 版本那说明这个项目的设计经受住了真实场景的检验即便你不直接用它的代码也能从别人的讨论里学到不少实际问题的解法。3.3 评估时要避开的两个坑有一个坑是 star 数陷阱。很多 star 数特别高的仓库其实是几年前乘着某波热度起来的内容早就和现在的 Deep Research 技术栈脱节了。star 能代表“很多人觉得它有用”但不能代表“它在今天还有用”。另一个坑是 README 过度包装。有些仓库 README 写得极其漂亮架构图画得贼专业术语一个接一个但你往下一拉发现连基本的安装说明都缺。我现在的判断习惯是先看安装和快速开始部分如果五分钟之内找不到“怎么跑起来”那就直接关掉不管它看起来多专业。4. 实操把仓库里的 Deep Research 技能真正跑起来筛选只是开始真正重要的是让技能在自己的环境里工作。这一节我分别讲框架类和技能包类的落地步骤都是我自己跑通过、整理过的流程。4.1 五分钟跑通一个开源 Deep Research Agent以我之前提到的 dzhng/deep-research 为例完整步骤是这样的。第一步准备环境。需要 Node.js 18 以上版本和一个可用的模型 API Key我用的是 OpenAI 兼容接口。项目本身依赖不多克隆下来之后在根目录找到 .env.example 文件复制成 .env填上 API Key 和搜索服务的 Key 就能开始配置。第二步安装依赖并启动。执行npm install安装依赖包然后运行npm run start。启动后它会进入交互式命令行让你输入研究课题你可以输入类似“对比分析 2025 年主流向量数据库的优劣势”这样的问题再设置研究深度参数。第三步理解它的研究循环。整个研究分为多轮。第一轮模型把你输入的问题拆解成若干个搜索查询并行执行搜索第二轮它阅读返回的结果提炼出关键信息和可能遗漏的角度再生成下一轮搜索词循环直到搜索轮数达到设定的上限。每一轮迭代的中间结果会保存下来最终汇总成报告。这个过程的核心价值在于它让模型有机会看到自己上一轮搜出来的内容再决定下一步往哪个方向挖避免了一次性搜索导致的信息浅薄。第四步输出报告。循环结束后项目会要求模型基于所有中间笔记生成最终报告并且要求标注引用来源。这里有个细节报告模板在根目录的 prompt 文件里可以改你可以让它按你的格式要求输出比如要求每个结论附上至少两个独立信源交叉验证。我实测下来一个普通的研究课题三轮搜索加报告生成耗时大概三到五分钟消耗的 token 在几万级别。对比直接让模型硬写调研深度和信息密度有明显的提升。4.2 把技能包装进 Claude Code 的完整流程如果你不用写代码而是想给 Claude Code 这类工具加装 Deep Research 技能流程会更简单。以 obra/superpowers 这个仓库为例。第一步把仓库克隆到本地找到其中的 skills 目录里面每个子目录就是一个技能。第二步把 deep-research 这个子目录复制到你项目的.claude/skills/目录下或者直接放到 Claude Code 全局技能目录里。第三步检查技能目录里的 SKILL.md 文件确认里面的 frontmatter名称、描述、触发场景符合你的预期。第四步重启 Claude Code在对话里输入一个研究型问题如果技能生效它会自动按 SKILL.md 里定义的步骤执行而不是直接给你一段笼统的回答。这里要特别提醒一个容易踩的坑技能目录放好后如果你发现 Claude 没有按预期调用技能大概率是 SKILL.md 的 frontmatter 写得不够明确。模型是通过描述字段来判断什么时候调用某个技能的如果描述写得太泛它可能在不需要的时候调用或者在需要的时候完全没意识到有这个技能可用。你最好把描述写得具体一点比如“当用户需要基于多个网络来源进行深入调研并生成带引用的报告时使用”。4.3 关键参数和取舍逻辑不管用哪个仓库有几个关键参数你需要根据自己的情况调。搜索轮数是最影响结果质量和成本的参数。轮数越多研究越深但 token 消耗指数级上涨。我一般先跑两轮看效果如果报告明显有遗漏再跑到三轮。实际使用中三轮以上的边际收益就很低了。并发搜索数容易被忽略。很多实现默认并发搜 3 到 5 个查询这个参数受搜索 API 限流影响很大。如果你用的是免费额度有限的搜索服务最好把并发调低避免触发 429 限流导致整个研究任务中断。还有一个是上下文窗口的管理。深度研究最大的隐形杀手是上下文溢出。研究循环跑了几轮之后中间笔记越来越多很容易撑爆模型的上下文窗口。好的实现会自动对中间结果做摘要压缩但如果你用的是自己搭的流程一定要在每轮迭代后有一步“压缩旧笔记、保留关键信息”的动作否则任务跑一半就会报错。5. 常见问题与排查技巧实录5.1 问题速查表现象常见原因排查思路研究跑一半提示上下文超限中间笔记未做摘要压缩检查每轮迭代后是否有压缩步骤降低搜索轮数报告质量不稳定时好时坏模型版本或温度参数不一致锁定模型版本温度参数尽量降到 0 或低值搜索返回结果大量重复搜索词不够发散检查查询生成逻辑加入排除词或限定来源站点技能装好了但助手不调用SKILL.md 描述不具体重写描述字段明确触发场景和任务类型引用来源无法追踪报告阶段未保留原网页 URL检查研究循环是否在每轮保存了完整的来源元数据跑起来特别慢搜索并发低或单轮等待时间长调高并发确认 API 限流允许或减少研究轮数API 报 401/403Key 配置有误或权限不足确认环境变量已加载检查 Key 是否支持所用接口5.2 报告质量不稳定的深层原因我在实际使用中发现报告质量不稳定这个问题很多时候不是代码的问题而是研究过程中“信息冲突”没处理好。网上关于一个问题的说法经常是互相矛盾的有的来自官方文档有的来自个人博客有的甚至是 AI 生成的内容在互相引用。好的 Deep Research 技能会在汇总阶段明确要求模型识别冲突信息并优先采信权重更高的信源比如官方文档大于二手博客、一手实测数据大于主观评论。如果你的技能产出的报告经常出现“信息来源混乱”的情况不要在搜索环节找原因直接去修改报告生成阶段的提示词把信源权重的规则写清楚效果立竿见影。5.3 技能失效的很大概率是依赖变化开源技能仓库最大的维护风险是外部依赖变化。搜索 API 改版、模型接口调整、某个库停止维护任何一个变化都可能导致原来正常的技能突然哑火。遇到这种情况先去仓库的 issue 区搜一下相关关键词大概率已经有人报了同样的问题。如果作者长时间没回应就得考虑你是不是需要自己接手维护了。这也是为什么我前面强调“理解原理比会用更重要”。你如果只是把仓库里的代码当作黑盒来用那一旦出问题就只能被动等作者更新但如果你理解了它的研究循环是怎么设计的哪怕外部依赖变了你也能自己换个搜索接口或者换个模型调用方式把断掉的链路接回来。6. 从“用别人的技能”到“沉淀自己的技能”研究了一段社区仓库之后你会发现一个有意思的现象那些最受欢迎的 Deep Research 技能往往不是来自什么顶级实验室而是来自一些长期用 AI 做深度思考的人他们在日常工作中反复打磨出来的流程。所以我的建议是从社区仓库找到你的起点但不要停在这里。跑通别人写的技能之后把它改造成适合你工作流的样子——你有你自己的报告格式、自己的研究偏好、自己关注的信源。把这些沉淀成你自己的技能定义文件下次再需要类似任务时就不必从零开始。我现在的做法是把所有经过验证的研究模板统一放在一个私有仓库里。每读完一个优秀的社区项目就把它的精华抽取出来融进自己的模板。几个月下来我自己的技能文件已经比当初参考的任何开源版本都更适合自己用了。这也是我认为“社区里最好用的 Deep Research 技能”这个问题的最终答案最好的技能不是存在于某个仓库里而是由你从这些仓库的养分中亲手打磨出来。
