我要投稿

Dify 开源DeepResearch工作流实现本地和Web混合搜索并探索工作流图的正确解析方法（一）

发布日期：2025-03-31 20:33:07 浏览次数： 1552 作者：AI工具推荐官

往期文章回顾：

dify内置DeepResearch工作流溯源——来看看Dify官方博客对它的介绍" data-itemshowtype="0" target="_blank" linktype="text" data-linktype="2">Dify内置DeepResearch工作流溯源——来看看Dify官方博客对它的介绍

Dify内置DeepResearch深度体验，抽丝剥茧带大家瞧瞧它的真实水准

Dify 实现DeepResearch工作流拆解并再看升级版Dify能否搭建出Manus？

深度解析：Dify能否复刻Deep Research与Manus？三大工具深度对比

普通打工人变身研究员还有多远？——2025年AI深度研究工具生死竞速，谁将主宰你的未来？

1、Open-Deep-Research-workflow-on-Dify简介

在之前的文章中，我介绍了Dify内置DeepResearch工作流，深入剖析了它的构成并体验了它的运行效果。发现不足还是挺多的，比如信源配置单一，只有Tavily一种信源输入，最头痛的是不能检索和使用本地文献进行研究。今天，带大家看看另一个开源实现（Open-Deep-Research-workflow-on-Dify），它正好解决了本地信源导入问题。

项目链接：https://github.com/AdamPlatin123

这个工作流是对DeepResearch进行了复现，但是没有介绍参考了哪个项目。从作者github首页看到follow了一个DeepResearch开源项目——open-deep-research，是参照这个了吗？

不妨打开这个项目看下：

翻看主页，原来是Firecrawl的创始人搞的。其实我在两周前已经在本地部署Firecrawl了，还没来得及集成，没想到它真的可以用到DeepResearch里面，看来我之前的判断还是没错的。

但是open-deep-research并没有搜索本地资源功能，另外从它的demo视频（https://x.com/nickscamara_/status/1886459999905521912）来看，它的流程和工作流Open-Deep-Research-workflow-on-Dify也是不一致的。今天暂时就不深入探索这个项目（open-deep-research）了，这次集中讲讲这个工作流的具体实现。

2、工作流解析成Mermaid代码

Open-Deep-Research-workflow-on-Dify工作流如上。像这种工作流图，看起来还是很让人头痛的，因为用户拖拉拽随意性比较高，另外工作流还进行了折叠，当然用“整理节点”调整后可读性会提高一些，但是作者设置的标注信息会混乱，同时画布是横向布置，超出屏幕显示范围，很难轻易读懂。

我们还有什么方法可以得到更加友好、一看就懂的工作流图呢？

2.1、采用大模型对直接对配置文件进行解析

之前尝试过让大模型（DeepSeek-V3-0324）直接从工作流配置文件整理出mermaid图形代码，这次我也试了，得到的效果如下：

我们把它和下面这个图的部分截图对照可以发现，大模型整理的工作流图是不完全准确的，它把工作流中部重要的串行结构错误识别为并行结构。

那么，为啥会出现这么大的偏差呢？

个人认为原因，主要原因有：

（1）工作流配置文件太大了，看下图，达到3401行，约9.7万字符，从这么多字符里面梳理出完整的图结构信息，难度可想而知。

（2）工作流配置文件中包含很多冗余字段，造成工作流图的节点关系很容易被混淆。

2.2、采用代码对配置文件进行解析

为了解决以上问题，暂时能想到的最好的方式就是用代码进行解析了。

直接上代码解析结果：

# Deep Researcher On Dify 工作流图```mermaidgraph TD    n1["开始 start"]    n2["sub主题1分析 llm"]    n3["问题4 answer"]    n4["条件分支 if-else"]    n5["问题2 answer"]    n6["问题分解 llm"]    n7["变量赋值 assigner"]    n8["问题参数提取 parameter-extractor"]    n9["第一次回复&问题1 answer"]    n10["上下文变量赋值  assigner"]    n11["问题变量赋值 assigner"]    n12["问题3 answer"]    n13["最终回复 answer"]    n14["上下文变量赋值  assigner"]    n15["上下文变量赋值 assigner"]    n16["上下文变量赋值 assigner"]    n17["输出：正在生成最终回答 answer"]    n18["sub主题提取 llm"]    n19["sub主题提取 parameter-extractor"]    n20["回答优化 llm"]    n21["回答优化 llm"]    n22["回答优化 llm"]    n23["回答优化 llm"]    n24["sub主题2分析 llm"]    n25["sub主题3分析 llm"]    n26["sub主题4分析 llm"]    n27["总结文档 template-transform"]    n28["变量赋值  assigner"]    n29["主题提取 llm"]    n30["回答记录1 assigner"]    n31["回答记录2 assigner"]    n32["回答记录3 assigner"]    n33["回答记录4 assigner"]    n34["输出：研究主题 answer"]    n35["输出：构建研究角度 answer"]    n36["输出：研究角度 answer"]    n37["迭代搜索1 iteration"]    n38["sub关键词提取1 parameter-extractor"]    n39["sub关键词提取2 parameter-extractor"]    n40["sub关键词提取3 parameter-extractor"]    n41["sub关键词提取4 parameter-extractor"]    n42["迭代搜索2 iteration"]    n43["迭代搜索3 iteration"]    n44["迭代搜索4 iteration"]    n45["起始段 llm"]    n46["结尾段 llm"]    n47["条件分支 2 if-else"]    n48["条件分支 3 if-else"]    n49["直接回复 10 answer"]    n4 -->|sys.dialogue_count=1| n5    n4 -->|sys.dialogue_count=0| n7    n7 --> n6    n6 --> n8    n8 --> n9    n4 -->|sys.dialogue_count=2| n12    n4 -->|sys.dialogue_count=3| n3    n18 --> n19    n20 --> n14    n23 --> n16    n22 --> n10    n21 --> n15    n29 --> n28    n4 -->|sys.dialogue_count=4| n17    n4 -->|sys.dialogue_count=4| n29    n5 --> n30    n12 --> n31    n3 --> n32    n17 --> n33    n28 --> n34    n19 --> n36    n1 --> n4    n19 --> n38    n8 --> n11    n4 -->|sys.dialogue_count=4| n21    n4 -->|sys.dialogue_count=4| n20    n4 -->|sys.dialogue_count=4| n23    n2 --> n24    n26 --> n46    n24 --> n25    n46 --> n27    n37 --> n42    n42 --> n43    n38 --> n39    n40 --> n41    n39 --> n37    n41 --> n37    n19 --> n40    n43 --> n44    n25 --> n26    n27 --> n47    n47 -->|17391136443240.te...| n13    n44 --> n45    n45 --> n2    n10 --> n48    n48 -->|conversation.quer...| n35    n35 --> n18    n47 -->|其他情况| n49    n16 --> n22```

结果和原工作流能完全对应上，并且采用竖向布局，一眼能看清全貌，对于人类这种严重依赖视觉进行记忆和理解的动物来说，相对dify的横向布局图，要容易理解多了，可以说，有了这个，几乎再也不用担心看不懂复杂的Dify工作流图了（到目前为止，这个工作流图几乎是我遇到过的最复杂的了）。

2.3、Mermaid工作流图对工作流自动优化的意义

相对于LangChain、MetaGPT等大模型和Agent编排框架来说，Dify工作流对于开发者来说是非常友好了，拖拉拽加很少的代码就能实现生产级的功能或应用。但是，作为一个Dify重度使用者，还是觉得工作流的搭建和维护非常繁琐，自己一直在思考，如何能够更近一步，实现动动嘴就能把工作流优化好或者甚至从零到一把它搭建出来。

可是，我们上面已经讲过，对于比较复杂的工作流，它的配置文件太大，冗余信息太多了，大模型难以一次性读懂读透澈。我看到有人也在尝试用Cursor对Dify工作流进行优化，但是实际效果却并不好。

那是不是暂时就没有比较简单又有效的办法来自动优化大型工作流呢？

我觉得还是有的：让大模型结合Mermaid工作流图和工作流配置文件一起，进行工作流优化或创建。

为啥这样能行得通呢？

首先，Mermaid图涵盖了工作流最关键信息，信息进行了充分压缩，少量字符就能表达很复杂的图形结构，结构信息非常明确，大模型容易透彻理解。

其次，修改或优化过的工作流配置，可以重新提取Mermaid图，并与原Mermaid（或大模型基于原Mermaid图进行优化后的Mermaid）进行对照、校核，极大提高优化结果准确性。

后续我会单独用一篇文章，结合实际例子来验证以上判断，暂时先不展开讲了。

3、工作流运行流程解析

第一阶段【问题初始化】

通过对话轮次判断（sys.dialogue_count），首次进入时由LLM分解用户问题，提取关键参数并生成首个回复。

通过sys.dialogue_count=0触发：变量赋值（n7）→ 问题分解LLM（n6）→ 参数提取（n8）→ 生成首问（n9）

第二阶段【渐进式信息收集】

分三轮对话（dialogue_count=1-3）依次处理预设问题，通过assigner节点记录每轮回答，构建研究基础数据。

分轮次处理：dialogue_count=1→问题2（n5）dialogue_count=2→问题3（n12）dialogue_count=3→问题4（n3）通过assigner节点（n30-n33）逐步记录回答

第三阶段【并行化内容精炼】

第4轮触发并行处理：Gemini模型提取核心主题，4个优化LLM同步精炼内容，输出研究方向和优化中间结果。

dialogue_count=4触发：主题提取LLM（n29）→ 输出研究主题（n34）4个优化LLM并行运作（n20-n23）→ 变量赋值节点（n10,n14-n16）存储中间结果

第四阶段【循环式知识拓展】

通过子主题分析LLM拆解4个维度，混合检索引擎（本地知识库+网络迭代搜索）获取细分领域数据

起始段LLM（n45）启动sub主题分析链（n2→n24→n25→n26）每个sub主题触发3级迭代搜索（n37→n42→n43→n44网络搜索）结尾段LLM（n46）衔接文档总结（n27）

第五阶段【条件化输出】

整合所有分析结果，由起始段/结尾段LLM生成首尾内容，经template-transform模板引擎格式化，最终输出万字级Markdown研究报告。

模板引擎（n27）根据搜索有效性分支：✅ 有效结果→生成最终报告（n13）❌ 无效结果→触发直接回复（n49）

4、结语

后面我会继续深入探索Dify DeepResearch，包括对它的补充、完善、优化，如扩充信源（本地文献、开源Firecrawl、百度和bing等）、工作流优化，以及Dify Agent 相关功能，欢迎持续关注。

53AI，企业落地大模型首选服务商

产品：场景落地咨询+大模型应用平台+行业解决方案

承诺：免费场景POC验证，效果验证后签署服务协议。零风险落地应用大模型，已交付160+中大型企业