Dify介绍：从应用、工作流到知识库的 AI 应用搭建平台

Dify 可以理解为一个 AI 应用搭建平台。它把模型、知识库、工作流、工具调用和发布入口放进同一套界面里。

如果只是在聊天窗口里试提示词，Dify 不是必需品。它真正有用的地方，是把一个“能反复运行的 AI 应用”搭出来。比如客服助手、文档问答、内容审核、报告生成、带工具调用的内部助理。

Dify 是什么

Dify 的核心不是某一个模型，而是一套把模型变成应用的工作台。

一个“产品 FAQ 助手”可以这样搭：

用户在网页里提问
-> Dify 应用接收问题
-> 检索产品文档
-> 调用 LLM 组织答案
-> 返回给用户

这个流程里，模型只负责生成。文档从 Knowledge 来，流程由 Workflow 或 Chatflow 编排，发布可以走 Web App 或 API。

flowchart LR
  U["用户"] --> A["Dify App"]
  A --> F["Workflow / Chatflow"]
  F --> K["Knowledge Retrieval"]
  K --> L["LLM Node"]
  F --> T["Tools / Agent"]
  L --> O["Web / API / MCP"]

App：应用是交付单元

在 Dify 里，App 是用户真正使用的东西。

不同 App 类型适合不同任务。

Text Generator

Text Generator 适合一次性生成任务。

例如输入：

主题：RAG 的工作流程
要求：写成 200 字摘要

输出就是一段摘要。它不需要多轮对话，也不需要复杂流程。

Chatflow

Chatflow 适合多轮对话。

例如客服机器人里，用户先问：

怎么开通企业版？

接着追问：

那价格是多少？

Chatflow 可以保留会话上下文，并在每轮对话里执行检索、判断和回答。

Workflow

Workflow 适合一次性流程任务。

例如用户输入公司名，系统依次完成：

抓取公司信息
提取关键字段
生成分析报告
输出 Markdown

这个过程不是聊天，而是一条明确的处理流水线。

Agent

Agent 适合需要模型自主决定下一步的任务。

例如用户说：

帮我查今天的汇率，然后写一封付款提醒邮件。

Agent 可以先调用汇率工具，再调用文本生成能力。它比普通 Workflow 更灵活，但也更需要权限控制。

Workflow 和 Chatflow 的区别

Workflow 和 Chatflow 都是编排流程，但使用场景不同。

Workflow 更像“提交任务，等待结果”。
Chatflow 更像“你一句我一句，持续对话”。

一个 Workflow 例子：

输入：公司名称
步骤：搜索资料 -> 总结业务 -> 生成竞品分析
输出：一份报告

一个 Chatflow 例子：

用户：你们产品支持私有化部署吗？
助手：支持，以下是部署方式……
用户：最低配置是什么？
助手：根据部署文档，最低配置是……

如果任务有持续上下文，用 Chatflow。
如果任务是明确输入和明确输出，用 Workflow。

节点：把复杂应用拆成步骤

Dify 的流程由节点组成。节点可以调用模型、检索知识库、执行代码、做条件分支、调用工具。

一个最小 RAG 问答流程是：

Start -> Knowledge Retrieval -> LLM -> Answer

用户问“怎么申请发票”，Knowledge Retrieval 节点先检索财务制度，LLM 节点把检索结果整理成答案，Answer 节点把答案返回给用户。

flowchart TD
  Q["用户问题"] --> R["Knowledge Retrieval"]
  R --> C["检索结果 result"]
  C --> L["LLM Node"]
  L --> S["Answer"]

节点的好处是调试清楚。答案错了，可以看是检索节点没找对，还是 LLM 节点没用好资料。

Knowledge：把自己的资料接入 AI

Knowledge 是 Dify 的知识库能力，用来支撑 RAG。

例如你上传：

产品手册
退换货政策
常见问题
内部操作规范

用户问“超过 7 天还能退货吗”，系统先检索退换货政策，再让模型基于检索结果回答。

Dify 的 Knowledge 不是简单文件夹。创建知识库时通常要配置分块、索引方法和检索设置。

例如一份“退换货政策.pdf”可以被切成多个 chunk：

chunk 1：7 天无理由退货
chunk 2：已拆封商品限制
chunk 3：质量问题售后流程

用户问“拆封耳机能不能退”，系统应该优先命中 chunk 2，而不是只命中 chunk 1。

Knowledge Retrieval 节点

Knowledge Retrieval 节点负责把用户问题拿去知识库检索。

一个典型配置是：

query：用户问题
knowledge：产品文档知识库
output：result

LLM 节点再把 result 当作上下文使用。

例如：

用户问题：怎么申请发票？
检索结果：财务制度中的发票申请流程
LLM 回答：根据流程，先进入订单页面……

这个节点很关键。没有它，模型就是凭记忆回答；有了它，模型才有机会基于资料回答。

Agent 与 Tools

Tools 是外部能力，Agent 是决定何时用工具的模型节点。

工具可以来自插件、自定义 OpenAPI、Workflow as Tool 或 MCP。

一个订单助手可以有两个工具：

查询订单状态
创建售后工单

用户问：

帮我查订单 123 的退款状态。

Agent 可以判断需要调用“查询订单状态”工具，而不是只根据知识库回答。

这里要注意权限。能查询订单的工具不应该默认能查所有用户订单。工具权限应该由后端和参数限制控制，而不是只靠模型自觉。

Variables：让流程中的数据能流动

变量是 Dify 工作流里非常重要的概念。

常见变量包括：

输入变量
系统变量
节点输出变量
环境变量

例如做一个客服欢迎语生成器，可以设置输入变量 company_name：

请为 {{company_name}} 生成一段客服欢迎语。

如果输入是“星河云”，输出就会围绕这个公司名生成。

环境变量适合保存 API Key 之类配置。这样导出 DSL 或共享流程时，不会把密钥直接写进节点里。

发布方式

Dify 应用可以通过多种方式交付。

Web App

内部团队可以直接使用 Web App。

例如 HR 助手做好后，把链接发给员工，员工在浏览器里提问。

API

正式产品通常通过后端调用 API。

例如 SaaS 产品里嵌入一个智能客服，前端请求自己的后端，后端再调用 Dify API。API Key 不应该暴露在浏览器前端。

网站嵌入

文档站可以嵌入聊天气泡。

例如用户在帮助中心右下角看到一个问答入口，提问后由 Dify 应用回答。

MCP

Dify 还可以把应用作为 MCP Server 暴露给支持 MCP 的工具。

例如在开发工具里调用某个知识库助手，让它回答项目文档问题。

适合哪些场景

Dify 适合这些任务：

知识库问答
客服机器人
内容生成流程
文档处理流程
内部业务助手
带工具调用的轻量 Agent

如果项目还在验证阶段，Dify 能快速搭出原型。等流程跑通后，再决定哪些部分需要自定义开发。

资料校验

Dify 的应用类型、Workflow、Chatflow、Knowledge、Knowledge Retrieval、LLM Node、Agent Node、Tools、变量和发布方式，均参考官方文档。关于发布 API 的安全提醒，来自官方 API 集成说明中“不应在前端暴露 API Key”的原则。