SpringAI2.1重构记忆机制，ChatMemory标记弃用转向事件溯源模型
Spring AI 2.1 版本正式弃用 ChatMemory 系列组件，引入基于事件溯源（Event Sourcing）的 Session 新抽象。新方案将对话记忆从可变列表改为只追加、不可变的事件...
Spring AI 2.1 已正式发布，其中一项关键变更引发开发者关注：原用于多轮对话记忆管理的核心组件 ChatMemory、MessageWindowChatMemory 等被整体标记为 @Deprecated，并明确将在 3.0.0 版本中彻底移除。取而代之的是一个名为 Session 的全新抽象层，其底层设计逻辑发生根本性转变——从“可变消息列表”转向“只追加的事件日志”，即采用事件溯源（Event Sourcing）架构重构 Agent 记忆系统。
这一改动并非简单的接口替换，而是对对话记忆建模方式的范式升级。在 Spring AI 2.0 及更早版本中，ChatMemory 以会话 ID 为键，维护一个动态消息列表。当列表长度超过预设窗口容量时，系统按消息条数从头部剔除旧消息。该策略在短对话中表现良好，但在涉及工具调用的复杂交互中暴露明显缺陷。
如图所示，一次完整交互（一轮）通常包含用户输入、助手推理、工具调用、工具返回结果及最终回复等多个环节。而旧模型仅按消息数量裁剪，可能在工具调用与结果之间强行截断，导致上下文结构断裂——例如工具调用被保留但结果被丢弃，或反之。模型接收到不完整的上下文后，行为变得不可预测，轻则逻辑混乱，重则陷入循环幻觉。更关键的是，被删除的消息完全不可追溯，系统对“遗忘”本身无任何记录。
值得说明的是，Spring AI 在 2.0 后期已通过 MessageWindowChatMemory 实现按“轮次”边界裁剪，避免了跨轮截断问题。但官方仍选择彻底重构，原因在于：旧方案本质仍是状态覆盖型存储，而新方案转向事件驱动型日志，二者在数据语义与可扩展性上存在代际差异。
Session 的核心思想源于后端系统中成熟的事件溯源模式。以银行账户为例：系统不直接存储余额字段，而是记录每一笔存取款事件；当前余额由事件流累加得出。同理，Spring AI 将每次对话交互拆解为原子化事件（如 UserMessageEvent、ToolCallEvent、ToolResultEvent），全部追加至不可变日志中。Session 本身仅作为元数据容器，保存会话 ID、创建时间、过期时间及自定义标签，实际内容由独立仓库管理。
如图所示，事件日志按顺序追加，永不修改；系统通过 EventFilter.active 机制筛选出当前有效事件子集，再由 getActiveMessages 动态构建供模型使用的上下文视图。压缩策略（Compaction）仅在日志过长时插入一个 COMPACTING 边界事件，标记“此前所有事件已合并为快照”，而非物理删除历史事件。这意味着即使被压缩，原始事件仍保留在日志中，可通过 EventFilter.all 全量读取，支持审计、回溯与调试。
值得注意的是，官方早期宣传中强调的“多 Agent 分支隔离”功能，在 2.1 正式版前已被维护者主动移除。该设计原计划允许同一会话下多个子 Agent 拥有独立历史分支，但因实现复杂度与一致性挑战被放弃。当前 Session 仍为单线程线性日志模型，多 Agent 协作需依赖外部协调逻辑（如父级 Orchestrator 统一管理会话）。
图中左侧为“接力 handoff”模式：多个 Agent 共享同一份完整会话日志，各自读取全部历史；右侧为曾计划的“委派 delegation”模式（agent-as-tool），每个子 Agent 拥有独立压缩日志。后者虽具灵活性，但增加了状态同步与冲突解决成本，最终未纳入 2.1 正式发布。
从工程实践角度看，此次重构带来三方面实质提升：
第一，确定性增强。事件日志的不可变性确保任意时刻上下文构建结果可复现，利于调试与测试。开发者可精确控制哪些事件参与当前推理，而非被动接受窗口裁剪后的模糊结果。
第二，可观测性提升。所有交互行为均以事件形式持久化，配合外部存储（如 Kafka、PostgreSQL event store），可实现全链路追踪、异常归因与合规审计。这对金融、医疗等高监管场景尤为重要。
第三，扩展性更优。事件模型天然支持异步处理、重放与分片。未来若需引入长期记忆检索（如向量库召回）、跨会话关联分析等功能，可在事件流基础上叠加处理管道，而无需改造核心记忆层。
迁移方面，Spring AI 提供了兼容层过渡方案：旧版 ChatMemory 可通过适配器包装为 Session 实现，但仅限短期过渡。官方建议新项目直接采用 Session API，其核心接口简洁清晰：
SessionRepository：负责 Session 元数据与事件日志的持久化Session：不可变值对象，含 id、createdAt、metadata 等字段SessionEvent：事件基类，派生出 UserMessageEvent、AssistantMessageEvent 等具体类型EventFilter：定义事件筛选规则（active / all / byType）
实际编码中，开发者不再手动管理消息窗口大小，而是通过配置 session.maxEvents 或自定义 CompactionStrategy 控制日志规模。模型调用时，框架自动调用 getActiveMessages(session) 获取当前上下文，开发者只需关注业务事件的构造与发布。
需要指出的是，事件溯源并非银弹。其代价在于存储开销略高（需保留全部事件）、首次构建上下文延迟稍增（需重放事件），且对开发者认知模型提出更高要求。但对于中大型对话系统，尤其涉及工具链、多步骤任务与审计需求的场景，其长期收益远超初期成本。
目前，Spring AI 2.1 已随 Spring Boot 3.3.x 系列集成发布，相关文档与示例代码已在 GitHub 官方仓库更新。社区反馈显示，已有部分企业级项目开始试点迁移，重点验证在客服机器人、运维助手等长流程场景中的稳定性提升。
此次记忆机制重构，标志着 Spring AI 从“可用”向“可靠”迈进的关键一步。它不再满足于提供基础对话能力，而是致力于构建符合生产级标准的 Agent 运行时基础设施。后续版本或将围绕事件流进一步拓展能力，例如集成向量索引实现语义压缩、支持事件回滚用于 A/B 测试等。对于开发者而言，理解事件溯源的设计哲学，将成为高效使用新一代 Spring AI 的必要前提。
