企业官网建设流程全解析

1. Dify 是什么：先想明白它在 AI 应用开发里的位置

坦白说，第一次接触 Dify 的人多多少少都会有点疑惑：它到底是“套壳应用”、“低代码平台”还是“AI 中台”？我的理解是——Dify 是一个开源的大模型应用开发平台，中文叫“狗狗狗”也好、叫“低代码 LLM 应用平台”也好，本质上它解决的是一个问题：让没有太多后端工程能力的人，也能快速把大模型能力变成真正可用的产品。

过去我们要做一个 AI 应用，链路是：申请大模型 API → 写 Prompt → 写后端逻辑做上下文管理 → 写前端对话界面 → 接入知识库 → 处理用户会话历史 → 做权限控制 → 部署上线。这一套下来，少说两三周。Dify 把这些事儿全部收拢到了可视化界面里，你只要把模型接上、把流程画出来、把知识库传上去，一个能用的 AI 应用就出来了。

1.1 一句话说清 Dify 的本质

Dify 官方对自己的定义是“LLMOps 平台”，这个概念对应的是 DevOps 的延伸。传统软件里，开发完要管部署、监控、运维，那叫 DevOps；在 AI 应用里，除了代码你还要管模型版本、Prompt 版本、知识库更新、日志追踪，这一整套就叫 LLMOps。Dify 就是把这些散落在各家工具里的能力统一到一个平台上，并且它是开源的、可以本地部署的。

它有几个非常重要的内置模块：

• 工作流（Workflow）：可视化编排多步骤的复杂逻辑，比如先检索知识库、再调用多个模型、再对结果做后处理，全程拖拽节点完成。
• 知识库与 RAG 流水线：上传文档自动做分段、向量化、检索，开箱即用的检索增强生成能力。
• Agent 节点：支持调用外部工具（HTTP 请求、内置工具、自定义工具），让模型自主决定下一步该干嘛。
• 应用发布与 API：每个应用一键发布成 Web 应用，同时生成 API 接口，方便接入其他系统。

1.2 Dify 与 LangChain、Flowise 这些工具差别在哪

很多人问过我：既然我会 LangChain，为什么还要用 Dify？答案是——LangChain 是开发框架，Dify 是开发平台。前者给你的是零件，你自己负责组装；后者给你的是流水线，你只需要把零件放上去。

更直白点说：LangChain 适合有后端开发能力的人自己造轮子，代码自由度极高，但你要自己处理调用链、异常重试、日志、数据库、前端等等；Dify 适合想快速交付业务结果的人，你用它可以省掉大量基础设施代码的时间。Flowise 也是一类产品，但它在企业级功能、多租户、权限体系上明显不如 Dify 扎实。从社区活跃度、迭代速度、生产可用性这几个维度来衡量，Dify 目前是开源赛道里的第一梯队。

1.3 核心组件与目录结构

你拿到 Dify 的源码仓库后会发现，它不是一个单体应用，而是一组前后端分离的微服务。大致由这些部分组成：

理解这个结构对你后续部署和排查问题非常有帮助。比如你看到一个报错“无法上传文档到知识库”，那大概率是 worker 或者向量数据库出了问题，而不是前端的问题；看到“工作流里的 HTTP 请求节点报 403”，那大概率是 ssrf_proxy 在起作用——它在帮你拦截非法的网络请求。

提示：Dify 的社区版虽然开源免费，但它和商业版之间的差异主要在企业级运维、权限审计、高可用方面。个人和中小团队使用社区版完全够用，这点后面我还会展开讲。

2. 怎么装：本地部署的完整实操路径

Dify 的部署方式有好几种，官方推荐的是 Docker Compose 一键部署。注意，我强烈建议你在动手之前先看一眼官方文档里对 Docker 版本的要求，不要用太老的 Docker，否则有些新镜像特性不兼容，起不来。实践下来最稳的组合是：Docker 20.10 以上 + Docker Compose v2.x + 2C4G 以上的机器。

2.1 部署前准备：硬件与环境要求

Dify 本身对硬件要求不高，因为它实际上是一个很轻量的 Web 应用，真正吃资源的是你打算在它里面使用的大模型接口，和它本地运行的向量数据库。Dify 官方给的是 2C4G 起步，但我实测下来，如果同时要跑知识库索引、多个工作流并发，4C8G 会舒适很多。尤其是你打算用到 Sandbox 去执行 Python 代码的时候，CPU 会被瞬间拉高。

操作系统方面，Linux、macOS、Windows 都能跑。但这里有个非常重要的细节：Windows 原生部署 Docker 其实是在 WSL2 或 Hyper-V 虚拟机里跑的，所以性能会有小幅损耗，而且目录挂载的方式和 Linux 有差异。新手如果一定要在 Windows 上跑，优先装 Docker Desktop，开 WSL2 后端。

存储方面，建议给 Dify 至少留 50GB 可用空间。这里面不仅包括镜像本身，还包括你后续上传知识库文档、向量数据库持久化、日志增长的空间。很多人用着用着发现磁盘满了，就是因为一开始只给了 10GB，知识库一传多就炸了。

2.2 Docker 一键安装（推荐方案）

官方仓库克隆下来之后，整个流程对我来说基本就是一套熟得不能再熟的步骤：

# 克隆官方仓库 git clone https://github.com/langgenius/dify.git cd dify/docker # 复制环境变量模板 cp .env.example .env # 启动所有服务 docker compose up -d

等它拉完镜像起来之后，访问http://localhost就能进入初始化页面了。首次进入会让你设置管理员账号，这一步要先想好邮箱和密码，后面登录系统都靠它。

需要注意 .env 文件里有几个关键配置项。我个人习惯在启动前改掉这几个：

• SECRET_KEY：系统加密密钥，务必改成一个足够长的随机字符串，别用默认值。这个和数据库里的敏感信息加密直接相关，部署后再改会出问题。
• POSTGRES_PASSWORD和REDIS_PASSWORD：数据库和 Redis 的密码，改成非默认的，至少后面机器暴露到公网时不会直接被扫到弱口令。
• DIFY_PORT：默认 80，如果你本机 80 已经被占了，改成别的端口，比如 8088。

改完 .env 之后再执行docker compose up -d，这才是完整正确的流程。千万别拿到项目就一把梭，默认配置适合本地开发，生产环境一定要改密钥。

2.3 国内镜像加速方案

因为 Dify 镜像托管在 Docker Hub 上，国内环境拉取时速度可能不尽如人意。这个不属于 Dify 本身的问题，而是网络环境问题。我自己的做法是给 Docker 配置镜像加速器。

Linux 上路径是/etc/docker/daemon.json，Windows Docker Desktop 则在 Settings 里的 Docker Engine 里编辑。加一段类似的内容：

{ "registry-mirrors": ["https://你的加速地址"] }

重启 Docker 后再拉镜像，速度会有明显改善。要注意不同时间段加速器服务的稳定性不同，建议在.env里把IMAGE_TAG指定为你需要的具体版本，拉镜像时也方便核对 digest。

2.4 Windows 本地部署（Hyper-V + Docker）

网上问“win10 本地部署 dify”的人很多，我帮一个朋友踩过一次坑之后，把方法总结成了下面几步。

第一，先在 Windows 功能里启用 Hyper-V 和“适用于 Linux 的 Windows 子系统”，然后装 Docker Desktop，设置里把 WSL2 作为后端。这里有一个很关键的判断：如果你机器上开了虚拟机软件（比如 VMware），Hyper-V 和它会冲突。这种情况更推荐直接用 WSL2 装 Docker。

第二，把 Dify 项目放在一个路径简单、无中文、无空格的目录下。Windows 上 Docker 的目录挂载对路径非常敏感，项目放在D:\apps\dify这样的路径下最省心。

第三，执行同样的docker compose up -d，然后访问http://localhost。Windows 下最常见的坑有这么几个：80 端口被 IIS 或别的程序占用导致启动失败；docker compose 版本太老导致启动命令报错；项目目录放在 OneDrive 同步目录里导致文件读写异常。你逐个排查就好。

2.5 飞牛 NAS 部署与 ARM 架构适配

得益于 Docker 镜像的多架构支持，Dify 在 NAS 上部署也越来越常见。飞牛、群晖、威联通这些 NAS 上，只要打开了 Docker 容器管理功能，操作方式基本一致：注册表里搜langgenius/dify-api，拉镜像，然后把 docker-compose 里的服务一个个创建出来。

不过 NAS 上有个显著区别：很多家用 NAS 是 ARM 架构。Dify 官方镜像目前对主流平台都有支持，我在 ARM 设备上实测过核心功能，跑工作流和知识库没问题，但 Sandbox 执行 Python 代码时可能会有部分依赖对 ARM 支持不佳。如果你有这类的运行需求，建议在 x86 机器上部署，或者改在流程里避开 Sandbox 节点。

实战建议：NAS 部署时别忘了把数据目录映射到 NAS 的存储池里。很多人在 NAS 上装 Dify 图的就是存储空间大、知识库可以放海量文档，如果数据目录留在容器内部，一旦容器重建数据全没，这就本末倒置了。

3. 能做什么：Dify 的核心能力与场景拆解

Dify 能做的远不止一个“聊天机器人”。我的判断标准很简单：凡是需要大模型参与、且有明确业务逻辑的交互场景，都可以在 Dify 上用工作流实现。下面我把几个高频场景拆开讲透，你就能明白为什么我说它是个“生产级工具”而不是个“玩具”。

3.1 工作流编排：把复杂逻辑可视化串联

Dify 的工作流编辑器是我见过最直观的节点编排之一，左拖右拖就能把“开始→问题分类→知识库检索→大模型→结束”串起来。和写代码不同的是，每个节点的输入输出都清清楚楚地展示在界面上，你可以实时查看中间结果，方便调试。

实用场景举例：一个客服机器人，请求进来先判断是“售前咨询”还是“售后投诉”。这里可以用IF/ELSE 节点做分支，不同的分支走不同的 Prompt 和知识库。然后接一个变量聚合节点，把多个分支的结果整合到一起再输出。这套逻辑完全可视化，不需要写一行后端代码。

很多人刚接触时容易忽略变量赋值的使用。Dify 工作流里，sys.query是用户输入这个系统变量，{{#节点ID#}}可以引用任何节点的输出。你想要在 Prompt 里注入知识库检索结果、或者把上一步模型的输出传给下一步的 HTTP 请求，全靠这些变量引用。理解了变量引用规则，工作流才能真正玩转。

3.2 知识库与 RAG：搭建自己的本地知识库

这是 Dify 被问得最多的场景之一。把企业文档、个人笔记、PDF、网页内容传进知识库，Dify 会自动做分段、清洗、向量化，之后你的 AI 应用就可以基于这些文档进行问答。

搭建知识库的时候有几个关键参数需要调：

• 分段模式：默认是“自动分段”，但如果你想精细控制，可以把分隔符设置成自定义的，比如按 Markdown 标题分隔。这样检索出来的片段上下文更完整。
• TopK 与 Score 阈值：TopK 决定了召回多少片段，Score 阈值过滤掉不相关的内容。这两个参数决定了回答的准确性，不能只依赖默认值。
• 索引方式：高质量模式（用 Embedding 模型）适合做语义检索；经济模式（用关键词）速度快但效果差。既然都上 Dify 了，我建议直接用高质量模式。

另一个高频需求是用 Dify 读硬盘/workflow API。Dify 工作流里有一个“知识检索”节点，还可以配合 HTTP 请求节点去调用外部 API 拉取数据后，再注入到知识库检索逻辑里，实现动态数据的 RAG。简单来说就是：先从自己的业务系统拉数据，再把拼接好的文本交给大模型回答。这个思路在很多数据看板、内部问答场景里非常实用。

3.3 Agent 与工具调用：让模型不止会聊天

光有大模型聊天还不够，Dify 里真正让应用“能干重活”的是 Agent 能力。你可以给 Agent 配置工具，比如“查询天气的 API”“查数据库的接口”“计算器”，模型会根据用户的意图自动选择调用哪个工具。

举例说明：我给某个内部应用接了 Dify 的 Agent，配置了一个 HTTP 工具对应到公司订单系统。用户问“上个月华东区订单总额是多少”，Agent 先判断需要调用订单接口，自动生成请求参数，拿到返回值后整理成自然语言回答用户。这个链路里，所有工具的参数说明就是模型的“说明书”，写得越清楚，模型调得越准确。工具描述里记得写明参数含义、返回结构，别指望模型自己猜。

还有一层是Cursor 连接 Dify 知识库。你在 Cursor 里面写代码时想在编辑器里直接查询 Dify 知识库，思路是把 Dify 知识库检索通过 API 暴露出来，Cursor 里通过自定义 MCP 或 HTTP 调用，把检索结果作为上下文塞给 Cursor 的对话。这也属于 Agent 工具调用的范畴，本质上就是“让模型会查知识库”。

3.4 其他高频能力：爬取网页、自然语言查数据库、Markdown 转 Word

热词里出现的“dify 如何爬取网址信息并保存到数据库中”，这个用 Dify 的工作流完全可以实现。思路是：开始节点接收 URL → HTTP 请求节点抓取网页内容 → 代码节点用 BeautifulSoup 或正则做清洗提取 → 再通过 HTTP 请求写入你自己的数据库 API。整个过程不需要单独写一个爬虫服务，Dify 工作流本身就是调度器。

“dify 实现自然语言查询数据库（达梦数据库）”也属于同一类能力。将用户的问题 → 借助大模型生成 SQL → 通过 HTTP 工具执行/处理 → 返回结果。需要注意两点：一是数据库权限必须做严格限制，只给查询权限不要给写权限；二是生产环境一定要加人工确认节点，防止 AI 生成的 SQL 误操作。用在上面的 Prompt 我通常会加一句“只允许生成 SELECT 语句”，同时在系统层面再兜一道，用户输入尽量不要直接拼接进去。

“dify markdown 转 word 中序号自动编号”这个问题，我见到的场景是：文档流里先生成了 Markdown，再转成 Word 报告，但转换后列表序号乱糟糟的。解决办法是双层处理：先在工作流里用代码节点，把 Markdown 列表转换为 Word 兼容的格式，或者直接把模板做成 Word 模板再替换变量。Dify 里的代码节点是支持 Python 的，处理这种文档转换非常顺手。

4. 部署后的运维实战：升级、迁移与多租户

Dify 装好了、应用也搭出来了，真正考验人的其实是后续的运维环节。升级、迁移、多租户、二次开发，每一项都有人踩坑，我这里分享的都是我自己实际操作过的路径。

4.1 在线升级与版本更新（包含 Windows）

Dify 的版本迭代非常频繁，社区版几乎每个月都有新功能。升级操作本身不复杂：

# 在 dify/docker 目录下 git pull origin main docker compose up -d

但有几个升级前的注意事项：

• 备份数据库：升级本质上会改数据库结构，一旦失败要能回滚。建议先执行docker compose exec db pg_dump -U dify dify > 备份文件.sql做一次完整备份。
• 检查版本兼容：如果你的 .env 里指定了 IMAGE_TAG，升级前要把镜像版本号改为目标版本。默认 main 分支对应 latest 标签，但我不建议生产环境直接用 latest，版本漂移后很难回溯问题。
• 观察迁移日志：升级时如果自动执行数据库迁移，留意 api 服务日志里有没有报错。迁移卡住了就等一会儿，不要立刻重启容器，否则容易造成重复迁移。

Windows 上的升级路径和 Linux 一样，用 Git 拉同步仓库，然后 docker compose up -d 即可。注意 Windows 下 Git 如果有换行符转换问题，可能导致 .env 被自动修改，建议git config core.autocrlf false之后再拉取。

4.2 数据迁移与备份恢复

换服务器或者从一台机器迁到另一台机器，核心就是迁移两个东西：数据库数据 和 存储目录。

我建议的迁移顺序是：新机器先装好同样版本的 Dify，启动一次初始化完成后停止 → 用旧机器的数据库备份恢复到新机器的 Postgres → 用旧机器的docker/volumes目录覆盖新机器的对应目录 → 重启所有容器。

存储目录里最重要的是 upload 文件夹和向量数据库数据。如果你用的是系统自带的 PostgreSQL + 默认向量插件，那全量迁移数据库就都带过去了；但如果你自建了外部向量数据库（如 Weaviate、Qdrant），记得向量库也要一起迁移。很多人在这一步翻车，因为忘了向量化文档其实在向量库里，光迁移 Postgres 是没用的，知识库文档“能看到但检索不到”。

4.3 社区版 1.10 多租户机制

关于“dify 社区版 1.10 多租户”，我的理解是 Dify 本身支持多工作空间，但真正的多租户隔离能力在开源版里是有限制的。你可以创建多个“空间”（Workspace），每个空间里各自管理应用、知识库、模型配置、成员权限。这是比较实用的一种多租户：

• 一个公司内部可以按部门建空间，财务、人事、技术各用各的。
• 空间之间应用和知识库天然隔离，互不可见。
• 系统管理员可以统一管理所有空间。

如果你需要更细粒度的多租户资源隔离（比如限制每个租户的模型配额、单独计费），那是商业版的能力范畴，社区版目前做不到。我之前给一家小公司做过内部 AI 平台，就是靠“一个空间对应一个团队”的模式落地的，实际效果很不错。

4.4 二次开发与 API 集成

Dify 是开源的，意味着你可以动源码。最常做的二次开发有两种：

• 前端定制：改 web 目录下的页面逻辑、文案、UI，重新构建镜像。适合想做品牌定制、或者给内部用户做简化界面的场景。
• 后端能力扩展：在 api 目录里加自定义代码、增加新的工具类型、写新的节点。适合需要和内部系统深度打通的场景。

不改源码也能集成的方式有很多，Dify 每一个应用都配有完整的 API 文档，你可以用 OpenAPI 规范直接对接。很多企业是“Dify 负责 AI 应用逻辑，业务系统负责发起请求”，通过 API 打通之后，Dify 就成了企业里的 AI 能力中台。

我特别提醒一句：接 API 时不要直接用管理后台的 API 密钥做生产调用。应该在应用配置里单独创建“API 访问凭据”，这样即使泄露了，也只在单应用范围内，不会波及整个系统。

5. 常见问题与排查技巧：从报错到解决方案

最后这一部分，我把热词里出现的高频报错和操作问题集中整理成一张速查表，再挑几个典型的讲下排查思路。这些都是社区里反复出现的问题，能帮你省下大量跪求答案的时间。

5.1 高频报错速查表

5.2 典型排查思路：以“接口 403”为例

Dify 里的 403 报错我遇到过不少，最典型的就是工作流里 HTTP 请求节点访问外部地址被拦截。Dify 默认带了一个 SSRF 防护代理，它会阻止服务端请求访问内网地址。你在工作流里调用http://192.168.x.x这类内网接口时会直接 403。怎么处理呢？

如果你的需求就是要在内网环境里调用内部服务，可以去改.env里 SSRF 相关的配置，把目标内网网段加入白名单，或者把 ssrf_proxy 关掉。但是——把这个防护关掉是有风险的，Dify 的 API 服务一旦被外面的人利用来发起内网探测，你的内网信息就可能会被带出去。我的建议是：如果非用不可，也要放在可信内网环境，并且尽可能精确地加白名单，而不是一刀切全部放行。

5.3 高频操作问题：插件启用、安装与国内镜像

关于“dify 上安装了 github 插件后，怎么才能开始启用”，这个问题主要是对 Dify 的“插件市场”不熟悉。Dify 的插件安装完成后，你还要到“插件管理”页面里去点击启用，并且在某个具体应用里选择把该插件绑到哪些工具上。只装不启用，等于没装。插件系统的逻辑是：先安装到平台 → 再启用为可用状态 → 再在应用的工具列表里引用。三步缺一不可。

关于“dify 内网部署怎么安装插件”，这个在没外网的环境里会比较折腾。Dify 插件有两种安装方式：一种是从在线插件市场直接安装，需要能访问外网；另一种是离线安装，把装好的插件包（通常是.difypkg文件）上传到平台上安装。内网环境只能走离线安装这条路，你需要在一台能联网的机器上先下载插件包，再拷进去装。版本兼容性要特别注意，新装的插件要求 Dify 内核版本不低于某个门槛，装不上就先升级系统。

5.4 其他高频操作问题

• Dify 平台登录入口官网：自部署后访问你自己的域名/IP 就是登录入口；云服务版则是官方提供的订阅地址。别把“官网”和“控制台登录入口”搞混，部署完从自己域名进就行。
• 安装 Skill：Skill 本质上就是插件/工具集。它的用处是给 Agent 预置一套可调用的技能，比如文档解析、表格处理。安装和启用逻辑同上。
• Dify 支持 ARM 吗：支持，主流架构都能跑，但部分高级功能（如 Sandbox）在 ARM 下可能有问题。
• Dify 读硬盘：这里的“读硬盘”通常指知识库加载本地文件，或者工作流通过代码节点访问挂载目录。只要你把宿主机目录挂载进容器，Dify 里的代码节点就能读到对应文件。
• Windows 在线升级：和 Linux 一样，git pull + docker compose up -d，唯一的坑是换行符和路径权限。

6. 关于 Dify 的选型建议与个人体会

说句掏心窝的话：在我用过的所有开源 AI 应用平台里，Dify 是少数几个让我觉得“它能承接真实业务”的工具。它最大的优势不是某个单一功能，而是把“模型接入、应用编排、知识库、工具调用、API 发布”整合成了一整条顺畅的流水线。我实际用下来，从部署到上线第一个客服机器人只花了两天，其中大半天还在调 Prompt。

如果让我给选择建议，我会这样说：你是个人开发者，想快速验证 AI 想法，Dify 的社区版 Docker 一键部署就够；你是小团队想给内部做知识库和 AI 助手，Dify 也扛得住；你是企业级要支撑高并发、大规模多租户、细粒度权限审计，那就得认真评估社区版的边界，或者考虑商业版。

最后分享一个我自己的运维心得：Dify 的日志最好从第一天就收集起来。用默认的docker compose logs看日志在出问题时会很痛苦，因为多个容器日志交错在一起。我现在的做法是给 Dify 配上 Loki 或简单的日志文件轮转，问题出现时能快速定位。另一个小技巧是升级前多看 Releases 页面，Dify 的 Release Notes 写得很细，每个版本的迁移注意点都会列出来，照着做基本不会翻车。

Dify 这个项目还在高速迭代，它不会替你解决所有问题，但只要你理解了“平台帮你管住复杂，你专注业务逻辑”这个定位，它就能成为 AI 应用开发里非常趁手的一件工具。