大家好，我是玄姐。

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

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

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

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

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

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

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

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

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

1. 有狀態 / 無狀態應用雙支持

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

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

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

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

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

3. 多租戶隔離機制

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

4. 復雜任務編排能力（Dify 獨有優勢）

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

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

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

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

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

圖片

（1）Backend App：應用開發入口

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 核心模塊

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

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

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

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

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

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

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

① GraphEngine 的核心設計

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

② GraphEngine 執行步驟（以 Workflow 應用為例）

圖片

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

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

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

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

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 執行對應工具（如搜索實時數據），將工具輸出再次傳入模型；
7. 結果返回組裝最終回答，持久化會話記錄，返回給用戶。

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

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

2. 未來發展趨勢

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

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

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

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

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

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

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