记忆的起源——为什么AI也需要'记住'
记忆的起源——为什么AI也需要"记住"
你有没有过这样的经历——上课时老师正讲到二次函数的顶点公式，黑板上密密麻麻写着推导过程，你正听得入神。突然，前排的同学举手问了一个关于之前数学课的问题，老师愣了两秒，然后……完全忘记了刚才在讲什么。Ta 转头看了一眼备课本，尴尬地笑了笑："呃……我们刚才讲到哪儿了？"
教室里一片笑声。但你有没有想过，这种"上一秒还在讲数学，下一秒就失忆"的情况如果出现在每天帮你解答问题的 AI 身上，会有多崩溃？
——这就是我们这本书要回答的第一个问题：AI 到底有没有"记忆"？如果有，它跟我们人类的记忆有什么不同？
如果说 ChatGPT 是 2022 年底点燃全世界的"人工智能时刻"，那么"上下文工程（Context Engineering）"就是 2024 年到 2026 年之间，让这场革命真正进入"实用阶段"的关键技术。没有上下文工程，AI 只是一个会说话的金鱼；有了上下文工程，AI 才能成为能跟你连续讨论三个小时作业的"学霸同桌"。 这本书，就是要把这门突然火爆的学科，从底层原理到实战技巧，给你完整地讲清楚。
我们先从最基础的问题开始：为什么人和 AI 都逃不掉"记忆"这件事？
---
1.1 人类的记忆是怎么"运作"的
在我们讨论 AI 之前，得先搞清楚人类自己的记忆长什么样。
科学家们通常把人类的记忆分成三类：感觉记忆（Sensory Memory）、短期记忆（Short-Term Memory）、长期记忆（Long-Term Memory）。
- **感觉记忆**只能维持几百毫秒。比如你眼睛扫过一行字，那一瞬间你的视觉皮层会"留住"这行字的影像，但如果你不去注意它，这个影像马上就消失了。
- **短期记忆**（也叫**工作记忆 / Working Memory**）能维持大约 15 到 30 秒，容量大概是 $7 \pm 2$ 个组块（chunk）。所谓"组块"，就是你大脑里把信息打包的单位。比如记一串电话号码 "13800138000"，如果你把它分成 "138-0013-8000" 三个组块，就比死记 11 个数字容易得多。
- **长期记忆**则是大脑里那个神奇的"硬盘"，理论上容量近乎无限，但它的代价是：你得有意识地复习、编码，否则它会"褪色"，甚至完全想不起来。
举个例子：你现在能脱口而出"床前明月光"这首诗，是因为你小时候反复背诵，把它从短期记忆搬到了长期记忆里。但你大概率记不起三天前早餐吃的具体是什么——因为那些细节没有被反复强化，已经被大脑"清理"了。
这就是著名的 艾宾浩斯遗忘曲线（Ebbinghaus Forgetting Curve）：新学到的东西，如果在 24 小时内不复习，就会遗忘大约 70%；一周后不复习，可能只剩下不到 10%。
记忆不是免费的。 大脑要消耗能量来"维持"一段记忆。短期记忆容量小、容易丢；长期记忆容量大、但需要"反复练习"才能存进去。这是一笔典型的生物学交易。
那么问题来了——AI 呢？它也有这种感觉记忆、短期记忆、长期记忆吗？
答案是：有类似的概念，但本质完全不同。
---
1.2 AI 的"记忆"——一个完全不同的物种
我们先来看一段你和 AI 的真实对话：
> 你：帮我写一个 Python 函数，计算斐波那契数列。 > AI：好的，下面是代码…… > 你：再加一个参数，让它支持从第 N 项开始算。 > AI：好的，下面是修改后的代码…… > 你：再把变量名改成英文。 > AI：好的，下面是……咦，你说的是哪个变量？
最后那个"咦"，在真实场景中太常见了。AI 好像突然忘了你们前面聊了什么。
为什么会这样？因为AI 模型本身是"无状态（stateless）"的——这个词听起来很学术，其实意思很简单：
> 每一轮对话开始时，AI 的脑子里其实是"空白"的。它之所以能接上你上一句话，是因为开发者把你们之前的对话历史，临时塞回了它的输入框里。
这就引出了我们这本书最核心的概念——上下文（Context）。
Context 这个词在英文里既有"上下文"的意思，也有"环境、背景、语境"的意思。 对 AI 来说，Context 就是它当下能"看见"的所有信息：你的问题、之前的对话历史、系统提示、工具调用结果、检索到的文档……全部打包成一坨文字，喂给模型。
你可以把 Context 想象成 AI 的"短期工作记忆"。它的容量是有限的——这个容量上限，我们叫上下文窗口（Context Window）。当新的对话进来，旧的对话就会被挤出去；如果一次性塞太多东西进窗口，AI 就会"装不下"，开始出现"失忆"甚至"胡言乱语"的现象。
这就是为什么 ChatGPT 早期版本聊久了会"忘记"开头的设定，Siri 经常听不懂你十分钟前说的话。不是因为它笨，而是它的"记忆容量"被塞满了。
接下来，我们就把 AI 的记忆这个"新物种"剖开来看一看。
---
1.3 上下文 = AI 的"短期工作记忆"
现在，让我们更正式地定义一下。
上下文（Context） 是指在某一次 AI 调用（inference call）中，模型能够"看到"的所有输入内容的总和。这些内容包括但不限于：
1. 系统提示（System Prompt）：开发者写给 AI 的"角色设定"，比如"你是一个耐心的数学老师"。 2. 用户输入（User Input）：你这一轮说的话。 3. 对话历史（Conversation History）：你和 AI 之前几轮的问答。 4. 工具调用结果（Tool Outputs）：如果 AI 调用了搜索引擎、计算器、数据库，返回的结果也会被加进上下文。 5. 检索增强（RAG, Retrieval-Augmented Generation）：从外部知识库里临时抓来的相关文档。
这些内容会被拼接（concatenate）成一长串文本，然后被切分成一个个token（可以粗略理解为"字或词片"），送进模型里。
这里要解释一下 token。一个中文汉字大约是 1 到 2 个 token，一个英文单词大约是 1 到 1.5 个 token。GPT 系列模型用一种叫 BPE（Byte Pair Encoding，字节对编码） 的算法来切分 token。
举例来说，"你好"可能被切成 ["你", "好"]，"ChatGPT" 会被切成 ["Chat", "G", "PT"]。模型不是按"字"或"词"理解世界的，它是按 token 理解的。
那么，一个模型一次能"看见"多少 token 呢？这就是它的上下文窗口大小（Context Window Size）：
| 模型 | 上下文窗口 | 大约能装下多少内容 | |------|-----------|------------------| | GPT-3.5（2022） | 4K tokens | 约 3000 个英文单词 / 2000 个汉字 | | GPT-4（2023） | 8K / 32K tokens | 约 6000 / 24000 个英文单词 | | Claude 2（2023） | 100K tokens | 约 75000 个英文单词 / 5 万字 | | GPT-4 Turbo（2024） | 128K tokens | 约 96000 个英文单词 | | Claude 3.5（2024） | 200K tokens | 约 15 万个英文单词 | | Gemini 1.5 Pro（2024） | 1M–2M tokens | 约 75 万到 150 万个英文单词 |
（这里的"大约"是因为不同语言的 token 切分效率不一样，英文最省 token，中文最费。）
从 2022 年的 4K，到 2024 年的 2M（两百万 token），短短两年时间，上下文窗口膨胀了 500 倍。 这个变化，就是"上下文工程"这门学科突然爆火的核心原因——容量够了，才有"工程"可言。
厨房切菜板类比
如果上面那段表格让你有点晕，我们换个你更熟悉的东西：厨房里的切菜板。
想象你有一块切菜板，你要切一整个西瓜、一根胡萝卜、几片生姜、一把小葱。
- 切菜板就是**上下文窗口**。
- 西瓜、胡萝卜、生姜、小葱，就是**待处理的对话内容**。
- 你一次能在切菜板上铺多少食材，取决于切菜板有多大。
- 如果你硬要把一整个西瓜都铺上去，胡萝卜和小葱就会被挤到地上——**它们就"失忆"了**。
- 你也可以把切好的菜先放到冰箱里（**长期记忆**），但每次要用的时候，你还得把它们从冰箱里拿出来，重新铺到切菜板上。
注意一个关键点：切菜板上的东西是"实时"的，冰箱里的东西是"持久"的。 冰箱是外部存储（数据库、向量数据库、文件系统），切菜板是 Context Window。每次 AI 启动时，开发者需要从冰箱里"取出"相关的东西，"摆放"到切菜板上，模型才能看见。
这就是我们后面要反复讲的"上下文管理"——不是越大越好，而是要会"摆放"。
---
1.4 当 AI "失忆"——Siri 的十分钟前难题
理论讲完了，我们来看一个真实的例子——Siri 为什么常常听不懂你十分钟前说的话？
假设你和 Siri 有一段这样的对话：
> 你（上午 9:00）：Siri，帮我设置一个明天下午 3 点的会议提醒。 > Siri：好的，已经设置明天 15:00 的提醒。 > > 你（上午 9:02）：顺便问一下，明天的天气怎么样？ > Siri：明天北京多云转晴，最高温度 26°C。 > > 你（上午 9:05）：刚才那个会议，是几点来着？
你期待 Siri 会说"明天下午 3 点"。但真实情况很可能是：
> Siri：抱歉，我没有听清你说的会议时间，请再说一遍。
为什么会这样？因为在大多数 Siri 的对话设计里，每一次新的指令都被当作"独立事件"处理。除非你明确用引用代词（"刚才那个"、"上面那个"），并且 Siri 的对话引擎专门做了"上下文关联"，否则它不会主动去翻历史对话。
更糟的是：Siri 为了节省手机内存和电量，它的上下文窗口往往非常小——可能只有几千 token，而且只在"当前这一段对话"内有效。一旦你锁屏、退出 App、过几分钟再回来，上下文就被清空了。
这就是典型的"上下文丢失"问题。它不是 AI 模型本身的智力问题，而是上下文工程没做好——开发者没有设计一个机制来"保存"和"召回"相关的历史信息。
我们再来对比一下 ChatGPT。如果你用 ChatGPT（特别是 Plus 或 Team 版本）问同样的问题：
> 你：帮我设置一个明天下午 3 点的会议提醒。 > ChatGPT：好的，我会假设你是想设置一个提醒…… > > 你：明天的天气怎么样？ > ChatGPT：…… > > 你：刚才那个会议，是几点来着？ > ChatGPT：你之前提到的是明天下午 3 点。
为什么 ChatGPT 表现得更好？不是因为它更聪明，而是它的上下文工程做得好：它会自动把之前的对话历史打包进 Context Window，默认给你保留"上下文连续性"。
所以，AI 的"记忆力"差异，背后是上下文工程能力的差异。模型本身可能差不多，但不同的产品会设计完全不同的"记忆策略"。
一个更深刻的实验
2024 年初，斯坦福大学和谷歌的研究人员合作发表了一篇论文，叫 "Lost in the Middle"（迷失在中间）。他们做了一个实验：
> 给一个长上下文（比如 100K tokens，里面藏了 20 个关键信息），让模型回答问题。但是关键信息的位置随机——可能放在开头、中间、或者结尾。
结果发现一个让人吃惊的现象：
- **关键信息放在开头或结尾时，模型的准确率非常高（接近 95%）**。
- **关键信息放在中间时，模型的准确率暴跌到 60% 以下**。
这意味着：AI 不是"看到"所有上下文就一定会"用上"所有上下文。它对不同位置的信息有偏好，开头和结尾的信息最容易被"记住"，中间的信息容易被"忽略"。
这就是著名的 "Lost in the Middle" 现象。它直接催生了上下文工程中一个非常核心的设计原则：
> 重要的信息要放在上下文的开头或结尾，不要堆在中间。
比如你在用 AI 写代码，要把"代码风格要求"放在系统提示的开头，把"具体的代码任务描述"放在用户输入的结尾。这样模型最不容易"漏看"。
这种"位置敏感性"，是人类的短期记忆也有的特征——你还记得刚才我说"心理学的'序列位置效应'"吗？人类对开头和结尾的记忆最好，中间最容易忘。AI 和人类在这一点上，竟然惊人地相似。
---
1.5 上下文工程：让 AI "记住" 的设计学科
现在我们可以给"上下文工程（Context Engineering）"下一个定义了。
> 上下文工程，是一门研究"如何设计、组织、管理和优化 AI 系统所能'看见'的全部信息"的工程学科。 它的目标是在有限的上下文窗口里，最大化 AI 的输出质量、相关性和稳定性。
它包括但不限于以下几个子领域：
1. Prompt Engineering（提示工程）：如何写好"提示词"，让 AI 准确理解你的意图。 2. Context Window Management（上下文窗口管理）：如何在容量有限的情况下，决定哪些信息该被"塞进"窗口、哪些该被"丢弃"。 3. Memory Systems（记忆系统）：如何设计短期记忆、长期记忆的存储和检索机制，让 AI 在多轮、多会话中保持"连续性"。 4. Retrieval-Augmented Generation（RAG，检索增强生成）：如何从外部知识库里高效地"捞"出相关文档，补充到上下文里。 5. Tool Use / Function Calling（工具调用）：如何让 AI 学会"用工具"，并把工具调用的结果整合进上下文。 6. Multi-Agent Context Sharing（多智能体上下文共享）：在多个 AI 协作的场景下，如何设计共享和隔离的上下文。
一句话总结：上下文工程就是"给 AI 设计它的工作环境"。
举个生活中的例子你就懂了：
> 你同桌小明数学很差，但他其实不笨，只是他的"工作环境"一团糟——草稿纸乱堆、公式表找不到、上次做题的笔记也丢了。每次做题他都要从头翻起，所以效率很低。 > > 如果你帮他做一次"上下文工程"：把所有公式整理成一张卡片放在他面前、把做题的草稿分类摆放、把所有相关的笔记用夹子夹好随时可查——他的数学成绩会立刻提升。 > > AI 也是一样的。给它"收拾"好上下文，它就能发挥更强的能力。
上下文流动的循环
下面这张流程图展示了"上下文"在一个典型的 AI 对话中是如何流动的：
```mermaid flowchart TD A[用户输入 User Input] --> B[上下文缓冲区 Context Buffer] H[外部记忆 External Memory] -->|检索 RAG / 历史| B B --> C[模型推理 Model Reasoning] C --> D[生成输出 Output] D --> E[回到上下文 Return to Buffer] E --> B B -.->|超出容量| F[遗忘最旧信息 Forget Oldest] F --> B ```
看懂这张图，就理解了上下文工程的核心：它不是"一次性"的事情，而是一个持续的循环。
- 用户说一句话 → 这句话被加进上下文缓冲区。
- 缓冲区里的"全部内容"被送给模型推理。
- 模型生成回答 → 回答也被加进缓冲区（作为"助手"的回复）。
- 新的用户输入又进来 → 再加进缓冲区。
- 当缓冲区塞满（达到上下文窗口上限）→ 最旧的信息会被挤出去。
- 同时，如果需要"长期记忆"，相关的信息会被检索系统从外部数据库里临时调出来，塞进缓冲区。
这个循环每秒钟可能跑几十次。 它就是你和 AI"对话"的物理本质。
我们这本书后面所有的章节，都是在讲如何优化这个循环里的每一个环节。
---
1.6 为什么 2023 年之后这门学科突然火爆？
你可能会好奇：AI 这个概念火了几十年，为什么"上下文工程"到 2023 年之后才突然成为一门独立的学科？
答案藏在三个趋势里。
趋势一：上下文窗口的"摩尔定律"
如果你熟悉计算机行业，你一定听过 摩尔定律（Moore's Law）——芯片的晶体管数量每 18 到 24 个月翻一番。AI 的上下文窗口，在 2022 到 2024 年间，走出了类似的指数曲线：
- 2022 年（GPT-3.5）：4K tokens
- 2023 年初（GPT-4）：8K → 32K
- 2023 年中（Claude 2）：100K
- 2024 年初（Claude 3）：200K → 1M
- 2024 年中（Gemini 1.5 Pro）：2M
两年时间，容量涨了 500 倍。 当容量只有 4K 的时候，"上下文管理"几乎没意义——反正装不下什么。当容量涨到 100K 以上，"如何在这么大的窗口里放对东西"就变成了一门真正的工程。
趋势二：Agent 时代的到来
2023 年下半年开始，一个新概念横扫整个 AI 圈：AI Agent（智能体）。
所谓 Agent，就是能自主完成多步骤任务的 AI。比如让它"帮我订一张下周五去上海的机票，预算 1500 以内，靠窗座位"，它需要：
1. 查询你的日程，确认下周五有空。 2. 搜索航班，比较价格。 3. 选定一个航班，访问航空公司 API。 4. 填写乘客信息，支付。 5. 把确认邮件发给你。
每一步都需要调用工具、获取结果、做出决策。 这些"中间产物"全都要塞进上下文。当一个 Agent 跑完一个复杂任务，它的上下文里可能堆了上百次工具调用的结果。
这时候，"上下文管理"就从"锦上添花"变成了"生死攸关"——如果 Agent 忘了它前面查到了什么，整个任务就会失败。
这就是为什么 LangChain、LlamaIndex、AutoGen 这些 Agent 框架在 2023 年爆火——它们本质上都是"上下文工程框架