Spring AI Session API 深度解析：避开 ChatMemory 常见使用误区与最佳实践指南

文档中有一个容易被忽略的警告：代码模式、Git历史、调试方法等内容不应存入AutoMemoryTools。原因很直接：这些内容会随代码库频繁变动，而长期记忆文件不会自动同步更新，很快便会过时，成为干扰噪音。这类信息更适合放在代码库本身的注释或文档中。

Session API：短期记忆的“工业级”升级

在Spring AI 1.1之前，短期记忆的主力是MessageWindowChatMemory，它维护一个固定大小的消息窗口。这种方式简单，但存在明显局限：按消息数而非token数截断，可能导致上下文利用率低；截断时可能破坏工具调用与结果的完整性；且缺乏持久化能力，重启即失。

Session API（属于Agentic Patterns系列）是对此的彻底重新设计，引入了事件溯源模型。

核心概念：Turn（轮次）是原子单位

Session API的最大创新在于将“一轮对话”定义为原子单位：即一条用户消息及其后续所有的助手消息、工具调用和工具结果，直到下一条用户消息出现。

在进行上下文压缩时，保证完整轮次要么全部保留，要么全部丢弃，彻底解决了工具调用与结果被割裂的难题。每个SessionEvent包装了一条消息，并附带了UUID、会话ID、时间戳、分支标签以及用于标记LLM生成摘要的METADATA_SYNTHETIC标志。

4种压缩策略怎么选

Session API提供了多种压缩策略：

• SlidingWindow：滑动窗口，保留最近N个事件。
• TurnWindow：轮次窗口，保留最近N轮完整对话。
• RecursiveSummarization：递归摘要，智能压缩历史内容。
• NoCompaction：不压缩，保留全部。

RecursiveSummarization是最智能但也最昂贵的选择。它并非每次都从头摘要，而是维护一个滚动的压缩历史，每次只对新淘汰的内容进行重新摘要，效率更高。摘要结果会被标记为METADATA_SYNTHETIC，以便后续进一步压缩。

选型建议：

• 聊天机器人、单轮问答：SlidingWindow或TurnWindow足矣。
• 复杂任务Agent（工具调用链长）：优先TurnWindow，保证原子性。
• 长期工作Agent（需保留全局上下文）：考虑RecursiveSummarization，但需权衡LLM调用成本。

// Session API 接入示例
SessionMemoryAdvisor advisor = SessionMemoryAdvisor.builder(sessionService)
    .defaultUserId("user-alice")
    // 20 轮之后触发压缩
    .compactionTrigger(new TurnCountTrigger(20))
    // 压缩策略：保留最近 10 个 event，其余滑走
    .compactionStrategy(
        SlidingWindowCompactionStrategy.builder().maxEvents(10).build()
    )
    .build();

还有一个隐藏能力：Recall Storage

即使上下文被压缩，Session API仍会保留完整的事件日志，并提供了conversation_search工具。Agent可以通过关键词搜索历史对话，例如在第80轮时查找“第5轮提到的API地址”，而无需在上下文中一直保留早期内容。这个设计参考了MemGPT的Recall Storage模式。

图：Session API四种压缩策略的选择决策流程，以及Recall Storage的保障机制

JDBC持久化：生产环境必须做

Session API默认通过spring-ai-session-jdbc模块，使用两张表（AI_SESSION会话元数据和AI_SESSION_EVENT只追加事件日志）进行持久化，支持PostgreSQL、MySQL等主流数据库。这确保了对话历史可以跨应用重启保留，是生产级短期记忆的基石。

向量库 vs Redis vs 文件系统：长期记忆存储选型

除了AutoMemoryTools的文件系统方案，社区还有另一套思路：利用Redis向量库实现基于语义的记忆检索。

Spring AI + Redis向量存储的架构

这套方案源自Redis社区的实践，核心是将记忆分为两种类型：

• EPISODIC（情节记忆）：如个人经历、用户偏好，按时间顺序精确检索。
• SEMANTIC（语义记忆）：如通用知识、事实，按语义相似度检索。

存储使用RedisVectorStore，通常配置HNSW近似最近邻算法、COSINE距离度量，能够支持海量向量的高效检索。

关键环节通过两个Advisor实现：Retrieval Advisor在调用LLM前进行向量搜索并注入相关记忆；Recorder Advisor在LLM响应后提取原子事实去重并存入向量库。

两种方案的对比

如何选择？

• AutoMemoryTools文件方案：适合面向个人用户的Agent（每个用户几十到几百条记忆）。优势是结构清晰、可读性好、便于调试，无需额外服务依赖。
• Redis向量方案：适合需要在海量历史记忆中进行语义检索的场景（如企业知识库Agent）。优势是检索能力强、支持多节点共享，但会引入Embedding调用开销和Redis运维成本。

两者并非互斥。完全可以混合使用：用AutoMemoryTools存储“用户偏好”这类精准事实，用Redis向量库存放“历史交互摘要”这类适合语义检索的内容。

图：两种长期记忆存储方案的全面对比，以及适用场景分析

Spring AI vs LangChain4j：记忆能力差距在哪里

国内很多文章对比这两个框架时，往往只关注模型支持列表，却很少深入记忆能力这一核心差异。

LangChain4j的记忆体系基于ChatMemory接口，提供了MessageWindowChatMemory和更实用的TokenWindowChatMemory（按Token数控制窗口）。但它没有内置类似AutoMemoryTools的跨会话长期记忆方案，需要开发者自行组合EmbeddingStore等组件来实现，灵活性高但样板代码也多。

Spring AI的优势在于其高层的、开箱即用的抽象。Spring AI 1.1+的Session API和AutoMemoryTools构成了清晰的两层记忆体系，并与Spring Boot的Advisor链深度集成，对Spring生态内的团队来说接入成本极低。AutoMemoryTools将记忆管理的决策权交给LLM本身，这在长期任务中往往比硬编码的规则更有效。

LangChain4j的优势在于更轻量的运行时（Quarkus下约50-100MB）以及对更广泛模型提供商的支持。如果你的应用运行在资源受限环境或依赖特定私有模型，这可能是一个决定因素。

坦白说，到了2026年，两个框架在1.x阶段的功能差距已在缩小。选型的核心考量应该是技术栈适配性：用Spring Boot就选Spring AI，用Quarkus则考虑LangChain4j，不必强行跨栈。

把两层记忆接在一起：完整Agent示例

下面是一个将Session API和AutoMemoryTools整合的完整配置示例，可供参考：

// 前置条件：Spring AI 1.1+，spring-ai-agent-utils
@Configuration
public class AgentConfig {
    @Bean
    public ChatClient agentChatClient(
            ChatModel chatModel,
            SessionService sessionService) {
        return ChatClient.builder(chatModel)
            .defaultSystem("""
                你是一个有记忆的 AI 助手。你能记住用户的偏好、项目背景和历史交互。
                在回答问题之前，主动检查是否有相关记忆需要加载。
                当用户纠正你或透露新的偏好时，主动保存到长期记忆。
                """)
            .defaultAdvisors(
                // 长期记忆层：AutoMemoryTools（跨会话持久化）
                AutoMemoryToolsAdvisor.builder()
                    .memoriesDir(System.getProperty("user.home") + "/.agent/memories")
                    .build(),
                // 短期记忆层：Session API（当前会话 + 上下文压缩）
                SessionMemoryAdvisor.builder(sessionService)
                    .defaultUserId("demo-user")
                    .compactionTrigger(new TurnCountTrigger(15))
                    .compactionStrategy(
                        RecursiveSummarizationStrategy.builder()
                            .summarizationModel(chatModel)
                            .build()
                    )
                    .build(),
                // 工具调用执行器
                ToolCallAdvisor.builder()
                    .disableInternalConversationHistory()
                    .build()
            )
            .build();
    }
}

关键点说明：

• AutoMemoryToolsAdvisor必须放在SessionMemoryAdvisor之前，以确保长期记忆的系统提示词优先注入。
• 调用ToolCallAdvisor.builder().disableInternalConversationHistory()可以避免该Advisor维护多余的对话历史副本。
• 生产环境中，memoriesDir应对不同用户进行隔离，例如使用{userId}作为子目录。

常见问题

Q：AutoMemoryTools用的是文件系统，部署在多个Pod上怎么办？
A：这是社区版当前的一个限制。多Pod场景下，需要将memoriesDir指向共享存储（如NFS、S3）。或者，可以考虑采用前述的Redis向量方案替代，Redis天生支持多节点共享。社区未来也可能提供JDBC或Redis后端的AutoMemoryTools实现。

Q：Session API的RecursiveSummarization会不会把重要内容总结丢？
A：存在一定风险。但Session API提供了双重保障：一是原始事件日志始终保留，可通过conversation_search工具检索；二是合成摘要会被标记为METADATA_SYNTHETIC，便于监控质量。若业务对信息完整性要求极高，建议仅使用TurnWindow策略，避免LLM摘要。

Q：AutoMemoryTools的6个工具会占用多少token？
A：工具定义本身约占500-800 token（取决于模型编码）。每次对话还需加载MEMORY.md索引（几十到几百token）。总体开销相对于完整对话历史较小，但在极度成本敏感的场景，可考虑手动接入，按需加载特定工具。

Q：Spring AI的ChatMemory和Session API可以同时用吗？
A：不建议。Session API旨在替代而非补充ChatMemory。两者同时使用会导致对话历史被重复记录。根据项目复杂度二选一即可：简单项目用MessageWindowChatMemory；生产项目用Session API的SessionMemoryAdvisor。

Q：LangChain4j有没有类似AutoMemoryTools的东西？
A：没有完全对等的开箱即用方案。LangChain4j的AiServices可通过注解注入记忆，但实现跨会话的长期记忆需要开发者自行组合EmbeddingStore和提取逻辑，代码量会显著增加。

核心判断

综合来看，AutoMemoryTools + Session API的组合，是目前Ja va生态中为Agent提供记忆能力最完整、最开箱即用的方案。短期记忆确保“这次对话不乱”，长期记忆实现“下次还记得你”，两层各司其职，相辅相成。

在这个方案成熟之前，生产环境往往需要拼凑各种临时方案来实现记忆功能。现在，大部分工作可以交给框架了。当然，挑战依然存在，比如AutoMemoryTools文件后端对云原生多副本部署不够友好的问题，可以等待社区推出JDBC版本，或暂时用Redis向量方案作为替代。

如果你或你的团队正在基于Spring AI进行Agent落地，希望这篇梳理能帮助你们避开一些弯路。