一、思维导图整体知识结构梳理
一、AI 会话记忆 ChatHistory 存储
- 内存存储（测试用，禁止上生产）
- 原理：ChatHistory 对象存 JVM 内存，内存保存每一轮用户、AI 对话消息
- 优点：开发简单，不需要建表、不需要数据库
- 缺点：项目重启，全部会话数据直接丢失；多用户并发，会话会互相污染，所有人共用一套对话；集群部署，多实例之间会话不共享
- 使用场景：本地单元测试、demo 演示
- 数据库持久化存储（生产环境方案）
- 原理：创建会话记录表，每条聊天消息落库；使用 sessionId (会话 ID) 区分每一个用户的对话；用户每次请求，根据 sessionId 从数据库读取历史 ChatHistory；AI 回复完成，把新一轮对话存入数据库
- 优点：服务重启历史对话不会丢失；支持多用户隔离，支持集群部署
- 核心字段
- session_id：会话唯一标识
- role：消息角色 user /assistant
- content：对话文本内容
- create_time：消息时间
二、Function‑Call 工具调用【本地模式】
- 核心概念
- LLM 大模型本身能力局限：不能访问网络、不能调用接口、操作数据库、读取业务数据
- Function‑Call：大模型识别问题，判断需要调用外部工具，输出工具调用参数；SpringAi 拦截执行 Java 工具方法；将工具返回结果再次交给 LLM；LLM 结合工具数据整理自然语言，返回给前端
- 核心注解与 API
@Tool：标记普通 java 方法，声明这是可供大模型调用的工具；把普通方法封装成工具回调；ChatClient 大模型接入之后，才可以调用工具MethodToolCallbackProvider：把方法包装为大模型才可调用工具
- 实战：高德天气查询工具
- 本地模式特点
- LLM 大模型、@Tool 工具代码在同一个 SpringBoot 项目一起
- 适合工具数量少，小型 demo
- 本地模式缺点
- 多个项目需要相同工具，必须复制粘贴代码，无法复用
- 修改工具逻辑，需要重新打包包含大模型的整个业务服务
三、MCP Model Context Protocol 模型上下文协议【分布式工具调用】
- MCP 基础介绍
- MCP 全称 Model Context Protocol，模型上下文协议。是 Spring AI 提供的分布式工具调用标准协议
- 诞生背景：本地 function‑Call 工具耦合严重，无法跨服务复用；MCP 就是用来解决这个痛点
- 核心理念：工具和大模型业务代码拆分成两个独立服务
- MCP‑Server：工具服务端，专门存放所有 @Tool 工具，本身不集成任何 LLM 大模型，只对外暴露工具能力
- MCP‑Client：业务服务端，持有 LLM 大模型；通过 SSE 连接，远程拉取、调用 MCP‑Server 上面的所有工具
- 通信方式：SSE（Server‑Sent‑Events）；服务端长连接，Client 和 Server 保持持续连接，自动推送工具列表
- 核心优势
- 工具复用：一套 MCP‑Server，可以被多个 MCP‑Client 客户端同时调用
- 解耦：工具的开发、更新、独立部署；修改工具，不用改动业务服务
- 职责拆分：工具团队维护 Server，业务团队维护 Client，互不干扰
- 扩展：新增工具只需要在 MCP‑Server 开发，所有客户端自动感知
- MCP‑Server 工具服务端（重点：本服务没有大模型）
- 技术基础：编写工具类，业务方法添加
@Tool注解 - 开发步骤
- 独立工程，引入
spring‑ai‑starter‑mcp‑server‑webflux依赖 - 编写
McpServerConfig配置类 - application.yml 配置 mcp 服务端口
- 启动服务，暴露 SSE 端点，等待客户端建立长连接
- 独立工程，引入
注意：WebFlux 环境，不要引入 ai‑spring‑mvc，会造成环境冲突；不要配置大模型 key，MCP‑Server 不接入 LLM，只存放工具
- MCP‑Client 业务客户端（持有 LLM）
- 技术基础：普通 SpringBoot 项目，引入 mcp client 依赖
- application.yml 配置 SSE 长连接，填写 MCP‑Server 服务地址
- ChatClientConfig 配置类
- 引入
McpSyncClient，spring 启动就连接远端 MCP 服务 SyncMcpToolCallbackProvider把远端工具封装成为工具回调对象- 注册 ChatClient Bean，绑定远端工具回调
- 引入
二、制作意图
- 搞懂 ChatHistory 两种存储方案，分清内存存储和数据库持久化的优劣，区分测试环境与生产环境选型；
- 吃透 Function‑Call 本地工具调用原理，理解大模型不会直接操作外部业务，是 SpringAI 代理执行 Java 工具再回传给大模型；掌握
@Tool注解开发工具； - 理解本地 Function‑Call 的痛点，学习 MCP 分布式工具调用架构；分清 MCP‑Server（只存工具无大模型）、MCP‑Client（业务 + 大模型）角色分工；掌握 SSE 长连接通信，实现工具服务和 AI 业务服务解耦复用，是工业级智能体工具调用标准方案。
三、当日学习总结
Day39 学习 SpringAI 智能体工具调用全套知识：
- ChatHistory 会话记忆分为内存存储和数据库持久化。内存仅用于测试，重启丢失；生产必须落库，通过 session_id 区分不同用户对话，保存每一轮 role+content 聊天记录。
- Function‑Call 本地工具调用：大模型没有访问外部资源能力，通过
@Tool定义 java 工具，大模型输出调用参数，SpringAI 执行工具方法，再把工具结果交还给大模型生成回答。缺点是工具和业务项目强耦合，不方便多项目复用。 - MCP 模型上下文协议解决本地 Function‑Call 耦合问题：拆分为 MCP‑Server 工具服务（只存放 @Tool 工具，不集成大模型）、MCP‑Client 业务服务（持有大模型），通过 SSE 长连接，客户端远程拉取调用远端全部工具；实现工具独立部署、多业务服务复用工具，企业级智能体开发架构。
