LangChain 不看好 OpenAI AgentKit：世界不需要再来一个 Workflow 构建器

在几天前的开发者大会上，OpenAI 发布了一套面向开发者和企业的完整工具集 AgentKit。其中，可视化画布 Agent Builder 用于创建、管理和版本化多智能体工作流，通过拖拽节点的方式即可编辑工作流。

LangChain 的创始人 Harrison Chase 最近又写了一篇博客文章，聊了聊他对于 AgentKit 的看法。Harrison 锐评，市场上不需要 AgentKit 这种「可视化工作流构建器」。

Workflow 和 Agent 的本质区别在于可预测性和自主性。Workflow 流程是固定的，有很多分支、并行的复杂逻辑，在可视化界面上就是各种节点和连接线；Agent 的逻辑被简化并抽象成自然语言，然后由 LLM 自己决定循环调用哪些工具来完成目标。

AgentKit 和市面上大多数类似工具，本质上都是在构建 Workflow，但不是真正的 Agent。

Harrison 认为，「可视化工作流构建器」正处在一个尴尬的位置，受到来自高、低两个方向的挤压：简单的任务用无代码 Agent 更方便，复杂的任务则必须用代码才能实现稳定可靠。

以下为文章原文内容，Founder Park 进行了编译微调。

原文链接：https://blog.langchain.com/not-another-workflow-builder/

超 15000 人的「AI 产品市集」社群！不错过每一款有价值的 AI 应用。

邀请从业者、开发人员和创业者，飞书扫码加群： 

进群后，你有机会得到：

• 最新、最值得关注的 AI 新品资讯； 
  

• 不定期赠送热门新品的邀请码、会员码；
  

• 最精准的AI产品曝光渠道

---

从 LangChain 项目启动第一天起，「可视化工作流构建器」就是最常收到的需求之一。但我们始终没有推进这项开发，而是选择让其他团队（如 LangFlow、Flowise、n8n）在我们的技术上进行构建。

昨天 OpenAI 在开发者大会（Dev Day）上推出了一款工作流构建器。借这个机会，我想聊聊我们为什么至今没有构建一个这样的工具，以及我们更关注、但不同的发展方向。

低代码 Workflow 要解决的核心问题是什么？

首先，有必要明确这类无代码工作流构建器要解决的核心问题。它们的主要目标是让非技术用户也能搭建 Agent，背后有两大核心原因：

• 许多公司在工程人才方面资源有限，难以支撑全团队的技术需求；

• 非技术用户最清楚需要搭建什么样的 Agent ，以及这些 Agent 应该实现哪些功能。

我们偶尔也会看到其他需求场景，比如技术用户用它快速搭建 Agent 原型，之后再把它转化为代码。但在本文中，我们假设核心需求是：让组织内的所有人都能独立搭建应用和组件，不需要依赖工程团队支持。

工作流与 Agent 的本质区别

我在前面特意使用了「工作流」和「 Agent 」两个术语。我们之前曾在一篇博文中讨论过二者的关系（有趣的是，那篇文章是为支持「工作流」而写，回应的正是 OpenAI 一篇反对「工作流」的文章。)

Founder Park 此前文章：

《Agents 和 Workflows 孰好孰坏，LangChain 创始人和 OpenAI 杠上了》

对「 Agent 」的定义，目前开发者社区已基本达成共识：

LLM Agent 通过循环调用工具来实现目标。

工作流以牺牲「自主性」为代价，换取更高的「可预测性」；而 Agent 则以牺牲「可预测性」为代价，换取更高的「自主性」。值得注意的是，搭建 Agent 系统的核心目标是实现「稳定可靠的良好结果」，但只靠「可预测性」或「自主性」都无法保证这一点。

工作流程通常很复杂，包含分支逻辑、并行节点和多条不同路径。这种复杂性会体现在工作流的「图谱」中，并通过某种领域特定语言（DSL）来呈现。

Agent 也可能包含复杂逻辑，但不同的是，这些逻辑都被抽象成自然语言，嵌入到 Prompt 中。因此， Agent 的整体结构很简单（只用「Prompt+工具」构成），尽管其中的「 Prompt 」本身有时也会相当复杂。

OpenAI 的 AgentKit，以及 n8n、Flowise、LangFlow 等工具，本质上都是「可视化工作流构建器」，而不是「 Agent 构建器」。

可视化工作流构建器存在哪些问题？

结合以上背景，可视化工作流构建器存在以下核心问题：

• 并不是「低」门槛：尽管目标用户是大众，但普通非技术用户使用起来仍然不轻松；

• 复杂任务难以管理：一旦任务复杂度超过某个阈值，且这个阈值很容易达到，界面上就会堆满节点和连接线，变得杂乱难管。

不同复杂度问题的解决方案

我们的核心目标是搭建「稳定可靠的 LLM 驱动系统」（无论是工作流还是 Agent ）。人们用这类系统解决的问题复杂度各异，从低到高不等，因此最佳解决方案也需要根据复杂度的不同来区分。

高复杂度场景：代码化工作流

对于高复杂度问题，我们发现要实现足够高的可靠性，系统不能是纯粹的 Agent ，而是需要融合工作流的部分特性。这类问题往往需要复杂的工作流支持，这个时候如果需要大量分支、并行处理和模块化设计，「代码」就是最佳选择（我们的 LangGraph 就是为了这个设计的）。

传统上，这类问题非技术人员无法解决。但随着代码生成成本逐渐降低，我们预计更多的构建者将发现自己能够构建这些解决方案。

低复杂度场景：无代码 Agent

对于低复杂度场景，我认为「简单 Agent 」（ Prompt +工具）的可靠性已足够解决问题。而且，用无代码方式搭建这类 Agent ，会比用无代码方式搭建工作流更简单。

随着 LLM 不断迭代，这类 Agent 能够解决的问题复杂度上限，也会持续提升。

无代码工作流构建器面临的困境

无代码工作流构建器面临的核心问题是：受到来自「低复杂度」和「高复杂度」两个方向的挤压。

用无代码方式搭建 Agent（ Prompt +工具），必然比搭建工作流更简单。而且随着模型、Agent 框架，以及「 Agent 创建、修改、训练界面」的持续优化，这些 Agent 能够稳定解决的任务会越来越多。

另一方面，当复杂度达到一定程度，可视化工作流构建器就会失控，这时候唯一的替代方案就是「代码」。编写代码在历史上一直局限于少数人，入门门槛相当高；但随着代码生成模型的优化和成本降低，选择用代码解决问题的门槛会越来越低。

未来的方向是什么？

需要明确的是：已经有不少公司在「 LLM 驱动工作流构建器」方面做得非常出色，比如 n8n、Flowise、LangFlow、Gumloop 等等。其中很多团队已找到 PMF，它们解决了当下的实际问题，也能让非技术用户创造出优秀的成果。

但我认为，世界上不需要再多一个「工作流构建器」了。相反，接下来更值得解决的核心问题是：

• 如何让用户更轻松地用无代码方式搭建「稳定可靠的 Agent 」。注意，是「 Agent 」，而不是「低代码工作流」；

• 如何优化代码生成模型，让它更擅长编写「 LLM 驱动的工作流/ Agent 」相关代码。