作者：Harrison Chase
LangChain 最初上线的那一天起，我们收到的最常见请求之一就是可视化工作流构建器。我们从未尝试过开发它，而是任由他人（如 LangFlow、Flowise、n8n）在我们之上进行构建。鉴于 OpenAI 昨日在 Dev Day 上发布了一个 工作流构建器，我认为探讨我们至今未曾开发此类产品的原因，以及我们更感兴趣的（但相关）不同方向，会是一件有趣的事情。
问题陈述
首先，值得明确的是，这些无代码工作流构建器所要解决的问题。主要动机是允许非技术用户构建代理。人们对此感兴趣主要有两个原因：
- 许多公司的工程人才资源比其他公司更为有限。
- 非技术用户最清楚应该构建什么代理 / 它们应该做什么。
我们偶尔也会看到其他动机，例如允许技术用户快速构建稍后将移植到代码中的原型代理。但就本文而言，我们假设其动机是让组织中的每个人都能在没有工程支持的情况下构建自己的应用程序和工具。
工作流与代理
我以上故意使用了“工作流”和“代理”这两个词。我们之前曾对此进行过讨论——实际上，在一篇 主张工作流的博客文章 中（讽刺的是，这是回应一篇反对工作流的 OpenAI 文章）。
开发者社区在很大程度上已经采纳了 以下代理的定义：
工作流在牺牲自主性的前提下提供更高的可预测性，而代理在牺牲可预测性的前提下提供更高的自主性。值得注意的是，在构建代理系统时，我们追求的是“可靠的良好”结果，而仅凭可预测性或自主性都无法保证这一点。
工作流通常很复杂——有分支逻辑、并行边、许多不同的路径。这种复杂性体现在工作流的“图”中，该图用某种 DSL 表示。
代理也可以包含复杂的逻辑，但相比之下，所有这些逻辑都被抽象成了自然语言，并包含在提示中。因此，代理的整体结构很简单（只需一个提示 + 工具），尽管这个“提示”本身可能相当复杂。
OpenAI 的 AgentKit ——以及 n8n、Flowise、LangFlow ——都是可视化的工作流构建器，而不是代理构建器。
可视化工作流构建器的问题
那么，有了所有这些背景信息，工作流构建器的问题是什么？
1. 可视化工作流构建器并非“低”门槛。
尽管它们是为大众用户设计的，但普通非技术用户使用它们仍然不那么容易。
2. 复杂任务会迅速变得过于复杂，难以在可视化构建器中管理。
一旦它们通过了某个复杂程度（这种情况发生得相当快），您最终会得到一团糟的节点和边，需要在 UI 中管理。
其他替代方案
目标是创建 LLM 驱动的系统（无论是工作流还是代理），这些系统“可靠地良好”。人们可能希望用 LLM 驱动的系统解决不同类型的问题——范围从低复杂性到高复杂性。最佳替代方案可能取决于复杂性级别。
高复杂度：代码中的工作流
对于高复杂度问题，我们发现为了达到一定的可靠性水平，这些系统不仅仅是纯代理，而是涉及工作流的某些方面。这些高复杂度问题通常需要复杂的工作流。在这些场景中，当您需要大量的分支、并行和模块化时，代码是最佳选择（LangGraph 就是为此设计的）。
传统上，这意味着这些类型的问题实际上无法由非技术构建器解决。然而，随着代码生成成本趋近于零，我们预计越来越多的构建者将能够构建这些解决方案。
低复杂度：无代码代理
对于低复杂度用例，我断言简单的代理（提示 + 工具）正变得足够可靠，可以解决这些用例。以无代码方式构建这些代理应该比以无代码方式构建工作流更简单。
随着模型越来越好，我预计这些代理能够解决的问题的上限会越来越高。
夹击
我认为无代码工作流构建器正受到来自两方面的夹击。
| 复杂度级别 | 最佳解决方案 |
|---|---|
| 低 | 无代码代理 |
| 中 | 无代码工作流 |
| 高 | 代码中的工作流 |
我认为，以无代码方式创建代理（提示 + 工具）应该比创建工作流严格来说更容易。我预计模型、代理连接器以及我们用于创建、修改和训练这些代理的接口将不断改进。这意味着这些代理将在越来越多的任务上表现出“可靠的良好”性能。
另一方面，对于一定程度的复杂性，可视化工作流构建器会变得难以管理。唯一的真正选择是代码。编写代码传统上仅限于少数人，其入门门槛相当高。随着模型在代码生成方面的能力越来越强，以及代码生成成本趋近于零，我预计选择代码会变得越来越容易。
有趣的问题
需要明确的是——有一些公司在普及 LLM 驱动的工作流构建器方面做得非常出色（n8n、Flowise、LangFlow、Gumloop 等）。他们中的许多人已经找到了产品市场契合点——他们解决了当今存在的实际问题，并赋予非技术用户构建出色事物的能力。
我认为世界不需要另一个工作流构建器。相反，我认为接下来有趣的问题是：
- 如何以无代码方式更轻松地创建“可靠的良好”代理？这些应该是代理！而不是低代码工作流。
- 如何让代码生成模型更擅长编写 LLM 驱动的工作流/代理？