Dify

在上一篇文章中，我们讲到了 Dify 的工具系统，其中有一个代码执行的内置工具非常重要，无论是在工作流的代码节点中执行用户代码，还是在智能体中作为 Code Interpreter 调用，都离不开这个

在这一个月的时间里，我们通过源码深入学习了 Dify 的整个会话流程，了解了从应用生成器到运行器的核心机制，从限流控制、文件处理、跟踪调试，到提示词组装、内容审核、外部数据扩展，再到最后的知识库检索和

在前面的几篇文章中，我们学习了 Dify 应用运行器中的外部数据扩展和知识库检索相关的内容，至此，万事俱备，只欠东风，我们已经到达应用运行器的收尾阶段。接下来就是重新组装提示词，调用大模型，完成对用户

在上一篇文章中，我们从界面操作的角度了解了 Dify 知识库的功能特性，包括创建知识库、配置分段设置、选择索引方式和检索方法，以及如何在应用中集成知识库。通过这些配置，我们可以让 AI 应用获得外部知

在构建 AI 应用时，如何让大模型能够准确回答特定领域的问题，一直是开发者面临的挑战。虽然大模型具有丰富的通用知识，但在处理企业内部文档、产品规范或专业领域的问题时，往往存在信息过时、不够准确或无法涵

在创建 Dify 应用时，我们可以在提示词中嵌入用户自定义变量，提高应用的灵活性和功能性。比如在之前的文本生成应用中，我们使用 {{lang}} 和 {{query}} 两个变量，实现了一个简单的中英

在上一篇文章中，我们学习了 Dify 应用运行器的提示词组装机制，了解了从用户输入到模型调用的完整转换流程。今天我们将继续深入 CompletionAppRunner 的 run() 方法源码，详细讲

应用运行器（App Runner） 是 Dify 应用的核心执行器，负责处理具体的生成逻辑，今天，我们将继续深入应用运行器的内部实现。 应用运行器的概览 让我们以文本生成应用为例，深入 Complet

在前面的文章中，我们深入分析了 Dify 应用生成器的源码实现，从限流策略、流式响应、配置管理、文件上传处理，到追踪调试机制，逐步了解了 Dify 会话处理的完整流程。今天我们将继续深入 Comple

在前面的几篇文章中，我们深入分析了 Dify 应用生成器的源码，包括限流策略、流式响应、配置管理以及上传文件的处理，今天我们将继续深入 CompletionAppGenerator 的 generat

我们之前曾学习过，当模型具备处理图片、文档、音视频的能力时（比如 Gemini 2.5 Pro），在应用的配置页面会多出三个配置开关： 在 “视觉” 右侧有一个设置按钮，还可以进行更细致的配置： 开启

在节前的文章中，我们深入分析了 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 提供了丰富的应用类