为什么需要多平台支持

智能客服的最终效果，很大程度上取决于背后的 AI 引擎。但不同团队、不同业务场景对 AI 引擎的需求千差万别：

• 有些团队已经用扣子（Coze）搭好了工作流和知识库
• 有些团队偏好 Dify 的开源可私有化部署
• 有些团队在 FastGPT 上维护了大量的文档向量数据
• 还有一些团队有完全自研的模型，只需要一个 HTTP 通道

我们的做法是：不做选择题，全都要。 一个后台统一配置，四种引擎自由切换。

引用原文：客服系统多智能体架构深度解析：一个后台，四种 AI 引擎随心切换

统一入口，统一配置

系统通过两个关键配置项控制 AI 引擎的切换——

配置项	说明
聊天补全模型	coze / fastgpt / dify / http（或其他 OpenAI 兼容模型名）
接口地址	各平台的 API 端点
接口密钥	API Key

用户在设置页面只需切换一次下拉框，修改接口地址，即可完成从”扣子”到”Dify”的切换，无需重启服务。后端入口通过 BigModelName 做分支分发，然后走各自的分支逻辑，下面逐一拆解。

---

一、Coze（扣子）智能体

扣子是字节跳动推出的一站式 AI Bot 开发平台，支持可视化搭建工作流、知识库、插件等。

接入方式

用户在扣子后台创建一个 Bot，拿到 Bot ID 和 API Key，然后在客服系统中：

• 聊天补全模型 → 选择 coze
• 接口地址 → 填入 Bot ID
• 接口密钥 → 填入 API Key

实现原理

系统为每个访客自动创建并维护独立的扣子会话，保证访客之间对话隔离、多轮上下文不串扰。核心分三步：

第一步：会话管理。 每个访客首次对话时，系统调用扣子 v1 API https://api.coze.cn/v1/conversation/create 创建一个 conversation_id 并持久化。后续该访客的所有消息都复用同一个会话 ID。

第二步：流式对话。 使用扣子 v3 API 的流式接口 https://api.coze.cn/v3/chat，携带 conversation_id、历史 additional_messages 上下文，设置 stream: true 和 auto_save_history: true，实现真正的流式多轮对话。

第三步：实时推流。 系统解析扣子返回的 SSE 事件流，监听 event:conversation.message.delta 类型事件，逐字提取 content 字段，并通过 WebSocket 实时推送到前端，给用户”打字机”般的流畅体验。

Coze 模式特点

特性	说明
流式输出	✅ SSE 流式推送，逐字显示
会话隔离	✅ 自动创建 + 持久化，多轮对话不串扰
历史消息	✅ 传递最近的问答对作为上下文
适用场景	已用扣子搭建 Bot 的团队，零代码复用

---

二、Dify 智能体

Dify 是开源的 LLM 应用开发平台，支持可视化编排 AI 工作流、RAG 知识库、Agent 等。与 Coze 理念相似，但核心区别在于支持私有化部署。

接入方式

• 聊天补全模型 → 选择 dify
• 接口地址 → 填入 Dify 的 API 根地址（如 http://your-dify-server，系统自动拼接 /chat-messages）
• 接口密钥 → 填入 Dify 应用的 API Key

实现原理

流式对话。 向 Dify 的 /chat-messages 端点发 POST 请求，关键参数：

{
  "response_mode": "streaming",
  "user": "访客ID",
  "query": "用户问题",
  "conversation_id": "会话ID（首次为空）",
  "inputs": {}
}

请求头携带 Authorization: Bearer <API_KEY>，Dify 返回标准 SSE 事件流。

SSE 解析。 与 Coze 不同，Dify 返回的是标准 SSE 格式——以 data: 为前缀的行，每行一个 JSON 对象，系统解析 answer 字段并逐字推送，同时每次都从事件中提取 conversation_id。

会话持久化。 对比 Coze 预先创建会话，Dify 的模式更轻量：首次请求不传 conversation_id，由 Dify 自动创建并返回，系统在流式响应首帧中拿到 conversation_id 后持久化到访客属性。当 message_end 事件到来时，流结束。

Dify 模式特点

特性	说明
流式输出	✅ SSE 流式推送
会话管理	✅ 自动，Dify 侧生成 conversation_id
私有化部署	✅ 支持，填入内网地址即可
适用场景	有私有化需求的团队、自建 RAG 知识库场景

---

三、FastGPT 智能体

FastGPT 是另一款知名的开源知识库问答平台，专注 LLM + 知识库的 RAG 能力。

接入方式

• 聊天补全模型 → 选择 fastgpt
• 接口地址 → 填入 FastGPT 的 API 地址
• 接口密钥 → 填入 FastGPT 的 API Key

实现原理

FastGPT 对外暴露的是标准 OpenAI 兼容接口，所以直接走通用 GPT 路径。这个路径的核心能力包括三重能力叠加：

第一层：向量知识库搜索。 用户问题 → Embedding 模型编码 → Qdrant 向量数据库检索 → 取 Top-K 相似文档作为参考知识。

第二层：系统提示词拼接。 将检索到的知识作为 [[quote]] 占位符的值，与预设的 system prompt 合并，形成带上下文的完整 system 消息。同时支持历史 N 条对话的上下文窗口拼接。

第三层：流式调用。 走标准 OpenAI Chat Completion 流式接口，支持 DeepSeek-R1 等推理模型的思考链格式化渲染（用 <pre> 包裹推理过程，正文正常展示）。

FastGPT 模式特点

特性	说明
流式输出	✅ OpenAI 兼容 SSE 流
知识库	✅ 外挂向量知识库（Qdrant），搜索优化 + 相似度阈值
协议兼容	✅ 任意 OpenAI 接口兼容的服务都能接入
思考链	✅ 自动识别 DeepSeek-R1 模型并渲染推理内容
适用场景	已用 FastGPT 搭建知识库的团队；或作通用兼容通道

---

四、自定义 HTTP 智能体

这是灵活度最高的模式，专为自研模型、私有服务、内部 API 设计。

请求格式（系统 → 你的接口）

系统以 POST + Content-Type: application/json 调用你的接口：

{
  "visitor_id": "访客唯一ID",
  "visitor_name": "访客昵称",
  "avatar": "访客头像URL",
  "content": "用户发送的消息原文",
  "kefu_name": "当前客服名称"
}

响应格式（你的接口 → 系统）

你的接口只需返回一个字段：

{
  "result": "你的智能体回复内容"
}

系统拿到 result 后，自动以客服身份发送给访客。

安全保护

• URL 空值校验：未配置 chatGPTUrl 时直接终止，打印日志
• 120 秒超时：超时自动失败，不阻塞主流程
• 调用失败兜底：网络错误或返回空 result 时，走”未知问题学习”逻辑，不影响服务可用性

实践示例（Python Flask）

仅需 20 行即可接入：

from flask import Flask, request, jsonify

app = Flask(__name__)

@app.route('/my-agent', methods=['POST'])
def my_agent():
    data = request.get_json()
    user_message = data.get("content", "")
    visitor_name = data.get("visitor_name", "用户")

    # 接入你自己的逻辑：
    # - 调用 OpenAI / 文心一言 / 通义千问
    # - 查询知识库 RAG
    # - 基于规则的自动回复
    reply = f"你好 {visitor_name}，你问的是：{user_message}。我是自定义智能体！"

    return jsonify({"result": reply})

if __name__ == '__main__':
    app.run(port=5000)

然后在客服系统后台配置：

• 聊天补全模型 → http
• 接口地址 → http://你的服务器:5000/my-agent

完成！

HTTP 模式特点

特性	说明
流式输出	❌ 同步等待完整结果
会话上下文	❌ 需自行维护（可通过 visitor_id 追踪）
灵活度	⭐⭐⭐⭐⭐ 极高
适用场景	私有模型、内部 API、规则引擎组合

---

四种模式全景对比

                         用户发送消息
                              │
                    ┌─────────▼─────────┐
                    │  读取 BigModelName  │
                    └─────────┬─────────┘
                              │
       ┌──────────┬──────────┼──────────┬──────────┐
       ▼          ▼          ▼          ▼          ▼
   ┌──────┐  ┌──────┐  ┌──────┐  ┌──────┐  ┌──────────┐
   │ coze │  │ dify │  │fastgpt│ │ http │  │ gpt-3.5  │
   │ 扣子 │  │ Dify │  │FastGPT│ │ 自定义│  │ 等兼容   │
   └──┬───┘  └──┬───┘  └──┬───┘  └──┬───┘  └────┬─────┘
      │         │         │         │            │
      ▼         ▼         ▼         ▼            ▼
   创建会话   无传参    向量检索   POST JSON   OpenAI标准
   SSE流式   Dify返回   prompt拼接  解析result  流式接口
   历史消息  conversation  OpenAI流   120s超时  知识库嵌入
   持久化ID   _id自动返回  deepseek             流式推送
      │         │         │         │            │
      └─────────┴─────────┴─────────┴────────────┘
                              │
                    ┌─────────▼─────────┐
                    │  WebSocket推前端   │
                    └───────────────────┘

对比维度	Coze	Dify	FastGPT	HTTP 自定义
流式输出	✅ SSE	✅ SSE	✅ OpenAI SSE	❌ 同步
会话隔离	✅ 自动	✅ 自动	✅ 历史消息	❌ 自行实现
私有化部署	❌ SaaS	✅ 开源	✅ 开源	✅ 任意
知识库	扣子内置	Dify 内置	Qdrant 外挂	自行实现
多轮对话	✅ 多对Q&A	✅ Dify管理	✅ N条上下文	❌
接入门槛	低	低	低	极低
灵活度	中	中高	高	极高
超时控制	无	无	SDK管理	120秒

---

总结

这套架构的核心思想是：把客服系统做成一个纯粹的消息管道，AI 引擎的选择权完全交给用户。

• Coze — 给用扣子搭建工作流的团队，零代码即插即用
• Dify — 给需要私有化部署 + 开源可控的团队
• FastGPT — 给已有知识库的团队，或作为 OpenAI 通用兼容通道
• HTTP 自定义 — 给有自研能力的团队，完全掌控对话逻辑

而这一切，在后台只是一个下拉框的切换。