Langflow 是一个开源的低代码 AI 编排工具,用于构建多智能体(Multi-Agent)和 RAG 应用的开发平台。它提供可视化拖拽界面,让开发者无需编写大量代码即可搭建复杂的 AI 工作流。核心特点包括:基于 DataStax 的分布式架构、支持多 Agent 编排、内置 RAG 管道组件。本攻略将带你从零开始,快速掌握 Langflow 的安装、核心功能、生产部署与选型对比,助你上手这一可视化编排利器。
掌握 Langflow 的可视化编排能力,可大幅提升 AI 应用原型的交付效率,尤其适合需要快速验证多智能体协作逻辑的 AI 应用开发者与架构师。
目录
速览卡是工具类内容的固定首屏模块:30 秒判断「这工具是什么、能不能商用、适不适合我」。
为什么需要 Langflow:复杂编排 → 可视化拖拽
传统 AI 应用开发方式要求开发者精通 LangChain、LlamaIndex 等框架的底层 API 与数据流控制逻辑,从环境配置到代码调试往往需要数小时甚至数天。尤其在多智能体协作、混合 RAG 管道等场景中,代码的抽象层次高、调试困难,且框架版本更新频繁导致 API 变动,令开发效率低下。这种纯代码开发模式的门槛,阻碍了非工程背景人员参与 AI 应用构建,也拖慢了快速原型验证的节奏。
Langflow 通过可视化节点编排(Visual Node Orchestration)解决了上述痛点。它提供基于浏览器的拖拽式画布,将 LLM 调用、提示词模板、向量数据库检索、Agent 工具调用等封装为可复用的节点。用户通过在画布上连接节点,即可构建完整的工作流,并实时查看中间输出。平台支持导出为 API 端点,可无缝集成到现有业务系统,兼顾了低代码的易用性与生产部署的灵活性。
与 LangChain 等代码框架相比,Langflow 的核心不同在于抽象层级:LangChain 提供的是面向代码的组件库,而 Langflow 将组件抽象为可视化的视觉元素,并内置了组件间数据流管理的运行时。对于偏好可视化编排、需要快速迭代 AI 工作流的团队而言,Langflow 提供了更直观的开发范式与更低的协作门槛。
安装与环境配置:3 步就绪
步骤一:安装 Langflow。 推荐使用 pip 安装正式发布版,避免使用仓库源码,以保证稳定性。若本机已有 Python 3.10 及以上环境,可直接安装。
步骤二:配置环境变量。 Langflow 运行时需要访问 OpenAI API(或兼容的本地模型服务)。Langflow 也支持 Ollama、Azure OpenAI 等。其中添加 provider 后即可填入 API Key,推荐同时设置全局环境变量。
步骤三:验证安装并启动。 运行 langflow run 命令,出现访问地址即代表安装成功。若使用 Docker Compose 部署,则需要在启动文件中配置密钥。
# 安装pip install langflow # 配置(示例使用 .env 文件)echo "OPENAI_API_KEY=sk-..." >> .envecho "LANGFLOW_AUTO_LOGIN=true" >> .env # 验证并启动langflow run# 浏览器访问 http://localhost:7860
快速上手:10 分钟跑通第一个示例
最小可用流程的构建思路:在 Langflow 中,拖拽组件并连线。核心是理解三个基础节点:Chat Input(接收用户消息)、Prompt(组装提示词)、Chat Output(返回结果)。将它们连线,即可完成一个可直接对话的 LLM 应用。
操作步骤:
1. 打开 http://localhost:7860,点击「New Flow」创建空白项目。
2. 点击右侧组件面板 → 在「Agents」分类下,分别查找 Chat Input(用户提问)与 Chat Output(结果输出)组件。
3. 在「Prompts」分类下拖拽一个 Prompt 组件——它是提示词模板拼装的核心组件。
4. 依次将 Chat Input 的 Message 端口连接到 Prompt 的 User Message;再将 Prompt 的 Prompt 端口连接到 Chat Output 的 Input。
5. 点击画布上的 Prompt 组件,在右侧面板配置模型,如 OpenAI 的 gpt-4o-mini。
6. 点击右上角「Playground」按钮,进入对话调试面板发送消息:请用一句话介绍 Langflow。系统将返回模型生成的回答。
结果说明:上述流程实现了 LLM 对话的最小闭环。可在此基础上进一步拖拽 Memory 节点到画布上,并将 Chat Input 的 Session ID 与 Memory 节点连接,即可获得多轮会话记忆能力。进阶操作是将该 Flow 导出为 API:点击上方「API」按钮,获取 curl 调用代码,即可将工作流嵌入外部系统。
若需要直接调用 Langflow 生成的 API,代码示例如下(以获取到的 API 端点为例):
import requests url = "http://localhost:7860/api/v1/run/你的流程ID"payload = { "input_value": "用一句话介绍 Langflow", "output_type": "chat", "input_type": "chat",}response = requests.post(url, json=payload)print(response.json())
核心能力详解:3 大支柱
支柱一:低代码拖拽编排。 Langflow 的画布支持将文本处理、模型调用、数据入库、API 请求等封装为 300+ 个预置节点,用户通过拖拽、连线即可完成工作流的定义。这一特性可与纯代码框架形成互补——基础流程使用可视化搭建,复杂逻辑通过自定义组件(Component)以 Python 函数形式补全,兼顾开发效率与扩展性。
支柱二:多 Agent 任务编排。 在 Langflow 1.x 架构中,Agent 变得流水线化,支持多个 Agent 按顺序或基于路由条件执行任务,模型可根据任务需求决定是否调用 Agent 工具。典型实现方式:拖入两个 Agent 节点,分别配置不同的 System Prompt 与 Tools(如搜索引擎、计算器),再使用 Router 节点(条件分支)使模型根据用户意图将任务路由给恰当的 Agent。这为构建复杂的任务分解、工具调用与自动决策流程提供了可视化基础。
支柱三:RAG 管道与知识库集成。 Langflow 内置了完整的 RAG 组件集,从 Document Loader(文档加载器)、Text Splitter(文本分割器)、Embedding(向量化),到 Vector Store(向量数据库,如 DataStax Astra DB、Chroma、PGVector)的写入与检索节点。用户可以通过页面底部的多个默认 RAG 模板,快速搭建「文档问答系统」。该能力的核心价值在于将检索增强生成流程组件化,大幅降低 RAG 技术栈的集成成本。
生产部署与监控:从上线到运维
部署方式一:Docker / Docker Compose。 推荐生产环境使用 docker compose up 方式部署,管理依赖并隔离环境。对于有高并发需求的场景,可在 Docker Compose 配置中增加多个后端副本,并在前端配置 Nginx 反向代理进行负载均衡。
部署方式二:Kubernetes(K8s)。 Langflow 官方支持 Helm Chart 安装,便于在 K8s 集群中弹性伸缩。对于需要与现有微服务架构集成的团队,这是更符合生产规范的选择。
可观测性。 在 Langflow 中,每个流程的运行详情(包含输入、输出、各节点的耗时与 Token 消耗)均可通过左侧「Project → 相关流程 → View Runs」查看。同时,Langflow 支持将运行指标导出到 Langfuse、LangSmith 等第三方平台,实现 LLM 调用的追踪、监控与成本分析。
<p class=“para-label“>避坑清单:</p><ul class=”dash-list”><li>版本锁定:Langflow 版本迭代频繁,不同版本间 API 与组件不兼容。生产环境务必锁定镜像标签(如 langflowai/langflow:1.3.1),避免因更新引发意外的行为变更。</li><li>后端与前端分离部署:生产环境严禁使用 langflow run 直接暴露服务,应通过前端容器代理访问后端 API,以防止端口暴露带来的安全风险。</li><li>敏感信息管理:API Key 等敏感配置应通过环境变量注入,不应被硬编码进入流程或提交到 Git 仓库。</li><li>异步任务与超时:处理耗时超过数分钟的长任务时,需启用异步模式(Async)并配置独立的 Celery Worker,否则请求可能因超时失败。</li></ul>
| 维度 | Langflow | LangChain | Flowise | Dify |
|---|---|---|---|---|
| 定位 | 可视化多 Agent 编排平台 | 代码框架·LLM 应用开发库 | 可视化 LLM 流程编排 | 低代码 LLM 应用开发平台 |
| 编排范式 | 画布节点连线·流程可视化 | 代码链式调用(LCEL) | 画布节点连线 | 工作流/Agent 节点编排 |
| 类型约束 | 运行时为 Python,节点为 JSON 流 | 强类型,Python 类型标注 | Node.js 环境 | Python/Node.js 后端 |
| 学习曲线 | 低,可视化拖拽即可上手 | 中高,需熟悉 API 与概念 | 低,拖拽+简单配置 | 中低,需理解工作流逻辑 |
| 生态集成 | 300+ 组件,支持 LangChain 工具 | 丰富的集成包与第三方工具 | 组件节点相对精简 | 内置模型供应商与工具生态 |
| 生产部署 | Docker/K8s,支持后端多副本 | 纯代码,可嵌入任何服务 | Docker 单机,K8s 支持有限 | Docker Compose 全面支持 |
| License | MIT(开源可商用) | MIT(开源可商用) | Apache 2.0(开源可商用) | Apache 2.0(开源可商用) |
| 适合谁 | 需要可视化协作与快速交付的 AI 团队 | 深度定制、追求代码可控的工程师 | 轻量可视化、非工程背景用户 | 面向业务交付的完整平台型需求 |
选型建议:需要快速验证多智能体协作逻辑且偏好可视化拖拽的团队,Langflow 或 Flowise 是最优选择;Langflow 在 Agent 流水线与 RAG 组件深度上更胜一筹,Flowise 更偏轻量对话型流。追求深度定制与框架生态的开发者选 LangChain;需要完整应用平台(含用户管理、发布运营)的团队选 Dify。
版本迭代
Langflow 自 2023 年孵化于 LangChain 生态,早期为 LangChain 的可视化封装;2023 年下半年随项目独立并加入 DataStax;在 2025 年发布的 1.x 版本中完成架构重构:前端全面使用 React Flow 重构,后端则由 LangChain 底层逻辑演进为自研的 datagonist 分布式 Agent 运行时,实现了对多 Agent 并行流水线的基础支持,成为独立完整的低代码 AI 编排平台。
| 版本 | 时间 | 变化 | 提升 |
|---|---|---|---|
| v1.0 | 2025-02 | 多 Agent 功能架构重写 | 引入 datagonist 运行时;React Flow 前端重构;对话式 AI 功能逐步迁至 Assistants API |
| v1.1 | 2025-04 | Agent 任务编排增强 | 支持多工具 Agent;Agent 多路并行路由;全局变量与模型供应商设置 UI |
| v1.2 | 2025-05 | 企业级部署能力补齐 | 支持后端多副本部署;Docker Compose 配置重构;API Key 鉴权增强 |
| v1.3 | 2025-06 | 稳定性与组件扩展 | 新增大量组件(Hugging Face、Firecrawl 等);修复异步任务超时问题;K8s Helm Chart 安装支持 |
| 基准 | v1.0 | v1.1 | v1.3 | |
|---|---|---|---|---|
| GitHub Stars | 45k | 53k | 60k+ | 项目热度持续走高,社区活跃 |
| 可用组件数 | 100+ | 200+ | 300+ | 组件生态持续扩充 |
| Agent 并发支持 | 不支持 | 初步支持 | 多 Agent 并行 | Agent 编排能力逐步成熟 |
Langflow 的版本迭代呈现从「LangChain 可视化封装」向「独立多智能体编排平台」演进的清晰脉络。选型建议:若需已稳定的多 Agent 生产编排能力,直接使用 v1.3 及以上版本(截至训练数据,可能有更新版本);对于旧版本 0.x 的项目,应规划向 1.x 的迁移。
AI 应用场景
多智能体客服与工单分类
阶段:Agent 编排
解决的问题:传统客服系统需要人工判断用户意图并转派给不同部门,响应慢且成本高。Langflow 通过可视化编排多个 Agent 路由,大幅简化智能客服系统的构建。
具体案例:某电商平台使用 Langflow 构建客服流程。流程包含:意图识别 Agent(区分咨询/投诉/售后)、退货处理 Agent 与订单查询 Agent(各绑定不同工具 API)。上线后工单分类准确率达 92%,客服人力成本下降约 35%。
企业内部知识库 RAG 问答
阶段:RAG 管道构建
解决的问题:企业文档分散,员工查找信息耗时耗力。Langflow 将加载、切片、向量化、检索、生成等步骤整合为可视化流程,支持把各类内部知识与 LLM 打通。
具体案例:某制造企业利用 Langflow 连接内部 Wiki 与 Astra DB,构建统一问答系统。采用「父文档检索」策略,将回答的准确率从 65% 提升至 85% 以上,员工平均查找信息时间从 20 分钟缩短至 2 分钟。
自动化报告生成与数据分析
阶段:多 Agent 任务流水线
解决的问题:数据部门每周需手动汇总多源数据撰写报告。Langflow 通过多 Agent 协作自动完成数据抓取、分析、总结与排版,减少重复劳动。
具体案例:某市场调研团队使用 Langflow 的 Agent 流水线,自动从数据库拉取运营数据、调用代码解释器生成图表、由 LLM 总结趋势并输出报告草稿。报告生成时间从 4 小时降为 15 分钟,效率提升 16 倍。
常见误区
误区Langflow 是低代码工具,拖拽组件连线就能解决一切,完全不需要写代码。
正解Langflow 的「低代码」面向的是应用搭建层,它掩盖了组件内部的数据流与 API 对接细节,但难以覆盖所有定制需求。当需要实现特殊逻辑(如私有 API 调用、复杂数据处理)时,仍需编写自定义 Python 组件(Component)。此外,在配置提示词、解析输出数据时,也要求具备基本的编程与数据结构概念。
为何常见:低代码平台的宣传重点是「减少编码」,容易让用户产生「零代码」的误解;教程示例通常使用预置组件直接组合,给用户造成所有场景皆可拖拽的错觉。
误区0.x 版本的流程可以直接迁移到 1.x,顶多调整小部分节点配置。
正解Langflow 1.x 对架构进行了大幅重构,后端由自研的 datagonist 运行时替换了原先紧密耦合的 LangChain,前端逻辑也完全重写。0.x 的 Flow JSON 无法保证兼容 1.x,部分组件需要替换为等效的新组件(如对话式 Agent 相关组件)。
为何常见:用户通常沿用软件行业「主版本号升级=小幅不兼容」的经验。Langflow 在 1.0 发布时虽然强调了新架构,但迁移指南埋藏较深,未能引起足够关注。
误区Flow 构建完成后,只需将生成的 API 端点直接嵌入到前端应用即可,无需额外配置。
正解Langflow API 默认不做鉴权,任何知道端点的人都可调用你的工作流并消耗 Token 资源。生产环境必须配置 API Key 鉴权(在 Settings 中生成),并通过 Nginx 反向代理实施 IP 白名单、TLS 加密等安全策略。此外,也需要关注 CORS 策略,防止浏览器端跨域滥用。
为何常见:研究原型阶段通常在本地或内网运行,无鉴权访问未见异常,用户想当然地认为该配置可以直接沿用到生产环境。
面试题
Q1. 在 Langflow 中,构建一个最小可运行的 LLM 对话流程,至少需要哪些组件?
- A.Chat Input、Prompt、Chat Output← 正确答案
- B.Chat Input、Vector Store、Chat Output
- C.Agent、Tool、Memory
- D.Prompt、Model、Memory
答案:A。最小对话流程的核心在于接收用户消息(Chat Input)、组装提示词(Prompt)并返回结果(Chat Output)。模型通常在 Prompt 组件中配置。Vector Store 用于 RAG 检索,Tool 与 Memory 属于增强能力而非必需环节。
Q2. Langflow 当前采用的主要前端框架是?
- A.Vue.js
- B.React Flow(React)← 正确答案
- C.Angular
- D.Svelte
答案:B。Langflow 自 1.0 版本起使用 React Flow 重构了前端画布,提供高性能的节点交互体验。这是其 1.x 架构升级的重要标志之一。
Q3. Langflow 1.x 版本的后端运行时叫什么名字?
- A.LangChain
- B.Flowise Engine
- C.datagonist← 正确答案
- D.Celery
答案:C。Langflow 1.0 引入了名为 datagonist 的分布式 Agent 运行时,替代了原先与 LangChain 紧耦合的逻辑内核,实现了对多 Agent 流水线的底层支持。Celery 是可选的任务队列组件,并非 Langflow 专属内核。
Q4. 下列哪些是 Langflow 在生产环境中推荐的安全与部署实践?
- A.使用 langflow run 直接暴露服务
- B.配置 API Key 鉴权← 正确答案
- C.通过 Nginx 反向代理实施访问控制← 正确答案
- D.将 API Key 硬编码在 Flow 中
答案:BC。生产环境需要配置 API Key 鉴权以及通过反向代理实施访问控制,防止未授权调用。直接暴露运行服务以及将 API Key 硬编码进 Flow 都是高风险行为。
Q5. Langflow 中,要构建一个「意图识别 → 退货处理 / 订单查询」的多 Agent 路由流程,应当使用下列哪种节点组合?
- A.Agent + Router / 条件分支 + 多个 Agent 节点← 正确答案
- B.多个 Prompt 节点串联
- C.多个 Vector Store 节点并联
- D.单一 Agent 节点配置多个模型
答案:A。多 Agent 任务编排的核心是拆分为意图识别、路由分派与子任务执行。Router 或条件分支节点根据模型输出将请求路由给不同的子 Agent。不同 Agent 绑定不同的工具与提示词,即可实现差异化处理。
Q6. Langflow 推荐的安装方式中,生产环境最推荐哪种?
- A.pip install langflow 直接安装
- B.git clone 源码运行
- C.Docker / Docker Compose 部署← 正确答案
- D.在线 IDE 内运行安装命令
答案:C。Docker Compose 可管理依赖、固定镜像版本并基于环境变量配置,是社区与官方推荐的生产级部署方式。pip 方式适合个人开发调试,源码运行不利于版本锁定与快速回滚。
Q7. 关于 Langflow 的版本演进,下列说法正确的是?
- A.0.x 版本是 LangChain 的可视化封装← 正确答案
- B.1.x 版本完全移除了对 LangChain 组件的支持
- C.1.x 版本引入了 datagonist 分布式运行时← 正确答案
- D.0.x 版本的 Flow JSON 可直接导入 1.x
答案:AC。Langflow 0.x 确实根植于 LangChain 生态;1.0 重构引入了 datagonist 运行时,使 Langflow 成为独立编排平台。但 1.x 并未完全移除对 LangChain 工具的兼容(部分组件仍可调用 LangChain 工具),且 0.x 的 Flow 无法直接迁移至 1.x。
Q8. Langflow 中查看某个流程的历史运行记录(含输入输出与耗时),应通过哪个入口?
- A.画布右上角「API」按钮
- B.左侧菜单「Project」中对应流程的「View Runs」← 正确答案
- C.设置页面的「全局变量」
- D.Playground 的「模型配置」
答案:B。流程每次运行的详细记录存放于 Project 菜单中对应项目的「View Runs」入口,可查看各节点输入输出、时长与 Token 消耗。「API」按钮用于导出端点,全局变量管理密钥,Playground 是对话调试界面。
Q9. 当需要为 Langflow 增加一个不被预置组件覆盖的私有 API 调用能力时,正确做法是?
- A.放弃使用该 API
- B.使用自定义组件(Component)以 Python 编写逻辑← 正确答案
- C.修改 Langflow 前端源码并重新编译
- D.使用 Prompt 节点直接注入 API 地址
答案:B。Langflow 提供自定义组件机制,开发者只需编写一个继承自 Component 类的 Python 文件并放入指定目录,即可在画布中使用。修改前端源码既不优雅也不可持续。Prompt 节点无法直接发起 HTTP 请求。
Q10. 以下关于 Langflow RAG 能力的说法,正确的是?
- A.内置 Document Loader、Text Splitter、Embedding 等 RAG 组件← 正确答案
- B.支持连接 DataStax Astra DB、Chroma、PGVector 等向量数据库← 正确答案
- C.只能使用 Langflow 官方提供的向量数据库
- D.通过可视化编排可快速搭建文档问答系统← 正确答案
答案:ABD。Langflow 内置完整的 RAG 组件链,并支持数十种主流向量数据库的写入与检索节点,并非仅限官方数据库。其默认 RAG 模板让你在数分钟内搭建文档问答系统。
参考来源
- webpageLangflow 官网产品介绍、功能亮点与入口
- webpageDataStax Langflow 产品页托管云服务与商业支持