大家好，我是玄姐。

?隨著大語言模型（LLM）技術的爆發(fā)，AI 原生應用開發(fā)不再是 “模型調用 + 簡單邏輯” 的淺層組合，而是需要一套能覆蓋 “場景定義 - 系統設計 - 開發(fā)部署” 全流程的支撐平臺。目前行業(yè)中，Tasking AI 與 Dify 是極具代表性的兩款開發(fā)平臺，前者以簡潔架構適配輕量需求，后者則憑借強大的任務編排能力成為復雜場景的首選。

本文將聚焦兩款平臺的核心設計，尤其以 Dify 的架構為重點，拆解 AI 原生應用開發(fā)平臺的關鍵能力、系統架構與任務編排引擎，幫你理清這類平臺的設計邏輯與落地思路。

一、先搞懂：AI 原生應用開發(fā)平臺的定位

在聊架構前，首先要明確這類平臺的核心價值，降低 AI 應用開發(fā)門檻，解決 “模型選型難、工具集成散、流程編排繁” 三大痛點。目前行業(yè)中的平臺主要分為兩類，定位差異顯著：

為什么 Dify 這類通用平臺更受企業(yè)青睞？對比開發(fā)框架的局限性就能明白：

• LangChain：無內置數據管理與向量存儲，開發(fā)者需額外集成，增加維護成本；
• OpenAI Assistant API：綁定 OpenAI 模型，工具與檢索能力深度耦合，無法適配多租戶場景，且參數配置自由度低。

而 Dify、Tasking AI 這類平臺，通過 “統一模型接入、模塊化工具管理、可視化流程編排”，讓業(yè)務人員也能快速搭建 AI 應用，這正是其核心定位價值。

二、AI 原生應用開發(fā)平臺的 4 大核心能力

無論 Tasking AI 還是 Dify，要支撐 AI 應用全流程開發(fā)，必須具備四大核心能力，這也是平臺設計的基礎：

1. 有狀態(tài) / 無狀態(tài)應用雙支持

AI 應用常需區(qū)分 “單次問答”（無狀態(tài)）與 “多輪對話”（有狀態(tài)），平臺需提供靈活的會話與數據管理能力：

• Tasking AI采用 “本地內存 + Redis+PostgreSQL” 三級存儲，自動管理會話歷史與向量數據，開發(fā)者無需關注底層存儲；
• Dify設計向量數據庫統一接入框架，支持多種向量庫（如 Milvus、FAISS）的動態(tài)加載 / 卸載，適配不同數據規(guī)模需求。

2. 模型、工具、RAG 模塊化管理

突破開發(fā)框架的 “綁定限制”，實現模塊自由組合：

• 模型層：支持數百種 LLM 接入（如 GPT、Qwen、DeepSeek），提供統一 API 調用 completion、embedding、rerank 能力；
• 工具層：提供插件化開發(fā)框架，支持系統內置工具（如搜索、Excel 分析）與用戶自定義工具，標準化接入流程；
• RAG 層：統一管理知識庫，支持文檔上傳、自動向量化、檢索配置，無需單獨開發(fā)檢索邏輯。

3. 多租戶隔離機制

企業(yè)場景中，不同團隊 / 項目的數據、模型資源必須隔離，避免風險：Dify 的設計極具代表性，在數據模型層通過??tenant_id??字段標識租戶，從 “應用創(chuàng)建 - 開發(fā) - 部署” 全生命周期，為不同租戶加載獨立的模型實例、私有知識庫，且實現成本低、靈活性高，特別適合中小型企業(yè)。

4. 復雜任務編排能力（Dify 獨有優(yōu)勢）

這是 Dify 區(qū)別于 Tasking AI 的核心亮點：支持可視化 Workflow 編排，通過拖拽節(jié)點（LLM 節(jié)點、分支判斷、Tool 節(jié)點、Code 節(jié)點等），快速構建復雜流程。例如 “用戶提問→Question Classifier 判斷意圖→調用 RAG 檢索→LLM 生成回答→工具補充數據” 的多步驟流程，無需寫代碼即可完成。

三、系統架構拆解：從 Tasking AI 看基礎設計，從 Dify 看復雜擴展

兩款平臺的架構設計各有側重：Tasking AI 以 “簡潔分層” 適配輕量需求，Dify 以 “異步化 + 任務編排” 支撐復雜場景。我們先從 Tasking AI 的基礎架構入手，再深入 Dify 的進階設計。

1. Tasking AI：微服務架構，分層清晰

Tasking AI 采用微服務拆分，按業(yè)務領域分為三大核心服務，代碼可讀性與可維護性極佳：

圖片

（1）Backend App：應用開發(fā)入口

作為用戶交互與業(yè)務編排的核心，負責：

• 管理 AI 應用（Assistant）、模型、知識庫、插件的配置；
• 提供版本控制、日志追蹤能力，支撐應用部署運維；
• 本地緩存模型 / 插件配置，定時刷新，提升響應速度。

代碼架構遵循 DDD 領域驅動設計，分為三層：

• Infra 層封裝 PostgreSQL/Redis/Boto3 的 CRUD 操作，隔離數據訪問細節(jié)；
• Domain 層基于 Infra 層能力，封裝 Assistant、模型、檢索、工具的核心業(yè)務邏輯；
• Interface 層處理前端請求（參數校驗、Request/Response 轉換），對應 MVC 的 Controller 層。

注意：Tasking AI 的 Interface 層承載了部分業(yè)務編排邏輯，略增加復雜度。理想設計應將業(yè)務編排抽象到獨立的 App 層，讓 Interface 層僅負責請求處理。

（2）Inference App：模型推斷服務

構建模型接入的 “抽象層”，解決多模型適配問題：

• 定義三大基礎模型類：??BaseChatCompletion??（對話生成）、??BaseTextEmbeddingModel??（文本向量化）、??BaseRerankModel??（結果重排）；
• 不同模型提供商（如 OpenAI、阿里云）通過實現基礎類的??prepare_request??、??handle_response??等方法，適配輸入輸出格式；
• 啟動時自動掃描模型配置文件，動態(tài)加載適配器，路由層根據應用配置的模型 ID，調用對應模型服務。

（3）Plugin App：工具插件服務

作為 Backend App 的下游服務，提供工具執(zhí)行能力：

• 設計??PluginHandler??基礎類，第三方插件需實現??execute??方法觸發(fā)邏輯；
• 統一插件輸入 / 輸出 Schema，自動轉換為 LLM 可識別的 Function Call 參數格式；
• 隔離應用開發(fā)與插件管理，Backend App 根據模型推斷結果，決定是否調用插件。

2. Dify：異步化 + 任務編排，支撐復雜場景

Dify 在 Tasking AI 基礎架構上，增加了 “異步任務處理” 與 “GraphEngine 任務編排引擎”，更適合復雜 AI 應用（如批處理任務、多步驟對話流程）。

（1）整體架構：MVC 分層 + Celery 異步

• 核心模塊

• Controllers 層：處理 API 請求，負責參數校驗與響應封裝；
• Services 層：核心業(yè)務邏輯（如應用創(chuàng)建、模型調用、任務編排）；
• Models 層：數據模型定義（如應用配置、會話記錄、插件信息）；
• Core 層：底層能力封裝（模型適配器、插件框架、RAG 引擎）；

• 異步優(yōu)化通過 Celery 將 IO 密集型任務（如文檔向量化、批量推理）異步處理，提升系統響應速度與吞吐量。

（2）模型接入：統一適配器設計

與 Tasking AI 思路一致，但更強調通用性：

• 定義??LargeLanguageModel??基礎類，統一模型調用接口；
• 各模型提供商實現??invoke??方法，處理參數預處理（如 Prompt 格式化）、API 調用、響應解析，輸出統一格式結果；
• 支持模型動態(tài)切換，應用開發(fā)時可隨時替換模型，無需修改業(yè)務邏輯。

（3）關鍵差異：GraphEngine 任務編排引擎

這是 Dify 支撐復雜場景的核心，能將 AI 應用流程解析為可執(zhí)行的 DAG（有向無環(huán)圖），通過事件驅動實現節(jié)點調度。

① GraphEngine 的核心設計

• 節(jié)點類型全覆蓋通過??NODE_TYPE_CLASSES_MAPPING??維護所有節(jié)點，包括 Start/End 節(jié)點、LLM 節(jié)點、IFElse 分支節(jié)點、Knowledge Retrieval 節(jié)點、Tool 節(jié)點、Loop 循環(huán)節(jié)點等，滿足復雜流程語義；
• 事件驅動調度采用 “事件生成 - 發(fā)布 - 監(jiān)聽” 模式，關鍵事件包括??GraphRunStartedEvent??（工作流啟動）、??NodeRunStartedEvent??（節(jié)點執(zhí)行）、??GraphRunSucceededEvent??（工作流成功），由??WorkflowAppGenerator??監(jiān)聽事件并更新狀態(tài)；
• DAG 執(zhí)行流程從根節(jié)點（Source Node）開始，按拓撲排序逐層執(zhí)行節(jié)點，自動處理節(jié)點依賴關系。

② GraphEngine 執(zhí)行步驟（以 Workflow 應用為例）

圖片

1. 初始化用戶觸發(fā) Workflow 運行時，??AppGenerateService??根據應用類型（如 Workflow）調用??WorkflowAppGenerator??，初始化隊列管理器（QueueManager）、變量加載器（VariableLoader）；
2. 構建 DAG??WorkflowAppRunner??根據用戶配置的節(jié)點關系、輸入參數，生成可執(zhí)行的 DAG 圖；
3. 啟動引擎??WorkflowEntry???封裝??GraphEngine??，觸發(fā) DAG 執(zhí)行，同時監(jiān)聽節(jié)點事件；
4. 節(jié)點執(zhí)行按拓撲序執(zhí)行節(jié)點，若觸發(fā)工具調用則請求 Plugin 服務，執(zhí)行結果存入變量池；
5. 狀態(tài)管理??WorkflowAppGenerator??監(jiān)聽事件，持久化節(jié)點執(zhí)行狀態(tài)與日志，支持失敗重試。

優(yōu)化建議：Dify 默認采用本地消息隊列實現事件調度，增加了故障恢復復雜度。建議引入 Redis/Pulsar 等分布式消息隊列，實現無狀態(tài)設計，提升擴展性與容錯能力。

四、典型 AI Assistant 核心流程：從用戶提問到輸出

理解架構后，我們以 “多輪對話 + RAG + 工具調用” 的 AI Assistant 為例，看 Dify/Tasking AI 如何編排流程（以 Tasking AI 為例，Dify 邏輯類似但支持更復雜節(jié)點）：

1. 會話初始化Backend App 根據 Assistant ID 與 Chat ID，從本地緩存加載模型配置、插件列表、歷史會話；
2. 分布式鎖開啟基于 Redis 開啟分布式鎖，防止多請求沖突；
3. Query 處理

• 調用 Inference App 的 Embedding 模型，將用戶 Query 向量化；
• 基于向量化結果檢索知識庫，獲取相關文檔片段；
• 調用 Rerank 模型對檢索結果重排，提升相關性；

4. Prompt 構建結合重排后的檢索結果、歷史會話、插件信息，按 Prompt 模板生成系統提示詞；
5. 模型推斷將 Prompt 提交給 Inference App 的 Chat 模型，獲取推斷結果；

   

6. 工具調用判斷若模型返回 Function Call 指令，Backend App 請求 Plugin App 執(zhí)行對應工具（如搜索實時數據），將工具輸出再次傳入模型；
7. 結果返回組裝最終回答，持久化會話記錄，返回給用戶。

五、總結與展望：AI 原生應用開發(fā)平臺的未來

1. 兩款平臺的對比與選擇

2. 未來發(fā)展趨勢

（1）開發(fā)模式：從 “人工編排” 到 “意圖驅動自動生成”

未來平臺將支持通過自然語言描述需求（如 “構建一個客戶服務 AI，能檢索產品文檔并生成工單”），自動解析意圖、獲取領域知識、生成應用流程，并持續(xù)優(yōu)化驗證，進一步降低開發(fā)門檻。

（2）系統架構：向 “自愈型、自進化” 演進

• 自愈能力：自動檢測故障（如模型服務不可用），切換備用資源，降低人工干預成本；
• 自進化能力：通過機器學習分析應用運行數據，優(yōu)化模型參數、檢索策略、流程編排，提升應用效果。

AI 原生應用開發(fā)平臺的核心價值，始終是 “讓 AI 技術更高效地落地業(yè)務”。無論是 Dify 的復雜編排，還是 Tasking AI 的輕量設計，其架構思路都圍繞這一核心展開。對于開發(fā)者而言，理解這些設計邏輯，不僅能更好地使用平臺，更能為自定義 AI 應用架構提供參考，這正是本文的最終目的。

好了，這就是我今天想分享的內容。

本文轉載自???玄姐聊AGI??  作者：玄姐