
在实际 AI 应用开发中从想法到上线往往需要跨越多个技术栈前端界面、后端服务、大模型 API 调用、提示词工程、知识库构建、工作流编排等。对于中小团队或个人开发者而言这通常意味着需要投入大量精力在基础设施搭建和不同组件的集成上而非专注于核心业务逻辑。Dify 的出现正是为了解决这一痛点。它是一个开源的 LLM 应用开发平台其核心目标是让开发者能够通过可视化、低代码的方式快速构建和部署 AI 驱动的应用程序。Dify 由中国团队开发并开源其设计理念是“AI for Everyone”。它提供了一个直观的图形化界面允许开发者通过拖拽组件来构建复杂的 AI 应用工作流而无需编写大量胶水代码。更重要的是它宣称支持数百个大型语言模型LLM这意味着你可以灵活地在 OpenAI GPT、Anthropic Claude、国内大模型或开源模型之间切换而无需重构应用逻辑。本文将带你从零开始完成 Dify 的本地部署、核心概念理解、一个简单 AI 应用的搭建并深入探讨其配置细节、常见问题排查以及生产环境的最佳实践。1. 理解 Dify 的核心概念与架构在动手部署和操作之前我们需要先理解 Dify 的几个核心抽象这有助于我们后续更高效地使用它。1.1 应用、工作流与智能体Dify 将 AI 应用分为几种主要类型每种类型对应不同的构建模式对话型应用类似于 ChatGPT 的聊天界面适用于客服、问答、聊天机器人等场景。你可以定义系统提示词、上下文长度、对话开场白等。文本生成型应用根据用户输入生成特定格式或内容的文本如文章写作、邮件起草、代码生成等。工作流这是 Dify 最强大的功能之一。它允许你将多个处理节点如 LLM 调用、知识库检索、代码执行、条件判断等通过可视化的画布连接起来形成一个复杂的处理流水线。这非常适合需要多步骤推理、数据加工或外部工具调用的场景。智能体可以理解为具备特定能力和目标的“AI 员工”。它通常由工作流驱动可以自主调用工具如搜索、API、数据库查询来完成复杂任务。理解这些类型的区别能帮助你在创建新应用时选择正确的起点。1.2 模型供应商与模型Dify 的核心优势之一是其对多模型的支持。在 Dify 中你需要先配置“模型供应商”然后才能使用具体的“模型”。模型供应商指的是提供模型服务的平台或接口例如 OpenAI、Azure OpenAI、Anthropic、智谱 AI、百度千帆、通义千问、Ollama用于本地开源模型等。配置供应商通常需要提供 API Key 和 Base URL。模型在已配置的供应商下选择具体的模型如gpt-4-turbo-preview、claude-3-opus-20240229、qwen-max等。Dify 会将这些模型统一抽象为可调用的组件。这种分层设计使得切换模型变得非常简单你只需要在应用或工作流的 LLM 节点中更换模型名称而无需改动任何调用代码。1.3 知识库Dify 内置了知识库功能允许你将文档TXT、PDF、Word、PPT、Markdown 等上传并进行向量化处理。处理后的知识库可以接入到对话应用或工作流中为 LLM 提供额外的、私有的上下文信息从而实现基于文档的精准问答。其底层通常依赖于向量数据库如 Milvus、PGVector、Qdrant来存储和检索嵌入向量。1.4 可视化画布可视化画布是构建工作流的核心界面。你可以从左侧拖拽各种节点如 LLM、知识库检索、条件判断、变量赋值、HTTP 请求等到画布上并用连线定义数据流。每个节点都有其输入和输出端口数据沿着连线从一个节点传递到另一个节点。这种方式极大地降低了构建复杂 AI 逻辑的门槛。2. 环境准备与本地部署我们将以在 Linux/macOS 系统上使用 Docker Compose 部署 Dify 为例这是官方推荐且最简单的方式。Windows 用户可以通过 WSL2 获得类似的体验。2.1 系统与环境要求在开始之前请确保你的环境满足以下最低要求组件最低要求推荐配置说明操作系统Linux, macOS, Windows (WSL2)Linux生产环境建议使用 Linux。Docker20.10最新稳定版确保 Docker 守护进程正在运行。Docker Compose2.0最新稳定版通常包含在 Docker Desktop 中Linux 需单独安装。CPU2 核4 核或以上向量化等操作对 CPU 有要求。内存4 GB8 GB 或以上运行多个容器和模型需要足够内存。磁盘20 GB 可用空间50 GB SSD用于存储镜像、数据库和上传的文档。通过以下命令检查 Docker 和 Docker Compose 版本docker --version docker-compose --version2.2 获取部署文件官方提供了集成的docker-compose.yaml文件它包含了 Dify 后端 API、前端 Web 界面、数据库PostgreSQL、缓存Redis和向量数据库默认为 Weaviate可选等所有必需服务。创建一个专用的项目目录并进入mkdir dify cd dify下载最新的docker-compose.yaml文件curl -o docker-compose.yaml https://raw.githubusercontent.com/langgenius/dify/main/docker/docker-compose.yaml可选下载环境变量配置文件模板curl -o .env https://raw.githubusercontent.com/langgenius/dify/main/docker/.env.example2.3 关键配置说明在启动前理解docker-compose.yaml和.env文件中的关键配置非常重要。我们主要关注.env文件。打开或创建.env文件你需要修改以下几项# 数据库配置 POSTGRES_PASSWORDdifyai123456 # 修改为一个强密码 POSTGRES_DBdify POSTGRES_USERpostgres # Redis 配置 REDIS_PASSWORDdifyai123456 # 修改为一个强密码 # Dify 核心配置 SECRET_KEYyour-secret-key-please-change # 必须修改用于加密会话等 # 外部访问地址如果是本地访问可以设置为 http://localhost CONSOLE_API_URLhttp://localhost:3001 CONSOLE_WEB_URLhttp://localhost:3000 APP_API_URLhttp://localhost:3001 # 向量数据库配置默认使用内置的 Weaviate WEAVIATE_ENABLEDtrue # 如果你想使用其他向量库如 Qdrant需要禁用 Weaviate 并配置对应连接 # WEAVIATE_ENABLEDfalse # VECTOR_STOREqdrant # QDRANT_URLhttp://qdrant:6333注意SECRET_KEY、POSTGRES_PASSWORD、REDIS_PASSWORD是安全关键项务必在生产环境中设置为复杂且唯一的随机字符串。2.4 启动 Dify 服务配置好.env文件后使用 Docker Compose 启动所有服务docker-compose up -d-d参数表示在后台运行。首次执行会从 Docker Hub 拉取镜像可能需要几分钟时间。启动后可以使用以下命令查看容器状态docker-compose ps如果所有服务状态均为Up则部署成功。2.5 访问与初始化打开浏览器访问http://localhost:3000对应CONSOLE_WEB_URL。首次访问会进入初始化页面你需要设置管理员账号邮箱和密码。登录后即可进入 Dify 控制台。至此Dify 平台本身已经就绪。接下来我们需要为其“注入灵魂”——配置大模型。3. 配置模型供应商与构建第一个 AI 应用平台本身没有推理能力必须接入一个 LLM 服务才能工作。3.1 配置 OpenAI 模型供应商我们以最通用的 OpenAI 为例。你需要准备一个有效的 OpenAI API Key。登录 Dify 控制台点击左侧导航栏底部的“设置”。选择“模型供应商”标签页。点击“添加模型供应商”在列表中找到“OpenAI”并点击。在配置页面中供应商名称可自定义如My-OpenAI。API Key填入你的 OpenAI API Key。API Base URL如果你使用官方接口留空即可。如果你使用第三方代理或 Azure OpenAI需要填写对应的端点地址。点击“保存”。保存成功后页面下方会显示该供应商下可用的模型列表如 gpt-3.5-turbo, gpt-4 等。3.2 创建一个简单的文本生成应用现在我们来创建一个能生成小红书风格文案的应用。在控制台首页点击“创建新应用”。选择“文本生成型应用”输入应用名称如小红书文案助手。进入应用编排界面。核心区域是“提示词编排”。在“系统提示词”区域输入以下内容你是一个擅长撰写小红书爆款文案的专家。请根据用户提供的产品名称和特点生成一篇吸引人的小红书笔记。 笔记需要包含 1. 一个吸引眼球的标题带2-3个相关标签。 2. 正文部分要口语化、亲切多用感叹号和表情符号如 、、✨。 3. 突出产品的核心卖点和使用场景。 4. 在结尾添加互动话术例如“大家觉得怎么样”或“有没有用过的姐妹来聊聊”。在右侧的“模型与参数”区域模型供应商选择刚才配置的My-OpenAI。模型选择gpt-3.5-turbo成本较低适合测试。可以调整温度temperature控制创造性和最大生成长度等参数。点击右上角的“发布”。发布后应用会生成一个独立的访问链接。3.3 测试与调试发布后点击顶部菜单的“体验”标签页。在聊天窗口输入“请为‘便携式榨汁杯’写一篇文案特点是无线充电、30秒出汁、易清洗。”点击发送观察 AI 返回的文案是否符合“小红书风格”的要求。如果效果不理想可以返回“编排”标签页调整系统提示词或模型参数再次发布和测试。这个简单的例子展示了 Dify 的基础工作流配置模型 - 编排提示词 - 发布测试。接下来我们探索更强大的功能。4. 使用可视化画布构建复杂工作流工作流允许你将多个步骤串联起来。我们构建一个“智能客服路由”工作流根据用户问题类型决定是调用知识库回答还是转接给人工或者直接由 LLM 处理。4.1 创建工作流并添加节点在控制台点击“创建工作流”命名为智能客服路由。进入画布编辑器。默认会有一个“开始”节点和一个“结束”节点。从左侧节点库拖拽节点到画布LLM节点用于判断问题类型。知识库检索节点用于查询已知问题。代码节点可以模拟一些逻辑处理此例中我们用条件判断节点更好。条件判断节点根据 LLM 的判断结果走不同分支。再拖两个LLM节点一个用于生成基于知识库的回答一个用于直接回答通用问题。回答节点用于输出最终结果。4.2 连接节点与配置逻辑连接流程用连线将节点按逻辑顺序连接起来。例如开始-LLM(问题分类)-条件判断。配置“问题分类” LLM 节点连接开始节点的query输出端口到此节点的query输入端口。在节点配置中编写提示词例如“请判断用户问题属于以下哪一类1. 产品使用问题A类2. 价格与订单问题B类3. 闲聊或通用咨询C类。只输出字母 A、B 或 C。”配置好模型供应商和模型。配置“条件判断”节点连接上一个 LLM 节点的输出端口到此节点的输入端口。在节点配置中设置分支条件。例如条件1变量选择问题分类节点的输出运算符选择等于值填写A。输出端口可命名为to_knowledge_base。条件2值等于B端口命名为to_human。条件3值等于C端口命名为to_llm。配置分支处理将to_knowledge_base端口连接至“知识库检索”节点再连接一个LLM生成答案节点最后连接到“回答”节点。在生成答案的 LLM 节点中提示词应包含知识库检索到的上下文。将to_llm端口直接连接到一个LLM通用回答节点再连接到“回答”节点。将to_human端口直接连接到“回答”节点并在回答节点中配置一个固定回复如“您的问题需要人工客服协助正在为您转接...”。配置“回答”节点确保所有最终分支都汇聚到此节点。它可以配置一个统一的输出格式。4.3 运行与测试工作流点击画布右上角的“保存”。点击“运行”按钮在右侧的调试面板中输入测试问题例如“这个杯子怎么清洗”点击“运行”你可以清晰地看到数据流经过每个节点的过程和中间结果。这对于调试复杂逻辑至关重要。通过这个工作流你可以直观地感受到 Dify 如何将复杂的业务逻辑可视化而无需编写繁琐的if-else代码和 API 调用链。5. 知识库的创建与集成知识库是让 AI 应用具备“专业知识”的关键。5.1 创建并填充知识库在控制台左侧导航栏点击“知识库”-“创建知识库”。输入名称如产品手册选择嵌入模型通常使用默认的text-embedding-ada-002或开源模型。创建后进入知识库详情页点击“上传文件”或“同步网站内容”。支持批量上传 TXT、PDF、Word、Markdown 等格式。上传后Dify 会自动进行文本分割、向量化并存储到向量数据库。你可以在“文档管理”中查看处理状态。5.2 在应用或工作流中调用知识库有两种主要集成方式在对话/文本型应用中在“编排”页面的“上下文”部分勾选“启用知识库”并选择你创建的知识库。这样用户每次提问系统都会先从知识库中检索相关片段再连同问题和片段一起发送给 LLM 生成答案。在工作流中使用“知识库检索”节点。如上节示例你可以将检索到的上下文变量{{#context#}}插入到后续 LLM 节点的提示词中。5.3 知识库处理参数解析上传文档时有几个关键参数影响检索效果参数说明推荐值/策略分段处理规则如何将长文档切分成片段。按字符/标点分割避免在句子中间切断。通常默认即可。文本清洗是否移除冗余的换行符、空格等。建议开启使文本更规整。索引方式如何建立向量索引。“高精度”模式检索质量更高“经济”模式更快更省资源。根据需求选择。召回数量每次检索返回的文本片段数量。通常 2-5 个。太少信息不全太多可能引入噪声。6. 生产环境部署考量与最佳实践本地 Docker Compose 部署适合开发和测试。要用于生产需要考虑更多因素。6.1 部署架构升级官方 Docker Compose 将所有服务打包在一起适合单机。生产环境建议分离服务将 PostgreSQL、Redis、向量数据库如 Qdrant部署为独立的、可扩展的集群服务。部署 Dify 后端/前端可以将api和worker服务部署在 Kubernetes 或通过反向代理如 Nginx进行负载均衡。使用外部存储将上传的文件存储在对象存储如 AWS S3、MinIO中而非本地磁盘。配置域名与 HTTPS通过 Nginx 或云负载均衡器配置域名并启用 SSL/TLS。6.2 配置与安全环境变量确保所有密码、密钥SECRET_KEY,POSTGRES_PASSWORD,REDIS_PASSWORD, 各模型 API Key都通过安全的秘密管理方式注入而不是硬编码在文件中。数据库备份为 PostgreSQL 建立定期备份策略。访问控制Dify 自身有用户角色管理员、普通用户。在生产中应结合企业 SSO 或更严格的网络 ACL 来控制控制台的访问。日志与监控配置 Docker 或系统的日志收集如 ELK Stack并监控各服务的资源使用情况CPU、内存、磁盘和健康状态。6.3 性能与成本优化模型选型在测试期使用低成本模型如 GPT-3.5-Turbo在关键生产流程中使用高性能模型如 GPT-4。Dify 允许你在不同节点使用不同模型。缓存策略对于相似度高的重复查询可以考虑在应用层或利用 Redis 实现回答缓存减少对 LLM API 的调用和成本。异步处理对于耗时的操作如知识库文档处理、长文本生成确保使用异步任务队列Dify 的worker服务负责此部分避免阻塞 Web 请求。向量数据库优化根据知识库的规模和查询频率选择合适的向量数据库并对其进行性能调优和索引优化。7. 常见问题排查在开发和运维 Dify 过程中你可能会遇到以下典型问题。7.1 部署与启动问题问题现象可能原因检查与解决步骤docker-compose up失败提示端口冲突。3000、3001、5432、6379 等端口被占用。1. 使用lsof -i:端口号或netstat -tulnp查看占用进程。2. 修改docker-compose.yaml中的宿主机端口映射如3000:3000改为8080:3000。访问localhost:3000无法连接。容器启动失败或仍在初始化。1. 运行docker-compose logs -f查看所有容器日志寻找 ERROR 信息。2. 常见问题数据库连接失败检查.env密码、内存不足、镜像拉取失败。知识库文档一直显示“处理中”。向量化进程worker服务异常或嵌入模型 API 不可用。1. 检查docker-compose logs worker -f日志。2. 确认模型供应商配置正确且 API Key 有效、额度充足。3. 检查网络连接确保能访问嵌入模型 API 端点。7.2 应用运行问题问题现象可能原因检查与解决步骤应用提示“模型服务不可用”或超时。1. 模型供应商配置错误或 API Key 失效。2. 网络问题导致无法访问模型 API。3. 模型额度用尽或频率超限。1. 在“设置 - 模型供应商”中测试连接。2. 在服务器上使用curl测试模型 API 端点是否可达。3. 登录对应模型供应商控制台检查额度和用量。知识库检索结果不相关。1. 文档分割不合理导致上下文碎片化。2. 嵌入模型不匹配或质量差。3. 检索的 Top-K 参数设置不当。1. 调整知识库的分段规则尝试不同的分割大小和重叠度。2. 尝试更换不同的嵌入模型如从text-embedding-ada-002换为text-embedding-3-small。3. 在知识库检索节点中调整“召回数量”和“相似度阈值”。工作流运行卡在某个节点。1. 节点配置错误如变量名引用错误。2. 外部 API 调用失败。3. 条件判断逻辑有误导致流程无法继续。1. 使用工作流的“调试”模式查看每个节点的输入/输出定位问题节点。2. 检查代码节点或 HTTP 请求节点的语法和网络连通性。3. 复核条件判断节点的逻辑条件设置。7.3 配置与数据问题如何更新 Dify进入项目目录拉取最新的docker-compose.yaml和.env.example合并配置变更然后执行docker-compose pull拉取新镜像最后docker-compose up -d重启服务。务必先备份数据库。数据存在哪里PostgreSQL 数据存储在名为dify-db的 Docker 卷中文件在宿主机的 Docker 存储目录下。可以通过docker volume inspect dify-db找到具体路径。如何迁移数据需要备份 PostgreSQL 数据库使用pg_dump和 Redis 数据如果需要然后在新的环境中恢复。Dify 通过将 LLM 应用开发的通用模式抽象为可视化组件显著降低了开发门槛。从快速原型验证到构建复杂的企业级 AI 工作流它提供了一个统一的平台。成功上手的核心在于理解其“模型供应商-应用-工作流-知识库”的层次结构并善用画布来编排逻辑。对于生产部署务必关注安全性、可观测性和成本管理。接下来你可以尝试将 Dify 与你自己的业务系统通过 API 集成或者探索其插件系统来扩展更多自定义功能。