探索Dify开源工作流，解锁本地与Web混合搜索新技能。
核心内容：
1. Dify内置DeepResearch工作流的开源实现与本地信源导入问题
2. 工作流图解析的挑战与Mermaid代码的应用
3. 大模型解析工作流配置文件的尝试与效果展示

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

在之前的文章里，我们对Dify内置的DeepResearch工作流进行了详尽拆解与实测体验。坦白说，不足之处相当明显。例如，信源配置过于单一，仅支持Ta vily一种输入。最令人困扰的是——它根本无法检索本地文献。今天，我们换个角度，聚焦另一个开源方案——Open-Deep-Research-workflow-on-Dify。这个项目恰好击中了痛点，有效解决了本地信源的导入难题。

该工作流是对DeepResearch的复现，但官方并未说明参考了哪个具体项目。翻阅作者GitHub首页后发现，其关注了一个名为open-deep-research的开源项目。点进去一看，原来是Firecrawl的创始人打造的。其实两周前我就已在本地部署了Firecrawl，只是尚未集成，看来之前的判断没错——它确实能与DeepResearch结合使用。

不过，open-deep-research本身并不具备搜索本地资源的能力。从其演示视频来看，流程与Open-Deep-Research-workflow-on-Dify也存在差异。今天暂不展开讨论那个项目，集中精力剖析这个工作流的具体实现细节。

2、工作流解析成Mermaid代码

工作流图如下所示。老实说，这类图看起来实在令人眼花缭乱——用户自由拖拽的随意性太大，部分节点还做了折叠处理。即便使用“整理节点”功能调整过后，可读性有所改善，但作者设置的标注信息容易错乱。加之画布采用横向布局，常常超出屏幕显示区域，想要一目了然读懂全貌，非常困难。

那么，是否存在更友好的方式，能够让我们获取一眼就能理解的工作流图呢？

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

此前曾尝试让大模型（DeepSeek-V3-0324）直接分析工作流配置文件，并生成Mermaid图形代码。这次再次进行试验，效果如下。将生成结果与原图部分截图对比后发现，大模型产出的工作流图并不完全准确——它错误地将工作流中部的关键串行结构识别成了并行结构。

为何会产生如此大的偏差？主要原因有两个：

• 首先，配置文件过大，多达3401行，约9.7万个字符。要从如此庞大的字符中梳理出完整的图结构信息，难度可想而知。
• 其次，配置文件中包含大量冗余字段，节点关系极易被混淆。

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

为了解决上述问题，目前能找到的最优方案就是用代码进行解析。直接呈现代码解析结果：

# Deep Researcher On Dify 工作流图

```mermaid
graph 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图，并与原图（或大模型基于原图优化后的结果）进行对照和校核，从而大幅提升优化结果的准确性。后续会单独用一篇文章，结合实际案例来验证这一判断，今天暂不展开。

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相关功能。