第七章 · 会话记忆设计
本章定位：前面几章聚焦「单轮问答」——用户问一句、检索+生成答一句。但真实对话是多轮的：用户问「报销流程」，接着追问「那需要哪些材料」，再问「多久能到账」。如果系统记不住上文，每轮都当成全新问题，就会答非所问（「需要哪些材料」——什么材料？）。会话记忆就是让大模型在多轮对话中「记住上文」的能力。但记忆越多 token 越爆，成本越高——如何在「上下文不断」和「token 不爆」之间找平衡，是本章的核心。
本章分两部分：
- 上篇 · 概念与原理（科普）：大模型的「失忆」真相是什么？会话记忆的五种策略各有什么优劣？RAG 场景下 token 预算怎么分配？
- 下篇 · SparkX 源码落地（实践）：SparkX 的双层记忆（L1 滑动窗口 + L2 话题摘要）怎么实现？为什么摘要「只记话题不记答案」？跨会话持久记忆（L3）为什么默认关闭？
上篇 · 概念与原理
一、大模型的记忆真相：每次请求都是失忆的
1. 一个常见的误解
很多人以为：你跟 ChatGPT 聊了 20 轮，它「记住」了前面所有内容。真相是：大模型本身没有任何记忆。
大模型是一个无状态的函数——每次调用，它只看你这次传入的内容，之前聊过什么它完全不知道。你能感觉到它「记得上文」，是因为应用层每次都把历史对话重新塞进了请求里。
2. messages 数组就是记忆的全部
调用大模型 API 时，你传的是一个 messages 数组：
{
"messages": [
{"role": "system", "content": "你是客服助手"},
{"role": "user", "content": "报销流程是什么"},
{"role": "assistant", "content": "报销流程是：1.填单子 2.主管审批..."},
{"role": "user", "content": "需要哪些材料"}
]
}
第四条 user: 需要哪些材料 能被正确理解，仅仅是因为前面三条历史也被一起传进去了。大模型看到「报销流程」的上下文，才知道「材料」指的是报销材料。
如果删掉前面的历史，只传最后一条 需要哪些材料，模型根本不知道你在说什么。
3. Token 膨胀：记忆越多，成本越高
问题来了——历史对话越多，messages 数组越长，消耗的 token 越多：
- 每次请求都要把全部历史重新传一遍（模型是无状态的）；
- 历史越长，输入 token 费用越高、响应越慢；
- 超过模型的上下文窗口（如 128K），直接报错或被截断。
假设每轮对话 500 token，聊 50 轮就是 25000 token。第 51 轮请求要把前 50 轮全传进去——每轮的边际成本越来越高，呈二次方增长。
💡 这就是会话记忆要解决的核心矛盾：记得太少 → 上下文断裂、答非所问；记得太多 → token 爆炸、成本失控。需要一个聪明的策略在两者间平衡。
二、会话记忆的五种策略
1. 完整历史（Full History）
把所有历史对话原样塞进 messages。
- ✅ 优点：信息完整，不丢任何上下文；
- ❌ 缺点：token 线性增长，几轮后就爆；成本高、延迟大。
只适合极短对话（3~5 轮）或上下文窗口极大的场景。
🔒 以上为本章部分预览（约 10%）
本章剩余 90% 内容包含：关键源码逐行拆解、设计细节与工程权衡、代码示例与生产实践要点。
💡 本次展示的仅为部分预览内容（约 10%）。完整的源码深度解析包含每一个技术点的完整实现细节。点击上方按钮扫码加入知识星球，解锁全部内容。
