FastGPT 部署与交付：集成商视角的六个决定
FastGPT 在做项目的人里口碑不错，原因有两个：知识库链路完整，以及许可明确允许交付给企业。
这篇从集成商的视角讲，从选型到验收要做的六个决定。
具体的部署方式、配置项和版本要求以 FastGPT 官方文档为准，会随版本变化。这篇讲决策不讲操作。
一、先确认许可这条路是通的
好消息先说：FastGPT 的许可是 Apache 2.0 加附加条款，官方在许可文件里明确写了允许商业化使用——包括作为「后端即服务」用于其他应用，以及作为应用开发平台交付给企业。
需要单独获得商业授权的情况有两种：
- 用它的源码运营类似 FastGPT 的多租户 SaaS 服务
- 移除或修改控制台里的 LOGO 与版权信息
对典型的集成项目来说，这两条基本不构成障碍：给甲方部署一套他们内部用的知识库问答系统，正常收项目费——这条路是通的。
但如果甲方要求「不能出现第三方 LOGO」，那就要提前谈，要么说服甲方接受，要么走官方的商业授权渠道。这件事要在报价之前搞清楚，不要等到验收时才发现。
这段是提示不是法律意见。同类平台的许可差别很大——n8n 只允许内部使用，详见开源 Agent 平台的许可证差别。
二、把甲方说的「私有化」问清楚
「私有化部署」这四个字在不同甲方嘴里含义差得很远，至少有三种：
第一种：装在我们的服务器上就行。 应用在甲方机房，模型调在线 API。成本最低，实施最快。
第二种：数据不能出我们的网。 那模型也必须本地部署，需要 GPU，硬件预算是另一个量级。
第三种：完全不能连外网。 除了本地模型，还要考虑离线安装、离线更新、内网镜像源这些事，实施复杂度再上一层。
这三种的报价可以差好几倍。 在方案阶段就要问清楚甲方要的是哪一种，并且把差异写进方案里让他们签字确认。
我们见过太多项目栽在这一步：报价按第一种报的，验收时甲方按第三种要求，双方都觉得对方不讲理。
三、文档摸底要在报价之前做
知识库项目的工作量，七成在文档，三成在系统。
报价前一定要看甲方的实际文档，重点看三件事：
格式。 扫描版 PDF 是最大的坑——那本质是图片，没有文字层，直接传进去等于什么都没传，需要先做 OCR。这部分工作量经常被漏算。
结构。 排版混乱、大量表格、页眉页脚干扰多的文档，切块效果差，要花时间做预处理。一份结构清晰的问答手册和一份十年积累的制度汇编，处理成本完全不同。
准确性和时效。 甲方给的文档里有没有过期内容？新旧两版制度都在，系统会随机挑一个答，而这个问题最后会算在你头上。文档治理这件事要明确写进项目范围，或者明确写进「不含」。
四、验收标准要提前定，而且要可测
「回答得准不准」是个没法验收的标准。双方各说各话，项目就卡在这。
可行的做法是提前定一批测试问题，比如三十到五十个甲方业务里真实会问的问题，双方一起确认这批问题的标准答案，验收时按这批问题跑。
这样做的好处：
- 验收有客观依据，不靠感觉
- 开发过程中就能拿它做回归测试
- 甲方在整理测试问题的过程中，自己会想清楚需求
同时要提前说明能力边界。 需要跨多个文档做对比推理的问题（「A 部门和 B 部门的标准有什么不同」），检索式问答天然不擅长——这类问题要么排除在验收范围外，要么单独设计流程处理。写在方案里，别等验收时才解释。
五、模型选择与成本结构
在线模型：效果好、无需 GPU、按调用计费。成本随使用量增长，长期大规模使用要提前算账。计费规则各家会调整，以官方最新说明为准，要算的是结构不是某个时点的单价。
本地模型：一次性硬件投入，之后边际成本低，数据不出网。代价是效果通常不如顶尖在线模型，且需要运维能力。
给甲方的建议要基于用量：试点阶段和小规模使用，在线模型更划算；确定要长期大规模用、或者有数据合规要求，才值得上本地模型。
别在方案里写死具体价格数字。 各家规则会变，写死了对你不利。写清楚计费机制和影响成本的变量，让甲方理解结构。
六、运维责任必须写进合同
交付之后谁管？这件事不写清楚，一年后一定有纠纷。
要明确的几条：
- 保修期多长，包含什么。 是只修 bug，还是包括版本升级？
- 升级怎么算。 开源项目迭代快，一年后甲方看到新功能想要，这是新项目还是免费服务？
- 响应时间。 系统出问题多久响应，这直接关系到你要不要配值班。
- 数据备份谁做。 尤其是知识库和对话记录。
- 甲方自己改坏了怎么办。 甲方管理员误删知识库、改错配置，这种情况的处理是否收费。
这些条款不是为了推卸责任，是为了让双方预期一致。 含糊过去的结果通常是：出任何问题客户都找你，而你没法收钱。
交付阶段的三个实际问题
前面五条都在签合同之前。下面三条发生在交付阶段，同样值得提前准备。
一、甲方管理员要培训，而且要留下能查的东西。
系统交付之后，日常维护知识库的是甲方的人：加文档、删过期内容、调整分类。这些操作不难，但没人教就不会做。
培训要做，但更重要的是留下可查的材料——一份带截图的操作说明，比一次两小时的培训有用得多。因为真正需要操作的时候，往往已经过去几个月，来听培训的那个人可能都换岗了。
这份材料的成本要算进报价里。 它不是附赠品，是交付物的一部分。
二、要留一条「答错了怎么反馈」的通道。
系统上线后一定会有答得不好的情况。如果没有反馈通道，甲方的感受就是「这东西不准」，然后慢慢没人用了。
做一个简单的反馈入口——用户觉得答得不对，能一键标记。这些标记就是你优化知识库的依据，也是向甲方证明系统在持续改进的材料。
三、第一个月要主动看数据。
上线后的第一个月，把用户实际问的问题调出来看一遍。你会发现两件事：
一是用户实际问的和甲方当初说的不一样——这几乎是必然的，甲方给的是他们以为的高频问题，真实数据才是准的。
二是有一批问题的答案根本不在文档里。这时候就能拿着数据回去跟甲方说：这部分需要补充资料。有数据支撑，这个沟通比空口说容易得多。
这一个月的投入，通常能决定这个项目最后是「用起来了」还是「验收完就没人用」。
一个推进顺序
- 问清「私有化」是哪一种 → 决定硬件方案和报价基准
- 看甲方真实文档 → 决定文档处理工作量
- 确认 LOGO 等许可相关要求 → 确认这条路通不通
- 定测试问题集 → 作为验收标准
- 搭最小环境跑真实文档，验证效果
- 定运维条款，再签合同
第 1、2、3 步都在签合同之前。这三步做扎实，项目风险能降一大半。
如果需求超出了平台能力——需要改代码接进甲方已有系统、需要做安全兜底机制——判断标准见低代码 Agent 平台的能力边界。这类活我们也做，可以聊聊。