1. 前言
期待已久的 Dify v1.0.0 终于正式发布了。作为一名从事生成式 AI 相关服务及基础开发的从业者，我感到无比兴奋！
该版本中备受关注的功能是新增的代理节点（Agent Node） 与插件系统（Plugin System） 。
所谓代理节点，是一种采用预先定义的 “代理策略（Agent Strategy）”，能根据问题自动执行工具调用及多步骤推理的新型节点。
本次，我将尝试使用 Dify 官方提供的智能体策略（Agentic Strategy）创建聊天流程（Chat Flow）。
2. 什么是代理节点
2.1. 基本功能
代理节点是一种可执行预先定义的多步骤推理及工具调用的节点。
通过在聊天流程中嵌入该节点，能够根据用户的问题动态选择、调用工具并进行推理，从而实现复杂任务的执行。
Dify 官方提供的名为 “Dify Agent Strategies” 的插件中，包含两种智能体策略，具体如下表所示：
| 策略（Strategy） | 概述（Overview） |
|---|---|
| Function Calling | 指 AI 能根据用户的问题，从预先定义的外部函数中判断应调用哪个工具，并返回所用函数名及参数的机制。也被称为 “Tool Use”（工具使用）。 |
| ReAct | 指 AI 交替执行推理（Reasoning）与行动（Action）的方法。通过反映思考结果及工具调用结果来更新回答，从而实现复杂问题的解决及任务自动化的机制。 |
本次将使用 Function Calling 来调用工具。
2.2. 与传统工作流实现方式的差异
以往，针对每种想要实现的聊天流程结构，都需要进行整体设计，并探讨工具选择的实现方法等。
例如，若想在聊天流程中实现 Function Calling，就需要考虑以下问题：
- 如何让系统选择合适的工具？
- 在何种条件下对所用工具进行分支处理？
- 考虑到分支后的处理，调用方需要传递哪些信息？
这些问题的探讨会导致设计、开发、修改等环节耗费大量成本。
而通过使用代理节点，这类成本有望得到降低。
2.3. 与 Dify 应用中 “代理” 的差异
传统的代理（Agent）是以单一应用的形式运行，是可独立执行预先定义的特定任务的应用。
简单来说，它和简单的聊天机器人比较接近。
另一方面，代理节点（Agent Node）会作为工作流的一部分被整合，能够与其他各类工具联动，从而实现复杂的处理。
3. 尝试使用代理节点（Agent Node）
3.1. 流程概述
本次将创建一个接收饮食相关咨询的聊天流程。
以下是我们这次要创建的流程。
创建主聊天流程，并使用该流程中代理节点的 Function Calling 策略来定义工具分配处理逻辑。该结构下，代理节点会根据问题调用相应的工具。
本次准备了以下 3 个工具：
- 菜单设计
- 营养师
- 一般咨询
3.2. 构建使用 Function Calling 的流程
工具准备
在代理节点之前，需先定义好待调用的工具。代理节点可调用的工具包括以下 3 类：
- 插件
- 自定义工具
- 工作流
本次将使用工作流作为工具。
从工作室的 “新建” 功能中选择 “工作流”，构建如下流程：该流程结构简单，接收问题后向大语言模型（LLM）发起查询。
为 “菜单设计” 功能的 LLM 定义了如下系统提示词：
你是专门设计并推荐餐食菜单的聊天机器人。请接收用户的问题与需求，根据内容提供最适合的餐食菜单。注意：仅需推荐单餐的菜单。
角色与目标：根据用户的问题及条件，推荐具体的菜名与烹饪方法。需兼顾营养均衡、烹饪难度、季节适配性、饮食主题（法餐、西餐、中餐等），设计符合用户需求的菜单。若用户提出具体条件（食材限制、过敏情况、预算、烹饪时间等），需推荐符合这些条件的菜单。
在结束节点的输出变量中设置 LLM 的回答后，工作流的构建即完成。为将其用作工具，需点击 “发布” 按钮，将工作流设置为公开状态。
为将创建好的工作流用作代理节点的工具，需进行名称等相关设置。“工具输入” 中的 “query”（查询）对应工作流开始节点中设置的输入字段。
此处可配置的 “方法” 项分为两类：
- LLM 输入：由 LLM 自动填充内容
- 设置：需自行预先定义填充值
本次中，“query” 项用于接收用户的问题，为了从 Function Calling 获取结果，将方法设置为 “LLM 输入”。
同理，“营养师”“一般咨询” 的工作流也通过以下系统提示词创建：
■ 营养师
你作为专业营养师，需针对用户提出的菜单及饮食相关问题，从健康与营养均衡的角度给出评价，并提供恰当的建议。请遵循以下指南进行回答。
从专业角度提供建议
根据菜单中包含的营养素、食材特点及烹饪方法给出具体评价。注意结合用户的问题与实际情况提供建议。
指南
用用户易于理解的语言讲解食材、烹饪方法及营养均衡相关知识。若菜单存在可改进之处或需补充的营养素，请给出具体建议。结合用户的目的（如维持健康、减肥、补充能量等）提供建议。
■ 一般咨询
你作为优秀的聊天机器人，请回答用户提出的各类问题。
代理节点设置
选择 “聊天流程” 新建应用，并按如下方式配置代理节点。
智能体策略：选择 Function Calling
模型：使用 AWS（Bedrock）的 “Claude 3 Haiku”。即使是 OpenAI 之外的、官方支持 Function Calling 的模型，也可正常执行。
工具列表（Tools List）：添加此前定义的 3 个工作流。
最后设置系统提示词与用户提示词：
■ 系统提示词
你是接收饮食相关咨询的代理系统的监控代理。请遵循以下规则与方针，选择合适的工具。
系统整体概述
针对用户的饮食相关问题，调用以下 3 类专业代理：
- 菜单设计：提供新菜单灵感及菜品推荐。
- 营养师：从营养均衡、健康层面、食材搭配等角度提供建议。
- 其他一般咨询代理：解答饮食之外的各类问题，以及不属于专业领域的饮食相关问题（如烹饪小知识、烹饪方法、食材挑选技巧等）。
注意事项
仅可选择 1 个工具。需基于调用工具返回的响应，充分利用所有信息进行回答。必要时可采用分点列举等方式，确保回答易于阅读。
最终目标
你的职责是为各代理创造条件，使其能在专业领域为用户的饮食相关问题提供最优回答，实现系统整体的一致性与高质量信息服务。
4. 尝试执行 Function Calling
执行结果
聊天流程整体搭建完成后，我们在预览模式下进行实际运行测试。
首先，针对菜单设计相关问题进行提问。
■ 问题 1
“帮忙想一个肉类料理的菜单”
结果如下：
查看日志可以发现，tool_name 字段显示，被调用的工具是在 “作为工具的工作流设置” 中配置的 think_name（注：推测为 “菜单设计” 工作流的配置名称，原文未明确说明，暂保留字段名）。这表明系统成功调用了 “菜单设计” 工作流。
进一步查看 query 部分，其中填入了 “肉类料理的菜单” 这一文本。由此可见，系统能从问题中提取出适合传递给工具的文本，并将其传入工具中。
我们也针对饮食之外的内容进行了提问。
■ 问题 2
“告诉我富士山的海拔高度”
从结果来看，系统调用了 “一般咨询” 工具。
当不存在对应的工具时会发生什么？
若不存在能匹配问题的合适工具，系统会如何运行呢？
我们先将代理节点中的 “一般咨询” 工具禁用，然后再次提出关于富士山海拔的问题。
首先，在代理节点的设置界面中，禁用 “一般咨询” 工具。
在该状态下，提出以下问题：
■ 问题
“告诉我富士山的海拔高度”
结果显示，系统选择了本应完全无关的 “菜单设计” 工具。
这意味着，无论收到何种问题，系统或许都会选择某个工具进行调用。
考虑到这一点，在设计和准备工具时，需要充分考量工具的覆盖范围与分类逻辑。
5. 总结
本次我们尝试了使用代理节点来执行函数调用（Function Calling）。
随着智能体策略的不断丰富，Dify 的使用场景想必会一下子变得更加多元！
今后，我也会持续关注 Dify 的更新动态。
发表回复