企业官网建设流程全解析

在 2026 年的大模型应用落地场景里，Dify 和 AI 工作流几乎成为团队搭建业务系统的常用起点。Dify 是一个开源的大模型应用开发平台，它把模型接入、提示词编排、知识库检索、工作流编排、日志观测和 API 发布整合到一套可视化界面中；AI 工作流则是指把一次大模型对话或批处理任务拆解成多个节点，由平台按照连线顺序执行。两者结合后，业务人员可以通过拖拽节点完成功能搭建，开发人员只需要关注复杂节点、系统集成和上线运维。

这篇文章不会停留在界面介绍层面，而是按照一条从入门到精通的实践路径展开：先理解 Dify 的工作原理，再完成本地部署，随后用一个最小工作流跑通全流程，再做知识库 RAG 实战，最后给出参数速查、问题排查和生产化建议。整条路径覆盖了企业级项目中反复出现的部署、编排、知识库、连续对话和排错场景，适合正在学习 AI 工作流搭建的初学者，也适合要把 Dify 引入团队项目的后端开发者。

1. 先理解 Dify 到底解决什么问题

1.1 Dify 是什么，和直接调用大模型 API 有什么区别

通俗地说，Dify 是一个把大模型封装成可视化可操作平台的开源工具。你不需要自己维护模型接入层、会话管理、日志存储和 Prompt 管理代码，只需要在网页上配置模型供应商，然后通过拖拽节点来定义应用行为。

从技术定义上看，Dify 属于 LLMOps 平台，核心能力包括模型管理、应用编排、知识库检索（RAG）、工作流编排、Agent 工具调用和 API 发布。它和直接调用大模型 API 的最大区别在于：

• 直接调用 API 时，每次对话的上下文、历史消息、Prompt 拼接、知识库召回逻辑都要自己写，且每个新项目都要重复写一遍。
• 使用 Dify 时，这些逻辑沉淀为平台能力，业务变更通过界面调整配置即可完成，不需要重新发布代码。

实际项目中最有价值的不是“能对话”，而是把对话改造成一个可治理的业务流程。Dify 的工作流编排正是这种治理能力的载体，它让 AI 应用的执行过程变得可见、可控、可修改。

1.2 AI 工作流的核心概念：节点、变量、连线

工作流是 Dify 中除了“聊天助手”之外的另一种应用形态，也是企业级项目中最常使用的形态。理解工作流只需要抓住三个概念：

• 节点：工作流的最小执行单元，常见节点类型包括开始、LLM、知识检索、条件分支、代码执行、HTTP 请求、模板转换和结束。
• 变量：节点之间传递的数据载体，包括用户输入变量、系统变量和上游节点的输出变量。
• 连线：定义节点之间的执行顺序和数据流向。

一个最简单的文本摘要工作流可以表示为：开始节点接收用户输入的文本，LLM 节点读取该变量并生成摘要，结束节点输出结果。这里的“开始节点输入”就是变量，LLM 节点通过变量引用拿到数据，执行完成后把结果作为输出变量传给结束节点。

为什么要用节点拆解而不是让大模型一步完成？原因有三个：第一，节点让每个处理环节都有独立的日志和耗时，方便定位哪一步出现质量问题；第二，条件分支可以针对不同输入走不同处理路径，这是单次 Prompt 很难稳定实现的；第三，知识检索、代码执行、HTTP 调用这类能力必须由固定逻辑完成，不能依赖模型自由发挥。

1.3 学习环境和生产环境的定位差异

初学者往往在一个环境里既做练习又跑正式业务，这是很多问题的根源。学习环境的目的是快速跑通功能，生产环境的目的是稳定交付业务价值，两者的要求完全不同。

这个表格不是要求新手一步到位，而是提醒你在设计学习路径时，就要为“从学习环境迁移到生产环境”留出改造空间。比如知识库的文档大小、并发请求量、模型超时时间，这些参数在学习和生产环境里应该使用不同配置。

2. 部署准备：本地安装 Dify 社区版

2.1 环境要求先对齐

Dify 社区版推荐使用 Docker Compose 方式部署，这也是最容易复现的环境准备方式。在正式安装前，先确认本机满足以下条件：

这里要注意，如果你的机器内存只有 8 GB，同时又想在本地运行 7B 以上参数的模型，建议优先保证 Dify 服务的可用性，模型可以选择较小的量化版本，或者暂时使用云端 API。否则会出现容器互相抢内存，Dify 页面偶尔能打开、偶尔报 502 的奇怪现象。

2.2 使用 Docker Compose 完成安装

安装 Dify 社区版的标准流程是拉取源码仓库中的 docker 目录，然后启动编排文件。以下命令用于说明整体步骤，实际执行前请确认你使用的版本和安装包路径。

# 拉取 Dify 源码仓库到本地 git clone https://github.com/langgenius/dify.git # 进入 docker 编排目录 cd dify/docker # 复制环境变量模板 cp .env.example .env # 启动全部容器 docker compose up -d

启动完成后，可以用下面命令观察容器状态：

docker compose ps

正常情况下会看到 api、worker、web、db、redis、sandbox、ssrf_proxy 等容器处于 running 状态。然后访问http://localhost/install完成初始化设置，设置管理员账号后即可进入 Dify 主界面。

这里解释几个关键点：

• .env文件集中管理数据库、Redis、端口、密钥等配置，生产环境不要使用默认密钥。
• docker compose up -d使用后台模式启动，便于关闭终端后继续运行。
• Dify 会创建多个容器，它们分工不同：api提供后端接口，worker执行异步任务，web提供前端页面，sandbox隔离代码执行节点。

如果当前机器已经安装过旧版本，升级前必须先备份数据库和持久化目录。Dify 的数据主要落在 Docker 卷中，常见操作是备份dify/docker/volumes目录，同时导出数据库内容。

2.3 接入本地模型：Ollama 与 BGE-M3 的搭配

很多教程在部署完 Dify 后卡在模型配置这一步，因为 Dify 本身不产模型，需要先有一个可用的模型服务。本地环境推荐使用 Ollama 运行推理模型和 Embedding 模型，组合通常是：

• 推理模型：qwen2.5 系列或 llama3 系列，负责对话生成。
• Embedding 模型：bge-m3，负责把文本转换为向量，用于知识库检索。

先安装 Ollama 并拉取模型：

# 安装 Ollama 后，先拉取推理模型 ollama pull qwen2.5:7b # 拉取 Embedding 模型 ollama pull bge-m3 # 查看本地已有模型 ollama list

然后在 Dify 界面中进入“设置 - 模型供应商”，选择 Ollama，填写以下配置：

这里最容易踩的坑是地址写错。在 Docker 容器内，127.0.0.1指向容器自身，而不是宿主机。因此访问本机 Ollama 时要使用host.docker.internal，Linux 下如果该域名不可用，则需要额外配置extra_hosts或使用宿主机局域网 IP。

配置完成后，在模型供应商页面点击“测试”，能看到模型响应说明接入成功。如果超时或返回连接失败，下一步需要检查 Ollama 服务是否监听正确的端口，以及 Docker 是否允许容器访问宿主机网络。

3. 从零搭建第一个可运行的工作流

3.1 创建应用并选择应用形态

进入 Dify 工作台后，点击“创建空白应用”，会看到多种应用类型。这里要先做一个区分：

入门阶段建议先创建一个“工作流”应用，因为它的节点执行顺序最直观。创建后可以看到一个空白画布，画布上默认有一个开始节点和一个结束节点。

在选择模型之前，先确认模型供应商已经配置完成。如果是第 2 章中接好的 Ollama 模型，这一步只需要把 LLM 节点里的模型切换到 qwen2.5:7b 即可。

3.2 用三个节点跑通最小闭环

最小闭环由三个节点组成：开始节点负责接收输入，LLM 节点负责生成内容，结束节点负责输出结果。

第一步，在开始节点中新增一个输入变量，命名为query，类型选择“文本段落”。这个变量会成为后续节点引用用户输入的入口。

第二步，拖入一个 LLM 节点，连线从开始节点指向 LLM 节点。在 LLM 节点的“提示词”区域使用如下模板：

你是一个专业的技术文档助手。 请根据用户的问题，生成一段 200 字以内的回答。 用户问题： {{#start#.query}}

这里{{#start#.query}}是 Dify 的变量引用语法，表示读取开始节点输出的 query 变量。如果变量名或节点 ID 不对，运行时会提示变量为空，因此不要在界面上手写节点 ID，使用编辑框里的变量插入功能更保险。

第三步，把 LLM 节点连接到结束节点，在结束节点的输出变量中选择LLM.text。这样一个工作流就完成了，它做的事情是：接收文本输入，交给大模型生成回答，把回答展示给调用方。

3.3 验证运行结果和管理运行时日志

点击画布右上角的“运行”按钮，在输入框中填写一个问题，观察每步节点的执行情况。Dify 会显示每个节点的输入输出和耗时，这是排查工作流问题最重要的入口。

正常运行时可以看到：

• 开始节点输出包含query变量。
• LLM 节点输出包含模型生成的text。
• 结束节点把最终结果返回。

如果 LLM 节点报错，常见原因是模型名称不存在、模型服务未启动、提示词语法错误。这时先看节点日志中的错误信息，再回到模型供应商页面测试模型连通性。

工作流调试通过后，可以在“发布”菜单中把它发布为 API 服务。发布后系统会生成 API 密钥，业务系统通过 HTTP 接口调用这个工作流，实现其他项目对 AI 能力的复用。

4. 企业级实战：基于知识库的 RAG 工作流

4.1 创建知识库并理解文档处理过程

知识库是 RAG 项目的核心。RAG 的基本逻辑是：用户提问时，先从知识库中检索出相关文档片段，再把片段和问题一起交给大模型，让模型基于检索到的内容作答。这样做可以减少模型“不知道”和“乱编”的问题。

在 Dify 中创建知识库的流程是：进入“知识库”页面，点击“创建知识库”，上传文档，然后选择分段和索引方式。

文档上传后，Dify 会把文档切分成多个文本片段，再为每个片段生成向量。分段规则直接影响检索效果：

自定义分段时有两个关键参数：最大分段长度和分段重叠长度。最大分段长度控制每个片段包含多少字符，太长会稀释语义，太短会导致信息不完整；分段重叠长度用于避免关键句子恰好落在两个片段的边界而被切断。

索引方式选择“高质量”模式会调用 Embedding 模型，向量检索效果更好，但需要模型服务稳定。选择“经济”模式使用离线关键词索引，速度快但语义检索能力弱，学习环境可以先跑通，生产环境建议使用高质量模式。

4.2 召回参数必须逐项理解

工作流中的“知识检索”节点负责从知识库中召回相关片段。很多人只是把知识库拖进来，完全不调参数，导致回答质量差却不知道原因。召回参数中最重要的三个是：

TopK 和 Score 阈值要一起调整。先观察检索结果中相关片段的分数分布，再确定阈值。如果阈值设为 0.8，而实际相关片段分数只有 0.5，你会得到一个回答“知识库中没有相关内容”的空结果，这不一定代表知识库没数据，而是阈值设置不合理。

如果需要更精确的排序，可以配置 Rerank 模型。Rerank 会把召回的多个片段与用户问题做更深入的语义匹配，重新排列顺序，通常能明显提升长文档场景的准确性，但会增加响应时间。

4.3 在工作流中完成“检索 - 拼装 - 生成”

创建一个新的 Chatflow 或工作流应用，按下面顺序搭建节点：

1. 开始节点接收用户问题变量query。
2. 知识检索节点选择刚建好的知识库，检索输入选择query。
3. LLM 节点读取检索结果，使用模板拼装上下文。
4. 结束节点输出最终答案。

LLM 提示词模板可以这样设计：

你是公司的售后客服助手。请严格基于下面的知识库内容回答用户问题。如果知识库中没有相关内容，请直接说明“知识库中暂无相关信息”，不要编造。 知识库内容： {{#knowledgeRetrieval#.result}} 用户问题： {{#start#.query}}

这里的{{#knowledgeRetrieval#.result}}是知识检索节点的输出变量，内容通常是召回片段的拼接结果。默认的拼接结果可能包含额外格式，例如段落自身的元信息，建议在实际项目中增加一个“模板转换”节点，把检索结果清洗成排好序的文本列表再传给 LLM。

生产项目中还应该在生成环节加一层条件分支：如果检索结果为空，直接走“无答案”分支，不再调用大模型，这样既能省一次调用成本，也能避免模型在缺乏依据的情况下强行作答。

4.4 客服连续对话场景的处理

知识库问答最容易出现的问题是“多轮对话时，用户问‘那第二个方案呢’，系统并不知道‘那’指什么”。在 Chatflow 中，连续对话需要用到会话历史和变量记忆机制。

处理思路是：

• 开启 Chatflow 的对话记忆功能，让系统可以把多轮对话历史传给 LLM。
• 在新一轮问答时，把用户当前问题与会话历史一起送入知识检索。
• 如果业务复杂，可以使用“问题分类器”节点先判断是否属于追问场景，再决定是否重新检索。

不要把大量历史消息全部塞进 Prompt。随着对话轮次增加，Token 消耗会快速上涨，而且模型对过长上下文的关注度会下降。通常只需要保留最近 3 到 5 轮对话，再配合一个“重写用户问题”的步骤，让大模型把“那第二个方案呢”改写为包含上下文的完整问题，再接知识检索。

5. 关键参数速查与调优

5.1 大模型生成参数

Dify 的 LLM 节点提供以下常用参数，它们共同控制生成结果的随机性和格式。

客服、制度问答等需要固定答案的场景，Temperature 建议设置在 0.1 到 0.2；头脑风暴、文案创作等需要多样性的场景，可以设置在 0.7 左右。不要在同一个生产工作流里频繁修改这些参数，参数变更要记录到变更说明中，否则回答质量波动时很难定位原因。

5.2 知识库分段和检索参数

这里特别提醒：分段参数调整后必须重新处理知识库文档才会生效。只修改参数不重新分段，检索结果不会变化，这是初学者最容易困惑的地方。

5.3 工作流节点通用执行参数

每个节点都有执行超时、错误重试等通用属性。生产环境建议统一设置：

• 超时时间：模型响应超时建议 60 秒以上，本地模型更慢时可放宽。
• 错误重试：关键节点开启 1 到 2 次重试，但要确认目标服务是否有幂等性。
• 最大运行并行数：涉及并发调用的工作流要限制并发数，避免把本地模型打满。

6. 常见问题排查链路

6.1 知识库修改时报 Internal Server Error

现象：进入知识库详情页，修改文档或重新分段后保存时，页面提示internal server error，知识库无法更新。

可能的排查链路如下：

1. 先看 api 容器日志，定位是哪个模块抛出的异常。
2. 检查磁盘空间是否已满，向量库写入时磁盘不足是最常见原因。
3. 检查 Embedding 模型是否可用。重新分段需要重新生成向量，如果 Ollama 中的 bge-m3 服务未启动或地址变更，索引会失败。
4. 检查数据库连接和迁移状态。升级版本后如果未完成数据库迁移，知识库相关表结构可能不一致。

# 查看 api 容器最近日志 docker compose logs api --tail 200 # 查看 worker 容器异步任务日志 docker compose logs worker --tail 200

如果是升级后出现的知识库报错，优先确认.env配置和数据库迁移是否在启动时自动完成。生产环境升级 Dify 前，一定要先备份 volumes 和数据库，避免无法回滚。

6.2 Ollama 模型连接失败

现象：在 Dify 模型供应商页面测试 Ollama 模型，提示连接超时或connection refused。

按以下顺序检查：

1. 先在本机终端执行ollama list，确认 Ollama 服务在运行。
2. 在容器内测试宿主机地址是否可达。
3. 确认 API Base URL 是否使用了host.docker.internal，而不是127.0.0.1。
4. Linux 环境如果host.docker.internal无效，需要在 docker-compose 文件中为 api 容器增加extra_hosts: - "host.docker.internal:host-gateway"。
5. 检查 Ollama 是否开放了外部访问。Ollama 默认监听127.0.0.1:11434，如果 Dify 通过局域网 IP 访问宿主机，需要先确认网络策略。

这台机器上的防火墙策略也要检查。生产服务器上 Docker 容器访问宿主机端口常常被防火墙拦截，这不是 Dify 本身的问题。

6.3 升级后服务异常或配置丢失

现象：执行docker compose pull和docker compose up -d后，部分容器反复重启，或登录后界面数据为空。

排查建议：

1. 升级前没有改过.env关键配置，异常通常在数据库与新版代码不兼容。
2. 查看容器启动日志，如果是数据库连接失败，检查数据库容器是否正常迁移。
3. 对比.env.example与当前.env，确认新增的配置项是否缺失。
4. 如果数据无法挽回，只能回滚到备份。因此升级前必须执行备份：

# 关闭服务 docker compose down # 备份容器数据卷目录（示例路径） cp -r dify/docker/volumes dify/docker/volumes_backup_日期

版本升级过程中不要直接在运行中的生产环境里操作。先在本地或测试环境复现升级流程，确认知识库保存、工作流运行、API 调用都正常后，再对生产环境操作。

6.4 其他高频问题速查表

7. 从入门到精通的实践清单与扩展方向

7.1 学习路径可以按五层递进

视频课程和企业项目训练营给出的“20 个实战项目”，本质上不会超过以下五层能力。建议你按这个顺序练习：

第一层：部署与模型接入。完成 Dify 安装、Ollama 接入、本地 Embedding 部署，目标是任何模型都能在平台内稳定调用。

第二层：基础工作流。完成文本生成、内容总结、关键词提取三个项目，掌握变量、节点、模板语法和条件分支。

第三层：知识库 RAG。完成客服问答、制度查询、文档问答三个项目，重点调优分段和召回参数。

第四层：复杂工作流集成。完成数据分析助手、审批流、多工具调用、HTTP 集成项目，掌握代码节点、HTTP 节点和外部系统对接。

第五层：生产化改造。完成日志接入、监控告警、多租户权限、版本发布流程，把一个实验项目改造成可交付的业务系统。

这里面最值得反复练习的是第三层和第四层。RAG 决定了回答质量的上限，外部系统集成决定了 Dify 能否真正进入业务链路，这两项能力在企业项目中出现频率最高。

7.2 生产环境还需要哪些额外保障

学习环境跑通后，上生产还差几步关键工作：

• 模型选择要稳定：生产环境使用商业 API 或内部推理服务，本地 Ollama 只适合开发和测试。
• 配置外置化：把数据库密码、模型 API Key、Ollama 地址放到环境变量或密钥管理系统中，不要写死在仓库里。
• 备份策略：定期备份 Docker 卷、数据库和知识库源文件，至少保留最近三份备份。
• 监控告警：接入日志采集系统，关注工作流失败率、平均响应时长、模型调用失败次数。
• 回滚方案：记录每个版本的镜像标签和数据库迁移脚本，出现问题能在半小时内回滚。

7.3 可复用的项目上线检查清单

发布任何一个 Dify 工作流到生产环境前，建议逐项确认以下清单：

• 模型供应商配置是否正确，API Key 是否使用生产密钥。
• 工作流在测试环境已用真实业务数据验证，包含边界输入和异常输入。
• 知识库文档已按生产分段规则重新处理，召回分数符合预期。
• 超时时间和重试策略已设置，避免接口长时间无响应。
• API 密钥已创建，且只授权给需要的业务系统。
• 日志已接入统一日志平台，错误能按请求 ID 追溯。
• 数据库和持久化目录已完成备份，且备份可恢复。
• 多租户或权限配置已按业务角色校验。
• 升级步骤和回滚步骤已在测试环境演练过。

Dify 的入门难点不在界面操作，而在于是否理解每个节点背后的执行逻辑，以及每一步配置会如何影响最终生成质量。把最小工作流跑通只是起点，真正值得投入时间的是知识库参数调优、外部系统集成和生产化部署。建议从今天动手完成本地部署，用你自己的文档做一个知识库问答项目，然后逐步加入条件分支、工具调用和外部接口，这套能力比看多少教程都更有价值。