引言

在《OpenAI Agent調用MCP Server案例分析》一文，小馬介紹了支持MCP的框架，其中Dify目前備受青睞。對于企業來說，早期一般會沉淀一系列的AI應用，然后如何把這些應用的能力能串聯到一起這是一個很值得探討的話題。而Dify正是這樣的一個框架，它兼容MCP，這樣已經落地的應用都可以封裝成一個MCP Server以工具的形式提供給AI LLM決策調用。就像積木一樣，把原本需要分別各自獨立實現一個成果的零件分別拆開工具化，這些工具作為基礎顆粒模塊就可以再自由拼裝出N種不同的成果。

本文小馬就對Dify進行初探，整理總結，聚焦剖析，以一個初學者的視角進入Dify的世界，幫助大家對Dify有初步的理解。尤其對于正在打算了解Dify框架或者正在進行Agent工程框架選型的同學具有參考意義。

閱讀本文之前默認讀者已經對基本的AI技術棧概念知識有所了解。

一、Dify是什么

首先我們來到Dify官方文檔。

Dify 是一款開源的大語言模型（LLM）應用開發平臺。它融合了后端即服務（Backend as Service）和 LLMOps 的理念，使開發者可以快速搭建生產級的生成式 AI 應用。即使你是非技術人員，也能參與到 AI 應用的定義和數據運營過程中。

這里面最后一句的概念很重要，“即使你是非技術人員，也能參與到 AI 應用的定義和數據運營過程中。”

想要git倉庫源碼的同學可以移步這里傳送門。但源碼不是今天本文的重點。

二、為什么使用Dify

為什么使用 Dify？

你或許可以把 LangChain 這類的開發庫（Library）想象為有著錘子、釘子的工具箱。與之相比，Dify 提供了更接近生產需要的完整方案，Dify 好比是一套腳手架，并且經過了精良的工程設計和軟件測試。
重要的是，Dify 是開源的，它由一個專業的全職團隊和社區共同打造。你可以基于任何模型自部署類似 Assistants API 和 GPTs 的能力，在靈活和安全的基礎上，同時保持對數據的完全控制。

這一點也正是呼應了上一段的“即使你是非技術人員，也能參與到 AI 應用的定義和數據運營過程中。”，它已經工程化了，直接可以傻瓜式操作。

三、使用Dify要怎么做

這才是一個龐大的重點話題。
我們先站在非研發人員的角度來討論這個話題，我們可以如何使用它。先來看幾組概念。

在 Dify 中，一個“應用”是指基于 GPT 等大語言模型構建的實際場景應用。通過創建應用，你可以將智能 AI技術應用于特定的需求。它既包含了開發 AI 應用的工程范式，也包含了具體的交付物。 簡而言之，一個應用為開發者交付了：

**封裝友好的API，可由后端或前端應用直接調用，通過 Token 鑒權； **
開箱即用、美觀且托管的WebApp，你可以 WebApp 的模板進行二次開發；
一套包含提示詞工程、上下文管理、日志分析和標注的易用界面；

你可以任選其中之一或全部，來支撐你的 AI 應用開發。

小馬特別喜歡其中的第一條，是不是意味著這個框架不僅提供了工程應用的搭建和Agent編排，同時還能提供API的調用服務。這對于企業來說既解決了工程應用的問題同時也具備了提供API服務的增值能力。

你可以通過 3 種方式在 Dify 的工作室內創建應用：

基于應用模板創建（新手推薦）
創建一個空白應用
通過 DSL 文件（本地/在線）創建應用

Dify 中提供了五種應用類型：

聊天助手：基于 LLM 構建對話式交互的助手
文本生成應用：面向文本生成類任務的助手，例如撰寫故事、文本分類、翻譯等
Agent：能夠分解任務、推理思考、調用工具的對話式智能助手
對話流：適用于定義等復雜流程的多輪對話場景，具有記憶功能的應用編排方式
工作流：適用于自動化、批處理等單輪生成類任務的場景的應用編排方式

上面這幾種類型看起來似乎沒啥區別，我們自己來詳細整理下這幾個應用類型的不同。

應用類型	對比區別
聊天助手	聊天式；多輪對話；上下文保存－持續；AI 開場白－支持；情景舉例－聊天；對話型應用的編排支持：對話前提示詞，變量，上下文，開場白和下一步問題建議；
文本生成應用	表單+結果式；一問一答；上下文保存－當次；AI 開場白－不支持；情景舉例－翻譯、判斷、索引；
Agent	智能助手（Agent Assistant），利用大語言模型的推理能力，能夠自主對復雜的人類任務進行目標規劃、任務拆解、工具調用、過程迭代，并在沒有人類干預的情況下完成任務；Agent應用的編排：提示詞－＞你可以在“提示詞”中編寫智能助手的指令，為了能夠達到更優的預期效果，你可以在指令中明確它的任務目標、工作流程、資源和限制等。添加工具－＞在“上下文”中，你可以添加智能助手可以用于查詢的知識庫工具，這將幫助它獲取外部背景知識。在“工具”中，你可以添加需要使用的工具。工具可以擴展 LLM 的能力，比如聯網搜索、科學計算或繪制圖片，賦予并增強了 LLM 連接外部世界的能力。配置Agent－＞在 Dify 上為智能助手提供了 Function calling（函數調用）和 ReAct 兩種推理模式。已支持 Function Call 的模型系列如 gpt-3.5/gpt-4 擁有效果更佳、更穩定的表現，尚未支持 Function calling 的模型系列，我們支持了 ReAct 推理框架實現類似的效果；
對話流	－
工作流	工作流通過將復雜的任務分解成較小的步驟（節點）降低系統復雜度，減少了對提示詞技術和模型推理能力的依賴，提高了 LLM 應用面向復雜任務的性能，提升了系統的可解釋性、穩定性和容錯性。Dify 工作流分為兩種類型：Chatflow面向對話類情景和Workflow面向自動化和批處理情景 ；

接下來小馬就重點挑幾個和小馬業務有關的應用類型來進一步展開剖析。

1、聊天助手

對話型應用采用一問一答模式與用戶持續對話。對話型應用的編排支持：對話前提示詞，變量，上下文，開場白和下一步問題建議。

這倒是蠻適合客戶服務和智能問答場景的，如下還可以自己添加附屬功能。

有一個不足如下：
聊天助手類型應用不支持添加第三方工具，你可以在 Agent 類型應用內添加第三方工具。
怎么理解這句話呢？就是聊天應用類型只支持上下文這里的知識庫（數據集或文件上傳），你如果要自己添加一些第三方工具，如Google搜索引擎則不支持，需要自己使用Agent類型去實現。
（因此這里的聊天助手類型應用小馬認為可拓展性還是有待斟酌的，選擇的時候應慎重考慮自己的業務場景是否能匹配滿足，長遠考慮如果不行應直接選擇可拓展性強的Agent類型）

2、Agent

這是小馬重點關注的重中之重。
在上面的對比區別表格中，我們可以看到大致分為了幾個步驟。

Agent應用的編排：選擇模型->編輯提示詞->添加工具->配置Agent

選擇智能助手的推理模型，智能助手的任務完成能力取決于模型推理能力，我們建議在使用智能助手時選擇推理能力更強的模型系列如 gpt-4 以獲得更穩定的任務完成效果。

你可以在“提示詞”中編寫智能助手的指令，為了能夠達到更優的預期效果，你可以在指令中明確它的任務目標、工作流程、資源和限制等。

在“上下文”中，你可以添加智能助手可以用于查詢的知識庫工具，這將幫助它獲取外部背景知識。
在“工具”中，你可以添加需要使用的工具。工具可以擴展 LLM 的能力，比如聯網搜索、科學計算或繪制圖片，賦予并增強了 LLM 連接外部世界的能力（這里就是上面聊天助手應用類型所提到的它不能支持在上下文中添加第三方工具的部分）。Dify 提供了兩種工具類型：第一方工具和自定義工具。

（小馬插播一下：根據經驗，從這一點來看，幾乎可以判定 聊天助手應用類型 的技術實現使用的是類似langchain的RAG架構，而 Agent應用類型 的技術實現使用的是類似langchain的Agent核心組件模塊。是Agent與非Agent思想架構的區別。《LangChain與Agent實現》）

你可以直接使用 Dify 生態提供的第一方內置工具，或者輕松導入自定義的 API 工具（目前支持 OpenAPI / Swagger 和 OpenAI Plugin 規范）。

“工具”功能允許用戶借助外部能力，在 Dify 上創建出更加強大的 AI 應用。例如你可以為智能助理型應用（Agent）編排合適的工具，它可以通過任務推理、步驟拆解、調用工具完成復雜任務。
另外工具也可以方便將你的應用與其他系統或服務連接，與外部環境交互。例如代碼執行、對專屬信息源的訪問等。你只需要在對話框中談及需要調用的某個工具的名字，即可自動調用該工具。

下一步我們配置Agent。官方是這么說的。

在 Dify 上為智能助手提供了 Function calling（函數調用）和 ReAct 兩種推理模式。已支持 Function Call 的模型系列如 gpt-3.5/gpt-4 擁有效果更佳、更穩定的表現，尚未支持 Function calling 的模型系列，我們支持了 ReAct 推理框架實現類似的效果。
在 Agent 配置中，你可以修改助手的迭代次數限制。

小馬認為這段話似乎理解起來有點歧義，Function calling和ReAct并不是兩個平行的概念吧？要實現一個完整的推理循環的Agent，必須是需要ReAct 的吧。而模型是否支持Function calling應該只是會影響其中Action環節的穩定性。這兩種模型的選擇并不是解決模型是否兼容Function calling的問題，而應該是解決是否需要ReAct推理的選擇。 于是小馬也進行了進一步的探索驗證。

2.1 Function calling（函數調用）和 ReAct 兩種推理模式的區別

這里提到了兩種推理模式，我們從以下兩張官方的案例圖多少可以看出兩種推理模式的不同（放大看嗷）。

Function calling（函數調用）和 ReAct（Reasoning + Acting）是構建AI智能體的兩種核心推理模式，它們在機制、適用場景和設計哲學上存在顯著差異。核心區別在于：Function calling 針對結構化工具調用，強調高效執行；而 ReAct 通過迭代推理和行動循環處理復雜問題，注重適應性和可解釋性。

2.1.1 技術本質與工作流程對比

Function calling?
技術本質?：一種結構化輸出協議，模型將用戶意圖映射到預定義函數或工具（如API調用），直接輸出標準化格式（如JSON），實現機器間通信。
工作流程?：單次請求完成決策：模型識別意圖 → 選擇工具 → 提取參數 → 執行并返回結果，無需多步迭代。

ReAct?
技術本質?：一種認知行為框架，模擬人類推理-行動循環，模型通過自然語言描述思考過程，結合外部工具交互逐步推進任務。
工作流程?：迭代循環：思考推理（Reason）→ 行動調用工具（Act）→ 觀察結果（Observe）→ 調整策略直至解決問題。

2.1.2 優缺點對比

Function calling?
優點?：
執行效率高：適用于簡單任務，響應速度快、。
結構化輸出：便于下游處理（如數據檢索或API集成）。
缺點?：
靈活性低：處理模糊意圖或多步任務時易出錯（如參數提取失敗）。
可解釋性弱：決策過程在模型內部（黑盒），用戶難跟蹤。

ReAct?
優點?：
靈活性強：適應開放世界問題，能動態調整策略（如根據工具輸出修改計算邏輯）。
可解釋性高：推理步驟顯式呈現（白盒），便于調試和信任。
缺點?：
執行成本高：多步循環增加時間和資源消耗。
依賴模型能力：部分基礎模型不支持自然語言指令解析。

2.1.3 適用場景與選擇依據

Function calling?：
適合意圖明確、結構化任務，例如：
實時數據查詢（如股票價格或天氣檢索）。
自動化工具調用（如數學計算或API交互）。

ReAct?：
適合復雜、多步驟問題，例如：
動態調整方案（如折扣計算中根據觀測值修改公式）。
開放環境決策（如目標導向的任務規劃）。

實踐中，兩者常結合使用（如混合架構），以平衡效率與適應性。選擇時優先考慮任務復雜度：Function calling 用于高效執行，ReAct 用于復雜推理。

2.2 LangChain 的 Agent 實現原理?同時融合了 Function Calling 和 ReAct 兩種模式?

這是本文的一則題外話，但是既然氣氛都到這里了還是一起整理了。

LangChain 的 Agent 實現原理?同時融合了 Function Calling 和 ReAct 兩種模式?，具體取決于底層使用的 LLM 和 Agent 類型。

2.2.1 核心機制：ReAct 框架?

ReAct（Reasoning + Acting）? 是 Agent 的?基礎推理邏輯?：

Thought?：LLM 分析問題并制定計劃。
Action?：選擇要調用的工具（如搜索、計算器）。
Action Input?：提供工具所需的參數。
Observation?：獲取工具執行結果。
循環直到得出最終答案（Final Answer）。

ReAct 是通用模式?：無論是否顯式使用 Function Calling，LangChain Agent 的交互流程都遵循此循環。

2.2.2 ?Function Calling 的作用?

優化 Action 步驟?：

傳統 ReAct 依賴 LLM 輸出結構化文本（如 Action: 工具名），易出錯。
Function Calling 允許 【LLM ?直接輸出】結構化 JSON?（工具名 + 參數），提高可靠性。

例如：OpenAI 的 gpt-3.5-turbo 支持 tools 參數，可返回：

{"tool_calls": [{"name": "search","arguments": {"query": "LangChain 工作原理"}}]
}

非必需但高度兼容?：
若 LLM 支持 Function Calling（如 OpenAI、Anthropic），LangChain 優先使用它以提升穩定性。
若不支持（如開源模型），Agent 仍可通過文本解析實現 ReAct。

2.2.3 LangChain 的靈活實現

不同 Agent 類型適配不同模式?：

Agent 類型	使用場景	典型模式
ZERO_SHOT_REACT_DESCRIPTION	通用任務（默認）	ReAct（文本解析）
OPENAI_FUNCTIONS	適配 OpenAI Function Calling	?Function Calling?
STRUCTURED_CHAT_ZERO_SHOT	復雜多工具場景	?ReAct + 結構化輸出

底層統一性?：
所有 Agent 均遵循 ReAct 的循環決策流程。
Function Calling 僅替代了其中的 ?Action 生成步驟?（從文本 → JSON）。

2.2.4 技術流程對比

傳統 ReAct（無 Function Calling）?

LLM 輸出: Thought: 我需要搜索天氣信息。Action: searchAction Input: {"query": "北京今日天氣"}
→ LangChain 解析文本，調用工具

Function Calling 優化版?

LLM 輸出（JSON）: {"tool_calls": [{"name": "search","arguments": {"query": "北京今日天氣"}}]}
→ LangChain 直接執行工具

結論
ReAct 是核心框架?：定義 Agent 的推理循環（Thought → Action → Observation）。
Function Calling 是優化手段?：在支持的 LLM 上替代文本解析，提升 Action 生成的準確性和效率。
LangChain 同時支持兩者?：根據 LLM 能力和 Agent 配置動態選擇模式。本質上是通過 Function Calling 增強的 ReAct 實現。?

3、應用工具箱

在 工作室 — 應用編排 內點擊 添加功能，打開應用工具箱
應用工具箱為 Dify 的應用提供了不同的附加功能：

Dify這里的應用工具箱似乎是一個功能附屬插件的概念，而不是MCP中的工具的概念。

4、工作流

小馬認為AI的工作流和傳統普通工作流的區別主要在于，有LLM參與的工作流可以讓決策更加智能同時AI的能力也將被串聯在工作流中。如下的幾個LLM節點的任務能力。（這似乎和Agent還是有概念區別的，雖有相關，但一個側重流程一個側重智能決策。同時我們也可以看到節點中已包含著工具、Agent、LLM等，從結構上也有子集關系。）

LLM 節點是 Chatflow/Workflow 的核心節點。該節點能夠利用大語言模型的對話/生成/分類/處理等能力，根據給定的提示詞處理廣泛的任務類型，并能夠在工作流的不同環節使用。

• 意圖識別，在客服對話情景中，對用戶問題進行意圖識別和分類，導向下游不同的流程。
• 文本生成，在文章生成情景中，作為內容生成的節點，根據主題、關鍵詞生成符合的文本內容。
• 內容分類，在郵件批處理情景中，對郵件的類型進行自動化分類，如咨詢/投訴/垃圾郵件。
• 文本轉換，在文本翻譯情景中，將用戶提供的文本內容翻譯成指定語言。
• 代碼生成，在輔助編程情景中，根據用戶的要求生成指定的業務代碼，編寫測試用例。
• RAG，在知識庫問答情景中，將檢索到的相關知識和用戶問題重新組織回復問題。
• 圖片理解，使用 vision 能力的多模態模型，能對圖像內的信息進行理解和問答。

選擇合適的模型，編寫提示詞，你可以在 Chatflow/Workflow 中構建出強大、可靠的解決方案。

5、工具 - MCP Server工具

這是一個很重要的點，也是小馬最關心的點之一。特別在MCP火爆的今天，不支持就會落伍。《模型上下文協議（Model Context Protocol，MCP）初見概念篇》

添加MCP Server 到Dify。還不知道如何實現一個MCP Server的也可以參考這里《編寫第一個MCP Server之Hello world》。

5.1 集成 MCP 工具

你可以在 Dify 的 Agent 和 Workflow 應用中，直接集成來自外部 MCP 服務器的工具。除了使用 Dify 內置插件外，還可以接入 MCP 生態系統中的第三方服務，持續擴展你的應用功能。

5.2 在應用中使用 MCP 工具

當服務器配置完成后，其下的工具會出現在應用構建時的工具選擇區：
?
Agent 應用
在 Agent 配置界面，與內置工具并列顯示 MCP 工具。
工具按服務器分組，例如：“Notion MCP ? 創建頁面”、“Linear MCP ? 創建任務”等。
可一鍵”添加全部”，快速啟用該服務器下的所有工具。
?
Workflow 應用
構建 Workflow 時，MCP 工具以可選節點類型出現。
每個工具節點都會指明歸屬服務器，便于定位和排查問題。
參數較為復雜的工具會自動生成 JSON 格式的結構化輸入界面。
?
Workflows 中的 Agent 節點
在 Workflow 的 Agent 節點中，也可靈活選擇 MCP 工具進行配置，使用方式與獨立 Agent 一致。

至此，MCP的Agent 工程框架 Dify初探 就告一段落了，歡迎交流。