目 录CONTENT

文章目录

不止于工作流构建器:LangChain 为什么不构建可视化工具的深层思考

青云TOP
2025-10-08 / 0 评论 / 0 点赞 / 1 阅读 / 0 字

📢 转载信息

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

原文作者:LangChain Blog


不止于工作流构建器:LangChain 为什么不构建可视化工具的深层思考

Not Another Workflow Builder

自 LangChain 诞生之初,我们收到的最常见的请求之一就是构建一个可视化的工作流构建器。但我们一直没有着手去做,而是选择让 LangFlow、Flowise、n8n 等第三方工具在我们的基础上进行开发。昨天 OpenAI 在 Dev Day 上发布了自己的 工作流构建器,这促使我们思考:为什么我们至今没有构建它?我们真正更感兴趣的是哪些不同但相关的发展方向?

核心问题界定

首先,有必要明确这些无代码工作流构建器旨在解决什么问题。它们的主要动机是让非技术人员也能够构建 Agent(智能体)。人们对此感兴趣主要有两个原因:

  1. 许多公司在工程人才方面的资源相对有限。
  2. 非技术人员最清楚他们需要构建什么样的 Agent,以及它们应该执行什么任务。

我们也偶尔看到其他动机,例如允许技术用户快速原型设计,然后将原型迁移到代码中。但为了本文的目的,我们假设其核心动机是:让组织内的每个人都能在无需工程团队支持的情况下,构建自己的应用和小工具。

工作流(Workflows)与智能体(Agents)的区别

我在上文中故意使用了“工作流”和“智能体”这两个词。我们之前也写过一篇文章——《关于如何思考 Agent 框架》(讽刺的是,这篇文章是为了回应一篇反对工作流的 OpenAI 文章)。

开发者社区基本上已经统一了对 Agent 的如下定义:

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

工作流能提供更高的可预测性,但牺牲了自主性;而智能体能提供更高的自主性,但牺牲了可预测性。**值得注意的是,在构建 Agent 系统时,我们追求的是“可靠地得到好的”结果,而这一点仅凭可预测性或自主性都无法保证。**

工作流通常很复杂——包含分支逻辑、并行执行、许多不同的路径。这种复杂性体现在工作流的“图谱”中,并以某种特定领域语言(DSL)表示。

智能体也可以包含复杂的逻辑,但相比之下,所有这些逻辑都被抽象为自然语言,并融入到提示词(Prompt)中。因此,Agent 的整体结构很简单(仅包含一个提示词 + 工具集),但这个“提示词”本身可能非常复杂。

OpenAI 的 AgentKit,以及 n8n、Flowise、LangFlow,本质上都是可视化的**工作流**构建器,而不是真正的**智能体**构建器。

可视化工作流构建器的问题所在

有了这些背景知识,可视化工作流构建器存在哪些问题呢?

1. 可视化工作流构建器的“门槛”并不低。

尽管它们是为大众受众设计的,但对于普通非技术用户来说,使用它们仍然不简单。

2. 复杂任务在可视化构建器中很快会变得难以管理。

一旦任务复杂性超过某个阈值(这发生得相当快),最终你就会得到一堆需要通过 UI 管理的节点和连线,场面一片混乱。

其他替代方案

我们的目标是创建能够产生可靠良好结果的 LLM 驱动系统(无论是工作流还是智能体)。人们可能希望用 LLM 系统解决的问题类型不同,复杂度从低到高不等。最佳的替代方案可能取决于问题的复杂度级别。

高复杂度:代码中的工作流

对于高复杂度问题,我们发现为了达到一定的可靠性水平,系统不能仅仅是纯粹的智能体,而需要涉及工作流的某些方面。这些高复杂度问题通常需要复杂的工作流。在需要大量分支、并行和模块化的情况下,代码是最佳选择(LangGraph 就是为此设计的)。

传统上,这意味着这类问题实际上无法通过非技术构建器来解决。然而,随着代码生成成本趋近于零,我们预计越来越多的构建者将有能力构建这些解决方案。

低复杂度:无代码智能体

对于低复杂度用例,我认为简单的智能体(提示词 + 工具)已经足够可靠地解决这些问题。以无代码方式构建这些智能体应该比以无代码方式构建工作流要简单。

随着模型越来越强大,我预计这些智能体能够解决的问题上限会越来越高。

两面夹击的困境(The Squeeze)

我认为无代码工作流构建器正遭受来自两个方向的挤压:

复杂度级别 最佳解决方案
无代码智能体
中等 无代码工作流
代码中的工作流

我认为创建(提示词 + 工具)形式的智能体在无代码方面应该比创建工作流更容易。我预计模型、Agent 框架以及我们创建、修改和教导这些智能体的界面都会变得更好。这意味着这些智能体将能可靠地完成越来越多的任务。

在另一个方向上,可视化工作流构建器在达到一定复杂度后会变得难以管理。在这种情况下,唯一的真正替代方案就是代码。编写代码历史上一直局限于少数人,门槛较高。随着模型在代码生成方面的能力越来越强,以及代码生成成本降至零,我预计转向代码的决策将变得越来越容易。

真正有趣的问题

明确地说——有些公司在普及 LLM 驱动的工作流构建器方面做得非常出色(例如 n8n、Flowise、LangFlow、Gumloop 等)。其中许多已经找到了产品市场契合点——它们解决了当下存在的真实问题,并赋能非技术用户构建出色的应用。

我认为世界不需要另一个工作流构建器。相反,我认为接下来真正有趣的问题在于:

  • 我们如何以无代码的方式更容易地创建可靠良好的智能体?这些应该是真正的智能体!而不是低代码工作流。
  • 我们如何让代码生成模型在编写 LLM 驱动的工作流/智能体方面表现得更好?



🚀 想要体验更好更全面的AI调用?

欢迎使用青云聚合API,约为官网价格的十分之一,支持300+全球最新模型,以及全球各种生图生视频模型,无需翻墙高速稳定,小白也可以简单操作。

青云聚合API官网https://api.qingyuntop.top

支持全球最新300+模型:https://api.qingyuntop.top/pricing

详细的调用教程及文档:https://api.qingyuntop.top/about

0

评论区