Dify系列（一）后台源码总览

原创 Yongtao 2025-07-31

913

dify项目地址

后台代码总览

目录~\dify\api里是dify的后台代码，使用python实现，每个模块内容按文件夹分类如下表所示。

模块（文件夹）	主要职责与功能
configs	配置管理，存放环境变量、默认参数、插件配置等静态或全局配置。
constants	各类全局常量与枚举，如状态码、类型标识、默认值等。
contexts	请求/业务上下文管理，用于在接口层传递状态、用户信息、追踪等上下文数据。
controllers	控制层（Controller），处理外部 HTTP 请求、解析参数、调用服务、返回响应。
core	核心模块实现，包含基础运行时、模型调度以及插件基础设施等功能块（如 model_runtime）。
docker	与 Docker 相关的配置文件，如 `docker-compose.yml`、容器构建和环境部署脚本。
events	事件驱动逻辑，处理系统内异步事件、消息发布/订阅机制、钩子回调等。
extensions	外部插件或扩展机制代码，比如自定义工具、集成外部服务的插件入口。
factories	工厂类/函数，用于根据类型创建服务、存储、模型调用适配器等实例。
fields	数据字段定义与验证逻辑，可能包括 DTO、schema、参数校验类型等。
libs	通用工具库，例如日志、网络请求、加密、通用 util 函数等共享代码。
migrations	数据库迁移脚本，用于创建表、变更 schema、初始化元数据等。
models	ORM 模型定义，与数据库表结构对应，定义实体结构与关系。
repositories	数据访问层（Repository），封装对 ORM 模型的 CRUD 操作、查询逻辑等。
schedule	定时任务调度脚本，如周期性执行的数据清理、任务触发、报告生成等。
services	业务层（Service），包含核心业务逻辑，与 controllers 层交互并治理过程。
tasks	异步任务或后台 worker 逻辑，用于处理长时间运行或需要异步执行的任务。
templates	文本模板、邮件模板、前端渲染模板等用于构建输出内容（如邮件、报告）。
tests	单元测试与集成测试代码，针对 controllers/services/models 等模块进行测试。

目录~\dify\api\core里是dify的后台代码核心部分，使用python实现，每个模块内容按文件夹分类如下表所示。

模块名称	主要职责与功能
agent	实现调度和执行 Agent 逻辑，支持基于 ReAct 或 Function‑calling 的智能代理行为，协调模型和工具调用。
app	定义“应用”运行时机制（如 `BaseAppRunner`），将用户输入映射到自定义流程执行，引导整个应用逻辑流程。
base	提供核心基类和抽象组件，供其他模块继承，比如基础 Runner、执行器等共用逻辑。
callback_handler	管理模型或插件调用的回调机制，处理异步调用结果的回传、状态更新等流程。
entities	定义核心业务实体的数据模型结构（非数据库 ORM），如 Agent 状态、工具接口、节点抽象等。
errors	定义核心错误类型与异常类，用于统一捕获、封装与上报核心层发生的问题。
extension	实现系统扩展机制基础，加载插件、模型 provider 插件、工具或自定义扩展的注册与调度逻辑。
external_data_tool	封装外部数据源读取工具逻辑，如抓取网页、调用外部 API 获取输入，作为 workflow 的输入变量来源。
file	处理与文件相关的通用逻辑，如 upload/download、文件类型检测、文本提取工具封装等。
helper	包含共用工具函数，如数据转换、时间处理、格式化帮助方法等跨模块通用辅助。
llm_generator	执行与 LLM 模型交互的业务逻辑，封装模型调用、生成策略、流式输出等统一接口。
mcp	负责 Model Context Protocol（MCP）相关流程处理（即 ScaleMCP 协议），实现上下文同步、工具交互决策的核心支撑模块。
memory	管理对话或工作流中的记忆机制（如长期短期记忆、上下文缓存、历史记录管理等）。
model_runtime	提供统一的模型调用接口，与不同提供商（OpenAI、Anthropic、Azure、Self‑hosted）交互的鉴权与调用实现。
moderation	实现内容审核模块，对输入/输出文本进行安全过滤、敏感内容拦截或分类判断。
ops	操作监控与运维支持，如调用 traces、日志记录、运行指标汇总等系统观察能力。
plugin	管理自定义插件（工具或模型扩展）逻辑，包括插件加载、配置注册、生命周期调用等。
prompt	Prompt 构建相关逻辑，如模板渲染、变量填充、提示词拼接与构造策略。
rag	RAG（检索增强生成）执行模块，处理索引检索、上下文拼接、文档检索与搭配生成流程。
repositories	和 `api/repositories` 不同，core 下的 repositories 主要管理核心组件元数据缓存、状态储存接口等核心层内部存储逻辑。
tools	内置工具集合（如搜索、算术、APIs 调用工具等），以及调度这些工具调用的封装逻辑。
variables	管理工作流中变量的定义、类型系统、绑定与流转规则，如结果变量、系统变量、用户变量。
workflow	构建执行流程引擎，包括节点（nodes）定义、执行逻辑、错误处理、分支调度等核心工作流调度机制。

以workflowrun为例子说明代码流向

核心组件说明

从用户点击工作流开始运行，到工作流每个节点开始运行的所有代码路径，如下图所示。
dify示意图.png
涉及的模块主要有以下三个：

controllers ：负责接收 /workflows/run 的 HTTP 请求 → 验证输入 → 调用 services；
services ：业务逻辑层，调用核心执行器启动 workflow；
core/workflow ：真正的工作流调度引擎，包括节点分支调度、变量处理、异常处理、执行状态跟踪等核心机制；

代码流向说明

controllers层

代码中controller控制层有两处WorkflowRunApi绑定到flask api上。

（1） service_api部分，对用用户直接命令调用：

bp = Blueprint("service_api", __name__, url_prefix="/v1")
api = ExternalApi(bp)

class WorkflowRunApi(Resource):
    def post(self, app_model: App, end_user: EndUser):

api.add_resource(WorkflowRunApi, "/workflows/run")

（2） web部分，对应用户web页面上操作：

bp = Blueprint("web", __name__, url_prefix="/api")
api = ExternalApi(bp)

class WorkflowRunApi(WebApiResource):
    def post(self, app_model: App, end_user: EndUser):

api.add_resource(WorkflowRunApi, "/workflows/run")

services层

WorkflowRunApi.post() 函数将要调用services业务层的AppGenerateService.generate()。
AppGenerateService.generate()调用core核心层的WorkflowAppGenerator.generate()。

core层

WorkflowAppGenerator.generate()->_generate()->_generate_worker()调用WorkflowAppRunner.run()调用WorkflowEntry.run()。GraphEngine.run()调用BaseNode.run()，调度到10来种类型的Node。

dify源码

「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」

关注作者

文章被以下合辑收录

Dify源码（共1篇）

Dify源码阅读