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

标题

工具栏

点击或拖拽上传图片

支持 PNG, JPG, GIF, WebP 格式

内容 (Markdown 格式)

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

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

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

然后我就刷到了 Langflow。

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

---

## 一、Langflow 到底是什么

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

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

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

**先看几个硬数据：**

| 指标 | 数值 |
|------|------|
| GitHub Star | **148k** |
| Fork | **9k** |
| Issues / PRs | 927 / 668 |
| 编程语言 | Python |
| 项目创建时间 | 2023 年 2 月 |
| Commits 总数 | 17,674 |
| Python 版本要求 | 3.10 ~ 3.13 |

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

---

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

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

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

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

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

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

---

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

### 技术栈一览

- 前端：React Flow（节点图画布）
- 后端：FastAPI + SQLModel
- AI 框架：LangChain（~1.2.0）
- 数据库：SQLite（开发默认）/ PostgreSQL（生产）
- 部署：Docker / 直接 pip install

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

### 两种运行模式

**1. 桌面版（Langflow Desktop）**
适合 Windows/macOS 用户，直接下载安装包，所有依赖打包好了，不用配 Python 环境。
下载地址：langflow.org/desktop

**2. 命令行版**
推荐用 uv 安装（项目明确推荐 uv，pip 次选）：

```bash
# 安装
uv pip install langflow -U

# 启动
uv run langflow run
```

启动后访问 http://127.0.0.1:7860，熟悉的拖拽界面就出来了。

### 从源码跑（开发者模式）

```bash
# 克隆仓库
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 / Anthropic / Google 等 LLM |
| 链拼接 | Retrieval QA Chain |

### 第二步：实际搭建

我在 Langflow 里依次拖入：

1. **PDF Loader** → 加载我准备好的技术文档 PDF
2. **Recursive Character Text Splitter** → 设置 chunk_size=500，overlap=50
3. **OpenAI Embeddings** → 把文本块转为向量
4. **Chroma** → 向量数据库存储（本地持久化）
5. **Vector Store Retriever** → 从 Chroma 里检索相似片段
6. **ChatOpenAI** → GPT-4o 作为生成模型
7. **Retrieval QA Chain** → 把检索结果和问题拼给 LLM

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

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

### 第三步：导出为 API

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

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

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

### 第四步：发布为 MCP 服务器

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

```bash
langflow run --mcp-server
```

在 Cursor 或者任何支持 MCP 的 IDE 里配置好之后，你就能用自然语言查询你上传的文档了，等于把文档变成了一个可以聊天的知识库。

---

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

### 坑 1：uv 安装报依赖冲突

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

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

**解决方法**：用 uv pip install langflow -U，uv 的依赖解析比 pip 强很多。Windows 用户直接用 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 模式下 session_id 管理和中文输入编码

**问题**：通过 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 | ~65k | ~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 服务器这个功能，我用下来觉得是真正的亮点——一次配置，多个客户端复用。

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

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

摘要

标签多个标签用逗号分隔

分类