这次我们来看一个能让你快速搭建 AI 应用和智能体的平台——Dify。它不是单一模型而是一个开源的 AI 应用开发框架核心是让你通过可视化工作流和知识库把大模型能力快速变成可用的应用。对于想入门 AI 应用开发、又不想从零写代码的开发者来说Dify 提供了一个低门槛的起点。Dify 最值得关注的点在于它的“一体化”和“可落地”。它集成了模型接入、提示词编排、知识库检索增强RAG、工作流自动化以及应用发布整个流程在一个 Web 界面上就能完成。这意味着即使你对后端部署和 API 调用不熟也能通过拖拽搭建一个具备复杂逻辑的 AI 应用。本文将带你走通从零部署 Dify 到搭建知识库、发布 AI 应用的全过程重点解决“怎么装”、“怎么用”、“怎么发布”这三个核心问题。本文适合所有对 AI 应用开发感兴趣的开发者、产品经理或技术爱好者。无论你是想为团队内部搭建一个智能问答助手还是想探索 RAG 知识库的构建亦或是学习如何将大模型能力产品化Dify 都是一个极佳的实践工具。我们将从最基础的环境准备开始确保每一步都有明确的操作和验证方法。1. 核心能力速览在深入操作之前我们先通过一个表格快速了解 Dify 的核心能力与门槛这有助于你判断它是否适合你的需求。能力项说明项目类型开源 AI 应用开发平台 / 框架核心功能可视化工作流编排、知识库RAG管理、多模型接入、应用发布与监控部署方式Docker 一键部署推荐、源码部署硬件门槛最低配置2核 CPU4GB 内存仅运行平台。推荐配置4核 CPU8GB 内存如有知识库嵌入需求CPU性能越高越好。注意Dify 本身不直接消耗大量 GPU 显存其计算负载取决于接入的大模型如 OpenAI API 或本地部署的模型。是否支持 API是平台本身提供完整的 RESTful API 用于管理应用、调用工作流。是否支持批量任务是通过工作流可以设计循环和批量处理逻辑也可通过 API 批量调用。适合场景快速原型验证、企业内部智能助手、基于文档的问答系统、多步骤 AI 自动化流程开发。简单来说Dify 把 AI 应用开发的“脏活累活”封装好了你只需要关心业务逻辑和提示词设计。它支持接入 OpenAI、Azure、 Anthropic 等云端模型也支持通过 OpenAI 兼容的 API 接入本地部署的模型如 Ollama、 LocalAI 等灵活性很高。2. 适用场景与使用边界Dify 不是一个“万能”工具明确它的边界能帮你更好地利用它。它非常适合以下场景快速构建智能对话机器人无论是客服机器人、行业顾问还是娱乐聊天都可以通过提示词工程和工作流快速搭建。构建企业知识库问答系统这是 Dify 的强项。你可以上传公司文档、产品手册、规章制度构建一个能准确回答内部问题的知识库助手。开发多步骤 AI 自动化流程例如一个工作流可以接收用户输入 - 调用模型生成文案 - 调用另一个模型审核文案 - 将结果通过邮件或 Webhook 发送出去。AI 应用原型验证在产品早期用 Dify 快速做出一个可交互的 Demo验证想法和用户反馈成本极低。它可能不适合或需要注意的场景超高性能、高并发生产环境对于千万级日活的 C 端应用Dify 作为中间层可能需要更深入的性能调优和架构改造。需要深度定制算法模型Dify 专注于应用层编排如果你需要修改模型底层结构或训练自定义模型它无法直接满足。完全离线的封闭环境虽然可以本地部署但其许多功能如嵌入模型、语音合成默认依赖互联网下载模型或调用云端服务。完全离线需要自行部署所有相关模型服务并修改配置复杂度较高。数据安全与合规当处理敏感数据如个人隐私、商业机密时需谨慎评估。尽管可以本地部署但知识库的嵌入向量生成、模型调用等环节的数据流转需清晰界定确保符合相关法规。务必使用经合法授权的数据构建知识库。3. 环境准备与前置条件为了让部署过程顺畅请先确保你的环境满足以下要求。我们将以最常用的Docker 部署方式为例进行说明。操作系统Linux (Ubuntu 20.04/22.04, CentOS 7/8), macOS, 或 Windows 10/11 (需 WSL 2)。本文以 Ubuntu 22.04 为例其他系统原理相通。Docker 与 Docker Compose这是必须的。确保已安装并启动 Docker 服务。检查 Docker 安装docker --version检查 Docker Compose 安装docker compose version(注意是compose不是docker-compose)硬件资源CPU至少 2 核处理知识库文档嵌入时建议 4 核以上。内存至少 4GB推荐 8GB 或以上。内存大小直接影响知识库处理速度和并发能力。磁盘空间至少 10GB 可用空间用于存放 Docker 镜像、数据库和上传的文档。网络能够访问 Docker Hub 和 GitHub 以下载镜像和代码。如果需要接入 OpenAI 等云端 API则需要相应的网络访问能力。端口Dify 默认使用80(HTTP) 和443(HTTPS) 端口。请确保这些端口未被占用如 Nginx, Apache。也可以通过修改配置使用其他端口。环境检查清单在终端中执行以下命令确认关键组件就绪。# 1. 检查 Docker docker --version # 预期输出类似Docker version 24.0.7, build afdd53b # 2. 检查 Docker Compose docker compose version # 预期输出类似Docker Compose version v2.23.0 # 3. 检查端口占用 (例如检查80端口) sudo lsof -i:80 # 如果无输出则表示端口空闲如果有输出则需考虑停止相关服务或修改Dify端口。 # 4. 检查磁盘空间 df -h /4. 安装部署与启动方式我们将采用官方推荐的 Docker Compose 方式进行一键部署这是最快捷、依赖问题最少的方式。步骤 1获取部署文件打开终端克隆 Dify 的部署仓库或直接下载docker-compose.yaml文件。# 创建一个工作目录并进入 mkdir dify-deploy cd dify-deploy # 从官方仓库下载 docker-compose 配置文件 curl -O https://raw.githubusercontent.com/langgenius/dify/main/docker/docker-compose.yaml # 下载环境变量配置文件示例 curl -O https://raw.githubusercontent.com/langgenius/dify/main/docker/.env.example步骤 2配置环境变量.env.example文件包含了所有可配置项。我们复制一份并修改关键配置。# 复制示例文件为正式配置文件 cp .env.example .env # 编辑 .env 文件这里使用 nano 编辑器你也可以用 vim 或直接图形化编辑 nano .env在打开的.env文件中你需要重点关注以下几项其他可暂时保持默认OPENAI_API_KEY如果你打算使用 OpenAI 的模型如 GPT-4在此填入你的 API Key。如果暂时没有或想先用免费模型测试可以先留空或注释掉后续在 Dify 界面中配置。DB_PASSWORD为 PostgreSQL 数据库设置一个强密码。SECRET_KEY用于加密会话的密钥建议使用一个长随机字符串。你可以用命令openssl rand -base64 32生成一个。CONSOLE_API_URL和APP_API_URL通常保持默认的http://localhost:5001即可除非你计划通过域名访问。步骤 3启动 Dify 服务配置完成后使用 Docker Compose 启动所有服务。# 在包含 docker-compose.yaml 和 .env 的目录下执行 sudo docker compose up -d-d参数表示在后台运行。命令执行后Docker 会开始拉取 PostgreSQL、Redis、Nginx 和 Dify 自身的镜像并启动容器。首次运行可能需要几分钟时间。步骤 4验证服务状态启动完成后检查容器是否正常运行。# 查看所有容器状态 sudo docker compose ps # 查看 Dify 主服务的日志确认启动无误 sudo docker compose logs -f dify-api当在日志中看到类似Application startup complete.或Uvicorn running on http://0.0.0.0:5001的信息时说明服务已成功启动。步骤 5访问 Web 界面打开你的浏览器访问http://你的服务器IP地址。如果你在本地部署直接访问http://localhost。 首次访问你将进入初始化页面需要创建第一个管理员账户。按照提示输入邮箱和密码即可完成初始化登录。至此Dify 平台已经安装并运行起来。接下来我们进入核心的功能测试环节。5. 功能测试与效果验证登录后你会看到 Dify 的控制台。我们从最简单的对话应用开始逐步测试到知识库和工作流。5.1 测试一创建并测试基础对话应用这个测试的目的是验证 Dify 平台基础功能是否正常以及模型接入是否成功。创建应用在控制台点击“创建应用”选择“对话型应用”输入应用名称例如“测试助手”。配置模型进入应用后在“模型与提示词”区域点击“添加模型”。如果你配置了OPENAI_API_KEY可以直接选择 OpenAI 提供的模型如gpt-3.5-turbo。如果你没有 OpenAI API Key可以选择“其他模型服务商”并添加一个“Ollama”或“OpenAI 兼容”的模型。这里以使用本地 Ollama 为例假设你已在本地http://localhost:11434运行了 Ollama 并拉取了qwen2.5:7b模型。在 Dify 的“模型供应商”处选择“其他”。模型类型选“文本生成”。模型名称自定义如local-qwen。服务器 URL 填写http://host.docker.internal:11434这是从 Docker 容器内部访问宿主机服务的特殊域名。模型名称填写qwen2.5:7b。保存配置。编写提示词在提示词编排区输入一个简单的系统提示词例如“你是一个乐于助人的助手请用简洁明了的语言回答用户的问题。”对话测试在页面右侧的“预览与调试”窗口输入一个问题如“请介绍一下你自己。”点击发送。成功现象几秒后你应该能收到一个连贯的、符合提示词风格的回复。失败排查如果长时间无响应或报错检查模型配置的 URL 和模型名称是否正确。查看 Docker 容器日志sudo docker compose logs dify-api看是否有连接超时或认证错误。确认 Ollama 服务是否在宿主机上正常运行 (curl http://localhost:11434/api/tags)。5.2 测试二构建与测试知识库RAG知识库是 Dify 的核心功能。我们来创建一个能回答特定领域问题的小型知识库。创建知识库在左侧菜单进入“知识库”点击“创建知识库”命名为“产品手册测试”。上传文档进入知识库后点击“上传文件”。准备一个简单的 Markdown 或 TXT 文件作为测试素材例如创建一个product_guide.md文件内容如下# 智能咖啡机用户指南 本产品型号为 CoffeeMaster 3000。 主要功能包括现磨咖啡、奶泡制作、预约冲泡、手机App控制。 清洁方法每周需清空渣盒每月使用专用清洁片清洗内部管路。 售后服务电话400-123-4567。上传该文件。Dify 会自动对文档进行“分段”和“索引”即生成嵌入向量并存入向量数据库。这个过程需要一些时间取决于文档大小和你的 CPU 性能。配置检索策略在知识库设置中可以调整“分段处理”规则和“检索”模式。初次测试可先用默认设置。在应用中启用知识库回到刚才创建的“测试助手”应用。在“工具”区域点击“添加工具”选择“知识库检索”。然后关联我们刚创建的“产品手册测试”知识库。测试知识库问答再次进入“预览与调试”。输入一个知识库内有明确答案的问题例如“CoffeeMaster 3000 的售后服务电话是多少”成功现象助手应该能准确回答出“400-123-4567”并且在回复下方会显示“引用”部分标明答案来源于你上传的文档片段。这证明了 RAG 流程检索-增强-生成工作正常。输入一个知识库外**的问题例如“今天天气怎么样”预期现象助手可能会根据其基础模型能力回答且不会显示引用。或者如果你在提示词中限制了只回答知识库内容它可能会说“我无法回答该问题”。高级测试尝试上传 PDF、Word 文档测试多格式支持。上传多个文档测试跨文档检索能力。5.3 测试三设计与运行工作流工作流允许你将多个步骤模型调用、代码、条件判断等连接起来实现复杂逻辑。创建工作流在控制台点击“创建应用”这次选择“工作流型应用”命名为“内容审核流水线”。设计工作流进入工作流画布。我们从左侧拖拽节点构建一个简单流程开始节点拖入一个“开始”节点。LLM 节点拖入一个“大语言模型”节点连接到开始节点。将其配置为使用你的对话模型如 GPT-3.5 或本地 Qwen提示词设为“请根据以下用户输入生成一段产品推广文案。用户输入{{input}}”关键词检查节点拖入一个“代码”节点连接到 LLM 节点之后。在代码节点中我们可以用 Python 写一个简单的检查逻辑示例# 输入参数是上游 LLM 节点的输出我们假设它叫 generated_text text inputs[generated_text] banned_words [免费, 点击, 立即购买] # 假设的违禁词列表 for word in banned_words: if word in text: # 如果包含违禁词输出一个标记 return {contains_banned_word: True, checked_text: text} # 如果不包含输出另一个标记 return {contains_banned_word: False, checked_text: text}条件分支节点拖入一个“条件判断”节点连接到代码节点。设置条件为{{contains_banned_word}} 等于 True。两个回答节点将条件节点的“真”分支连接到一个“回答”节点其内容设为“文案生成失败包含违禁词汇。”将条件节点的“假”分支连接到另一个“回答”节点其内容设为“文案生成成功{{checked_text}}”运行测试保存工作流后在右侧调试面板的“变量输入”中为input赋值例如“一款新的智能手机”。点击“运行”。工作流将依次执行生成文案 - 检查违禁词 - 根据结果返回不同信息。成功现象你能在“运行记录”中看到每个节点的执行状态和输入输出最终得到符合预期的回答。失败排查如果某个节点报错红色点击该节点查看详细错误信息。常见问题包括变量名引用错误、代码语法错误、模型调用超时等。通过以上三个测试你已经验证了 Dify 最核心的对话、知识库和工作流功能。接下来我们看看如何通过 API 来批量使用这些能力。6. 接口 API 与批量任务Dify 为每个创建的应用都提供了 API方便集成到其他系统或进行批量处理。6.1 获取 API 密钥与端点在 Dify 控制台进入任意一个应用如“测试助手”。点击顶部导航栏的“发布”。在“API 访问”部分你会看到API 密钥需要创建一个新的密钥或使用已有的。API 地址通常是http://你的Dify域名/v1或http://localhost/v1本地部署。应用编号每个应用唯一的app_id。记下这三项信息下面调用时会用到。6.2 调用对话应用 API以下是一个使用 Pythonrequests库调用对话型应用的示例。假设我们想批量向助手提问。import requests import json # 配置参数 api_key “你的-API-密钥” # 替换为你的实际密钥 base_url “http://localhost/v1” # 替换为你的 Dify 地址 app_id “你的-应用-ID” # 替换为你的应用 ID endpoint f“{base_url}/chat-messages” headers { “Authorization”: f“Bearer {api_key}”, “Content-Type”: “application/json” } # 准备批量问题 questions [ “Dify 是什么”, “如何搭建一个知识库”, “工作流有什么作用” ] answers [] for q in questions: payload { “inputs”: {}, “query”: q, “response_mode”: “blocking”, # 同步模式等待结果返回 “conversation_id”: “”, # 留空创建新会话 “user”: “batch_test_user_001” # 用户标识 } try: response requests.post(endpoint, headersheaders, jsonpayload, timeout60) response.raise_for_status() # 检查HTTP错误 result response.json() answer_text result.get(‘answer’, ‘No answer found’) answers.append({‘question’: q, ‘answer’: answer_text}) print(f“Q: {q} \nA: {answer_text}\n{‘-’*30}”) except requests.exceptions.RequestException as e: print(f“请求失败 for ‘{q}’: {e}”) answers.append({‘question’: q, ‘answer’: f“Error: {e}”}) # 后续可以保存 answers 到文件 with open(‘batch_qa_results.json’, ‘w’, encoding‘utf-8’) as f: json.dump(answers, f, ensure_asciiFalse, indent2)关键参数说明response_mode:blocking同步等待结果或streaming流式适合前端展示。conversation_id: 用于维持多轮对话上下文。同一会话传入相同 ID。user: 用于区分不同终端用户便于后续分析。6.3 调用工作流应用 API工作流应用的调用与对话应用类似但端点和使用参数不同。import requests api_key “你的-API-密钥” base_url “http://localhost/v1” app_id “你的-工作流应用-ID” # 注意这里是工作流应用的ID endpoint f“{base_url}/workflows/{app_id}/run” headers { “Authorization”: f“Bearer {api_key}”, “Content-Type”: “application/json” } # 根据工作流定义的输入变量来构造 payload # 假设我们的“内容审核流水线”工作流只有一个输入变量叫 input payload { “inputs”: { “input”: “这款全新的智能手表现在免费试用点击链接立即购买” }, “response_mode”: “blocking”, “user”: “api_user_001” } response requests.post(endpoint, headersheaders, jsonpayload, timeout120) if response.status_code 200: result response.json() print(“工作流执行成功”) print(“输出:”, result.get(‘data’, {}).get(‘outputs’)) # 工作流的输出可能在 ‘outputs’ 字段中具体结构取决于工作流终点的设置 else: print(“工作流执行失败:”, response.status_code, response.text)通过 API你可以轻松地将 Dify 应用集成到你的业务系统或编写脚本进行大规模的批量数据处理和测试。7. 资源占用与性能观察Dify 平台本身的资源消耗相对平稳性能瓶颈主要出现在两个环节知识库文档处理和大模型调用。平台基础服务占用启动后通过docker stats命令可以查看各容器的实时资源占用。dify-api和dify-web容器通常各占用 200-500MB 内存CPU 占用较低。postgres容器内存占用约 100-200MB。redis容器内存占用约 50-100MB。总体而言平台空闲时内存占用约 1GB 左右。知识库处理性能观察CPU 密集型当上传文档并触发“索引”时嵌入模型如text-embedding-ada-002或本地嵌入模型会全力运行此时 CPU 使用率会飙升。这是正常现象。内存影响处理大量或大型文档如数百页 PDF时内存占用会显著增加主要用于缓存文本和向量计算。优化建议将大文档拆分成多个小文件上传。在系统负载低时如夜间进行批量文档索引。考虑使用性能更好的 CPU 或配置更高内存。模型调用性能观察网络延迟如果使用云端 API如 OpenAI响应时间主要受网络延迟和 API 服务端影响。本地模型资源如果通过 Ollama 等调用本地大模型则消耗的是本地 GPU/CPU 和内存资源。此时需要监控 Ollama 服务所在的机器资源。并发限制Dify 默认配置对并发请求有一定限制。如需高并发需要调整后端服务的WORKER数量和相关配置如docker-compose.yaml中dify-api服务的环境变量WEB_CONCURRENCY。监控方法Docker 容器监控docker stats查看实时资源。Dify 内置日志在“日志与审计”中查看应用调用日志分析响应时间。系统监控使用htop,nvidia-smi(如有 GPU) 等工具监控宿主机资源。8. 常见问题与排查方法在部署和使用过程中你可能会遇到以下问题。这里提供快速的排查思路。问题现象可能原因排查方式解决方案访问http://localhost失败1. 容器未成功启动。2. 端口被占用。3. 防火墙阻止。1.docker compose ps查看容器状态。2.sudo lsof -i:80检查端口。3. 查看docker compose logs dify-nginx日志。1. 根据日志修复启动错误。2. 修改docker-compose.yaml中 nginx 的端口映射如“8080:80”。3. 配置防火墙规则。创建管理员账户时失败或无法登录1. 数据库连接失败。2. 环境变量SECRET_KEY不一致。3. 初始化未完成。1. 检查docker compose logs dify-api和dify-db日志。2. 确认.env文件中的SECRET_KEY在重启后未更改。1. 确保数据库容器正常运行密码正确。2. 保持SECRET_KEY稳定重启所有服务。3. 尝试清除浏览器缓存或使用无痕模式。上传知识库文档后一直显示“索引中”1. 嵌入模型下载慢或失败。2. 文档分段处理耗时过长。3. 向量数据库写入慢。1. 查看dify-api日志是否有网络或模型下载错误。2. 观察 CPU 使用率处理大文件需要时间。1. 检查网络或配置国内镜像源。2. 耐心等待大型 PDF 索引可能需要数十分钟。3. 尝试先上传一个小的 TXT 文件测试。调用 API 返回 401 或 403 错误1. API 密钥错误或过期。2. 应用未发布。3. 请求地址不正确。1. 检查请求头中的AuthorizationBearer Token 是否正确。2. 在 Dify 控制台确认应用已“发布”。3. 检查base_url和endpoint是否拼写正确。1. 在 Dify 中重新生成 API 密钥并更新代码。2. 进入应用点击“发布”按钮。3. 仔细核对 API 文档中的端点地址。工作流运行到某个节点报错1. 节点配置错误如变量名错误。2. 外部服务如模型 API不可用。3. 代码节点存在语法错误。1. 在工作流运行记录中点击失败节点查看详细错误信息。2. 检查模型供应商配置是否正常。1. 根据错误信息修正节点配置或代码。2. 测试模型连接是否正常。3. 在代码节点中使用print调试日志会在运行记录中显示。使用本地 Ollama 模型无响应1. Docker 容器无法访问宿主机服务。2. Ollama 未运行或模型未加载。3. 防火墙阻止。1. 在 Dify 容器内执行curl http://host.docker.internal:11434/api/tags测试连通性。2. 在宿主机执行ollama list确认模型存在。1. 确保 Ollama 在宿主机运行。对于 Linux有时需用--add-hosthost.docker.internal:host-gateway启动容器或直接使用宿主机 IP172.17.0.1。2. 拉取并运行所需模型ollama run qwen2.5:7b。平台运行一段时间后变慢或卡死1. 内存不足。2. 数据库连接池耗尽。3. 磁盘空间不足。1. 使用docker stats和free -h查看内存。2. 检查数据库日志。3. 使用df -h查看磁盘。1. 增加服务器内存或优化知识库索引策略。2. 重启 Dify 服务 (docker compose restart)。3. 清理不必要的日志和缓存文件。9. 最佳实践与使用建议为了让你的 Dify 体验更顺畅并构建出更健壮的 AI 应用这里有一些经验之谈。从简单开始迭代优化不要一开始就设计极其复杂的工作流或上传海量知识库。从一个清晰的提示词、一个简单的问答对、一个只有两三个节点的工作流开始。验证核心流程跑通后再逐步增加复杂性。提示词工程是关键Dify 的强大很大程度上依赖于你给模型的指令。花时间精心编写和调试系统提示词、用户提示词模板。利用“变量”功能{{variable}}让提示词动态化。知识库文档预处理上传前尽量对文档进行预处理。将大型 PDF 拆分为章节清除无关的页眉页脚、水印。良好的源文档质量会极大提升检索效果。善用“变量”和“上下文”在工作流中合理规划变量的传递。了解每个节点的输入输出确保数据流清晰。对于对话应用合理利用“上下文”长度在提示词中明确指示模型参考历史消息。测试与评估发布应用前务必进行充分测试。不仅测试“Happy Path”更要测试边界情况和异常输入。Dify 的“预览与调试”和“日志”功能是你的好朋友。安全与权限管理在团队中使用时利用 Dify 的“成员”和“权限”功能管理访问。对于公开应用考虑设置频率限制和内容过滤。备份与迁移定期备份你的数据库。Dify 的数据应用、知识库、对话记录主要存储在 PostgreSQL 中。了解如何使用docker compose exec执行数据库备份命令。关注资源消耗监控生产环境的资源使用情况。如果使用频繁考虑将数据库PostgreSQL和缓存Redis部署到更专业的云服务或独立服务器上以提高稳定性和性能。合规使用再次强调确保你上传到知识库的文档、用于微调的数据、以及应用生成的内容都符合版权法规和数据隐私政策。明确告知用户这是 AI 生成内容。10. 总结与下一步走完从部署、测试到 API 调用的全流程你应该已经感受到 Dify 在降低 AI 应用开发门槛上的强大能力。它把模型调用、上下文管理、知识检索、流程编排这些复杂技术封装成可视化操作让你能更专注于业务逻辑本身。最值得尝试的点无疑是它的知识库RAG和可视化工作流。前者能快速让你的应用“拥有”专业知识后者能让你设计出超越简单问答的复杂 AI 自动化流程而这两者都不需要你编写复杂的后端代码。最先应该验证的功能建议你按照本文顺序先确保基础对话和知识库问答跑通。这是大多数应用的基石。成功后可以尝试用工作流搭建一个包含条件判断和外部 API 调用的流程例如用户提问 - 知识库检索 - 模型总结 - 调用翻译 API - 返回结果。最容易踩的坑网络与连接本地模型服务Ollama与 Docker 容器的网络互通问题。配置错误环境变量.env文件配置错误尤其是数据库密码和密钥。资源不足索引大型知识库时 CPU/内存不足导致进程卡死。后续探索方向集成更多模型尝试接入 Claude、通义千问、文心一言等更多模型的 API。探索高级功能使用“函数调用”让模型能执行具体操作或探索“多模态”应用需使用支持图像的模型。性能调优学习如何调整知识库的“分段规则”和“检索参数”以在召回率和准确性之间取得最佳平衡。生产部署研究如何通过 Nginx 配置域名和 HTTPS如何设置数据库定期备份如何监控应用健康状态。Dify 就像一个 AI 应用的“乐高”平台提供了丰富的积木块。如何搭建出有趣、有用的作品现在完全取决于你的想象力。建议将本文作为手边参考在遇到具体问题时回来查阅对应的章节。 Dify开源AI应用开发平台：从零部署到RAG与工作流实战
这次我们来看一个能让你快速搭建 AI 应用和智能体的平台——Dify。它不是单一模型而是一个开源的 AI 应用开发框架核心是让你通过可视化工作流和知识库把大模型能力快速变成可用的应用。对于想入门 AI 应用开发、又不想从零写代码的开发者来说Dify 提供了一个低门槛的起点。Dify 最值得关注的点在于它的“一体化”和“可落地”。它集成了模型接入、提示词编排、知识库检索增强RAG、工作流自动化以及应用发布整个流程在一个 Web 界面上就能完成。这意味着即使你对后端部署和 API 调用不熟也能通过拖拽搭建一个具备复杂逻辑的 AI 应用。本文将带你走通从零部署 Dify 到搭建知识库、发布 AI 应用的全过程重点解决“怎么装”、“怎么用”、“怎么发布”这三个核心问题。本文适合所有对 AI 应用开发感兴趣的开发者、产品经理或技术爱好者。无论你是想为团队内部搭建一个智能问答助手还是想探索 RAG 知识库的构建亦或是学习如何将大模型能力产品化Dify 都是一个极佳的实践工具。我们将从最基础的环境准备开始确保每一步都有明确的操作和验证方法。1. 核心能力速览在深入操作之前我们先通过一个表格快速了解 Dify 的核心能力与门槛这有助于你判断它是否适合你的需求。能力项说明项目类型开源 AI 应用开发平台 / 框架核心功能可视化工作流编排、知识库RAG管理、多模型接入、应用发布与监控部署方式Docker 一键部署推荐、源码部署硬件门槛最低配置2核 CPU4GB 内存仅运行平台。推荐配置4核 CPU8GB 内存如有知识库嵌入需求CPU性能越高越好。注意Dify 本身不直接消耗大量 GPU 显存其计算负载取决于接入的大模型如 OpenAI API 或本地部署的模型。是否支持 API是平台本身提供完整的 RESTful API 用于管理应用、调用工作流。是否支持批量任务是通过工作流可以设计循环和批量处理逻辑也可通过 API 批量调用。适合场景快速原型验证、企业内部智能助手、基于文档的问答系统、多步骤 AI 自动化流程开发。简单来说Dify 把 AI 应用开发的“脏活累活”封装好了你只需要关心业务逻辑和提示词设计。它支持接入 OpenAI、Azure、 Anthropic 等云端模型也支持通过 OpenAI 兼容的 API 接入本地部署的模型如 Ollama、 LocalAI 等灵活性很高。2. 适用场景与使用边界Dify 不是一个“万能”工具明确它的边界能帮你更好地利用它。它非常适合以下场景快速构建智能对话机器人无论是客服机器人、行业顾问还是娱乐聊天都可以通过提示词工程和工作流快速搭建。构建企业知识库问答系统这是 Dify 的强项。你可以上传公司文档、产品手册、规章制度构建一个能准确回答内部问题的知识库助手。开发多步骤 AI 自动化流程例如一个工作流可以接收用户输入 - 调用模型生成文案 - 调用另一个模型审核文案 - 将结果通过邮件或 Webhook 发送出去。AI 应用原型验证在产品早期用 Dify 快速做出一个可交互的 Demo验证想法和用户反馈成本极低。它可能不适合或需要注意的场景超高性能、高并发生产环境对于千万级日活的 C 端应用Dify 作为中间层可能需要更深入的性能调优和架构改造。需要深度定制算法模型Dify 专注于应用层编排如果你需要修改模型底层结构或训练自定义模型它无法直接满足。完全离线的封闭环境虽然可以本地部署但其许多功能如嵌入模型、语音合成默认依赖互联网下载模型或调用云端服务。完全离线需要自行部署所有相关模型服务并修改配置复杂度较高。数据安全与合规当处理敏感数据如个人隐私、商业机密时需谨慎评估。尽管可以本地部署但知识库的嵌入向量生成、模型调用等环节的数据流转需清晰界定确保符合相关法规。务必使用经合法授权的数据构建知识库。3. 环境准备与前置条件为了让部署过程顺畅请先确保你的环境满足以下要求。我们将以最常用的Docker 部署方式为例进行说明。操作系统Linux (Ubuntu 20.04/22.04, CentOS 7/8), macOS, 或 Windows 10/11 (需 WSL 2)。本文以 Ubuntu 22.04 为例其他系统原理相通。Docker 与 Docker Compose这是必须的。确保已安装并启动 Docker 服务。检查 Docker 安装docker --version检查 Docker Compose 安装docker compose version(注意是compose不是docker-compose)硬件资源CPU至少 2 核处理知识库文档嵌入时建议 4 核以上。内存至少 4GB推荐 8GB 或以上。内存大小直接影响知识库处理速度和并发能力。磁盘空间至少 10GB 可用空间用于存放 Docker 镜像、数据库和上传的文档。网络能够访问 Docker Hub 和 GitHub 以下载镜像和代码。如果需要接入 OpenAI 等云端 API则需要相应的网络访问能力。端口Dify 默认使用80(HTTP) 和443(HTTPS) 端口。请确保这些端口未被占用如 Nginx, Apache。也可以通过修改配置使用其他端口。环境检查清单在终端中执行以下命令确认关键组件就绪。# 1. 检查 Docker docker --version # 预期输出类似Docker version 24.0.7, build afdd53b # 2. 检查 Docker Compose docker compose version # 预期输出类似Docker Compose version v2.23.0 # 3. 检查端口占用 (例如检查80端口) sudo lsof -i:80 # 如果无输出则表示端口空闲如果有输出则需考虑停止相关服务或修改Dify端口。 # 4. 检查磁盘空间 df -h /4. 安装部署与启动方式我们将采用官方推荐的 Docker Compose 方式进行一键部署这是最快捷、依赖问题最少的方式。步骤 1获取部署文件打开终端克隆 Dify 的部署仓库或直接下载docker-compose.yaml文件。# 创建一个工作目录并进入 mkdir dify-deploy cd dify-deploy # 从官方仓库下载 docker-compose 配置文件 curl -O https://raw.githubusercontent.com/langgenius/dify/main/docker/docker-compose.yaml # 下载环境变量配置文件示例 curl -O https://raw.githubusercontent.com/langgenius/dify/main/docker/.env.example步骤 2配置环境变量.env.example文件包含了所有可配置项。我们复制一份并修改关键配置。# 复制示例文件为正式配置文件 cp .env.example .env # 编辑 .env 文件这里使用 nano 编辑器你也可以用 vim 或直接图形化编辑 nano .env在打开的.env文件中你需要重点关注以下几项其他可暂时保持默认OPENAI_API_KEY如果你打算使用 OpenAI 的模型如 GPT-4在此填入你的 API Key。如果暂时没有或想先用免费模型测试可以先留空或注释掉后续在 Dify 界面中配置。DB_PASSWORD为 PostgreSQL 数据库设置一个强密码。SECRET_KEY用于加密会话的密钥建议使用一个长随机字符串。你可以用命令openssl rand -base64 32生成一个。CONSOLE_API_URL和APP_API_URL通常保持默认的http://localhost:5001即可除非你计划通过域名访问。步骤 3启动 Dify 服务配置完成后使用 Docker Compose 启动所有服务。# 在包含 docker-compose.yaml 和 .env 的目录下执行 sudo docker compose up -d-d参数表示在后台运行。命令执行后Docker 会开始拉取 PostgreSQL、Redis、Nginx 和 Dify 自身的镜像并启动容器。首次运行可能需要几分钟时间。步骤 4验证服务状态启动完成后检查容器是否正常运行。# 查看所有容器状态 sudo docker compose ps # 查看 Dify 主服务的日志确认启动无误 sudo docker compose logs -f dify-api当在日志中看到类似Application startup complete.或Uvicorn running on http://0.0.0.0:5001的信息时说明服务已成功启动。步骤 5访问 Web 界面打开你的浏览器访问http://你的服务器IP地址。如果你在本地部署直接访问http://localhost。 首次访问你将进入初始化页面需要创建第一个管理员账户。按照提示输入邮箱和密码即可完成初始化登录。至此Dify 平台已经安装并运行起来。接下来我们进入核心的功能测试环节。5. 功能测试与效果验证登录后你会看到 Dify 的控制台。我们从最简单的对话应用开始逐步测试到知识库和工作流。5.1 测试一创建并测试基础对话应用这个测试的目的是验证 Dify 平台基础功能是否正常以及模型接入是否成功。创建应用在控制台点击“创建应用”选择“对话型应用”输入应用名称例如“测试助手”。配置模型进入应用后在“模型与提示词”区域点击“添加模型”。如果你配置了OPENAI_API_KEY可以直接选择 OpenAI 提供的模型如gpt-3.5-turbo。如果你没有 OpenAI API Key可以选择“其他模型服务商”并添加一个“Ollama”或“OpenAI 兼容”的模型。这里以使用本地 Ollama 为例假设你已在本地http://localhost:11434运行了 Ollama 并拉取了qwen2.5:7b模型。在 Dify 的“模型供应商”处选择“其他”。模型类型选“文本生成”。模型名称自定义如local-qwen。服务器 URL 填写http://host.docker.internal:11434这是从 Docker 容器内部访问宿主机服务的特殊域名。模型名称填写qwen2.5:7b。保存配置。编写提示词在提示词编排区输入一个简单的系统提示词例如“你是一个乐于助人的助手请用简洁明了的语言回答用户的问题。”对话测试在页面右侧的“预览与调试”窗口输入一个问题如“请介绍一下你自己。”点击发送。成功现象几秒后你应该能收到一个连贯的、符合提示词风格的回复。失败排查如果长时间无响应或报错检查模型配置的 URL 和模型名称是否正确。查看 Docker 容器日志sudo docker compose logs dify-api看是否有连接超时或认证错误。确认 Ollama 服务是否在宿主机上正常运行 (curl http://localhost:11434/api/tags)。5.2 测试二构建与测试知识库RAG知识库是 Dify 的核心功能。我们来创建一个能回答特定领域问题的小型知识库。创建知识库在左侧菜单进入“知识库”点击“创建知识库”命名为“产品手册测试”。上传文档进入知识库后点击“上传文件”。准备一个简单的 Markdown 或 TXT 文件作为测试素材例如创建一个product_guide.md文件内容如下# 智能咖啡机用户指南 本产品型号为 CoffeeMaster 3000。 主要功能包括现磨咖啡、奶泡制作、预约冲泡、手机App控制。 清洁方法每周需清空渣盒每月使用专用清洁片清洗内部管路。 售后服务电话400-123-4567。上传该文件。Dify 会自动对文档进行“分段”和“索引”即生成嵌入向量并存入向量数据库。这个过程需要一些时间取决于文档大小和你的 CPU 性能。配置检索策略在知识库设置中可以调整“分段处理”规则和“检索”模式。初次测试可先用默认设置。在应用中启用知识库回到刚才创建的“测试助手”应用。在“工具”区域点击“添加工具”选择“知识库检索”。然后关联我们刚创建的“产品手册测试”知识库。测试知识库问答再次进入“预览与调试”。输入一个知识库内有明确答案的问题例如“CoffeeMaster 3000 的售后服务电话是多少”成功现象助手应该能准确回答出“400-123-4567”并且在回复下方会显示“引用”部分标明答案来源于你上传的文档片段。这证明了 RAG 流程检索-增强-生成工作正常。输入一个知识库外**的问题例如“今天天气怎么样”预期现象助手可能会根据其基础模型能力回答且不会显示引用。或者如果你在提示词中限制了只回答知识库内容它可能会说“我无法回答该问题”。高级测试尝试上传 PDF、Word 文档测试多格式支持。上传多个文档测试跨文档检索能力。5.3 测试三设计与运行工作流工作流允许你将多个步骤模型调用、代码、条件判断等连接起来实现复杂逻辑。创建工作流在控制台点击“创建应用”这次选择“工作流型应用”命名为“内容审核流水线”。设计工作流进入工作流画布。我们从左侧拖拽节点构建一个简单流程开始节点拖入一个“开始”节点。LLM 节点拖入一个“大语言模型”节点连接到开始节点。将其配置为使用你的对话模型如 GPT-3.5 或本地 Qwen提示词设为“请根据以下用户输入生成一段产品推广文案。用户输入{{input}}”关键词检查节点拖入一个“代码”节点连接到 LLM 节点之后。在代码节点中我们可以用 Python 写一个简单的检查逻辑示例# 输入参数是上游 LLM 节点的输出我们假设它叫 generated_text text inputs[generated_text] banned_words [免费, 点击, 立即购买] # 假设的违禁词列表 for word in banned_words: if word in text: # 如果包含违禁词输出一个标记 return {contains_banned_word: True, checked_text: text} # 如果不包含输出另一个标记 return {contains_banned_word: False, checked_text: text}条件分支节点拖入一个“条件判断”节点连接到代码节点。设置条件为{{contains_banned_word}} 等于 True。两个回答节点将条件节点的“真”分支连接到一个“回答”节点其内容设为“文案生成失败包含违禁词汇。”将条件节点的“假”分支连接到另一个“回答”节点其内容设为“文案生成成功{{checked_text}}”运行测试保存工作流后在右侧调试面板的“变量输入”中为input赋值例如“一款新的智能手机”。点击“运行”。工作流将依次执行生成文案 - 检查违禁词 - 根据结果返回不同信息。成功现象你能在“运行记录”中看到每个节点的执行状态和输入输出最终得到符合预期的回答。失败排查如果某个节点报错红色点击该节点查看详细错误信息。常见问题包括变量名引用错误、代码语法错误、模型调用超时等。通过以上三个测试你已经验证了 Dify 最核心的对话、知识库和工作流功能。接下来我们看看如何通过 API 来批量使用这些能力。6. 接口 API 与批量任务Dify 为每个创建的应用都提供了 API方便集成到其他系统或进行批量处理。6.1 获取 API 密钥与端点在 Dify 控制台进入任意一个应用如“测试助手”。点击顶部导航栏的“发布”。在“API 访问”部分你会看到API 密钥需要创建一个新的密钥或使用已有的。API 地址通常是http://你的Dify域名/v1或http://localhost/v1本地部署。应用编号每个应用唯一的app_id。记下这三项信息下面调用时会用到。6.2 调用对话应用 API以下是一个使用 Pythonrequests库调用对话型应用的示例。假设我们想批量向助手提问。import requests import json # 配置参数 api_key “你的-API-密钥” # 替换为你的实际密钥 base_url “http://localhost/v1” # 替换为你的 Dify 地址 app_id “你的-应用-ID” # 替换为你的应用 ID endpoint f“{base_url}/chat-messages” headers { “Authorization”: f“Bearer {api_key}”, “Content-Type”: “application/json” } # 准备批量问题 questions [ “Dify 是什么”, “如何搭建一个知识库”, “工作流有什么作用” ] answers [] for q in questions: payload { “inputs”: {}, “query”: q, “response_mode”: “blocking”, # 同步模式等待结果返回 “conversation_id”: “”, # 留空创建新会话 “user”: “batch_test_user_001” # 用户标识 } try: response requests.post(endpoint, headersheaders, jsonpayload, timeout60) response.raise_for_status() # 检查HTTP错误 result response.json() answer_text result.get(‘answer’, ‘No answer found’) answers.append({‘question’: q, ‘answer’: answer_text}) print(f“Q: {q} \nA: {answer_text}\n{‘-’*30}”) except requests.exceptions.RequestException as e: print(f“请求失败 for ‘{q}’: {e}”) answers.append({‘question’: q, ‘answer’: f“Error: {e}”}) # 后续可以保存 answers 到文件 with open(‘batch_qa_results.json’, ‘w’, encoding‘utf-8’) as f: json.dump(answers, f, ensure_asciiFalse, indent2)关键参数说明response_mode:blocking同步等待结果或streaming流式适合前端展示。conversation_id: 用于维持多轮对话上下文。同一会话传入相同 ID。user: 用于区分不同终端用户便于后续分析。6.3 调用工作流应用 API工作流应用的调用与对话应用类似但端点和使用参数不同。import requests api_key “你的-API-密钥” base_url “http://localhost/v1” app_id “你的-工作流应用-ID” # 注意这里是工作流应用的ID endpoint f“{base_url}/workflows/{app_id}/run” headers { “Authorization”: f“Bearer {api_key}”, “Content-Type”: “application/json” } # 根据工作流定义的输入变量来构造 payload # 假设我们的“内容审核流水线”工作流只有一个输入变量叫 input payload { “inputs”: { “input”: “这款全新的智能手表现在免费试用点击链接立即购买” }, “response_mode”: “blocking”, “user”: “api_user_001” } response requests.post(endpoint, headersheaders, jsonpayload, timeout120) if response.status_code 200: result response.json() print(“工作流执行成功”) print(“输出:”, result.get(‘data’, {}).get(‘outputs’)) # 工作流的输出可能在 ‘outputs’ 字段中具体结构取决于工作流终点的设置 else: print(“工作流执行失败:”, response.status_code, response.text)通过 API你可以轻松地将 Dify 应用集成到你的业务系统或编写脚本进行大规模的批量数据处理和测试。7. 资源占用与性能观察Dify 平台本身的资源消耗相对平稳性能瓶颈主要出现在两个环节知识库文档处理和大模型调用。平台基础服务占用启动后通过docker stats命令可以查看各容器的实时资源占用。dify-api和dify-web容器通常各占用 200-500MB 内存CPU 占用较低。postgres容器内存占用约 100-200MB。redis容器内存占用约 50-100MB。总体而言平台空闲时内存占用约 1GB 左右。知识库处理性能观察CPU 密集型当上传文档并触发“索引”时嵌入模型如text-embedding-ada-002或本地嵌入模型会全力运行此时 CPU 使用率会飙升。这是正常现象。内存影响处理大量或大型文档如数百页 PDF时内存占用会显著增加主要用于缓存文本和向量计算。优化建议将大文档拆分成多个小文件上传。在系统负载低时如夜间进行批量文档索引。考虑使用性能更好的 CPU 或配置更高内存。模型调用性能观察网络延迟如果使用云端 API如 OpenAI响应时间主要受网络延迟和 API 服务端影响。本地模型资源如果通过 Ollama 等调用本地大模型则消耗的是本地 GPU/CPU 和内存资源。此时需要监控 Ollama 服务所在的机器资源。并发限制Dify 默认配置对并发请求有一定限制。如需高并发需要调整后端服务的WORKER数量和相关配置如docker-compose.yaml中dify-api服务的环境变量WEB_CONCURRENCY。监控方法Docker 容器监控docker stats查看实时资源。Dify 内置日志在“日志与审计”中查看应用调用日志分析响应时间。系统监控使用htop,nvidia-smi(如有 GPU) 等工具监控宿主机资源。8. 常见问题与排查方法在部署和使用过程中你可能会遇到以下问题。这里提供快速的排查思路。问题现象可能原因排查方式解决方案访问http://localhost失败1. 容器未成功启动。2. 端口被占用。3. 防火墙阻止。1.docker compose ps查看容器状态。2.sudo lsof -i:80检查端口。3. 查看docker compose logs dify-nginx日志。1. 根据日志修复启动错误。2. 修改docker-compose.yaml中 nginx 的端口映射如“8080:80”。3. 配置防火墙规则。创建管理员账户时失败或无法登录1. 数据库连接失败。2. 环境变量SECRET_KEY不一致。3. 初始化未完成。1. 检查docker compose logs dify-api和dify-db日志。2. 确认.env文件中的SECRET_KEY在重启后未更改。1. 确保数据库容器正常运行密码正确。2. 保持SECRET_KEY稳定重启所有服务。3. 尝试清除浏览器缓存或使用无痕模式。上传知识库文档后一直显示“索引中”1. 嵌入模型下载慢或失败。2. 文档分段处理耗时过长。3. 向量数据库写入慢。1. 查看dify-api日志是否有网络或模型下载错误。2. 观察 CPU 使用率处理大文件需要时间。1. 检查网络或配置国内镜像源。2. 耐心等待大型 PDF 索引可能需要数十分钟。3. 尝试先上传一个小的 TXT 文件测试。调用 API 返回 401 或 403 错误1. API 密钥错误或过期。2. 应用未发布。3. 请求地址不正确。1. 检查请求头中的AuthorizationBearer Token 是否正确。2. 在 Dify 控制台确认应用已“发布”。3. 检查base_url和endpoint是否拼写正确。1. 在 Dify 中重新生成 API 密钥并更新代码。2. 进入应用点击“发布”按钮。3. 仔细核对 API 文档中的端点地址。工作流运行到某个节点报错1. 节点配置错误如变量名错误。2. 外部服务如模型 API不可用。3. 代码节点存在语法错误。1. 在工作流运行记录中点击失败节点查看详细错误信息。2. 检查模型供应商配置是否正常。1. 根据错误信息修正节点配置或代码。2. 测试模型连接是否正常。3. 在代码节点中使用print调试日志会在运行记录中显示。使用本地 Ollama 模型无响应1. Docker 容器无法访问宿主机服务。2. Ollama 未运行或模型未加载。3. 防火墙阻止。1. 在 Dify 容器内执行curl http://host.docker.internal:11434/api/tags测试连通性。2. 在宿主机执行ollama list确认模型存在。1. 确保 Ollama 在宿主机运行。对于 Linux有时需用--add-hosthost.docker.internal:host-gateway启动容器或直接使用宿主机 IP172.17.0.1。2. 拉取并运行所需模型ollama run qwen2.5:7b。平台运行一段时间后变慢或卡死1. 内存不足。2. 数据库连接池耗尽。3. 磁盘空间不足。1. 使用docker stats和free -h查看内存。2. 检查数据库日志。3. 使用df -h查看磁盘。1. 增加服务器内存或优化知识库索引策略。2. 重启 Dify 服务 (docker compose restart)。3. 清理不必要的日志和缓存文件。9. 最佳实践与使用建议为了让你的 Dify 体验更顺畅并构建出更健壮的 AI 应用这里有一些经验之谈。从简单开始迭代优化不要一开始就设计极其复杂的工作流或上传海量知识库。从一个清晰的提示词、一个简单的问答对、一个只有两三个节点的工作流开始。验证核心流程跑通后再逐步增加复杂性。提示词工程是关键Dify 的强大很大程度上依赖于你给模型的指令。花时间精心编写和调试系统提示词、用户提示词模板。利用“变量”功能{{variable}}让提示词动态化。知识库文档预处理上传前尽量对文档进行预处理。将大型 PDF 拆分为章节清除无关的页眉页脚、水印。良好的源文档质量会极大提升检索效果。善用“变量”和“上下文”在工作流中合理规划变量的传递。了解每个节点的输入输出确保数据流清晰。对于对话应用合理利用“上下文”长度在提示词中明确指示模型参考历史消息。测试与评估发布应用前务必进行充分测试。不仅测试“Happy Path”更要测试边界情况和异常输入。Dify 的“预览与调试”和“日志”功能是你的好朋友。安全与权限管理在团队中使用时利用 Dify 的“成员”和“权限”功能管理访问。对于公开应用考虑设置频率限制和内容过滤。备份与迁移定期备份你的数据库。Dify 的数据应用、知识库、对话记录主要存储在 PostgreSQL 中。了解如何使用docker compose exec执行数据库备份命令。关注资源消耗监控生产环境的资源使用情况。如果使用频繁考虑将数据库PostgreSQL和缓存Redis部署到更专业的云服务或独立服务器上以提高稳定性和性能。合规使用再次强调确保你上传到知识库的文档、用于微调的数据、以及应用生成的内容都符合版权法规和数据隐私政策。明确告知用户这是 AI 生成内容。10. 总结与下一步走完从部署、测试到 API 调用的全流程你应该已经感受到 Dify 在降低 AI 应用开发门槛上的强大能力。它把模型调用、上下文管理、知识检索、流程编排这些复杂技术封装成可视化操作让你能更专注于业务逻辑本身。最值得尝试的点无疑是它的知识库RAG和可视化工作流。前者能快速让你的应用“拥有”专业知识后者能让你设计出超越简单问答的复杂 AI 自动化流程而这两者都不需要你编写复杂的后端代码。最先应该验证的功能建议你按照本文顺序先确保基础对话和知识库问答跑通。这是大多数应用的基石。成功后可以尝试用工作流搭建一个包含条件判断和外部 API 调用的流程例如用户提问 - 知识库检索 - 模型总结 - 调用翻译 API - 返回结果。最容易踩的坑网络与连接本地模型服务Ollama与 Docker 容器的网络互通问题。配置错误环境变量.env文件配置错误尤其是数据库密码和密钥。资源不足索引大型知识库时 CPU/内存不足导致进程卡死。后续探索方向集成更多模型尝试接入 Claude、通义千问、文心一言等更多模型的 API。探索高级功能使用“函数调用”让模型能执行具体操作或探索“多模态”应用需使用支持图像的模型。性能调优学习如何调整知识库的“分段规则”和“检索参数”以在召回率和准确性之间取得最佳平衡。生产部署研究如何通过 Nginx 配置域名和 HTTPS如何设置数据库定期备份如何监控应用健康状态。Dify 就像一个 AI 应用的“乐高”平台提供了丰富的积木块。如何搭建出有趣、有用的作品现在完全取决于你的想象力。建议将本文作为手边参考在遇到具体问题时回来查阅对应的章节。