Spring AI 2.1.0-RC1 发布：Session Memory、工具调用确认有什么变化？Java 项目该升级吗？

发布信息：Spring 官方于 2026 年 10 月 23 日 同时宣布 Spring AI 2.1.0-RC1 和 2.0.2 可用。
技术范围：Java / Spring Boot / Spring AI / AI Agent / Tool Calling / RAG。

先说结论：生产项目选 2.0.2，新功能评估可以试 2.1.0-RC1

如果你在关注 Spring AI 的新版本，最近有两条消息值得放在一起看：

• Spring AI 2.0.2：2.0 稳定分支的维护更新，适合已使用 2.0.x 的项目优先评估。
• Spring AI 2.1.0-RC1：2.1 的 Release Candidate（候选发布版），带来 Session Memory、工具调用确认、更多模型的 Message Parts 支持等能力；它还不是 2.1 GA 正式版。

所以，“该不该升级”不是单看版本号更大，而要看你是在维护已经上线的 Java 系统，还是准备开发具有长期会话、工具执行能力的 Agent。

我的建议：已有生产系统先评估 2.0.2；对 2.1 的新 API 感兴趣，可以单独创建实验分支验证 RC1，避免把预发布 API 直接带入生产。

下面按 Java 开发者真正关心的问题拆开说。

一、这次到底发布了什么？不要把 RC1 写成 GA

Spring 官方 2026 年 10 月 23 日的文章标题是 Spring AI 2.1.0-RC1 and 2.0.2 Available Now。

版本对比如下：

版本	当前定位	主要看点	适合谁
2.0.2	2.0.x 正式维护版本	依赖升级、可观测性、MCP 服务器定制等改进	维护 2.0.x 项目的团队
2.1.0-RC1	2.1 候选发布版	Session Memory、工具确认、Message Parts、向量检索改进	需要评估新 Agent 能力的开发者

这里不能说“2.1 已正式发布”——截至本文核对日期，Spring 官方的这次公告仍明确表示 2.1 GA 是接下来的目标。

另外，2.0.2 中的修复也已包含在 2.1.0-RC1 中，但这不代表两条分支的 API 稳定性相同。

二、Session Memory：终于不只是把聊天消息拼成一个 List

1. 传统 ChatMemory 解决什么问题？

对话系统至少需要知道“上一轮说了什么”，因此很多 Spring AI 教程会使用 ChatMemory、MessageChatMemoryAdvisor 和一个 conversationId 管理消息历史。

这适合比较简单的聊天场景。

但当一个 AI Agent 开始调用工具，历史内容就可能包括：

• 用户提问；
• 模型决定调用的工具及参数；
• 工具执行结果；
• 模型基于结果生成的最终回复；
• 额外的业务事件，例如用户批准或拒绝某个动作。

如果只把历史当成“消息列表”，就会遇到三个工程问题：

1. 如何保证工具调用和对应结果成对出现？
2. 历史太长时，如何裁剪但不截断一个完整的处理回合？
3. 压缩上下文后，如何既控制 Token，又保留可审计的事件记录？

2. 2.1 引入的 Session Memory 有什么不同？

Spring AI 2.1 RC1 将来自社区的 Session Memory 能力引入框架，核心思想是：

把完整历史保存成只追加的事件日志（append-only event log），再按需要构建当前要送给模型的上下文视图。

它强调三个能力：

• 结构化事件：不仅可以保存消息，还可以记录其他 SessionEvent。
• 按回合压缩：TurnCountTrigger 可判断何时触发压缩；WindowCompactionStrategy 可以保留最近若干完整回合，而不是在工具调用和结果中间切一刀。
• 可替换的持久化仓库：InMemorySessionRepository 适合测试，JdbcSessionRepository 支持 PostgreSQL、MySQL、MariaDB 和 H2 等数据库。

注意这里有一个很重要的概念区分：

压缩模型看到的上下文，不等于把原始事件从存储中删除。 Session Memory 通过事件记录和活动视图来管理长期会话。

这对于多轮 Agent，往往比简单限制“最多记住最近 20 条消息”更有用。

3. Java 开发者怎么接入？

Spring 官方给出了基于 ChatClient 的示例。下面保留它最核心的部分：

@Bean
ChatClient chatClient(ChatModel chatModel, SessionService sessionService) {
    return ChatClient.builder(chatModel)
            .defaultAdvisors(
                    SessionAdvisors.builder(sessionService)
                            .compaction(
                                    new TurnCountTrigger(20),
                                    WindowCompactionStrategy.builder()
                                            .lastTurns(10)
                                            .build())
                            .build())
            .build();
}

请求时显式指定 Session ID：

String answer = chatClient.prompt()
        .user("解释一下 Spring 中的事务传播行为")
        .advisors(SessionAdvisors.session("session-abc"))
        .call()
        .content();

对应的 JDBC Session 依赖为：

<dependency>
    <groupId>org.springframework.ai</groupId>
    <artifactId>spring-ai-starter-model-session-jdbc</artifactId>
</dependency>

这里假设工程已经通过 Spring AI BOM 管理匹配版本，并具备 ChatModel、数据源等必要配置。这只是核心集成片段，不是复制即可运行的完整 Maven 项目。

还有一个小设计很值得参考：每次调用都必须明确传入 Session ID，不提供共享默认会话。否则多个用户可能在不知不觉中混用同一段聊天历史。

4. 旧的 ChatMemory 要马上替换吗？

不必。

Spring 官方在 2.1 RC1 中已将 ChatMemory、MessageChatMemoryAdvisor 及部分对应仓库标记为弃用，并指出将在 3.0 移除；但弃用不等于 2.1 RC1 已删除。

对现有项目，我会这样处理：

• 简单聊天：如果现有记忆机制稳定，不必为了追版本立即重构。
• 复杂 Agent：如果需要保存工具调用过程、按回合压缩、跨实例继续执行，可以优先评估 Session Memory。
• 存量迁移：先列清原有存储实现、数据迁移策略与回滚方案。部分旧仓库还没有对应的 Session 版本，不要默认所有实现都能无缝替换。

三、工具调用确认：让 AI 执行删除、付款、发送消息之前先问用户

这是我认为本次最贴近真实业务系统的能力之一。

以前我们很容易写出这样的工具：

@Tool(description = "Delete a file")
public String deleteFile(String filePath) {
    return fileService.delete(filePath);
}

如果模型选中了这个工具，系统如何阻止它立即执行？

只在 Prompt 中写“危险操作需要确认”是不够的。 Prompt 是行为指导，不应该代替真正的授权控制。

Spring AI 2.1 RC1 支持在工具定义上声明需要确认：

class BookingTools {

    @Tool(
        description = "Book a flight",
        requiresConfirmation = true
    )
    String bookFlight(String flightNumber) {
        return bookingService.book(flightNumber);
    }
}

这段代码来自 Spring 官方发布说明展示的用法。它表达的意思非常直接：模型提出要调用这个工具时，先暂停在执行之前，等待应用获取人的决定。

具体流程是什么？

用户：帮我预订某个航班
        |
        v
模型：需要调用 bookFlight
        |
        v
Spring AI：发现该工具要求确认
        |
        v
返回待确认的工具调用信息
        |
        v
业务界面：展示航班号、操作内容和风险
        |
        +---- 拒绝 ---> 不执行工具，向模型反馈拒绝原因
        |
        +---- 同意 ---> 执行工具，再把结果发给模型继续处理

Spring 官方说明，应用可以为待执行调用收集 ToolCallDecision，并使用 ToolCallingManager.executeToolCalls(...) 继续处理。确认策略还可以按工具名或参数设置，而不局限于注解中的固定布尔值。

这是不是等于有了安全授权？

不是。

用户确认只是一个交互环节，服务端仍必须自己完成身份认证、资源归属校验、权限判断、参数验证和操作审计。

例如 AI 要删除某个订单，即使用户点击了“确认”，后台仍应核对：

• 当前账号是否有权操作该订单；
• 订单是否满足删除或取消条件；
• 操作参数是否与用户确认时展示的内容一致；
• 是否存在重复提交或重放风险。

Spring AI 帮你提供了暂停和继续调用的机制，不会替业务系统决定什么操作是合法的。

因此我更愿意把这次更新理解为：Agent 开发向常规企业软件的审批和授权流程靠近了一步。

四、Message Parts：复杂消息不再只是一段 text

很多开发者对消息对象的理解是：

role = assistant
content = "模型生成的文本"

但对于真实的推理与工具调用，模型的响应可能同时具有不同类型的内容块，例如：

• 文字；
• 工具调用及其参数；
• 推理相关内容；
• 供应商特定的消息块与标识。

Spring AI 2.1.0-RC1 将 MessagePart 相关能力扩展到更多模型接入，包括 OpenAI Chat Completions、Anthropic、Google GenAI、Amazon Bedrock Converse、Ollama、Mistral AI 和 DeepSeek。

这样做的价值不是“终于能返回 JSON”，而是在多个模型调用和会话回放过程中，尽可能保留消息内容块本身的顺序与必要元数据。

为什么 Java 开发者要关心？

假设一个模型先给出工具调用，工具返回后再继续生成。对于某些模型提供商，工具调用及推理相关字段存在严格的上下文格式要求。

如果应用自己把所有内容揉成一个字符串，再重新构造历史消息，可能丢失必要信息，甚至造成下一轮调用不兼容。

新版本在这方面提供了更丰富的消息结构，但并不意味着旧的 getText() 等访问器马上不能用了。官方说明这些已有访问方式保持可用。

DeepSeek 兼容接口也有一个配置变化

对于部分 OpenAI 兼容接口，是否将历史回复中的 reasoning_content 重新发回模型可能有兼容性差异。

2.1 RC1 提供了以下选项：

spring.ai.openai.chat.replay-reasoning-content=false

官方说明默认仍会重放相关内容，而 false 可关闭重放。

不要不分模型统一改成 false：有的模型可能需要该字段延续推理上下文，有的兼容服务却可能拒绝它。应根据你实际使用的模型提供商和接口行为验证。

五、RAG 场景：支持用“自己算好的向量”直接搜索

RAG 项目里经常会遇到这样的情况：

• 文档向量由离线任务计算；
• 查询向量由另一个模型服务生成；
• 向量数据库只负责存储和相似度检索；
• 不希望每次搜索都强制调用 VectorStore 内配置的嵌入模型。

Spring AI 2.1.0-M1 已引入预计算向量写入能力，2.1.0-RC1 又补充了对查询向量的搜索支持。

官方给出的核心用法类似：

float[] queryEmbedding = ...; // 由外部 Embedding Model 计算

List<Document> results = vectorStore.similaritySearch(
        queryEmbedding,
        SearchRequest.builder()
                .topK(5)
                .similarityThreshold(0.7)
                .build()
);

该能力的关键是直接传入已计算的向量，而不是让向量库内部再次调用嵌入模型。

官方列出的相关实现包括 pgvector、Qdrant、Redis、Elasticsearch；OpenSearch 也扩展了相关支持。对不支持的实现，新版强调尽早给出 UnsupportedOperationException，而不是悄悄尝试其他路径。

但请注意：

• 文档向量和查询向量必须来自兼容的向量空间。
• 向量维度必须匹配索引。
• topK、相似度阈值和过滤条件仍需结合业务调优。
• 这并不自动意味着 RAG 质量提高，也不能凭接口更新宣称性能提升。

六、2.0.2 值得升级吗？别被 2.1 的新闻盖过去

2.1 RC1 的新功能容易吸引注意力，但对于在维护 Spring AI 2.0.x 项目的团队，2.0.2 可能更值得先看。

根据该版本的官方 Release Notes，2.0.2 涉及的内容包括：

• Anthropic Java SDK 依赖更新；
• 语音合成、语音转写和部分图像模型的可观测性支持；
• Redis Vector Store 元数据字段配置；
• Stateless MCP Server 的定制能力；
• 一些文档、兼容性和依赖更新。

这属于“维护稳定版本”的正常节奏。能不能升级还要看项目模型供应商、配置方式和现有集成测试的兼容性。

尤其对于已经接入 MCP、向量库或第三方模型的项目，先看 Upgrade Notes，再跑自己的回归测试，比仅看“新版本发布”四个字可靠得多。

七、升级选择：我会给 Java 团队的三个建议

场景 A：已有系统稳定上线，只用简单 ChatClient

建议：优先评估 2.0.2，不急着上 2.1 RC1。

理由：你可能只需要一般的模型调用、Tool Calling 和简单会话历史，没有必要承担新 API 的迁移成本。

场景 B：准备做带工具执行的业务 Agent

建议：单独使用 2.1 RC1 验证工具调用确认。

重点测试：

1. 工具请求确认之前，业务代码是否确实没有执行；
2. 用户拒绝时能否正确返回模型；
3. 用户确认后是否存在重复执行；
4. 超时、刷新、服务重启后如何恢复用户决策；
5. 真实业务权限是否在服务端再次校验。

这里尤其不能混淆“框架具备暂停工具调用能力”和“你的业务已经具备完整可恢复审批流”。

场景 C：要做长对话、Agent 轨迹或复杂记忆

建议：重点评估 Session Memory 的事件记录、回合压缩与持久化方式。

可以用一个小型 PoC 对比：

评估项	传统 ChatMemory	Session Memory
普通聊天历史	适合	适合
工具调用过程	需要关注中间消息保存的限制	强调完整回合与事件记录
长历史窗口	常见做法是消息条数窗口	支持按回合压缩与活动视图
事件可追溯性	取决于应用设计	采用只追加事件日志
迁移成本	现有项目较低	需要评估新 API 和存储

不要盲目把 Session Memory 当成“自动的长期记忆”。 它主要解决会话事件与上下文管理，不等于帮你完成用户画像、事实抽取、跨会话召回等全部业务功能。

八、一个适合团队执行的升级检查清单

真正升级时，建议至少完成下面几项：

1. 固定版本：区分 2.0.2 正式版和 2.1.0-RC1 候选版，不使用模糊的动态版本。
2. 核对 Spring Boot 兼容性：按目标 Spring AI 版本的官方兼容说明选择 Spring Boot 版本，不只修改一个 Maven 属性。
3. 建立测试分支：保留可随时回滚的原版本和配置。
4. 验证模型接入：普通聊天、流式响应、工具调用、异常处理分别回归。
5. 检查消息持久化：特别留意 ChatMemory 与 Session Memory 的行为和数据格式差异。
6. 测试敏感工具：确认拒绝、批准、超时、并发与重试的处理。
7. 关注向量库：如果使用预计算向量，检查维度、写入与搜索语义是否匹配。
8. 查看官方 Upgrade Notes：尤其涉及包名调整、弃用接口和依赖升级时，不要只按旧教程拼凑代码。

如果没有具体新功能需求，“新版本发布了”本身不是生产系统必须立即升级的充分理由。

九、常见问题

Spring AI 2.1.0-RC1 是正式版吗？

不是。RC1 是发布候选版本，不等同于 GA（General Availability，正式可用版）。2026 年 10 月 23 日的 Spring 官方公告仍明确表示 2.1 GA 尚待发布。

Spring AI 2.0.2 和 2.1.0-RC1 应该选哪个？

生产项目倾向先评估 2.0.2；如果明确要试验 Session Memory、工具调用确认或新的消息结构，可以在独立测试环境评估 2.1 RC1。

Spring AI 2.1 的 Session Memory 会自动替换 ChatMemory 吗？

不会。新能力需要按官方指南接入相应依赖、SessionService 和 Advisors。旧 API 虽被标记弃用，但迁移仍是需要安排和验证的工作。

工具调用确认能替代权限校验吗？

不能。确认是用户交互与工具编排机制，服务端仍必须检查身份、资源归属、权限、参数和重放风险。

这次更新是不是意味着 Java Agent 已经完全成熟？

不能这么推断。框架能力越来越完善，但真实业务里的状态恢复、审计、幂等、可靠消息、模型供应商差异和异常处理仍然需要应用开发者设计。

总结

2026 年 10 月这一轮 Spring AI 更新，我更关注的不是版本号，而是它反映出的演进方向：

Spring AI 正在从“把模型接进 Spring Boot”，进一步走向“让 Agent 的长期会话、工具执行和状态管理更符合企业级 Java 工程习惯”。

其中，Session Memory 解决了复杂会话历史如何记录和压缩的问题，工具调用确认让有风险的外部动作更容易接入人工审批，Message Parts 则改善了多模型、多内容块消息的处理基础。

对于准备学习的人，2.1 RC1 很值得跟进；对于正在维护生产系统的人，先评估 2.0.2，再根据真实需求规划 2.1 升级，会更稳妥。

---

参考资料

• Spring 官方发布公告：Spring AI 2.1.0-RC1 and 2.0.2 Available Now（2026-10-23）
• Spring AI 2.1 — Session Memory
• Spring AI 2.1 — ChatClient Integration
• Spring AI 2.1 — Tool Call Confirmation
• Spring AI Releases（含 2.0.2 官方更新记录）
• Spring AI Upgrade Notes