FastGPT
Sealos（labring/FastGPT） · 知识库问答起家，许可对集成商友好
FastGPT 是国内团队做的知识库问答平台。官方对自己的定位是：基于大模型的知识库平台，提供数据处理、RAG 检索、可视化 AI 工作流编排等开箱即用的能力，不需要大量配置就能搭出复杂的问答系统。
和 Dify 相比，它的重心更靠近知识库这一侧——如果你的需求本来就是「把一堆文档变成能问答的东西」，它的路径更直接。
它擅长什么
知识库链路完整。 数据导入、处理、切分、检索、问答，整条链路在一个界面里，不用东拼西凑。
可视化工作流编排。 除了单纯的问答，也能编排多步骤的流程。
可自部署。 这是它相比托管型平台的核心价值，对数据有要求的项目走这条路。
中文场景考虑得比较多。 国内团队做的，文档和社区讨论都是中文，遇到问题找答案比英文项目省事。
许可：对做项目的人友好
FastGPT 用的是 Apache 2.0 加附加条款，要点：
- 明确允许商业化，官方 LICENSE 里写了可以作为「后端即服务」用于你的其他应用，或者作为应用开发平台交付给企业
- 需要单独商业授权的情况有两种：做类似 FastGPT 的多租户 SaaS 服务，以及移除或修改控制台的 LOGO 与版权信息
对系统集成商来说，这个许可结构和 Dify 基本一致，都属于「能拿去接活」的那一类。跟 n8n 的 fair-code 许可有本质区别，选型时值得先看这一条。
这段是提示不是法律意见，商用前请自己读官方 LICENSE，拿不准就直接联系官方问。
什么情况下它会不够用
需求重心不在知识库时。 如果你要做的是复杂的多步骤业务流程编排，或者大量对接外部系统，那它的长处用不上。
检索需要深度定制时。 平台给的调优空间总是有限的。当切块策略、检索逻辑需要按你的文档结构做专门设计时，就到了平台的边界。
要接进已有系统时。 能通过 API 对接，但要做到深度嵌入——比如把对话能力嵌进甲方自己的小程序、和业务系统联动做安全兜底——仍然需要写代码。
判断标准我们整理在这篇：什么时候必须从低代码转向原生开发。
平台功能与界面会随版本迭代，本页讲的是定位与许可结构，具体功能以官方文档为准。
相关教程（7）
用 FastGPT 的 API 接进自己的系统：四种接法和各自的代价
把知识库问答嵌进已有产品，接法不止一种。前端直连、后端代理、事件驱动、只借检索——四种方式的适用场景、风险和改造成本完全不同。
FastGPT 部署与交付：集成商视角的六个决定
FastGPT 的许可明确允许交付给企业，这让它在集成项目里很实用。但从装起来到能验收，中间还有六个决定要做。
FastGPT 部署要多少硬件：三个变量决定，别照抄配置表
网上的配置推荐大多没说前提。真正决定硬件规模的是三件事：跑不跑本地模型、多少人用、知识库多大。这篇讲怎么估、怎么验证、怎么给客户报。
FastGPT 知识库出现乱码：从文件编码到解析的排查顺序
传进去的文档变成一堆问号或方块字。这类问题九成出在上传之前，不在系统里。这篇按链路给出排查顺序和各环节的判断方法。
知识库权限：不同人该看到不同答案，这件事必须在系统层解决
全公司共用一个知识库，销售能查到人事的工资表——这不是配置疏忽，是架构没设计。这篇讲三种隔离方式和各自的适用场景。
知识库优化的正确顺序：先改文档，最后才动参数
大部分人的优化顺序是反的——一上来就调参数、换模型，却从没看过系统实际读到了什么。这篇给出按收益排序的五步。
知识库项目七成工作量在文档，不在系统
扫描件、表格、过期文档、口口相传的经验——这些才是知识库项目真正的成本。这篇讲文档摸底该看什么、怎么估工作量、哪些坑要写进合同。