Dify开源AI应用开发平台：从零部署到工作流实战指南

🚀 30+款热门AI模型一站整合，DeepSeek/GLM/Qwen 随心用，限时 5 折。 👉 点击领海量免费额度

Dify 是一个开源的 AI 应用开发平台，由 LangGenius 团队维护。它的核心定位是让开发者、产品经理甚至业务人员，能够通过可视化拖拽的方式，快速构建和部署生产级的 AI 应用。简单来说，它把复杂的 AI 应用开发，比如智能客服、内容生成、数据分析等工作流，变成了“搭积木”一样的操作。

这个项目最值得关注的点在于，它把 Agentic（智能体）工作流、RAG（检索增强生成）管道、丰富的模型集成以及应用监控等能力，打包成了一个开箱即用的平台。你不需要从零开始写代码去调用各种大模型 API、处理知识库索引、设计复杂的逻辑判断，而是可以直接在 Dify 的图形化界面里，通过连接不同的“节点”来组装你的 AI 应用。

对于想快速验证 AI 想法、或者需要将 AI 能力集成到现有业务中的团队和个人来说，Dify 大幅降低了技术门槛。它支持接入 OpenAI、Anthropic、国内主流大模型以及本地部署的模型（如通过 Ollama），这意味着你可以灵活选择推理后端，兼顾成本与效果。

本文将带你从零开始，完成 Dify 的本地部署、核心功能上手，并重点剖析其强大的“工作流”功能。我们会搭建一个实际的 AI 应用案例，并演示如何通过 API 将其集成到你的系统中。无论你是 AI 应用开发的新手，还是寻求效率工具的技术负责人，这篇文章都能提供直接的、可落地的操作指南。

1. 核心能力速览

在深入细节之前，我们先通过一个表格快速了解 Dify 的核心特性，这有助于你判断它是否适合你的需求。

2. 适用场景与使用边界

Dify 不是万能的，理解其最佳使用场景和边界，能帮你更好地决策。

它非常适合：

1. 快速原型验证：当你有一个 AI 产品想法时，用 Dify 可以在几小时内搭建出可交互的 Demo，无需前后端开发。
2. 企业内部工具开发：如搭建一个基于公司文档的智能问答助手、一个自动生成周报的机器人，或一个客服话术优化工具。
3. 教育/学习用途：对于学习 AI 应用开发、RAG 技术、智能体（Agent）概念的学生和开发者，Dify 提供了直观的实践环境。
4. 中小型生产应用：对于不需要极端定制化、追求开发效率的场景，Dify 的开源版本足以支撑。

它可能不适合：

1. 超大规模、超高并发的场景：虽然 Dify 设计考虑了生产环境，但对于亿级日活的应用，可能需要基于其开源代码进行深度定制和架构优化。
2. 需要深度定制算法逻辑的场景：如果你的 AI 应用核心是极其特殊的算法或模型架构，Dify 的工作流节点可能无法直接满足，需要自行开发插件。
3. 完全离线的封闭环境：Dify 的某些功能（如从市场安装插件）可能需要网络。纯内网部署需提前准备所有依赖。

合规与安全边界提醒：

• 数据隐私：如果使用云端大模型 API（如 OpenAI），你的提示词和数据会发送到第三方，需注意企业数据合规要求。Dify 支持本地模型，可实现数据完全私有化。
• 内容安全：基于 Dify 构建的应用，其生成内容受所用底层大模型的安全策略影响。在生产环境中，务必对生成内容添加审核或过滤机制。
• 版权与授权：使用 RAG 功能时，确保上传的知识库文档拥有合法使用权。生成内容时，避免直接复制受版权保护的素材。

3. 环境准备与前置条件

本地部署 Dify 非常简单，主要依赖 Docker 环境。以下是详细的准备工作。

3.1 系统与软件要求

• 操作系统：Windows 10/11, macOS, Linux (Ubuntu 20.04+/CentOS 7+ 等) 均可。本文以Windows 11和Ubuntu 22.04为例。
• Docker 与 Docker Compose：这是必须的。确保已安装最新稳定版。
  • Windows/macOS：直接安装 Docker Desktop 。
  • Linux：通过包管理器安装 Docker 和 Docker Compose Plugin。
• 硬件资源：
  • CPU：现代双核以上处理器。
  • 内存：建议至少4GB，推荐 8GB 或以上。
  • 磁盘空间：至少 10GB 可用空间，用于存放 Docker 镜像和后续的模型文件。
  • GPU（可选）：如果计划在本地运行大模型（如通过 Ollama），则需要 GPU。对于 7B 参数量的模型，至少需要 8GB 显存；13B 模型需要 16GB 以上显存。仅运行 Dify 平台本身不需要 GPU。
• 网络：需要能访问 Docker Hub 和 GitHub 以下载镜像和源码。如果需要使用在线大模型 API，则需要相应的网络条件。

3.2 环境检查清单

在开始安装前，请打开终端（Windows 下用 PowerShell 或 CMD，Linux/macOS 用 Terminal），执行以下命令验证环境：

# 检查 Docker 版本 docker --version # 检查 Docker Compose 版本 (Docker Desktop 已包含) docker compose version # 检查系统资源（Linux/macOS） free -h # 查看内存 df -h / # 查看根目录磁盘空间

如果上述命令都能正确执行并输出版本信息，说明基础环境已就绪。

4. 安装部署与启动方式

Dify 官方推荐使用 Docker Compose 进行部署，这是最快捷、最不容易出错的方式。

4.1 一键部署（Docker Compose）

1. 获取部署文件： 打开终端，创建一个工作目录并进入，然后下载官方提供的docker-compose.yaml文件。

   # 创建并进入目录 mkdir dify && cd dify # 下载 Docker Compose 配置文件 (请始终从官方仓库获取最新版) # 方式一：使用 curl (Linux/macOS) curl -o docker-compose.yaml https://raw.githubusercontent.com/langgenius/dify/main/docker/docker-compose.yaml # 方式二：使用 wget # wget -O docker-compose.yaml https://raw.githubusercontent.com/langgenius/dify/main/docker/docker-compose.yaml # 对于 Windows PowerShell，可以使用： # Invoke-WebRequest -Uri https://raw.githubusercontent.com/langgenius/dify/main/docker/docker-compose.yaml -OutFile docker-compose.yaml

2. （可选）配置环境变量： 你可以创建一个.env文件来覆盖默认配置，例如修改端口、数据库密码等。对于初次体验，可以直接使用默认配置。

   # 创建 .env 文件示例 cat > .env << EOF # 修改 Web 服务端口，如果默认的 3000 端口被占用 # PORT=3000 # 修改 API 服务端口，如果默认的 5001 端口被占用 # API_PORT=5001 # 修改数据库密码（强烈建议在生产环境修改） # DB_PASSWORD=your_strong_password_here EOF

3. 启动 Dify 服务： 在包含docker-compose.yaml文件的目录下，执行启动命令。

   # 在后台启动所有服务 docker compose up -d

   这个命令会拉取 PostgreSQL、Redis、Nginx 和 Dify 自身的镜像，并启动所有容器。首次运行需要下载镜像，时间取决于你的网络速度。

4. 验证服务状态：

   # 查看容器运行状态 docker compose ps # 查看实时日志（Ctrl+C 退出） docker compose logs -f

   当看到所有容器状态均为running，并且日志中没有持续报错时，说明服务已启动成功。

4.2 访问与初始化

1. 访问 Web 界面： 在浏览器中打开http://localhost:3000（如果你修改了PORT环境变量，则使用对应的端口）。

2. 初始化设置：

   • 首次访问会进入初始化页面。
   • 设置管理员账号、邮箱和密码，请务必牢记。
   • 接下来进入“模型供应商”配置页面。这里你可以添加后续工作流中要使用的大模型。
     • 对于初学者：可以先添加一个免费的在线模型 API，如 OpenRouter 提供的各种模型，或者使用 OpenAI、通义千问等（需要 API Key）。
     • 对于本地测试：可以配置本地运行的 Ollama。确保 Ollama 服务已启动（例如在http://localhost:11434），然后在 Dify 中添加“Ollama”供应商，填入基础 URL 即可。

3. 进入控制台： 初始化完成后，你会进入 Dify 的主控制台。左侧是导航菜单，包括“应用”、“工作流”、“知识库”、“工具”等核心模块。

至此，Dify 平台已经部署完成并可以正常使用。整个过程如果网络通畅，通常在 10-15 分钟内即可完成。

5. 功能测试与效果验证：构建你的第一个 AI 工作流

平台跑起来了，我们通过创建一个实际的 AI 应用来验证核心功能。我们将构建一个“多格式营销文案生成器”：用户输入一个产品描述，工作流会自动生成一段广告标语、一篇小红书风格的种草文案和一段商品详情描述。

5.1 创建应用与工作流

1. 创建新应用：

   • 在控制台点击“创建应用”，选择“空白应用”，命名为“营销文案生成器”。
   • 创建后，会进入应用编排界面。默认是“对话”模式，我们点击顶部切换到“工作流”模式。

2. 认识工作流界面：

   • 中间是画布，右侧是节点工具箱，左侧是运行历史和变量面板。
   • 工具箱里节点主要分为几类：开始、LLM（大语言模型）、工具（代码、HTTP请求等）、逻辑（判断、循环）、文档处理、结束。

3. 搭建工作流： 我们从左侧拖拽节点到画布，进行连接。目标是构建如下流程：开始 -> 产品描述输入 -> (并行)LLM生成标语 -> LLM生成小红书文案 -> LLM生成商品详情 -> 结束并输出

   具体步骤： a.开始节点：从工具箱拖入“开始”节点。在右侧配置区，点击“添加变量”，定义一个名为product_desc的字符串变量，作为用户输入的产品描述。 b.LLM 节点（生成标语）： * 拖入一个“LLM”节点，连接到“开始”节点之后。 * 在配置区，选择你之前配置好的模型供应商和模型（例如gpt-3.5-turbo或qwen-plus）。 * 在“提示词”区域输入：text 你是一个专业的广告文案师。请根据以下产品描述，创作一句吸引人的广告标语，要求简短、有力、有记忆点。 产品描述：{{product_desc}}* 在“上下文”标签页，可以清空“对话历史”，因为我们不需要记忆。 * 在“变量”标签页，将输出变量名设置为slogan。 c.LLM 节点（生成小红书文案）： * 再拖入一个“LLM”节点，同样连接到“开始”节点之后。这样两个 LLM 节点就处于并行关系。 * 配置模型。 * 提示词示例：text 你是一个小红书热门博主。请为以下产品写一篇种草文案，风格要活泼、亲切，多用表情符号和“啦”、“呀”等语气词，包含使用场景和优点。 产品描述：{{product_desc}}* 输出变量名设置为xiaohongshu_post。 d.LLM 节点（生成商品详情）： * 拖入第三个“LLM”节点，连接到“开始”节点之后，形成三个并行任务。 * 提示词示例：text 你是一个电商产品经理。请为以下产品撰写一段详细、专业的商品详情描述，突出产品功能、规格和用户价值。 产品描述：{{product_desc}}* 输出变量名设置为product_detail。 e.结束节点： * 拖入“结束”节点。 * 将三个 LLM 节点的输出都连接到“结束”节点。 * 在结束节点的配置中，你可以选择要返回给用户的结果。我们可以配置为返回一个包含所有内容的 JSON 对象。 * 在“回复”配置中，选择“高级”，在“回复内容”里编写：json { “slogan”: “{{slogan}}”, “xiaohongshu_post”: “{{xiaohongshu_post}}”, “product_detail”: “{{product_detail}}” }

4. 保存并运行测试：

   • 点击右上角的“保存”按钮。
   • 点击右上角的“运行”。在左侧的运行面板，输入product_desc的值，例如：“一款采用新型石墨烯材料制作的保温杯，保冷保热效果长达24小时，外观简约时尚。”
   • 点击“运行”。你会看到画布上的节点依次变为绿色（执行成功）或红色（失败）。
   • 运行结束后，在运行历史中点击本次运行，即可在“输出”部分看到生成的三种不同格式的文案。

效果验证点：

• 功能成功：三个 LLM 节点是否都独立执行并输出了内容？
• 内容质量：生成的文案是否符合提示词中设定的角色和风格要求？（标语是否简短有力？小红书文案是否有网感？详情是否专业？）
• 并行效率：观察运行时间，理论上三个并行节点应该几乎同时开始执行，总耗时约等于最慢的那个节点的耗时，而不是三者相加。

5.2 测试 RAG 知识库问答

工作流展示了 Dify 的流程编排能力，而 RAG 是其另一大核心功能。

1. 创建知识库：
   • 在主导航栏点击“知识库”，然后“创建知识库”，命名为“公司产品手册”。
   • 选择“文本分割方式”，可以使用默认的“通用”模式。
2. 上传文档：
   • 进入知识库，点击“上传文件”。支持 txt、pdf、docx、ppt、excel、markdown 等多种格式。
   • 上传一份你准备好的产品说明书或任何文本资料。
   • 上传后，Dify 会自动进行文本提取、分割和向量化（嵌入）处理。这个过程需要一些时间，可以在“索引状态”查看进度。
3. 创建基于知识库的对话应用：
   • 回到“应用”页面，新建一个“对话型”应用，命名为“产品知识助手”。
   • 在应用编排页面的“提示词”区域，下方找到“上下文”部分。
   • 勾选“启用知识库”，并选择我们刚创建的“公司产品手册”。
   • 你还可以在提示词中设定 AI 的角色，例如：“你是一个专业的产品顾问，请严格根据提供的知识库内容回答用户问题。如果知识库中没有相关信息，请如实告知。”
4. 测试问答：
   • 保存应用后，在右侧的聊天窗口进行测试。
   • 提问一个知识库中明确包含答案的问题，例如产品规格。
   • 再提问一个知识库中没有的问题。观察 AI 的回答是否符合你的设定（是胡编乱造还是承认不知道）。

效果验证点：

• 检索准确性：AI 的回答是否严格基于你上传的文档内容？
• 引用溯源：Dify 的回答通常会附带引用的文档片段，点击可以查看来源，验证其可靠性。
• 拒答能力：对于知识库外的问题，AI 是否能按照提示词要求，诚实地说“我不知道”？

6. 接口 API 与批量任务

Dify 的核心价值之一是将构建好的 AI 应用封装成 API，方便集成到其他系统。

6.1 获取并使用应用 API

1. 查看 API 配置：
   • 在任何一个你创建的应用界面（无论是工作流还是对话型），点击顶部导航的“发布”。
   • 选择“API 访问”标签页。这里提供了该应用的专属 API 端点（Endpoint）和密钥（API Key）。
2. API 调用示例（Python）： 假设我们想通过代码调用刚才创建的“营销文案生成器”。

   import requests import json # 替换为你的实际信息 API_KEY = “your-app-api-key-here” # 在应用发布页找到 APP_ID = “your-app-id-here” # 同样在发布页 # 如果你的 Dify 部署在本地，且未修改默认端口 BASE_URL = “http://localhost:5001” # API 服务地址 url = f“{BASE_URL}/v1/workflows/run” headers = { “Authorization”: f“Bearer {API_KEY}”, “Content-Type”: “application/json” } # 请求体，对应工作流的输入变量 payload = { “inputs”: { “product_desc”: “一款智能语音助手音箱，支持多房间音乐同步和家居控制。” }, “response_mode”: “blocking”, # 阻塞模式，等待完成返回。也可以是 ‘streaming’ 流式。 “user”: “test_user_123” # 标识用户，用于运营统计 } try: response = requests.post(url, headers=headers, data=json.dumps(payload), timeout=120) response.raise_for_status() # 检查HTTP错误 result = response.json() print(“API调用成功！”) print(“完整响应：”, json.dumps(result, indent=2, ensure_ascii=False)) # 提取我们定义的输出 if result.get(“data”): outputs = result[“data”].get(“outputs”, {}) print(“\n生成的标语：”, outputs.get(“slogan”)) print(“\n生成的小红书文案：”, outputs.get(“xiaohongshu_post”)) print(“\n生成的商品详情：”, outputs.get(“product_detail”)) except requests.exceptions.RequestException as e: print(f“API请求失败：{e}”) if response: print(“响应内容：”, response.text)

3. 测试 API： 将上述代码中的API_KEY和APP_ID替换成你自己的，在 Python 环境中运行。你应该能收到一个包含三种文案的 JSON 响应。

6.2 实现批量任务处理

Dify 工作流本身可以通过 API 被循环调用，从而实现批量处理。你只需要在外围写一个脚本，遍历你的输入数据，依次调用 API。

import requests import json import time API_KEY = “your-api-key” APP_ID = “your-app-id” BASE_URL = “http://localhost:5001” WORKFLOW_API_URL = f“{BASE_URL}/v1/workflows/run” headers = { “Authorization”: f“Bearer {API_KEY}”, “Content-Type”: “application/json” } # 假设你有一个产品描述列表 product_list = [ “防水蓝牙运动耳机，续航15小时”, “全自动智能咖啡机，支持手机App预约”, “可折叠便携显示器，15.6英寸4K分辨率” ] results = [] for idx, product_desc in enumerate(product_list): print(f“正在处理第 {idx+1} 个产品：{product_desc}”) payload = { “inputs”: {“product_desc”: product_desc}, “response_mode”: “blocking”, “user”: f“batch_user_{idx}” } try: response = requests.post(WORKFLOW_API_URL, headers=headers, data=json.dumps(payload), timeout=180) if response.status_code == 200: data = response.json().get(“data”, {}) outputs = data.get(“outputs”, {}) results.append({ “product”: product_desc, “slogan”: outputs.get(“slogan”), “xiaohongshu_post”: outputs.get(“xiaohongshu_post”), “product_detail”: outputs.get(“product_detail”) }) print(f“ 处理成功”) else: print(f“ 处理失败，状态码：{response.status_code}”) results.append({“product”: product_desc, “error”: response.text}) # 避免请求过于频繁，可根据模型速度调整间隔 time.sleep(1) except Exception as e: print(f“ 请求异常：{e}”) results.append({“product”: product_desc, “error”: str(e)}) # 保存结果 with open(“batch_marketing_results.json”, “w”, encoding=“utf-8”) as f: json.dump(results, f, indent=2, ensure_ascii=False) print(“批量处理完成，结果已保存到 batch_marketing_results.json”)

关键点：

• 错误处理：批量任务必须包含健壮的错误处理（如 try-except），记录失败项以便重试。
• 速率限制：如果使用第三方付费 API，注意其速率限制，通过time.sleep()控制请求频率。
• 异步与队列：对于大规模批量任务，更可靠的方式是使用消息队列（如 Redis、RabbitMQ）配合异步 worker，而不是简单的循环。

7. 资源占用与性能观察

Dify 平台本身作为 Web 服务，资源消耗并不高。性能瓶颈主要出现在你集成的 AI 模型推理环节。

7.1 平台服务资源占用

启动 Dify 的 Docker 容器后，可以通过以下命令观察资源使用情况：

# 查看所有容器的资源占用（CPU， 内存） docker stats # 查看特定容器的详细资源使用 docker stats dify-api dify-worker dify-web

通常情况下：

• 内存：几个核心服务（API、Worker、Web）容器各自占用约 200-500 MB 内存。
• CPU：空闲时占用很低，在处理工作流或进行知识库文档索引时会有峰值。
• 磁盘：主要占用来自 PostgreSQL 数据库和向量数据库（如果使用本地向量库如 Qdrant）。知识库文档和索引文件会持续增长。

7.2 模型推理性能

这是影响用户体验的关键。

• 使用云端 API（如 GPT-4）：性能取决于 API 提供商的网络和算力，Dify 主要负责请求转发和结果处理，延迟较低。
• 使用本地模型（如通过 Ollama 运行 Qwen2.5-7B）：
  • 首次加载：模型加载到 GPU 显存或 CPU 内存需要时间，首次请求响应慢。
  • 推理速度：受本地硬件（GPU > CPU）、模型参数量（7B > 13B > 70B）和生成长度影响。
  • 显存占用：这是本地部署的核心关注点。使用nvidia-smi（Linux）或任务管理器（Windows）监控。

    # Linux 查看 GPU 使用情况 nvidia-smi # 或动态监控 watch -n 1 nvidia-smi

  • 优化建议：
    1. 量化：使用 4-bit 或 8-bit 量化版本的模型，可大幅减少显存占用，速度损失可接受。
    2. 模型选择：在效果和速度间权衡。7B/14B 模型适合大多数对话和生成任务，响应快。
    3. 参数调整：在 Dify 的 LLM 节点配置中，可以调整max_tokens（最大生成长度）和temperature（创造性）。更短的长度和更低的 temperature 通常意味着更快的响应。

7.3 工作流执行效率

• 并行节点：如前例所示，互不依赖的 LLM 节点会并行执行，充分利用计算资源。
• 串行依赖：如果节点 A 的输出是节点 B 的输入，则它们是串行的。优化关键是减少不必要的串行，将可并行的任务拆分。
• 网络调用：工作流中如果有“HTTP 请求”节点调用外部服务，其延迟会直接影响整个工作流的执行时间。务必为这些节点设置合理的超时时间。

8. 常见问题与排查方法

在部署和使用 Dify 过程中，你可能会遇到以下问题。这里提供一份排查清单。

9. 最佳实践与使用建议

基于社区经验和生产实践，以下建议能帮助你更高效、更稳定地使用 Dify。

1. 项目结构规划：

   • 环境分离：使用不同的 Dify 部署（或利用其多环境功能）来区分开发、测试和生产环境。
   • 应用分类：在 Dify 内，使用清晰的命名和标签来管理不同的 AI 应用，例如project1-marketing-bot,project2-kb-qa。

2. 模型管理策略：

   • 配置备用模型：在 LLM 节点配置中，可以设置“备用模型”。当主模型调用失败时，会自动切换到备用模型，提高可用性。
   • 成本与性能平衡：对于内部工具，可以使用成本较低的模型（如 GPT-3.5-Turbo、本地模型）；对于面向客户的核心功能，再使用效果更好的模型（如 GPT-4、Claude-3）。

3. 工作流设计原则：

   • 模块化：将复杂的逻辑拆分成多个子工作流，通过“工作流”节点进行调用，使主工作流更清晰。
   • 善用变量：合理规划和使用变量，避免在提示词中硬编码。将可配置的部分（如风格、长度）作为输入变量。
   • 添加错误处理：在关键节点后添加“判断”节点，检查上一步的输出是否有效，无效则跳转到错误处理分支或给出友好提示。

4. 知识库优化：

   • 文档预处理：上传前，尽量清理文档格式，将复杂的 PDF/PPT 转换为结构清晰的 Markdown 或文本，能提升检索质量。
   • 调整分块策略：根据文档类型（法律条文、技术文档、对话记录）调整文本分割的长度和重叠度，找到最适合的索引粒度。
   • 定期更新：建立知识库文档的更新机制，当源文件变化时，在 Dify 中重新索引。

5. API 安全与监控：

   • 保护 API Key：不要在客户端代码中暴露 API Key。应该通过你自己的后端服务器转发请求。
   • 启用访问日志：Dify 提供了详细的 API 调用日志，定期审查有助于了解使用情况和排查问题。
   • 设置用量限制：对于公开的 API，可以在 Dify 或上游网关设置频率限制和用量配额。

6. 版本控制与备份：

   • 应用版本化：Dify 支持应用版本管理。在重大修改前，先发布一个新版本进行测试，稳定后再切回生产版本。
   • 定期备份：定期备份 Docker 卷中的数据，特别是 PostgreSQL 数据库卷，以防数据丢失。

10. 总结与下一步

Dify 作为一个生产级的 AI 应用开发平台，其价值在于将 AI 能力工程化、产品化的门槛降到了极低。通过本文，你应该已经完成了从零部署、核心功能验证到 API 集成的完整流程。

最值得尝试的点：

• 可视化工作流：对于不擅长编码的产品、运营人员，这是快速将 AI 想法落地的神器。
• 开箱即用的 RAG：搭建一个可用的知识库问答系统，从未如此简单。
• 强大的模型兼容性：一套界面，可以无缝切换和测试国内外数十种大模型。

最先应该验证的功能： 建议你按照“部署 -> 配置一个在线模型（如 OpenAI）-> 创建一个简单对话应用 -> 创建一个并行工作流 -> 接入一个本地模型（如 Ollama）-> 构建一个知识库应用”这个路径来实践，由浅入深。

最容易踩的坑：

1. 网络问题：部署时拉取镜像慢，或无法访问海外模型 API。准备好镜像加速和网络解决方案。
2. 变量引用错误：工作流中节点间的变量名必须完全匹配，包括大小写。
3. 本地模型显存不足：在配置本地模型前，先用ollama run <model-name>命令测试模型是否能正常加载和运行。

后续扩展方向：

1. 探索插件市场：Dify 社区提供了许多插件（如数据库查询、搜索引擎、图像生成等），可以极大扩展工作流的能力边界。
2. 深入研究 MCP：Model Context Protocol 是 Dify 连接外部工具和服务的标准化方式，学习如何创建或集成 MCP Server，可以让你的 AI 应用获得更多“手和脚”。
3. 性能调优与高可用部署：当应用需要服务大量用户时，研究如何对 Dify 的各个组件（API、Worker、数据库）进行水平扩展和负载均衡。
4. 贡献社区：如果你解决了某个特定问题或开发了有用的工作流模板，可以回馈给开源社区。

Dify 正在快速迭代，保持关注其 GitHub 仓库 和官方文档，能让你始终站在 AI 应用开发效率的前沿。现在，你可以关闭这篇教程，打开浏览器，开始构建你的第一个 AI 应用了。

🚀 30+款热门AI模型一站整合，DeepSeek/GLM/Qwen 随心用，限时 5 折。 👉 点击领海量免费额度