30款热门AI模型一站整合DeepSeek/GLM/Claude 随心用限时 5 折。 点击领海量免费额度Dify 是一个开源的 AI 应用开发平台由 LangGenius 团队维护它让你能通过可视化拖拽的方式快速构建和部署生产级的 AI 应用。如果你觉得直接调用大模型 API 太“原始”想搭建一个带知识库的问答机器人、一个自动化的内容生成流程或者一个复杂的多步骤 AI Agent但又不想从零开始写代码那么 Dify 就是为你准备的。它的核心是Agentic 工作流和RAG Pipeline。简单说你可以像搭积木一样把大模型调用、知识库检索、代码执行、条件判断等节点连接起来形成一个完整的 AI 应用。无论是个人开发者想快速验证想法还是企业团队需要构建稳定、可观测的 AI 服务Dify 都提供了一站式解决方案。它支持对接 OpenAI、Claude、国内各大模型以及本地部署的模型如通过 Ollama让你能灵活选择算力来源。这篇文章将带你从零开始彻底搞懂 Dify。我们会先快速了解它的核心能力然后完成本地部署接着通过构建一个实际的 AI 工作流来验证其功能最后探讨如何将其集成到你的项目中。无论你是零基础的 AI 爱好者还是有一定经验的开发者都能通过本文快速上手。1. 核心能力速览在深入细节之前我们先通过一个表格快速把握 Dify 的核心特性和门槛让你判断它是否适合你当前的需求。能力项说明项目类型开源 AI 应用开发平台 / 低代码工作流构建工具核心功能1.可视化工作流Workflow拖拽式构建复杂 AI 流程。2.RAG 引擎构建知识库实现基于文档的智能问答。3.Agent 框架支持工具调用、推理等 Agent 能力。4.模型集成无缝接入 OpenAI、Claude、通义千问、智谱、Ollama 等数十种模型。5.应用发布一键发布为 Web App 或 API 服务。部署方式Docker 一键部署、源码部署、云服务SaaS硬件门槛极低。核心服务本身对 GPU 无要求资源消耗取决于你集成的模型。本地测试用 CPU 和 4GB 内存即可启动平台。运行大模型时才需要对应 GPU/算力。是否支持 API是。所有构建的应用都自动提供 RESTful API方便集成。是否支持批量任务是。工作流天然支持批量处理可通过 API 触发并发任务。适合场景快速原型验证、企业级 AI 应用开发、构建智能客服/知识库、自动化内容生成、内部工具开发等。从表格可以看出Dify 的定位非常清晰降低 AI 应用开发的门槛。它把模型调用、流程编排、知识库管理、应用部署这些繁琐的工程化工作封装起来让你能专注于业务逻辑和提示词工程。2. 适用场景与使用边界Dify 不是万能的理解它的边界能帮你更好地利用它。它非常适合以下场景快速构建 AI 原型比如你想做一个根据公司内部文档自动回答问题的机器人用 Dify 的 RAG 功能几小时就能搭出可用的 Demo。构建复杂 AI 工作流例如一个营销内容生成流程输入主题 - 联网搜索最新信息 - 生成文案大纲 - 调用文生图模型配图 - 格式化输出。这种多步骤、有条件分支的流程用可视化工作流搭建比写代码高效得多。为企业提供标准化 AI 能力Dify 支持多租户、权限管理、使用量监控适合作为团队内部的 AI 能力中台。集成现有业务系统通过 API 将 Dify 构建的 AI 应用如合同审核、工单分类嵌入到现有的 OA、CRM 系统中。它可能不适合需要极致性能调优的底层模型研发Dify 专注于应用层编排不涉及模型训练、微调或底层推理框架的深度定制。完全定制化的前端界面虽然 Dify 提供 Web App但如果你需要高度定制化的 UI/UX可能需要基于其 API 自行开发前端。离线、无网络环境的部署Dify 的某些功能如插件市场可能需要联网完全离网部署需要额外配置。合规与安全提醒使用 Dify 时尤其是处理企业数据或个人隐私信息时务必注意数据安全如果使用云端大模型 API如 OpenAI你的数据会离开本地环境。对于敏感数据务必使用支持本地化部署的模型或通过私有化部署的 API 网关。版权与授权使用 Dify 生成文本、图像等内容时需确保生成内容不侵犯他人版权并遵守相关平台的使用政策。模型合规确保你接入的模型服务符合当地法律法规。3. 环境准备与前置条件在安装 Dify 之前请确保你的环境满足以下基本要求。这里我们以最常见的Docker 部署方式为例这也是官方推荐的方式。基础环境要求操作系统Linux (Ubuntu 20.04, CentOS 7), macOS, 或 Windows 10/11 (需要 WSL2 或 Docker Desktop)。Docker版本 20.10.0 或更高。这是必须的。Docker Compose版本 2.0.0 或更高。通常安装 Docker Desktop 时会自带。硬件资源CPU2 核或以上。内存至少 4 GB。如果要同时运行本地大模型如通过 Ollama则需要更多。磁盘空间至少 10 GB 可用空间用于存放 Docker 镜像、数据库和向量数据库。网络能够访问 Docker Hub 和 GitHub 以下载镜像和源码。验证 Docker 环境打开终端或 PowerShell运行以下命令检查 Docker 和 Docker Compose 是否就绪。# 检查 Docker 版本 docker --version # 检查 Docker Compose 版本 docker compose version # 运行一个测试容器验证 Docker 服务正常 docker run hello-world如果hello-world容器能成功运行并输出信息说明 Docker 环境准备就绪。4. 安装部署与启动方式Dify 提供了多种部署方式对于绝大多数用户使用 Docker Compose 一键部署是最简单、最推荐的方式。它能自动处理好数据库、前端、后端等所有依赖。步骤 1获取部署文件在你想安装的目录下执行以下命令克隆部署仓库如果网络较慢也可以直接下载 ZIP 包。# 克隆部署仓库 git clone https://github.com/langgenius/dify.git cd dify/dockerdocker目录下包含了所有部署所需的配置文件。步骤 2启动 Dify 服务在docker目录中运行一条命令即可启动所有服务。# 在 docker 目录下执行 docker compose up -d这条命令会拉取 PostgreSQL、Redis、Web 服务、API 服务等所有必要的 Docker 镜像并在后台启动它们。首次运行需要下载镜像时间取决于你的网速。步骤 3访问并初始化服务启动完成后打开浏览器访问http://localhost:3000。你将看到 Dify 的初始化页面。按照指引设置管理员账号、密码并配置初始的模型供应商例如填入你的 OpenAI API Key或选择“本地模型”如 Ollama。完成初始化后即可登录进入 Dify 控制台。步骤 4验证服务状态你可以通过以下命令检查各个容器是否正常运行。# 查看所有容器状态 docker compose ps # 查看服务日志CtrlC 退出 docker compose logs -f正常情况下你应该看到api、worker、web等服务的状态都是Up。至此Dify 平台就已经在你的本地或服务器上运行起来了。整个过程通常只需要 5-10 分钟。5. 功能测试与效果验证构建你的第一个 AI 工作流平台跑起来了我们通过构建一个实际的 AI 工作流来验证 Dify 的核心功能。这个例子是一个“智能内容优化助手”输入一篇草稿工作流会自动检查语法、优化措辞并生成三个不同风格的标题建议。5.1 创建新应用登录 Dify 控制台点击“创建应用”。选择“工作流”类型命名为“内容优化助手”。5.2 搭建工作流进入工作流画布你会看到一个空的起点Start和终点End。我们从左侧的节点库拖拽组件来构建流程。节点 1文本输入拖入一个Question Input节点连接到Start。将其命名为“文章草稿”作为用户输入。节点 2LLM 调用语法检查拖入一个LLM节点。连接将“文章草稿”节点的输出连接到该 LLM 节点的输入。配置选择模型提供商如 OpenAI 的 GPT-4。在系统提示词中填写“你是一名专业的文本编辑。请检查以下文本的语法和拼写错误并给出修改建议。只输出修改后的文本。”在用户提示词中引用变量{{#文章草稿.query#}}节点 3LLM 调用风格优化再拖入一个LLM节点。连接将上一个 LLM 节点语法检查的输出连接到本节点。配置选择模型。系统提示词“你是一名资深撰稿人。请将以下文本优化得更流畅、更具吸引力保持原意。”用户提示词引用上一个节点的输出变量例如{{#LLM_1.output#}}。节点 4LLM 调用生成标题拖入第三个LLM节点。连接同样连接到“风格优化”节点的输出。配置系统提示词“基于以下文章内容生成三个风格迥异的标题建议1个严肃专业型1个轻松网络型1个疑问引发思考型。”用户提示词引用{{#LLM_2.output#}}。节点 5答案输出拖入一个Answer节点连接到“生成标题”节点。它将把最终结果返回给用户。最终你的工作流画布应该类似下图文字描述结构[Start] - [文章草稿输入] - [语法检查 LLM] - [风格优化 LLM] - [生成标题 LLM] - [Answer] - [End]5.3 运行测试点击画布右上角的“保存”。点击“发布”按钮将工作流发布为一个版本。在应用概览页找到“预览”或“测试”区域。在输入框粘贴一段文本例如“人工智能是未来科技发展的核心驱动力它正在改变我们生活和工作的方式。”点击“运行”。预期结果几秒钟后你将获得一个结构化的输出包含语法检查后的文本。优化后的流畅文本。三个不同风格的标题建议。这个简单的测试验证了 Dify 工作流的几个关键能力多节点串联、变量传递、灵活的 LLM 调用。你可以看到无需编写任何代码我们就构建了一个包含多个 AI 处理步骤的复杂流程。6. 深入核心功能RAG 知识库与 Agent除了基础的工作流Dify 还有两个杀手锏功能RAG 知识库和 AI Agent。6.1 构建 RAG 知识库问答机器人RAG检索增强生成是让 AI 回答特定领域知识的关键。步骤在 Dify 控制台进入“知识库”模块点击“创建知识库”。命名后进入知识库详情页点击“上传文件”。支持 TXT、PDF、Word、PPT、Excel 等多种格式。上传你的文档例如公司产品手册、技术文档。系统会自动进行文本提取、分块、向量化并存入向量数据库Dify 内置了。回到“应用”模块创建一个新的“对话型”应用。在应用配置的“提示词编排”阶段开启“知识库”功能并关联你刚创建的知识库。发布应用。测试在应用预览窗提问“你们公司产品的主要优势是什么” AI 会首先从你上传的文档中检索相关信息然后结合检索到的内容生成回答答案的准确性和相关性会显著提升。6.2 创建具备工具调用能力的 AgentAgent 能通过调用外部工具如搜索、计算、API来完成任务。示例创建一个“天气查询助手”Agent创建一个“工作流”类型的新应用。在工作流中拖入Tool节点。Dify 内置了一些工具你也可以通过插件添加自定义工具例如连接一个天气 API。配置 LLM 节点在提示词中说明“你可以使用天气查询工具来获取实时天气信息。”将 LLM 节点、工具节点和Answer节点连接起来。发布后测试提问“北京今天天气怎么样” Agent 会自动识别意图调用天气工具获取数据然后组织成自然语言回复给你。7. 接口 API 与批量任务集成Dify 的核心价值之一是将你构建的 AI 应用封装成 API便于集成到其他系统或进行批量处理。7.1 获取并使用 API在 Dify 控制台进入你创建的应用页面。点击“访问 API”或“集成”选项卡。你会看到该应用的API 端点Endpoint和API 密钥。使用curl或任何编程语言都可以调用。Python 调用示例假设你构建了一个文本总结的应用。import requests import json api_key your-app-api-key-here url https://your-dify-domain/v1/chat-messages # 对话型应用端点 # 对于工作流应用端点可能是 /v1/workflows/run headers { Authorization: fBearer {api_key}, Content-Type: application/json } payload { inputs: {}, query: 请总结一下这篇长文章的主要内容...文章内容..., response_mode: blocking, # 同步模式 conversation_id: , # 新的会话 user: test_user_001 # 用户标识 } response requests.post(url, headersheaders, jsonpayload) result response.json() print(json.dumps(result, indent2, ensure_asciiFalse))7.2 处理批量任务对于需要处理大量数据的场景如批量总结1000篇文章你有两种主要方式方式一异步 API 调用将上述 Python 示例中的response_mode改为streaming或使用异步端点并结合队列系统如 Celery、RabbitMQ来管理任务避免阻塞。方式二利用工作流的批量处理能力在工作流起始节点配置一个“变量”节点来接收一个列表如文章 URL 列表。在工作流内部使用“循环”或“迭代”节点如果 Dify 版本支持来处理列表中的每个元素。或者更常见的做法是在外部的脚本中循环调用 Dify 的 API。这样更灵活易于控制并发和错误重试。import concurrent.futures def process_one_item(item): # 构造针对单个 item 的请求 payload payload {inputs: {article: item}, query: 总结, ...} # 调用 Dify API # ... 处理响应和错误 return result # 假设 articles 是一个包含多篇文章内容的列表 articles [文章1内容..., 文章2内容..., ...] # 使用线程池进行并发调用注意控制速率避免触发 API 限制 with concurrent.futures.ThreadPoolExecutor(max_workers5) as executor: futures [executor.submit(process_one_item, article) for article in articles] results [f.result() for f in concurrent.futures.as_completed(futures)]8. 资源占用、性能观察与调优Dify 平台本身作为编排层资源消耗相对平稳。性能瓶颈主要出现在两个方面向量检索和大模型推理。1. 平台基础资源占用使用docker stats命令可以实时查看各容器的资源使用情况。docker stats通常api和worker服务会占用一定的 CPU 和内存各约 200-500MB。PostgreSQL 和 Redis 容器也会占用一部分内存。对于本地测试8GB 内存的机器绰绰有余。2. 知识库检索性能索引速度首次为大量文档构建向量索引时会消耗较多 CPU 和时间。建议在业务低峰期进行。检索速度取决于向量数据库的性能和文档块的数量。对于百万级以下的片段检索通常在百毫秒内完成。如果变慢可以考虑优化分块策略在知识库设置中调整块大小、重叠度。3. 模型推理性能云端 API性能取决于 OpenAI 等供应商Dify 主要负责请求转发和结果处理延迟增加很少。本地模型如 Ollama这是资源消耗的大头。运行一个 7B 参数的模型可能需要 4-8GB 的 GPU 显存或更多的 CPU 内存。你需要在 Dify 的“模型供应商”设置中正确配置本地模型的 API 地址如http://host.docker.internal:11434用于连接宿主机的 Ollama。4. 调优建议启用缓存对于重复性较高的查询可以在工作流中启用 LLM 缓存节点减少对模型的调用次数和成本。优化提示词清晰、具体的提示词能减少模型的“思考”时间Token 消耗并提高输出质量。并发控制通过 API 批量调用时务必控制并发数避免压垮本地模型服务或触发云端 API 的速率限制。监控与日志充分利用 Dify 控制台提供的“日志与标注”功能分析每次调用的耗时、Token 使用量定位性能瓶颈。9. 常见问题与排查方法在部署和使用过程中你可能会遇到一些问题。下表列出了一些常见问题及其解决方法。问题现象可能原因排查方式解决方案访问localhost:3000失败Docker 服务未成功启动端口被占用。1.docker compose ps查看容器状态。2.docker compose logs web查看前端容器日志。3.netstat -tuln | grep 3000检查端口占用。1. 确保在docker目录下执行up。2. 重启服务docker compose down docker compose up -d。3. 修改docker-compose.yaml中的端口映射如将3000:3000改为8080:3000。应用运行时报错 “Model provider not available”未配置模型供应商或配置的 API Key 错误、额度不足。1. 检查控制台“模型供应商”设置。2. 测试该 API Key 是否能在原平台正常使用。1. 在“设置”-“模型供应商”中添加并正确配置。2. 对于本地模型确保 Ollama 等服务正在运行且网络可通。知识库文件上传后问答时检索不到内容文件解析失败文本分块不合理向量化未完成。1. 进入知识库详情页查看文件处理状态是否为“已索引”。2. 检查文件内容是否被正确提取预览分段内容。1. 尝试重新上传文件或转换为纯文本格式再上传。2. 调整知识库的分段规则块大小、重叠度。3. 手动点击“重建索引”。工作流运行卡住或超时某个节点尤其是 LLM 调用响应时间过长网络问题。查看应用运行日志定位具体在哪个节点卡住。1. 为 LLM 节点设置超时时间。2. 检查模型供应商的网络连接。3. 简化工作流将复杂任务拆解。API 调用返回 401 或 403 错误API 密钥错误密钥未启用请求地址或方法不对。1. 核对应用的 API Key 是否复制正确。2. 检查 API 密钥在设置中是否处于“启用”状态。3. 对照 API 文档检查请求体和 URL。1. 重新生成 API Key。2. 确保在请求头中正确添加Authorization: Bearer api_key。3. 使用 Postman 等工具先进行正确性测试。Docker 容器启动失败提示数据库连接错误PostgreSQL 或 Redis 容器启动慢依赖服务未就绪。查看docker compose logs db或docker compose logs redis的日志。1. 增加服务启动等待时间在docker-compose.yaml中配置depends_on和健康检查。2. 最简单的方法是docker compose down -v(警告这会删除数据) 然后重新up。首次启动多等一会儿。10. 最佳实践与进阶使用建议掌握了基础操作后遵循一些最佳实践能让你的 Dify 应用更健壮、更高效。版本控制与回滚在修改生产环境的应用前务必先创建一个新版本进行测试。Dify 支持应用版本管理测试无误后再发布新版本有问题可快速回滚。环境隔离使用不同的配置如docker-compose.override.yml来区分开发、测试和生产环境避免数据混淆。数据备份定期备份 Docker 卷中的数据特别是 PostgreSQL 数据库卷通常名为dify-db-data里面存储了你的应用配置、知识库元数据和对话记录。# 备份数据库示例需在宿主机执行 docker exec -t dify-db-1 pg_dump -U postgres dify dify_backup_$(date %Y%m%d).sql提示词工程Dify 的核心是编排但提示词质量直接决定 AI 的输出。花时间精心设计系统提示词和上下文使用“变量”功能让提示词动态化。多利用“上下文”功能向模型传递关键信息。利用插件生态关注 Dify 的插件市场将常用的工具如搜索引擎、代码执行器、第三方 API集成进来能极大扩展工作流的能力边界。监控与迭代养成查看“日志与标注”的习惯。分析失败案例对提示词和工作流进行持续优化。Dify 的可观测性功能是迭代改进的利器。Dify 将 AI 应用开发的工程复杂度封装在了直观的可视化界面之后。它可能不是所有场景的最优解但对于需要快速构建、迭代和部署 AI 能力的个人开发者或团队来说它是一个能极大提升效率的“杠杆”。从今天开始尝试用 Dify 将你的下一个 AI 想法变成可运行、可分享、可集成的现实应用吧。 30款热门AI模型一站整合DeepSeek/GLM/Claude 随心用限时 5 折。 点击领海量免费额度