Spring AI第九模型聊天记录功能深度测评
大型语言模型（LLMs）本身是无状态的——它们不会记住你上一次说了什么，每次对话都是“初次见面”。这在需要保持连续上下文的多轮交互中，显然是个硬伤。为了补上这块短板，Spring AI 提供了聊天记忆（ChatMemory）功能，让开发者能够跨多次交互存储和检索信息，从而让模型“记得”上下文。
核心架构分为两层
整个记忆机制可以拆成两层来看：上层是记忆管理层（ChatMemory），下层是存储层（ChatMemoryRepository）。前者负责定义记忆策略——比如保留最近多少条消息、还是对历史对话做摘要；后者则负责把这些数据写到某个地方，内存、数据库或文件系统均可。
Spring AI 默认自动配置了一个 ChatMemory bean，可以直接注入使用。其默认实现基于内存仓库，适合开发阶段的快速验证。官方提供了几种开箱即用的记忆策略：
| 策略类型 | 实现类 | 描述 |
|---|---|---|
| 消息窗口 | MessageWindowChatMemory | 维护一个固定大小的消息窗口，当消息数超过设定值（默认为20）时，自动移除最旧的消息。 |
| 摘要记忆 | ConversationSummaryChatMemory | 对超出 Token 限制的历史对话进行摘要，将摘要作为后续对话的上下文，节省 Token 用量。 |
| 时间窗口 | 需自定义 | 根据时间戳，只保留最近一段时间内的消息作为上下文。 |
而在存储层，Spring AI 提供了两种现成的实现：InMemoryChatMemoryRepository（内存存储，重启即丢失）和 JdbcChatMemoryRepository（关系型数据库持久化，支持 MySQL、PostgreSQL、SQL Server、HSQLDB 等）。
关键差异：ChatMemory 与 ChatHistory
很多人在使用 Spring AI 记忆功能时容易混淆这两个概念，这里必须分清楚：
- ChatMemory：专为维持当前对话的上下文感知而设计，它只关注对模型回答质量有帮助的那部分信息，不会保留全量历史。
- ChatHistory：指的是完整的、原始的对话记录。官方文档明确提醒，ChatMemory 不适合用于存储完整历史；如果你需要保留每一次对话的原始记录，应该使用 Spring Data 之类的方式单独处理。
简单来说，ChatMemory 是“为了模型更好地回答”而存在，ChatHistory 则是“为了事后审计或重现”而存在。两者各司其职，千万别混着用。
基于内存存储进行演示
先通过最简配置跑一个内存版本，感受整体流程。
源码示例
项目结构可以在相关仓库中找到（此处省略具体链接，直接看下面的关键配置）。
YAML 配置
# application.yml
spring:
ai:
zhipuai:
api-key: ${ZHIPUAI_API_KEY}
chat:
options:
model: glm-4v-flash
datasource:
url: jdbc:h2:file:./data/chat_memory
username: sa
password:
driver-class-name: org.h2.Driver
h2:
console:
enabled: true
path: /h2-console
sql:
init:
mode: always
schema-locations: classpath:schema.sql
测试代码
启动应用后，访问 http://127.0.0.1:8082/index.html 即可进入测试页面。
测试结果
数据库查询
如果你配置了 H2 持久化，可以直观地看到存储的数据。
本地数据文件的存放位置：
通过 H2 控制台访问：http://localhost:8082/h2-console
登录信息：
- JDBC URL: jdbc:h2:file:./data/chat_memory
- Username: sa
- Password: （留空）
然后执行查询语句：
SELECT * FROM SPRING_AI_CHAT_MEMORY;
结果如下：
整体看下来，Spring AI 的聊天记忆模块设计得很清晰：上层策略控制“记住哪些”，下层存储控制“存到哪里”。实际开发中只需根据业务场景选择合适的策略和持久化方案，就能让 LLM 在多轮对话中保持连贯的状态。