最近在做一些 AI 应用相关的东西FastGPT 用得比较多所以想简单聊聊这个工具。先说结论。如果你的需求只是调用一次大模型比如把一段文字交给 DeepSeek 总结一下或者让 GPT 帮你改写一段文案那么完全没必要上 FastGPT直接调模型接口就可以了。但如果你的需求开始涉及知识库、公司内部资料、RAG、工作流、多个模型节点、业务接口调用这些东西FastGPT 就会比较省事。我最开始接触 FastGPT 时其实也有个疑问大模型本身不是已经有 API 了吗我为什么还要在中间再加一层 FastGPT用一段时间以后我觉得这个问题的答案很简单。FastGPT 真正帮我们解决的并不是“怎么调用大模型”而是调用大模型以后那一堆本来需要自己开发的东西。FastGPT到底是干什么的FastGPT 官方现在把自己定义为一个基于大语言模型的 AI Agent 应用开发平台里面集成了知识库问答、可视化工作流、Agent 编排、工具调用等能力。通俗一点说它就是夹在你的业务系统和大模型之间的一层。大概是这样你的程序 ↓ FastGPT ↓ DeepSeek / Qwen / 豆包 / 其他模型FastGPT 自己并不是一个大模型。真正负责“思考”和“生成答案”的还是后面的 DeepSeek、Qwen、豆包这些模型。它更像是帮你把这些模型组织起来。比如Prompt 怎么配置历史对话怎么处理企业资料怎么做成知识库文档怎么切片怎么做 Embedding怎么检索知识怎么做 RAG怎么搭工作流怎么调用外部 API怎么把最后的 AI 能力提供给自己的程序这些事情 FastGPT 已经帮你做掉了一大部分。所以它的价值其实不是我不用写代码就能调大模型了。而是我不用自己从头写一整套 AI 应用基础设施了。这两个概念还是不太一样。直接调用大模型其实非常简单比如我们现在做一个最简单的功能用户问一句话然后把这句话交给模型。后端代码大概就是constresponseawaitclient.chat.completions.create({model:xxx,messages:[{role:user,content:帮我总结一下这段内容}]})到这里其实已经完成了一个最基础的 AI 功能。所以单纯看“大模型调用”这件事情真的没什么复杂的。问题通常出现在下一步。假设你要做的不是一个简单聊天框而是公司产品知识助手。员工可以问产品A支持哪些功能产品A的退货政策是什么产品B和产品C有什么区别这时候直接调大模型接口就开始不够用了。因为模型并不知道你公司的内部资料。例如最新产品说明书售后政策企业内部制度私有产品参数培训文档公司数据库这些东西大模型本身是没有的。于是就会引出一个现在做 AI 应用经常会听到的词RAG。RAG其实没那么玄乎RAG 全称叫 Retrieval-Augmented Generation中文一般翻译成“检索增强生成”。名字看起来挺唬人原理其实很朴素不要让模型直接凭自己的记忆回答先帮它查一下资料。比如用户问产品A能不能退货系统先去你的公司资料里找到了产品A支持7天无理由退货已经拆封的特殊商品除外……然后再把这段资料和用户的问题一起交给大模型。实际上发给模型的内容可能类似请根据下面的公司资料回答问题。 参考资料 产品A支持7天无理由退货已经拆封的特殊商品除外。 用户问题 产品A能不能退货模型看了资料以后再回答。这就是最简单的 RAG。理论并不复杂。真正麻烦的是怎么从几千篇甚至几万篇资料里面快速找到刚才那一段。总不能每次有人提问都把整个公司的 PDF、Word、Excel 全塞给大模型。这显然不现实。于是你还得继续往下做。真正麻烦的是RAG后面的工程通常一套知识库系统大概会经历这么一个流程PDF / Word / Markdown / Excel ↓ 文档解析 ↓ 文本切片 ↓ Embedding ↓ 生成向量 ↓ 向量数据库用户提问的时候再走用户问题 ↓ Embedding ↓ 向量检索 ↓ 找出相关知识 ↓ 拼到 Prompt 里 ↓ 调用大模型 ↓ 返回结果这里面每一步其实都能继续拆。例如文档上传。你得处理PDFWordTXTMarkdownExcel然后还要考虑PDF 能不能正确解析表格怎么办扫描件怎么办图片怎么办标题层级会不会丢文件更新以后怎么重新入库文档解析完以后又碰到切片。一份 100 页的 PDF你不可能整个塞进一个知识块。所以要拆成Chunk 1 Chunk 2 Chunk 3 Chunk 4 ……但切多大合适500 字1000 字按段落按标题前后要不要重叠不同业务答案都不一样。切完以后还要 Embedding。再把 Embedding 存到向量数据库。然后实现检索、召回、排序有时候还要加 rerank。最后还要自己控制系统 Prompt 知识库内容 历史聊天记录 用户问题怎么组合起来。所以最后经常会出现一个挺有意思的情况真正调用大模型 API 的代码只有几十行。但是围绕它做的知识库、RAG、检索、管理后台、工作流可能写了几千行甚至更多代码。这也是 FastGPT 这类工具存在的原因。FastGPT到底帮我们省了什么FastGPT 官方现在已经把知识库、文档处理、知识检索、工作流、Agent 等能力整合在了一起。所以刚才那套流程如果自己做可能是你的前端 ↓ 你的后端 ↓ 文档处理 ↓ 文本切片 ↓ Embedding ↓ 向量数据库 ↓ 知识检索 ↓ Prompt 拼装 ↓ 模型调用 ↓ 会话管理用了 FastGPT 以后可以简化成你的前端 / 系统 ↓ FastGPT API ↓ 知识库 / Workflow / Agent ↓ 大模型当然这不代表上面那些东西不存在。它们依然存在。只是不用你自己全部重新开发一遍了。这是我觉得 FastGPT 最实在的地方。FastGPT怎么用如果第一次使用我不太建议上来就研究复杂工作流。FastGPT 官方现在的快速上手也是按照几个典型场景来介绍对话 Agent知识库 对话 AgentWorkflowAgent V2其中最容易理解 FastGPT 价值的我觉得还是知识库 对话 Agent。我们可以直接拿“公司产品知识助手”做例子。第一步先把模型配好FastGPT 后面还是要调用大模型所以首先需要有模型。比如DeepSeek 豆包 GLM Qwen ……这里有两个概念需要区分一下。一个是聊天模型。也就是负责用户提问 ↓ 模型回答另外一个是 Embedding 模型。Embedding 模型并不是用来跟人聊天的。它主要负责把文字转换成向量用于知识检索。比如产品A支持7天无理由退货经过 Embedding 模型以后会变成一串数字。系统通过这些向量去判断“这个商品不要了怎么办”和“7天无理由退货”虽然字面不一样但意思比较接近。第二步创建知识库模型准备好以后可以先创建一个知识库。例如公司产品资料然后把你现有的资料传进去产品说明书.pdf 售后政策.docx 产品参数.xlsx FAQ.mdFastGPT 会负责后面的知识处理流程。官方目前的知识库能力包括数据导入、预处理、知识匹配和问答并且针对 PDF 等复杂文档也提供结构化解析能力。以前这一步通常就意味着“我要开始写文档解析程序了。”现在至少大部分常规场景不用从零开始搞。上传完文件别急着开始聊天这个地方我觉得挺容易被忽略。很多人第一次做知识库会觉得文件上传成功事情就结束了。实际上不是。知识库最后好不好用跟切片质量关系特别大。比如一个产品说明书原文是退款说明 1. 商品签收后7天内可以申请退款 2. 已激活的软件产品不支持退款 3. 定制商品不支持无理由退款。如果切片的时候切成退款说明 1. 商品签收后7天内下一片变成可以申请退款 2. 已激活的软件……那后面检索出来的内容就可能很奇怪。所以知识库上传完成以后最好先看看每个知识块完整不完整标题有没有和正文分开表格有没有乱条款有没有被截断一个 Chunk 是不是塞了太多不相关内容很多时候 RAG 回答不准不一定是大模型不行。而是前面根本没找到正确资料。第三步创建一个对话Agent知识库弄好以后就可以新建应用。最简单的方式是做一个对话 Agent然后把刚才的知识库关联进去。整个过程大概就是用户问题 ↓ FastGPT 检索知识库 ↓ 找到相关内容 ↓ 交给大模型 ↓ 生成答案这时候一个最基础的企业知识问答就已经跑起来了。第四步写好Prompt虽然有了知识库但 Prompt 还是要配。例如你可以写你是公司的产品客服助手。 回答问题时优先参考知识库内容。 如果知识库里没有相关资料请直接说明没有找到相关信息不要自己编造。 回答尽量简洁。这个很好理解。知识库决定的是模型能看到什么资料。Prompt 决定的是模型应该怎么回答。两者不是一回事。第五步实际问几个问题接下来就可以直接测试。比如问产品A支持退款吗这时候我一般不会只看最终答案。还会顺便看一下FastGPT 到底检索出了哪些知识。因为如果答案有问题可以顺着流程查用户问题 ↓ 有没有检索到正确内容 ↓ Prompt有没有问题 ↓ 模型有没有理解错这样比一看回答不准就直接换模型靠谱得多。工作流是FastGPT另外一个比较实用的地方如果只是做知识问答其实到这里就差不多了。但真实业务很多时候不会只有用户提问 ↓ AI回答比如售后客服可能是用户提出问题 ↓ 判断是退货还是维修 ↓ 查产品售后规则 ↓ 查订单 ↓ 判断订单是否满足条件 ↓ 生成处理建议这时候就需要工作流。FastGPT 官方对节点的解释其实挺直观一个节点可以理解成程序里的一个 Function 或者接口。我觉得这个解释比“低代码编排”容易理解多了。以前我们可能写if(...){...}else{...}再写getOrder()searchKnowledge()callLLM()现在一部分逻辑可以直接在工作流里连起来。例如用户输入 ↓ 判断问题类型 ↓ 知识库搜索 ↓ 调用订单API ↓ AI生成结果所以工作流本质上并不神秘。就是把原来写在代码里的部分执行流程变成可视化节点。FastGPT不是只能在它自己网页里用这个也是我刚接触时比较关心的问题。FastGPT 可以只当后端。最终用户完全可以不知道你用了 FastGPT。例如你自己做一个网站Electron 软件SaaS企业内部系统小程序APP结构可以是用户 ↓ 你的前端 ↓ 你的后端 ↓ FastGPT ↓ 大模型FastGPT 官方提供 Dev API 和 System OpenAPI同时官方也强调可以通过标准 API 把 FastGPT 接到现有业务系统里。这一点其实挺重要。因为它意味着 FastGPT 并不是一定要取代你的后端。它完全可以只是你后端里的一个 AI 服务。那为什么不直接调大模型API聊到这里就可以把这两种方式放在一起看了。如果直接调大模型你的系统 ↓ 大模型API好处很明显。代码链路最短而且所有东西都在自己手里。你想怎么控制Prompt上下文Token缓存模型路由并发成本都可以。但代价也一样明显。只要开始涉及知识库和复杂 AI 逻辑就要自己继续补RAGEmbedding向量库文档解析工作流对话管理工具调用管理后台FastGPT 则是你的系统 ↓ FastGPT ↓ 大模型多了一层。但也正是这一层把很多通用能力给你封装起来了。所以我不觉得这两种方式谁一定比谁先进。更多还是看项目。如果只是一段文字 → 大模型 → 一个结果我肯定直接调 API。如果是知识库 RAG 工作流 Agent 业务接口那我大概率会先考虑 FastGPT 这种平台而不是上来就把所有轮子重新造一次。FastGPT的同类产品也不少FastGPT 不是唯一一个做这件事情的产品。现在这一类平台其实已经很多了。如果你去看 FastGPT 官方自己的 Comparison Hub它直接把Dify RAGFlow MaxKB列成主要比较对象。我觉得这三个也确实最有代表性。先说DifyDify 和 FastGPT 是非常直接的同类产品。Dify 官方的定位是一个用于构建 AI 工作流的开源平台同时提供模型接入、RAG、Agent、低代码工作流和 API。所以很多人在做项目选型的时候确实经常会纠结FastGPT 还是 Dify我自己的理解是Dify 的“应用开发平台”味道会更重一些。它的 Workflow、插件体系、Agent、外部服务接入做得比较完整。官方现在的插件体系甚至已经分到了ToolModelAgent StrategyDatasourceTriggerExtension这些类型。所以如果你的项目本身流程很复杂外部工具很多插件和 Agent 逻辑占比比较高Dify 很值得比较。再说RAGFlowRAGFlow 一看名字就知道它早期非常强调 RAG。到现在官方首页依然把自己描述为面向 AI Agent 的开源 RAG 引擎并且重点强调数据摄取、文档处理、混合检索、rerank 和 Agent 编排。所以如果你的项目是这种几万份PDF 大量扫描文档 各种表格 复杂企业资料 对检索准确率要求很高那 RAGFlow 往往会比较值得研究。简单说就是FastGPT 更容易让我想到知识库 AI应用 工作流RAGFlow 更容易让我想到文档 检索 RAG当然现在大家都在互相补功能RAGFlow 现在也已经有 Agent 平台和可视化工作流了所以这个区别更多是“侧重点”不是严格的能力边界。MaxKB也属于这一类MaxKB 官方定位是“企业级智能体平台”。它现在同样支持RAG 工作流 Agent MCP 主流大模型并且明显比较强调企业知识库、智能客服、内部知识问答这些场景。MaxKB 官方给出的典型使用流程也很直白添加模型 ↓ 创建知识库 ↓ 创建应用 ↓ 发布应用复杂一点再进入高级编排。所以如果主要需求就是企业知识库、客服、内部助手这一类东西FastGPT 和 MaxKB 会比较容易被放在一起比较。这几个东西怎么简单区分如果非要用一句话帮它们做个粗略区分我大概会这么理解产品我个人比较直观的理解FastGPT知识库、RAG、工作流比较均衡适合快速把 AI 接进业务Dify更偏完整 AI 应用开发平台Workflow 和插件生态比较值得关注RAGFlowRAG 和复杂文档检索特色更明显MaxKB比较偏企业知识库和智能体落地这里一定要强调一下这不是功能清单。也不是说 Dify 不能做知识库或者 FastGPT 不能做复杂工作流。实际上这些产品现在已经越来越像了。基本都在往LLM RAG 知识库 Workflow Agent Tools MCP这条路走。所以真实项目选型最好别看宣传页上谁打的勾最多。最简单的办法反而是拿自己真实的一批文档、几个真实问题、一个真实工作流分别搭一遍。谁用起来最顺谁的检索效果好谁更容易接现有系统就选谁。FastGPT 官方自己的对比页面现在其实也建议用相同条件做 POC而不是只看功能表。这个思路我比较认同。FastGPT最大的价值到底是什么讲到最后我觉得 FastGPT 最大的价值其实特别简单。不是“它比直接调大模型聪明”。模型还是那个模型。你后面接的是 DeepSeek最终负责回答的还是 DeepSeek。接的是 GPT最终负责回答的还是 GPT。FastGPT 帮你解决的是模型周围那些重复度很高但是做起来又挺麻烦的东西。例如文档导入 文档切片 Embedding 知识库 向量检索 RAG Prompt Workflow Agent API如果每做一个项目都重新写一遍确实很浪费时间。尤其一个项目还在 MVP 阶段时我觉得更没必要。产品到底有没有人用还不知道就先花两个月自己开发知识库平台、工作流平台和向量检索系统我个人觉得有点本末倒置。更现实的方式可能是先用FastGPT跑通 ↓ 把产品做出来 ↓ 验证有没有价值 ↓ 业务真的起来以后 ↓ 再决定哪些东西需要自己开发如果以后发现RAG 策略高度定制检索量特别大延迟要求特别高成本需要压得很极致工作流完全不适合平台有大量特殊算法那再把某一部分抽出来自己做也来得及。哪些情况我会直接用模型接口说完 FastGPT 的好处也不能把它说成什么项目都需要。下面这种功能用户输入一篇文章 ↓ 让DeepSeek总结 ↓ 返回摘要我肯定不会上 FastGPT。直接一条 API 就解决了。再比如一句中文 ↓ 翻译成英文或者商品标题 ↓ 生成5条广告文案都没太大必要加中间层。直接调用模型的优点就是简单。而且简单本身就是很大的优点。哪些情况FastGPT开始有价值我觉得主要是下面几种。第一种企业内部资料问答。你有产品资料 公司制度 培训文档 售后政策 FAQ希望 AI 基于这些东西回答。那知识库和 RAG 基本躲不开。第二种AI 客服。除了知识库还可能需要查订单 查库存 查物流 判断售后规则这时候 Workflow 和 API 调用就开始有用了。第三种内部 AI 工具。比如员工输入客户需求 ↓ 查询公司产品资料 ↓ 生成方案 ↓ 调用CRM ↓ 保存结果这种东西如果全写代码当然也能做但工作流平台确实会省不少事。第四种就是快速验证产品。这可能是我最推荐 FastGPT 的场景。因为前期真正应该验证的其实是这个 AI 功能有没有人要。而不是我们的向量数据库是不是自己搭的。最后简单总结一下如果只是第一次接触 FastGPT我觉得不用把它想得太复杂。可以直接理解成大模型 负责生成和推理 FastGPT 负责知识库、RAG、工作流、Agent这些中间能力 你的程序 负责真正的业务和产品直接接模型 API就像你自己买了一台发动机。自由度很高但发动机之外的很多东西你得自己装。FastGPT 更像已经帮你把一部分通用结构搭好了。你不用每次都重新研究文档怎么切 向量怎么存 RAG怎么写 知识库后台怎么做 工作流怎么编排可以更快进入真正的业务开发。所以我的理解一直是FastGPT 的价值不在于替代大模型而在于替代一部分重复的 AI 工程开发。至于最终选 FastGPT、Dify、RAGFlow、MaxKB还是全部自己开发没有统一答案。项目越简单越应该直接调 API。项目开始涉及知识库、RAG、工作流和 Agent这类平台的价值就越明显。如果项目最后真的做到很大很多底层能力又可能逐渐回到自研。这其实跟以前的软件开发也差不多。早期先用成熟工具把事情做出来。等真正知道哪里是瓶颈了再去优化那个瓶颈。没必要一开始就什么都自己造。 简单聊聊FastGPT
最近在做一些 AI 应用相关的东西FastGPT 用得比较多所以想简单聊聊这个工具。先说结论。如果你的需求只是调用一次大模型比如把一段文字交给 DeepSeek 总结一下或者让 GPT 帮你改写一段文案那么完全没必要上 FastGPT直接调模型接口就可以了。但如果你的需求开始涉及知识库、公司内部资料、RAG、工作流、多个模型节点、业务接口调用这些东西FastGPT 就会比较省事。我最开始接触 FastGPT 时其实也有个疑问大模型本身不是已经有 API 了吗我为什么还要在中间再加一层 FastGPT用一段时间以后我觉得这个问题的答案很简单。FastGPT 真正帮我们解决的并不是“怎么调用大模型”而是调用大模型以后那一堆本来需要自己开发的东西。FastGPT到底是干什么的FastGPT 官方现在把自己定义为一个基于大语言模型的 AI Agent 应用开发平台里面集成了知识库问答、可视化工作流、Agent 编排、工具调用等能力。通俗一点说它就是夹在你的业务系统和大模型之间的一层。大概是这样你的程序 ↓ FastGPT ↓ DeepSeek / Qwen / 豆包 / 其他模型FastGPT 自己并不是一个大模型。真正负责“思考”和“生成答案”的还是后面的 DeepSeek、Qwen、豆包这些模型。它更像是帮你把这些模型组织起来。比如Prompt 怎么配置历史对话怎么处理企业资料怎么做成知识库文档怎么切片怎么做 Embedding怎么检索知识怎么做 RAG怎么搭工作流怎么调用外部 API怎么把最后的 AI 能力提供给自己的程序这些事情 FastGPT 已经帮你做掉了一大部分。所以它的价值其实不是我不用写代码就能调大模型了。而是我不用自己从头写一整套 AI 应用基础设施了。这两个概念还是不太一样。直接调用大模型其实非常简单比如我们现在做一个最简单的功能用户问一句话然后把这句话交给模型。后端代码大概就是constresponseawaitclient.chat.completions.create({model:xxx,messages:[{role:user,content:帮我总结一下这段内容}]})到这里其实已经完成了一个最基础的 AI 功能。所以单纯看“大模型调用”这件事情真的没什么复杂的。问题通常出现在下一步。假设你要做的不是一个简单聊天框而是公司产品知识助手。员工可以问产品A支持哪些功能产品A的退货政策是什么产品B和产品C有什么区别这时候直接调大模型接口就开始不够用了。因为模型并不知道你公司的内部资料。例如最新产品说明书售后政策企业内部制度私有产品参数培训文档公司数据库这些东西大模型本身是没有的。于是就会引出一个现在做 AI 应用经常会听到的词RAG。RAG其实没那么玄乎RAG 全称叫 Retrieval-Augmented Generation中文一般翻译成“检索增强生成”。名字看起来挺唬人原理其实很朴素不要让模型直接凭自己的记忆回答先帮它查一下资料。比如用户问产品A能不能退货系统先去你的公司资料里找到了产品A支持7天无理由退货已经拆封的特殊商品除外……然后再把这段资料和用户的问题一起交给大模型。实际上发给模型的内容可能类似请根据下面的公司资料回答问题。 参考资料 产品A支持7天无理由退货已经拆封的特殊商品除外。 用户问题 产品A能不能退货模型看了资料以后再回答。这就是最简单的 RAG。理论并不复杂。真正麻烦的是怎么从几千篇甚至几万篇资料里面快速找到刚才那一段。总不能每次有人提问都把整个公司的 PDF、Word、Excel 全塞给大模型。这显然不现实。于是你还得继续往下做。真正麻烦的是RAG后面的工程通常一套知识库系统大概会经历这么一个流程PDF / Word / Markdown / Excel ↓ 文档解析 ↓ 文本切片 ↓ Embedding ↓ 生成向量 ↓ 向量数据库用户提问的时候再走用户问题 ↓ Embedding ↓ 向量检索 ↓ 找出相关知识 ↓ 拼到 Prompt 里 ↓ 调用大模型 ↓ 返回结果这里面每一步其实都能继续拆。例如文档上传。你得处理PDFWordTXTMarkdownExcel然后还要考虑PDF 能不能正确解析表格怎么办扫描件怎么办图片怎么办标题层级会不会丢文件更新以后怎么重新入库文档解析完以后又碰到切片。一份 100 页的 PDF你不可能整个塞进一个知识块。所以要拆成Chunk 1 Chunk 2 Chunk 3 Chunk 4 ……但切多大合适500 字1000 字按段落按标题前后要不要重叠不同业务答案都不一样。切完以后还要 Embedding。再把 Embedding 存到向量数据库。然后实现检索、召回、排序有时候还要加 rerank。最后还要自己控制系统 Prompt 知识库内容 历史聊天记录 用户问题怎么组合起来。所以最后经常会出现一个挺有意思的情况真正调用大模型 API 的代码只有几十行。但是围绕它做的知识库、RAG、检索、管理后台、工作流可能写了几千行甚至更多代码。这也是 FastGPT 这类工具存在的原因。FastGPT到底帮我们省了什么FastGPT 官方现在已经把知识库、文档处理、知识检索、工作流、Agent 等能力整合在了一起。所以刚才那套流程如果自己做可能是你的前端 ↓ 你的后端 ↓ 文档处理 ↓ 文本切片 ↓ Embedding ↓ 向量数据库 ↓ 知识检索 ↓ Prompt 拼装 ↓ 模型调用 ↓ 会话管理用了 FastGPT 以后可以简化成你的前端 / 系统 ↓ FastGPT API ↓ 知识库 / Workflow / Agent ↓ 大模型当然这不代表上面那些东西不存在。它们依然存在。只是不用你自己全部重新开发一遍了。这是我觉得 FastGPT 最实在的地方。FastGPT怎么用如果第一次使用我不太建议上来就研究复杂工作流。FastGPT 官方现在的快速上手也是按照几个典型场景来介绍对话 Agent知识库 对话 AgentWorkflowAgent V2其中最容易理解 FastGPT 价值的我觉得还是知识库 对话 Agent。我们可以直接拿“公司产品知识助手”做例子。第一步先把模型配好FastGPT 后面还是要调用大模型所以首先需要有模型。比如DeepSeek 豆包 GLM Qwen ……这里有两个概念需要区分一下。一个是聊天模型。也就是负责用户提问 ↓ 模型回答另外一个是 Embedding 模型。Embedding 模型并不是用来跟人聊天的。它主要负责把文字转换成向量用于知识检索。比如产品A支持7天无理由退货经过 Embedding 模型以后会变成一串数字。系统通过这些向量去判断“这个商品不要了怎么办”和“7天无理由退货”虽然字面不一样但意思比较接近。第二步创建知识库模型准备好以后可以先创建一个知识库。例如公司产品资料然后把你现有的资料传进去产品说明书.pdf 售后政策.docx 产品参数.xlsx FAQ.mdFastGPT 会负责后面的知识处理流程。官方目前的知识库能力包括数据导入、预处理、知识匹配和问答并且针对 PDF 等复杂文档也提供结构化解析能力。以前这一步通常就意味着“我要开始写文档解析程序了。”现在至少大部分常规场景不用从零开始搞。上传完文件别急着开始聊天这个地方我觉得挺容易被忽略。很多人第一次做知识库会觉得文件上传成功事情就结束了。实际上不是。知识库最后好不好用跟切片质量关系特别大。比如一个产品说明书原文是退款说明 1. 商品签收后7天内可以申请退款 2. 已激活的软件产品不支持退款 3. 定制商品不支持无理由退款。如果切片的时候切成退款说明 1. 商品签收后7天内下一片变成可以申请退款 2. 已激活的软件……那后面检索出来的内容就可能很奇怪。所以知识库上传完成以后最好先看看每个知识块完整不完整标题有没有和正文分开表格有没有乱条款有没有被截断一个 Chunk 是不是塞了太多不相关内容很多时候 RAG 回答不准不一定是大模型不行。而是前面根本没找到正确资料。第三步创建一个对话Agent知识库弄好以后就可以新建应用。最简单的方式是做一个对话 Agent然后把刚才的知识库关联进去。整个过程大概就是用户问题 ↓ FastGPT 检索知识库 ↓ 找到相关内容 ↓ 交给大模型 ↓ 生成答案这时候一个最基础的企业知识问答就已经跑起来了。第四步写好Prompt虽然有了知识库但 Prompt 还是要配。例如你可以写你是公司的产品客服助手。 回答问题时优先参考知识库内容。 如果知识库里没有相关资料请直接说明没有找到相关信息不要自己编造。 回答尽量简洁。这个很好理解。知识库决定的是模型能看到什么资料。Prompt 决定的是模型应该怎么回答。两者不是一回事。第五步实际问几个问题接下来就可以直接测试。比如问产品A支持退款吗这时候我一般不会只看最终答案。还会顺便看一下FastGPT 到底检索出了哪些知识。因为如果答案有问题可以顺着流程查用户问题 ↓ 有没有检索到正确内容 ↓ Prompt有没有问题 ↓ 模型有没有理解错这样比一看回答不准就直接换模型靠谱得多。工作流是FastGPT另外一个比较实用的地方如果只是做知识问答其实到这里就差不多了。但真实业务很多时候不会只有用户提问 ↓ AI回答比如售后客服可能是用户提出问题 ↓ 判断是退货还是维修 ↓ 查产品售后规则 ↓ 查订单 ↓ 判断订单是否满足条件 ↓ 生成处理建议这时候就需要工作流。FastGPT 官方对节点的解释其实挺直观一个节点可以理解成程序里的一个 Function 或者接口。我觉得这个解释比“低代码编排”容易理解多了。以前我们可能写if(...){...}else{...}再写getOrder()searchKnowledge()callLLM()现在一部分逻辑可以直接在工作流里连起来。例如用户输入 ↓ 判断问题类型 ↓ 知识库搜索 ↓ 调用订单API ↓ AI生成结果所以工作流本质上并不神秘。就是把原来写在代码里的部分执行流程变成可视化节点。FastGPT不是只能在它自己网页里用这个也是我刚接触时比较关心的问题。FastGPT 可以只当后端。最终用户完全可以不知道你用了 FastGPT。例如你自己做一个网站Electron 软件SaaS企业内部系统小程序APP结构可以是用户 ↓ 你的前端 ↓ 你的后端 ↓ FastGPT ↓ 大模型FastGPT 官方提供 Dev API 和 System OpenAPI同时官方也强调可以通过标准 API 把 FastGPT 接到现有业务系统里。这一点其实挺重要。因为它意味着 FastGPT 并不是一定要取代你的后端。它完全可以只是你后端里的一个 AI 服务。那为什么不直接调大模型API聊到这里就可以把这两种方式放在一起看了。如果直接调大模型你的系统 ↓ 大模型API好处很明显。代码链路最短而且所有东西都在自己手里。你想怎么控制Prompt上下文Token缓存模型路由并发成本都可以。但代价也一样明显。只要开始涉及知识库和复杂 AI 逻辑就要自己继续补RAGEmbedding向量库文档解析工作流对话管理工具调用管理后台FastGPT 则是你的系统 ↓ FastGPT ↓ 大模型多了一层。但也正是这一层把很多通用能力给你封装起来了。所以我不觉得这两种方式谁一定比谁先进。更多还是看项目。如果只是一段文字 → 大模型 → 一个结果我肯定直接调 API。如果是知识库 RAG 工作流 Agent 业务接口那我大概率会先考虑 FastGPT 这种平台而不是上来就把所有轮子重新造一次。FastGPT的同类产品也不少FastGPT 不是唯一一个做这件事情的产品。现在这一类平台其实已经很多了。如果你去看 FastGPT 官方自己的 Comparison Hub它直接把Dify RAGFlow MaxKB列成主要比较对象。我觉得这三个也确实最有代表性。先说DifyDify 和 FastGPT 是非常直接的同类产品。Dify 官方的定位是一个用于构建 AI 工作流的开源平台同时提供模型接入、RAG、Agent、低代码工作流和 API。所以很多人在做项目选型的时候确实经常会纠结FastGPT 还是 Dify我自己的理解是Dify 的“应用开发平台”味道会更重一些。它的 Workflow、插件体系、Agent、外部服务接入做得比较完整。官方现在的插件体系甚至已经分到了ToolModelAgent StrategyDatasourceTriggerExtension这些类型。所以如果你的项目本身流程很复杂外部工具很多插件和 Agent 逻辑占比比较高Dify 很值得比较。再说RAGFlowRAGFlow 一看名字就知道它早期非常强调 RAG。到现在官方首页依然把自己描述为面向 AI Agent 的开源 RAG 引擎并且重点强调数据摄取、文档处理、混合检索、rerank 和 Agent 编排。所以如果你的项目是这种几万份PDF 大量扫描文档 各种表格 复杂企业资料 对检索准确率要求很高那 RAGFlow 往往会比较值得研究。简单说就是FastGPT 更容易让我想到知识库 AI应用 工作流RAGFlow 更容易让我想到文档 检索 RAG当然现在大家都在互相补功能RAGFlow 现在也已经有 Agent 平台和可视化工作流了所以这个区别更多是“侧重点”不是严格的能力边界。MaxKB也属于这一类MaxKB 官方定位是“企业级智能体平台”。它现在同样支持RAG 工作流 Agent MCP 主流大模型并且明显比较强调企业知识库、智能客服、内部知识问答这些场景。MaxKB 官方给出的典型使用流程也很直白添加模型 ↓ 创建知识库 ↓ 创建应用 ↓ 发布应用复杂一点再进入高级编排。所以如果主要需求就是企业知识库、客服、内部助手这一类东西FastGPT 和 MaxKB 会比较容易被放在一起比较。这几个东西怎么简单区分如果非要用一句话帮它们做个粗略区分我大概会这么理解产品我个人比较直观的理解FastGPT知识库、RAG、工作流比较均衡适合快速把 AI 接进业务Dify更偏完整 AI 应用开发平台Workflow 和插件生态比较值得关注RAGFlowRAG 和复杂文档检索特色更明显MaxKB比较偏企业知识库和智能体落地这里一定要强调一下这不是功能清单。也不是说 Dify 不能做知识库或者 FastGPT 不能做复杂工作流。实际上这些产品现在已经越来越像了。基本都在往LLM RAG 知识库 Workflow Agent Tools MCP这条路走。所以真实项目选型最好别看宣传页上谁打的勾最多。最简单的办法反而是拿自己真实的一批文档、几个真实问题、一个真实工作流分别搭一遍。谁用起来最顺谁的检索效果好谁更容易接现有系统就选谁。FastGPT 官方自己的对比页面现在其实也建议用相同条件做 POC而不是只看功能表。这个思路我比较认同。FastGPT最大的价值到底是什么讲到最后我觉得 FastGPT 最大的价值其实特别简单。不是“它比直接调大模型聪明”。模型还是那个模型。你后面接的是 DeepSeek最终负责回答的还是 DeepSeek。接的是 GPT最终负责回答的还是 GPT。FastGPT 帮你解决的是模型周围那些重复度很高但是做起来又挺麻烦的东西。例如文档导入 文档切片 Embedding 知识库 向量检索 RAG Prompt Workflow Agent API如果每做一个项目都重新写一遍确实很浪费时间。尤其一个项目还在 MVP 阶段时我觉得更没必要。产品到底有没有人用还不知道就先花两个月自己开发知识库平台、工作流平台和向量检索系统我个人觉得有点本末倒置。更现实的方式可能是先用FastGPT跑通 ↓ 把产品做出来 ↓ 验证有没有价值 ↓ 业务真的起来以后 ↓ 再决定哪些东西需要自己开发如果以后发现RAG 策略高度定制检索量特别大延迟要求特别高成本需要压得很极致工作流完全不适合平台有大量特殊算法那再把某一部分抽出来自己做也来得及。哪些情况我会直接用模型接口说完 FastGPT 的好处也不能把它说成什么项目都需要。下面这种功能用户输入一篇文章 ↓ 让DeepSeek总结 ↓ 返回摘要我肯定不会上 FastGPT。直接一条 API 就解决了。再比如一句中文 ↓ 翻译成英文或者商品标题 ↓ 生成5条广告文案都没太大必要加中间层。直接调用模型的优点就是简单。而且简单本身就是很大的优点。哪些情况FastGPT开始有价值我觉得主要是下面几种。第一种企业内部资料问答。你有产品资料 公司制度 培训文档 售后政策 FAQ希望 AI 基于这些东西回答。那知识库和 RAG 基本躲不开。第二种AI 客服。除了知识库还可能需要查订单 查库存 查物流 判断售后规则这时候 Workflow 和 API 调用就开始有用了。第三种内部 AI 工具。比如员工输入客户需求 ↓ 查询公司产品资料 ↓ 生成方案 ↓ 调用CRM ↓ 保存结果这种东西如果全写代码当然也能做但工作流平台确实会省不少事。第四种就是快速验证产品。这可能是我最推荐 FastGPT 的场景。因为前期真正应该验证的其实是这个 AI 功能有没有人要。而不是我们的向量数据库是不是自己搭的。最后简单总结一下如果只是第一次接触 FastGPT我觉得不用把它想得太复杂。可以直接理解成大模型 负责生成和推理 FastGPT 负责知识库、RAG、工作流、Agent这些中间能力 你的程序 负责真正的业务和产品直接接模型 API就像你自己买了一台发动机。自由度很高但发动机之外的很多东西你得自己装。FastGPT 更像已经帮你把一部分通用结构搭好了。你不用每次都重新研究文档怎么切 向量怎么存 RAG怎么写 知识库后台怎么做 工作流怎么编排可以更快进入真正的业务开发。所以我的理解一直是FastGPT 的价值不在于替代大模型而在于替代一部分重复的 AI 工程开发。至于最终选 FastGPT、Dify、RAGFlow、MaxKB还是全部自己开发没有统一答案。项目越简单越应该直接调 API。项目开始涉及知识库、RAG、工作流和 Agent这类平台的价值就越明显。如果项目最后真的做到很大很多底层能力又可能逐渐回到自研。这其实跟以前的软件开发也差不多。早期先用成熟工具把事情做出来。等真正知道哪里是瓶颈了再去优化那个瓶颈。没必要一开始就什么都自己造。