快速创建应用
你可以通过 3 种方式在 Dify 的工作室内创建应用：
- 基于模板创建
- 创建一个空白应用
- 通过 DSL 文件创建应用
在创建新应用时，你需要选择一种应用类型
以下是它们的核心区别对比总览：
| 对比维度 | 聊天助手 (Chatbot) | 文本生成应用 (Text Generator) | 智能体 (Agent) | 工作流 (Workflow) | 对话流 (Chatflow) |
|---|---|---|---|---|---|
| 核心定位 | 会聊天的问答助手 基于 LLM 的即时对话交互，快速解答问题 |
内容生产工厂 专注于根据单次指令生成高质量、结构化的文本内容 |
自主决策的 AI 员工 具备推理能力，能自主规划、拆解任务并调用工具 |
自动化流水线 通过可视化节点编排，自动化执行单次或批处理任务。 |
可编排的对话剧本 通过可视化节点设计复杂、有记忆的多轮对话流程 |
| 交互方式 | 一问一答，支持多轮但逻辑松散 典型对话模式，能记住上下文，但流程无强逻辑控制 |
单次请求 - 响应 输入主题或指令，一次性输出完整文本，无对话记忆 |
目标驱动，动态多轮 用户给出复杂目标，Agent 自主决定步骤，可能进行多轮询问和工具调用 |
无人工交互，单次执行 输入一次性完成，流程按节点线性执行，输出最终结果，无状态记忆 |
流程驱动，可预测的多轮交互 对话路径由预设节点流程控制，支持上下文记忆和状态管理 |
| 关键特性 | • 配置简单，上手快 • 支持知识库检索 • 具备基础对话记忆 |
• 专注于文本生成质量 • 支持变量定制输出 • 无工具调用，交互性弱 |
• 自主任务分解与推理 • 动态工具/API 调用 • 支持 ReAct 等推理框架 |
• 可视化节点编排（拖拽） • 必须包含“结束”节点 • 支持定时/事件触发、批处理 • 提供代码、条件分支、循环等逻辑节点 • 可发布为工具供调用 |
• 可视化节点编排（拖拽） • 内置对话历史与会话变量 • 支持流式输出和中间步骤输出 • 可集成知识库、工具等节点 |
| 典型场景 | 智能客服、日常问答、 简单信息查询、 对话式用户界面 |
内容创作（文章/报告/邮件）、 翻译、摘要生成、 批量文案生产 |
复杂任务自动化（旅行规划/调研）、 跨系统查询、 需要工具调用的智能助手 |
数据清洗与分析、 批量翻译、 报表自动生成、 电子邮件自动化、 内容批量生成与发布 |
复杂客服流程、 多步骤信息收集（面试/问诊）、 语义搜索、 强状态管理的对话机器人 |
| 配置复杂度 | 简单 | 简单 ~ 中等 | 中等 | 复杂 | 复杂+ |
各类型简要说明
- 聊天助手(Chatbot)：最基础的对话应用 像一个“知识渊博的客服”，能通过知识库回答问题并进行多轮聊天，但流程自由，不适合需要严格步骤控制的场景
- 文本生成应用(Text Generator)：专注于“写”的应用 像一个“专业的写手”，你给一个主题或大纲，它生成一篇完整的文章、报告或文案，但不进行多轮对话
- 智能体(Agent)：更高级的“聊天助手” 像一个“有头脑的助理”，不仅能对话，还能理解复杂指令，自己规划步骤、调用搜索引擎、数据库等工具来完成任务
- 工作流(Workflow)：用于自动化处理非对话任务的工具 像一个“自动化流水线设计器”，通过拖拽节点（如HTTP请求、代码执行、循环）将多个任务串联起来 一次性自动执行(支持单次/定时/事件触发自动执行)，适合批处理和集成外部系统
- 对话流(Chatflow)：用于构建复杂对话应用的工具
像一个“对话流程图设计器”，允许你通过拖拽节点（如问题分类、知识检索、条件判断）来精确设计多轮对话的每一步，并保持记忆
Chatflow可用于构建具备Agent能力的对话应用，两者可结合使用
- Agent 是一种应用类型(具备自主推理能力)
- Chatflow 是一种编排工具(用于设计对话流程)
- 两者不是”底层/上层”关系，而是可以组合使用(如在Chatflow中嵌入Agent节点)
核心关系与选型建议
- 对话流 vs. 工作流：这是Dify中两种可视化编排工具选择关键在于是否需要多轮对话和状态记忆
- 需要 -> 选 对话流
- 不需要（只需自动化执行）-> 选 工作流
- 聊天助手 vs. Agent：这是两种开箱即用的对话应用；选择关键在于是否需要AI自主调用工具
- 纯聊天、问答 -> 选 聊天助手
- 需要AI自动调用工具完成复杂任务 -> 选 Agent
- 文本生成应用：需求非常明确，当你的核心需求就是高质量、单次的文本内容生成时选择它
选择逻辑：
- 先判断核心任务：是生成文本、进行对话，还是自动化流程？
- 对于对话：是否需要AI自主调用工具？是->Agent；否->聊天助手
- 对于自动化流程：是否需要多轮交互和记忆？是->对话流；否->工作流
它们也可以组合使用
例如：在对话流中嵌入Agent节点来处理需要推理的子任务，或将工作流发布为工具供Agent调用
吞吐与可扩展性
Dify 本身是轻量级编排层，其吞吐瓶颈主要在于：
- 下游模型 API 的调用上限：Dify 支持为同一供应商配置多个密钥/端点，并设置 QPM（每分钟查询数）限制，可以在一定程度上分散负载
- 自身 Web 服务与数据库性能：对于超高并发（如 QPS > 1000），需要水平扩展 Dify 的
api服务实例，并使用外部 Redis 和 PostgreSQL
日志与追踪
启用 Dify 的详细日志，并集成到 ELK 或 Loki 中。关键操作（如工作流运行、模型调用）应包含唯一的 trace_id，便于跨服务追踪
