当AI拥有记忆——上下文工程的世界
当AI拥有记忆——上下文工程的世界
一个让人困惑的现象
早上九点，你打开电脑，开始与一个AI助手协作撰写一份项目报告。第一轮对话，你告诉它："请帮我写一份关于'城市垃圾分类'的项目报告，目标读者是高中生，篇幅3000字左右。"AI回应得体，给出了一份结构清晰的大纲。第二轮，你说："在大纲的第二部分加入上海和深圳的对比案例，并各引用一份近三年的统计数据。"AI顺利执行，给出了两个城市的对照段落。第三轮到第五轮，你们依次讨论了引言的切入角度、数据来源的权威性、图表风格的整体调性。AI表现得像一个合格的协作伙伴——它记得报告的定位，记得目标读者是高中生，记得你偏好的图表风格。
但到了第六轮，当你问："关于上海和深圳的对比，能否进一步细化数据并补充垃圾分类准确率的演变？"AI的回应开始变得奇怪。它似乎忘记了你们之前确定的报告结构，把对比段落放在了一个完全不相关的位置；它引用了一份你从未提及的数据源；它甚至把目标读者写成了"环保政策制定者"——这是你们在第三轮明确排除的选项。
你怀疑：AI是不是"变笨了"？还是它根本没有"记住"你们之前的对话？如果把同样的任务分发给一个新人，对方大概率不会犯这种错误。
如果把这个问题抛给一个AI研究者，得到的答案会非常冷静：AI从未真正"记住"任何东西。它只是在每一轮对话中，根据当前可见的"上下文"，重新计算出一个回答。 所谓"遗忘"，并非AI主观上抛弃了信息，而是更早之前的信息已经滑出了它的"视野"——或者虽然仍在视野中，却因为距离过远而被"稀释"了。
这个现象，正是"上下文工程"（Context Engineering）这门新兴学科要解决的核心问题。
什么是上下文：四层结构
要理解AI为何"遗忘"，首先必须澄清一个看似简单、实则极其复杂的概念——"上下文"。
在日常语言中，"上下文"指的是"与某句话相关的背景信息"。但在AI系统中，这个词的含义远不止于此。一个AI系统在生成回复时，会同时考虑四种不同来源的信息。这四种信息共同构成了AI所"看见"的全部世界。理解这四层结构，是掌握上下文工程的起点。
第一层：输入上下文。 这是当前用户发送给AI的消息本身——你刚刚打出的那句话、那张图片、那段代码、那个上传的PDF。输入上下文是AI每轮对话的"触发器"，也是最直接、最强相关的信号。一个优秀的输入描述，会让AI的回应质量产生天壤之别。例如，"写一首关于秋天的诗"与"写一首七言绝句，主题是深秋的萧瑟，押平水韵'尤'韵部"所产生的输出完全不同。输入上下文的艺术，本质上是"如何向一个没有任何先验知识的旁观者讲清楚你的需求"。
第二层：对话历史。 这包括从对话开始到当前时刻的所有"用户消息"和"AI回复"。对话历史赋予AI"短期记忆"，使它能够理解指代关系（如"它"、"那个"、"上面提到的方法"）、追踪话题演变、保持语气一致、处理多轮澄清。例如，当你第三轮说"它"时，AI需要知道"它"指的是第一轮提到的"垃圾分类"还是第二轮提到的"上海"——这种指代消解完全依赖对话历史。然而，对话历史是上下文中最容易"溢出"的部分——一旦对话超过模型的处理上限，最早的信息就会被截断。这也是开篇案例中AI"遗忘"的直接原因。
第三层：外部知识。 这是AI通过检索、工具调用、API查询等方式，从外部数据源获取的信息。它可以是一篇最新的新闻报道、一份公司内部文档、一个数据库查询结果、一段实时天气数据。外部知识让AI突破训练数据的时效限制，使其能够回答"今天北京发生了什么"、"公司去年Q4的营收是多少"这类问题。但外部知识也引入了新的复杂性：检索质量（是否找到了真正相关的内容）、相关性排序（多个结果中哪个更重要）、信息融合方式（如何把外部信息与对话自然衔接）都会影响最终输出。一个糟糕的检索系统，可能让AI自信地引用一份完全无关的文档。
第四层：系统状态。 这是AI运行时的"环境变量"——角色设定（如"你是一位耐心的数学老师"）、语气约束（如"回答必须使用第二人称"）、可用工具列表（如"你可以调用计算器和绘图工具"）、用户偏好设置（如"我喜欢简洁的回答"）、安全边界（如"不得讨论敏感政治话题"）。系统状态通常由开发者预设，对用户透明，但它从根本上塑造了AI的行为模式。例如，同样是GPT-4，在"程序员助手"模式下的回答与在"心理咨询师"模式下的回答截然不同——前者倾向于给出代码示例，后者倾向于先倾听与共情。
这四层之间的关系，可以用下图表示：
```mermaid flowchart TD Input[输入上下文] --> Engine[AI响应生成引擎] History[对话历史] --> Engine External[外部知识] --> Engine System[系统状态] --> Engine Engine --> Output[输出] ```
这张图揭示了一个反直觉的事实：AI不是"读心者"，也不是真正意义上的"思考者"，而是一个精密的信息整合器。 它的每一个回答，都是对四层上下文的综合"翻译"。当某一层信息缺失、过载或失真，最终的输出都会偏离预期。理解这一点，是掌握上下文工程的第一把钥匙。
窗口约束：AI记忆的物理边界
为什么对话历史会"溢出"？这要从AI模型的一个基本限制说起——上下文窗口（Context Window）。
上下文窗口是AI一次性能"看见"的最大信息量，通常用"token"来衡量。Token可以理解为AI处理文本的最小单位：英文中，一个token大约对应一个单词的子部分（如"unhappiness"可能被切成"un"、"happiness"两个token）；中文中，一个汉字通常对应1到2个token，一段100字的中文文本大约对应150-200个token。
早期的语言模型，上下文窗口只有几百到几千个token。这意味着AI一次只能"记住"大约一两页纸的内容。一旦对话超过这个长度，AI就必须丢弃最早的信息——这就是"遗忘"的物理原因。
但问题不止于此。即使信息仍然在窗口内，AI对不同位置信息的"注意力"也是不均匀的。这源于Transformer架构的核心机制——自注意力（Self-Attention）。
自注意力允许AI在处理每一个token时，"关注"序列中所有其他token，并计算它们之间的关联强度。从原理上讲，这似乎意味着AI对所有位置一视同仁。但大量实证研究表明，距离当前位置越近的信息，AI的关注度越高；距离越远，关联强度越弱。 这种现象被称为"注意力衰减"（Attention Decay）或"中间遗忘"（Lost in the Middle）。
一项2023年发表于AI顶级会议的研究发现，当关键信息被放置在长上下文的"中间位置"时，AI的检索准确率会显著下降——开头和结尾的信息更容易被精确回忆，中间部分则容易被"看漏"。研究者将这种现象形象地称为"U形注意力曲线"——AI对上下文两端的信息掌握最牢，对中间部分则相对模糊。
这种衰减现象带来一个重要启示：在AI系统中，"可见"不等于"可记"，"可记"不等于"可用"。 信息即使被塞进了窗口，也可能因为位置不当而失去效用。上下文工程的任务，就是在这个层层衰减的链条上，尽可能保留关键信息的"效用"——这要求我们不仅要管理"有多少信息"，还要管理"信息放在哪里"。
从规则到深度学习：上下文长度的技术演进
理解上下文窗口的演进，能帮助我们看清当下技术所处的位置，以及未来的可能方向。
第一代：规则系统（1960s-1980s）。 早期的对话系统（如1966年的ELIZA）完全依赖人工编写的规则。它们没有真正的"上下文理解"能力，只会根据关键词匹配和简单的模式替换生成回复。例如，当用户说"我今天很难过"，ELIZA可能会回答"为什么你今天很难过？"——这种问句并不是因为它"理解"了情绪，而是因为规则库里有一条"对包含'难过'的句子返回'为什么你...'句式"。这种系统的"上下文"极其有限，通常只能记住最近一两轮对话，远远谈不上"记忆"。
第二代：统计模型（1990s-2010s初）。 随着统计语言模型的发展，AI开始能够基于概率预测下一个词。这一时期的代表是n-gram模型和循环神经网络（RNN）。RNN引入了"隐藏状态"（Hidden State）的概念——一种在每一步处理中都会被更新的内部表示，使AI能够在一定程度上"记住"前文信息。但RNN的记忆能力有限：长距离依赖（如第50个词与第1个词的关系）很难被有效捕捉，因为梯度在反向传播过程中会逐渐消失。研究者用长短时记忆网络（LSTM）和门控循环单元（GRU）等变体部分缓解了这一问题，但本质上RNN仍是"逐步处理"——处理长序列既慢又易丢信息。
第三代：Transformer与深度学习（2017至今）。 2017年，Google发表了具有里程碑意义的论文《Attention Is All You Need》，提出了Transformer架构。Transformer的核心创新是自注意力机制——让AI能够直接计算序列中任意两个位置之间的关联，无需像RNN那样逐步传递信息。这彻底改变了长距离依赖的处理方式。
Transformer的诞生，直接推动了上下文窗口的指数级扩张。下表展示了主流模型的上下文窗口演进：
| 时间 | 模型 | 上下文窗口（约） | 相当于 | |------|------|----------------|--------| | 2019 | GPT-2 | 1,024 tokens | 1-2页纸 | | 2020 | GPT-3 | 2,048 tokens | 3-4页纸 | | 2022 | GPT-3.5 | 4,096 tokens | 6-8页纸 | | 2023 | GPT-4 (8K) | 8,192 tokens | 约50页 | | 2023 | GPT-4 (32K) | 32,768 tokens | 约200页 | | 2023 | Claude 2 | 100,000 tokens | 一本书 | | 2024 | Claude 3 | 200,000-1,000,000 tokens | 数本书 | | 2024 | Gemini 1.5 Pro | 1,000,000-2,000,000 tokens | 数十本书 |
从1,024到2,000,000，三个数量级的跨越，仅用了五年。这背后，是位置编码优化（如RoPE旋转位置编码、ALiBi线性偏置注意力）、稀疏注意力（如Longformer的滑动窗口）、状态空间模型（如Mamba的线性复杂度）等一系列技术突破。
但窗口扩大，并不等于"记忆"完美。即使是支持百万级token的模型，仍然面临三方面挑战：
挑战一：注意力衰减依然存在。 长上下文中"中间位置"的信息仍然容易被忽视，窗口扩大并没有消除这一现象，反而让"中间位置"的范围变得更大。
挑战二：推理成本激增。 自注意力的计算复杂度是序列长度的平方（$O(n^2)$）。当窗口从8K扩展到1M，计算量增加约15,000倍。这意味着更长的窗口 = 更慢的响应 + 更高的费用。
挑战三：长文本理解偏差。 模型在处理长文本时，仍可能出现"答非所问"、"遗漏关键信息"、"逻辑跳跃"等问题。这些问题不能仅靠扩大窗口解决。
这些挑战，正是当前上下文工程研究的核心战场。
上下文工程的五大研究方向
当上下文窗口从几千扩展到几百万，一个新的问题浮出水面：如何在有限的计算资源下，让AI真正"用好"这些上下文？
这正是"上下文工程"作为一门学科的核心议题。它不是单一技术，而是一个由多个研究方向组成的体系。这五个方向相互交叉，共同构成了上下文工程的研究版图。
方向一：长上下文建模（Long-Context Modeling）。 目标是让AI能够更准确地理解超长文本中的语义关系。核心挑战是"如何在保持全局信息的同时，降低计算复杂度"。研究重点包括：改进注意力机制（如滑动窗口注意力，只让每个token关注邻近的几个窗口；稀疏注意力，让大部分token对之间不计算关联）、优化位置编码（让模型能够区分"开头"和"结尾"的位置信号）、提升模型在长文本上的推理能力（如"大海捞针"测试、跨段落逻辑链追踪）。这个方向解决的是"如何让AI看见得更清楚"。
方向二：信息压缩（Information Compression）。 当上下文超出窗口限制时，如何在保留关键信息的前提下压缩文本？核心思路是"让AI学会略读"。技术手段包括摘要生成（让AI把一段长对话压缩为几行总结）、关键信息提取（让AI从冗长文本中抽取"实体—关系—事件"三元组）、层级化记忆结构（把信息组织为"概要—要点—细节"的层级）。这类似于人类大脑的"遗忘机制"——不重要的细节被自动丢弃，核心要点被保留。例如，在撰写一份长报告时，你可能只记得"第一章有三个核心论点"这样的摘要，而忘记了每个论点的具体表述——信息压缩正是要模拟这种机制。
方向三：检索增强生成（Retrieval-Augmented Generation, RAG）。 不让AI一次性"读完"所有信息，而是在需要时动态检索相关内容。核心思路是"按需取用，而非全量加载"。技术实现包括：构建高效的向量数据库（把文本转为数学向量，使语义相近的内容在向量空间中距离也相近）、设计相关性排序算法（在多个候选结果中找出最相关的）、构建信息融合机制（把检索结果自然融入回答）。RAG的优势是处理成本低（无需一次性处理全部信息）、信息时效性强（可以随时更新外部知识库）；劣势是检索质量不稳定——一个糟糕的查询可能导致AI检索到完全无关的内容。
方向四：记忆管理（Memory Management）。 为AI设计"长期记忆"机制，使其能够跨对话保留用户偏好、历史任务、关键事实。核心思路是"让AI拥有持久身份"。技术实现包括外置记忆库（把重要信息存储到独立数据库）、向量记忆（用语义检索找到相关记忆）、事件日志（按时间顺序记录关键交互）。这与人类的"长期记忆"最为接近。例如，一个AI助手如果能记住"用户是高中生，偏好简洁回答，对数学感兴趣"——那它在每次新对话开始时都能提供个性化体验。
方向五：状态追踪（State Tracking）。 在复杂任务（如多步骤推理、工具使用、Agent协作）中，维护系统的运行状态——已完成哪些步骤、当前进度如何、下一步该做什么、临时变量是什么。核心思路是"让AI拥有工作记忆"。这要求AI具备类似人类"工作记忆"的能力——相当于解题时的草稿纸。例如，一个AI Agent在帮你订机票时，需要追踪"已搜索航班 → 已比较价格 → 待确认时间 → 待输入乘客信息"这样的状态链条。如果状态管理失败，Agent可能陷入重复操作或逻辑死循环。
本书的后续章节，将逐一深入探讨这些议题。
案例剖析：一场对话机器人的失败
理论分析之后，让我们回到实践，看一个真实常见的场景。
一位产品经理使用AI助手规划一个新功能的发布。他与AI进行了长达20轮的对话，覆盖了用户调研（3轮）、竞品分析（3轮）、功能设计（4轮）、UI草图讨论（3轮）、测试计划制定（3轮）、上线时间讨论（2轮）、文档输出（2轮）等环节。整段对话累计文本量超过15,000字，包含多张图表描述、若干数据表格、十几条用户访谈摘录。
但在第21轮，当他说："按照我们之前讨论的方案，生成最终的产品需求文档"时，AI输出了一个混乱的版本——它遗漏了三个关键功能，把UI草图描述错了（将"卡片式布局"写成了"列表式布局"），把目标用户群体写成了"中小企业管理者"（实际是"个体创业者"），并且把上线时间推迟了一个月（与第19轮确认的日期不一致）。
事后复盘，这场"失败"的原因可以追溯到上下文的多个层面：
问题一：对话历史溢出。 在20轮对话中，累计文本量超过了模型的上下文窗口（假设该模型限制为32K token，约等于15,000-20,000中文字）。系统为了"塞进"所有内容，对较早的对话进行了截断或压缩，导致用户调研阶段（前三轮）确立的核心信息丢失。这是"遗忘"的直接物理原因。
问题二：信息位置不当。 关键的功能决策（如"必须包含A、B、C三个核心功能"）被讨论在对话的第7到第10轮，恰好处于"中间位置"。根据注意力衰减规律，这部分信息在后续对话中被"覆盖"或"稀释"的概率最高。即便没有溢出窗口，这些信息也可能因为距离过远而失去效用。
问题三：缺乏结构化记忆。 所有讨论都以自由文本形式存在于对话历史中，没有被抽取为结构化条目（如"功能列表：[A, B, C, D, E]"、"用户画像：{年龄：25-35，职业：个体创业者，核心痛点：获客成本高}"）。当对话过长时，AI难以从冗长的自然语言中精确检索这些信息——就像让一个人在20分钟的录音中精确找出"他说了哪三个功能"一样困难。
问题四：未使用外部记忆。 产品经理没有要求AI建立"项目笔记"或"决策日志"。如果每轮关键决策都被记录到外部文档（如一份持续更新的Markdown文件），并在需要时检索回来，"遗忘"问题会大幅缓解。这是典型的"检索增强"思想——把AI无法稳定记住的内容外包给外部系统。
问题五：缺乏状态追踪。 20轮对话跨越了多个子任务（调研→设计→测试→上线），但AI没有维护一个明确的状态标记："当前处于哪个阶段？哪些任务已完成？"导致在最终输出时，它无法精确判断"应该输出什么"。
这个案例揭示了一个重要规律：上下文工程的失效，往往不是单一原因造成的，而是多个层面的累积效应。 改进方案也需要从多个维度同时入手——压缩早期历史、优化关键信息位置、建立外部结构化记忆、动态检索关键事实、维护任务状态。这正是本书后续章节将要系统展开的内容。
本书的整体框架
理解了问题与研究方向，我们现在可以勾勒本书的脉络。本书按照"理解—压缩—扩展—管理"的逻辑递进展开，共十五章。
第一部分：理解（第1-3章）——建立对上下文的本质认识。 第一章你已经看到，本章从现象入手，引出上下文的四层结构。第二章将深入"信息流的本质"，从信息论和认知科学的角度，探讨为什么有些信息更容易被记住、有些更容易被遗忘。我们将引入"信息熵"、"冗余度"、"信号与噪声"等概念，建立评估信息价值的理论工具。第三章聚焦"注意力机制"，揭示AI如何"选择"关注哪些信息——这是所有上下文技术的理论基石。我们将剖析自注意力的数学原理，解释"为什么距离影响关注度"，并讨论新兴的注意力优化技术。
第二部分：压缩（第4-6章）——当上下文超出窗口时如何处理？ 第四章讨论摘要技术，让AI学会"略读"——如何在保留核心语义的前提下大幅缩短文本。第五章探讨关键信息提取，让AI识别"必须记住"的核心事实，建立结构化知识库。第六章引入层级记忆结构，让AI像人类一样区分短期记忆（当前对话）、工