为了方便理解，我画了一个最简单的工作流作为案例示意：
在理解这两个概念之前，我们要先理解这个工作流到底在干嘛：
我们是希望用户输入一个关键字之后，用llm写文章。
此时，我们再细分这个需求。既然要写文章，文章本身是有结构的，示例图中将文章的结构拆成：标题、摘要、主要内容、文章配图四个部分。
这四个部分都是来自开始节点，但是各自又互不影响，所以能各自工作，在并发的过程中，这四个任务可以同时进行。等并发结束之后，我们设计了一个模板转换节点接收他们的返回值，用于文章全文的拼接，最后用回复节点展示全文。
从上面的示意图，你也看到了，右边还有一个绿框，那是因为生成文章配图的时候，我们需要用到一个“文生图”自定义工具。但是我们选用这个工具之前就知道，这个工具是先提交作图提示词，然后它才能工作，但是它的工作原理是异步，也就是说，你第一次提交了提示词，它返回的是一个任务的ID，那么你可以通过另外一个节点，获取到这个ID之后，再请求生图的结果。在这个过程中，这是工作流串行的，也是异步的。这个本示例中，文生图是不需要并发的，因为我们只做一个文章配图就行，如果你是多个配图，依然可以继续并发。
特别说明：
截止到2024.09.05，dify的0.8测试版本需要你自己部署使用，官方的仓库并没有更新到这个版本，你可以使用官方说明的分支仓库进行体验。言外之意就是，如果你是本地部署的，dify版本低于0.8版本，你无法使用并发任务功能。
我理解中的dify异步理念
第一种：文生图类的需要异步获取结果的场景
上面的示意图就已经说明这个场景了。你先提交生图的任务，获取一个任务ID，然后再提交这个ID，获取图片地址。
这个在很多文生图的Ai创作平台能见到。它与我们在dify的工作流中，直接找某个节点实现异步不太一样。如果你有编程经验，我猜测，你第一想法就是：为什么文生图的时候，不能同时写好获取图片地址，为什么这些不是在一个节点执行完成。
这就不得不说说dify的基础工作原理：整个工作流从开始节点开始，后面不管有多少个节点，都是串行工作，每个节点单独负责自己的那一块，除非你在代码节点中，自己尝试手搓异步逻辑代码，否则是没办法在一个节点中实现异步多任务。
在设计层面，我个人认为，dify的工作流就是一个积木平台，你想要实现异步，就通过拼接一个个节点来模拟实现。
第二种：dify的自定义工具
dify的自定义工具是我认为最能体现文生图这种异步需求的设计了。
首先我必须得说一下，我猜测肯定有一些dify的同学把这个工具理解错了，认为这就是一个工具，其实不是，你在dify中创建了一个自定义工具，其实本质上是创建了一个自定义工具集。
我知道大家为什么会有这种错误的理解，因为我们大多时候创建一个自定义工具，这个工具里面只有一个具体的工具，下意识就认为dify的工具其实就是一个工具。
这种情况的正确理解是：你创建了一个工具集，例如名字叫：imgai。假设这个工具是AI文生图服务。一般情况下，AI文生图服务如果是异步的，会具备如下三个子服务：文生图、图生图、获取结果。
这三个子服务都能通过openapi-swagger全部写到dify中。那么你一定会发现，imgai这个工具集下，出现了三个对应的子工具。
其实当你到工作流中使用你刚创建的AI文生图工具时，你一定会发现，你增加了一个文生图，其实是imgai这个工具集的文生图子工具。说直白了，工作流中添加的任何工具，都是对应工具集下的子工具，你不可能在一个工具节点中，一下子把多个子工具的工具集全部使用了。
为了方便dify初学者理解，请看下方示意图：
这个就是我创建的一个名叫mazeguru的工具集，这个工具集下有三个具体的子工具。（为了方便理解，你就认为它是子工具就行了，免得到时候自己又绕糊涂了。）
那么，我既然工具集有了，我想在工作流中使用的时候体现呢？请看下方示意图：
一个工具节点，对应的就是一个具体的子工具。这样一个流程下来，就符合AI文生图平台的异步任务了，每个环节都对应上了。
粤ICP备14082021号
免费POC，
零成本试错
