Langflow

Langflow 是一款用于可视化构建 AI 流水线的开源低代码平台。它由 Rodrigo Nader 和 Gabriel Freitas Almeida 于 2023 年作为其咨询公司 Logspace 的一部分创建，最初是作为 LangChain 之上的图形层，让开发者可以将组件拖放到画布上，而无需从头开始编写链。DataStax 于 2024 年 4 月收购了 Logspace，随后 IBM 于 2025 年 2 月宣布收购 DataStax，这为 Langflow 提供了全球最大企业软件公司之一的资金支持，同时保持其基于 MIT 许可证的核心完全开源。

该平台涵盖了 AI 应用程序构建的整个生命周期：通过 PDF 或 Web 加载器摄取文档，使用您选择的嵌入模型对其进行分块和嵌入，将向量存储在 Astra DB 或任何受支持的向量存储中，将检索器连接到 LLM，并将整个流水线部署为 REST API，所有这些都在一个画布上完成。1.8+ 版本的当前功能包括 MCP（Model Context Protocol）客户端和服务器支持、用于本地开发的桌面应用程序、使用 IBM 开发的 CUGA Agent 组件进行企业任务自动化的多智能体编排、用于单步追踪的 LangSmith 和 Langfuse 集成，以及允许单个流程保持多个独立对话历史记录的内存会话管理器。它支持所有主要的 LLM 提供商：OpenAI、Anthropic、Google、Mistral、AWS Bedrock，以及通过 CometAPI 连接器支持的数百个其他提供商。

2026 年 5 月的 Langflow 实际功能

Langflow 的核心模型是一个基于节点的画布，其中每个组件（LLM 调用、检索器、Web 搜索工具、Python 代码块）都是一个具有类型化输入和输出端口的可拖拽节点。您可以将节点连接在一起形成一个流程，在内置的游乐场中对其进行测试，使用输出可视化工具（Output Visualizer）检查每一步的输出，然后将其部署为 API 端点或将流程导出为 JSON 文件。自 1.0 版本（2024 年 6 月）以来，画布已经超越了预构建组件库，转向了“制造工厂”模型：任何带有正确装饰器的 Python 类都可以成为可共享、可重用的 Langflow 组件。

2025 年 12 月发布的 1.7 版本引入了 MCP Streamable HTTP 支持，这意味着任何 Langflow 项目都可以作为 MCP 服务器公开，Claude Desktop、Cursor 或任何外部智能体等工具都可以直接调用它。1.8 桌面应用程序将完整的构建器引入了本地 Electron shell，消除了独立开发时运行服务器的需要。智能体组件得到了显著扩展：ALTK Agent 通过基于 SPARC 的验证和智能 JSON 后处理改进了工具调用，而 CUGA Agent 则通过内置的任务规划、Web 浏览和自定义代码执行来处理多步企业自动化。Webhook 身份验证、用于 RAG 文档输入的 AWS S3 文件存储以及用于将任务路由到正确模型的 LLM Selector 组件完善了当前的功能集。

Langflow 的 RAG 工作流是其最强大的用例。连接文档加载器（PDF、Web 抓取、S3 文件）、文本分割器、嵌入模型和向量存储（Astra DB、Pinecone、Chroma、Weaviate 等）。添加一个检索器节点，将其连接到 LLM，设置系统提示词，您就可以在不到一个下午的时间内获得一个可以在游乐场中测试并作为 API 公开的 RAG 聊天机器人。鉴于 DataStax 的所有权，它与 Astra DB 的集成尤为紧密，具有原生连接器并支持一键部署到 DataStax Langflow Cloud。

Langflow 与 Dify 和 Flowise 的对比定位

这三大开源可视化 LLM 构建器在表面宣传上趋于一致（拖拽式流程、可自托管、免费），但在架构和生产定位上却大相径庭。

Dify 是这三者中最具主见的一个。它作为一个全栈平台发布，拥有自己的 Celery 和 Redis 工作节点用于异步任务排队，具有工作区级别角色分离的原生多租户功能，以及一个内置的 API 网关，默认将每个流程转换为受速率限制的端点。Dify 还包括 OpenTelemetry 导出和单步对话日志，无需第三方集成。代价是复杂性：Dify 更接近于部署一个产品，而不是构建一个原型。Langflow 将流程编译为 LangChain Python 代码，这意味着它可以自然地集成到现有的 Python 环境中，但没有自带的队列或多租户功能。对于发布具有多个客户工作区的 SaaS 产品的团队来说，Dify 具有显著的架构优势。对于由工程主导的流水线，如果团队控制基础设施并希望进行深度的 Python 定制，Langflow 通常是更好的选择。

Flowise 是更轻量级的选项。它基于 Node.js 构建，依赖项极少，强调快速部署聊天机器人，并带有原生的 Telegram 和 WhatsApp 渠道集成，这是 Dify 和 Langflow 开箱即用所不具备的。Flowise 更容易在一个下午内运行起来，但其 LangChain 深度不如 Langflow，其追踪和调试功能是三者中最弱的，而且其社区也较小（约 30,000 个 GitHub star，而 Langflow 有 49,000+ 个）。如果您正在构建一个带有少量集成的可嵌入式面向客户的聊天机器人，Flowise 值得评估。如果您正在构建具有复杂检索逻辑或多智能体协调的 RAG 流水线，Langflow 更深度的 Python 定制和更活跃的开发轨迹通常会胜出。

第三个值得注意的比较是：n8n 处理具有 400 多个服务连接器（Salesforce、Slack、Stripe）的通用工作流自动化，但它并非为 AI 优先的流水线而设计。需要将 AI 流程与大量业务工具集成的团队有时会因为连接器的广度而选择 n8n，然后发现自己缺少了 Langflow 的 RAG 和智能体原语。许多团队会同时运行两者：n8n 用于业务流程自动化，Langflow 用于 AI 推理层。

“创建一个智能体非常容易——过程直截了当，使得构建思维链、通过反馈循环进行评估并将其转化为 API 变得简单，有时只需三个小时。” - Matheus Barbosa (@barboosaaaa)，Product Hunt，2025 年 10 月

工作流的真实体验

对于独立开发者来说，Langflow 兑现了它的承诺。打开画布，放入一个 ChatOpenAI 节点、一个 Prompt Template（提示词模板），也许还有一个文件加载器，连接端口，在游乐场中点击运行（Run），在您编写哪怕一行 Python 代码之前，您就已经拥有了一个可测试的东西。输出可视化工具（Output Visualizer）允许您点击任何节点并准确检查它接收和返回的内容，这对于在不添加日志代码的情况下调试检索问题或提示词格式问题非常有用。

性能是现实考验的到来之处。与直接调用 LLM 提供商相比，通过 Langflow 服务器的 API 调用会增加显著的延迟。GitHub 讨论记录了在 Docker 中，一秒钟的 OpenAI 调用通过 Langflow 的 API 层变成 120 秒的案例，并且在中等并发下 CPU 使用率飙升至 100% 是一个已知问题。该平台针对原型迭代速度进行了优化，而不是吞吐量。对于大规模服务真实用户的 API，团队通常最终会将流程导出为 Python 代码并直接运行，这在某种程度上违背了初衷。

大型 RAG 工作负载的内存管理存在已记录的泄漏问题。在不重启服务器的情况下重复上传文件或重建组件会导致内存使用量增长且无法释放。对于处理数百个大型文档的数据密集型流水线，这会成为一个崩溃隐患。实际的解决方法是定期重启服务器，但这并不是生产级的解决方案。

团队规模的协作也会很快暴露出摩擦。Langflow 流程存储为 JSON 文件，这意味着在团队成员之间共享更改意味着导出、通过 Slack 或电子邮件发送，然后重新导入。没有实时协同编辑，没有内置的分支或版本历史记录，也没有基于角色的访问控制来限制谁可以编辑生产流程与开发副本。Leo Nguyen 在与团队构建生产流程后，于 2025 年 2 月在 Medium 上直白地描述了这种体验：

“每次有人进行更改时，他们都会导出一个 JSON 文件并在 Slack 上共享。这个过程既笨重又过时。此外，跨多个帐户的流程没有集中的单一事实来源。” - Leo Nguyen，Medium，2025 年 2 月 7 日

安全问题值得关注。2025 年 5 月，CVE-2025-3248（CVSS 9.8）被添加到 CISA 的已知被利用漏洞目录中。该漏洞位于 /api/v1/validate/code 端点，该端点在没有身份验证或沙箱的情况下对用户提供的代码调用了 Python 的 exec()。已确认有一个部署 Flodrix 僵尸网络的活跃活动正在利用未修补的实例，GreyNoise 追踪到了 361 个恶意 IP 地址。修复程序在 v1.3.0 中发布，对该端点增加了身份验证要求。任何低于 1.3.0 且可从互联网访问的自托管部署实际上都已受到威胁。虽然这已被修补，但它揭示了一个基本的设计决策（未经身份验证的代码执行），这应该会影响组织如何考虑即使在当前版本上对自托管 Langflow 实例进行网络隔离。

对于与 Langflow 自然搭配的工具：AnythingLLM 在自托管的 RAG 流水线之上提供了一个精美的全端聊天界面，使其成为希望兼顾 Langflow 后端灵活性和更完善的面向用户 UI 的团队的常见补充。

Langflow 适合哪些人

Langflow 最适合那些已经习惯用 Python 和 LangChain 思考，但希望比纯代码迭代更快地构建 AI 流水线原型的开发者。最理想的用户是机器学习工程师或后端开发者，他们希望在几个小时内组装一个 RAG 聊天机器人、文档问答系统或多智能体工作流，对其进行可视化测试，与产品经理或设计师共享画布，然后通过导出 Python 代码或通过 DataStax Cloud 一键部署来实现生产化。

运行自托管 AI 基础设施、希望获得完全数据主权、没有按次调用计费，并且能够自由切换 LLM 提供商的团队会发现 Langflow 的 MIT 许可证和广泛的提供商支持非常有吸引力。DataStax/IBM 的支持意味着该项目不会消失，这在基于开源工具构建关键基础设施时非常重要。

Langflow 也适用于在 LangChain 之上进行构建并希望进行可视化调试的开发者。输出可视化工具和内存会话管理器增加了一个纯 LangChain 代码所缺乏的开发时反馈循环。

Langflow 不是什么

Langflow 不是面向业务用户的无代码工具。该平台需要了解 LLM 概念（嵌入、向量存储、检索、智能体），能够熟练管理 API 密钥，并且通常需要 Python 技能来编写自定义组件。希望在没有任何技术知识的情况下构建聊天机器人的用户会发现 Dify 或专用的聊天机器人平台更容易上手。

它不是生产级的多租户平台。需要基于角色的访问控制、工作区隔离、内置审计日志和企业 SSO 的组织在决定将 Langflow 用于团队部署之前，应评估 Dify 或托管解决方案。单租户架构需要为每个团队运行单独的实例，或者在顶层添加自定义身份验证层。

它没有针对高吞吐量、低延迟的生产 API 进行优化。如果您的用例需要以亚秒级响应时间处理数百个并发 API 请求，Langflow 增加到 LLM 调用路径的开销将会产生负面影响。请导出为 Python 并直接运行链，或者评估 Dify 内置的 Celery 队列以处理异步工作负载。

而且它不是一个通用的业务自动化平台。对于连接 Salesforce、Slack、Stripe 和数十种其他 SaaS 工具的自动化工作流，n8n 或 Make 具有 Langflow 并不试图匹敌的连接器广度。