1.1 FastGPT 是什么：开源定位与核心价值
我最初接触FastGPT时，以为它就是个聊天机器人框架。用了一段时间才发现，它更像一个AI应用的操作系统。开源定位让个人开发者和小团队也能搭建私有知识库问答，不用从零造轮子。
它的核心价值在于把大模型能力封装成可视化模块。我不需要写太多代码，拖拽就能连接知识库和LLM。这种低门槛设计特别吸引我。从企业视角看，FastGPT解决了数据隐私和定制化需求。我把内部文档喂进去，就能得到精准回答。开源协议允许商用，这点对创业公司很关键。我见过不少团队用FastGPT快速验证产品想法，省下了大笔开发费用。
1.2 核心能力拆解：知识库、RAG、工作流、Agent 与 API
知识库是我最常用的功能。上传PDF、Word、Markdown，系统自动切片、向量化。检索时根据相似度召回。我调整过切片大小和召回数量，效果差异明显。有时候切片太小，答案会碎片化；切片太大，又容易混入无关信息。这个调参过程需要耐心。
RAG是知识库的引擎。工作流让我把多个步骤串起来，比如先分类问题再检索。Agent能自主调用工具，比如搜索网页或执行代码。这些能力单独用已经不错，组合起来更强大。我通过API把问答能力嵌入到公司OA里，员工不用切换系统。
API能力让FastGPT融入现有系统。这些能力组合起来，覆盖了从简单问答到复杂自动化的需求。我试过用工作流加Agent做个自动写周报的工具，省了不少时间。从开发者角度看，API文档清晰，调用示例丰富。从产品经理角度看，可视化编排降低了沟通成本。
1.3 技术架构概览：前端交互、后端服务、向量库与模型接入
前端用Next.js，界面清爽。我作为用户，在浏览器里就能配置所有东西。后端是Node.js，处理请求和调度。向量库支持Milvus、PGVector等。我选了Milvus，数据量大时性能稳定。有一次我导入十万条文档，检索速度依然很快。
模型接入通过OneAPI，可以接OpenAI、Claude、通义千问等。我试过切换模型，只需改配置。整个架构是松耦合的。我可以单独升级向量库，或者替换嵌入模型。这种灵活性对运维很友好。我作为运维人员，最怕系统绑死。FastGPT的模块化设计让我能按需替换组件。
前端交互、后端服务、向量库、模型接入，每一层都有选择空间。我可以在本地跑小模型做测试，上线时换成云端大模型。这种平滑过渡的能力，让技术选型不再痛苦。从架构师视角看，FastGPT的边界清晰，扩展点明确。
1.4 版本与生态：社区版、商业版、应用模板与插件体系
社区版免费，功能已经很强。我一开始用社区版做原型，后来公司买了商业版，多了多租户和审计日志。商业版还有技术支持。应用模板让我快速上手。官方提供了客服、知识库助手等模板。我直接导入，改改提示词就能用。有一次我花半小时就搭好了一个产品问答机器人。
插件体系还在成长，但已经能连接外部API。生态方面，社区活跃。我在GitHub上提过issue，作者回复很快。文档虽然有些地方不够细，但示例代码多。商业版用户有专属群。我作为团队负责人，会考虑长期维护成本。社区版适合小团队试水，商业版适合有合规要求的企业。模板和插件降低了二次开发的门槛。
我认识一些独立开发者，他们用社区版接私活，收入不错。企业用户则更看重商业版的权限管理和数据隔离。FastGPT的版本策略给了不同规模团队灵活的选择。
1.5 适用边界：FastGPT 适合解决哪些问题
FastGPT适合有私有数据、需要精准问答的场景。比如企业规章制度查询、产品手册解答。我帮朋友的小公司搭了一个，客服效率提升明显。它也适合快速验证AI想法。我用工作流做了个自动写周报的工具。从我的经验看，知识密集型行业最能受益。
如果你要做超大规模实时推荐，或者需要极低延迟，FastGPT可能不是最佳选择。它不适合完全零代码的纯小白？其实可视化已经很简单。理解RAG原理能帮你调得更好。我的经验是，先明确业务问题，再决定用哪些模块。有一次我试图用它做实时股票分析，发现响应速度跟不上。
我作为咨询顾问，经常被问FastGPT能不能做这个那个。我的回答是：看你的数据量和响应要求。知识库问答、文档处理、内部支持，这些它很擅长。高并发交易系统或者复杂科学计算，它就不合适。明确边界，才能用好工具。
2.1 部署前准备：硬件配置、操作系统、Docker 与网络环境
我头一回在本地搭 FastGPT，用了一台旧笔记本，16GB 内存，四核 i5。Docker 跑起来后，知识库导入慢得让人想砸键盘。后来换成 32GB 内存、八核处理器、NVMe 固态的机器，流畅多了。官方推荐最低 16GB，我的建议是 32GB 起步。如果你打算本地跑 Embedding 和 LLM，显存至少 8GB。没有 GPU 也行，调用云端 API 一样跑。磁盘留出 100GB，向量库和日志会越长越大。我见过有人用树莓派折腾，能跑，但只适合玩具级测试。
操作系统方面，Ubuntu 22.04 LTS 最省心。我用过 CentOS 7，Docker 版本太老，升级麻烦。Windows 用户装 WSL2，记得把 WSL 内存限制调大。macOS 的 Docker Desktop 也能用，M 系列芯片兼容性不错。Docker 装 24 以上版本，Docker Compose 用 v2。网络环境是隐形杀手。国内拉取 Docker Hub 镜像经常超时。我配了阿里云镜像加速器，速度提升明显。公司内网需要代理，提前设好 HTTP_PROXY 环境变量。
从运维角度看，我习惯把部署机器单独划分 VLAN。个人开发者用云服务器，2核4G 也能跑，但别开知识库。团队负责人要评估并发量。十个人同时用和一百个人同时用，配置差好几倍。我踩过的坑：没开虚拟化，Docker 启动报错。BIOS 里打开 VT-x 或 AMD-V。还有交换分区，内存不够时能救命，但别依赖它。
2.2 基于 Docker Compose 的快速部署实操
我一般直接克隆官方仓库。git clone 之后进入目录，复制 .env.example 为 .env。这个文件里要改几个关键值：数据库密码、OneAPI 地址、FastGPT 的访问端口。默认端口 3000，如果被占用就改。我的习惯是把所有密码换成随机字符串。之后 docker compose up -d。第一次拉镜像比较久，可以去泡杯茶。看到所有容器状态是 running，就成功了一半。
访问 http://localhost:3000，能看到登录页。我遇到过 502 错误，通常是 fastgpt 容器还没准备好。等两分钟刷新。还有一次数据库连不上，检查 .env 里的 MONGODB_URI 和 PG 配置。容器日志用 docker logs -f 容器名 看。我通常先看 oneapi 容器，再看 fastgpt 容器。部署脚本里有个 init 容器，负责初始化数据库。如果它退出了，说明初始化有问题。
团队部署时，我会把 compose 文件拆成生产版和开发版。生产版加 restart: always，加日志切割。开发版挂载本地代码，方便调试。有人问能不能不用 Docker。可以，但依赖装到你怀疑人生。Docker Compose 让部署可重复，换台机器照样跑。我帮客户部署时，写了个 shell 脚本，自动改配置、拉镜像、启动。省得每次手敲。
2.3 模型与向量库配置：OneAPI、LLM、Embedding、Rerank
OneAPI 是模型网关。我登录 OneAPI 后台，添加渠道。OpenAI 渠道填 API Key，国内模型填对应密钥。渠道添加后，测试模型是否可用。随后在 FastGPT 的配置文件里填 OneAPI 的地址和令牌。LLM 我常用 GPT-4o 或通义千问 Max。Embedding 选 text-embedding-3-small 或 bge-m3。本地跑 bge-m3 需要 4GB 显存。Rerank 模型推荐 bge-reranker-v2-m3，能明显提升检索精度。
向量库我选 Milvus。FastGPT 的 .env 里有 MILVUS_ADDRESS。默认用内置的 Milvus，数据量大了再换集群版。PGVector 更轻量，适合小规模。我对比过，十万条以下 PGVector 够用。配置完重启 fastgpt 容器。在知识库设置里选 Embedding 模型和向量库。有一次我忘了配 Rerank，检索结果差很多。加上 Rerank 后，回答准确率上升。
从开发者视角，模型路由能省钱。简单问题走小模型，复杂问题走大模型。我配了多个渠道，设置权重和优先级。从运维视角，监控模型调用延迟和费用。OneAPI 自带统计。我设了每日限额，防止意外扣费。本地模型用 Ollama 接入 OneAPI，延迟低但效果可能打折。我试过 Qwen2.5 7B，做简单问答没问题。
2.4 初始化与验证：账号创建、知识库导入、应用测试
部署完第一次访问，系统提示创建 root 账号。我填邮箱和密码。登录后进入工作台。导入知识库，我点“新建知识库”，选向量模型。上传一份 PDF 产品手册。系统自动切片，我调整切片大小为 500 字符，重叠 50。切片太小答案不完整，太大检索不精准。我习惯先导入小样本，测试召回效果。用“预览”功能看切片内容。
创建应用，选“知识库问答”模板。关联刚才的知识库。写提示词，比如“你是一个客服助手，根据知识库回答”。测试问题：“产品保修多久？”如果答案准确，说明配置成功。我还会测边界问题，比如知识库没有的内容。它应该回答“不知道”，而不是瞎编。调整温度参数，0.1 更稳定。API 调用用 Postman 测试，填上 API Key 和 base URL。
从用户角度，我会让同事试用，收集反馈。他们经常问奇怪的问题。从产品经理角度，验证流程要记录，方便复制。我建了个检查清单：账号能登录、知识库能检索、应用能回答、API 能调用。全过一遍，才算部署完成。有一次我忘了开防火墙端口，外部访问不了。本地测试正常，远程失败。检查网络策略。
2.5 常见问题排查、版本升级、数据备份与安全加固
容器起不来，先看日志。docker compose logs 能看到所有服务输出。常见错误：端口冲突、密码错误、镜像拉取失败。模型调用报错，去 OneAPI 看渠道状态。知识库检索不准，调整切片大小和 Rerank 阈值。我遇到过向量维度不匹配，换 Embedding 模型后要重建索引。内存溢出，加 swap 或限制容器内存。
版本升级，我习惯先备份。导出 MongoDB 和 PostgreSQL 数据，还有 Milvus 的 collection。之后 git pull 拉新代码，看 .env 有没有新增变量。docker compose down，再 up -d。数据库迁移脚本会自动跑。升级后验证核心功能。数据备份用 cron 每天跑。我写了个脚本，打包数据库和上传的文件，传到对象存储。保留最近七天。
安全加固，改默认密码，开 HTTPS，用 Nginx 反代。限制访问 IP，只允许公司网络。FastGPT 的管理后台加二次验证。OneAPI 的令牌设置过期时间。我还会关闭不需要的端口。从合规角度，审计日志要开启。商业版有审计功能，社区版靠 Nginx 日志。定期更新镜像，修复漏洞。别把数据库端口暴露公网。我见过有人图省事，结果被挖矿。
3.1 产品定位差异：FastGPT 与 Dify 的设计哲学
我最早用 Dify 搭建了一个客服机器人，功能挺多，配置起来像拼乐高。后来接触 FastGPT，发现它更像一把专门切知识库的刀，刀锋很利。FastGPT 的设计哲学围绕 RAG 展开，把知识库检索、切片、重排这些环节做得细致。Dify 的野心更大，它想成为 LLM 应用的操作系统，工作流、Agent、插件、工具调用都塞进去。我团队里有人喜欢 Dify 的全面，有人偏爱 FastGPT 的专注。
从开发者视角看，FastGPT 的代码结构更直接，改起来不绕弯。Dify 的抽象层多，扩展时需要理解它的概念模型。我帮客户选型时，会问一句：你主要想解决问答，还是想编排复杂任务？答案偏向问答，FastGPT 顺手。答案偏向自动化流程，Dify 更合适。两个产品都在进化，边界慢慢模糊，设计哲学的差异依然清晰。
3.2 核心功能对比：RAG、工作流、Agent、插件与工具调用
RAG 方面，我实测过同一批 PDF 文档。FastGPT 内置的检索模式开箱即用，调整切片大小和 Rerank 阈值很直观。Dify 的 RAG 也能用，但它更鼓励你把检索节点嵌入工作流。我做过一个对比：FastGPT 回答产品保修问题准确率高，Dify 需要多配几个节点才达到类似效果。Rerank 模型两家都支持，FastGPT 的集成更无感。
工作流这块，Dify 明显更成熟。节点类型丰富，拖拽体验顺滑。我搭过一个多步审批流程，Dify 半小时搞定。FastGPT 的工作流也在进步，适合轻量级场景。Agent 能力上，Dify 支持 ReAct、Function Calling，工具调用灵活。FastGPT 的 Agent 偏向知识库增强，做问答型助手很稳。插件生态 Dify 有市场，FastGPT 插件体系简单些，API 调用足够覆盖常见需求。
工具调用我试过让两者都去查天气。Dify 配置插件后直接返回结果，FastGPT 需要写 API 工具。从产品经理角度，Dify 的插件商店省开发时间。从运维角度，FastGPT 的依赖少，出问题好排查。我团队里做复杂自动化的同事偏爱 Dify，做知识库问答的同事守着 FastGPT。
3.3 部署与运维对比：本地化能力、云服务、扩展性与成本
本地部署我两边都做过。FastGPT 用 Docker Compose 起服务，依赖 MongoDB、PG、Milvus、OneAPI，半小时能跑通。Dify 组件更多，除了数据库还有 Redis、Weaviate 或 Qdrant，我第一次部署花了一小时。硬件要求 FastGPT 更亲民，16GB 内存的机器能跑。Dify 建议 32GB 起步，不然工作流一多就卡。
云服务方面，Dify 有官方云版，注册就能用，省去运维。FastGPT 也有商业版，但云服务不是它的主打。数据敏感的企业，本地部署是硬需求。我帮一家医院部署 FastGPT，数据不出内网。扩展性上，Dify 的插件和自定义工具更容易接入第三方系统。FastGPT 靠 API 和 Webhook 也能扩展，需要多写点代码。
成本账我算过。开源版都免费，商业版 Dify 按调用量或坐席收费，FastGPT 按版本授权。小团队预算有限，FastGPT 社区版够用。大企业要做 AI 中台，Dify 的扩展性和云服务更省心。我见过一个公司两个都用：FastGPT 做内部知识库，Dify 做对外智能客服。运维上 FastGPT 日志清晰，Dify 的链路追踪需要额外配。
3.4 生态与社区对比：文档、模板、更新频率与企业支持
文档这块，FastGPT 的中文文档写得接地气，例子直接能抄。Dify 的文档中英文都有，内容详细，有时版本更新后文档滞后。我查一个工作流节点配置，Dify 文档里还是旧版截图，得去社区翻帖子。FastGPT 的文档更新跟得紧，社区版功能说明清楚。
模板方面，Dify 提供大量应用模板，从客服到内容生成都有。FastGPT 的模板偏知识库问答，数量少但精准。更新频率两家都活跃，Dify 社区更大，GitHub 星数多，讨论热烈。FastGPT 的社区群响应快，官方人员经常冒泡。我提过一个 issue，FastGPT 两天给回复，Dify 一周才有人理。
企业支持上，FastGPT 商业版提供技术支持和定制开发。Dify 也有企业版，支持 SLA 和私有化部署。我帮客户选型时，会看他们有没有专职运维。有运维团队，Dify 的复杂架构能驾驭。没有运维，FastGPT 省事。社区生态的繁荣程度 Dify 领先，FastGPT 在知识库垂直领域更扎实。
3.5 选型建议：不同团队、业务场景与预算如何选择
小团队做知识库问答，我推荐 FastGPT。上手快，部署简单，一个人能维护。创业公司预算紧，FastGPT 社区版免费，商业版价格也友好。我见过三个人的团队用 FastGPT 搭出内部问答系统，两周上线。业务场景如果是客服、工单辅助、文档检索，FastGPT 的 RAG 调优更省心。
中大型团队要做 AI 应用平台，Dify 更合适。工作流编排、插件市场、多租户管理，这些 Dify 做得深。业务场景涉及复杂自动化、多步骤任务、工具调用，Dify 的节点和 Agent 能力占优。预算充足的企业，Dify 企业版提供审计、权限、SLA。我服务过一家金融公司，用 Dify 做信贷审批流程，扩展性满足需求。
没有绝对的好坏。我自己的做法：FastGPT 做知识库问答，Dify 做工作流自动化，两者通过 API 互通。选型时问三个问题：核心需求是问答还是流程？团队运维能力如何？数据能否上云？答案清晰了，选择就简单。我见过有人跟风选 Dify，结果工作流没用上，知识库效果不如 FastGPT。也见过硬用 FastGPT 做复杂 Agent，开发成本翻倍。匹配场景比追新重要。
4.1 企业知识库与智能问答系统
我帮一家做医疗器械的公司部署了 FastGPT，把产品手册、合规文档、售后记录全部灌进知识库。员工在内部网页上提问，比如“某型号监护仪的电池续航参数是多少”，系统直接从 PDF 里抽出答案，还带原文出处。这家公司之前用传统搜索，关键词匹配经常翻出无关文件。换到 FastGPT 后，RAG 的切片和重排把准确率拉高了一大截。他们的合规部门很满意，因为答案有引用，方便追溯。
从运维角度看，整套服务跑在内网，数据不出公司。我配置了混合检索，向量加关键词，冷门型号也能查到。业务方反馈说，新员工培训周期短了。以前要翻三天手册，现在问几句就上手。我还帮一家律所搭过类似系统，律师查法条和案例，FastGPT 把判决书切片后检索，比人工翻文件夹快很多。不过律所对数据隔离要求高，我用了独立的知识库分区。
4.2 智能客服、工单辅助与内部支持
电商客服场景我做过一个落地。客户问“退货地址在哪”，FastGPT 从帮助中心知识库匹配答案，通过 API 回传到客服系统。遇到复杂问题，它自动生成工单草稿，客服改一改就能提交。客服主管告诉我，重复问题减少了六成。我让 FastGPT 接了订单查询工具，用户问“我的包裹到哪了”，系统调 API 拿物流状态，再组织语言回复。这套东西不需要人工介入。
内部 IT 支持也用得上。员工问“VPN 怎么连”“密码重置流程”，FastGPT 直接回答。碰到需要权限的请求，它触发工作流，给 IT 部门发邮件。我观察到一个细节：FastGPT 的回答语气可以调，我们设成简洁风格，员工觉得不啰嗦。运维同事喜欢它的日志，每次问答都有记录，排查问题方便。客服团队那边，我加了人工转接按钮，机器人搞不定的直接转人工，体验平滑。
4.3 文档处理、内容生成与知识管理
我处理过一批混合格式的文档，PDF、Word、Excel 都有。FastGPT 的文档解析能抽出表格和段落，切片后送 Embedding。有个客户是做工程咨询的，项目报告几千页，以前找历史数据靠人肉。现在问“2022 年某桥梁项目的抗震参数”，几秒出结果。内容生成方面，我用 FastGPT 的工作流写产品描述。先检索知识库里的技术规格，再让 LLM 组织成营销文案。运营同事改改就能发，效率翻倍。
知识管理这块，我帮一家公司做了版本控制。旧版政策文件下架，新版重新索引。FastGPT 支持知识库标签，不同部门看到不同内容。有个坑我踩过：文档更新后没重新切片，问答还是旧答案。后来我设了定时任务，每周同步一次。内容生成时，我限制 LLM 只能引用知识库里的内容，避免胡编。客户反馈说，生成的培训材料准确度高，省了编辑校对的时间。
4.4 数据分析、业务自动化与流程集成
销售团队想用自然语言查数据。我拿 FastGPT 接了一个数据库查询工具，用户问“上个月华东区销售额多少”，系统生成 SQL，跑完返回结果。这比教销售写查询简单多了。业务自动化方面，我做过审批流程。员工提交报销，FastGPT 检查知识库里的财务制度，合规的直接通过，不合规的退回并说明原因。Webhook 把结果推到 OA 系统，全程不用人盯。
流程集成我试过接 ERP 和 CRM。FastGPT 的 API 做中间层，CRM 里的客户问题自动匹配知识库，销售能看到推荐话术。有个制造企业用 FastGPT 做设备故障排查，操作工描述现象，系统检索维修手册，给出步骤。维修主管说，以前等工程师到场要半小时，现在操作工自己就能处理简单故障。我注意到底层模型换了之后，工具调用的稳定性有波动，后来固定了模型版本。
4.5 教育科研、个人助手与垂直领域应用
高校科研团队用 FastGPT 管理文献。研究生把 PDF 论文导入，问“某方法的实验设置是什么”，系统从多篇论文里找答案。我帮一个实验室部署时，他们最看重引用来源。FastGPT 返回原文片段，方便写综述。有个教授用它做课题申报，检索过往项目书，避免重复。教育场景里，我还见过做在线答疑的，学生问数学题，FastGPT 从教材知识库找相似例题，给解题思路。
个人助手方面，我自己用 FastGPT 搭了一个。笔记、日程、待办都扔进去，问“上周开会提到什么”，它能翻出来。垂直领域我接触过农业和医疗。农业客户用 FastGPT 查病虫害防治，输入症状，返回农药配方和注意事项。医疗那边谨慎些，只做内部知识库，不对外。我帮一个乡镇卫生院部署，医生查药品说明书和诊疗指南。他们反馈说，比翻书快，而且不会漏掉禁忌症。这些场景的共同点是知识密集，FastGPT 的 RAG 正好对口。
5.1 性能优化：索引策略、缓存、并发与模型路由
我帮那家医疗器械公司上线半年后，知识库文档涨到两万多份。问答响应开始变慢，尤其早上高峰期。我调了索引策略。FastGPT 默认用 HNSW，我根据数据量把 efSearch 和 M 参数微调。向量维度 1024，切片长度从 500 改成 800，重叠 80。检索召回率没降，延迟少了三分之一。冷门型号查询以前要 1.2 秒，现在 0.7 秒。我还加了关键词索引，混合检索权重调到 0.3 向量加 0.7 关键词？不对，通常向量权重大。我根据业务调，医疗术语关键词重要，关键词权重给到 0.4。效果不错。
缓存这块我踩过坑。FastGPT 本身有 Redis 缓存，默认只缓存会话。我加了 Embedding 缓存层。相同问题直接命中，不走模型。电商客服场景里，Top 20 常见问题占了 60% 流量。缓存命中率上去后，GPU 压力小很多。并发上，我用了 OneAPI 的负载均衡。三个模型实例，两个本地一个云。并发请求排队，超时设 15 秒。模型路由按任务分：简单问答走小模型，复杂推理走大模型。成本降了四成。有次云模型 API 抖动，自动切到本地，用户没感知。
5.2 安全与权限：多租户、审计、数据隔离与合规
律所那个项目对安全要求高。我做了多租户隔离。每个案件组独立知识库，API Key 绑定空间。用户登录后只能看自己组的内容。FastGPT 的角色权限我配了三级：管理员、编辑、只读。审计日志开了全量。谁问了什么、检索了哪些文档、返回了什么，全部落库。合规部门每月导出一次。数据隔离上，向量库按租户分 collection。Embedding 也独立。有次客户误操作，把 A 组文档传到 B 组，审计日志立刻告警。我五分钟内回滚。
数据合规方面，我帮一家金融客户做了脱敏。输入问题里的身份证号、手机号自动替换。知识库里的敏感字段用正则过滤。FastGPT 支持自定义预处理钩子，我写了个脚本。审计还覆盖 API 调用。外部系统通过 API 访问，每次请求带 trace ID。日志存到 ELK，保留 180 天。客户过等保测评时，这些日志帮了大忙。我建议生产环境一定开 HTTPS，内部服务也走 TLS。密码策略强制 12 位，双因素认证。
5.3 监控运维：日志、指标、告警与成本控制
监控我用的 Prometheus 加 Grafana。FastGPT 暴露了 /metrics 接口。我盯几个核心指标：QPS、P95 延迟、错误率、Token 消耗。电商客服大促前，我设了告警。QPS 超过 200 或者延迟超过 3 秒，钉钉群通知。有次向量库磁盘快满，告警提前两小时发出来。我扩容后没影响业务。日志分三类：访问日志、应用日志、审计日志。访问日志看流量，应用日志排错。我用 Loki 聚合，查起来快。
成本控制是老板关心的。我做了 Token 用量看板。按应用、按模型、按天统计。发现某个内部助手每天烧 50 美元，查下来是循环调用。我加了最大轮次限制。模型路由也省钱：Embedding 用本地 BGE，Rerank 用本地 bge-reranker，只有复杂生成才走 GPT-4。每月成本从 3000 降到 800。还有缓存命中率，我设了目标 40%。达不到就优化切片。运维同事每周看一次报表。有次云模型涨价，我提前切到国产模型，成本没波动。
5.4 扩展开发：API、Webhook、插件与二次开发
FastGPT 的 API 我接了很多系统。电商客服那边，订单查询用 OpenAPI 对接。用户问物流，FastGPT 调我的 API 拿数据。Webhook 用于事件通知。工单创建后，Webhook 推到企业微信。我写过插件，把内部 CMDB 接进来。FastGPT 插件市场有模板，改改就能用。二次开发方面，我改过前端。品牌色、Logo、欢迎语。后端我加了自定义鉴权。FastGPT 是开源，代码能读能改。有次需要支持 LDAP 登录，我照着文档改了 auth 模块。
API 设计我注意限流和重试。外部调用带 API Key，每分钟 60 次。失败重试三次，指数退避。Webhook 签名验证，防止伪造。插件开发用 TypeScript，定义好输入输出 schema。我做过一个天气插件，客服问“今天下雨吗”，FastGPT 调插件返回。二次开发别改核心逻辑，用扩展点。FastGPT 的 workflow 支持自定义节点。我写了个 Python 节点，做数据清洗。社区版够用，商业版有更多企业特性。我建议先看文档，再动代码。
5.5 生产落地路线图与最佳实践
生产落地我走过完整流程。我一开始做 POC，选一个部门，两周验证。指标定好：准确率 85%，延迟 2 秒内。POC 通过后试点，扩大到三个团队。我盯着反馈，每周迭代。试点稳定后全公司推广。推广前做压力测试，模拟 500 并发。我用的 Locust。测试发现数据库连接池不够，调大后通过。上线后前两周每天复盘。日志、告警、用户反馈一起看。有次召回率下降，查出来是文档更新没重新索引。
最佳实践我总结几条。知识库切片按文档类型调，技术手册 800 字，法律条文 400 字。混合检索权重根据业务定。缓存一定要开，Embedding 缓存优先。模型路由做故障转移。安全上多租户隔离加审计。监控告警阈值别设太紧，容易狼来了。成本看板每周 review。扩展开发用 API 和 Webhook，别硬编码。生产环境用 Docker Compose 或 K8s，我倾向 K8s 做高可用。备份每天一次，向量库和配置文件一起备。版本升级先看 changelog，灰度发布。我帮客户落地了五个项目，这套路线图没出过大问题。
