跳到主要内容

AI记忆的真相与核心概念

你有没有遇到过这种情况？

跟AI聊天，前一秒还在讨论某个具体的产品，你顺口追问一句"那它的保修期是多久？"，AI突然一脸懵逼地回复："请问您想了解哪款产品的保修期？麻烦提供一下具体的产品名称。"

或者你正在跟一个智能旅行规划助手聊天：

你：帮我规划一个去成都的5天行程 AI：好的！以下是成都5日游推荐行程：Day1 宽窄巷子+锦里，Day2 大熊猫基地……（详细回答） 你：第三天能换成去都江堰吗？ AI：请问您想去哪个城市旅行呢？可以告诉我您的目的地，我来帮您规划。

是不是很崩溃？你明明刚说了去成都，结果下一句它就忘了。

别急着骂AI傻，这事儿还真不能全怪它。今天就来聊聊大模型记忆的真相，以及必须搞清楚的四个核心概念。

一个扎心的事实：大模型没有记忆​

很多人用过ChatGPT、Kimi这类产品，感觉它们挺能记事儿的。聊了十几轮，它还记得一开始你说了啥，好像真的有"记忆力"一样。

但实际上呢？大模型的每一次API调用都是完全独立的。它压根不知道上一轮你说了什么，也不知道你是谁，更不会主动保存任何对话状态。

打个比方：大模型就像一个超级聪明但患有严重失忆症的专家。每次你去找他咨询，他都不记得你来过。你必须把之前聊的内容从头到尾再说一遍，他才能接上话茬。

那ChatGPT网页版为啥看起来有记忆呢？答案其实很简单——它把你之前所有的对话历史一股脑儿塞进了请求里，每次都重新发给API。模型看到了完整的聊天记录，自然就能接着聊，但本质上它每次都是从头看一遍。

核心认知

大模型本身没有记忆能力。所谓的"记忆"，其实就是开发者把对话历史塞进messages数组重新发送。记忆的管理权完全在你的代码手里，模型只是一个"看到什么就回答什么"的应答器。

记忆的真相：messages数组​

要理解这个机制，咱们得看看调用大模型API时到底发了什么。

单轮对话长啥样​

最简单的情况，只有系统指令和用户消息：

{
  "messages": [
    {"role": "system", "content": "你是一个旅行规划助手"},
    {"role": "user", "content": "成都有哪些必去的景点？"}
  ]
}

模型收到后正常回答，没有任何问题。

多轮对话又长啥样​

用户追问"那边住哪个区域比较方便？"，你需要把第一轮的内容一起发过去：

{
  "messages": [
    {"role": "system", "content": "你是一个旅行规划助手"},
    {"role": "user", "content": "成都有哪些必去的景点？"},
    {"role": "assistant", "content": "成都必去景点推荐：1.大熊猫繁育研究基地 2.宽窄巷子 3.武侯祠 4.锦里 5.都江堰..."},
    {"role": "user", "content": "那边住哪个区域比较方便？"}
  ]
}

因为模型看到了"成都""景点"这些前文信息，所以它知道"那边"指的是成都，能给出合理的住宿建议。

不带历史直接追问会怎样​

如果第二轮你只发了当前问题：

{
  "messages": [
    {"role": "system", "content": "你是一个旅行规划助手"},
    {"role": "user", "content": "那边住哪个区域比较方便？"}
  ]
}

模型看到的就是一个没头没尾的问题——"那边"是哪边？什么区域？它只能反问你"请问您想了解哪个城市的住宿推荐呢？"。

这就是开头那个让人抓狂场景的底层原因。

全塞进去不就完了？代价有点大​

既然记忆就是把历史消息塞进messages，那最简单的做法不就是——全部塞进去？用户聊了10轮，就把10轮的user+assistant消息全带上呗。

想法很美好，现实很骨感。实际跑起来会遇到一个很头疼的问题：Token膨胀。

来算笔账。假设一个旅行规划场景，每轮对话大概消耗这么多Token：

对话轮次用户消息AI回复单轮Token累计历史Token
第1轮40300340340
第2轮25200225565
第3轮50350400965
第5轮.........~1,600
第10轮.........~3,500
第20轮.........~7,000

这还只是对话历史。别忘了，如果你在做RAG系统，每次请求还得带上：

  • System Prompt：800~1,500 Token（角色定义、行为规范、输出格式要求等）
  • RAG检索结果：2,000~5,000 Token（从知识库召回的景点介绍、攻略文档等）
  • 预留输出空间：500~2,000 Token（留给模型生成回答的空间）

算一下：到第10轮时，总Token ≈ 1,200 + 3,500 + 3,000 + 1,500 = 9,200 Token。

到第20轮？轻松突破 15,000 Token。如果用户聊的是一趟复杂的跨国自由行规划，来回沟通几十轮，光对话历史就能吃掉上万 Token。

两个直接后果​

后果一：直接超限报错

有些模型的上下文窗口只有4K或8K Token，塞不下这么多内容，请求直接失败。

后果二：费用蹭蹭涨

就算模型支持32K甚至128K的上下文窗口，Token越多费用越高、推理速度越慢。每轮对话都带着完整历史，相当于每次都在为重复发送旧消息买单。

关键问题

会话记忆的核心难题不是"要不要记住历史"，而是怎么在有限的Token预算内，尽可能多地保留有用信息。

两大核心概念：Context、Memory​

在深入聊记忆策略之前，先把有些概念必须捋清楚。

Context：模型的视野范围​

Context（上下文）是模型生成回答时能看到的所有信息的总和。如果把大模型比作一个考生，Context就是它面前摊开的所有试卷和参考资料。

Context通常包含这些内容：

组成部分具体内容举个例子
指令System Prompt + User Prompt"你是旅行规划师" + "推荐成都行程"
对话历史之前几轮的问答记录上一轮用户问了什么，模型回了什么
外部知识RAG检索回来的文档片段从知识库中召回的景点介绍、酒店评价
工具清单Function Call/MCP工具的定义可用的天气查询工具、机票搜索工具
工具执行结果工具调用返回的数据天气API返回的"成都明天晴，25°C"

核心限制：Context受模型的最大上下文长度限制。而且别忘了，上下文窗口 = 输入Token + 输出Token。如果你用的是32K模型，那输入 + 输出加起来不能超过32K。

一句话记住

Context = 模型这次请求能看到的一切。Token是它的计量单位，Prompt是其中的一个组成部分。

Memory：靠代码"焊"上去的外挂能力​

Memory（记忆）是指AI系统记住和利用历史信息的能力。

重要澄清

Memory并不是大模型自带的能力——标准的大模型API每次请求都是无状态的，它不会自动记住上一次你们聊了什么。所谓的Memory，是开发者通过代码实现的，不是模型原生具备的。

Memory根据持续时间和用途，可以分成两类：

短期记忆（Short-term Memory）

  • 也叫"对话上下文"或"会话记忆"
  • 存储当前会话中的对话历史
  • 会话结束后就清空
  • 实现方式：把历史消息塞进messages数组

长期记忆（Long-term Memory）

  • 跨会话持久保存的信息
  • 记住用户偏好、历史行为、个人信息等
  • 下次对话时还能用
  • 实现方式：向量数据库、关系型数据库、专门的记忆框架（如Mem0）

举个例子：你今天跟AI说"我有恐高症，不要安排玻璃栈道"，三个月后让它给你规划新行程。如果只有短期记忆，它早就忘了你的恐高情况；如果有长期记忆，它会主动排除有玻璃栈道的景点。

关系图​

一次请求中，Context、Memory、Prompt、Token如何协作
一次请求中，Context、Memory、Prompt、Token如何协作

简单类比：

概念类比
Token构成句子的"字母"
Prompt你此刻问的问题
Context你和朋友聊天时，朋友脑子里记得的刚才聊过的所有内容
Memory（长期）朋友回家后写在笔记本上、下次见面还能想起来的事情

短期记忆与长期记忆：两个不同的战场​

理解了记忆的本质之后，我们需要认识到一个事实：记忆不是一个问题，是两个问题。

短期记忆——当前这通电话聊了什么​

短期记忆解决的是"同一次会话内，模型能记住前几轮聊了什么"的问题。

典型场景：用户打开旅行助手，从问"成都好玩吗"开始，一路追问行程、住宿、美食、交通，聊了十几轮。在这个过程中，模型需要始终知道用户是在规划成都之旅。

短期记忆的实现思路就是前面说的——把对话历史塞进messages数组。核心难点在于如何控制Token膨胀。

长期记忆——上次见面时你告诉我的事​

长期记忆解决的是"跨会话、跨时间，模型还能记住用户的偏好和关键信息"的问题。

典型场景：三个月前用户说过"我有恐高症，不要安排玻璃栈道""我喜欢清净的小众景点"。三个月后用户再来规划新行程，模型如果还能记住这些偏好，体验会好很多。

长期记忆不能靠塞messages来解决（三个月的聊天记录塞进去，Token早就炸了），需要借助外部存储 + 语义检索的方式，按需把相关记忆"召回"到当前Context中。

两种记忆的关系
  • 短期记忆 = 你正在打的这通电话里聊过的内容
  • 长期记忆 = 你的通讯录备注（"这个人怕辣""上次来买过蓝色款"）
  • 两者不冲突，生产级系统通常同时需要

本章小结​

回顾一下这一节的核心要点：

  1. Context是模型单次请求能看到的全部信息，受上下文窗口大小限制
  2. Memory是开发者通过代码实现的外挂能力，模型本身不具备记忆
  3. 大模型每次请求都是无状态的，"记忆"的本质是把历史信息塞进messages数组
  4. 记忆带来Token膨胀问题，需要在信息保留和成本控制之间找平衡
  5. 记忆分为短期记忆（会话内）和长期记忆（跨会话），是两个不同层次的问题

下一节，我们来聊聊当Context信息过多时会出现哪些"翻车"事故，以及怎么用上下文工程的思路来应对。

🎁优惠