Dify 这名字最近在 AI 应用开发圈子里出现频率相当高。简单来说它是一个开源的 LLM 应用开发平台让你不写前端、不写复杂后端逻辑就能把大模型能力包装成真正的产品聊天机器人、知识库问答、复杂工作流、Agent 应用。它解决的核心问题是“从模型 API 到可用应用”之间那一大段重复劳动。这篇文章我不打算写成官方文档复述而是按我自己的部署和二次开发经验把它是什么、怎么装、装完能干什么、会遇到哪些坑一条线讲清楚。适合刚接触 Dify、准备本地部署一套试试的人也适合已经在用但遇到部署或使用问题的朋友翻一翻。1. 先把它放在正确的位置上Dify 到底是什么1.1 一句话定位和它背后的设计逻辑Dify 的官方定位是“LLMOps 平台”但这个词太拗口。用大白话讲它把 AI 应用开发里最常重复的那几件事给包起来了模型接入与管理、提示词编排、知识库处理、工作流设计、应用发布与运维监控。你可以把它理解成一个“AI 应用工厂里的流水线设备”。你不需要从零开始造轮子——比如自己写一套 RAG 管道的代码、自己管理向量数据库的连接、自己搞一套用户会话状态存储这些 Dify 都内置了。你只需要关心业务本身知识文档怎么切、提示词怎么写、工作流节点怎么连、给用户开放的入口是什么形态。这个设计逻辑很重要它决定了你用 Dify 的正确姿势。它不是让你把所有业务逻辑都塞进去的万金油而是在“模型能力 业务编排”这一层帮你省时间。凡是能用节点拖拽解决的问题别写代码凡是需要深度的个性化定制Dify 也留了 API 和二次开发的口子。所以它不是取代程序员而是把程序员从重复劳动里解放出来。1.2 和 LangChain、扣子、FastGPT、n8n 的区别在哪我把这几个经常被放一起比较的项目拉出来说下帮你建立坐标系。LangChain是一个开发框架它给的是代码库和工具链你得自己写 Python 程序把它组装起来。灵活度最高但什么都要自己动手。Dify 是平台你把 LangChain 写出来的那套东西用可视化方式在 Dify 里搭出来。扣子Coze字节出品的托管平台零代码、上手快但应用跑在别人服务器上模型调度和分发渠道跟字节生态绑定较紧。Dify 社区版是开源可自托管的数据和流程全部自己掌控。FastGPT开源项目核心强项在知识库检索这一块工作流能力相对轻一些。如果你想做重度知识库应用可以比较一下。Dify 的定位更宽除了知识库还有完整的 Agent、工作流、工具接入和运维体系。n8n通用自动化工作流平台本质是“各种服务之间的流程编排”它能调用 AI 能力但它本身不专注于 LLM 应用开发范式上下文管理、知识库切分、模型统一接入这些。Dify 是专门为 LLM 应用设计的两者的心智模型完全不同。一句话总结LangChain 是零件库n8n 是万能胶水FastGPT 是知识库专精选手扣子是托管便捷版而 Dify 是更均衡的开源全家桶。1.3 适合谁来用、不适合谁来用我觉得这是选型时最关键的问题。Dify 适合这些人产品经理或业务方想快速把 AI 想法做成可演示的原型不依赖开发排期。后端开发想少写那些“模型调用、上下文拼接、会话存储”的通用代码直接通过 API 把 AI 能力嵌入现有系统。企业内部做 AI 中台的人需要一套可私有化部署、有多租户隔离能力的底座。独立开发者想低成本运营一个 AI 应用又不想买一堆云服务拼起来。不适合的场景我也说直白点如果你的应用对推理链路有极其特殊的定制需求比如要精细控制每一步的 token 计算、自定义采样策略、或者深度改造模型调用层那 Dify 的可视化编排反而会变成约束。如果你的核心业务是一个高并发的纯 API 服务对响应延迟极度敏感你需要的是直接写服务而不是套一个平台。Dify 再好它也不是为极致性能调优设计的。搞清楚了这些你再决定装不装、怎么装。2. 装之前必须知道的部署选型思路2.1 为什么 Docker Compose 是唯一的主流推荐Dify 官方给出多种安装方式Docker Compose、本地源码运行、Kubernetes Helm。但我个人的建议是除非你有极特殊的理由否则一律用 Docker Compose。原因有三点。第一Dify 的依赖组件太多了PostgreSQL 存业务数据、Redis 做缓存和会话、Weaviate 或 Qdrant 之类的向量数据库做知识库检索、API 服务和 Worker 服务分开部署还有 Sandbox 做代码执行隔离。这些组件手工装一遍半天就没了而且版本不匹配的概率极高。Compose 文件把这些依赖关系全部固化好了一条命令就是一套完整环境。第二升级维护方便。Dify 迭代速度很快社区版基本每个月都有更新。用 Docker Compose 升级就是拉镜像、重建容器的事。你要是手工装的依赖升级一次数据库迁移能让你怀疑人生。第三隔离性好。Dify 的 API 服务和 Worker 服务都会跑 Python 代码包括用户在工作流里写的自定义代码它们跑在独立容器和 Sandbox 里。容器化部署天然给了这层隔离宿主机不会因为某个应用崩溃而遭殃。2.2 硬件要求到底高不高我实测下来Dify 全家桶跑起来内存占用大概在 2GB 到 4GB 之间。如果是个人体验2 核 4G 的云服务器能跑但会比较勉强打开界面会有卡顿感。建议至少 4 核 8G尤其是你要接本地 Embedding 模型或者跑 Sandbox 代码执行资源开销会明显上涨。存储方面Dify 镜像和容器数据加起来大概 5GB 到 10GB这里还没算你导入知识库的文档和向量数据。所以部署前检查一下磁盘低于 20GB 就别硬装了。还有一点必须提前说CPU 架构尽量选 x86_64。虽然官方也提供 ARM 镜像但社区版在 ARM 上的兼容性问题明显更多比如某些依赖的向量数据库镜像在 ARM 下没有官方构建你得自己用其他方案替代。除非你非常清楚自己在做什么否则别拿树莓派或者 Arm 服务器当主力部署环境。2.3 三种典型部署环境Linux、Windows、家用 NAS我把三种环境的要点先列个对比表后面再逐个展开部署环境推荐方式难度典型问题Linux 服务器Docker Compose低旧系统 Docker 安装源失效WindowsDocker Desktop / WSL2中路径映射、内存分配、防火墙群晖、飞牛等 NAS套件版 Docker / Compose中镜像拉取慢、端口冲突Linux 是最干净的部署环境几乎没有额外坑Windows 主要靠 Docker Desktop 提供的 Linux 兼容层NAS 本质上还是 Linux但受限于 NAS 系统的资源管理和自带的应用商店部署方式会更绕一些。后面我分别给出实操过程。3. 从零开始部署我的完整实操路线3.1 以 CentOS 7 为例的 Linux 部署全流程CentOS 7 这个系统虽然已经停止维护但存量服务器实在太多我就以它为例把流程完整走一遍。新系统如 Ubuntu 22.04、Debian 12 反而更简单直接用系统自带 Docker 源就行。第一步安装 Docker 和 Compose 插件CentOS 7 的默认软件源里没有 Docker需要先添加 Docker 官方源。这里要特别提醒CentOS 7 的官方 Docker 源已经因为系统停止维护而下线必须改用 vault 源或阿里云镜像源。# 安装基础工具 yum install -y yum-utils # 使用阿里云镜像源添加 Docker 仓库 yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo # 安装 Docker 与 Compose 插件 yum install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin # 启动并设置开机自启 systemctl enable --now docker这里有个 CentOS 7 特有的坑内核版本太低时Docker 的 overlay2 存储驱动可能报错提示“failed to mount overlay”。解决办法是改用 vfs 驱动但性能会差一些。更推荐的方式是升级内核到 3.10 以上的长期支持版本或者干脆换新系统。第二步拉取 Dify 源码并配置环境变量Dify 的 Docker 编排文件在 GitHub 仓库的 docker 目录下。你需要把它克隆下来但注意不要克隆整个仓库到服务器上仓库体积不小而且你只需要 docker 目录里的文件。可以这样操作mkdir -p /opt/dify cd /opt/dify # 只拉取 docker 子目录 git clone --depth 1 --filterblob:none --sparse https://github.com/langgenius/dify.git cd dify git sparse-checkout set docker cd docker然后复制环境变量模板cp .env.example .env打开 .env 文件有几个关键项需要你检查SECRET_KEY用于会话加密和签名一定要改成一个随机长字符串。可以用openssl rand -base64 42生成。POSTGRES_PASSWORD、REDIS_PASSWORD数据库和缓存密码别用默认值。EXPOSE_NGINX_PORTDify 对外服务的 HTTP 端口默认 80。如果 80 被占用改成 8080 之类。VECTOR_STORE向量数据库类型默认是weaviate一般不用动。第三步一键启动docker compose up -d第一次启动会拉取十几个镜像根据网络情况可能要等 10 到 30 分钟。启动完成后docker compose ps等所有容器状态都是 healthy 或 running就表示启动成功了。然后浏览器访问http://你的服务器IP:端口第一次打开会让你设置管理员邮箱和密码。这里我补充一个很重要的经验启动后一定要做一次容器健康检查别只看到容器 running 就以为成功了。有一次我部署完nginx 容器 running 了但后面 api 容器健康检查一直 failed结果页面能打开、登录不了查了半天才发现是 PostgreSQL 初始化没完成。稳妥的做法是等两分钟再执行一次docker compose ps确认 api、worker、db 这几个核心容器都是 healthy。3.2 Windows 本地部署Docker Desktop 路线Windows 上部署 Dify官方没有提供像 Linux 那样的一键脚本但用 Docker Desktop 也能跑起来。整体思路就是先把 Docker Desktop 装好再走一遍 Linux 的流程。在 Windows 上安装 Docker Desktop 有几个前置条件Windows 10/11 专业版或企业版开启 Hyper-V 和 WSL2。CPU 需要支持虚拟化并在 BIOS 里开启。内存建议 16GB 以上因为 Docker Desktop 虚拟机本身要占 2-4GB。装完 Docker Desktop 后建议在 Settings - Resources 里把内存调到至少 6GB否则 Dify 跑起来会很吃力。然后打开一个终端Powershell 或 CMD按前面的步骤拉取 Dify 的 docker 目录并启动。Windows 上最容易出问题的地方是路径映射。Dify 的 compose 文件里有./volumes这样的相对路径映射Windows 下 Docker Desktop 会自动处理但如果你的项目目录在 C 盘系统目录可能会遇到权限问题。建议把 Dify 放到一个专门的目录比如D:\dify然后在该目录下操作。还有一个很常见的坑Windows 防火墙会拦截 Docker 的端口映射。等你启动完成后浏览器访问localhost:80如果打不开先检查防火墙是不是把 Docker 的端口拦了。Docker Desktop 一般在安装时会自动添加规则但某些安全软件会接管防火墙策略导致规则失效。3.3 飞牛 NAS 部署家用环境下最顺滑的方案最近飞牛 NASfnOS讨论度挺高它基于 Debian自带 Docker 管理界面。在飞牛上装 Dify本质上跟在 Linux 上装一样但有两点要注意第一飞牛自带的“应用中心”里可能有 Dify 或类似应用的一键安装但我试下来版本往往滞后而且编排文件被封装在黑盒里出了问题很难排查。建议还是手动部署下载 Docker Compose 文件自己跑。第二飞牛的 Docker 管理界面支持 Compose 项目上传。你可以把 Dify 的 docker 目录传到 NAS 上然后在界面里选择该目录下的docker-compose.yaml文件点击部署。部署完成后飞牛会自动管理容器的启停和日志。NAS 部署最容易卡在镜像拉取上。很多 NAS 用户都在国内网络环境而 Dify 镜像全部在 Docker Hub 上拉取速度可能很慢甚至超时。解决办法是给 Docker 配置镜像加速器。在飞牛 Docker 设置的 registry mirrors 里填入可用的加速地址或者直接修改 daemon.json。这一步务必在启动前做好否则中途拉取失败容器起一半状态会非常尴尬。3.4 更新与迁移云桌面最容易被忽略的两个动作先聊升级。Dify 的升级流程不长但很多人会忽略“数据备份”和“版本迁移”这两件事。常规升级步骤# 进入 dify 的 docker 目录 cd /opt/dify/docker # 拉取最新代码获取新的 docker-compose 配置 git pull # 备份当前数据库 docker compose exec db pg_dump -U postgres -d dify dify_backup_$(date %Y%m%d).sql # 拉取新镜像并重建容器 docker compose down docker compose pull docker compose up -d升级之后部分版本可能需要执行数据库迁移命令。对于社区版 1.x通常在容器启动时自动执行迁移但如果你发现某个功能异常或页面报 500可以手动执行docker compose exec api flask db upgrade这个命令会把数据库 schema 升级到当前代码版本对应的状态。执行前一定要确保另一个备份已经生成数据库迁移是不可逆的一旦执行到一半出错你得靠备份恢复。再聊迁移也就是把 Dify 从一台服务器搬到另一台。这事说难不难但你得知道该迁哪些东西Docker 容器编排文件即整个docker目录包括.env环境变量。volumes 目录Dify 的持久化数据都在./volumes下包括 PostgreSQL 数据、Redis 数据、向量数据库数据、上传的文件。额外配置如果你给 Dify 配置了自定义的 SSL 证书、nginx 配置等也要一并迁移。简单做法是把整个 Dify 项目目录包含 docker 目录、.env、volumes打包拷贝到新服务器然后在新服务器上直接docker compose up -d。唯一要注意的是.env文件里如果有域名或 IP 相关的配置需要同步修改。4. 装完能干什么功能全景与实操演示4.1 知识库从上传文档到可检索问答的全流程Dify 的知识库模块本质上是一个完整的 RAG 管道但它把复杂度全藏起来了。你只需要做三件事上传文档、设置分块参数、配置检索方式。这三步背后对应了 RAG 的三个核心阶段文档解析与切分、向量化与索引、检索与重排。文档上传与解析Dify 支持 PDF、DOCX、TXT、Markdown、HTML 等常见格式。上传后进入“分段与清洗”环节这里要特别说一下分段模式的选择如果你对文档结构有明确把握比如固定格式的周报、合同用“自定义分段”指定分隔符和最大分段长度如果文档结构乱七八糟用“自动分段”让它按段落智能切开效果往往更好。索引模式“高质量”是基于向量索引的它需要你配置了 Embedding 模型每条分段都会被转成向量检索时通过语义相似度召回效果最好但占用存储和 token。“经济”模式不转向量靠关键词匹配省资源但语义理解能力基本为零。我的建议是面向用户体验的应用必须用高质量模式内部试验或资源受限先用经济模式顶一顶。检索策略Dify 提供向量检索、全文检索、混合检索三种。混合检索会同时跑前两种再用 Rerank 模型把结果融合重排。如果你的应用对准确率要求高、用户问题经常变化表达方式混合检索 Rerank 是标配。这里需要提醒Rerank 模型本身也需要 API 接入如 Cohere 或 Jina 的服务配置好之后在“检索设置”里勾选即可。知识库配置好之后可以在“编排”页面的上下文区引用它。最简单的用法是对话型应用里把知识库作为上下文输入模型回答时会先检索相关片段再生成答案。我在实操中有一个体会知识库质量的瓶颈不在模型而在分段策略。很多人把整份 PDF 随便上传自动分段然后发现问答效果稀烂。其实你只要把每个分段控制在 200 到 500 字之间并保留尽量完整的语义单元检索命中率就会显著提升。遇到那种大表格、多层级标题的文档建议先预处理成 Markdown 再上传Dify 对结构化文本的解析效果远好于原始 PDF。4.2 工作流从对话流到复杂业务流的编排Dify 的工作流模块是它最值钱的地方。它把一次 LLM 调用拆成多个可编排的节点开始、LLM、知识检索、代码执行、条件分支、HTTP 请求、工具调用、模板转换、变量聚合、结束等等。你可以像搭积木一样把一条复杂的业务逻辑拼起来。我用一个实际例子说明。有一次我需要做一个“文档摘要 分类 生成周报”的内部工具按照传统开发方式我要写一个 Python 服务串联三次模型调用、一次文档解析、一次数据库写入。在 Dify 里我只需要在工作流画布上拖六个节点开始节点接收用户上传的文档 URL。代码节点把文档下载并解析成纯文本。LLM 节点生成摘要。条件分支根据摘要长度分流。HTTP 节点把结果写入内部系统。结束节点把摘要返回给用户。整个过程不到半小时就搭完了而且每次调用都有完整的日志轨迹哪个节点耗时多少、输入输出是什么一目了然。这种可观测性是手写代码很难获得的。工作流里最容易忽略的细节是变量作用域和类型。不同节点的输出变量要用节点名.输出变量名的格式引用而且类型要匹配。比如 LLM 节点输出的“text”类型变量不能直接传给要求“number”类型的代码节点需要先用模板转换节点处理。新手在这里最容易卡壳但其实只要理解了“每个节点有输入和输出输出通过变量暴露给下游节点”这个模型就通了。4.3 Agent让模型自己决定调用什么工具Dify 的 Agent 功能走的是 ReAct 模式的 Agent 范式。你给它一组工具比如搜索引擎、计算器、数据库查询接口、你自己的 HTTP 服务它会在回答过程中不断分析当前状态、选择工具、调用工具、观察结果直到完成目标。配置 Agent 应用的步骤很简单创建一个“Agent”类型应用选择模型在“工具”列表里启用你需要的工具。Dify 内置了不少常用工具比如 Wikipedia、Web 搜索等也支持通过 OpenAPI Schema 接入自定义工具。这里值得展开的是“自定义工具”。这个能力非常强大——你只要提供一个符合 OpenAPI 规范的接口描述Dify 就能让模型理解这个工具的功能和参数格式在需要时自动调用。比如你有一个查询内部库存的接口只要写成 OpenAPI Schema 放进 Dify模型就会在用户问“库存还有多少”时自动拼接参数调用你的接口。但 Agent 也是最容易出现不可控行为的地方。模型选错工具、参数拼接错误、陷入循环调用这些都会发生。所以我的经验是第一工具描述要写得极其详细包括什么情况该用、不该用第二给 Agent 设置最大迭代轮数默认值往往太大实际场景下 5 到 10 轮足够第三认真看日志Dify 的 Agent 日志里有完整的工具调用轨迹排查问题全靠它。4.4 模型接入API Key 和模型选型Dify 目前支持的模型服务商非常多OpenAI、Anthropic、Google Gemini、Azure OpenAI、AWS Bedrock、国内的主流服务商智谱、百度千帆、通义千问、百川、月之暗面等以及开源模型的本地部署方案Ollama、Xinference。接模型的核心动作就一个在“设置 - 模型供应商”里填入 API Key。填完之后系统会做一次“凭据验证”验证失败会直接提示“an error occurred during credentials validation”。这个验证动作特别容易踩坑我后面会专门讲排错。这里先说模型选型的基本思路如果你做知识库问答Embedding 模型和 Rerank 模型与生成模型同等重要如果是跑工作流同一个应用里可以用不同的模型承担不同节点角色比如摘要用便宜的模型、对话用更强的主力模型如果是 Agent尽量选工具调用能力强的大模型否则 Agent 的调用成功率会让你抓狂。5. 部署和使用中最常见的坑问题排查实录5.1 凭据验证失败an error occurred during credentials validation这个报错几乎人人都会遇到。它的直接含义是Dify 拿着你填的 API Key 去请求模型服务商的接口验证时请求失败了。排查思路按顺序来第一步确认密钥本身没问题。很多模型服务商的密钥有额度限制比如 OpenAI 的免费额度用完验证就会失败一些国内服务商的密钥有白名单 IP 限制你的服务器 IP 不在白名单里同样会失败。第二步确认服务器到模型服务商的网络连通性。Dify 所在服务器如果在国内机房直连 OpenAI 的接口经常超时或拒连。你可以先手动 curl 一下接口地址curl -I https://api.openai.com如果超时说明问题在网络上你需要给 Dify 配置代理或者改用国内可达的模型服务商。第三步确认服务商返回的具体错误。Dify 在验证时会把服务商的原始错误信息记录到后端日志里执行下面的命令就能看到docker compose logs api --tail200 | grep -i credential日志里通常会有 HTTP 状态码和错误详情。如果是 401密钥无效如果是 429触发限流如果是 5xx服务商侧出了问题。5.2 登录被锁too many incorrect password attempts. please try again later.这个报错是 Dify 的登录安全策略在起作用。连续多次输错密码后Dify 会锁定该账号一段时间锁定期内即使密码正确也无法登录。如果你是被锁定的普通用户等锁定时间过去即可。如果你是管理员且自己也被锁了那就得在服务器端干预。Dify 的这个限制逻辑依赖后端缓存重启 api 容器可以清掉锁定状态docker compose restart api如果重启还不够你可能需要直接改数据库。但这种情况相当少见多数时候重启一下就好。从运维角度我建议部署后立刻修改.env里的几个安全参数比如AUTH_PASSWORD_LOCKED_THRESHOLD锁定阈值次数和AUTH_PASSWORD_LOCKED_MINUTES锁定分钟数设置成符合你团队使用习惯的值。5.3 文档解析报错unstructured api url is not configured知识库里上传 PDF、DOCX 等复杂格式文档时如果系统提示unstructured api url is not configured for doc file processing说明 Dify 尝试调用 Unstructured 服务解析文档但你还没配置这个服务的地址。Unstructured 是一个文档解析引擎专门把 PDF、Word、PPT 这类复杂格式转成结构化文本。Dify 在“设置 - 文档解析”里提供了两种模式“自动”和“自定义”。自动模式用 Dify 内置的解析能力自定义模式则要求你指定一个 Unstructured API 地址。问题的根源通常是你切换到了“自定义”模式但没填 URL。两个办法如果你没有部署 Unstructured 服务切回“自动”模式即可如果你确实想用自定义解析它对复杂表格和版面识别效果更好那就得自己部署一个 Unstructured API 服务并把地址填到配置里。值得多说一句Unstructured 服务本身的部署也是镜像化操作一条 docker run 就能起一个 API 服务。但它在处理超大 PDF 时比较吃内存如果你的服务器内存不到 4G建议还是先用自动模式。5.4 CentOS 7 上莫名其妙的 SSL 错误CentOS 7 上安装 Dify 时遇到的 SSL 错误常见于两个地方一个是拉取 git 仓库或 Docker 镜像时报 SSL 证书验证失败另一个是启动后页面访问报 HTTPS 证书异常。前者多半是系统 CA 证书过期。CentOS 7 的ca-certificates包在 2021 年前后就停止更新了而部分 git 和镜像源已经切换到了新证书链。解决办法是把系统证书更新到最新yum update ca-certificates如果 yum 源本身已经失效你还需要先把CentOS-Base.repo换成 vault 源再操作。后者如果是你自己给 Dify 配了 HTTPS 证书报错一般是证书格式或者私钥不匹配。Dify 的 nginx 容器默认只加载./volumes/nginx/ssl目录下的证书文件你需要把证书命名为dify.crt和dify.key放进去然后重启 nginx 容器。5.5 Windows 部署的常见报错Windows 上部署 Dify我遇到过比较典型的问题有三个第一docker compose up -d执行后某些容器一直重启。这通常是因为路径映射出了问题。Windows 的 Docker Desktop 在映射 C 盘目录时如果目录路径包含中文或特殊字符容器内进程可能无法正确读取配置文件。解决方案是换成纯英文路径。第二端口被占用。Dify 的 nginx 默认监听 80 端口Windows 上 IIS 或某些开发环境经常占用 80。改.env里的EXPOSE_NGINX_PORT即可。第三容器启动成功但浏览器访问不到。排查中心放在 Docker Desktop 的虚拟网络。新版 Docker Desktop 用的是 WSL2 后端端口映射会有延迟等 30 秒再刷新。如果还不行执行docker compose logs nginx看 nginx 有没有正常起来。6. 进阶方向多租户、二次开发和与 Cursor 的联动6.1 社区版 1.10 的多租户能力Dify 社区版从 1.x 开始引入了更完善的多租户支持。在早期版本里Dify 社区版基本是单工作区模式一个部署就是一个团队在用。到 1.10 之后工作区机制逐渐成熟管理员可以创建多个工作区每个工作区有独立的成员、知识库、应用和数据隔离。这个能力对内部中台场景非常关键。比如你给公司搭了一套 AI 平台研发部、市场部、客服部想各自维护自己的知识库和应用互不干扰。没有多租户时要么多部署几套 Dify浪费资源要么大家挤在一个工作区里权限混乱。有了多租户一套部署解决所有问题。配置方式在“管理后台”里做创建组织、创建成员、分配工作区。注意多租户的管理入口和管理员权限是分开的第一次登录的管理员账号默认拥有超级管理员权限可以进入管理后台操作。6.2 Cursor 连接 Dify 知识库Cursor 是目前非常流行的 AI 编程工具很多人想让它直接使用 Dify 里已经建好的知识库省去重复录入上下文。这个需求有两类场景一类是让 Cursor 在写代码时能检索你内部的技术文档另一类是想让 Cursor 调用你在 Dify 里发布的 AI 能力。实现方法不复杂。Dify 从 1.6 之后支持把应用发布为 MCP Server 形态而 Cursor 原生支持 MCP 客户端。你只要在 Dify 的应用“API 访问”页面找到 MCP 服务的连接地址和密钥然后把它配置到 Cursor 的 MCP 列表里Cursor 就可以把 Dify 应用当作一个工具来调用了。实际操作中我建议你先在 Dify 里发布一个“工作流”类型的应用把内部知识库检索 生成逻辑封装进去再通过 MCP 连到 Cursor。这样你在 Cursor 里写代码时通过对话就能触发 Dify 工作流拿到检索结果。比直接让 Cursor 读一堆文档效果要稳定得多。我自己在做项目时也经常会把团队接口文档、技术规范都打到 Dify 知识库里然后让 Cursor 里随时可以问。6.3 二次开发从插件到 ForkDify 的二次开发弹性很大。最小的改动是开发自定义插件Dify 的插件体系允许你接入自定义工具、自定义模型服务商、自定义扩展 API。稍微重一点的是改前端样式Dify 的前端仓库是独立项目你可以替换 logo、改主题色、调整交互逻辑。最重的是 Fork 后端代码对 API 服务做深度定制。后端二次开发前你需要先跑起本地开发环境。Dify 的开发模式可以理解为后端跑在 Docker 容器里前端跑在你的本机开发服务器上两者通过环境变量对接。官方文档里的“本地开发环境搭建”一节写得很清楚核心步骤是在 docker 目录下启动依赖的中间件db、redis、向量库、sandbox。Fork 并克隆后端仓库 langgenius/dify用 Poetry 安装 Python 依赖。启动后端开发服务器它会连接 Docker 里的中间件。Fork 并克隆前端仓库 langgenius/dify-web安装 npm 依赖启动前端开发服务器。浏览器访问 :3000前后端通过代理连接。这套环境搭好之后你可以直接在代码里改逻辑、调接口前端热更新、后端也可以热重载。建议把 API 服务、Worker 服务和前端服务的环境变量都调成 DEBUG 模式这样终端里能打出详细的 SQL 语句、请求参数和模型调用日志排查问题会轻松很多。还有一个经验如果你要改的东西比较深比如新增数据库表、改动核心工作流引擎逻辑建议先在 GitHub 的 Discussion 或 Issues 里搜一搜有没有人提过类似需求。Dify 社区很活跃很多功能你想到的别人已经做了能抄作业就别从零造轮子。实在没现成的Fork 之后也建议保持和主仓库的同步定期把上游的新功能合并过来避免分叉太深后面想升级都难。7. 部署后的那些小事日常运维和我的个人体会流程全走完服务也跑起来了最后聊几个容易被忽略的小事。Dify 的日志会越攒越多。默认配置下容器日志和 volumes 里的日志文件都没有自动清理策略。我建议在 compose 文件的每个服务里加上 logrotate 相关配置或者写一个简单的 crontab 定期清理 7 天前的日志。这活儿看着不起眼却是线上环境最容易踩的磁盘坑。升级前先看 Release Notes。Dify 每个版本都有 breaking changes 说明尤其是涉及数据库表结构变更的版本贸然升级很容易出兼容问题。我见过有人直接从 0.x 跳到 1.x数据库迁移直接失败。正确做法是版本分段升级——先升到中间版本确认无误后再继续升。用 Dify 的监控面板关注应用运行情况。应用详情页的“日志与标注”里记录了每次会话的完整链路、token 消耗、模型响应时间。我每周会拉一次 token 消耗数据看看哪些应用烧钱、哪些节点耗 token 大头然后针对性地优化提示词或换便宜模型。这个习惯帮我省了不少钱。最后再分享一个小技巧Dify 的 API 密钥体系是可以按应用隔离的。你发布一个应用给内部系统调用创建一个单独的 API Key 并限定它的访问范围只能调这个应用这样可以避免一个 Key 泄露导致所有应用数据暴露。虽然 Dify 界面做得比较浅但多花一分钟拆两个 Key安全等级完全不同。我把这套平台部署在两台不同环境的服务器上跑了半年从最初的纯试验到后来团队内部真正开始用它搭建知识库、跑业务流程。感触最深的不是它省了多少代码而是它把“AI 应用的技术门槛”这件事降了一个量级——让业务人员能看懂、能上手、能自己调开发者也从繁琐的模型接入和调试中解放出来把精力放到真正需要深度定制的地方。如果你还在犹豫要不要花一个下午装一套 Dify我的建议是直接上手试装完之后你会发现它比你想象中能做的事情要多得多。