30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度如果你正在寻找一个能让你快速构建、部署和管理 AI 应用尤其是 Agentic 工作流的平台那么 Dify 绝对值得你花时间深入了解。它不是一个简单的模型调用工具而是一个开箱即用的生产级 AI 应用开发平台由 LangGenius 团队开源和维护。简单来说Dify 让你能用拖拽的方式像搭积木一样组合大模型、知识库、工具和逻辑最终生成一个可独立运行的 Web 应用或 API 服务。这篇文章将带你从零开始手把手完成 Dify 的本地部署、核心功能上手并重点剖析其强大的工作流Workflow能力。我们会避开那些华而不实的介绍直接聚焦于实操如何安装、如何配置、如何构建你的第一个 AI 应用以及在实际使用中可能遇到的坑和解决方案。无论你是想快速验证一个 AI 产品想法还是希望为团队搭建一个内部 AI 工具Dify 都能大幅降低你的开发门槛。1. 核心能力速览在深入细节之前我们先通过一个表格快速了解 Dify 的核心特性让你判断它是否适合你的需求。能力项说明项目类型开源 AI 应用开发平台支持无代码/低代码构建。核心功能Agentic 工作流可视化编排、RAG Pipeline知识库问答、模型集成、应用发布与监控。开源团队LangGenius项目在 GitHub 上非常活跃。硬件门槛极低。Dify 服务本身资源消耗很小普通云服务器即可主要资源消耗取决于你接入的模型如本地部署的 LLM。启动方式支持 Docker 一键部署、源码部署提供 Web 管理界面。是否支持 API是。构建的应用可提供 API 接口也支持将应用发布为 MCP Server。是否支持批量任务是。通过工作流可以轻松设计并行或串行的批量处理逻辑。模型支持全面。支持 OpenAI、Azure、 Anthropic、国内主流模型以及通过 OpenAI 兼容接口接入的本地模型如 Ollama、本地部署的 Qwen 等。适合场景快速原型验证、企业内部 AI 工具开发、构建复杂的多步骤 AI 智能体Agent、知识库问答系统、AI 应用商业化部署。简单总结Dify 的核心价值在于将 AI 应用的构思、开发、部署、监控整合到一个可视化平台中让你无需从零搭建后端和前端就能快速产出可交付的 AI 产品。2. 适用场景与使用边界在投入时间学习之前明确 Dify 能做什么、不能做什么至关重要。Dify 非常适合以下场景快速验证 AI 产品想法你有一个利用大模型的创意比如智能客服、内容生成助手、数据分析报告生成器想快速做出一个可交互的 Demo 给客户或团队看。构建企业内部 AI 工具例如一个连接了公司内部知识库的问答机器人或是一个自动处理工单并分类的流程。开发复杂的多步骤 AI 智能体Agent需要模型进行多轮思考、调用工具如搜索、计算、查询数据库、并根据结果决定下一步行动的复杂场景。Dify 的工作流功能为此而生。需要集成 RAG检索增强生成想让模型基于你提供的专属文档PDF、Word、网页等进行回答Dify 提供了完整的知识库构建、嵌入、检索流水线。希望集中管理 AI 应用在一个平台上管理多个不同的 AI 应用统一监控使用量、日志和性能。Dify 可能不是最佳选择或需要注意的边界对前端 UI 有极高定制化需求Dify 生成的应用界面是标准化的。虽然可以一定程度定制但如果你需要完全独特的交互设计可能需要自行开发前端仅使用 Dify 的 API。超大规模、超高并发的生产场景虽然 Dify 定位生产级但超大规模部署需要专业的运维团队进行架构优化和集群部署。完全离线的纯本地环境Dify 服务本身可以离线部署但其 Marketplace 中的一些插件或模型可能需要网络连接。核心的模型接入如本地 Ollama可以完全离线。版权与合规使用 Dify 构建应用时你接入的模型、处理的数据需确保拥有合法授权。特别是处理用户上传的文档时需注意隐私和数据安全。3. 环境准备与前置条件开始部署前请确保你的环境满足以下基本要求。Dify 的部署非常灵活这里我们以最常见的Docker 部署方式为例这也是官方推荐的方式。基础要求操作系统Linux (Ubuntu 20.04/CentOS 7), macOS, 或 Windows (WSL2 推荐)。生产环境建议使用 Linux。Docker Docker Compose这是必须的。确保已安装并运行正常。硬件资源CPU2 核以上。内存4 GB 以上建议 8 GB。磁盘空间至少 10 GB 可用空间用于存放镜像、数据库和向量数据库。网络能够访问 Docker Hub 和 GitHub 以下载镜像。如果需要接入在线模型 API如 GPT-4则需要稳定的网络连接。可选准备用于接入模型本地大模型如果你打算使用本地模型如通过 Ollama 部署的 Qwen、Llama 等需要提前准备好模型文件并确保有足够的 GPU/CPU 内存。云模型 API Key如果你使用 OpenAI、Azure OpenAI、DeepSeek 等在线服务需要准备好相应的 API Key。检查 Docker 环境是否就绪# 检查 Docker 版本 docker --version # 检查 Docker Compose 版本 docker-compose --version # 运行一个测试容器 docker run hello-world如果以上命令都能成功执行说明环境准备就绪。4. 安装部署与启动方式我们将使用最快速的 Docker Compose 方式部署 Dify。整个过程大约需要 5-10 分钟。步骤 1获取部署文件在服务器或本地电脑上创建一个工作目录例如dify并进入该目录。mkdir dify cd dify从官方仓库下载docker-compose.yaml配置文件# 使用 curl 下载如果系统没有 curl可使用 wget curl -O https://raw.githubusercontent.com/langgenius/dify/main/docker/docker-compose.yaml # 或者使用 wget # wget https://raw.githubusercontent.com/langgenius/dify/main/docker/docker-compose.yaml步骤 2启动 Dify 服务直接使用 Docker Compose 启动所有服务包括后端、前端、数据库等# 在后台启动所有服务 docker-compose up -d这个命令会拉取所需的 Docker 镜像包括 PostgreSQL、Redis、Dify 后端和前端等并启动容器。首次运行需要下载镜像时间取决于你的网速。步骤 3检查服务状态启动完成后检查容器是否正常运行docker-compose ps你应该看到类似下面的输出所有服务的状态State都应为Up。Name Command State Ports ---------------------------------------------------------------------------------------------------- dify-api /bin/bash /entrypoint.sh Up 5001/tcp dify-db docker-entrypoint.sh postgres Up 5432/tcp dify-frontend /docker-entrypoint.sh ngin ... Up 0.0.0.0:80-3000/tcp dify-redis docker-entrypoint.sh redis ... Up 6379/tcp dify-weaviate /bin/weaviate --host 0.0. ... Up 8080/tcp步骤 4访问 Dify 控制台服务启动后打开你的浏览器访问本地访问http://localhost服务器访问http://你的服务器IP地址你将看到 Dify 的初始化页面。按照指引完成管理员账号的注册即可进入主控制台。至此Dify 平台已经安装并运行成功。整个过程几乎是一键式的无需复杂的配置。5. 功能测试与效果验证构建你的第一个 AI 应用平台跑起来了我们立刻来验证它的核心功能。我们将通过创建一个简单的“智能翻译与摘要”工作流来体验 Dify 的核心操作。5.1 创建应用并选择工作流登录 Dify 控制台点击“创建应用”。输入应用名称例如“智能内容处理器”应用类型选择“工作流”。工作流是 Dify 最强大的功能允许你通过节点拖拽构建复杂逻辑。点击“创建”进入工作流画布。5.2 搭建一个简单工作流我们的目标是用户输入一段中文文本工作流先将其翻译成英文再对英文内容进行摘要。步骤 1添加开始节点画布上默认有一个“开始”节点。点击它在右侧配置“变量”。我们添加一个名为input_text类型为“字符串”的变量作为用户输入。步骤 2添加 LLM 节点翻译从左侧节点库中拖拽一个“LLM”节点到画布。将其连接到“开始”节点。模型选择在节点配置中选择你已配置的模型。例如可以选择“OpenAI GPT-3.5-Turbo”或你本地部署的 Qwen。系统提示词输入你是一个专业的翻译官请将用户输入的中文内容准确、流畅地翻译成英文。对话内容在“用户”部分引用变量{{input_text}}。步骤 3添加第二个 LLM 节点摘要再拖拽一个“LLM”节点到画布连接到第一个 LLM 节点之后。模型选择可以使用同一个模型也可以换一个。系统提示词输入你是一个摘要专家请对给定的英文文本进行总结提取核心要点不超过3句话。对话内容在“用户”部分引用上一个节点的输出。点击输入框选择“变量选择器”然后选择“节点” - “翻译 LLM” - “回答”。这会自动生成引用语法{{#context.translation.answers#}}。步骤 4添加结束节点并定义输出拖拽一个“结束”节点到画布连接到摘要节点。在结束节点的配置中定义输出变量。例如添加一个translated_text映射到翻译节点的输出再添加一个summary映射到摘要节点的输出。至此一个包含两个 LLM 调用、顺序执行的工作流就搭建完成了。画布看起来应该像一条简单的流水线开始 - 翻译LLM - 摘要LLM - 结束。5.3 测试与发布配置模型如果你还没有配置模型需要先在顶栏的“模型供应商”设置中添加。支持 OpenAI、Azure、 Anthropic、Ollama本地等多种来源。以 Ollama 为例只需填入本地 Ollama 服务的地址如http://host.docker.internal:11434即可。运行测试点击画布右上角的“运行”按钮。在弹出窗的input_text框中输入一段中文例如“人工智能是未来科技发展的核心驱动力它正在深刻改变各行各业从医疗诊断到自动驾驶从金融风控到内容创作。”查看结果点击运行后你可以实时看到每个节点的执行状态运行中/成功/失败和中间结果。运行完成后在右侧“运行记录”中可以看到最终的translated_text和summary输出。发布应用测试无误后点击右上角“发布”。你可以选择发布为“Web 应用”或“API”。Web 应用Dify 会生成一个可分享的链接用户通过网页与你的 AI 应用交互。APIDify 会提供 API 端点Endpoint和密钥App Key方便你集成到自己的系统中。通过这个简单的例子你已经体验了 Dify 工作流的核心操作拖拽节点、连接逻辑、配置模型和提示词、变量传递、测试运行、一键发布。整个过程无需编写任何后端代码。6. 深入核心工作流Workflow高级功能详解工作流是 Dify 的杀手锏。除了简单的线性流程它还能做什么6.1 条件判断与分支逻辑工作流支持“条件判断”节点。你可以根据上一个节点的输出内容决定流程的走向。场景示例用户输入一个问题。先用一个 LLM 节点判断问题的类型是“技术问题”还是“商务问题”。然后根据判断结果将问题路由到不同的知识库或专家模型进行处理。6.2 并行执行与聚合Dify 工作流支持并行执行多个分支最后将结果聚合。场景示例用户输入一个产品名称你需要同时进行“竞品分析”、“市场舆情搜集”和“技术参数查询”。可以创建三个并行的 LLM 或工具调用节点最后用一个“聚合”节点将三份结果合并再交给一个 LLM 生成最终报告。6.3 集成外部工具与知识库这是构建强大 Agent 的关键。工具调用工作流中可以集成“代码执行”、“HTTP 请求”等节点。例如让 LLM 生成一段 Python 代码来分析数据然后由“代码执行”节点运行它并返回结果。知识库检索RAG直接拖入“知识库检索”节点。配置好你之前创建的知识库当工作流执行到该节点时会自动从知识库中检索相关片段并将其作为上下文提供给后续的 LLM 节点。这对于构建基于私有文档的问答系统至关重要。6.4 循环与迭代对于需要重复处理列表数据的任务可以使用“循环”节点。场景示例用户上传一个包含多个新闻标题的 CSV 文件。工作流可以循环遍历每一个标题分别调用 LLM 生成摘要最后将所有摘要汇总输出。6.5 错误处理与重试在生产环境中稳定性很重要。Dify 工作流允许你为节点配置“重试”策略。当某个节点如调用外部 API失败时可以自动重试指定次数提高流程的鲁棒性。7. 接口 API 与批量任务集成Dify 不仅提供 Web 界面更是一个强大的 API 服务平台。7.1 调用应用 API当你发布一个应用后无论是“对话型”还是“工作流型”Dify 都会为其生成专用的 API。在应用概览页进入“访问 API”标签页。你可以看到 API 端点Endpoint和你的 App Key。使用curl或任何 HTTP 客户端如 Python 的requests即可调用。Python 调用示例import requests import json # 替换为你的实际 API 地址和 Key api_url https://your-dify-domain/v1/chat-messages app_key your-app-api-key headers { Authorization: fBearer {app_key}, Content-Type: application/json } payload { inputs: {}, query: 请将‘你好世界’翻译成英文, response_mode: blocking, # 同步模式 conversation_id: , user: test_user_001 } response requests.post(api_url, headersheaders, jsonpayload, timeout30) result response.json() print(json.dumps(result, indent2, ensure_asciiFalse))对于工作流应用query字段对应的是你定义的输入变量。7.2 批量任务处理Dify 本身没有直接的“批量任务队列”界面但通过 API 可以轻松实现。思路编写一个简单的脚本读取你的任务列表如一个文本文件或 CSV循环调用上述 API并收集结果。示例脚本框架import csv import requests import time def process_single_task(input_text): # ... 调用上述 API 的代码 ... return output_text with open(tasks.csv, r, encodingutf-8) as f: reader csv.DictReader(f) results [] for row in reader: task_input row[input_column] try: output process_single_task(task_input) results.append({input: task_input, output: output}) print(fProcessed: {task_input[:50]}...) time.sleep(1) # 避免请求过快 except Exception as e: print(fFailed on {task_input}: {e}) results.append({input: task_input, output: fERROR: {e}}) # 将结果保存到新文件 with open(results.csv, w, newline, encodingutf-8) as out_f: writer csv.DictWriter(out_f, fieldnames[input, output]) writer.writeheader() writer.writerows(results)通过这种方式你可以利用 Dify 强大的工作流逻辑处理成千上万的异步任务。7.3 发布为 MCP Serverv1.9.2 新特性根据网络材料Dify 从 v1.9.2 开始支持将 AI 应用发布为MCPModel Context ProtocolServer。这意味着你构建的 Dify 应用可以作为一个标准化的“工具”或“能力”被其他支持 MCP 协议的客户端如某些 AI 助手直接调用实现了 AI 能力的跨平台共享和复用。这为构建企业内部的 AI 能力中台提供了强大的支持。8. 资源占用与性能观察Dify 服务本身资源消耗很轻主要压力来自你运行的 AI 模型。Dify 服务容器在空闲状态下dify-api和dify-frontend容器内存占用通常在 200-500 MB。PostgreSQL 和 Redis 各占用约 100-200 MB。Weaviate向量数据库占用会随知识库数据量增长。性能关键点模型推理速度这是整个应用响应的瓶颈。使用云端 API如 GPT-4取决于网络和 API 的速率限制。使用本地模型如 Ollama Qwen则取决于你的 GPU/CPU 算力。知识库检索速度当知识库文档数量巨大时检索可能变慢。确保为 Weaviate 分配足够内存并考虑对文档进行合理分块和索引优化。工作流复杂度一个包含多个 LLM 调用、条件分支、HTTP 请求的复杂工作流其总耗时是各节点耗时的累加。在设计时需考虑用户体验对于耗时长的任务建议使用异步response_mode: streaming或后台任务模式。监控建议使用docker stats命令实时查看各容器的 CPU、内存占用。在 Dify 控制台的“日志与审计”中查看应用调用的详细耗时和状态。对于生产部署建议将 Docker Compose 中的服务配置如数据库连接数、JVM 堆内存等根据服务器资源进行调整。9. 常见问题与排查方法以下是部署和使用 Dify 时可能遇到的典型问题及解决方案。问题现象可能原因排查方式解决方案访问localhost报错或无法连接1. 容器未成功启动。2. 端口被占用默认80端口。3. 防火墙/安全组限制。1.docker-compose ps查看容器状态。2.docker-compose logs查看具体错误日志。3.netstat -tlnp | grep :80检查端口。1. 根据日志修复错误常见于数据库初始化失败。2. 修改docker-compose.yaml中dify-frontend的端口映射如3001:3000然后访问localhost:3001。3. 开放服务器对应端口。模型测试连接失败1. API Key 错误或余额不足。2. 网络问题无法访问模型服务。3. 本地模型服务如 Ollama未运行或地址错误。1. 在 Dify 模型供应商配置页测试连接。2. 在服务器上curl测试模型 API 地址。3. 检查 Ollama 服务ollama serve是否运行。1. 检查并更正 API Key确保账户有额度。2. 配置正确的网络代理或检查防火墙。3. 对于 Docker 内访问宿主机服务使用host.docker.internal作为主机名。确保 Ollama 在运行。工作流运行卡住或失败1. 某个节点配置错误如提示词语法问题。2. 节点超时。3. 变量引用错误。1. 查看运行记录中具体哪个节点失败点击节点查看错误详情。2. 检查节点的“超时”设置是否太短。1. 根据错误信息修正提示词或配置。2. 对于耗时的 LLM 调用或 HTTP 请求适当增加超时时间。3. 仔细检查变量选择器的路径是否正确。知识库文档处理失败1. 文档格式不支持或已损坏。2. 文本分割或嵌入模型出错。3. 向量数据库Weaviate异常。1. 查看知识库文档处理状态日志。2. 检查 Weaviate 容器日志docker-compose logs dify-weaviate。1. 确保上传 PDF、Word、TXT 等常见格式。尝试重新上传。2. 尝试更换嵌入模型在知识库配置中。3. 重启 Weaviate 容器docker-compose restart dify-weaviate。应用 API 调用返回 401/403 错误1. App Key 错误或未传递。2. API 端点地址错误。1. 检查请求头中的Authorization: Bearer app-key是否正确。2. 核对 Dify 控制台中提供的 API 地址。1. 使用正确的 App Key注意不要泄露。2. 确保 API URL 路径正确例如/v1/chat-messages用于对话应用/v1/workflows/run用于工作流应用。内存或磁盘占用过高1. 知识库文档过多向量数据量大。2. 日志文件累积。3. Docker 镜像和缓存过多。1. 使用docker system df查看 Docker 磁盘使用。2. 进入容器查看日志文件大小。1. 清理不再需要的知识库。2. 配置 Docker 日志轮转或定期清理日志docker-compose logs --tail1000后重置。3. 定期执行docker system prune -a清理无用镜像和缓存谨慎操作。10. 最佳实践与使用建议为了让你的 Dify 之旅更顺畅这里有一些从实战中总结的经验。从简单开始不要一开始就设计极其复杂的工作流。从一个输入-输出明确的简单应用如我们演示的翻译摘要开始熟悉节点连接和变量传递。善用“变量选择器”这是工作流编排的核心。点击输入框旁的{x}图标可以可视化地选择上游节点的输出避免手动输入变量名出错。为关键节点添加“重试”对于调用外部 API、数据库查询等可能失败的节点务必在节点配置中设置重试次数如3次和重试间隔提升流程稳定性。测试时使用“对话”模式在构建工作流时可以临时在开始节点后接一个“对话”结束节点快速测试单步 LLM 的输出是否符合预期然后再接入后续复杂逻辑。管理好你的模型配置在“模型供应商”中集中管理所有 API Key 和端点。可以为不同环境开发、测试、生产配置不同的模型供应商方便切换。知识库优化上传文档前如果文档很大考虑手动分割成逻辑章节。调整文本分割器Splitter的块大小和重叠区这对检索质量影响很大。版本控制与发布Dify 支持应用版本管理。在做出重大修改前先发布一个版本这样如果新版本有问题可以快速回滚到稳定版本。关注安全性保管好你的docker-compose.yaml文件其中可能包含数据库密码等敏感信息。为生产环境配置强密码并修改默认的数据库密码。如果对外提供服务务必配置 HTTPS并在 Web 服务器如 Nginx层面设置访问限制和速率限制。加入社区Dify 拥有活跃的 GitHub 和 Discord 社区。遇到棘手问题时去那里搜索或提问通常能快速找到答案或灵感。Dify 将 AI 应用开发的复杂性封装在了直观的可视化界面之后让你能更专注于业务逻辑和创意本身。从今天开始尝试用 Dify 将你的下一个 AI 想法快速变成现实。无论是构建一个智能客服、一个自动报告生成器还是一个复杂的多智能体决策系统这个平台都能为你提供强大的支撑。 30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度