以Dify架构设计为例，一篇文看懂AI原生应用开发平台

腾讯云开发者

发布于 2025-10-31 11:35:57

2470

本文基于LLM AI原生应用开发平台Tasking AI和Dify的架构设计，浅析两者在LLM接入与集成、工具插件扩展与管理、典型AI Assistant应用核心流程、复杂AI任务编排执行引擎方面的核心设计理念与基本原理，初步探讨了LLM AI原生应用开发平台在系统架构设计理念、AI应用开发模式方面的未来发展趋势。

关注腾讯云开发者，一手技术干货提前解锁👇

10/30晚7:30鹅厂面对面直播继续！

随着大语言模型LLM技术的高速演进，围绕其构建的AI原生应用开发平台也快速涌现，这类平台的核心价值在于，降低AI应用开发门槛，强化从AI应用场景定义、AI应用系统系统设计、开发、发布上线的全流程支撑能力，加速业务专家快速构建生产级的生成式AI应用。在基于LLM的开放能力接入层面，集成数百种LLM模型，对上层业务提供统一的API进行commpletion、rerank、text embedding；在工具插件开发和平台集成层面，提供简单、灵活的插件化开发框架，进一步扩展LLM应用场景和能力边界，帮助开发者以标准化组件的形式进行AI原生应用的开发和实践。

在AI原生应用开发层面，对于LLM模型、工具插件、RAG提供统一的API进行注册、管理和维护，同时，提供了消息历史和多论会话的状态支持，方便构建有状态和无状态的assistant和commpletion AI原生应用。对于复杂流程编排的AI应用场景，则可以基于可视化Workflow的模式构建复杂对话流程和自动化任务。本文将聚焦于TaskingAI和Dify的系统设计理念、原理及关键流程，分析对比两款AI原生应用开发平台在LLM开放能力接入与集成、工具插件开发与扩展、AI 任务编排执行引擎、AI 原生应用开发Assistant 4个基础能力，浅析其系统背后的核心设计理念和基本原理，探讨基于LLM AI原生应用开发平台在系统架构设计理念、AI应用开发模式方面的未来发展趋势。

01

平台定位

虽然基于LLM的AI应用技术在各行业已经广泛落地，但是真正成熟且有价值的AI应用还是凤毛麟角，常见的LLM应用形态主要集中在AI助手和知识库。从LLM AI应用开发平台的角度来看，基本上可以分为两类，一是面向产品专家和业务开发人员，通用LLM应用开发平台和知识库专用平台，比如Dify/Coze/Tasking AI；二是面向AI业务开发人员的LLM 应用开发框架，比如LangChain/OpenAI Assistant API。

与业内通用LLM应用开发平台定位一致，TaskingAI/Dify 面向产品专家和业务开发人员，其主要定位于提供一站式的LLM AI原生应用开发与部署平台，提供便捷、友好的交互式开发体验；而LLM应用开发框架LangChain/OpenAI Assistant API，对于AI应用开发人员来说，则面临了一些不得不解决的问题和限制：

LLM应用开发框架LangChain，对于有状态的会话数据管理和维护、问答/知识语料的向量化，开发人员必须集成外部数据管理服务或者向量存储引擎，增加了AI应用落地的开发成本和维护成本。
OpenAI Assistant API 对于AI应用开发者来说，限制了AI模型的技术选型；工具集与检索能力与智能助手应用深度绑定，无法适应多租户的AI应用场景；同时，也限制了用户AI应用对于内存、检索系统相关参数了配置，无法进行深度定制。

为了进一步降低基于LLM AI原生应用的开发门槛、LLM接入和维护的成本、LLM能力边界的扩展，行业内涌现了诸如Dify、TaskingAI等众多优秀的基于LLM的AI原生应用开发与部署平台。

02

核心能力

横向对比来看，当前基于LLM的AI原生应用开发与部署平台，其各平台系统核心能力大同小异，具体如下：

2.1 有状态和无状态的AI应用能力支持

比如，TaskingAI 基于本地内存窗口、redis和postgres的三级存储架构，提供了有状态的会话数据管理及向量存储能力，AI应用开发人员无需关注历史会话数据的状态管理、向量存储的实现与维护，进一步降低了AI应用开发的门槛；Dify则提供了向量数据库的统一接入框架，支持多种向量数据库的动态卸载与集成。

2.2 工具、模型、RAG 模块化管理能力

TaskingAI /Dify 突破了OpenAI AssistengAPI 对于工具、LLM模型、RAG系统的技术选型限制，动态加载和卸载相关模块，自由组合，构建AI原生应用。对于工具、RAG、LLM的开放能力，Tasking AI / Dify 提供了统一的外部API，降低了AI原生应用开发的复杂度。

2.3 AI原生应用的多租户隔离机制

AI APP 多租户隔离机制保证了不同租户（工作空间/项目）私有数据、模型实例、模型资源的互相隔离，管控了租户之间的未知风险系数，确保平台整体能力的可用性。比如，Dify 的AI APP在数据模型层面，通过共享表tanent_id字段标识，进行了租户隔离，在AI App的创建、开发、调试、发布、运行、部署的生命周期中，可以为不同的租户加载不同配置的模型实例和资源以及租户私有知识数据，对于小型企业级用户，通过共享数据表的租户设计成本低且灵活性强。

2.4 复杂AI业务编排工作流能力支持

相对于Tasking AI来说，可视化AI APP任务编排和开发能力的支持，则是Dify Workflow开发模式特有的能力。AI App开发人员可以通过更加清晰、直观且易于验证的方式，在Dify用户操作界面，基于DAG不同的类型节点（比如，LLM节点、分支判断节点、Tool节点、HTTP节点、Code节点等）来快速进行AI任务编排与开发。

03

系统架构

对于基于LLM的AI原生应用开发平台来说，其整个系统架构设计的核心围绕着三个方面：

LLM 能力的接入与集成
工具插件能力的接入与集成
AI 应用流程编排与管理

针对这部分内容，本文主要基于TaskingAI 系统架构的核心组件，来重点关注系统中的backend app、infenrence app、plugin app组件。需要注意的是，虽然，TaskingAI 相对于Dify在AI任务流程编排、数据处理能力方面有所欠缺，但是，对于开发和验证一个轻量、简洁的AI原生应用来说，已经完全足够了。而且，Tasking AI代码架构设计分层合理、代码结构逻辑清晰、代码的可读性和可维护性，本文认为是要好于Dify的，具体介绍如下：

Tasking AI系统设计采用微服务的架构设计思路，按照业务领域划分为AI应用开发backend app 服务、模型推断infrenrence app服务、工具插件plugin app服务。

3.1 AI应用开发 backend app

backend app 作为用户应用开发的入口，主要负责AI应用assistant、model、knowledge、plugin相关的开发配置和管理；同时 backend app为AI应用的发布提供了版本控制、日志追踪和分析，方便后续AI应用的部署和运维。

backend app 服务在local cache会维护plugin、model 的配置信息，并且定时刷新，用于加速AI原生应用开发的服务响应。
backend app 服务的AI原生应用开发中，assistant plugin配置、knowlege 的检索结果，最终都会基于system prompt 模版，构建LLM chat model的输入，由LLM 进行内部推断，扩展能力边界。

backend app 代码架构设计层面，其按照DDD领域驱动的架构设计思路，围绕智能助手、模型推断、模型管理、知识检索、插件工具、文件作为核心的领域对象，将整个代码架构分层设计为基础设施infra层、领域服务domain层、业务编排及服务接口interface层。

infra层，封装了postgre/redis/boto3 各领域对象存储CRUD相关的原子操作。
domain层，基于infra层的数据操作、下游infenrence app/plugin app的核心能力，封装了assistant、ineranece、model、retrieval、tool、ui 相关的领域对象的核心服务能力。
interface层，基于domain层的业务编排，主要负责针对前端AI应用开发提供UI交互，参数校验、request/response 转换以及业务逻辑编排，在这里对应到MVC则是我们熟知的Controller，主要负责接收request，响应response。

注意：这里与我们之前实践的DDD 4层代码设计（infra/domain/app/interface）不同；Tasking AI的interface层，承载了太多的功能，增加interface这一层的代码复杂度和后续维护成本。通常情况下，我们会将业务编排抽象到app层，来将代码架构中经常“变化”与“不变”的部分隔离开；interface层更加聚焦在承载统一鉴权、限流、异常处理、操作审计，这种不经常变化或者简单变化的能力。

3.2 模型推断 infenrence app

infenrence app服务，在LLM AI原生应用开发平台中，构建了模型推断服务的抽象层，通过BaseChatCompletion、BaseRerankModel、BaseTextEmbeddingModel 为不同模型提供了可动态加载的模型适配器，支持了 completion、embedding、rerank 多种模型的接入能力，给了开发者更多模型技术选型的空间。

整个服务代码架构的设计思路与backend app保持一致，核心就是在于对completion、embeding、rerank 模型基础能力的抽象与封装、基于模型配置文件和schemas的插件化动态加载机制。

BaseChatCompletion，负责提供模型chat completion的基础能力。不同的大模型服务提供方，通过实现prepare_request/prepare_response函数适配模型的输入/输出，通过extract模型核心数据输出、文件内容、函数调用以及通用会话辅助信息封装成统一的ChatCompletion对象，为上游backend app 提供服务。
BaseTextEmbeddingModel，负责提供模型embedding的基础能力。embedding类型的模型服务提供方，通过实现embed_text/handle_response函数来实现文本数据的向量化能力，最终将不同模型的输出封装成统一的TextEmbeddingResult输出，为上游backend app RAG应用场景提供支撑。
BaseRerankModel，负责提供模型rerank的基础能力。模型提供方，通过实现rerank/handle_response函数实现结果文本list的重排。

在整个infenrence app启动过程中，会扫描不同模型提供方 resources 资源文件和模型的基础配置文件，动态加载不同模型对于completion、emedding、rerank三种场景的Base类实现，维护在本地cache中，在infenrence app的路由层，根据AI原生应用的模型配置的唯一id，在适配层来请求不同的模型服务能力。

3.3 工具插件 plugin app

plugin app服务，作为backend app下游服务，为系统/用户自定义插件的配置和注册，引入了统一的防腐层设计，隔离了AI应用开发与插件管理能力。backend app 根据 inenrence app 模型推断结果，决定是否需要通过function call的方式请求plugin app维护的插件执行，并获取插件执行结果，增强模型对于在chat app 或者completion app 场景中结果输出和边界扩展。

plugin app服务的插件加载机制与infenrence app的Base类动态加载机制类似，其核心是需要由第三方的插件提供方实现 PluginHandler类的execute方法，来触发插件的执行，系统内部维护的builtin插件、用户自定义的插件使用统一的输入/输出。

这里核心需要关注的就是，plugin app在插件动态加载过程中，会基于插件输入/输出的schema配置文件，统一映射输入/输出的参数type、name、description、required，并将plugin的输入参数转换为LLM function call 的 paramters schema。

3.4 backend app开始，backend app结束的AI Assistant

到这里，初步了解了AI应用开发平台的核心组件与设计思路。但是，基于LLM AI原生应用开发平台所构建的AI Assistant，在LLM、Plugin、RAG之间，如何进行核心流程的编排？LLM 如何使用系统/用户自定义的Plugin进行能力边界的扩展?

具体，我们围绕backend app、infenrence app、plugin app 三个核心的微服务，来一起梳理下其核心流程：

如下图所示，backend app 服务基于当前AI原生应用开发的两种形态（assistant/chat），构建了有状态和无状态两种seesion模式，编排了assistant session生命周期内，query text查询向量、knowlege相似度检索、检索结果rerank、模型推断、插件执行、assistant message 持久化等一系列复杂流程。

生成式的assistant会话，backend app 会根据assistant id 和 chat id 从本地cache中获取assistant plugin、model、retrieval 的基本配置和chat history message
基于第一步中的assistant、chat基本信息构建了初始化了有状态的会话session，并基于redis开启分布式锁
初始化的session对象，接下来会生成会话的message数据（这里，backend app 会基于inenrence app和 plugin app 定时拉去pulgin/model的schema 配置信息）
1. backend app 会基于infenrence app提供的embeding model能力，针对用户输入的query text进行向量化处理；
2. backend app 基于assistant配置的已经向量化的knowlege通过向量数据库进行检索增强；
3. backend app 根据向量数据库返回的result 进行rerank进行结果召回，根据用户配置的propmt模版、plugin工具，进行 system prompt message信息的构建，提交给infenrence app chat model进行内部推断。
backend app 根据模型推断结果，通过采取function call的方式请求plugin app进行插件的执行。
获取插件执行结果，组装chat message 响应信息、存储message 响应结果，返回给assistant client。

OK，截止到这里，对于初步设计和实现一个轻量、简洁、基于LLM、具备LLM广泛接入、工具插件能力扩展、AI应用通用流程编排的AI应用开发平台基本已经足够。对于大部分的AI应用开发平台，在LLM AI应用开发方面的核心能力基本如上所述。接下来，我们可以重点关注下，相对于Tasking AI 能力欠缺的部分，这里我们会以号称 LLM AI应用开发领域的"瑞士军刀" Dify为基础，重点分析其面向复杂AI任务编排的GraphEngine。

04

AI 任务编排执行引擎

对于AI任务编排执行引擎，这部分内容会基于Dify的整体架构设计，重点分析Dify GraphEgnine的框架设计和核心流程。

4.1 Dify 架构浅析

从Dify系统架构的分层设计来看，整体沿用MVC的设计理念，其承载核心业务能力的api服务，以core、controllers、models、services四个模块分别构建了AI 应用开发的核心业务逻辑层、接口控制器层、数据模型层和业务服务层。

在系统核心能力上，对于LLM模型、工具插件、RAG提供了统一的API进行注册、管理和维护。不同的是，Dify 设计与实现了面向AI应用复杂对话Advanced Chat、AI批处理自动化任务Workflow的工作流引擎，支持复杂AI应用场景的业务编排。除此之外，与Tasking AI的设计不同，Dify 基于Celery 将各种IO密集型的任务进行了异步化处理，进一步提升了其系统的响应时间与扩展性。不可否认，在复杂AI应用场景业务编排、系统吞吐能力的扩展性设计方面，Dify在系统的设计理念上更具备前瞻性。

但是，从Dify和Tasking AI代码架构设计上来看，个人认为Tasking AI代码架构设计的可维护性和可读性方面，是要好于Dify的。在Dify的代码中，虽然整体采用MVC的代码架构设计，但是依然可以看到代码层次之间的"穿透性"问题，如果models层的数据模型发生变化直接影响到了controllers，代码上下文之间直接耦合，模块之间"Anti-Corruption Layer" 防腐层的设计上不是很完善。

Dify与Tasking AI 对于APP、RAG的维护和管理、工具插件扩展与集成、LLM接入与管理的核心设计理念上大同小异。比如，对于LLM 的接入与集成，其通过模型适配器LargeLanguageModel 定义了LLM的统一接口，不同的模型提供商可以通过继承LargeLanguageModel 实现模型invoke function内部的参数预处理、消息格式转换、请求参数构建、LLM API调用和模型响应解析，为AI APP、Chat、Workflow 应用的开发与编排提供统一的接口支持。所以，这里我们重点来分析下Dify面向Advanced chat和AI批处理任务编排引擎的核心设计。

4.2 GraphEngine 框架

Dify工作流编排最核心的就是执行引擎层的GraphEngine，通过将AI APP编排流程解析成可执行的DAG，随后从根source节点开始，通过拓扑排序的方式，按层调度与执行不同的工作流节点；Graph Engine 整体设计思路采用 Event-Driven 事件驱动的方式进行DAG不同节点的调度、执行、状态维护和管理。

在执行节点的注册与维护方面，Dify通过NODE_TYPE_CLASSES_MAPPING 维护了DAG运行时所有节点的类型，包括Start/End Node、LLM Node、IFElse Node、 Knowledge Retrieval Node、Question Classifier Node、Tool Node、Http Node、Loop Node、Variable Assigner Node等等，基本覆盖了AI应用开发业务编排所需要的全部语义表达；
在DAG核心执行就流程方面，通过Event Generator 在DAG的调度与执行中，有序抛出调度事件，比如GraphRunStartedEvent、NodeRunStartedEvent，最终交给App runner负责发布相关事件到local queue， Workflow APP Generator负责监听DAG调度执行事件，进行节点、工作流状态和执行记录持久化。这里本文认为有个可以优化的点，在Dify GraphEngine 事件驱动架构的默认实现中，采用了本地消息队列的构建了调度与状态事件生产者和消费者模式。

从面向故障系统设计的角度出发，这里无疑增加了GraphEngine 对于Workflow AI应用开发故障恢复的成本与系统的扩展能力。本文更加推荐的做法应该是进行无状态的设计与改造，通过引入第三方消息队列（比如，redis、pulsar）来降低Workflow AI App故障恢复的系统复杂度、提升系统的扩展能力。

如下图所示，Dify在其Agent chat app、chat app、completion app、advaned chat app、workflow app 5中类型的AI应用形态上，统一抽象为MessageBasedAppGenerator和WorkflowAppGenerator，分别基于消息模式和基于工作流模式的AI应用开发，其中advaned chat app和workflow app基于WorkflowAppGenerator构建对应的app，其他app构建主要基于MessageBasedAppGenerator。

在复杂AI任务编排构建Workflow到执行Workflow 批处理任务，GraphEngine构建与节点执行的核心流程中：

Web/API层请求运行Workflow的时候，Dify会通过AppGenerateService来根据用户开发配置的app类型（agent chat、chat、completion、advanced chat、workflow）来通过BaseAppGenerator（这里我们以WorkflowAppGeneator为例）来初始化事件驱动队列管理器QueueManager、工作流及节点运行时DB操作对象、变量加载器VariableLoader。
WorkflowAppGeneator生成WorkflowAppRunner运行时对象，WorkflowAppRunner基于用户设置的app输入参数、系统变量及环境变量、Workflow App节点编排关系初始化构建可运行的DAG Graph。
由WorkflowEntry统一封装构建可运行的GraphEngine，开启DAG的节点执行。这里WorkflowAppRunner会基于GraphEngine返回的事件生成器，监听GraphEngine 节点的执行与状态变更，统一将事件发布到内部本地队列，由WorkflowAppGeneator监听相关事件，并对事件作出节点/工作流执行状态持久化、调度重试等相关操作。

4.3 GraphEngine 核心流程

具体GraphEngine对于节点调度执行的核心流程如下图所示：

可以看到，GraphEngine开始进行节点调度之前首先会生成GraphRunStartedEnvent事件（注意：最开始的source root node在构建可执行的Graph的时候就已经确定好了）。

然后，GraphEngine检查当前可执行的最大可运行steps（这里实际是在计算整个Graph node的执行次数，包含节点重试）和Graph的执行超时时间，防止因为未知异常导致GraphEngine无法退出或者节点资源无法释放。

检查完GraphEngine当前可执行的基本条件之后，会通过NODE_TYPE_CLASSES_MAPPING 和用户配置的Node基本信息来初始化当前准备执行的节点实例对象，并进行执行。如果在这个过程中触发异常，GraphEngine会生成GraphRunFailedEvent事件，交给WorkflowAppRunner对事件进行发布；否则会检查节点是否为END结束节点，如果是结束节点，则退出循环，触发生成GraphRunSucceededEvent事件，如果不是END结束节点，则会基于DAG边的依赖关系，获取下游可执行的节点，继续在循环中执行节点。

整个GraphEngine的核心执行流程比较简单，但是这里需要注意的是，GraphEngine 对于条件分支判断以及节点重试执行、节点状态管理等方面错误处理、容错设计以及节点性能监控。毕竟一个工业级的GraphEngine 必须要有面向故障的设计理念，这部分内容就留给大家自己研究了。

05

总结

本文基于LLM AI原生应用开发平台Tasking AI和Dify的架构设计，重点分析了系统中LLM接入与集成、工具插件扩展与管理、典型AI Assitent应用核心流程、复杂AI流程编排执行引擎设计理念。其中，Tasking AI采用微服务的系统架构设计、DDD领域驱动的代码架构设计模式，系统代码层次结构清晰，适合于轻量级AI应用的开发和验证；同样，Dify采用微服务的系统架构设计，整体代码架构设计更加偏向于MVC模式，但是，在部分代码设计中存在上下层代码直接耦合的问题。不过，Dify创新型设计了面向复杂AI任务编排的GraphEngine，可以支持更加广泛的AI应用开发场景。综上，Tasking AI和Dify 两者都是比较优秀的LLM大模型应用开发平台，作为开发者，我们更加关注系统的整体设计理念和思路。