所有类型由一个枚举统一标识（api/models/model.py:364）：

# api/models/model.py:364
class AppMode(StrEnum):
    COMPLETION = "completion"        # 文本生成（一问一答，无记忆）
    WORKFLOW = "workflow"            # 工作流（跑流程图，非对话）
    CHAT = "chat"                    # 聊天助手（多轮对话，有记忆）
    ADVANCED_CHAT = "advanced-chat"  # Chatflow（对话 + 工作流 混合）
    AGENT_CHAT = "agent-chat"        # Agent 对话（能自己调工具循环）
    AGENT = "agent"                  # 新版 Agent 应用（基于 Dify Agent 运行时）
    CHANNEL = "channel"
    RAG_PIPELINE = "rag-pipeline"

    @classmethod
    def value_of(cls, value: str) -> "AppMode":
        for mode in cls:
            if mode.value == value:
                return mode
        raise ValueError(f"invalid mode value {value}")

ls api/core/app/apps/ 真实输出（节选），能看到五种类型是并列的子目录：

# api/core/app/apps/
chat/                 # 聊天助手
agent_chat/           # Agent 对话
completion/           # 文本生成
workflow/             # 工作流
advanced_chat/        # Chatflow（高级对话）
base_app_generator.py         # 所有 Generator 的基类
base_app_runner.py            # 所有 Runner 的基类
base_app_queue_manager.py     # 事件队列基类
message_based_app_generator.py  # 会话式应用的 Generator 基类

随便点开一个类型（如 chat/），会发现四件套结构（ls api/core/app/apps/chat/）：

# api/core/app/apps/chat/
app_generator.py            # Generator：组装请求 + 起线程 + 返回响应
app_runner.py               # Runner：在后台线程里真正调模型
app_config_manager.py       # ConfigManager：把应用配置解析成运行时配置
generate_response_converter.py  # ResponseConverter：把内部事件转成对外格式

五种类型共享同一套"两段式"骨架。看 ChatAppGenerator 的继承与 ChatAppRunner 的入口签名，就能理解分工：

# api/core/app/apps/chat/app_generator.py:36
class ChatAppGenerator(MessageBasedAppGenerator):
    def generate(self, session, app_model, user, args, invoke_from, streaming=True):
        # 组装请求、起后台线程、返回响应流（Day04 逐行看）
        ...

# api/core/app/apps/chat/app_runner.py:28
class ChatAppRunner(AppRunner):
    def run(self, session, application_generate_entity, queue_manager, conversation, message):
        # 后台线程里真正干活：组织提示词 → 审核 → 调模型 → 事件入队
        ...

五种类型看似并列，其实按"底层是不是跑图"分成两大家族。这从它们的 Generator 基类和目录差异能看出来：