一个对话框聚合 7 家大模型 + MCP 热装载，三千AI智能体的工程化思路拆解

用户990212616817
367 阅读6分钟

一个对话框聚合 7 家大模型 + MCP 热装载，三千AI智能体的工程化思路拆解

本文最后更新于 2026-05-03 / 基于 v25.3.5 源码实测

TL;DR

三千AI智能体 把多模型聚合、MCP 热装载、Agent 编排、短视频流水线、商业化模块，用 Docker Compose 编排成单机可起的一体化 AI 工作台。本文从工程化角度拆它的三个有意思的设计：

  1. 多模型聚合层 — 一个对话框切换 7 家 LLM + 多家文生图/视频
  2. MCP 热装载 — 运行时挂载工具，不重启进程
  3. License 机制 — ECDSA P-256 签域名而非签机器

源码 + 部署文档：github.com/2961799660/… 在线 Demo：**ai1.zijie.lol**（demo / Demo123456）

一、为什么这套架构值得拆

2026 年「AI 应用」的工程标准其实已经分化得很清楚：

  • 底层引擎层（Dify / LangChain / LlamaIndex）— LLMOps 工作流
  • Agent 框架层（CrewAI / AutoGen / Coze）— 多 Agent 协作
  • 业务成品层（三千AI智能体 / FastGPT 高阶玩法）— 前端 + 商业化 + 白标

业务成品层的工程难点不在「能不能跑」，在「如何把模型异构性、工具异构性、商业模块、白标系统，包成一个 90 秒拉起的 Docker Compose」。

下面拆三个最有工程美感的点。

二、多模型聚合层 — 一个对话框切 7 家

2.1 接入面

LLM 7 家：
  - GPT-5.4         (OpenAI)
  - Claude Opus 4.6 (Anthropic)
  - Gemini 3.1 Pro  (Google)
  - Kimi K2.5       (月之暗面)
  - 深度求索         (DeepSeek)
  - 智谱 GLM        (Zhipu)
  - xAI Grok        (xAI)

文生图：闪绘 / 精绘 / 可灵 omni-image / 豆包 Seedream 5.0
文生视频：创影 / 可灵动作控制 / 可灵 V3 / 豆包 Seedance 2.0 Pro / 1.x Lite

2.2 抽象设计的关键

不同 model provider 的 API contract 差异极大：

  • OpenAI 走 messages[] + tool_choice
  • Anthropic 走 messages[] + system 单独字段 + tool_use block
  • Google Gemini 走 contents[] + functionDeclarations
  • Kimi / 深度求索 / 智谱 兼容 OpenAI 格式但行为不一致
  • 国内文生图各家 webhook / 轮询 / SSE 模式都有

聚合层的核心是 provider adapter 层 + 统一的 ChatRequest / ChatResponse 协议：

interface ChatRequest {
  messages: Message[];
  model: string;        // 'gpt-5.4' / 'claude-opus-4.6' / ...
  tools?: Tool[];       // MCP-style 协议
  thinking?: boolean;   // 深度思考开关
  artifacts?: boolean;  // 代码 artifact 预览开关
}

interface ChatResponse {
  delta?: string;       // SSE 流式增量
  toolUse?: ToolCall;
  artifact?: Artifact;  // 代码 / HTML / SVG
  thinking?: string;    // 思考过程
  usage: TokenUsage;
}

每个 provider 写一个 adapter 把自家协议映射到这套接口；前端永远只面对 ChatRequest / ChatResponse。这是最朴素也最稳的设计。

2.3 切换不破坏会话状态

切模型时，前端保留 messages 历史，重新走 adapter 即可。比起每家会员开一个 tab，这里是同一个会话流里换大脑。对长上下文场景（比如分析报告写一半切 Claude）非常关键。

2.4 深度思考 + Artifacts 的工程取舍

  • 深度思考：协议层加 thinking 字段，provider 不支持就 ignore（gracefully degrade）
  • Artifacts：识别响应里的 html / svg / ```react 代码块，前端用 iframe sandbox 实时预览

这两个能力是 Claude / GPT 体验的护城河，聚合层把它工程化了。

三、MCP 热装载 — 运行时挂载工具

3.1 MCP 是什么

Model Context Protocol，由 Anthropic 牵头的工具调用协议。把「外部工具」抽象成 server，模型通过统一协议调用。

三千AI智能体内置的 MCP server：

  • 飞书 / 企微 / 钉钉 — 协作类
  • TikHub — 14+ 社媒数据接口（抖音 / 小红书 / B站 / YouTube / Twitter / Reddit / TikTok 等）
  • 小红书 — 单独的发布 / 数据接口
  • 自定义 MCP — 后台可挂任意 MCP server URL

3.2 热装载的工程价值

传统插件架构：

改插件 → 重启服务 → 用户掉线 → 重新登录

MCP 热装载架杤：

管理员后台填 MCP server URL → 服务在线 register → 立刻在对话工具列表里出现

实现机制是 MCP registry 走 Redis pubsub：worker 进程监听 channel，收到新 server 注册事件就 hot-load adapter，整个过程对在线用户无感。

这个设计对生产环境的代理商非常重要 — 客户临时要接一个新的 SaaS 工具（比如某 CRM），运维 5 分钟挂上去，不用半夜停机。

3.3 一段示例：自定义 MCP 注册

后台 → MCP 管理 → 新增：

{
  "name": "internal-crm",
  "url": "http://crm.your-domain.com/mcp",
  "auth": {
    "type": "bearer",
    "token": "xxx"
  },
  "scope": ["lead.search", "lead.create"]
}

提交后 Redis pubsub 广播 → 所有 worker 在线注册 → 模型在下一轮对话里就能调 lead.search。

四、License 机制 — ECDSA P-256 签域名

4.1 为什么签域名而不是签机器

传统 license：

  • 绑 MAC 地址 / CPU ID → 换服务器要重签
  • 绑 IP → 不能上云、不能多机部署

签域名的好处：

  • 换服务器无感 — 把 MySQL / Redis / 数据卷搬过去，license.lic 一字不动
  • 多机部署天然支持 — 同域名指向哪台机器都能验
  • 支持通配 *.buyer.com — 客户做 SaaS 多租户时，每个子站不用重签

4.2 验证流程

license.lic
├── domain: "ai.your-brand.com"  (或 *.your-brand.com)
├── version_constraint: ">=v25.0.0"
├── features: ["canvas", "mcp", "billing", "diy"]
├── expires_at: null  (终身)
└── signature: ECDSA-P256(payload, vendor_private_key)

服务启动时校验 signature + 校验 request.host ∈ domain。整个过程不联网，不打回母站，对客户合规审计非常友好。

4.3 ECDSA-P256 选型理由

  • 比 RSA-2048 短得多（签名 ~64 字节 vs 256 字节），license.lic 体积小
  • 验证速度快（适合每个请求都校验 host）
  • 主流 Go / Node / Python 标准库都原生支持，没第三方依赖
  • 抗量子还没到，但常规威胁模型够用

五、5 分钟跑起来

# clone
git clone https://github.com/2961799660/sanqian_ai.git
cd sanqian_ai

# 配置
cp .env.example .env
vim .env  # 填域名、DB 密码、模型 API key

# 起服务
docker compose up -d

# 验证
docker compose ps
curl http://localhost/api/health

容器列表：

容器角色
app主 API + 前端静态文件
worker异步任务（视频合成、批量出图、MCP register 监听）
mysql默认数据库（生产可换 RDS）
redis缓存 + pubsub（MCP 热装载靠这个）
nginx反代 + SSL 终止

最低配 4C8G / 40G 磁盘，10 分钟内拉齐。

六、几个 ad-hoc 问题

Q1：能不能只跑 LLM 不跑视频/图？

能。docker-compose.yml 把 worker 拆出来，不需要的能力关掉对应模块的 feature flag 即可。

Q2：能改成 PostgreSQL 吗？

源码档 (¥万元级) 可改 ORM 层。授权档默认 MySQL。

Q3：MCP server 自己写要多久？

按 Anthropic 官方 spec，写一个 stdio 模式的 MCP server 通常半天到一天。三千AI智能体支持 HTTP / SSE / stdio 三种 transport。

Q4：模型成本怎么控？

后台有 Token 计费 + 按次计费 + 算力多级套餐 + 用户每日额度，可以按用户 / 按工作空间 / 按 IP 限流。

Q5：跟 LangChain / LlamaIndex 关系？

定位不同。LangChain 是引擎，三千AI智能体是业务成品。如果要在工作台里集成 LangChain 写的复杂 chain，挂成 MCP server 即可。

七、写在最后

工程角度看，这套设计没有炫技：聚合层是经典 adapter pattern，热装载是 Redis pubsub，license 是经典 ECDSA。但把这些朴素的工程做到「Docker 一键启 + 90 秒可用」的成品形态，对中小团队就是把「3 个月 + 2 个工程师」的研发投入直接砍掉。

文档、源码层级（授权档 / 包搭建档 / 开源源码档）的对比表、演示账号、license 说明全部在公开仓：

👉 github.com/2961799660/…

演示站直接体验：**ai1.zijie.lol**（demo / Demo123456）

基于 v25.3.5 实测，2026-05-03 更新。下一篇打算拆 AI 画布的 DAG 编排执行器，感兴趣的同学评论扣 1。

avatar
文章
阅读
粉丝