传统Workflow与Multi-Agent workflow的区别

前端时间基于workflow的agent架构开始成为热点，随着技术的进一步演进，现在我们已经对此有了非常深刻的理解。

实际上，我们以前讲的workflow和基于workflow的agent存在巨大的区别。过去，我们设计workflow，非常大程度上依赖流程引擎，我们的流程引擎支持的能力，既决定了我们的开发设计，也决定了最终用户的体验。我们需要定义流程中的节点，通过编程的方式，调用它们，并且设计流程过程、逻辑跳转等，这些都需要代码来实现。一旦遇到复杂的情况，代码的实现就变得非常庞大。而真正影响的，则是开发体验和发布效率。

而AI时代的workflow，则依赖agent，或者说为agent设计workflow。此时，在开发体验上变得非常不同，我们不再依赖代码实现，而是依赖LLM的智能。我们不再主动分配流程逻辑跳转，而是让agent自动分配。这也就意味着，此时的流水线从整体形态上变得非常简单，agent就像一项工作中的多个角色，按照自己的能力完成任务，并根据情况，把下一个任务智能交给需要的agent。

然而，基于LLM的agent workflow有一个问题，即常有准确性不足的情况。由于LLM本身存在的问题，或者智能程度不足，它在分配下一个任务时，可能存在误差，甚至在判定自身的任务是否执行得当时，也存在误差，这也就意味着，agent可能提交了一份胡说八道的成果，还自以为是的发送它。这其实给一些严谨性强的工作带来风险。

因此，传统的workflow也是需要的。我们可以让agent作为传统workflow中的一项节点，对于流水线来说，agent像是一个黑盒，只提供了自己的能力，一个输入，一个输出，仅此而已。因此，当我们需要严谨性更强的工作时，可以考虑使用传统workflow+agent作为黑盒能力的方案。

这也就意味着，我们需要让我们的工作系统，既支持multi-agent workflow模式，也支持在传统workflow模式中把agent作为节点的能力。multi-agent本身实际上也是一个复合agent，因此，也可以作为传统workflow的节点。

实际上，我们只需要一个workflow形式，当workflow节点为agent时，节点的逻辑跳转由agent智能决定，而如果是普通功能节点时，按照流程引擎决定。在之前的文章中，我指出，无论是workflow也好，agent也好，我们都以服务的形式发布，以API的方式以最简单的形态提供给第三方应用调用。这使得我们对agent的使用更加简单。