Dify 是一个开源的大语言模型应用开发平台近几年在企业内部和独立开发者群体里使用频率很高。它解决的问题很直接把模型接入、知识库管理、提示词编排、工作流设计、Agent 智能体构建和应用发布整合到同一个可视化平台里减少重复造轮子。这篇内容围绕“Dify 安装部署”和“智能体搭建”两条主线展开先理清 Dify 的核心概念和部署架构再完成 Docker 环境准备、Compose 部署、模型供应商配置最后从零创建一个带知识库和工具的智能体并完成运行验证。适合刚接触 Dify 的开发者、想用私有化方式交付大模型应用的运维工程师以及打算用 Dify 做内部 AI 应用原型的团队技术人员。读完本文后你可以在本地服务器或云主机上跑起 Dify 社区版接入 OpenAI、通义千问、DeepSeek 等模型服务配置知识库和外部 API 工具构建一个能回答业务问题的智能体应用。整个过程不依赖任何图形界面点鼠标以外的复杂操作只要把命令和配置逐行执行完就能得到一个可用的对话应用。1. 先想清楚不是装完 Dify 就等于能建智能体很多新手在部署 Dify 时只盯着“能不能启动”却忽略了启动之后还有模型接入、知识库索引、工具编排三件大事。这三件事没配好界面再正常智能体也不会回答出有价值的内容。所以在敲第一条命令前必须先理解 Dify 的业务逻辑。1.1 Dify 到底解决了什么问题在没有 Dify 这类平台之前做一个大模型应用通常要自己写后端接口自己管理提示词、多轮对话上下文、历史会话存储、文档切分和向量检索还要对接不同的模型厂商 API。每一项都涉及大量重复代码而且调试困难。Dify 把这一套流程产品化了。它把应用开发拆成几个可视化模块模型供应商统一管理 OpenAI、Anthropic、通义千问、DeepSeek、Ollama 等模型服务的 API Key 和 Base URL。知识库支持上传 TXT、PDF、Markdown、HTML、Docx 等文档自动切分后调用嵌入模型生成向量支持向量检索和全文检索。工作流用节点连线的方式组织提示词、问题分类、知识检索、代码执行、HTTP 请求和条件分支。Agent 智能体在对话中让模型自主决定调用哪些工具完成多步任务。应用发布可以把编排结果发布成 Web 页面、分享链接、API 接口或嵌入到其他系统。这个分工决定了部署时要同时准备好几类依赖PostgreSQL 存业务数据、Redis 存缓存和会话状态、向量数据库存文档向量、Sandbox 执行代码、SSRF Proxy 转发外部请求。这些组件由 Docker Compose 统一管理所以部署 Dify 的核心工作就是把这些依赖编排起来。1.2 从安装到智能体上线完整链路是什么一次完整的 Dify 落地方案可以分成五步准备服务器环境安装 Docker 和 Docker Compose。拉取 Dify 源码目录修改.env配置启动容器。初始化管理员账号进入控制台。在“设置 - 模型供应商”中配置模型 API并做连通性测试。创建知识库、应用和智能体把知识检索与工具编排进去发布后验证。很多人装了 Dify 却不知道怎么建智能体原因就是把第 4 步跳过了。模型供应商没有可用模型时无论创建什么 Agent、工作流最后模型节点都会报错“Model Not Available”。安装只是地基模型接入才是让应用真正有智能的关键。1.3 版本选择社区版、云服务与源码部署差异Dify 提供社区版、云服务和企业版。社区版开源免费可以自托管功能覆盖大多数常规场景适合学习和中小型业务验证。云服务由官方托管省去运维成本但数据放在第三方平台需要评估数据合规要求。企业版一般面向大型组织提供 SSO、多租户、审计等能力授权方式以官方商务政策为准。社区版部署常见两种方式使用docker compose部署适合 Linux 服务器本文采用这种方式。在 Windows 上用 Docker Desktop 部署适合本地体验注意文件路径、端口占用和 Docker Desktop 的资源限制。选择部署方式时不要只看步骤多少还要考虑后续升级和维护。docker compose部署的结构稳定升级时更换镜像并迁移数据库即可是实践中最常用的方式。2. 部署前准备把环境检查做在前面能省掉后面一半问题Dify 由多个容器协作如果一个基础组件没准备好启动过程中会出现各种相互重叠的错误。环境准备阶段需要把操作系统、硬件资源、Docker 版本和端口占用都确认清楚。2.1 硬件和操作系统建议虽然 Dify 社区版没有官方最低配置的一刀切标准但参考常见容器部署经验可以按下面这张表评估部署场景建议配置说明本地学习实验2 核 CPU内存 4 GB磁盘 20 GB可以启动但并发对话和知识库索引会偏慢开发环境调试4 核 CPU内存 8 GB磁盘 40 GB适合日常开发和集成测试生产环境小规模4 核以上内存 16 GB磁盘 100 GB 以上还要考虑日志、备份和监控占用内存是 Dify 部署最敏感的资源。PostgreSQL、Redis、API 服务、Worker 和 Sandbox 同时运行的峰值内存可能超过 3 GB如果主机内存只有 2 GB容器很容易反复重启。磁盘空间同样要提前看Dify 相关镜像加起来会有几个 GB知识库和日志也会持续增长。操作系统方面Ubuntu 22.04、Debian 12、CentOS 7.9 都是常见选择。CentOS 7 的内存 Linux kernel 较老如果 Docker 版本较新可能会出现网络或存储驱动兼容问题建议优先使用 Ubuntu 22.04 或 Debian 12。Windows 环境下建议使用 Docker Desktop但要注意 WSL2 的资源分配。2.2 安装 Docker 引擎与 Compose 插件Dify 依赖 Docker Compose 来编排多容器所以在安装 Docker 时就要把 Compose 插件一起装好。以下命令以 Ubuntu 为例sudo apt-get update sudo apt-get install -y ca-certificates curl gnupg sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg echo \ deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin安装完成后检查版本docker --version docker compose version正常输出会显示 Docker 版本号和 compose 版本号例如Docker version 26.1.4, build 5650f9b Docker Compose version v2.29.1这里的关键点是docker compose命令作为插件存在而不是旧的docker-compose独立命令。如果执行docker compose version提示找不到命令说明没有安装 compose-plugin需要单独补装。2.3 端口和系统参数核对Dify 默认通过 Nginx 容器监听 80 端口如果 80 端口被 Nginx、Apache 或其他服务占用需要提前释放或者修改.env中的EXPOSE_NGINX_PORT改绑其他端口。检查端口占用sudo ss -lntp | grep -E :80|:443如果看到80端口已有进程监听可以选择停掉占用服务也可以规划 Dify 使用另一个端口比如 8080。要特别注意修改端口后访问地址会变化后续登录取出的链接也要跟着改。部署目录建议使用/opt/dify或/data/dify这类独立路径方便备份和升级。不要放在/tmp或用户家目录的临时目录里容器重启或系统清理会导致文件丢失。环境准备完成后建议再确认一遍可用磁盘空间df -h / free -h只要磁盘剩余空间大于 20 GB、可用内存大于 4 GB部署过程基本不会因为资源问题中断。3. 部署 Dify拉取代码、配置 .env、启动容器Dify 的社区版仓库维护了一个直接可用于 Docker Compose 的目录里面包含docker-compose.yaml、.env.example以及ssrf_proxy、nginx等子目录。部署时不需要自己编写编排文件只做配置修改和启动即可。3.1 获取 release 代码Dify 在 GitHub 上以langgenius/dify仓库维护部署时建议下载稳定 release 而不是直接拉取 main 分支。main 分支属于开发版本可能包含未稳定的功能升级和排错风险更高。sudo mkdir -p /opt/dify sudo chown -R $USER:$USER /opt/dify cd /opt/dify git clone https://github.com/langgenius/dify.git cd dify/docker拉取代码后最核心的目录是docker里面放的就是整套容器编排文件。进入docker目录后下一步是准备环境变量文件。如果服务器无法直接访问 GitHub可以尝试通过镜像源或离线包方式获取代码但要注意所有镜像和源代码来源都应该使用官方渠道避免供应链风险。3.2 理解 .env 文件的作用不要跳过.env是 Dify 部署的全局配置中心。所有容器都会读取这个文件来决定端口、数据库密码、密钥、服务地址等参数。仓库里提供的是.env.example需要复制成.env再修改cp .env.example .env复制完成后打开.env查看关键项vim .env需要重点关注以下几项配置项作用注意点EXPOSE_NGINX_PORT对外访问端口默认 80被占用时改成 8080EXPOSE_NGINX_SSL_PORTHTTPS 端口默认 443未配置证书时可先保持默认NGINX_PORT容器内部 Nginx 端口一般不要改POSTGRES_PASSWORD数据库密码必须修改为强密码SECRET_KEY会话和加密密钥必须修改为随机字符串INIT_PASSWORD初始管理员密码首次登录后要修改VECTOR_STORE向量数据库类型默认weaviate可切换qdrant、milvus等很多人直接沿用.env.example里的默认密码这在公网服务器上风险很高。数据库一旦暴露Dify 里的知识库、用户数据和会话记录都可能被读取。所以在启动前至少要把POSTGRES_PASSWORD和SECRET_KEY改掉。生成随机密钥的方式openssl rand -base64 42把输出结果填入.env的SECRET_KEY字段。3.3 初始化配置后再启动修改完.env后先不要急着启动。Dify 启动会拉取多个镜像包括langgenius/dify-apilanggenius/dify-webpostgresredisweaviatenginxlanggenius/dify-sandboxlanggenius/dify-ssrf-proxy启动命令如下docker compose up -d第一次执行会下载镜像时间取决于网络速度通常在几分钟到十几分钟不等。下载完成后Compose 会依次创建并启动容器。查看容器状态docker compose ps正常状态下所有服务都会显示running或healthy状态。不要在running后立刻操作Dify API 初始化数据库需要时间建议等待 30 秒到 1 分钟再访问页面。3.4 启动后的必要检查启动成功后可以用 curl 检查 Web 服务curl -I http://localhost如果返回 HTTP 200 或 302 响应说明 Nginx 和 Web 服务已正常响应。如果返回 502说明 API 容器还没有就绪需要继续等待或检查日志。查看 API 容器日志docker compose logs -f api日志中出现以下输出时说明 API 服务已经准备好Application startup complete如果日志出现database connection refused说明 PostgreSQL 还没有初始化完成等待片刻后再次查看即可。日志中如果出现FATAL: password authentication failed则说明.env中的数据库配置和初始化数据不一致需要检查POSTGRES_PASSWORD是否包含特殊字符以及是否在修改后重新执行了docker compose up -d。4. 初始化管理员并接入模型供应商容器启动成功后需要完成两部分配置管理员账号初始化和模型供应商接入。模型供应商是智能体能否正常对话的前提这一步如果跳过后续所有应用创建都会卡在模型不可用。4.1 完成首次登录和密码初始化浏览器访问http://服务器IP或http://localhost进入 Dify 初始化页面。首次访问会出现管理员账号创建页面需要设置管理员邮箱和密码。注意首次页面会要求设置管理员账号而不是直接使用.env中的INIT_PASSWORD登录。INIT_PASSWORD是 Docker 初始化阶段的默认密码同样要在首次配置中改成自己的邮箱和强密码。创建完成后使用新邮箱和密码登录控制台。控制台主界面会显示创建应用、知识库、工具、工作流等入口。4.2 配置模型供应商模型接入的完整步骤进入控制台后点击右上角头像进入“设置”选择“模型供应商”。Dify 支持几十种模型服务常见的有OpenAIAzure OpenAIAnthropic ClaudeDeepSeek通义千问Ollama 本地模型以 OpenAI 为例在供应商列表中找到 OpenAI点击“安装”或“添加模型”填写参数说明API Key从模型服务商后台获取的密钥API Base URLOpenAI 官方默认为https://api.openai.com/v1如果使用代理网关则填写网关地址Models需要添加的模型名称例如gpt-4o-miniType对话、文本生成、Embedding 等类型添加模型后页面会显示“模型列表”点击“点击测试”或发起对话来验证连通性。如果使用 DeepSeek需要填写 DeepSeek 平台的 API KeyModel 名称通常是deepseek-chat和deepseek-reasoner。如果使用通义千问API Base URL 需要设置为 DashScope 兼容地址模型名以qwen-plus、qwen-turbo等为准。如果使用本地 Ollama需要保证 Dify API 容器能访问到 Ollama 服务地址不能填localhost而应该填宿主机局域网 IP 或 Docker 网络内地址。4.3 为什么模型配置决定智能体能力边界智能体的本质是让模型根据用户问题决定调用哪些工具、检索哪些知识。没有模型接入Dify 只是一个表单系统接入了模型才具备语义理解、工具选择和回复生成能力。模型选型还要结合场景判断通用对话应用选择响应快、成本低的对话模型。文档问答智能体需要同时配置对话模型和嵌入模型。对话模型用于生成回答嵌入模型用于把文档片段转成向量。多步骤任务优先选择支持 Function Calling 或 Tool Calling 的模型否则 Agent 节点无法自主调用工具。嵌入模型常见配置为 OpenAI 的text-embedding-3-small或通义千问的text-embedding-v3。知识库索引时如果选择了某个嵌入模型后续查询也要保持一致否则向量维度不同检索效果会出问题。5. 从零搭建智能体知识库、工作流、工具和 Agent完成模型接入后才开始真正搭建智能体。本节用一个“产品使用文档问答智能体”作为最小案例展示从知识库到发布的全过程。这个智能体需要做到当用户询问产品问题时先检索知识库再根据检索结果回答如果用户问到计算相关的问题调用计算器工具。5.1 先设计一个最小需求不要一上来就堆复杂工作流一个可用的智能体不是把工具全部接上就能工作。建议先明确三件事输入用户会问什么是开放聊天还是限定业务文档问答。知识来源现有文档在哪些文件里是否需要预处理为纯文本。工具需要是否需要查询外部系统、计算、搜索网络。本文的案例限定为内部产品文档助手知识源来自一份 Markdown 格式的使用手册工具只保留计算器和知识检索。5.2 建立知识库并完成文档索引在控制台左侧点击“知识库”选择“创建知识库”上传准备好的文档。Dify 支持 TXT、Markdown、PDF、HTML、Docx 等格式但实际项目中建议先处理格式统一的问题。上传文档后需要设置分段方式。Dify 会把长文档切成片段片段过大会导致检索不精准片段过小会丢失上下文。默认分段长度通常在 500 到 800 token 之间实际项目建议根据文档结构调整。对于带标题结构的 Markdown 文档可以开启按标题分段让每个片段保留层级上下文。分段完成后选择 Embedding 模型点击“保存并处理”。知识库会调用嵌入模型把每个片段转成向量写入向量数据库。处理完成的页面会看到文档状态变成“可用”并且显示分段数量。这里要注意Embedding 模型必须已经在模型供应商中配置好。如果配置了对话模型但没配置嵌入模型知识库索引会报错“Embedding model not initialized”。5.3 创建 Agent 应用并配置提示词在控制台点击“创建应用”选择“Agent 应用”命名后进入编排页面。Agent 编排页面有几个核心区域模型选择、提示词、工具、对话调试。模型选择要挑支持工具调用的模型例如gpt-4o-mini、deepseek-chat这类支持 Function Calling 的模型。提示词设置系统角色例如你是产品使用文档助手只依据知识库内容回答用户问题。 回答时先判断是否需要检索知识库再结合文档内容给出结构化答案。 如果文档中没有答案直接说明资料里没有覆盖该问题不要编造。这段提示词虽然简单但规定了三个关键行为限定知识来源、禁止编造、结构化回答。真实项目中还可以加入语气规范、敏感词拦截、引用格式要求等。5.4 挂载工具和知识检索Agent 编排页面左侧是工具列表。默认自带一些内置工具包括计算器、维基百科搜索、天气查询等。本案例需要添加知识检索工具选择知识库设定 topK 召回数量。计算器工具用于处理数值运算。知识检索工具本质上是把用户问题转成向量到知识库中检索最相关的文档片段再把片段拼进上下文。topK 一般设置在 3 到 5topK 太高会加入无关内容干扰模型判断。除了内置工具Dify 还支持自定义 OpenAPI 工具。如果你有一个内部系统接口只要提供符合 OpenAPI 规范的 JSON 或 URLDify 就能把接口包装成一个可调用的工具。自定义工具适合查询订单、查询库存、控制设备等业务场景。工具越多模型的选择负担越大错误率也会上升。建议工具数量控制在 5 个以内并在每个工具描述里写清楚“什么时候使用、传入什么参数、调用后返回什么”这样模型的工具选择准确率会明显提升。5.5 调试、保存与发布配置完成后点击右侧对话窗口进行调试。输入几个测试问题观察回答是否引用知识库内容。Dify 的调试面板会展示模型调用链、工具调用记录和 token 消耗如果模型没有调用工具可以查看 tool_call 是否被触发。确认无误后点击右上角“发布”。发布方式有三种Web App生成一个可分享的对话页面。API Access生成 API 密钥供外部系统调用。嵌入 iframe把应用嵌入到公司内部站点。发布后可以在“概览 - 访问 API”里查看 API 调用地址和密钥。使用 API 时通过标准 OpenAI 兼容的接口格式发送消息即可curl -X POST https://your-dify-domain/v1/chat-messages \ -H Authorization: Bearer app-xxxxxx \ -H Content-Type: application/json \ -d { inputs: {}, query: 产品的导出功能在哪里, response_mode: blocking, conversation_id: }这个接口是 Dify 对外服务的核心入口第三方系统接入智能体时通常都用这个协议格式。6. 验证运行结果从数据流视角检查智能体是否真的可用很多人和我一样刚开始验证智能体时只看“能不能回复”忽略了“回复质量”和“调用链是否正确”。更可靠的验证方式是分三层功能测试、日志观察、数据落库检查。6.1 端到端功能测试测试用例不要只写一个通用问题至少覆盖四类场景场景类型测试问题预期表现知识库问答“导出功能在哪里”回答内容来自知识库并包含文档要点工具调用“帮我计算 128 乘以 36”模型调用计算器工具返回计算结果未覆盖问题“你们最近融资了吗”回答资料未覆盖不编造连续对话先问一个知识库问题再追问能结合上一轮上下文理解问题测试时如果发现知识库问题没有命中先检查知识库的分段和召回效果再考虑调整检索参数如果工具没有调用优先检查模型是否支持工具调用以及工具描述是否清晰。6.2 观察容器状态和日志对话过程中Dify 的 API 容器会记录请求、调用模型、调用工具等日志。查看日志docker compose logs -f api正常调用链会看到类似这样的阶段收到对话请求查询知识库调用模型生成回复返回结果如果出现tool call failed说明工具接口或参数出了问题如果出现knowledge retrieval empty query说明知识检索没有收到有效查询向量。Web 前端日志也值得看docker compose logs -f web如果前端页面能打开但点击应用跳转异常通常是 Nginx 反代配置或 Web 容器版本不匹配导致。6.3 检查数据库中的会话与消息Dify 的会话数据会持久化到 PostgreSQL。需要确认数据落库时可以进入数据库容器查询docker compose exec postgres psql -U postgres -d difyDify 数据库中常见的表包括conversations、messages、app_instances、knowledge_documents、datasets等。查询最近创建的会话SELECT id, app_id, created_at FROM conversations ORDER BY created_at DESC LIMIT 5;如果对话记录出现在数据库里说明应用发布和消息链路是通的。如果表里没有数据但又显示对话成功可能消息存储写到了其他数据库或环境变量配置不一致。7. 智能体搭建中最容易踩的 5 个坑部署和搭建过程中最常见的坑往往不复杂但一旦踩中排查起来会耗掉很多时间。下面这些问题是根据社区反馈和实际使用场景整理出来的建议逐条对照。7.1 模型供应商配置错误页面正常但对话报错现象Dify 容器全部运行页面能打开但创建应用后发送消息提示模型不存在或调用失败。原因没有在“设置 - 模型供应商”中添加可用模型或者 API Key 无效、模型名写错、Base URL 不匹配。检查方式# 在 Dify 控制台进入模型供应商页面点击模型测试 # 查看 API 容器日志确认是否出现 401/404 docker compose logs api | grep -i openai\|model解决方案先确认模型供应商页面显示模型状态为“可用”再发起测试对话。如果使用代理网关要确认 API Base URL 后缀是否包含/v1不同服务商路径格式不同。7.2 嵌入模型与知识库索引不匹配现象知识库文档显示“处理成功”但智能体问答时始终检索不到相关内容。原因常见为嵌入模型服务不可用、向量维度不一致、分段后文档内容过少。Dify 只返回“可用”状态不代表向量已经真正写入成功。检查方式进入知识库文档详情查看分段数量是否正常在调试面板中查看知识检索工具返回值是否为空。解决方案确认嵌入模型已配置文本分段长度不要低于 100 token至少保留 3 个分段以上。如果向量数据库是 Weaviate还可以进入 weaviate 容器检查对象数量。7.3 内存不足导致容器反复重启现象docker compose ps中部分容器状态一直restartingAPI 日志中频繁出现连接断开或容器被杀。原因服务器内存不足OOM Killer 触发容器重启。检查方式dmesg | grep -i oom\|killed docker stats解决方案给服务器增加内存或减少同时运行的非必要容器。本机测试时也可以关闭一些没用的服务确保内存余量在 3 GB 以上。7.4 修改 .env 后没有重新生成密钥导致登录异常现象Dify 部署几天后管理员登录失效或者修改配置后容器反复报授权错误。原因.env中的SECRET_KEY被改动或者从不同环境复制了.env导致签名密钥不匹配。加密密钥在多容器间不一致会话和密码都会异常。解决方案SECRET_KEY是全局密钥一旦生成就不要随意更换。需要更换时要同步清理数据库中的加密数据或重新初始化一部分会话字段。升级时要注意备份.env不要直接覆盖旧配置。7.5 升级前不备份出现数据丢失现象执行docker compose pull和docker compose up -d后版本升级成功但应用配置丢失甚至知识库不可用。原因Dify 升级除了镜像版本还可能有数据库迁移逻辑。如果升级顺序不对或者数据库版本不兼容新版本 API 可能无法读取旧数据。解决方案升级前备份.env、docker目录和 PostgreSQL 数据卷。最稳妥的方式是导出数据库 dumpdocker compose exec postgres pg_dump -U postgres dify dify_backup_$(date %Y%m%d).sql升级动作要安排在低峰期并准备回滚方案。社区版的升级路径以官方发布说明为准不要跨多个大版本直接升级。8. 从学习环境走向生产环境稳定性和升级建议能在本机跑通智能体和能作为正式服务对外提供中间还差安全加固、备份、监控和升级策略。如果只是练习上一节的流程已经足够如果是团队使用或对外交付还需要补上下面这些工作。8.1 反向代理和 HTTPSDify 默认直接通过 Nginx 提供 HTTP 访问生产环境应该把 HTTPS 放在最外层。常见方案是在 Dify 前再加一层 Nginx 或 Caddy把 443 端口的 HTTPS 请求转发到 Dify 的 HTTP 端口这样才能让页面和 API 都走加密传输。使用 Nginx 时核心配置片段server { listen 443 ssl; server_name dify.example.com; ssl_certificate /etc/nginx/ssl/fullchain.pem; ssl_certificate_key /etc/nginx/ssl/privkey.pem; location / { proxy_pass http://127.0.0.1:80; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-Proto $scheme; } }配置完成后外部访问统一走 HTTPS内部容器只在宿主机网络内接受请求。公网服务器上不要把它直接暴露到 80 端口否则流量和数据都容易被截获。8.2 备份策略和回滚生产环境至少要做到三样备份.env文件、docker下的自定义配置、PostgreSQL 数据。.env是部署的“钥匙”没有它即使容器还在升级时也可能因为环境变量缺失而无法正常启动。备份命令cd /opt/dify tar czf dify_env_backup_$(date %Y%m%d).tar.gz dify/docker/.env docker compose exec -T postgres pg_dump -U postgres dify dify_db_$(date %Y%m%d).sql备份文件要复制到另一台机器或对象存储不要只存在 Dify 所在服务器的磁盘上。回滚时恢复.env和数据库 dump再使用原版本镜像启动可以最大程度还原到升级前状态。8.3 升级 Dify 的正确步骤社区版升级时建议按以下顺序操作cd /opt/dify/dify git pull cd docker cp .env .env.bak docker compose pull docker compose up -d升级后立即查看容器状态和 API 日志docker compose ps docker compose logs api | tail -50如果升级后界面功能异常优先检查数据库迁移是否自动完成再检查新版本.env是否引入了新配置项。Dify 官方会提供新版本的环境变量说明升级前要逐项对比.env.example和当前.env。8.4 多租户、权限和可观测性社区版在默认配置下同一套实例里所有用户共用一套应用和知识库。如果团队内部需要隔离部门数据就需要评估多租户方案或企业版能力。搜索词里提到的“Dify 社区版多租户”属于社区讨论较多的方向具体支持程度要以官方版本发布说明为准不建议只看网络教程就做生产决策。可观测性方面至少要把 API 日志接入统一日志平台给 PostgreSQL、Redis 和向量数据库配置基础监控。一旦容器异常或磁盘写满能通过告警及时知道而不是等用户反馈才排查。8.5 扩展方向工作流、流水线和自动化Dify 的能力并不止于 Agent。搭建完第一个智能体后可以继续深入这些方向工作流把用户问题先经过意图分类再分流到不同处理链路例如售前咨询走知识库、售后工单走 API。流水线把文档上传、分段、嵌入、质检做成自动流程知识库更新频率更高。自定义工具通过 OpenAPI 规范接入业务系统让智能体具备查询订单、创建工单等操作能力。插件机制按需接入搜索、翻译、数据分析等插件扩展智能体边界。如果把 Dify 当作一个应用开发平台而不是单纯的聊天框它能承载的场景会多很多。但要注意角色权限、数据隔离、敏感信息过滤这类安全项在正式接入业务前必须补齐否则智能体越“聪明”越容易在不合适的时机把不该说的话说出去。对新手来说最有效的练习路径是先按这篇文章部署一套环境跑通一个带知识库的 Agent然后在工作流里增加一个分类节点模拟“不同问题走不同通道”的场景最后接一个自定义 API 工具让智能体具备真实操作能力。完成这三步你对 Dify 的理解就不再是“见过”而是真正会用了。