Dify 源码解析 (一)：架构总览——从 MVP 到生产级 Agent 平台的演进

最新推荐文章于 2025-11-24 21:27:43 发布

原创最新推荐文章于 2025-11-24 21:27:43 发布 · 83 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#架构

python 同时被 3 个专栏收录

67 篇文章

订阅专栏

源码分析

39 篇文章

订阅专栏

架构设计

13 篇文章

订阅专栏

前言

在 LLM 应用开发领域，Dify 无疑是目前最耀眼的开源项目之一。短短时间内斩获 120k+ Stars，Dify 已经不仅仅是一个简单的 Prompt 管理工具，而是演进成了一个涵盖 RAG 管道、Agent 工作流编排、LLMOps 以及 BaaS（后端即服务） 的全能型平台。

很多开发者在使用 Dify 时惊叹于其功能的完整性，但往往对其内部实现感到好奇：

它是如何统一管理上百种不同模型的？
复杂的 Agent 工作流（Workflow）是如何被调度和执行的？
RAG 的切片和检索策略在代码层面是如何落地的？

本系列文章将深入 Dify (v0.6.x - v0.10.x) 源码，剥开它的外壳，从架构设计到核心代码实现，带你彻底理解这个生产级 LLM 平台的构建之道。

作为系列开篇，我们将从上帝视角俯瞰 Dify 的整体架构，理清其技术栈、目录结构以及核心的数据流转机制。

1. 技术栈概览：典型的现代 Web 架构

Dify 采用了一个非常务实且经典的前后端分离架构。它没有过度追求微服务化，而是采用了一种**模块化单体（Modular Monolith）**的策略，这在快速迭代的 AI 产品中是非常明智的选择。

组件	技术选型	作用
前端 (Frontend)	Next.js, React, Tailwind CSS	提供 WebApp (用户端) 和 Console (管理端) 的交互界面。
后端 (Backend)	Python 3.10+, Flask	核心业务逻辑、API 接口暴露。
异步队列 (Queue)	Celery, Redis	处理耗时任务（如 RAG 索引构建、批量任务、邮件发送）。
数据库 (DB)	PostgreSQL	存储应用配置、用户数据、知识库元数据、日志等。
缓存/PubSub	Redis	缓存热点数据，以及用于 SSE (Server-Sent Events) 流式输出的消息发布订阅。
向量数据库	Weaviate / Qdrant / Milvus / PGVector	存储知识库的向量数据（通过抽象层支持多种）。
ORM	SQLAlchemy	Python 层的数据库操作。

架构师视角的点评：

Dify 选择了 Python 作为后端核心，这是毫无疑问的，因为 Python 是 AI 领域的“第一公民”。使用 Flask 而非 FastAPI，可能是因为 Dify 项目启动较早，或者团队更看重 Flask 生态在复杂 Web 应用（如鉴权、插件扩展）上的成熟度。而 Celery 的引入至关重要，因为 LLM 推理和 Embeddings 生成都是高延迟操作，必须通过异步解耦来保证 HTTP 服务的响应速度。

2. 目录结构全景图

Clone 下代码库后，你会看到一个庞大的结构。以下是核心目录的“藏宝图”：

Plaintext

dify/
├── api/                  # [核心] Python 后端代码，Dify 的大脑
│   ├── controllers/      # RESTful API 控制器 (Web 路由入口)
│   ├── core/             # [最重要] 核心业务逻辑 (Model, RAG, Agent, Workflow)
│   ├── events/           # 事件处理
│   ├── extensions/       # 扩展组件 (DB, Redis, Celery 初始化)
│   ├── models/           # SQLAlchemy 数据模型定义
│   ├── services/         # 业务服务层 (连接 Controller 与 Core)
│   ├── tasks/            # Celery 异步任务定义
│   └── app.py            # Flask 应用入口
├── web/                  # 前端代码 (Next.js)
├── docker/               # Docker Compose 部署配置
├── sdks/                 # 客户端 SDK (Python, JS)
└── ...

重点关注：`api/core`

这是 Dify 的灵魂所在。在该目录下，你会发现以下关键模块：

model_runtime/: 统一了 OpenAI, Anthropic, Llama 等百模千态的调用接口。
rag/: 实现了 ETL、清洗、切分、Embedding 和检索（Retrieval）逻辑。
workflow/: 包含工作流引擎的 DSL 解析、节点执行与拓扑排序算法。
agent/: 智能体的推理策略（ReAct, Function Calling）实现。

3. 核心架构逻辑：请求是如何流转的？

为了理解架构，我们跟踪一个典型的 “用户发送 Chat 消息” 的生命周期。这个过程展示了 Dify 如何处理流式响应和长链接。

阶段一：HTTP 请求与鉴权

前端发起：用户在界面输入问题，前端通过 POST /chat-messages 发起请求。
Flask 入口：api/controllers/service_api 接收请求。
鉴权 (Passport)：验证 API Key 或 JWT Token，确定当前租户（Tenant）和应用（App）身份。

阶段二：编排与执行 (Orchestration)

Service 层：ChatService 被调用，它负责组装上下文，判断是“对话型应用”还是“工作流应用”。
Core 层介入：
- 如果是 基础 Chat：调用 ModelManager，组装 Prompt（包含 System Prompt, History, RAG Context），向 LLM 发起请求。
- 如果是 Workflow：实例化 WorkflowEngine，解析图结构，按照拓扑顺序通过 Runner 执行每个 Node。

阶段三：流式响应 (Streaming Response)

这是 LLM 应用最特殊的地方。Dify 不会等待 LLM 生成完所有文字才返回，而是利用 Server-Sent Events (SSE)。

Generator 生成：core 层将 LLM 返回的 chunk 封装成统一的事件格式（如 message、agent_thought、error）。
Redis Pub/Sub (可选)：在某些复杂的异步场景下，任务状态会推送到 Redis。
Flask Yield：Controller 层通过 Python 的 yield 关键字，将生成器的数据源源不断地推向前端。