项目地址：
GitHub 仓库：https://github.com/bytedance/deer-flow
GitCode 镜像：https://gitcode.com/GitHub_Trending/de/deer-flow

很多团队在做技术选型、竞品分析、行业研究或者论文综述时，都有类似的痛点：

  • 资料来源太多：官网、GitHub、论文、博客、Issue、社区讨论……
  • 人肉搜索 + 复制粘贴非常耗时，而且每次都是「重来一次」。
  • 做完一版调研报告后，下次很难在此基础上复用流程和中间产物。

简单用一个大模型问几句，往往也不太靠谱：

  • 回答很「会说」，但引用不清、来源不明；
  • 覆盖不全，关键细节容易漏掉；
  • 很难跑一个完整的「长链路调研」工作流。

DeerFlow 就是为了解决这类问题而生的。

简单理解：

DeerFlow = 深度调研场景下的多智能体工作流框架 + LangGraph 驱动的状态机引擎。

它把「需求理解 → 任务拆解 → 多轮检索 → 实验验证 → 报告生成」整个过程，固化成一条可观察、可配置的流水线。

本文会从工程实践视角带你：

  1. 用通俗语言解释 DeerFlow 是什么、解决了什么问题；
  2. 过一遍它的核心架构和角色分工；
  3. 按步骤在本地跑起来一个最小可用的 DeerFlow 实例；
  4. 给出 3 个适合直接上手的调研场景。

一、DeerFlow 是什么？

1.1 一句话定义

DeerFlow 是字节跳动开源的深度调研多智能体框架，基于 LangGraph 构建工作流，用一套预置的 Agent 团队，自动完成「检索 → 阅读 → 分析 → 报告」的长链路任务。

它不是一个通用的任务调度系统，也不是一个简单的 ChatBot，而是专门围绕「深度调研」做了工程化设计：

  • 默认就具备「研究助理小组」：协调者、规划者、研究员、Coder、报告生成器；
  • 内置 Web 搜索、MCP 服务等工具，支持从多种外部来源拉取信息；
  • 用 LangGraph 管理整个流程的状态和分支决策。

1.2 典型使用场景

结合官方说明和论文中的案例，DeerFlow 适合用在：

  • 技术调研 / 架构选型：

    • 评估多种消息队列/向量数据库/Agent 框架；
    • 对比不同开源项目的功能和生态。

  • 产品 / 竞品分析：

    • 自动收集公开资料、用户反馈、功能对比；
    • 输出结构化竞品报告。

  • 学术文献综述：

    • 围绕某个研究方向，汇总论文、博客和 Benchmark；
    • 作为组会分享或项目立项的输入。

  • 代码库与 API 体系调研：

    • 例如快速理解一个复杂开源项目的模块划分和使用方式。

1.3 与「直接问大模型」的区别

直接问大模型：

  • 优点：门槛低，随便问；
  • 缺点：链路短、缺乏结构化、引用不清。

DeerFlow 则是：

  • 把「调研」当成一条有阶段、有角色分工的流水线；
  • 强调每一步有状态、有中间产物（notes/evidence）；
  • 最终由 Reporter 按结构化资料生成报告。

你可以把它看成是一只「会调研的 AI 鹿」，而不是一个只会聊天的 ChatBot。

二、整体架构：一群 Agent + 一张 LangGraph

DeerFlow 的整体思路可以概括成一句话：

用 LangGraph 把多智能体团队串成一张有状态的工作流图，每个节点代表一个角色或工具调用。

2.1 关键角色

（命名可能会随版本略有差异，这里按照官方文档常见称呼来描述）

  1. Coordinator（协调者）

    • 整个系统的入口，对接用户请求；
    • 负责初始化一次调研会话、选择工作流模版；
    • 在不同 Agent 之间转发信息、控制流程走向。

  2. Planner（规划者）

    • 根据用户目标拆解任务，生成「调研路线图」；
    • 把任务拆成若干子主题，设定优先级和建议信息源类型；
    • 随着调研过程推进，可以动态调整计划。

  3. Researcher（研究员）

    • 负责「找资料」：
      • 调用 Web 搜索、爬虫、MCP 服务等工具；
      • 从网页/论文/博客中抽取关键信息；
    • 输出结构化的「发现（finding）」：结论 + 引用链接 + 证据摘要。

  4. Coder（程序员/技术专家）

    • 拥有执行代码的能力（常见是 Python REPL 等）；
    • 用于：
      • 跑示例代码；
      • 做小规模实验或性能对比；
      • 解析复杂配置/日志。

  5. Reporter（报告生成器）

    • 在 Planner 的任务结构和 Research Team 的 evidence 基础上，生成最终报告；
    • 注重：章节结构、引用、结论与证据对应关系；
    • 可以输出 Markdown/HTML 文本，也可以扩展成音频播客。

2.2 LangGraph：把一切串起来的「骨架」

DeerFlow 底层依赖 LangGraph 作为工作流引擎和状态机：

  • 每个角色对应一个节点（或一组节点）；
  • 边的走向取决于状态：
    • 计划是否完成？
    • 信息是否足够？
    • 是否需要更多实验？
  • 中间状态（任务进度、notes/evidence、报告草稿）都会被持久化。

文档中提到 DeerFlow 默认暴露了基于 LangGraph 的 HTTP 接口，例如：

  • POST /api/langgraph/... 触发一次新调研；
  • GET /api/langgraph/... 查询当前状态和事件流。

想理解整体结构，最好的方式就是：

  1. 打开 GitHub 仓库：https://github.com/bytedance/deer-flow
  2. 找到工作流定义和 Agent 定义的代码；
  3. 对照 LangGraph 的官方文档看一眼状态机抽象。

三、在本地跑起一只 DeerFlow：最小可行路径

注意：下面命令是基于当前公开资料的「通用示例」，具体以 DeerFlow 仓库 README 为准。不同版本可能有差异，请以 GitHub/GitCode 最新说明为主。

3.1 环境准备

  • 一台可以上网的机器（推荐 Linux / macOS）；
  • 安装好：
    • Git
    • Python 3.10+（以 README 为准）
  • 拥有至少一组大模型 API Key（例如 OpenAI 兼容接口或其他 LLM 提供商）。

3.2 克隆项目

# GitHub 源仓库
git clone https://github.com/bytedance/deer-flow.git
cd deer-flow

# 如果访问 GitHub 不稳定，也可以用 GitCode 镜像
# git clone https://gitcode.com/GitHub_Trending/de/deer-flow.git

3.3 安装依赖

通常项目会提供 requirements.txt 或 pyproject.toml：

# 示例：使用 pip 安装
pip install -r requirements.txt

# 或者使用 uv/pipx/poetry 等工具，以 README 为准

如果提供了 Docker / docker-compose，也可以直接用容器方式运行：

# 示例，仅供参考
docker compose up -d

3.4 配置大模型和工具

根据 README，一般需要：

  1. 在 .env 或配置文件中填入 LLM 相关配置：

    # 示例，具体 key 名称以项目实际为准
LLM_PROVIDER=your_provider
LLM_API_KEY=sk-...
LLM_MODEL=...

  2. 视情况开启 Web 搜索、MCP 等工具：

    • 配置搜索 API Key；
    • 配置 GitHub/Arxiv 等 MCP 服务的访问凭证。

建议：第一次先用公开 Demo 模式跑通，不要一上来就接企业内网系统，方便你先理解工作流本身。

3.5 启动服务

项目通常会提供一个 Web 服务入口（FastAPI/Uvicorn 或类似方案）：

# 示例命令，以 README 为准
python -m deer_flow.api.main
# 或者
uvicorn deer_flow.api.main:app --host 0.0.0.0 --port 2026

启动成功后，你可以：

  • 打开浏览器访问对应的文档/控制台页面（如果有提供）；
  • 或直接通过 curl / Postman / 自己写脚本调用 POST /api/langgraph/... 来发起调研。

3.6 发起第一次「深度调研」

假设项目提供了一个类似下面的接口（伪代码）：

curl -X POST "http://localhost:2026/api/langgraph/run" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "帮我调研一下几种向量数据库的优劣，对比 Milvus / Qdrant / pgvector",
    "max_depth": 3
  }'

你可以观察：

  • 返回的是一个任务 ID；
  • 随后用 GET 请求轮询状态，看到：
    • Planner 如何拆解任务；
    • Researcher 找到了哪些资料和链接；
    • Coder 是否执行了某些实验；
    • Reporter 生成的最终报告内容。

具体接口名称和字段应以 DeerFlow 仓库当前实现为准，这里仅展示一个通用使用方式。

四、3 个可以直接照做的调研场景

4.1 场景一：评估几种向量数据库方案

问题背景：团队要落地向量检索，需要在 Milvus / Qdrant / pgvector 等方案之间做选型。

用 DeerFlow 可以：

  1. 给出总体需求：数据规模、QPS 预期、部署环境、预算等；
  2. 让 Planner 拆成多个子问题：功能、性能、生态、运维难度；
  3. Researcher 负责：
    • 收集官方文档、Benchmark、社区使用案例；
    • 抽取每个方案的优劣对比；
  4. 如有需要，让 Coder：
    • 跑一个小型 Benchmark；
    • 验证示例代码的复杂度和易用性；
  5. 最终由 Reporter 输出一份结构化报告，包含：
    • 表格对比；
    • 结论和建议；
    • 引用链接列表。

4.2 场景二：竞品功能对比与用户反馈收集

问题背景：你正在做一个 AI 写作工具，需要对比市面上几款产品。

DeerFlow 调研流程可以是：

  1. 给出目标产品列表（A/B/C）；
  2. Planner 拆成几块：
    • 功能矩阵；
    • 价格策略；
    • 目标用户群体；
    • 用户口碑（好评/差评点）；
  3. Researcher 从官网、博客、测评文章、社区帖子里收集信息；
  4. Reporter 整理成一份「竞品对比报告」，帮助产品团队做决策。

4.3 场景三：学术方向文献综述草稿

问题背景：你是研究生/算法工程师，需要在某个方向上做 survey，比如「多智能体深度调研系统」。

可以让 DeerFlow：

  1. Planner 先列出需要覆盖的子方向：
    • 多 Agent 协作模式；
    • 引用管理与证据收集；
    • 长上下文处理方案；
  2. Researcher：
    • 利用 Arxiv/MCP 等工具收集代表性论文；
    • 抽取每篇论文的贡献点和实验结论；
  3. Reporter：
    • 生成一个带章节结构的 survey 草稿；
    • 列出参考文献列表，方便你进一步精修。

在官方论文中，其实已经有用 DeerFlow/Deerflow+ 做多智能体调研研究的实践，可以在 GitHub 仓库的 README 或文档链接中找到参考。

五、小结：把 DeerFlow 当成你的「深度调研流水线」

如果说传统搜索 + 手工整理是一种「人肉流水线」，那 DeerFlow 更像是：

一个可编排、可观察的「AI 调研流水线」，你只需要告诉它目标，它负责带着一群 Agent 把过程跑完。

对工程师和学生来说，DeerFlow 值得你投入时间的原因有三点：

  1. 从工程角度理解多智能体框架：

    • 不只是论文里的概念，而是真实可跑的 LangGraph 状态机；
    • 可以看到角色划分、工具接入、状态管理是如何落地的。

  2. 让深度调研变得可复用、可扩展：

    • 实现一次调研流程后，下次只要换关键词和配置就能复用；
    • 可以逐步把自己团队的内部系统接入进去，形成「企业级调研助手」。

  3. 很好写在简历上的项目实践：

    • 「基于 DeerFlow 搭建技术选型调研助手」
    • 「将 DeerFlow 接入公司内部文档库，做自用行业研究平台」

最后再放一遍项目地址，方便你直接收藏和尝试：

建议你直接 Fork 一份到自己的 GitHub/GitCode，跟着 README 跑通第一个 Demo，然后挑一个真实的调研需求，试着让这只「深度调研鹿」帮你完成一次完整的研究任务。

# 开源 # 人工智能 # 学习
Logo
AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

cover

Gemini 3.5 办公论文写作实战评测

avatar AtomGit开源社区

从“表皮仿生”到“内生心智”：论通用人工智能的架构缺失与演进路径

当前，以大语言模型为代表的深度学习已展现出惊人的模仿能力，但其背后“表皮仿生”式的路径正触及根本性瓶颈。要让机器真正具备通用智能，我们必须正视那些缺失的拼图，并构想一条从被动工具到主动智能体的进化之路。

avatar AtomGit开源社区
cover

基于边缘计算物联网关的机房动力环境监控系统解决方案！

avatar AtomGit开源社区