Multi-Agent 多智能体架构解析–DeerFlow

在人工智能技术快速演进的当下，Multi-Agent（多智能体） 架构因其对 复杂任务 的高效协作能力，正成为驱动 AI 应用突破的核心引擎。这一技术的爆发式增长与大语言模型的局限性密切相关 —— 尽管大模型在单一场景表现优异，但面对跨领域、多步骤的现实任务时，仍需通过多智能体的分工协作实现突破。例如，旅行规划场景中，航班预订、酒店推荐、行程优化等子任务可由不同智能体并行处理，效率远超单一模型。这种架构不仅解决了传统 AI 系统的「决策孤岛」问题，更通过动态协作机制（如星型拓扑与群组聊天模式），显著提升了复杂系统的灵活性与鲁棒性。

在众多 Multi-Agent 技术实践中，开源框架以其开放性和灵活性成为推动技术落地的重要力量。它们不仅降低了开发门槛，更通过社区协作加速了技术迭代。今天，我们将以 Deerflow 这一 多智能体协同开源框架 为例，深入探索 Multi-Agent 技术在工程实践中的核心奥秘。

本文将结合 Deerflow 官方文档与代码实现，系统剖析 Deerflow 多智能体协同工作机制及数据流转逻辑。为清晰呈现各 Agent 的任务分工体系，文中将重点提炼每个智能体的核心提示词设计。无论是探究智能体协作原理的技术研究者、致力于 Agent 落地开发的工程人员，还是专注于提示词优化的 Prompt 工程师，均可通过本文深入理解 Deerflow 的协同工作范式与提示词工程实践。

• 架构总览
• coordinator（协调器）
• planner（规划器）
• research_team（研究团队）
• reporter（报告员）

DeerFlow 是字节跳动于 2025 年 5 月 9 日开源的多智能体深度研究框架，旨在通过人工智能技术简化科研和内容创作流程。

DeerFlow 采用了 Multi-Agent 的架构设计，通过多个Agent之间的相互协作，来实现通用Agent的功能，并完成用户报告的最终解答。在 DeerFlow 公开的架构设计图中，主要使用了四个Agent来进行协同。

• coordinator（协调器）：管理工作流生命周期的入口点
• planner（规划器）：负责任务分解和规划的战略组件
• research_team（研究团队）：执行计划的专业智能体集合
• reporter（报告员）：研究输出的最终阶段处理器

接下来我们将基于官方释义与代码实现展开深入剖析，一同探究其具体实现逻辑。

当用户提出一个任务的时候，首先会调用后台的 chat_stream 方法，并且借由 _astream_workflow_generator 函数构建整个多Agent协同的工作流。

然后将用户输入的问题直接交给 coordinator 来进行处理。

代码中可以看到，coordinator_node 通过获取名为 coordinator 的 prompt 来构建Agent，我们可以通过查看 prompt 中的核心内容（部分prompt，非全部），来了解一下 coordinator 的职能。

Deerflow 对于 coordinator 要做的事情主要进行了 三个定义，如果是简单对话，那么直接进行答复，如果含有攻击意图或者有害信息的请求，直接进行拒绝，否则的话，移交给 planner 进行操作。

在 coordinator 代码的结尾（上图），我们可以看到，默认下一步就是 planner （上图中的 goto=planner）。但是如果用户选择了Investigation_mode 模式，那么在交给 planner 之前，会先调用 background_investigation_node 方法进行一次联网搜索，以方便 planner 能够进行更好的规划（goto=background_investigation）。也就是下图中，用户在交互的时候选择 Investigation_mode 为开启状态。

background_investigation_node 节点没有与大模型进行交互，只有简单的信息检索，部分代码如下。

初步信息检索完成后，会将查询后的信息以及用户的问题一起交给 planner，进行任务规划。

上图中我们看到，planner_node 加载了名为 planner 的 prompt，我们同样将 planner 中的部分核心内容摘出来，来看看 planner 的具体职责。

planner 被要求，在出具计划之前，必须要严格了解用户的问题，有充足的信息支撑才可以出具计划，否则的话，会通过与用户的多轮对话来进行信息的补全。如果 planner 分析下来，觉得回答用户的问题已经有足够的信息了，那么就会将 has_enough_context 设置为 true，后续不会移交研究团队，直接生成报告（下图中，goto=reporter）。

如果信息不充分，则会流转到 human_feedback_node，进行人工计划确认（下图中，goto=human_feedback）。

人工确认完成后，会流转到 research_team，由研究团队进行数据收集（下图中，goto=research_team）。

对于研究团队中的每一个研究员，会使用 researcher 的 prompt 执行任务。

我们同样将研究员的 prompt 部分核心内容 摘出来，看看研究员是如何工作的。

可以看到，研究员被要求 不能使用自己的知识 进行作答，需要通过 合理使用工具来进行信息搜索，并且要进行信息的整合，确保信息的有效性。在上图的 _setup_and_execute_agent_step 方法中，会通过 mcp 调用提供的工具，以完成信息检索任务。信息查询完成后，任务会再次 流转回到 planner，让 planner 来判断信息是否已经全面。如果认为信息不全面，则继续查询，否则，则调用 reporter 进行报告输出。如果忘记 planner 的逻辑，可以再看看上面 planner 那一趴。

下图中的方法 continue_to_running_research_team，是在研究员任务完成后调用的，可以看到任务会继续流转回 planner。

进入 reporter 以后，就算进入了整个流程的最后阶段。reporter 会将所有的信息，包括用户问题、执行计划、搜索结果全部进行整合，然后按照 reporter prompt 的任务要求，给与用户反馈。

最终的输出，会参考用户在前端界面选择的 输出风格 进行调整，包括学术风格、科普风格 以及 小红书风格 等等。

reporter 输出风格的 prompt 如下

reporter 的 prompt 还规定了文章的输出格式、以及常见输出用语等等，这里内容比较多，以小红书举例，可以看下输出标准。

此外，整个 Deerflow 还整合了多种工具类 Agent，例如 生成代码的 coder。

专门用于生成 ppt 的 ppt_composer 等。

所有的 Agen t全部在构建流程图的时候全部装入了整个流程中，然后在后续执行的时候互相进行协调。

若你对 AI 技术烙（如模型开发、NLP 应用、行业落地等）感兴趣，欢迎✉️私信我～

拉你进专属交流群，和技术大牛们面对面深度探讨、互换经验！