Dify 是一个开源的、生产级的 Agentic 工作流开发平台由 LangGenius 团队打造。它的核心目标是把 AI 创意快速落地让你能通过可视化拖拽的方式构建和部署复杂的 AI 应用和工作流而无需处理繁琐的后端复杂性。简单说它把大模型应用开发的门槛降到了最低无论是想快速验证一个 AI 想法还是构建一个企业级的智能问答、内容生成或自动化流程Dify 都能提供一站式的解决方案。这个平台最值得关注的点在于它的“开箱即用”和“生产就绪”。它无缝集成了全球主流的大语言模型LLM无论是 OpenAI、Anthropic 这样的闭源服务还是 Llama、Qwen 等开源模型甚至是本地部署的 Ollama都能轻松接入。更重要的是它提供了强大的工作流Workflow引擎、RAG检索增强生成管道、丰富的工具集成以及全面的可观测性让你能专注于业务逻辑而不是底层架构。对于开发者、产品经理甚至业务人员来说Dify 意味着你可以用“搭积木”的方式在几分钟内组合出一个具备复杂逻辑的 AI 应用。比如一个结合了联网搜索、文档知识库查询、多模型决策和格式化输出的智能客服机器人在 Dify 里通过拖拽节点就能完成。本文将从零开始带你完成 Dify 的本地部署、核心功能上手并通过一系列实战项目案例让你彻底掌握如何用它来构建企业级 AI 应用。如果你关心如何快速将大模型能力集成到自己的业务中如何通过无代码/低代码方式构建稳定可用的 AI 工作流或者想寻找一个比直接调用 API 更高效、比从零开发更省事的解决方案那么 Dify 绝对值得你花时间深入了解。接下来我们就直接进入实战环节。1. 核心能力速览在深入部署和实战前我们先快速了解 Dify 的核心规格和能力边界这有助于你判断它是否适合你的项目。能力项说明项目类型开源 AI 应用开发平台 / 低代码工作流引擎开源团队LangGenius核心功能1.可视化工作流构建拖拽式编排 LLM、工具、逻辑判断等节点。2.RAG 知识库支持多种格式文档上传构建私有知识库进行智能问答。3.Agentic 智能体构建能调用工具、执行复杂任务的 AI Agent。4.模型无缝接入支持 OpenAI、Azure、 Anthropic、Cohere、本地模型Ollama, vLLM等、国产大模型等。5.应用发布与 API一键将工作流发布为 Web 应用或 API 服务。部署方式Docker Compose推荐、源码部署、云服务硬件门槛轻量本地测试4GB 内存可运行基础服务。生产建议 8GB 内存如需运行本地大模型则需相应 GPU 资源。显存占用平台本身不直接消耗大量显存。显存占用取决于你接入并运行的本地模型如通过 Ollama。支持平台Windows (Docker Desktop), Linux, macOS启动方式命令行一键启动Docker Compose、WebUI 访问是否支持 API是为每个创建的应用自动生成 OpenAPI 规范的 API。是否支持批量任务是工作流支持批量处理输入可通过 API 进行异步或同步调用。适合场景快速原型验证、企业级 AI 应用开发、智能客服、内容生成、数据分析、自动化流程、内部知识库问答系统。2. 适用场景与使用边界Dify 的强大在于其灵活性和完整性但它并非万能钥匙。明确其适用边界能帮助你更好地决策。它非常适合以下场景快速验证 AI 想法你有一个结合了搜索、文档处理和文本生成的创意想在几小时内做出可演示的 Demo。构建企业级 AI 助手需要为团队打造一个基于私有知识库的问答机器人确保数据不出域且回答准确。开发复杂的多步骤 AI 流程例如一个营销内容生成流程需要先进行市场分析再生成多种风格的文案最后进行敏感词审核。为现有系统添加 AI 能力通过 Dify 暴露的 API可以轻松将 AI 工作流集成到你的 CRM、OA 或其他业务系统中。无代码/低代码 AI 应用开发产品、运营等非技术角色也能参与构建 AI 工具。它可能不是最佳选择如果你需要极致的定制化算法Dify 专注于应用编排和集成而非底层模型算法的研发。复杂的模型训练、微调仍需专业框架。你的应用是纯前端交互应用如果核心复杂度在前端 UI/UX而非后端 AI 流程那么直接调用模型 API 搭配前端框架可能更直接。资源极度受限的嵌入式环境Dify 作为服务平台需要一定的服务器资源来运行。合规与安全边界提醒数据安全在本地部署模式下你的所有数据知识库文档、对话记录都保存在自己的服务器上这是企业级应用的核心优势。模型合规接入第三方模型 API 时需遵守相应服务商的使用条款。使用开源模型则需注意其开源协议。内容审核在构建内容生成类应用时务必在工作流中加入内容安全审核节点避免产生不合规内容。版权与隐私使用 RAG 知识库时确保上传的文档拥有合法版权或授权。处理用户数据时应遵循隐私保护法规。3. 环境准备与前置条件开始部署前请确保你的环境满足以下要求。这里以最常用的Docker Compose部署方式为例。1. 操作系统推荐Linux (Ubuntu 20.04/22.04 LTS, CentOS 7/8) 或 Windows 10/11 (需安装 WSL2 或 Docker Desktop)。macOS同样支持。2. 软件依赖Docker版本 20.10.0 或更高。Docker Compose版本 v2 或更高。在 Linux 上通常可通过docker-compose-plugin安装。在 Windows/macOS 上安装 Docker Desktop 即包含。3. 硬件资源CPU2 核或以上。内存最低 4GB建议 8GB 或以上以获得流畅体验。如果计划在本地运行大模型如通过 Ollama 集成则需要根据模型大小预留额外内存和显存。磁盘空间至少 10GB 可用空间用于存放 Docker 镜像、数据库和向量数据库。4. 网络确保服务器可以访问 Docker Hub 和 GitHub 以下载镜像和代码。如果需要接入 OpenAI 等在线 API则需要稳定的国际网络连接。对于纯内网或离线环境需提前准备离线镜像和模型文件。5. 端口检查Dify 默认会占用以下端口请确保它们未被占用3000前端 Web 界面。5001后端 API 服务。6379Redis缓存。5432PostgreSQL数据库。9000MinIO对象存储用于文件。9091Weaviate向量数据库可选也可用其他如 PGVector。使用以下命令快速检查端口占用情况Linux/macOS# 检查关键端口是否被占用 sudo lsof -i :3000 sudo lsof -i :5001 # 如果端口被占用可以考虑停止相关服务或修改 Dify 的 docker-compose.yaml 文件中的端口映射。4. 安装部署与启动方式Dify 官方推荐使用 Docker Compose 进行一键部署这是最快、最不容易出错的方式。4.1 一键部署Docker Compose步骤 1获取部署文件在你的服务器上创建一个工作目录并下载官方提供的docker-compose.yaml文件。# 创建并进入目录 mkdir dify cd dify # 下载最新的 docker-compose 配置文件 curl -Lo docker-compose.yaml https://raw.githubusercontent.com/langgenius/dify/main/docker/docker-compose.yaml # 下载环境变量配置文件示例 curl -Lo .env https://raw.githubusercontent.com/langgenius/dify/main/docker/.env.example步骤 2配置环境变量编辑.env文件这是配置 Dify 的关键。你需要至少设置一个安全的密钥。# 使用文本编辑器打开 .env 文件例如 nano 或 vim nano .env找到以下关键配置项并进行修改# 设置一个强密码作为加密密钥务必修改 SECRET_KEYyour-strong-secret-key-change-this-please # 外部访问地址如果是本地测试可以设置为 localhost 或你的服务器IP APP_WEB_URLhttp://localhost:3000 API_BASE_URLhttp://localhost:5001 # 数据库密码建议修改 POSTGRES_PASSWORDdifyai123456 REDIS_PASSWORDdifyai123456其他配置如邮件服务器、S3存储等初次体验可以保持默认。步骤 3启动所有服务使用 Docker Compose 命令启动所有容器。# 在包含 docker-compose.yaml 和 .env 的目录下执行 sudo docker compose up -d这个命令会拉取 PostgreSQL、Redis、Weaviate、MinIO、Nginx 以及 Dify 前后端等多个镜像并以后台模式运行。首次执行可能需要几分钟时间下载镜像。步骤 4查看服务状态与日志启动后可以使用以下命令检查服务是否正常运行。# 查看所有容器状态 sudo docker compose ps # 查看实时日志CtrlC 退出 sudo docker compose logs -f # 如果某个服务启动失败可以单独查看其日志例如后端 api sudo docker compose logs -f api当看到所有容器状态均为running且日志中没有持续报错时说明启动成功。步骤 5访问 Web 界面在浏览器中打开你配置的APP_WEB_URL通常是http://你的服务器IP:3000。 首次访问会进入初始化页面按照提示设置管理员账号和密码并配置初始的模型供应商例如 OpenAI 的 API Key。完成初始化后即可登录进入 Dify 控制台。4.2 常见部署问题排查端口冲突如果启动失败首先检查端口是否被占用。可以修改docker-compose.yaml文件中对应服务的ports映射例如将“3000:3000”改为“3001:3000”。权限问题在 Linux 上如果使用非 root 用户确保该用户在docker用户组中或者使用sudo。镜像拉取慢可以配置 Docker 国内镜像加速器。内存不足如果服务器内存较小可能会因 Weaviate 或 PostgreSQL 启动失败。可以尝试在docker-compose.yaml中为这些服务增加资源限制或者关闭 Weaviate使用 SQLite 向量数据库需修改配置。5. 功能测试与效果验证成功部署后我们通过几个核心功能来验证 Dify 是否工作正常并熟悉其基本操作。5.1 测试一创建第一个对话型应用Chat App这是最基础的功能用于测试模型接入是否成功。进入控制台登录后点击左侧导航栏的“应用”然后点击“创建新应用”。选择应用类型选择“对话型应用”输入应用名称例如“测试助手”。配置模型与提示词在“模型与提示词”区域选择“模型供应商”。如果你在初始化时配置了 OpenAI这里可以直接选择。在“系统提示词”框中输入你是一个乐于助人的AI助手请用中文回答用户的问题。模型参数温度、最大 Token 等可以先保持默认。测试对话点击右上角的“发布”按钮然后选择“预览”。在预览窗口的输入框里问一个问题例如“介绍一下你自己。”观察是否能收到连贯、符合提示词要求的中文回复。成功标准AI 能够根据你的系统提示词用中文流畅地回答你的问题。这证明 Dify 后端已成功连接到你所配置的 LLM 服务。5.2 测试二构建一个简单工作流Workflow工作流是 Dify 的核心。我们来构建一个“文章总结并提取关键词”的自动化流程。创建工作流点击“创建新应用”这次选择“工作流”。命名为“文章总结器”。拖拽节点从左侧节点库中拖拽一个“开始”节点到画布。拖拽一个“LLM”节点到画布并将其连接到“开始”节点。再拖拽一个“LLM”节点到画布连接到第一个 LLM 节点的输出。配置节点第一个 LLM 节点将其重命名为“总结”。在提示词框中输入“请总结以下文章的主要内容{{#context.input#}}”。选择你的模型。第二个 LLM 节点将其重命名为“提取关键词”。在提示词框中输入“根据以下文章总结提取3-5个核心关键词{{#summary#}}”。选择模型。注意{{#summary#}}是一个变量它引用了上一个“总结”节点的输出。Dify 会自动识别和建立连接。配置输入输出点击“开始”节点在右侧面板的“变量”中点击“添加”。设置变量名称为input类型为“字符串”这将作为工作流的输入。点击画布空白处在右侧的“工作流输出”设置中添加两个输出summary来自“总结”节点和keywords来自“提取关键词”节点。测试运行点击右上角的“运行”。在弹出窗口中为input变量输入一段文本例如一篇新闻的前两段。点击“运行”观察画布上节点的执行状态会变成绿色。运行结束后在右侧“运行结果”中查看summary和keywords的输出。成功标准工作流能顺序执行第一个节点生成总结第二个节点基于总结提取出关键词并正确输出结果。这证明 Dify 的工作流引擎和变量传递机制工作正常。5.3 测试三创建并测试知识库RAGRAG 是 Dify 的另一个王牌功能用于构建基于私有文档的智能问答。创建知识库在左侧导航栏点击“知识库”然后“创建知识库”。命名为“测试文档库”。上传文档进入知识库后点击“上传文件”。支持 TXT、PDF、Word、PPT、Excel、Markdown 等多种格式。上传一个你准备好的文档例如一份产品说明书或一篇技术文章。处理与索引上传后Dify 会自动对文档进行分块、向量化并存入向量数据库。等待状态变为“已索引”。在应用中启用知识库回到之前创建的“测试助手”对话应用。在应用配置页面找到“工具”区域点击“添加工具”选择“知识库”。选择你刚创建的“测试文档库”。进行知识库问答测试再次进入该应用的“预览”界面。提问一个与你上传文档内容相关的问题。例如如果文档是关于 Dify 的可以问“Dify 支持哪些部署方式”观察回答。理想的回答应该基于你上传的文档内容并且 AI 会引用来源片段。成功标准AI 的回答准确引用了上传文档中的信息并且在回答下方显示了“引用”片段点击可以跳转到原文位置。这证明 RAG 管道文档解析、向量化、检索工作正常。6. 接口 API 与批量任务Dify 不仅提供 Web 界面更重要的是为每个应用提供了完整的 API方便集成到其他系统中。6.1 获取并使用 API查找 API 信息在任何你创建并发布的应用界面点击右上角的“访问 API”。查看 API 文档你会看到一个清晰的界面展示了该应用的Endpoint、API Key以及请求示例cURL, Python 等。使用 Python 调用对话应用 API 假设你创建了一个对话应用其 API 端点为https://api.dify.ai/v1/chat-messagesAPI Key 为app-xxxxxx。import requests import json url http://你的Dify服务器IP:5001/v1/chat-messages # 如果是本地部署替换为你的地址 api_key app-你的应用API-KEY # 替换为你的实际 API Key headers { Authorization: fBearer {api_key}, Content-Type: application/json } payload { inputs: {}, query: 你好请介绍一下Dify平台的主要功能。, response_mode: blocking, # 同步模式等待结果返回 conversation_id: , # 首次对话留空后续传入以保持上下文 user: test_user_001 # 用户标识 } response requests.post(url, headersheaders, jsonpayload, timeout60) if response.status_code 200: result response.json() print(回答, result.get(answer)) print(对话ID, result.get(conversation_id)) else: print(f请求失败状态码{response.status_code}) print(response.text)6.2 批量任务处理对于工作流应用你可以通过 API 轻松实现批量处理。构建支持批量输入的工作流在工作流设计时确保“开始”节点的输入变量设计合理能够接受一个列表或通过循环节点处理多个项目。通过 API 发起批量请求你可以写一个简单的脚本循环读取一批输入数据然后依次或并发地调用工作流的 API。import requests import json url http://你的Dify服务器IP:5001/v1/workflows/run # 工作流运行API api_key app-你的工作流应用API-KEY headers { Authorization: fBearer {api_key}, Content-Type: application/json } # 假设你的工作流有一个输入变量叫 article_text batch_inputs [ 文章内容1..., 文章内容2..., 文章内容3..., ] results [] for i, text in enumerate(batch_inputs): payload { inputs: { article_text: text }, response_mode: blocking, # 对于批量也可以考虑使用 streaming 或异步 user: fbatch_user_{i} } try: resp requests.post(url, headersheaders, jsonpayload, timeout120) if resp.status_code 200: result resp.json() results.append(result.get(outputs)) # 获取工作流输出 print(f任务 {i1} 完成) else: print(f任务 {i1} 失败: {resp.text}) except Exception as e: print(f任务 {i1} 请求异常: {e}) print(批量处理完成结果, results)关键点异步处理对于耗时长的工作流建议使用“response_mode”: “streaming”或调用异步接口避免 HTTP 超时。错误处理与重试在生产环境中务必为批量任务添加完善的错误处理、日志记录和重试机制。速率限制注意 Dify 后端和所接入的 LLM API 可能存在的速率限制需要在脚本中控制请求频率。7. 资源占用与性能观察了解 Dify 平台的资源消耗模式有助于进行容量规划和性能优化。1. 基础服务资源占用无本地模型使用docker stats命令可以实时查看各容器的资源使用情况。sudo docker stats --format “table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.MemPerc}}”在仅运行 Dify 平台服务不运行本地大模型的情况下典型资源占用如下PostgreSQL内存约 100-200MB。Redis内存约 30-50MB。Weaviate (向量数据库)内存占用相对较高启动后可能在 500MB-1GB 左右具体取决于索引的数据量。MinIO内存约 100MB。Dify API 服务内存约 300-500MBCPU 使用率随请求量变化。Dify Web 服务内存约 100-200MB。总计一个基础的 Dify 平台空闲时内存占用大约在1.5GB - 2.5GB之间。这是平台运行的成本。2. 接入本地模型后的资源占用如果你通过“模型负载”功能或集成 Ollama 在本地运行大模型那么主要的资源消耗将来自模型本身。CPU 推理例如运行 7B 参数的模型可能需要 8GB 以上的系统内存推理速度较慢。GPU 推理这是推荐的方式。显存占用完全取决于加载的模型大小。7B 模型INT4量化约 4-6GB 显存。13B 模型INT4量化约 8-10GB 显存。70B 模型INT4量化需要多卡或高显存显卡如 2x24G。观察方法使用nvidia-smi命令NVIDIA GPU或相应的 AMD/其他加速卡监控工具。3. 性能优化建议向量数据库选择Weaviate 功能强大但内存占用高。对于数据量小或资源紧张的环境可以考虑使用PGVector集成在 PostgreSQL 中或ChromaDB它们更轻量。Dify 支持配置不同的向量数据库。缓存策略利用 Redis 缓存频繁访问的提示词模板、会话历史或中间结果可以显著降低对 LLM 的调用次数和延迟。工作流优化避免在工作流中设计过于复杂或耗时的循环。对于可以并行执行的无依赖节点考虑使用 Dify 未来的并行执行特性或拆分成多个工作流。模型接入优化如果使用本地模型确保推理服务器如 Ollama, vLLM配置了足够的并发数并启用批处理以提升吞吐量。8. 常见问题与排查方法在部署和使用 Dify 过程中你可能会遇到一些问题。下表列出了常见问题及其解决方法。问题现象可能原因排查方式解决方案访问localhost:3000无法打开页面1. 容器未成功启动。2. 防火墙或安全组阻止了端口。3. 在服务器上部署未使用服务器 IP 访问。1.docker compose ps查看容器状态。2.docker compose logs web查看前端日志。3.curl localhost:3000在服务器本地测试。1. 根据日志修复启动错误常见于数据库连接失败。2. 开放服务器防火墙的 3000、5001 端口。3. 使用http://服务器公网IP:3000访问。应用初始化时配置模型 API Key 失败1. API Key 填写错误或余额不足。2. 网络问题无法访问模型供应商 API。3. 环境变量API_BASE_URL配置错误针对自建模型服务。1. 在模型供应商控制台检查 Key 状态。2. 在服务器上curl测试到 API 端点的连通性。3. 检查 Dify 后台“模型供应商”配置页面的 Base URL。1. 更换或充值 API Key。2. 配置服务器网络代理或使用国内可访问的模型。3. 修正环境变量或界面中的 Base URL。知识库文档上传后一直处于“处理中”或“索引中”1. 向量数据库如 Weaviate服务异常。2. 文档解析失败格式复杂或损坏。3. 系统资源内存/CPU不足。1.docker compose logs weaviate查看向量数据库日志。2. 尝试上传一个简单的纯文本.txt文件测试。3. 使用docker stats观察内存是否耗尽。1. 重启 Weaviate 容器docker compose restart weaviate。2. 将复杂文档转换为纯文本或 PDF 再尝试。3. 增加服务器资源或优化 Weaviate 配置。工作流运行时报错提示“节点执行失败”1. 节点配置错误如提示词语法问题。2. 上下游节点变量引用错误。3. 调用的外部 API 或工具不可用。1. 仔细检查报错节点的配置特别是提示词中的变量引用{{#var#}}。2. 使用工作流的“调试”模式逐步运行查看每个节点的输入输出。3. 检查工具如联网搜索的配置和网络。1. 修正提示词或变量名。2. 确保变量在之前的节点已被正确生成和命名。3. 确保外部服务可达必要时在节点前添加“判断”或“重试”逻辑。通过 API 调用应用返回超时或 5xx 错误1. 后端服务 (api) 崩溃或假死。2. 工作流执行时间过长超过 API 网关超时时间。3. 数据库连接池耗尽。1.docker compose logs api查看后端服务日志寻找错误堆栈。2. 检查 Nginx 或负载均衡器的超时设置。3. 监控数据库连接数。1. 重启后端服务docker compose restart api。2. 对于长任务使用异步调用模式 (“response_mode”: “streaming”)。3. 优化数据库配置或重启数据库服务。本地 Ollama 模型在 Dify 中连接失败1. Ollama 服务未运行或端口不对。2. Dify 中配置的 Ollama 地址不正确。3. 模型名称在 Ollama 中不存在。1. 在终端执行ollama serve确保服务运行并curl http://localhost:11434/api/tags测试。2. 在 Dify “模型供应商”配置中检查 Ollama 的 Base URL如http://host.docker.internal:11434用于 Docker 内访问宿主机。3. 在 Ollama 中ollama list确认模型已拉取。1. 确保 Ollama 服务正常运行。2. 在 Docker 网络内使用宿主机的特殊域名或 IP。对于 Linux可能是http://172.17.0.1:11434。3. 通过ollama pull拉取正确的模型。9. 最佳实践与使用建议基于大量项目实践遵循以下建议可以让你的 Dify 应用更稳定、高效和安全。1. 项目结构与版本管理使用 Git将你的 Dify 工作流配置、提示词模板、知识库文档列表等通过 Dify 的“导出”功能定期备份并纳入 Git 版本管理。这便于团队协作和回滚。环境分离建立开发、测试、生产三套独立的 Dify 环境。可以使用不同的 Docker Compose 项目或直接使用 Dify Cloud 的团队协作功能。2. 提示词工程与工作流设计模块化提示词将常用的系统指令、角色设定、输出格式要求等保存为“提示词编排”中的片段在不同应用中复用。善用变量在工作流中清晰地为每个节点的输出命名并在下游节点中通过{{#node_name.output#}}格式引用使流程逻辑清晰。添加审查节点对于内容生成类应用在工作流末尾添加一个“文本审核”节点可调用另一个 LLM 或关键词过滤确保输出内容的安全性。3. 知识库优化文档预处理上传前尽量将文档清理为结构清晰、格式统一的文本。复杂的排版、图片、表格会影响解析和检索效果。分块策略根据文档类型调整知识库的“分段处理”规则。技术文档可能适合较小的块200字而小说可能适合较大的块500字。重叠区间可以保证上下文连贯。混合检索在知识库设置中启用“高质量”模式它结合了向量检索和关键词检索BM25通常能获得更准确的结果。4. 性能与成本模型选择根据任务复杂度选择模型。简单的分类、总结任务可以用小模型如 Qwen-7B复杂的创作、推理再用大模型如 GPT-4。在 Dify 中可以轻松配置模型路由。缓存对话在对话应用设置中开启“会话记忆”可以避免重复向 LLM 发送完整历史节省 Token 消耗。监控与日志定期查看 Dify 后台的“日志与标注”以及“使用情况统计”了解 API 调用量、Token 消耗和用户反馈优化应用和成本。5. 安全与合规API 密钥管理不要在代码或前端暴露 Dify 的应用 API Key。使用环境变量或密钥管理服务并通过后端服务器进行转发。访问控制Dify 支持基于团队的权限管理。为不同成员分配“所有者”、“管理员”、“编辑者”、“查看者”角色控制其对应用和知识库的操作权限。数据定期备份定期备份 Docker 卷中的数据特别是 PostgreSQL 数据库卷包含用户数据、应用配置和 MinIO 卷包含上传的文件。10. 总结与下一步Dify 的核心价值在于它极大地简化了将大模型能力转化为实际应用的过程。通过可视化的拖拽界面你可以在几小时内搭建出过去需要一个小团队开发数周才能完成的 AI 应用原型。无论是构建一个智能客服、一个内部知识库问答系统还是一个复杂的多步骤内容生成流水线Dify 都提供了从构思、开发、测试到部署的全套工具链。对于初学者最应该优先验证的功能就是工作流和知识库。从一个简单的“文本总结情感分析”双节点工作流开始再到接入一份 PDF 文档进行问答你能快速感受到 AI 应用开发的效率提升。最容易踩的坑通常集中在部署环境端口冲突、镜像拉取失败和模型接入API Key 错误、网络不通、本地 Ollama 连接配置。按照本文的部署和排查步骤大部分问题都能解决。掌握了基础之后下一步可以深入探索 Dify 的更多高级特性Agent 能力尝试构建能自动调用搜索引擎、计算器、代码解释器等工具的智能体。MCP 集成探索 Model Context Protocol连接更多外部工具和数据源。插件市场关注 Dify 的插件生态使用社区贡献的插件快速扩展功能。企业级功能研究单点登录SSO、审计日志、更精细的权限控制等为项目上生产环境做好准备。Dify 的社区非常活跃遇到问题时查阅官方文档和 GitHub Issues 通常能找到答案。现在你可以关闭这篇教程打开浏览器开始你的第一个 Dify 项目了。建议将本文收藏在部署和开发过程中遇到具体问题时再回来查阅相应的章节。