流程编排

低代码平台 Dify / Coze / FastGPT

不是所有团队都要从 LangGraph 写起。Dify、Coze、FastGPT 这类平台提供可视化的拖拽式 Workflow 构建——适合快速原型、非技术团队、以及 80% 不需要自定义控制流的场景。这篇讲清楚三个平台各自的 sweet spot、能力边界、以及什么时候该从低代码切换到代码方案。

适合阶段：工具选型 / 快速验证核心：可视化 Workflow + 内置 RAG + Agent 能力面试重点：平台选型 + 低代码 vs 代码的边界

本文边界：聚焦三个低代码平台的能力对比与选型。代码方案的 Workflow 编排见 LangGraph 深度解析 和 LlamaIndex Workflows；编排模式的通用理论见 编排模式；RAG 的底层原理见 RAG 基础。

面试官想考什么

读完这篇你要能正面回答下面这些题。每题后面括号里是面试官真正想看你答出什么。

Dify / Coze / FastGPT 各自的定位和 sweet spot 是什么？考你能不能区分"通用 LLM 开发平台" vs "聊天机器人构建器" vs "知识库 Q&A"。

低代码平台的 Workflow 构建器和 LangGraph 的图编排有什么本质区别？考对"可视化拖拽 vs 代码定义"的理解，以及各自的能力上限。

什么时候该用低代码平台？什么时候必须写代码？考工程判断——不是"代码更高级"，而是场景匹配。

这些平台的 RAG 能力和自建 RAG 管线比，差在哪？考对"开箱即用 vs 可定制性"的权衡理解。

一个企业想快速上线一个内部知识库问答，你推荐哪个方案？考实际选型能力——能结合团队技术栈、时间约束、维护成本给出建议。

---

为什么需要了解低代码平台

先看一个真实场景。某中小企业想做一个内部知识库问答：员工上传公司文档（PDF / Word / Notion），问问题时能基于公司知识回答。

如果用 LangGraph 从零搭：

1. 选向量数据库（Pinecone / Weaviate / Qdrant？）
2. 写文档解析（PDF / Word / HTML 各一套 parser）
3. 写 chunking 策略
4. 写 embedding 管线
5. 写检索 + reranking
6. 写 LLM 生成 + 引用溯源
7. 写前端界面
8. 部署 + 运维
→ 预计 2-4 周，需要 1-2 个有经验的 AI 工程师

用 Dify / FastGPT：

1. Docker 部署平台（30 分钟）
2. 上传文档到知识库（自动解析 + 向量化）
3. 拖拽搭 Workflow（检索 → 生成）
4. 配置模型和参数
→ 预计 1-2 天，运维人员就能搞定

差距在 10 倍以上。对于标准化的 RAG 场景，低代码平台是合理选择。

---

三大平台定位

Dify：通用 LLM 应用开发平台

一句话定位：LLM 应用的"后端即服务"——不只做 chatbot，还做 Workflow、Agent、文本生成等多种应用类型。

核心能力：

• 可视化 Workflow 构建器（节点 + 连线，支持条件分支、循环、并行）
• 内置 RAG 引擎（文档上传 → 自动切分 → 向量化 → 检索）
• Agent 模式（支持 ReAct 风格的工具调用）
• 多模型支持（OpenAI / Anthropic / 开源模型 / Ollama 本地模型）
• API 优先——每个应用自动生成 REST API，方便集成到现有系统
• 开源（GitHub 110K+ stars），可自托管

适合谁：有一定技术能力的团队，需要快速搭建多种 LLM 应用，且希望可视化管理。

Coze：聊天机器人构建平台

一句话定位：字节跳动的 AI Bot 构建器——重点在多渠道分发（Telegram / Discord / 网页嵌入 / API）。

核心能力：

• 极简 Bot 构建界面（no-code 拖拽）
• 丰富的插件市场（搜索、天气、新闻等开箱即用）
• 多步骤 Workflow
• 知识库（文档 + 网页 + API 数据源）
• 多渠道一键发布
• 2025 年 7 月开源了 Coze Studio 和 Coze Loop

适合谁：想快速做一个能在多平台上线的 chatbot，不需要深度定制。

FastGPT：企业知识库 Q&A 专精

一句话定位：专注于"企业知识库问答"的开源平台——文档处理和检索能力最强。

核心能力：

• 文档预处理管线（PDF / Word / Excel / Markdown / 网页，自动清洗 + 切分）
• 混合检索（向量检索 + 关键词检索 + reranking）
• 可视化 Workflow 构建器（支持复杂逻辑）
• 代码沙箱节点（在 Workflow 里运行自定义代码）
• 问答调试工具（看检索到了哪些 chunk、LLM 基于什么生成的）

适合谁：核心需求就是"基于公司文档做问答"，需要高质量的检索结果。

---

能力对比

维度	Dify	Coze	FastGPT
定位	通用 LLM 应用平台	Chatbot 构建器	企业知识库 Q&A
Workflow 能力	强（条件 / 循环 / 并行）	中（多步骤流程）	强（含代码沙箱）
RAG 能力	内置，支持多向量库	内置知识库	最强（混合检索 + reranking）
Agent 能力	支持（ReAct + 工具调用）	支持（插件调用）	支持（Q&A + 代码沙箱）
模型支持	最广（OpenAI / Anthropic / Ollama / 自定义）	OpenAI / 字节自研	OpenAI / 开源模型
多渠道发布	API + 网页嵌入	最强（Telegram / Discord / 网页 / API）	API + 网页嵌入
自托管	Docker（开源）	Docker（2025 开源）	Docker（开源）
社区规模	最大（110K+ stars）	成长中	中（18K+ stars）
学习曲线	低-中	最低	低-中

---

低代码 vs 代码方案的边界

关键问题不是"低代码好不好"，而是"你的需求是否在低代码的能力范围内"。

低代码能搞定的

• 标准 RAG（文档 → 检索 → 生成 → 回答）
• 简单 Workflow（顺序 / 条件分支 / 循环，节点数 < 20）
• 标准 Agent（工具调用 + 对话，不需要自定义循环逻辑）
• 快速原型验证——2 天内跑通一个 MVP
• 非技术团队自助搭建

低代码搞不定的（需要代码方案）

• 复杂的自定义控制流——比如"并行检索 3 个数据源 → 根据检索质量动态决定是否追加检索 → 合并 → 多轮评估优化"。低代码的节点和连线在这种复杂度下会变得不可维护。
• 自定义 Reducer / 状态合并——多个节点并行写入同一字段时的合并策略，低代码平台通常不支持。
• 生产级 Checkpoint + HITL——LangGraph 的 interrupt/resume + PostgresSaver 提供的暂停-恢复能力，低代码平台的支持程度有限。
• 深度可观测性——需要 trace 每一步的 prompt / token 消耗 / 延迟，然后做自动化评估。
• 自定义 embedding / reranking 模型——低代码平台通常提供有限的模型选择。

判断标准

你的需求能用 < 20 个节点的可视化 Workflow 表达？
  → 是：低代码
  → 否：代码方案

你的团队有 AI 工程师？
  → 有：代码方案上限更高
  → 没有：低代码是唯一选择

你的场景是标准 RAG / chatbot？
  → 是：低代码够用
  → 不是（复杂 Agent / 多 Agent / 自定义编排）：代码方案

---

实战：用 Dify 搭一个知识库问答

以 Dify 为例，展示低代码平台的典型使用流程。

Step 1：部署

git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env
docker compose up -d
# 访问 http://localhost/install 初始化

Step 2：创建知识库

在 Dify 界面里：

1. 进入"知识库" → 创建知识库
2. 上传公司文档（PDF / Word / Markdown）
3. 选择切分策略（自动 / 自定义分隔符 / 按段落）
4. 选择 embedding 模型（text-embedding-3-small / BGE 等）
5. 点击"处理"——自动完成切分 → embedding → 存入向量库

Step 3：搭建 Workflow

在可视化编辑器里拖拽节点：

[开始] → [知识库检索] → [LLM 生成] → [输出]
         ↑
         配置：Top-K=5, 相似度阈值=0.7
                          ↑
                          配置：模型=GPT-4o, 温度=0.3
                          System prompt: "基于检索到的资料回答，引用来源"

Step 4：测试和发布

1. 在"调试"面板测试几个问题，看检索结果和生成质量
2. 调整参数（Top-K、温度、prompt）
3. 发布为 API 或嵌入式网页聊天

整个过程不需要写一行代码。

---

容易踩的坑

坑 1：把低代码平台当成最终方案

现象：用 Dify 搭了 MVP，产品上线后需求越来越复杂，Workflow 节点从 10 个涨到 50 个，可视化编辑器卡得动不了。

根因：低代码平台适合快速验证，不一定适合长期复杂演进。

修法：明确低代码是原型阶段工具。当 Workflow 节点超过 20 个、或者需要频繁加自定义逻辑，及时迁移到代码方案（LangGraph / LlamaIndex Workflows）。

坑 2：忽视检索质量，只调 prompt

现象：用户反馈"回答不准"，团队一直在改 system prompt，效果不大。

根因：RAG 的质量 80% 取决于检索（检索到了正确的 chunk），20% 取决于生成。Prompt 调得再好，检索不到相关内容也没用。

修法：先看检索结果——Dify / FastGPT 都有调试面板，能看到检索到了哪些 chunk。如果检索不准，调 chunk 大小、切分策略、Top-K、相似度阈值。

坑 3：数据安全——模型 API 外传敏感数据

现象：内部文档包含商业机密，但知识库接了 OpenAI API，文档 chunk 通过 embedding API 发到了外部。

根因：默认配置用的是云端 embedding 和 LLM 模型。

修法：(1) 自托管 embedding 模型（BGE / M3E 通过 Ollama 本地跑）；(2) 自托管 LLM（Llama / Qwen 本地部署）；(3) Dify / FastGPT 都支持连接本地模型。

坑 4：平台锁定

现象：在 Dify 里搭了一套复杂的 Workflow + 知识库，想迁移到另一个平台，发现没有导出功能。

根因：每个平台的 Workflow 格式、知识库存储、prompt 模板都不通用。

修法：(1) 核心 prompt 和 Workflow 逻辑另存一份文档（不只存在平台里）；(2) 知识库的原始文档单独备份；(3) 评估平台时考虑导出能力。

---

与相邻概念的辨析

低代码平台 vs LangGraph：低代码平台是"给你 90% 的能力，你只需要配置"；LangGraph 是"给你 100% 的控制权，你需要自己搭"。不是对立关系——很多团队用低代码平台做 MVP，验证后迁移到代码方案。

Dify vs n8n：n8n 是通用自动化平台（400+ 节点，连接 Slack / Gmail / 数据库等），后来加了 AI 功能。Dify 从第一天就是 LLM 应用平台。如果你的核心是"连接各种 SaaS + 加一点 AI"→ n8n。如果核心是"搭 LLM 应用"→ Dify。

FastGPT vs RAGFlow：都专注 RAG，但 FastGPT 是完整平台（有 Workflow 构建器 + 前端），RAGFlow 更像后端引擎（专注文档解析和检索质量）。需要一站式方案 → FastGPT。需要嵌入到已有系统 → RAGFlow。

---

面试题深度解析

Q: 低代码平台和 LangGraph 的 Workflow 有什么本质区别？

30 秒版本：两者都是 Workflow 编排，区别在抽象层级和能力上限。低代码平台用可视化拖拽定义 Workflow，简单快速但能力有上限——复杂控制流（自定义 Reducer、动态子图、生产级 checkpoint）难以表达。LangGraph 用代码定义 graph，学习曲线陡但完全可控——任何控制流都能实现。类比：低代码像 Notion 数据库，LangGraph 像 PostgreSQL——前者零配置上手，后者 SQL 全能。

追问：那什么场景低代码反而比代码方案更好？ 非技术团队自助搭建、快速原型验证（2 天内跑通 MVP）、标准化场景（客服 / 知识库 / 内容生成）。关键判断：如果你的 Workflow 能用 < 20 个节点表达、不需要自定义控制流逻辑，低代码省的不只是开发时间，还有后续的维护成本（运维人员就能改 Workflow，不需要工程师）。

Q: 一个企业想快速上线内部知识库问答，你推荐哪个方案？

30 秒版本：取决于三个条件——(1) 团队有没有 AI 工程师；(2) 文档类型和质量；(3) 数据安全要求。

• 没有 AI 工程师 + 标准文档 + 允许云端 → Dify 或 Coze，2 天上线
• 没有 AI 工程师 + 大量复杂文档（扫描件、表格） → FastGPT，文档处理能力最强
• 有 AI 工程师 + 需要深度定制 → LangGraph + 自建 RAG 管线
• 数据安全要求高（不能外传） → Dify / FastGPT 自托管 + 本地模型（Ollama）

追问：FastGPT 和 Dify 都能做 RAG，怎么选？ FastGPT 的检索质量更高（混合检索 + reranking 开箱即用），但生态比 Dify 小。Dify 的 Workflow 和 Agent 能力更强，生态最大（110K+ stars）。如果核心是"文档问答准确率"→ FastGPT。如果还要做 Agent、Workflow 等多种应用 → Dify。

---

延伸阅读

• Dify 官方仓库 (github.com/langgenius/dify) 110K+ stars 的开源 LLM 应用平台。看 docker/ 目录下的部署指南和 api/ 下的后端架构。

• FastGPT 官方仓库 (github.com/labring/FastGPT) 企业知识库 Q&A 专精。重点看知识库配置和混合检索的文档。

• Coze Studio 开源 (github.com/coze-dev/coze-studio) 字节跳动 2025 年 7 月开源。Go + React 微服务架构。

• Jimmy Song：Open Source AI Agent Platform Comparison (jimmysong.io/blog/open-source-ai-agent-workflow-comparison) 2026 年的横向对比，覆盖 Dify / Coze / n8n / FastGPT / RAGFlow / LangGraph。选型时参考。

• 配套阅读：LangGraph 深度解析 — 代码方案的对照；编排模式 — 底层编排模式的理论；RAG 基础 — 低代码平台内置 RAG 的底层原理。