引言：为什么AI也需要'记忆术'

为什么AI也需要"记忆术"

如果你在2024到2026年这段时间里频繁使用ChatGPT、Claude、文心一言、通义千问或者任何一个AI助手，你大概率遇到过一种让人抓狂的情况：AI"失忆"了。

这种失忆不是科幻电影里那种"我是谁"的戏剧性遗忘，而是一种更隐蔽、更让人无奈的"工作记忆缺失"——它刚才明明听到了你说的关键信息，转过头就忘；它刚刚还在引用文档里的某段话，问到细节时就开始胡编；它在多步骤任务里跑着跑着就偏离了原本的目标，仿佛一个走丢了方向的快递员。

这种"失忆"不是bug，而是当前大语言模型架构的必然产物。要解决它，就催生了一门新的工程学科——上下文工程（Context Engineering）。这门学科的目标，简单说就是：让AI在有限的"脑子"里，记住最该记住的东西。

本书要讲的就是这件事。我们会用15章的篇幅，从AI大脑的工作原理讲起，一步步揭开上下文工程的六大核心技术，并通过大量真实案例展示如何把这些技术应用到日常工作和产品设计中。

但在开始这场探险之前，让我们先看看AI"失忆"到底是怎么发生的，又为什么会造成如此大的麻烦。

三个真实场景：AI"失忆"到底有多痛

抽象地讨论"AI记性差"难以引起共鸣。让我们先看三个真实发生过的场景，每一个都来自真实的产品案例或用户反馈。

场景一：聊了30轮后，AI开始"自相矛盾"

小张是一家SaaS公司的产品经理。他在准备一份竞品分析报告，让AI帮他梳理思路。对话一开始很顺利：

> 小张：我需要分析一下我们的产品Noteflow和竞品Roam Research、Obsidian的差异。我们的目标用户是知识工作者，特别是研究人员和咨询顾问。请你帮我列一个分析框架。 > > AI：好的。针对知识工作者，特别是研究人员和咨询顾问这个群体，我建议从以下五个维度展开分析……

前几轮对话质量很高，AI给出的框架逻辑清晰，角度全面。但随着对话推进到第15轮、20轮、25轮，问题开始出现：

> 小张：回到最初我们确定的目标用户。请你基于这个用户群体，重新审视一下你刚才提出的第四个分析维度是否合理。 > > AI：好的。基于您提到的目标用户——学生和职场新人，我认为第四个维度需要调整……

"学生和职场新人"——小张愣住了。他从来没有提过这个用户群体。他从一开始说的就是"知识工作者，特别是研究人员和咨询顾问"。AI不仅忘了最初的设定，还凭空编造了一个新的用户画像。

小张不得不在第28轮又重新强调了一次用户群体定义，才让AI"想起来"。

这种"金鱼记忆"现象在长对话中极为常见。研究人员Liu等人2024年发表在ACL会议上的论文发现：在一个有50轮对话的测试中，即使是最先进的模型，在30轮之后对最初设定的关键约束的回忆准确率也会下降到60%以下。换句话说，AI在你对话中段开始，就会逐渐"忘记"你最开始说过的核心信息。

场景二：200页的文档，AI只"看见"了头和尾

小李是一名律师。他需要审阅一份200页的并购合同，找出其中关于"对赌条款"的具体描述。他把整份合同上传给AI，然后问：

> 小李：请帮我找到第三章第四节关于对赌条款的描述，并总结其关键风险点。

AI花了20秒，给出了一段看起来很专业的回答。但小李一对照原文，发现AI引用的内容根本不在第三章第四节，而是从第七、八章的零散段落拼接出来的。AI甚至还"创造"了一个原文里根本不存在的条款编号。

发生了什么？

问题出在"迷失在中间"（Lost in the Middle）现象上。斯坦福大学和Samaya AI的研究人员在2023年发表的一项奠基性研究中发现：即使上下文窗口足够大、文档确实被完整地"装进"了AI的工作记忆，AI对位于文档中间部分的内容的回忆准确率也显著低于对开头和结尾部分的内容。

研究者设计了这样一个实验：准备20个文档（其中19个是干扰文档，1个包含问题答案），然后让模型回答一个只能靠那1个文档才能回答的问题。关键变量是这个"目标文档"在20个文档中的位置。实验结果呈现出明显的"V形曲线"：

• 当目标文档放在**第1位**（开头）时，模型回答准确率约为**74%**。
• 当目标文档放在**第10位**（中间）时，准确率骤降到**约57%**。
• 当目标文档放在**第20位**（结尾）时，准确率又回升到**约70%**。

这意味着：哪怕AI的"工位"足够大，能装下整份200页的合同，它对合同中间部分的内容也是"视而不见"的。 这不是bug，而是注意力机制的固有特性。

场景三：AI Agent在"订机票"任务里走丢了方向

小王想用AI Agent帮他订一张从北京到东京的机票，预算5000元以内，日期在国庆假期后，要靠窗座位。Agent开始工作了：

• 第一步：搜索航班信息 → 完成 ✅
• 第二步：筛选符合日期的航班 → 完成 ✅
• 第三步：筛选符合预算的航班 → 完成 ✅
• 第四步：检查座位偏好 → 完成 ✅
• 第五步：比价 → 完成 ✅
• 第六步：选择最优选项 → **问题开始出现**

在第六步，Agent推荐了一个航班，但它突然"忘记"了小王要的是"靠窗座位"，推荐了一个中间座位。更糟的是，在第七步准备下单时，Agent检查价格时引用的是"4000元"的航班（这是它内部生成的"记忆"），而不是第三步实际筛选出来的那个"4800元"的航班。

小王看着屏幕上Agent给出的最终方案，发现它自己和自己之前的工作成果产生了矛盾。如果不仔细核对就点击确认，可能会订错机票。

这个场景揭示了AI Agent的另一个关键问题：多步骤任务中的"状态漂移"。当一个任务需要分10步、20步执行时，每一步的中间结果、用户约束、决策依据都需要被"持续记住"。但AI的工作记忆有限，它会在执行过程中逐渐丢失这些状态信息，就像一个人在没有便签纸的情况下做一道需要20步的数学题——前面算的结果，到后面就忘了。

三个场景的共同根源

这三个场景看起来完全不同：一个是日常对话、一个是文档分析、一个是Agent执行。但它们背后指向同一个核心问题——

AI的"工作记忆"是有限的、有偏的、临时的。

具体来说：

• **有限**：上下文窗口有大小，AI不能在脑内装下无限多的信息。
• **有偏**：它对不同位置的信息关注度不同，开头和结尾的信息被"看得更清楚"，中间的信息容易被"忽略"。
• **临时**：一旦对话结束、任务完成，所有信息都会被清空，下次再问就是从零开始。

这三个特性合起来，构成了当下所有大语言模型的根本局限。也正是这三个局限，催生了上下文工程这门学科。

上下文窗口：AI大脑的"工位"就这么大

要理解AI为什么"失忆"，我们必须先理解一个核心概念：上下文窗口（Context Window）。

什么是上下文窗口

你可以把上下文窗口想象成AI的"工作台"。无论是大语言模型还是多模态模型，它们在处理任何一次任务时，都有一个固定大小的"工作台"，所有的输入信息——你的提问、之前的对话历史、上传的文档、工具调用的结果——都会被摊在这个工作台上。

工作台的大小是有限的。这个"大小"用一个叫做"token"的单位来衡量。一个token大致相当于一个英文单词的3/4，或者一个中文字符（中文标点会算成1个token）。常见模型的上下文窗口大小包括：

• GPT-3.5：4K tokens（约3000个汉字）
• GPT-4：8K~32K tokens
• GPT-4 Turbo：128K tokens
• Claude 2：100K tokens
• Claude 3：200K tokens
• Gemini 1.5 Pro：1M~2M tokens
• 国产大模型（文心、通义、Kimi等）：8K~200K不等

听起来动辄几十万、几百万token已经"很够用了"，对吧？但这里有两个隐藏的陷阱。

第一个陷阱：token不是"免费"的

你可能觉得"上下文窗口大"是个单纯的好事。但实际上，token是有计算成本的。

Transformer架构的核心是自注意力机制（Self-Attention）。在自注意力机制中，每一个token都需要和所有其他token计算相关性。这意味着计算量与token数量的关系是平方关系：如果token数量翻倍，计算量就变成4倍；如果token数量变成10倍，计算量就变成100倍。

用数学公式表示，自注意力的计算复杂度是：

$$O(n^2 \cdot d)$$

其中 $n$ 是序列长度（token数），$d$ 是隐藏层维度。当 $n$ 达到几十万、几百万时，这个计算量是非常惊人的。

这就解释了为什么同样是"读一篇文章"，使用128K上下文窗口的GPT-4 Turbo比使用8K窗口的版本贵得多、慢得多。窗口越大，单次推理的硬件成本和延迟都呈非线性增长。

所以在生产环境中，AI产品经理不会无脑使用最大的窗口。他们要在"能装下多少信息"和"花多少钱、等多久"之间做精细的权衡。这正是上下文工程要解决的第一类问题。

第二个陷阱：窗口大不等于"记得住"

更反直觉的是，即使信息被装进了窗口，也不等于AI能正确使用它。

这就是"迷失在中间"（Lost in the Middle）现象的核心结论。它的发现者是斯坦福大学的Nelson Liu和Samaya AI的研究员，他们2023年发表了一篇具有奠基性意义的论文。

在前文"场景二"中我们已经看到这个研究的关键发现：模型对中间位置文档的回忆准确率显著低于对开头和结尾位置的文档。一个"目标文档在第1位"的查询准确率约74%，在第10位时骤降到57%，在第20位又回升到70%。

这个"V形曲线"后来被无数后续实验反复验证。它的含义是：AI的注意力有强烈的"首尾偏好"，对中间位置的信息会"视而不见"。

这就像一个学生复习时只看了笔记的开头和结尾，中间部分被跳过了——而恰好考试题考的是中间部分。

为什么"迷失在中间"会发生？

要理解这个现象，我们需要深入AI的"大脑"——注意力机制。这正是我们下一节的主题。

注意力机制：AI"看见"信息的过滤器

要理解"迷失在中间"现象，我们必须理解Transformer架构的核心——注意力机制（Attention Mechanism）。

从"人脑注意力"到"机器注意力"

人类大脑的注意力是有选择性的。当你走进一个嘈杂的咖啡馆，背景音乐、邻桌的对话、咖啡机的嗡嗡声同时涌入耳朵，但你的大脑会自动"调低"无关声音的音量，把注意力集中在你朋友的声音上。这种"选择性聚焦"的能力，让我们能在海量信息中提取关键内容。

2017年，Google Brain团队在论文《Attention Is All You Need》中提出了一种让机器也具备类似能力的机制——自注意力机制（Self-Attention）。它的核心思想是：在处理一段文本时，让每一个词（或token）都"看一眼"其他所有词，并自动判断哪些词与自己更相关、应该获得更多"注意力"。

用一个简单的例子说明。假设AI正在处理这句话：

> "小明在北京参加了会议，他感到很开心。"

当AI处理"会议"这个词时，自注意力机制会让"会议"和句子中所有其他词计算相关性。结果可能是：

• "北京"：相关性 0.2（会议在北京开）
• "参加"：相关性 0.7（动词搭配）
• "他"：相关性 0.3（主语承接）
• "感到"：相关性 0.4（情感关联）
• "开心"：相关性 0.1（间接关联）

然后，AI会根据这些相关性加权求和，得到"会议"这个词的最终表示。相关性越高的词，对最终表示的贡献越大。

这就是为什么我们说AI"理解"了上下文——它通过相关性计算，把相关的信息"加权"到了自己的表示中。

注意力机制为何带来"位置偏差"

但自注意力机制有一个奇怪的特性：它本身对位置是"无感"的。

在数学上，自注意力机制没有内置"位置"的概念。如果不额外加入位置编码（Positional Encoding），AI甚至分不清"小明打了小王"和"小王打了小明"——因为它对词的顺序没有先验偏好。

为了解决这个问题，研究者引入了位置编码——给每个位置打一个"位置标签"，让AI知道"这是第几个token"。但这种"位置标签"的设计本身，就带来了"首尾偏好"。

具体来说，主流的旋转位置编码（RoPE, Rotary Position Embedding）和ALiBi（Attention with Linear Biases）等方案，都倾向于让"距离近"的token之间有更高的注意力权重，"距离远"的token之间注意力权重更低。这意味着：

• 当前位置的相邻词（开头、结尾附近）容易获得较高注意力
• 远离当前位置的词（中间部分）容易被"稀释"

用一个比喻：自注意力机制像一束"聚光灯"，它能照亮当前正在处理的token附近的内容，但对远处的token就模糊了。在一份长文档中，AI当前正在处理第5000个token时，它对第1个token和第10000个token的"关注度"，会显著低于对第4900~5100个token的"关注度"。

这就是"迷失在中间"的根本原因——不是AI看不见，而是AI"不够关注"。

"有效上下文"与"原始上下文"的鸿沟

基于以上分析，我们可以区分两个重要概念：

• **原始上下文（Raw Context）**：模型理论上的输入容量，比如128K tokens。
• **有效上下文（Effective Context）**：模型能"高保真"使用的输入容量，往往**远小于**原始上下文。

研究者在2024年的一项研究中测过，对于一个宣称支持128K tokens的模型：

• 在文档**前10%**和**后10%**的位置，回忆准确率约为**80~85%**。
• 在文档**中段**（40%~60%位置），回忆准确率只有**50~60%**。
• 综合下来，**"有效上下文"大约只有原始上下文的40~50%**。

换句话说，一个128K的窗口，真正"好用"的部分可能只有50K~60K。剩下的部分虽然被装进了窗口，但AI对它们的"记忆"是模糊的、不确定的。

这就像你有一个10米长的书架，但你的阅读专注力只能覆盖中间2米的内容——书架两头的东西你"知道在那里"，但具体内容你"看不太清"。

这个发现对我们意味着什么？

它意味着：不能盲目相信模型的"窗口大小"参数。一个声称支持1M tokens的模型，并不意味着你能把所有1M tokens的内容"等效地"使用。在产品设计中，你必须假设AI对不同位置的内容有不同程度的"记忆能力"，并据此设计信息的组织方式——把最关键的信息放在开头和结尾，把不重要的信息（或者可以"查到"的信息）放在中间。

这正是上下文工程要解决的核心问题之一。

上下文工程：管理AI记忆的新学科

理解了AI"失忆"的根本原因后，我们自然会问：有什么办法解决？

答案是：有一整套技术体系。这套技术体系在2024年到2025年之间被研究者们赋予了一个统一的名字——上下文工程（Context Engineering）。

从"提示工程"到"上下文工程"

在2023年之前，AI应用开发的主流方法是"提示工程（Prompt Engineering）"。它的核心是：怎么写一句巧妙的提示词，让AI给出更好的回答？

提示工程解决的是"怎么问"的问题。但随着AI应用变复杂，开发者们发现，光靠"问得好"远远不够。更重要的问题是：

• 对话太长，AI忘了前文，怎么办？
• 文档太长，AI装不下，怎么办？
• 任务太复杂，AI不知道当前进展，怎么办？

这些问题都属于"怎么管理AI能看到的所有信息"——而不仅仅是"怎么写一句提示词"。

于是，提示工程开始向上扩展。研究者们开始把视野从"一句话提示"扩展到"AI在一次任务中能看到、处理、记忆的所有信息"，包括：

• 系统提示（System Prompt）
• 用户对话历史（Chat History）
• 上传的文档（Documents）
• 工具调用的结果（Tool Results）
• 外部检索到的知识（Retrieved Knowledge）
• 任务执行的中间状态（Task State）

所有这些信息合起来，构成了AI的"上下文"。 而"上下文工程"，就是研究如何最优地组织、管理、利用这些信息的学科。

如果说提示工程是"教AI说话的艺术"，那么上下文工程就是"设计AI工作环境"的工程学。

上下文工程的正式定义

给上下文工程一个正式的定义：

> 上下文工程（Context Engineering） 是一门研究如何在大语言模型的有限上下文窗口约束下，最优地组织、筛选、压缩、检索、持久化输入信息，以最大化模型在具体任务上表现的工程学科。

它有四个核心特征：

1. 约束导向：明确承认上下文窗口是有限资源，所有设计都要在这个约束下进行。 2. 任务驱动：不同任务需要不同的上下文配置，上下文工程必须因任务而异。 3. 系统思维：上下文不是孤立的字符串，而是包含系统提示、对话历史、外部知识、工具结果的复杂组合。 4. 工程化：它不是"提示词技巧"，而是一套可复用、可测量、可优化的工程方法。

上下文工程的六大技术领域

为了更清晰地理解上下文工程的范畴，我们可以把它分解为六个相互关联的技术领域。下面这张全景图展示了它们之间的关系：

```mermaid flowchart LR A[AI记忆挑战<br/>窗口有限+位置偏差+信息过载] --> B[上下文工程<br/>Context Engineering] B --> C1[长上下文技术<br/>Long Context<br/>扩大窗口容量] B --> C2[压缩技术<br/>Compression<br/>降低信息密度] B --> C3[摘要技术<br/>Summarization<br/>提炼关键信息] B --> C4[检索增强<br/>RAG<br/>接入外部知识] B --> C5[记忆系统<br/>Memory<br/>实现持久记忆] B --> C6[状态管理<br/>State<br/>结构化任务状态] ```

让我逐一介绍这六个领域

让我逐一介绍这六个领域，并说明它们在本书中对应的章节。

**1. 长上下文