深入拆解 Spring AI 记忆机制，并改造上下文管理以适配求职派多 Agent 系统

求职派同时对接了微信、钉钉、飞书三个渠道。

用户在微信上说“帮我推荐 Java 岗位”，紧接着追问一句“薪资 25k 以上的”——如果大模型没有记住第一句话，第二句话就变成了一个莫名其妙的筛选条件，结果很可能会乱掉。

多轮对话的底层逻辑其实并不复杂，每次调用大模型时把之前的对话历史一起塞进去就好了。

Spring AI 的 ChatMemory 已经把这件事封装好了。但有三个问题接踵而至：

这篇内容将从 Spring AI 的 ChatMemory 机制讲起，再拆解求职派在它基础上做的三层改造。

智能裁剪、文件持久化、复合 ID 隔离。

读完你就能搞清楚，一个生产级别的多 Agent 系统到底应该怎么管理聊天上下文。

01、大模型的记忆

大模型本身是无状态的。

每一次 API 调用，对它来说都是一轮全新的对话。它不知道上一轮说了什么，也不关心对面是谁。

那为什么我们和 ChatGPT、DeepSeek 这些产品聊天时，它们似乎“记得”之前的内容？

答案很简单，客户端在每次发消息时，会把之前所有的对话历史一起拼进请求体发给大模型。大模型看到的不只是刚输入的那一句提示词，还有从第一轮到当前轮的完整对话文本。

换个说法，“记忆”不是大模型的能力，是调用方的职责。

谁负责把历史对话管理好、拼接好、传递好，谁就决定了多轮对话的质量。管理得好，大模型就表现得像一个有连贯思路的助手；管理得差，它每一轮都像刚入职的新人，什么都不知道。

Spring AI 把“管理对话历史”这个职责抽象成了一套模块化的记忆机制，来看看它具体怎么工作。

Spring AI 的记忆机制分两层，存储层和注入层。

存储层决定对话历史存在哪里。

Spring AI 内置了基于内存的实现，底层是 ConcurrentHashMap，开箱即用，服务重启就清零。

如果需要持久化，Spring AI 也提供了 JDBC、Cassandra、Neo4j 三种数据库方案，需要引入对应的 starter 依赖。

为了避免上下文窗口被无限撑大，Spring AI 提供了一个窗口管理器，默认保留最近 20 条消息，超出部分自动丢弃最早的消息（始终保留系统消息）。

窗口大小通过 maxMessages 参数调整，比如设为 10 就只保留最近 10 条。

注入层决定对话历史怎么塞给大模型。Spring AI 通过 Advisor 机制自动完成这件事，提供了两种注入方式。