不只是另一個(gè) Workflow Builder：LangChain 的不同選擇

發(fā)布于 2025-10-17 07:54

瀏覽

0收藏

在 AI 智能體開發(fā)領(lǐng)域，“可視化工作流構(gòu)建器（Visual Workflow Builder）”似乎成了新寵。當(dāng) OpenAI 剛剛發(fā)布 AgentKit，眾多工具如雨后春筍般進(jìn)入這一賽道時(shí)，LangChain 卻選擇了另一條路。
為什么我們始終沒有推出自己的可視化工作流構(gòu)建器？答案或許與你想的不一樣。

一、從 Day 0 開始的呼聲

自 LangChain 創(chuàng)立以來，我們收到最多的用戶請求之一，就是：“能不能出個(gè)可視化工作流構(gòu)建器？” 但直到今天，我們?nèi)晕赐瞥觯亲屍渌ぞ摺?strong>LangFlow、Flowise、n8n——在我們之上去構(gòu)建。

隨著 OpenAI 在 Dev Day 上推出 AgentKit，這一話題再次被推到聚光燈下。今天，我們想分享為什么我們至今沒有構(gòu)建這樣的工具，以及我們更感興趣的方向是什么。

二、問題定位：誰需要什么？

首先，明確一點(diǎn)：這些無代碼工作流構(gòu)建器（No-Code Workflow Builder）究竟在解決什么問題？核心動(dòng)機(jī)是——讓非技術(shù)用戶也能構(gòu)建智能體（Agent）。

這類需求的出現(xiàn)，通常出于兩個(gè)原因：

公司在工程人力上更為緊張；
非技術(shù)用戶往往最了解“應(yīng)該構(gòu)建怎樣的智能體、它該做什么”。

當(dāng)然，也有人將這些工具用于快速原型設(shè)計(jì)，再遷移到代碼中。但總體目標(biāo)相同： ?? 讓組織中的每個(gè)人都能獨(dú)立構(gòu)建自己的 AI 應(yīng)用，而無需依賴工程支持。

三、Workflows vs Agents：根本的思維差異

我們在一篇文章中曾為“工作流”辯護(hù)（諷刺的是，那是回應(yīng) OpenAI 一篇“反對工作流”的文章）。

社區(qū)普遍接受的 Agent 定義是：

?? An LLM Agent runs tools in a loop to achieve a goal.

簡單來說：

Workflow提供更高的可預(yù)測性（Predictability），但犧牲了自主性；
Agent擁有更強(qiáng)的自主性（Autonomy），但失去了可預(yù)測性。

而我們追求的，是“reliably good”——既穩(wěn)定又靈活的結(jié)果。

?? Workflows 通常具有復(fù)雜的分支邏輯、并行結(jié)構(gòu)和多路徑執(zhí)行，其復(fù)雜性被表示為一個(gè) DSL 圖結(jié)構(gòu)。 ?? Agents 則將復(fù)雜邏輯“隱藏”在自然語言 Prompt 中，雖然結(jié)構(gòu)簡單（Prompt + Tools），但語義豐富。

因此，無論是 OpenAI 的 AgentKit，還是 n8n、Flowise、LangFlow，它們本質(zhì)上都是可視化的 Workflow Builder，而不是 Agent Builder。

四、可視化工作流構(gòu)建器的兩大局限

1?? 并沒有真正降低門檻雖然號稱“人人可用”，但對于普通非技術(shù)用戶而言，依然需要相當(dāng)?shù)倪壿嬎季S與操作經(jīng)驗(yàn)。

2?? 隨著復(fù)雜度提升，系統(tǒng)變得難以管理一旦任務(wù)超過某個(gè)復(fù)雜度閾值（而這通常發(fā)生得很快），用戶就會(huì)陷入一張“節(jié)點(diǎn)與連線的蜘蛛網(wǎng)”，可視化反而成了障礙。

五、我們更關(guān)注的替代方案

我們的目標(biāo)不是“讓畫布更好看”，而是構(gòu)建可靠的 LLM 驅(qū)動(dòng)系統(tǒng)（LLM-powered Systems）。在不同復(fù)雜度下，最優(yōu)方案也應(yīng)不同：

?? 高復(fù)雜度任務(wù)：Workflow in Code

對于分支繁多、模塊化強(qiáng)的系統(tǒng)，代碼仍然是最優(yōu)解。例如 LangGraph，正是為這種高復(fù)雜度任務(wù)而設(shè)計(jì)。

過去這意味著“非技術(shù)用戶無能為力”，但隨著代碼生成成本趨近于零，越來越多用戶能“用自然語言生成代碼”，這正在改變一切。

?? 低復(fù)雜度任務(wù)：No-Code Agents

對于簡單場景，一個(gè)由 Prompt + Tools 組成的 Agent 就足以穩(wěn)定運(yùn)行。這類無代碼智能體的構(gòu)建方式，理應(yīng)比 Workflow 更簡單。

隨著模型能力持續(xù)提升，這類智能體的應(yīng)用上限也在不斷擴(kuò)大。

六、“中間層”的困境：被雙向擠壓的無代碼工作流

目前，無代碼 Workflow Builder 正在遭受“雙向夾擊”：

復(fù)雜度水平	最佳解決方案
低	無代碼智能體（No-Code Agent）
中	無代碼工作流（No-Code Workflow）
高	代碼中的工作流（Workflow in Code）

向下，智能體正以更高的可靠性和可教性逐步替代工作流；向上，代碼生成正迅速降低門檻，讓開發(fā)者更傾向直接編寫可維護(hù)的代碼。

這意味著，未來“畫圖式”的構(gòu)建方式將越來越難以在復(fù)雜任務(wù)中保持高效。

七、真正值得探索的問題

不可否認(rèn)，n8n、Flowise、LangFlow、Gumloop 等團(tuán)隊(duì)在 democratizing LLM-powered workflows 方面做得非常出色—— 它們確實(shí)幫助非技術(shù)用戶構(gòu)建出了許多優(yōu)秀的 AI 應(yīng)用。

但世界真的需要“又一個(gè) Workflow Builder”嗎？

我們認(rèn)為，更值得探索的方向是：