请介绍一下 AI 超级智能体项目的整体架构设计，有哪些模块？
- 标签：后端、编程导航
🏛 业务架构师
我把这个项目按业务能力域分成六层，模块边界即业务边界：
- 接入层：SSE 流式接口 + 统一鉴权，负责对话的长连接交付——流式输出是 AI 应用的体验底线，用户等完整答案 30 秒早就流失了；
- 会话与记忆层：多轮对话管理、会话持久化（ChatMemory + 数据库存储），对话历史是用户资产，跨设备可续聊是产品竞争力；
- AI 编排层：ChatClient + Advisor 链（RAG 增强、查询重写、Re-Reading 等按需插拔）——Advisor 机制让"AI 能力的组合"变成配置而非代码；
- RAG 知识库层：文档 ETL（加载-清洗-切分-向量化）+ 向量存储 + 检索策略（多查询扩展、重排序），支撑企业知识问答这类最高频的落地场景；
- 工具与 MCP 层：Tool Calling（搜索、PDF 生成等业务工具）+ MCP 客户端/服务端，让智能体能"做事"而不只是"说话"；
- Agent 编排层：分层智能体（规划-执行）、ReAct 循环、任务退出控制。
架构演进思路（我讲项目时必带这段）：MVP 先跑通"会话 + 大模型 + 流式"最小闭环验证价值；知识问答需求出现后上 RAG；用户要"帮我做"而不是"帮我查"时引入工具与 Agent 循环。模块随业务需求逐层点亮，而不是第一天搭全家桶——AI 应用需求变化极快，重资产起步的架构三个月就成负资产。
🏗 系统架构师
这个项目我按"接入层 → 应用层 → 智能体层 → 资源层"四层讲架构：
接入层：Web 前端（React/Vue 聊天界面）+ 网关，通过 SSE 流式协议对接后端，鉴权、限流在这一层收口；
应用层（Spring Boot）：会话管理（多聊天室、上下文维护）、对话记忆持久化（数据库存储历史消息，摘要压缩长上下文）、用户与权限、流式响应服务（SseEmitter 推送模型输出）；
智能体层（核心）：基于 Spring AI 构建——ChatClient 统一多模型调用（OpenAI/DeepSeek/通义等），RAG 知识库（文档 ETL → 向量化 → 向量库检索增强）、工具调用 Tool Calling（联网搜索、PDF 生成、文件处理）、MCP 协议客户端（接入地图、图片搜索等外部 MCP 服务）、分层 Agent 编排（规划 Agent + 执行 Agent，ReAct 循环驱动）；
资源层：向量数据库（pgvector/Milvus）、关系库（业务与对话数据）、对象存储（文档）、第三方 API（搜索、地图）。
设计权衡：智能体层独立成层，是为了模型/工具/知识库可独立演进替换（供应商解耦）；SSE 而非 WebSocket 是因为 AI 对话是"单向流为主"；工具与 MCP 统一注册管理，新能力插拔式接入。整个架构的核心诉求：模型能力易变，业务骨架稳定。
💻 全栈开发专家
我按"一次提问的完整旅程"讲架构，这比背模块清单直观：
text
用户（Web/SSE 流式）
→ 接入层：Spring Boot + SseEmitter 流式响应 + 登录态（Spring Security/GitHub OAuth）
→ 会话层：多轮对话管理、ChatMemory（MySQL 持久化 + 上下文窗口截断）
→ 编排层（核心）：ChatClient 链 + Advisor 链
├─ 预检索 Advisor：查询重写、多查询扩展、RAG 路由
├─ RAG Advisor：知识库检索（向量库 + 元数据过滤）
└─ 后处理：结构化输出、Re-Reading 增强
→ 能力层：
├─ 多模型接入：OpenAI / DeepSeek / 通义 + 本地 Ollama（统一网关、降级切换）
├─ 工具调用 Tool Calling：联网搜索、PDF 生成、数据库查询
├─ MCP 客户端：接入外部 MCP 服务（地图、图片搜索）
└─ Agent 循环：ReAct 模式自主规划执行（规划→执行→观察→汇总）
→ 知识层：文档 ETL（解析/切分/元信息标注/向量化）→ PGVector 存储
→ 基础设施：Redis（缓存/限流）、监控（token 用量/延迟）模块职责一句话版：接入层管"怎么来"，会话层管"聊了什么"，编排层管"怎么答"，能力层管"能干什么"，知识层管"知道什么"。
工程上的关键决策：Advisor 链做成可配置（每个会话可选不同 RAG 知识库和工具集）；模型调用统一封装超时/重试/降级；流式链路全程 traceId 串联，方便排查"卡在哪一段"。