📄 文档管理系统

← 返回列表

不想写代码？我用 Langflow 拖拽出了一套 RAG 系统，踩坑记录全公开 v2

article #Langflow #RAG #AI工作流 #可视化编排 #LangChain #Docker 📅 创建：2026-05-15 16:17:20 🔄 更新：2026-05-15 16:17:20
👁️ 预览 & 复制到公众号 ✏️ 编辑

不想写代码？我用 Langflow 拖拽出了一套 RAG 系统，踩坑记录全公开

说起来有点不好意思——我折腾 Langflow 的起因，是被一段报错信息逼疯了。

当时在给自己的小项目搭 RAG（检索增强生成）流程，LangChain 的链式调用写了几百行，调试的时候一个参数写错，整条链就原地爆炸。那天晚上我对着屏幕发了很久的呆，心想：有没有一种工具，能让我像搭积木一样把 RAG 流程拼出来，不用记那些绕来绕去的 API？

然后我就刷到了 Langflow。

今天这篇文章，我把自己的调研结果和实操踩坑全部摊开来讲，目标是让你看完就知道 Langflow 适不适合你、值不值得投入时间。

一、Langflow 到底是什么

Langflow 是一个可视化 AI 流程编排工具，核心用途是通过拖拽组件的方式构建 AI 工作流，最后可以导出为 API 调用或者 MCP 服务器。

简单理解：它给你的 LangChain 链提供了一个 GUI 前端。

项目地址是 github.com/langflow-ai/langflow，当前版本 v1.9.2（两周前刚发），MIT 协议，完全开源。

先看几个硬数据：

指标 数值
GitHub Star 148k+
Fork 9k+
编程语言 Python
项目创建时间 2023 年 2 月
Python 版本要求 >=3.10, <3.14

这个 Star 数在 AI 编排工具赛道里是妥妥的头部玩家，比很多知名开源项目都高。

二、从 VizQM 到 Langflow：它的前世今生

Langflow 并不是一诞生就叫这个名字的。

最早的版本叫 VizQM（Visual Query Manager），是一个数据查询可视化工具。团队在做的过程中发现，开发者对"用图形界面拼 AI 流程"这件事有很强的需求，于是逐渐把方向转向了 LLM 应用编排。

几次改名后确定为 Langflow，定位也正式锁定在"AI-powered agents and workflows"这个赛道。

目前项目由 7 位核心维护者 共同管理（来源：pyproject.toml maintainers 字段）：
- Carlos Coelho、Gabriel Almeida、Rodrigo Nader（langflow.org 团队）
- Cristhian Zanforlin、Lucas Eduoli、Otávio Anovazzi
- Italo dos Anjos

项目使用 uv 作为包管理器（Astral 出品的 Python 工具），前端基于 React Flow（这也解释了为什么它的节点图用起来手感很顺滑）。

三、核心架构：它是怎么跑起来的

技术栈一览

Langflow 本身不造 AI 能力，它扮演的是编排层的角色——底层调用 LangChain，LangChain 再对接具体的 LLM Provider（OpenAI、阿里云、MiniMax、Google 等）。

三种安装方式

方式一：Docker（最省心）

官方提供预构建镜像，一行命令跑起来：

docker run -p 7860:7860 langflowai/langflow:latest

启动后访问 http://localhost:7860/，即可看到熟悉的拖拽界面。数据默认存在容器内，如需持久化挂载：

docker run -p 7860:7860 -v $(pwd)/langflow_data:/data langflowai/langflow:latest

更多配置选项参考官方 Docker 部署文档。

方式二：桌面版（Windows/macOS 用户首选）

直接下载安装包，所有依赖打包好了，不用配 Python 环境。
下载地址：langflow.org/desktop

方式三：命令行（推荐给开发者）

推荐用 uv 安装（项目明确推荐 uv，pip 次选）：

# 安装
uv pip install langflow -U

# 启动
uv run langflow run

启动后访问 http://127.0.0.1:7860。

从源码跑（开发者模式）

# 克隆仓库
git clone https://github.com/langflow-ai/langflow.git
cd langflow

# 初始化环境（安装前后端依赖 + pre-commit）
make init

# 直接运行
make run_cli

项目要求 Node.js v22.12 LTS + npm 10.9，Python >= 3.10 且 < 3.14。Windows 用户推荐用 WSL2 或者 Dev Container。

四、我用它搭了一套 RAG 系统，完整过程讲给你

第一步：理解 RAG 在 Langflow 里的对应组件

RAG（检索增强生成）三件套：文档加载 → 分块 → 向量存储 → 检索 → 生成。

在 Langflow 里，每一步都有对应组件：

RAG 环节 Langflow 组件
文档加载 PDF Loader、Text Loader、Web Loader
分块 Recursive Character Text Splitter
向量存储 Chroma、Pinecone、FAISS、Milvus
检索 Vector Store Retriever
生成 OpenAI / 阿里云 / MiniMax 等 LLM
链拼接 Retrieval QA Chain

第二步：实际搭建

我在 Langflow 里依次拖入：

  1. PDF Loader → 加载我准备好的技术文档 PDF
  2. Recursive Character Text Splitter → 设置 chunk_size=500，overlap=50
  3. 阿里云 Text Embedding → 调用阿里云 text-embedding-v3 把文本块转为向量（国内访问稳定，免费额度高）
  4. Chroma → 向量数据库存储（本地持久化）
  5. Vector Store Retriever → 从 Chroma 里检索相似片段
  6. MiniMax Chat → MiniMax 2.7 作为生成模型（国内调用延迟低、成本低）
  7. Retrieval QA Chain → 把检索结果和问题拼给 LLM

整条链连起来之后，界面大概是这样的：

[截图占位：Langflow 画布上的完整 RAG 流程]

第三步：导出为 API

在 Langflow 里点击 "API" 标签，它会为你的流程生成一个 REST endpoint。curl 调用示例：

curl -X POST http://127.0.0.1:7860/api/v1/run/rag_flow \
  -H "Content-Type: application/json; charset=utf-8" \
  -d '{"input_value": "Langflow 支持哪些向量数据库？", "session_id": "test-session"}'

返回了基于我上传文档的答案，延迟大概 1-2 秒（本地部署 + MiniMax 2.7）。

第四步：发布为 MCP 服务器

这个是我觉得最实用的功能——你的 RAG 流程可以直接暴露为 MCP server，然后被任何 MCP 客户端调用。

在 Langflow 里创建项目后，流程会自动加入 MCP server 配置（可通过环境变量 LANGFLOW_MCP_SERVER_ENABLED 控制开关）。

在 OpenCode（我主要使用的 AI 编程工具）里配置好 MCP 客户端之后，就能用自然语言查询你上传的文档了——等于把文档变成了一个可以聊天的知识库。整个过程不需要写一行代码，全靠拖拽配置。

五、踩坑记录：这些问题我真真实实遇到过

坑 1：uv 安装报依赖冲突

问题：直接 pip install langflow 提示 Python 版本冲突，或者缺少某些 C 依赖。

原因：Langflow 依赖链比较深，有些组件（如 onnxruntime）对平台有要求。

解决方法：用 uv pip install langflow -U，uv 的依赖解析比 pip 强很多。Windows 用户直接用 Docker 版或 Desktop 版最省心。

坑 2：Chroma 向量数据库持久化路径问题

问题：本地用 Chroma 建了向量库，关掉后重新打开，数据没了。

原因：Chroma 默认用内存模式，需要手动指定 persist_directory。

解决方法：在 Chroma 组件设置里，填上 persist_directory 为本地路径，比如 ./chroma_db。这样每次启动会自动加载已有数据。

坑 3：分块大小对检索质量影响巨大

问题：早期我设的 chunk_size=1000，结果问一些短问题经常答非所问。

原因：过大的分块会引入过多无关上下文，检索时噪音大；过小又会切断语义。

解决方法：针对问答场景，chunk_size=500，overlap=50 是一个相对稳健的起点。重要文档建议多做几次实验调整。

坑 4：LLM 返回格式不稳定

问题：有时候 RAG 回答会带上"根据提供的文档"这类前缀，有时候不会，不同家的模型表现不一致。

原因：LangChain 的输出解析器默认行为不一致。

解决方法：在 QA Chain 后加一个 Output Parser 组件做格式约束，保证输出结构化。

坑 5：API 模式下中文输入编码

问题：通过 API 调用时，中文 query 偶尔出现乱码或者编码错误。

原因：Langflow API 的 JSON 处理在某些版本对 unicode 支持不一致。

解决方法：请求头里明确加 Content-Type: application/json; charset=utf-8，确保发送前对中文做 URL encode。

六、Langflow vs Dify vs Flowise：怎么选

对比项 Langflow Dify Flowise
Star 数 148k ~22k ~35k
编程语言 Python Node.js Node.js
前端技术 React Flow React React Flow
LLM 框架 LangChain 自研 LangChain/LangGraph
API 导出 ✅ REST ✅ REST ✅ REST
MCP 支持 ✅ ✅ ✅
桌面版 ✅ Windows/macOS ❌ ❌
中文社区 一般 活跃 一般
学习曲线 中等 较低 较低

我的判断：
- 如果你主要用 Python，团队有 LangChain 背景，选 Langflow
- 如果你更在意开箱即用和中文社区，选 Dify
- 如果你想要轻量级、部署简单，Flowise 也不错

七、什么人适合用 Langflow

适合的场景：
- 对 LangChain 有一定了解，想用 GUI 加速原型验证
- 需要给非技术同事提供 AI 流程配置界面
- 需要快速把 RAG 对话能力集成到现有系统
- 想把 AI 流程发布为 MCP 服务，供多个客户端复用

不太适合的场景：
- 追求极致性能的生产级 RAG 系统（专用优化更高效）
- 完全不想接触代码的同学（配置项较多，GUI 也有学习成本）
- 需要复杂的多 Agent 协作和状态管理（这块 LangGraph 更成熟）

写在最后

Langflow 148k Star 不是吹出来的，它的可视化和导出能力确实能大幅提升 AI 流程的搭建效率。特别是把流程发布为 MCP 服务器这个功能，我用下来觉得是真正的亮点——一次配置，多个客户端复用。搭配国内模型（阿里云 Embedding + MiniMax）使用，延迟和成本都比纯 OpenAI 方案友好很多。

但它也不是银弹。LangChain 的底层能力在那里，Langflow 只是给你提供了一个更友好的界面。如果你想做非常精细的流程控制，原生写 LangChain 代码仍然更灵活。

你在用 Langflow 吗？搭过什么有意思的流程？踩过什么坑？评论区聊聊。

💬 评论区

加载中...