极简入门，本地部署dify低代码平台构建AI Agent大模型全流程（使用教程、微案例、配置详解、架构图解析）

一、环境搭建

1.1 安装VMware-workstation+CentOS7.9

VMware安装完后，典型安装即可，一直下一步。

注意配置要求：
CPU >= 2 Core
RAM >= 4 GiB

1.2 安装宝塔

参考网址：宝塔官方
在centos进系统前登录root账号，终端执行：

url=https://download.bt.cn/install/install_panel.sh;if [ -f /usr/bin/curl ];then curl -sSO $url;else wget -O install_panel.sh $url;fi;bash install_panel.sh ed8484bec

安装完成后会出现：

 【云服务器】请在安全组放行 25101 端口外网面板地址: 内网面板地址: username: password:

本机虚拟机登录内网地址，输入账号密码即可。
后续重启电脑后，启动宝塔命令：

systemctl start bt

查看宝塔访问地址命令：

bt default

1.3 安装docker及改镜像、安装dify

点击左侧Docker后，安装即可。

该镜像，参考链接：【教程贴】如何在宝塔面板更换Docker加速站

https://docker.1ms.run

完成后，访问虚拟机的8088端口；
第一次进入后，可能加载不了设置管理员账户，多刷新几遍即可。

至此环境以搭建完成。参考链接宝塔面板部署

1.4 配置模型供应商

硅基流动免费的deepseek-ai/DeepSeek-R1-Distill-Llama-8B：官网链接：siliconflow

本地部署ollama+deepseek

ollama+deepseek-r1:1.5b
链接：deepseek-r1
安装ollama，执行像对应的命令安装即可，同时也是执行命令；


或者也用宝塔：

二、dify快速上手体验

2.1 知识库

一开始不要上传过大的文档，我们本地部署的配置低！新建txt上传即可

直接确认即可

2.2 微案例：基于知识库的助手

构建知识库，我们可以先随便上传一个txt，然后添加内容：

创造工作流

选择工作流：

点击“+”选择流程：

最终构建流程如下：

运行，OK，不输出无关内容。

三、dify知识库配置详解

3.1 分片策略

在知识库中，“分片”是指将较长文本或文档拆分为多个小段，以便后续的向量检索和大模型处理。

分片的作用

• 提高检索精度：大模型或搜索引擎在处理较长文本时，容易出现语义模糊或无法精确定位的情况。通过将文档分片，可以让搜索引擎更精准地匹配用户查询，避免整篇文本过于冗长导致的匹配误差。
• 加速检索速度：分片后的文本更易于并行处理，索引和检索效率更高，减少大规模数据查询的延迟。

分片大小的设定

• 分片大小上限：指单个分片可包含的最大 Token 数量（如 500 或 1000）。Token 是自然语言被模型处理时的基本单位，1 个单词或符号可能对应 1～多个 Token。
• 分片重叠：在某些场景下，可以设置分片之间的重叠部分（Overlap）来保证语义上下文连续。例如分片大小为 500 Tokens，重叠 50 Tokens，这样当用户提问涉及跨分片的内容时，也能获取更完整的语义。

---

3.2 父子分段

父子分段是一种将文本分为“父块”和“子块”两级结构的方式，常用于 Q&A 场景。它的核心思路是：父块负责提供上下文背景，子块则是实际用于检索和匹配用户问题的最小单位。

1. 父块（Parent Block）

   • 通常对应较大的内容单元，如整段问答或长段落。
   • 在 Dify 中，父块可通过 \n\n（双换行）切分，并设置最大 Token 数（如 500 Tokens），保证一个父块能容纳较完整的语义。
   • 父块在检索流程中主要用于为大模型提供上下文，让模型理解这部分文本的整体含义。

2. 子块（Child Block）

   • 处于父块之下，通常是一段更小的文本，如一句话或几句话。
   • 在 Dify 中，子块可通过 \n（单换行）继续细分，并设置相对更小的最大 Token 数（如 200 Tokens）。
   • 子块是实际检索的目标单位：当用户提出问题后，系统会先锁定最相关的子块，然后再利用父块来提供更完整的语境。

为什么要用父子分段？

• 精准检索：子块足够小，便于系统快速找到与问题最匹配的内容。
• 语义保留：父块能让大模型在生成答案时参考更大范围的上下文，避免只看到小片段而丢失关键信息。
• 适合 Q&A 场景：当一个父块内包含多组问答或长答案时，细分成子块能让搜索结果更具针对性。

举个简单例子

• 父块：“关于大数据架构的常见问题及答案”，其中可能包含多条问答；
• 子块：针对每个问题或答案拆分成小段落，一旦用户提问与其中某条问答相似，系统就能快速检索到对应子块，并同时引入父块里的背景信息，帮助模型给出更准确、上下文丰富的回答。

通过这种**“父块提供上下文、子块用于检索”**的机制，企业能够在构建 FAQ 或技术知识库时，实现更高效的知识检索与问答体验。

---

3.3 索引方法

向量化索引（Embedding）

• 概念解析：Embedding 指的是将文本转换为可计算的向量表示，用以衡量文本之间的语义相似度。简单来说，Embedding 能将“文本”变成一串数字，让模型能够“识别”文本间的含义关联，而不仅仅是字面上的匹配。
• 模型选择：在上述截图中，我们使用 netease youdao/bce-embedding-base_v1 作为 Embedding 模型。它能将文本转换为维度较高的向量，用于后续的相似度计算。
• 使用场景：对海量文档做语义索引时，通过 Embedding 可以迅速检索到与用户问题最相关的文档片段。

ReRank（二次排序）

• 概念解析：ReRank 模型是对初步检索到的候选结果进行二次排序，以获得更高精度的匹配。它会对初始搜索结果再次打分，并把最符合语义需求的结果排在前面。
• 模型选择：在上述截图中，采用 netease youdao/bce-reranker-base_v1 作为 ReRank 模型。它会对已经检索到的前 N 条结果（通常称为 Top K）逐条进行重新打分排序。
• 好处：在第一步向量检索得到的结果基础上，ReRank 能过滤掉一些相似度高但不一定最精准的内容，从而提升最终答案的可靠性和可读性。

---

3.4 检索结果参数

Top K

• 含义：Top K 指从初步检索的结果集中选取得分最高的 K 条结果。比如设定为 10，则在向量检索阶段会返回与用户问题最相关的前 10 个分片，供后续 ReRank 或大模型生成答案。
• 影响：如果 K 值过大，可能引入无关噪音；如果 K 值过小，可能遗漏部分潜在的有用内容。因此需要结合实际文档规模和业务需求进行调试。

Score Threshold（得分阈值）

• 含义：当检索结果的相似度评分低于该阈值时，将被认为“不相关”或“可信度不足”，因此不予返回。
• 建议：阈值的设置需要通过多轮测试和观察。当阈值过高，系统可能忽略一些潜在的相关内容；当阈值过低，又会增加噪音，影响回答准确度。

---

3.5 配置要点与实践建议

1. 根据业务场景调整分片大小

   • 如果文档较长且上下文紧密，适当提高分片大小上限；若文档内容结构松散，减小分片大小以提高检索灵活度。

2. Embedding 与 ReRank 模型配合使用

   • 先通过向量检索获取初步候选，再使用 ReRank 进行精细化打分排序，以得到最优答案。

3. 关注 Top K 与阈值之间的平衡

   • 建议在测试环境下多次试验不同的 K 值和阈值组合，找到最佳的召回率与准确率平衡点。

4. 多语言与跨领域文本的适配

   • 如果需要处理多语言或专业领域文本，需选择合适的 Embedding 模型或微调现有模型，以保证语义理解的准确度。

5. 持续监控与迭代

   • 知识库不是一蹴而就的系统，需要定期更新文档内容、观察用户反馈，并在必要时对索引策略或模型参数进行微调。

---

四、工作室

4.1 Dify 的工作节点

在 Dify 中，工作节点是构建对话流程和业务逻辑的基本单元，每个节点都代表一类功能或操作，通过将多个节点组合在一起，可实现灵活多样的 AI 应用。下列是常见的工作节点及其主要用途：

• LLM：调用大语言模型（Large Language Model）生成文本回复或执行推理，是对话流程的核心计算节点。
• 知识检索：从预先构建的知识库中检索最相关的文本片段，为 LLM 提供上下文支撑，提升回答的准确度。
• 直接回复：将前面节点生成的结果直接输出给用户，常作为流程的终止节点。
• 问题分类器：根据预设规则或模型，将问题分类至不同领域或类型，以便后续的逻辑分支处理。
• 条件分支：类似于编程中的 if-else，依据特定条件（如检索结果是否为空）将流程导向不同路径。
• 迭代：针对列表或批量数据进行循环处理，适合在多条记录上重复执行相同操作。
• 代码执行：允许在流程中嵌入自定义脚本或代码段，满足更灵活的逻辑需求。
• 模板转换：将变量或数据以预定义模板的形式输出，便于格式化文本或生成特定格式的字符串。
• 文档提取器：从文档或文本块中解析出特定字段或信息，用于后续处理或检索。
• HTTP 请求：调用外部 API 或微服务，获取额外信息或完成某些后端操作。
• 列表操作：对数组或列表进行筛选、映射、排序等处理，方便在流程中对批量数据进行变换。

4.2 开始

在 Dify 的工作流程中，“开始”节点是整个对话或操作的入口，用于接收并管理系统默认传入的各类输入变量。通过这些变量，后续节点可以获取用户输入、对话信息以及当前流程的上下文，从而实现更灵活的逻辑编排。下表是“开始”节点常见的输入字段及其用途：

• sys.query (String)
  • 表示用户在对话或搜索框中输入的文本内容。后续节点（如知识检索、LLM 等）会根据此内容执行相应的操作或检索。
• sys.files (Array[File])
  • 当用户在对话或表单中上传了文件时，这里将存储文件数组，方便后续节点对文件进行解析或处理。
• sys.dialogue_count (Number)
  • 记录当前对话轮次或用户提问次数，常用于统计或多轮对话逻辑判断。
• sys.conversation_id (String)
  • 表示本次会话的唯一标识符，有助于区分不同用户或场景下的对话上下文。
• sys.app_id (String)
  • Dify 应用的唯一 ID，用于在多应用场景下区分各自的配置和工作流程。
• sys.workflow_id (String)
  • 当前工作流程（Workflow）的唯一标识符，用于管理和追踪不同的流程版本或逻辑分支。
• sys.workflow_run_id (String)
  • 每次执行工作流程时生成的运行 ID，可帮助记录日志或追溯操作历史。

此外，还可以继续添加：

4.3 知识检索

在构建智能问答或对话系统时，知识检索节点是将用户输入与已有知识库进行匹配的关键步骤。Dify 通过向量化搜索与 ReRank（重排序）技术相结合，实现对多条候选结果的筛选和精排，为大模型提供精准的上下文参考。以下为主要配置项的说明与应用建议：

1. 查询变量 (sys.query)

   • 用于接收用户输入的查询内容，通常是用户在对话或搜索框中输入的问题或关键词。
   • 知识检索节点会根据该变量，在内部向量索引中查找相似度最高的文本片段。

2. ReRank 设置

   • 权重模型 与 Rerank 模型 共同构成二次排序流程：
     1. 初步检索：先通过向量相似度获取与用户查询最相关的若干结果；
     2. 重排序：再利用 ReRank 模型对初步检索结果进行精细化打分，并重新排序。
   • 示例中使用 netease-youdao/bce-reranker-base_v1 作为重排序模型，可有效提升最终结果与查询的匹配度。

3. Top K

   • 表示在初步检索阶段，系统返回相似度最高的 K 条结果（如设定为 4），然后再将这几条结果传给 ReRank 模型进行排序。
   • 若 K 值过大，可能引入无关噪音；过小，则可能漏掉部分相关内容，需结合实际测试进行调优。

4. Score 阈值

   • 当检索结果的相似度评分低于此阈值时，视为与查询不匹配或可信度不足，不会返回给大模型。
   • 建议在部署前进行多轮实验，以找到能兼顾准确度与召回率的平衡点。

4.4 LLM

在 Dify 的工作流程中，LLM 节点承担着核心的文本生成与推理任务。通过在该节点选择适合的语言模型（如 Qwen/QwQ-32B-Preview），并配置相应的提示词（Prompt），可以为用户提供高度定制化的回答和交互体验。下面对截图中的关键配置项做简要说明：

1. 模型 (Model)

   • 这里选择的是 Qwen/QwQ-32B-Preview (CHAT 语言)，这类大模型具备强大的语言理解与生成能力，能够根据上下文生成连贯且具有专业深度的回答。
   • 若有其他需求，可切换至不同规模或不同厂商的大模型，以满足性能或行业专用场景的要求。

2. 上下文 (SYSTEM)

   • 在 SYSTEM 提示词中设置了“你的回答务必完全基于知识库的上下文，不能超出知识库范围。”，用于严格约束模型的输出。
   • 通过这种提示，模型会优先参考知识检索节点返回的结果，减少不必要的推测或“幻想”式回答。

3. 用户输入 (USER)

   • “开始”节点的 sys.query 作为用户实际提问的来源。LLM 节点将其与知识检索结果合并，形成最准确的答复。
   • 若需要在对话中添加更多信息（如上下文变量或额外指令），可将这些内容一并注入到 USER 提示中。

4. 记忆与思考

   • Dify 提供了“记忆”、“思考”等选项，用于保存或展示模型在推理过程中的中间信息。
   • “记忆”可帮助模型在多轮对话中保留上下文，“思考”则有助于调试与观察模型的中间推理思路，但往往不会直接显示给最终用户。

5. 温度 (Temperature)

   • 在截图中温度被设为 15，通常这意味着系统在不同量程中自定义了温度取值。数值越高，模型输出越具有创造性；数值越低，回答更保守且一致。
   • 建议在实际使用中根据业务场景进行调整：若更需要准确性和稳定性，可降低温度；若需要更多创意，可适度提高。

6. 输出变量

   • 该节点可将生成的文本、思考过程或其它中间结果存储在变量中，供后续节点使用或直接输出给用户。
   • 通过对输出变量进行进一步处理或与其他数据源结合，可实现更丰富的业务逻辑。

通过精心配置 LLM 2 节点，Dify 能在严格参考知识库内容的同时，发挥大语言模型的自然语言处理优势，为企业内部问答、客户服务或技术支持等场景提供高效且可控的智能化交互体验。

在使用 Qwen/QwQ-32B-Preview (CHAT) 模型时，Dify 提供了一系列可调参数，用于平衡生成内容的准确性、创造力与可控性。以下是主要参数的含义与调优建议：

1. 温度 (Temperature)

   • 作用：决定模型输出的随机程度。温度越高，模型的生成内容越具有创造性；温度越低，回答更趋于稳定与保守。
   • 典型范围：0.0～1.0（或更高），根据业务场景灵活调配。例如技术问答场景通常选用较低温度（0.2～0.5），以保证回答的准确性。

2. 最大标记 (Max Tokens)

   • 作用：限制模型在生成答案时使用的最大 Token 数。
   • 意义：防止模型生成过长或跑题的回答，也能避免浪费 Token 资源。一般可根据具体需求设定为几百到上千不等，截图中显示为 4096，属于较高上限，能容纳更多上下文。

3. Top P

   • 作用：即“核采样”参数，用于控制模型在生成时选取概率分布前 P% 的候选词。
   • 调优建议：若需要更具创造性，可适度提高 Top P（如 0.9），使模型有更多机会选用相对不常见的词；若需严格、精确回答，则可将其设为 1.0（等同于关闭核采样）。

4. 取样数量 (Number of Samples)

   • 作用：一次请求生成多少条不同的答案，用于对比或筛选。
   • 应用场景：在创意写作或头脑风暴场景下，可以设为 2～3 以获取多种思路；在严谨的技术问答中通常为 1。

5. 频率惩罚 (Frequency Penalty)

   • 作用：惩罚生成过程中重复出现过多的词句，降低重复用词的概率。
   • 调优建议：当回答容易出现口水话或频繁重复时，可适度提高频率惩罚（如 0.5），让模型输出更加多样化。

6. 回退格式 (Response Format)

   • 选项：text、markdown 或其他可用格式。
   • 意义：决定模型返回的文本排版或渲染方式；对前端显示和二次处理有影响。
   • 应用建议：若需要富文本格式或更好展示效果，可选 Markdown；纯文本场景则用 text。

7. 停止序列 (Stop Sequences)

   • 作用：当模型生成内容包含特定字符序列时，自动停止输出。
   • 应用场景：可用于防止输出敏感信息、分割多段回复或与系统指令区分。

4.5 其他

功能：

会话变量

环境变量：

后续进阶参照官方文档即可：
节点说明

五、推荐阅读

上述是可视化构建大模型，此外还可以写Python代码，
推荐博客：

LangChain:AI大模型开发与分布式系统设计
LangChain:AI大模型开发与分布式系统设计

理论文章：

读书笔记:要点提炼《基于大模型的RAG应用开发与优化——构建企业级LLM应用》(严灿平)
智能体系统（AI Agent System）是什么？——从概念解析到企业数字化转型的全景落地及投资视角

精选文章：

小胡说技书博客分类（部分目录）：服务治理、数据治理与安全治理对比表格

个人主页：
小胡说技书

六、dify架构图

封面图：

Dify 的 LLMs App Stack 架构将数据处理、检索增强、可视化编排、模型运维及安全合规等功能模块有机结合，为企业提供一站式的大语言模型应用解决方案。其核心理念在于：

1. 高效整合数据（ETL + Storage + RAG）；
2. 可视化与插件式开发（Orchestration Studio + Plugins Toolbox + DSL）；
3. 服务化与可运营（BaaS 平台 + LLMOps + Moderation + Cache）。

---

6.1 数据层

Dataset ETL

• 功能：ETL（Extract, Transform, Load）指的是从源头数据中进行提取、转换和加载的过程。
• 作用：将各种结构化或非结构化数据（如文档、知识库、日志等）转化为可被下游组件（尤其是 RAG Pipeline）处理的统一格式。
• 优势：在多源数据汇总的企业环境中，通过 ETL 能够清洗和预处理数据，减少噪音并提升检索准确度。

Storage

• 功能：存储经过 ETL 处理后的数据，并为后续检索提供高效的读写能力。
• 特点：可能包含对象存储、向量数据库或传统关系型数据库，用于满足不同类型数据的管理需求。
• 与 Dify RAG Pipeline 的关系：当用户提问时，RAG Pipeline 会在此处检索所需内容，以提供上下文给大模型。

---

6.2 检索与增强生成层

Dify RAG Pipeline

• RAG（Retrieval-Augmented Generation）：一种在调用大模型生成答案前，先检索相关文档并将其作为上下文提供给模型的技术。
• 流程：
  1. 接收查询：用户输入或上游模块传入问题；
  2. 向量检索：在存储中查找最相似的文档片段；
  3. 文档过滤/排序：对检索到的文档进行重排序（ReRank）或去重；
  4. 生成回答：将检索结果与用户问题一并传给大模型，得到更准确的回答。
• 好处：显著提升回答的准确性，减少“幻觉”现象（模型凭空捏造），同时保留对源文档的可追溯性。

---

6.3 开发与编排层

Dify Prompts IDE

• 定位：专门用于 Prompt 工程（Prompt Engineering）的集成开发环境。
• 功能：帮助开发者可视化地编写、调试和管理 Prompt，从而快速迭代对大模型的指令。
• 意义：Prompt 是大模型生成结果的核心控制手段，一个精心设计的 Prompt 能使模型更符合业务需求。

Orchestration Studio

• 作用：在整个系统中扮演“指挥中心”的角色，负责将用户请求、RAG Pipeline、LLMs、插件调用等多种流程有机串联。
• 可视化编排：开发者可在图形界面中拖拽节点、配置逻辑流，减少底层代码编写难度。
• 好处：让业务人员和技术人员都能快速上手，通过可视化流程图了解系统的工作原理与数据流向。

Plugins Toolbox

• 概念：插件（Plugin）是可选的扩展模块，用于连接外部系统或服务（如数据库、第三方 API、支付网关等）。
• 功能：让大模型在回答问题时具备调用外部资源或执行操作的能力，比如查询实时数据、发送邮件或进行数据分析。
• 优势：极大拓展大模型的应用边界，使其不仅能“回答问题”，还可执行实际的业务指令。

Dify Agent DSL

• DSL（Domain-Specific Language）：面向特定领域的语言，用于描述“智能体（Agent）”的行为逻辑。
• 用途：帮助开发者用更简洁的脚本或配置方式来定义 Agent 的执行步骤、调用的插件以及异常处理等。
• 价值：提高自动化与可维护性，让非深度开发人员也能通过 DSL 快速构建自定义 Agent。

---

6.4 服务化与运营层

Dify BaaS Platform (API/Agents)

• BaaS（Backend as a Service）：提供对外统一的 API 接口或 Agent 服务，屏蔽底层复杂度。
• 功能：
  1. API Gateway：对外暴露 RESTful 或 GraphQL 等形式的服务端点；
  2. Agents：封装业务逻辑，支持多轮对话、插件调用、RAG 检索等能力。
• 意义：让前端应用、第三方系统或移动端都能便捷地集成 AI 功能，无需关心底层流程。

LLMOps

• 概念：类似于 MLOps，指针对大语言模型的运维和管理实践，包括模型监控、版本管理、性能优化等。
• 作用：在模型上线后，通过持续监控模型的回答质量、响应速度和资源消耗，及时发现问题并迭代优化。
• 重要性：对于需要长期、稳定运行的大模型服务来说，完善的 LLMOps 能极大降低运维成本和风险。

Moderation System

• 功能：对用户输入与模型输出进行内容审核，过滤潜在的敏感信息或违规内容（如不良语言、隐私信息、法律风险等）。
• 价值：保障企业与用户的合规与安全，避免因不当言论或敏感数据泄露导致的法律与舆论风险。
• 技术点：可采用规则引擎或机器学习模型，对文本进行实时或准实时检测。

Cache System

• 定位：缓存层，用于存储最近或高频访问的查询与响应，以减少重复计算与网络消耗。
• 应用场景：
  1. 常见问题：对多次出现的相同或相似请求可直接从缓存返回结果；
  2. 性能优化：在高并发场景下显著降低对大模型的调用次数，提高整体吞吐量。

---

6.5 模型层

LLMs（Commercial、Open Source、Local）

• 多样性：Dify 可对接商业化 LLM（如通义千问、GPT 系列）、开源 LLM（如 BLOOM、LLaMA 变体）或本地部署的自研模型。
• 灵活性：企业可根据预算、数据合规要求、业务规模等因素自由选择模型类型或切换供应商。
• 衍生功能：通过插件、RAG Pipeline、Prompt 工程等手段，充分发挥大模型的通用能力，为业务创造更大价值。

---

6.6 交互流程

1. 用户请求 (Queries Requests)

   • 用户通过前端或 API 向 Dify BaaS 平台发起查询，可能包含自然语言问题或操作指令。

2. Orchestration & RAG

   • Dify 接收请求后，通过 Orchestration Studio 的编排逻辑调用 RAG Pipeline、Plugins Toolbox 等。
   • 若需要外部数据或执行业务操作，则通过 Agent DSL 协同插件完成。

3. 模型生成 & Moderation

   • 在获取必要上下文后，LLM 生成初步回答。Moderation System 对输出进行过滤或修正，保证内容合规。

4. Cache & 返回响应 (Outputs Responses)

   • 若命中缓存，直接返回缓存结果；否则更新缓存并将最终结果返给用户。
   • 整个过程会记录在 LLMOps 系统中，便于后续分析和运维。