引言

在《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初探 就告一段落了，欢迎交流。