昨天看到 LangChain 团队创始人 Harrison Chase 发布的一篇文章，标题是《Not Another Workflow Builder（不只是另一个工作流构建器）》。
这篇文章讨论了一个颇有争议但又很现实的话题：
"为什么 LangChain 不做可视化工作流构建器？"
读完之后我觉得，这不仅仅是关于一个功能是否值得开发的问题，更是一次关于 AI 应用开发范式转变 的思考。
于是我结合原文，以及我和 ChatGPT 的一些讨论，整理了这篇文章，希望能帮助更多人理解"工作流"与"智能体（Agent）"在未来 AI 架构中的位置与关系。
《不只是另一个工作流构建器》 原文翻译
LangChain 自诞生以来，我们最常收到的请求之一，就是希望推出一个可视化工作流构建器（visual workflow builder）。 我们一直没有这么做，也观察了其他公司（如 OpenFlow、Flows.io 等）在做类似的事情。
昨天，OpenAI 推出了他们的 workflow builder（工作流构建器），因此我觉得这正是一个合适的时机，来聊聊为什么我们到现在还没有做这件事，以及我们更感兴趣的不同方向。
问题陈述
首先，我们需要明确无代码工作流构建器要解决的问题。 主要动机是让非技术用户也能使用或创建智能体（agents）。
这里其实存在两类主要动机：
- 许多公司在工程人才上的资源有限。
- 非技术用户往往更清楚自己想要构建什么，或想要实现什么。
有时，我们也看到第三种动机：让技术人员能够快速原型化 agent，或者让团队中不同角色能够协作。 但本文的重点在于：帮助非工程人员能够快速构建 AI 应用和工作流。
工作流 vs 智能体
我们之前在另一篇文章《arguing for workflows（为工作流辩护）》中讨论过这个话题（那篇文章其实是回应 OpenAI 的一篇文章，题为《arguing against workflows（反对工作流）》）。
开发者社区目前大体上达成了一个共识： Agent 的定义是：
一个 LLM 智能体通过循环使用工具来实现目标。
工作流带来的是更高的可预测性 ，但以牺牲自主性为代价； 而智能体提供的是更高的自主性，但可预测性较低。
换句话说，在构建 agent 系统时，我们追求的是高质量结果，而不是可预测性或自主性本身。
工作流通常包括复杂的分支逻辑、条件路径、不同的执行分支------这种复杂性通常以某种"图形化语言（DSL）"表示。
而智能体虽然也能表现出复杂行为，但它的逻辑被压缩成一种自然语言的提示（prompt）形式。 智能体的"图"只有一个节点，就是 prompt 本身。
OpenAI 的 Aptentive、以及 Flows.io、LangFlow、Flowise 等，都是可视化工作流构建器，不是智能体构建器。
可视化工作流构建器的问题
那么问题是： 既然可视化工作流构建器很直观，为什么它们仍然存在明显的局限？
主要有两个方面：
-
它们的"上手门槛"其实并不低。 尽管是为大众设计，但对非技术用户来说，创建一个结构化的工作流仍然不容易。
-
一旦复杂度提升，管理就会变得非常困难。 可视化节点图在节点数量变多后变得难以维护。 一旦超过一定复杂度，界面管理、逻辑跟踪和调试都非常困难。
其他替代方案
我们看到一些公司尝试用不同的方式来实现"工作流"或"智能体"的目标。
这些方案大体可以分为两类：
1. 高复杂度问题：在代码中实现工作流
当需要极高的可靠性时，我们发现工程师往往不会仅仅"调用智能体"，而是将 agent 嵌入到更大的工作流中。
这种高复杂度场景通常涉及分支逻辑、并行执行、多模态输入输出等，这类情况最适合直接在代码中实现。 （这其实正是 LangGraph 的设计目的。）
换句话说，这类系统已经超出了"无代码"工具的能力范围。
2. 低复杂度问题：无代码智能体
对于低复杂度的使用场景，构建简单的智能体（一个 prompt + 一些工具）已经足够。 让这些简单智能体通过无代码界面创建，比通过可视化工作流构建器更简单、更直观。
随着模型能力的提升，这类智能体能够覆盖的用例范围也越来越广。
挤压效应
我们观察到，可视化工作流构建器其实正被"两头挤压"：
| 复杂度等级 | 最佳解决方式 |
|---|---|
| 低 | 无代码智能体 |
| 中 | 可视化工作流 |
| 高 | 代码中的工作流 |
我认为智能体（prompt + 工具）应该是更自然的无代码方式。 它们更轻量、更智能、扩展性更好。
同时，随着模型变得更强，能自动生成更复杂逻辑，代码工作流的门槛也在降低。 当高端和低端的解决方案都在进化时，**中间那层"可视化工作流"**反而逐渐变得多余。
有趣的问题
要明确一点： 目前已经有很多公司在构建 LLM 驱动的可视化工作流工具方面做得非常好（如 Flows.io、Flowise、LangFlow、Gumloop 等）。 它们都找到了自己的市场契合点，帮助了很多非技术用户构建出色的产品。
但我认为，世界并不需要"又一个工作流构建器"。 相反，我们需要思考两个更有趣的问题：
-
我们如何在无代码环境中让人们更容易创建优秀的智能体？ 这应该是"无代码智能体（no-code agents）"的方向，而不是"无代码工作流"。
-
我们如何在创建 LLM 驱动的智能体系统时，让代码生成模型更高效、更精准？
结语
我相信未来的方向，不是继续堆叠"可视化节点"，而是让智能体更易于创建、更高效地自我编排、并在需要时自动生成代码。
原文摘要
Harrison Chase 在文章中主要表达了几个核心观点：
-
LangChain 不做可视化工作流构建器，因为那并不是他们认为的未来方向。
-
工作流的局限性：
- 对非技术用户来说，真正好用的可视化流程仍然不易上手；
- 当系统变复杂时，流程图的可维护性迅速下降；
- 因此它不适合长期扩展和演进。
-
替代思路：无代码智能体（No-Code Agent）
- 对于低复杂度任务，直接通过 prompt + 工具的组合， 就能实现原本需要工作流才能完成的事情；
- 随着模型变得更强，智能体可以自主决策、灵活调用工具， 更符合用户的自然使用方式。
-
高复杂度问题应当回到代码层解决，比如用 LangGraph 等框架来实现稳定、可控的流程逻辑。
-
最终结论是：
"世界不需要另一个工作流构建器，而需要更容易创建、更自然的无代码智能体系统。"
我的理解与思考
Harrison 的文章其实反映出一个清晰的趋势：
AI 应用的开发方式正在从"流程驱动"走向"语义驱动"。
但我认为在现实落地层面，这个变化是渐进的 ，而非取代式的。 不同复杂度的场景，需要不同的解决方式。
（1）不同复杂度的最佳实现方式
| 复杂度 | 实现方式 | 特点 | 适用场景 |
|---|---|---|---|
| 高复杂度 | 代码实现（LangGraph 等） | 完全可控、可维护 | 企业级系统、复杂业务 |
| 中复杂度 | 可视化工作流 | 快速验证、逻辑清晰 | 原型、MVP、验证阶段 |
| 低复杂度 | 无代码智能体 | 自然语言驱动、轻量 | 自动化任务、助手型应用 |
我同意作者的一点：
高复杂度场景必须代码化，这样才能获得稳定性和扩展性。
但我也认为：
中复杂度的"可视化工作流"依然是最好的原型验证工具。 它可视、可调试、可协作，在业务快速试错阶段非常高效。
当系统逐步稳定后，确实应当迁移到代码化实现，这也是工作流"被挤压"的合理现象。 这不是被淘汰，而是生命周期的自然演进。
（2）"被挤压"的中复杂度层
作者提到"工作流被两头挤压" ------ 低端被智能体替代，高端被代码吸收。
我认为这在逻辑上是正确的，但需要一点语境补充：
工作流的使命本来就不是终局，而是"过渡层"。
一个典型的产品流程是：
- 产品经理用可视化工作流快速验证思路；
- 验证通过后，工程师用代码重构；
- 最终再把这套能力封装成模块，给非技术用户用。
因此，工作流并没有被"挤死"，而是在整个 AI 产品生命周期中承担着重要的"中转站"角色。
（3）Agent：理想与现实之间
作者在文中提出：
"未来低复杂度任务将由 Agent 来取代工作流。"
我部分同意。 Agent 确实更符合人类直觉------我们希望"告诉 AI 目标"，而不是"画流程图"。 但这里有两个关键的现实问题需要解决：
① Agent 的搭建形式
Agent 是怎么被创建的？
- 直接写 prompt？
- 还是拖拽配置工具？
- 还是自然语言指令生成逻辑？
对非技术用户来说，这一步依然需要一个友好的界面层。 它可能不是"节点+连线"的工作流，而是一个语义工作流（Semantic Workflow）。 所以，Agent 的可视化只是换了一种形态。
② 工具生态的依赖
Agent 的强大在于它能调用工具（Tools）。 但这些工具谁来提供？如何接入？
这就需要平台生态的支撑。 随着像 MCP（Model Context Protocol）这样的标准逐渐出现，我们也许能让不同平台的 Agent 共享一套标准工具集。 届时，Agent 才真正具备"无代码"的现实可能。
（4）未来的方向：智能体化的工作流
我相信未来不会是"Agent 完全取代工作流"，而是二者的融合。
未来的形态可能是这样的：
- 用户用自然语言描述目标；
- 系统自动生成内部工作流和工具调用逻辑；
- 用户依然能在界面上查看、理解、调整执行路径。
这就是所谓的「语义化工作流」。 它结合了 Agent 的灵活性与工作流的可控性，既让系统能理解"意图"，又让人类能控制"过程"。
四、结语：AI 应用开发的"语义时代"
回头再看 LangChain 的选择，其实是有战略前瞻性的。 他们不是在拒绝"可视化工作流"，而是在思考下一个时代的开发范式。
未来的 AI 应用，可能不再是"写代码"或"拉流程"，而是**"说出逻辑"**。
人类用语言描述目标，模型用逻辑生成执行路径，工具生态负责提供能力。
工作流不会消失，它只是从"显式的图形"变成"隐式的语义"。 当我们再谈"无代码"，它可能意味着------连逻辑都能自动生成。
📘 最后
这篇文章既是对 LangChain 团队理念的理解，也是我自己对智能体生态的一些思考。 如果你也在构建智能体、使用 Dify、LangFlow、LangGraph 等工具，也许能从这个角度重新思考：
我们到底需要什么样的"无代码"？ 它真的只是拖拽节点，还是让智能体帮我们拖拽逻辑？