日习一技

在节前的文章中，我们深入分析了 Dify 会话处理流程的流式处理机制，学习了限流生成器、事件流转换和响应格式化的实现原理。通过分析 rate_limit.generate()、convert_to_e

在昨天的文章中，我们学习了 Dify 会话处理流程的核心服务 AppGenerateService，并通过分析它的 generate() 方法了解了 Dify 如何通过系统级和应用级两层限流策略来保障

在前面的文章中，我们梳理了 Dify 应用的各种会话接口，了解了不同蓝图下五种应用类型的接口实现，以及各自的认证方式和用户类型。如果我们仔细阅读源码就会发现，所有应用的会话接口背后处理逻辑几乎一样：

在前面的文章中，我们学习了 Dify 的代码结构和路由系统，了解了 Dify 是如何通过 Flask Blueprint 和 Flask-RESTX 来组织其复杂的 API 架构的。今天，我们将深入探

我们昨天学习了 Dify 的代码架构和三种启动模式，不过在应用启动过程中，我们并没有看到路由注册的相关代码，这里的关键就在于它模块化的扩展系统。Dify 通过 ext_blueprints 模块注册路

在前面的系列文章中，我们从实用的角度学习了 Dify 的部署方式、应用创建和各种应用类型的使用方法。今天，我们将深入 Dify 的源码，从技术架构的角度来理解这个 LLM 应用开发平台是如何构建的。

在前面的文章中，我们学习了 Dify 的聊天助手、文本生成和 Agent 应用，这些应用虽然功能强大，但在处理一些复杂业务逻辑时仍有局限性。今天，我们将学习 Dify 的 工作流（Workflow）

在前两篇文章中，我们介绍了 Dify 的基本概念和部署方式，并通过创建一个简单的翻译助手初步体验了聊天助手的构建流程。今天，我们将继续学习 Dify 的另外两种应用类型：文本生成应用 和 Agent

上一篇文章中，我们介绍了 Dify 这个开源 LLM 应用开发平台，并演示了两种主要的部署方式。今天，我们将进入实操阶段，学习如何使用 Dify 来构建我们的 AI 应用，Dify 提供了丰富的应用类