用 FastGPT 的 API 接进自己的系统：四种接法和各自的代价
FastGPT 官方把自己定位成可以作为「后端即服务」使用——也就是说，它不只是一个让你在网页上聊天的产品，还可以作为能力层被你自己的系统调用。
这正是很多项目真正需要的形态：用户不该知道背后有个 FastGPT，他们只是在用你的产品。
但「接进自己的系统」有四种接法，代价差别很大。选错了，要么返工，要么留下安全隐患。
具体的接口路径、参数和鉴权方式请以 FastGPT 官方文档为准，会随版本变化。这篇讲的是架构选择。
接法一：前端直连
你的网页或小程序直接调用 FastGPT 的接口。
优点：改造量最小，后端几乎不用动。想快速验证效果的时候，这条路最快。
致命问题：密钥会暴露在前端。
任何写在前端代码里的密钥，都等于公开。用户打开开发者工具就能看到，或者直接从打包后的代码里搜出来。拿到密钥的人可以随意调用你的接口——刷你的额度、读你的知识库内容。
结论：只适合内部验证，绝不能上生产。 这条我们见过不止一次有人踩，通常是在赶工期的时候「先这么上，之后再改」，然后就没有之后了。
接法二：后端代理（大多数项目的正确答案）
前端调你自己的后端，你的后端再去调 FastGPT。
这是绝大多数生产项目应该用的方式。 它解决的不只是密钥问题：
密钥留在服务端，前端完全接触不到。
能做鉴权。 只有登录用户能问，或者只有某些角色能问某些内容。这件事只能在你自己的后端做——FastGPT 不知道你的用户体系。
能做限流。 防止单个用户刷爆额度，也防止恶意调用。
能记日志。 谁问了什么、系统答了什么，留在你自己的库里。这对排查问题和后续优化很关键，也常常是甲方的审计要求。
能做内容过滤。 在问题进去之前和答案出来之后各加一道，处理敏感内容。
代价：后端要写一层转发逻辑，还要处理流式响应的透传——如果要打字机效果，这一层不能简单地等结果全部返回再转发，需要边收边转。这是这条路最容易卡住的技术点，动手前先确认你的后端框架支持流式转发。
接法三：事件驱动，不做实时对话
不是用户问一句答一句，而是由某个事件触发处理。
比如：新工单进来，自动匹配知识库里的相似案例推给客服；新文档上传，自动生成摘要和标签。
适用场景：处理不需要实时、且能批量做的事。
优点：没有响应时间压力，可以从容重试；能批量处理，效率高；不需要处理流式响应，实现简单得多。
要注意：失败要能重试且不重复处理，处理结果要有地方落库。这些是批处理的通用问题，跟用哪个平台无关。
接法四：只借检索，生成自己做
这是最灵活的一种，也最少被想到。
只用它的知识库检索能力，拿到相关的文档片段之后，生成环节用你自己选的模型、你自己写的提示词。
什么时候值得这么做：
- 你对生成环节有特殊要求——固定的输出格式、特定的语气、要和你自己的业务数据混合
- 你想在不同场景用不同的模型，而不是全局配一个
- 你已经有一套自己的对话逻辑，只是缺一个检索能力
代价：你要自己处理提示词组装、上下文长度控制、模型调用。工作量明显变大，但换来的是完全的控制权。
判断标准：如果你发现自己一直在跟平台的生成逻辑较劲——改提示词改不到想要的效果、想控制的东西控制不了——那说明该走这条路了。
四种接法怎么选
按顺序问自己：
要不要上生产？ 不要 → 接法一，快速验证完就扔。要 → 往下看。
是实时对话还是后台处理？ 后台处理 → 接法三，简单可靠。实时对话 → 往下看。
生成环节需要深度控制吗？ 不需要 → 接法二，这是最常见的答案。需要 → 接法四。
大部分项目的答案是接法二。
接进去之后，还有三件事要处理
一、答不上来怎么办。 检索不到相关内容时，系统应该明确说不知道并给出下一步，而不是硬答。这个兜底逻辑写在你的后端，不要指望模型自觉。
二、响应慢了怎么办。 检索加生成是有耗时的，前端要有加载状态。超时了要有兜底提示，不能一直转圈。
三、平台挂了怎么办。 你依赖的是一个外部服务（哪怕是你自己部署的）。它不可用的时候，你的产品应该降级——显示提示、转人工、或者退回到关键词搜索，而不是整个功能白屏。
第三条最常被忽略，因为开发阶段服务一直是好的。但一旦上线，这是迟早会遇到的情况。
会话状态放在哪，是个要提前定的架构问题
多轮对话意味着要记住上下文。这个状态存在哪，有三种选择，各有代价。
存在平台那边。 由平台维护会话，你的后端只传会话标识。实现最简单，但你对上下文没有控制权——想在中间插入业务信息、想裁剪历史、想跨设备同步，都不好办。
存在你自己的库里。 每次调用时由你的后端组装完整上下文传过去。控制权完全在你手上，代价是要自己处理上下文长度——对话轮数多了之后，历史会越来越长，既费钱又可能超出模型的上下文限制，需要做裁剪或摘要策略。
混合。 平台维护基础会话，你的后端额外存一份业务侧的记录用于分析和审计。这是不少生产项目的实际选择——用户体验交给平台，数据留在自己这边。
判断标准：如果你的业务需要在对话过程中注入外部信息（用户的订单状态、权限、历史行为），那必须自己管上下文，否则做不到。
顺带说一个容易被忽略的点：会话记录属于业务数据。 如果对话内容涉及客户信息、订单细节，那这些记录的敏感程度等同于业务数据本身，存储和访问控制都要按这个标准来，不能当成「日志」随便放。
什么时候说明该做定制开发了
如果你发现自己在做下面这些事，说明已经在平台边界上了：
- 为了绕开平台限制，在自己的代码里写了大量补丁逻辑
- 检索效果需要针对你的文档结构做深度调优，而平台给的配置项不够
- 需要把对话能力和业务系统深度联动，做必须机械保证执行的兜底机制
这时候继续在平台上加补丁，成本会超过重新实现。判断标准我们写在低代码 Agent 平台的能力边界。
我们做过这类活——有客户要把对话功能嵌进他自己的小程序，按他提供的产品资料调模型、调知识库、调工具调用；也为一个需要安全兜底的场景做过关键词识别、强制转人工和人工后台。如果你正卡在类似的地方，可以聊聊。
顺带提一句：用 FastGPT 做交付类项目，许可这一条是通的——它明确允许作为应用开发平台交付给企业。详见开源 Agent 平台的许可证差别。