大模型是无状态的。每一次HTTP请求都是独立会话，模型不会主动保存任何历史对话。比如我们先问“你是挂号助手”，再问“我刚刚说了什么”，AI会完全无法应答，这也是原生LLM的“健忘”特性。想要实现类似ChatGPT的连续多轮对话，必须手动维护对话上下文。Spring AI 提供了整套ChatMemory对话记忆体系，彻底解决无状态痛点，让AI拥有上下文记忆能力。本篇作为记忆系列第一篇，我们先从最简单

知识存在时间断层，无法获取最新实时数据；无法访问业务数据库、业务接口，不能查询订单、用户、业务数据；不会执行精确计算、代码运算，容易出现算术错误；不能调用外部服务，无法完成联网查询、文件读取、天气查询等任务。想要让 AI 真正落地业务，就必须赋予它调用外部工具的能力，而支撑这套能力的行业标准就是MCP 模型上下文协议（Model Context Protocol）。

看完上一篇MCP工具调用，很多同学已经实现了AI调用天气、日期等工具，但这仅仅是基础函数调用，距离真正的AI智能体还差核心能力。

前面我们完成了基础对话、多轮记忆、MCP工具调用、Agent智能体，让AI具备了聊天、思考、做事的能力。知识静态滞后：训练数据固定，无法学习企业最新制度、业务文档、产品手册无私有业务认知：完全不懂公司内部业务规则、专属流程、私有资料严重幻觉问题：面对未知业务问题，会凭空编造答案，绝对无法上线生产想要让AI适配企业业务、基于内部文档精准答疑、杜绝幻觉，唯一低成本、高效率、可迭代的落地方案就是RAG（

知识存在时间断层，无法获取最新实时数据；无法访问业务数据库、业务接口，不能查询订单、用户、业务数据；不会执行精确计算、代码运算，容易出现算术错误；不能调用外部服务，无法完成联网查询、文件读取、天气查询等任务。想要让 AI 真正落地业务，就必须赋予它调用外部工具的能力，而支撑这套能力的行业标准就是MCP 模型上下文协议（Model Context Protocol）。

作为一名长期做Java后端开发的程序员，一直以来都在深耕Spring全家桶、业务开发、微服务等传统技术栈。近几年AI技术飞速发展，Python生态的LangChain、大模型应用开发如火如荼，但Java后端在AI工程化领域一直缺少一套官方、规范、轻量化的开发框架。而最新的Spring Boot4.0.4 + Spring AI1.1.6组合，让Java AI工程化正式进入稳定、企业可用阶段。

很多同学做完 Spring AI 入门demo后，都会遇到一个上线必死的致命问题：大模型的返回是「自由文本」。你让它返回 JSON，它可能：前后带一大段解释、开场白、总结键名大小写不统一、缺字段、多字段换行、空格、注释乱飞有时候返回数组，有时候返回对象，格式不稳定这种自由文本，在页面展示可以“凑合看”，但完全无法用于业务开发无法直接 JSON 反序列化为实体类无法入库、无法做字段校验、无法做后续业

在 AI 应用开发中，提示词（Prompt）是大模型交互的核心入口，提示词的精准度、规范性、完整性，直接决定 AI 输出结果的准确性、逻辑性和可用性，其重要性等同于传统开发中的核心业务 SQL。但在初学开发阶段，绝大多数开发者都会采用硬编码字符串拼接的方式编写提示词，这种写法在简单demo中可以快速运行，一旦落地生产，会暴露大量致命问题：提示词与业务代码强耦合，修改提示词需要改动 Java 代码、

在前几期记忆实战中，我们借助官方提供的，快速实现了 AI 多轮对话的上下文记忆与数据库持久化能力，解决了 AI 对话无状态、会话数据丢失的问题。但在实际生产开发中，仅靠官方自带的记忆顾问远远不够，我们往往需要实现全局日志审计、自定义请求拦截、业务参数透传、会话权限校验等通用扩展能力。而支撑这些高阶功能的核心底层，正是 Spring AI 框架的核心扩展机制 ——Advisor 顾问机制。多数初学者

上一篇我们彻底吃透了 Spring AI官方标准记忆架构，基于内存存储实现了多轮上下文对话、会话隔离、消息窗口裁剪等核心能力。基于JVM内存存储，项目重启记忆全部丢失、不支持多实例集群共享，仅能用于本地开发测试，完全无法上线生产环境。为了解决记忆持久化问题，Spring AI 官方提供了数据库存储方案，适配MySQL、PostgreSQL等主流关系型数据库。本篇我们基于MySQL + JDBC持久