
AI 流程平台对比——Dify、Fastgpt、Ragflow
TLDR
- 如果您需要一个简单、固定的需求,随便选用一个适合的编程语言调用LLM API即可
- 如果您是正在学习的AI的开发人员,能自己实现就自己实现,框架会变,底层原理不变
- 注重流程与扩展选Dify
- 注重知识库选RagFlow
一、背景
市面上目前工作流分为几种形式,一种是以Coze为代表的基于网页的工作流形式,另一种以langchain与llamaindex为主的基于代码框架的形式。
两种形式各有千秋,针对不同的技术与框架,我们需要针对自己的业务进行合理的判断,每一种场景、每一种业务、每一种使用的客户都会产生不同的答案。
所以我从多个角度,针对 Dify、FastGPT、RAGFLow这类基于webui 的工作流,进行一个对比。
先对比下Github Start🌟

二、测评维度
作为一个LLMIOps平台,包含几个基本的模块,所以我们也会从这些维度进行一个比较
测评维度
- 团队人员管理
- 模型管理
- 第三方工具
- 知识库管理
- 应用管理
- 对话管理
- 应用类型
- 开源协议与功能对比
- 部署难度
三、测评产品版本
- Dify v1.0.0
- FastGPT v4.8.20
- RAGFlow v0.17.0 slim
四、详细测评
4.1 团队人员管理
作为团队使用的平台,我们需要考虑人员管理的一些需求。
主要考虑两个方向:
- 工作空间
- 权限管理
| 维度 | Dify | FastGPT | RAGFlow |
|---|---|---|---|
| 空间数量 | 1个 | 无空间 | 多个支持邀请制 |
| 角色 | - 管理员 |
- 编辑
- 成员 | 无 | -管理员 -成员 | | 加入多个团队 | 否 | 否 | 是 | | 商业版 | 支持 | 支持 | | | 推荐值 | 🌟🌟 | 🌟 | 🌟🌟 |
4.2 模型管理
作为一个LLMOps的平台,是否支持完备的平台是一个非常重要的功能,模型管理需要考量三个方面,一个是支持的平台数量,一个是支持的模型类型,还有一个是可扩展性。
第一点保证了能够方便对接各类平台;
第二点保证在模型不断变化的情况,包括文本模型、视觉模型、视觉模型等都能方便接入;
第三点是否方便用户接入自定义或者其他平台的模型。
| 维度 | Dify | FastGPT | RAGFlow |
|---|---|---|---|
| 模型供应商 | 56 | 20 | 44 |
| OpenAI兼容格式 | 支持 | 支持 | 支持 |
| 扩展接入 | 强,自定义插件 | 中,自定义配置 | 弱,不能自定义配置 |
| 支持模型类型 | - Text Generation |
- Image Generattion
- Vision
- Audio Generation
- Text Embedding
- Speech2text
- TTS
- Rerank
- Moderation | - Text Generation
- Vision
- Text Embedding
- Speech2text
- TTS
- Rerank | - Text Generation
- Vision
- Text Embedding
- Rerank
- Moderation | | 缺点 | - 负载均衡需要企业版
- 一个模型名称只能部署一个服务 | - 管理页面有点混乱 | - 不支持在提供商上增加模型
- 一个平台只支持一个key | | 特点 | - 支持自己编写插件对接各类模型服务 | - 支持配置文件方式
- 可以设置别名 | / | | 推荐值 | 🌟🌟🌟 | 🌟🌟 | 🌟 |
4.3 第三方工具
一个平台如果无法很好的调用第三方的工具,就无法做到很好的扩展性,随着业务的不断发展,会越来越无法支撑,第三方工具方面需要考虑两个比较重要的点
- 自带工具的丰富度
- 工具扩展的难度与灵活度
| 维度 | Dify | FastGPT | RAGFlow |
|---|---|---|---|
| 自带工具数量 | - 工具:40 |
- Agent策略:2
- 扩展:6 | 系统插件:15 | 工具:21 | | 特色工具 | - database:连接数据库
- Json处理
- ECharts图表生成 | - 数据库连接
- 飞书、钉钉
- BI图表 | - 谷歌学术 | | 扩展 | - API扩展
- 支持插件开发 | 无 | 无 | | 插件类型 | - 模型
- 工具
- Agent策略
- 扩展 | 无 | 无 | | 自定义 | - 基于OpenAPI-Swagger创建接口
- 基于工作流转换为工具 | 无 | 无 | | 兼容实现 | Http请求 | Http请求 | 无 | | 推荐值 | 🌟🌟🌟 | 🌟🌟 | 🌟 |
4.4 知识库
知识库是RAG技术的一个关键落地场景,所以针对知识库,需要从以下维度进行考虑
- 导入阶段:
- 考虑支持的格式是否丰富
- 导入的方式:如网页、文本、接口
- ETL数据清晰流程是否准确
- 创建阶段: 手动或自动构建知识库。
- 召回阶段: 检索相关信息的效率和准确性。
- 权限设置: 控制谁可以访问或编辑知识库。
| 维度 | Dify | FastGPT | RAGFlow |
|---|---|---|---|
| 导入阶段:支持格式 | TXT、 MARKDOWN、 MDX、 PDF、 HTML、 XLSX、 XLS、 DOCX、 CSV、 MD、 HTM | .txt, .docx, .csv, .xlsx, .pdf, .md, .html, .pptx | Word、PPT、Excel、TXT、PDF、HTML |
| 导入阶段:导入方式 | - 文本 |
- Notion
- Web站点
- API接口 | - 文本
- API Web网站
- 飞书
- 语雀 | - 文本
- 网页 | | 导入阶段:清洗方式 | - DIfy ETL
- Unstructured ETL | - 自带 | - DeepDoc
- 简易
- 大模型 | | 创建阶段:分段设置 | - 通用文本分块模式
- 使用父子模式时,子块用于检索,父块用作上下文 | - 直接分段
- 问题拆分 | - 自动创建关键词
- 自动创建问题 | | 创建阶段:索引方式 | - 高质量:Text-Embedding
- 经济:关键词 | - Text-Embedding | - 召回增强RAPTOR策略
- 知识图谱 | | 召回阶段:检索设置 | - 向量搜索
- 全文搜索
- 混合搜索 | - 向量搜索
- 全文搜索
- 混合搜索 | - 搜索 | | 召回阶段:rerenk | - 支持rerank模型 | - 支持rerank模型
- 支持大模型理解 | - 支持rerank模型 | | 召回测试 | - 支持多种召回测试 | 支持多种召回测试 | - 知识图谱 | | 团队管理 | - 支持个人
- 支持团队
- 支持部分成员 | 商业版功能 | - 支持个人
- 支持团队 | | 推荐值 | 🌟🌟 | 🌟 | 🌟🌟🌟 |
在知识库模块功能比较强大的的属于RAGFLow,支持模型理解也支持知识图谱创建,召回的效果应该算比较好,这是RAGFLow 的主打特点。
4.5 应用管理
应用是LLMOps平台的核心,所有的业务都是围绕应用进行开展,通过应用连接了模型、工具调用、Agent等一系列工作。
| 维度 | Dify | FastGPT | RAGFlow |
|---|---|---|---|
| 应用类型 | - 聊天助手 |
- Agent
- 文本生成应用
- Chatflow
- 工作流 | - 简单聊天
- 工作流聊天 | - 聊天
- Agent | | 应用功能 | - 对话开场白
- 下一步问题简易
- 文字转语音
- 文件上传
- 引用与归属
- 内容审查 | - 文件上传
- 语音播放
- 语音输入
- 猜你想问
- 定时执行
- 自动执行
- 输入引导
- 对话开场白 | | | 变量 | - 环境变量
- 会话变量 | - 全局变量 | 无 | | 工作流支持功能 | 基础功能
- LLM
- 知识检索
- 直接回复 Agent 问题理解
- 问题分类器 逻辑
- 条件分支
- 迭代 转换
- 代码执行
- 模板转换
- 变量聚合器
- 文档提取器
- 变量赋值
- 参数提取器 工具
- HTTP请求
- 列表操作 工具
- 工作流
- Api接口 | 基础功能
- AI对话
- 知识库搜索
- 问题分类
- 文本内容提取 工具箱
- 工具调用
- 交互
- 用户选择
- 表单输入
- 工具
- 文本拼接
- 指定回复
- 文档解析
- HTTP请求
- 判断器
- 变量更新
- 代码运行
- 批量执行
- 其他 团队应用 (未显示具体功能) AI能力
- 知识库搜索引用合并
- 问题优化
- Laf函数调用(测试)
- 自定义反馈 工具 | 1. 知识检索
- 生成回答
- 对话
- 问题分类
- 静态消息
- 问题优化
- 关键词
- 条件
- 集线器
- 模板转换
- 循环
- 注释 | | 工作流特点 | - 迭代并发模式
- 错误响应
- 节点并行 | - 批量执行
- AI模型支持变量引用 | | | 是否支持扩展 | 支持 | 支持贡献插件 | 不支持 | | 导入导出 | 支持 | 不支持 | 支持 | | 测试历史 | 支持 | 支持 | | | 发布渠道 | - web应用
- Api接口
- 嵌入网站 | - Web网页
- Api接口
- 飞书机器人
- 钉钉机器人
- 微信公众号接入 | - 嵌入网站 | | 日志与标注 | 支持
- 详细显示调用日志
- 针对问答可以进行标注 | 支持
- 详细显示调用日志
- 针对问答可以进行标注 | 无 | | 监测 | 7大维度分析 | 不支持 | | | | | | | | 特色功能 | 错误响应 | 自动执行 定时任务 | 搜索 | | 推荐值 | 🌟🌟🌟 | 🌟🌟 | 🌟 |
从上述对比当中,Dify的应用方面吊打其他两家,无论是编排的方式,错误的处理还有未来的扩展上,都是第一位。并且搭配了丰富的日志,方便后续的追踪。
而且dify还可以的搭配LangSmith、Langfuse、opik进行LLM应用的生命周期监控。

4.6 开源协议
开源协议也是商业公司在使用的时候特别关注的部分,这一章,我们针对各个工作流进行协议的对比,看下哪个框架更适合企业使用
| 产品 | 协议 |
|---|---|
| Dify | - Dify可以用于商业用途,包括作为其他应用程序的后端服务或企业应用开发平台。 |
- 不能使用Dify源代码来运营多租户环境。 | | FastGPT | - FastGPT可以用于商业化用途,包括作为“后端即服务”(backend-as-a-service)为其他应用程序提供服务,或作为应用开发平台交付给企业。
- 不能使用FastGPT.AI源代码运营与FastGPT类似的多租户SaaS服务。 | | RAGFlow | - 允许您复制、修改、公开显示、公开表演、分许可和分发作品及其衍生作品。 |
4.7 部署难度
一个平台功能是一方面,部署难度,依赖的技术栈都需要考量,下面总结下部署难度与依赖
| 维度 | Dify | FastGPT | RAGFlow |
|---|---|---|---|
| Docker部署 | 支持 | 支持 | 支持 |
| 技术栈 | - Python flask |
- Nextjs
- PostgresSQL
- Qdrant
- Redis
- Unstructured
- Sandbox
- Plugin Demon | - pg vector
- mongo
- sandbox
- mysql
- fastgpt | - es
- MySQL
- minio
- Redis |
五、汇总
| 维度 | Dify | FastGPT | RAGFlow |
|---|---|---|---|
| 团队人员管理 | 🌟🌟 | 🌟 | 🌟🌟 |
| 模型管理 | 🌟🌟🌟 | 🌟🌟 | 🌟 |
| 第三方工具 | 🌟🌟🌟 | 🌟🌟 | 🌟 |
| 知识库 | 🌟🌟 | 🌟 | 🌟🌟🌟 |
| 应用管理 | 🌟🌟🌟 | 🌟🌟 | 🌟 |
六、结束
经过多方面你的对比,我们对基于web页面的工作流有了一定的了解。我们会发现每个框架都有自己的特点与用处,工作流知识我们解决问题的一个工具,不要痴迷工具。
我们需要更好的利用各个工具的特点,掌握AI工作流的核心才是最重要的
最后推荐几个几篇我与AI共创的文章