5分钟使用Dify实现《射雕英雄传》问答智能体Agent

引言

我们之前聊到《一文搞懂什么是AI Agent》、《MCP Agent 工程框架Dify初探》、《多智能Multi-Agent原理与实现初探》等大量关于Agent相关的概念，但始终没有完整得实现过Agent。

今天小马以Dify框架实践为例来实现一个关于小说《射雕英雄传》的智能问答Agent系统，并为了尽量演示覆盖Dify的所有关键节点的使用，还刻意额外增加了“问题分类器”、“HTTP请求”等节点的使用，一文就能上手Dify的入门使用, 亲测效果贼拉爽。话不多说，我们开始吧。

一、什么是Dify

关于Dify的概念这里不再赘述，《MCP Agent 工程框架Dify初探》这里介绍得很详细了。

它就是一个类似于LangChain一样的AI Agent实现框架，与其不同的是这个框架是可视化的，不会编程代码的同样也能照样叱诧风云，像搭积木一样推拉拽任意组装出自己想要的业务逻辑智能体，只要基础工具齐全，一切皆有可能，并没有研发人员什么事。

同样，它不仅能支持MCP，引言中提到的多智能体也是能通过它实现的，文末我们也会来特意探讨下。

当然，需要使用Dify我i们首先得熟读官方使用文档（也可以直接看小马上面提到的文章），然后就是得安装起来。

Dify官方文档传送门。

二、使用Dify实现《射雕英雄传》问答智能体Agent

2.1 Agent需求逻辑整理

我们今天要实现的是一部经典小说《射雕英雄传》的智能问答Agent系统，并包含天气问题意图分类判断。

我们的工作流功能逻辑流程如下：

1、户输入一个问题，问题分类器判断是否属于天气类别的问题；

2、如果是天气类别的则经过HTTP请求节点调用天气查询HTTP api，由于api返回的数据格式不规范，使用了参数提取器节点对返回结果进行了天气信息的提取，最终返回目标信息；

3、如果不是天气类别的问题，则经过知识检索节点通过向量知识库查询匹配语料，再通过Agent节点判断如果知识检索数据不足以得到答案则通过网络搜索工具获取参考信息，综合输出可以回答出问题答案的参考资料，如无合适资料则输出“暂无相关已知信息”。最终连接一个LLM节点兜底总结。

用户可以尝试这样输入提问：

黄蓉的出生地是？
郭靖的父亲是谁？
今天会下雨吗？
……

2.2 用Dify创建工作流

我们先来看下我们创建的 “工作流” 的最终效果。

我们接下来按照关键节点来逐一介绍, 且听小马慢慢道来。

2.2.1 开始节点

我们只需要关心新增一个我们的问题输入字段query即可。

2.2.2 问题分类器节点

这个节点是我们为了覆盖关键节点的使用刻意加的。

这里的模型一般情况是没有的,如果没有需要自行添加。
我们先在这里添加模型供应商的插件, 如OpenAI。

假设我们添加的是OpenAI的供应商插件,则需要填写调用模型接口的api key。

填写完key之后, 就可以添加模型了。

添加完模型, 我们就可以回到分类节点选择模型了。假设我们已选定某模型(样例中我们显示的是deepseek-r1模型, 注意这个不属于openai的模型,仅供效果参考)。
这里唯一需要注意的是, 这个节点本质上看起来其实也是个Agent节点封装的, 因此所选的模型要支持Agent能力(Function Calling/ReAct)。

至此问题分类器节点配置完毕。

2.2.3 HTTP 请求节点

我们选择了一个免费的天气接口: https://wttr.in/nanjing。


细心的同学可以看到, 我们后面接了一个 “参数提取器” 用于对结果信息的有用信息提取(因为这个api返回的是个 不规则的结构数据)。

2.2.4 参数提取器节点

这个节点本质上也是需要LLM来处理信息并提取的, 所以也需要配置一个LLM来提取总结。

至此, 加上结束节点, 天气分支的流程就结束了。

2.2.5 知识检索节点

接下来我们进入另一个分支, 知识检索节点。
这个节点我们需要先去知识库处理知识语料录入。

在知识库菜单, 我们导入文件小说《射雕英雄传》txt文件后可以看到如下。(有需要文件的也可以直接找小马)

我们为了方便就不选择向量处理 LLM来向量化了, 选择直接切割入库,其他参数按需选择。当然,我们通常认为向量化的语义相似度匹配更能适用一些场景。

处理完知识库, 我们继续回到节点进行知识库选择即可。

2.2.6 AGENT节点

这里的Agent只负责获取参考信息的职责任务并没有处理最后总结输出,当然也是可以直接处理总结输出的, 为了演示全部节点的时候, 本工作流在此后又接了个 LLM节点来处理总结, 特此说明。

我们选择策略是 ReAct, 两种Agent策略的不同我们放在下一章节来介绍。我们选了模型(主要需要支持Agent思考能力), 同时我们为Agent添加了工具插件。

上面是我们的核心中的核心, 就是指令配置。以及我们配置了知识检索结果作为上下文。

## 角色定位
作为专业的知识检索分析师，我将通过以下结构化流程为您提供完整的参考知识材料：## 分析流程
1.分析上一步知识库检索得到的资料：{{#1757407853456.result#}}是否可以得到问题{{#1757302749117.query#}}的答案；
2.如果无法得到问题的答案，请从网页爬虫检索问题的参考资料；
3.综合输出可以回答出问题答案的参考资料，如无合适资料则输出“暂无相关已知信息”。

我们的指令内容如上, 当然这个只是为了演示, 指令还是有很多优化空间的, 不是本文的重点。

最后, 我们设置一下最大的思考循环次数,防止死循环。

至此, AGENT节点的配置结束了。

2.2.7 LLM节点

这是我们最后的一个节点, 功能是根据参考知识总结最后的结果输出。

此时, 我们将上一个节点AGENT的结果作为上下文{{#context#}}输入总结模型。

指令内容如下：

已知信息：{{#context#}}根据上述已知信息，简洁和专业的来回答用户的问题，回答时直接输出答案。如果无法从中得到答案，请说 “暂时无法回答该问题” 或 “没有提供足够的相关信息”，不允许在答案中添加编造成分，答案请使用中文。 问题是：{{#1757302749117.query#}}

2.2.8 结束节点

这个节点就是接收最终输出参数即完成任务。

至此, 整个工作流就结束啦。点击右上角的 “运行” 我们就可以体验到需求逻辑的效果了, 可以在 “运行历史” 中查看整个 工作流执行中各个节点的 运行日志逻辑, 对于调试也是非常友好。

因为小马本次演示是导入的 DSL, 因环境问题, 所以流程上还需要一些修复, 因此就不直接演示了。但是这个流程小马是亲测跑通过, 绝对靠谱, 哈哈哈。如有疑问, 欢迎交流探讨。

三、探讨Dify如何实现多智能体

如果已经试成功的小伙伴是不是已经体验到了效果的哇塞。我们上面的流程似乎还没涉及多智能体的协作。有的同学说,不对啊, 流程中我们不是用了那么多的Agent智能体呢。

我们还是需回顾下对多智能体的定义。

3.1 Dify 实现多智能体协作的方式

在 Dify 中，“多智能体”（Multi-Agent）通常指的是通过工作流（Workflow） 编排多个具备不同能力的 Agent 节点，或者由一个“中枢”Agent 节点根据任务动态选择和调用不同的工具（这些工具可以代表某些特定功能或能力域，其背后可能由其他模型或逻辑支持，但并非直接以另一个完整 Agent 节点的形式被添加）来协同完成复杂任务。

核心关键在于工作流的编排和Agent 节点的策略配置，而不是简单地将一个 Agent 作为工具添加到另一个 Agent 中。

主要实现方式

1. 工作流（Workflow）中编排多个 Agent 节点：这是 Dify 实现多智能体协作最直接和常见的方式。你可以在一个工作流中依次或并行地部署多个 Agent 节点，每个节点承担特定子任务，并通过节点连接传递参数和结果。
   例如，一个电商客服工作流可以这样设计：

   • Agent 节点1（意图识别）：判断用户是想咨询商品、查询订单还是投诉。
   • 条件判断节点：根据意图将流程导向不同的分支。
   • Agent 节点2（商品咨询专家）：专门处理商品详情、推荐等问题，可连接知识库和商品数据库。
   • Agent 节点3（订单查询专家）：专门处理订单状态、物流等问题，可连接订单系统 API。
   • Agent 节点4（客户投诉处理）：处理投诉，并可能在需要时调用外部工单系统 API。 这些 Agent 节点各司其职，通过工作流串联，共同构成一个多智能体协作系统。

2. 单个 Agent 节点配置复杂策略与工具链：一个强大的 Agent 节点本身可以通过配置复杂的推理策略（如 ReAct）和丰富的工具集，来模拟“多智能体”的协作行为。这个 Agent 会自主规划、思考，并选择调用不同的工具来逐步解决问题，其行为模式类似于一个“大脑”指挥多个“工具手”。
   例如，一个“旅行规划”Agent 节点可以配置以下工具：

   • 网络搜索工具：查找最新旅行信息和景点评价。
   • 航班查询 API：获取实时航班信息和价格。
   • 酒店预订 API：查询和预订酒店。
   • 天气查询 API：获取目的地天气预报。
   • 地图服务 API：规划本地交通路线。

当用户提出“我想下周末去北京旅游，帮我规划一下”的请求时，这个 Agent 会自主决定调用搜索工具了解北京热门景点，调用航班和酒店 API 查询和预订，调用天气 API 建议携带衣物，最后调用地图 API 规划大致行程。这看起来就像是多个专门化的智能体在协作，但实际上是由一个 Agent 节点调度多个工具完成的。

3.2 Agent 节点的核心：策略与工具

在 Dify 的 Workflow 中，Agent 节点的能力主要来源于其配置的推理策略和工具集。

特性	Function Calling 策略	ReAct 策略
工作原理	LLM 根据用户指令直接匹配预定义函数/工具，并提取参数进行调用。	LLM 模拟“思考-行动-观察”循环，逐步推理，自主决定何时调用何种工具。
优点	响应速度快，对于目标明确的任务精确度高，输出结构化。	灵活性更强，能处理更复杂、未知或需要多步推理的任务，可解释性更好（通过日志查看思考过程）。
适用场景	工具功能明确、参数清晰的场景，如查询天气、计算器、调用特定数据库查询等。	任务复杂、需要逻辑推理、动态规划或探索的场景，如复杂问题解答、多步骤规划、未知工具探索等。
多智能体协作体现	更像一个高效的“命令执行者”，快速调用特定工具。	更像一个“自主规划者”，其动态推理和工具调用过程更像一个智能体在独立工作。

3.3 实施多智能体协作的建议

• 明确分工与边界：无论是多个 Agent 节点还是一个“强大”的 Agent 节点，在设计之初就要明确每个部分的责任域，避免功能重叠和混乱。清晰的分工是高效协作的前提。
• 注意迭代次数与超时：对于使用 ReAct 策略的 Agent 节点，要合理设置最大迭代次数，防止陷入无限循环或过长的推理过程，平衡响应时间和任务复杂度。

总结: 按照上面的说法, 我们如果要改造上文中的工作流的话, 小马作个大胆的猜想。我们可以在主Agent的节点中多加几个含Agent的工作流来作为职能工具, 比如 “根据小说内容自续写创作答案Agent” 、 “从相识网络小说自总结Agent”。然后我们对主Agent的指令这样要求, 如果知识库不能总结出问题答案, 则尝试用网页爬虫检索问题的参考资料, 如果网页爬虫也拿不到答案, 则随机选择 “根据小说内容自续写创作答案Agent” 或 “从相似网络小说自总结Agent” 工具来生成参考资料用于问题回答。(注: 前者会自己根据知识库内容续写小说并造出一个参考语料, 后者则会先搜索网络小说后自己从中总结出答案语料)

最终主Agent再根据各方得到的资料总结语料是否能得出问题答案, 若不能得出还是像原工作流一样直接告诉后面的LLM 没有参考语料。

这样也算是多Agent的子任务协调了。

本文抛砖引玉, 如有不到之处欢迎更正交流。夜已深, 时间不早了,就此搁笔吧, 感谢评阅, 下次再见。