Dify 核心功能

三、核心功能

应用类型

选型口径：能用「一段提示词加一个知识库」解决的，就用聊天助手，别上工作流；任务有固定步骤、要分支或要调用外部系统，用 Workflow；既要多轮对话又要固定步骤（例如先问清需求、再查库、再回答），用 Chatflow；需要模型自己决定用哪个工具、调用几轮，才用 Agent。工作流比 Agent 更可控、更便宜、更容易排错，凡是步骤能提前写死，就不要交给模型自由发挥。

工作流节点清单

节点名称与可用范围会随版本调整，动手前请对照当前版本的官方文档确认。

知识库：分段、索引、召回与重排

知识库质量决定 RAG 应用的上限。需要分三个环节分别调优：分段决定检索粒度，索引方式决定检索手段，召回与重排决定最终喂给模型的内容。

• 分段：可以指定分段标识符、分段最大长度与重叠长度。中文文档建议按标题或自然段切分，长度结合模型上下文与内容粒度调整；设置重叠是为了避免一句话被切断导致语义丢失。结构化内容（FAQ、条款、制度）尽量做到一段一个完整语义单元，问答型内容按问答对切分效果最好。
• 索引方式：经济模式使用关键词倒排索引，不调用嵌入模型，成本低，但不擅长处理同义改写与口语化提问；高质量模式调用嵌入模型建立向量索引，语义召回更好，但需要配置嵌入模型并承担调用成本。文档量大、术语多、用户问法多变时选高质量。
• 召回：支持向量检索、全文检索与混合检索。混合检索可以调权重，常见做法是向量为主、关键词为辅，让专有名词、编号、型号类查询也能命中。Top K 决定召回条数，分数阈值用于过滤低相关内容；阈值设得太高会出现「召回为空」，设得太低会把噪声喂给模型。
• 重排：开启重排模型对召回结果做二次精排，通常能明显改善「相关内容排在后面被 Top K 截断」的问题，代价是增加一次模型调用与相应耗时。重排模型需要单独配置。

变量与提示词编排

变量是节点之间传递数据的唯一通道。常见四类：系统变量（对话标识、用户标识、当前时间等）、环境变量（工作区级常量，适合放不宜写死在提示词里的配置，比如品牌名、服务时段）、会话变量（Chatflow 与聊天助手中跨轮保持的状态，适合记录「用户已提供的信息」）、节点输出变量（上游节点的结果，用双花括号引用节点名与字段）。提示词里通过双花括号插入变量，例如引用用户输入与检索结果。建议把提示词拆成「角色设定、任务说明、上下文、输出格式约束」四段，上下文段固定引用知识检索节点的输出，格式约束写到可被程序解析的程度——后面要接结构化输出或代码节点时，这一点尤其关键。

插件与工具

Dify 的插件体系把模型、工具、Agent 策略、扩展等能力都做成可安装单元，应用市场里可以直接安装官方与第三方插件。工具插件让模型能够搜索网页、查询数据库、调用自建接口；自建工具可以把公司内部 API 按接口描述导入，成为工作流里可调用的节点。实践建议：生产应用装插件要克制，每个工具都会进入模型的可选动作空间，工具越多，模型选错的概率越高，在提示词里明确「什么情况用哪个工具」比装一堆工具更有效。

API 与 WebApp

每个应用发布后自动获得三种交付形态：WebApp（应用自带的网页，可直接分享，也可嵌入自有站点）、服务端 API（用应用专属 API Key 鉴权）、以及可选的嵌入式组件。API 与 WebApp 共用同一套提示词、知识库与工作流配置，改配置即时生效，不需要重新部署前端。

日志、标注与可观测

「日志与标注」记录每次对话的输入输出、耗时、token 消耗与用户反馈，可以把好答案直接存为标注，并在应用里开启标注回复：命中相似问题时直接返回人工确认过的答案，既快又稳。标注回复适合高频重复问题，不适合需要结合实时数据的问答。可观测方面，Dify 支持把运行轨迹导出到第三方追踪平台（例如 LangSmith、Langfuse、Opik，具体支持列表以官方文档为准），便于做链路级排错与成本归因。工作流每次运行都能在运行历史里看到逐节点的输入与输出，这是排查「为什么答错」最直接的手段：先确认召回对不对，再看提示词，最后才怀疑模型。