什么是上下文工程：AI也需要"记性"

第 1 章　什么是上下文工程：AI 也需要"记性"

你有没有过这样的经历：打开一个聊天 AI，兴冲冲地问了一个复杂问题，AI 也给出了看起来头头是道的回答。你接着追问了一句"那如果是学生用户呢？"结果 AI 完全忘了你刚才问的是"如何设计一款英语学习 App 的首页"，开始一本正经地讲起"如何针对学生群体做营销"。你不得不再敲一遍"我是说 App 首页的设计……"。

那一刻，你是不是觉得 AI 有点"笨"？它明明刚才还在和你聊设计，聊得好好的，怎么一句话就"失忆"了？

别急，这不是 AI 的"智商"问题，而是它的"记忆方式"和我们人类完全不同。这背后藏着的，就是本书要讲的核心话题——上下文工程（Context Engineering）。说白了，就是研究怎么让 AI"记得住"、"记得对"、"记得全"的一门学问。

在我们正式踏上这段旅程之前，先用一个完整的章节帮你建立"全局视野"。读完这一章，你不仅能搞清楚"上下文工程"到底是什么，还能理解为什么它在 2024 年之后突然成为整个 AI 行业最热门的关键词之一，更能清楚地知道这本书将带你走一条怎样的路。

---

1.1　AI 为什么会"失忆"：从一次尴尬的对话说起

1.1.1　一次让你哭笑不得的真实场景

先让我们完整地"还原"一下开头的那个尴尬场景。小王是一家创业公司的产品经理，最近负责开发一款英语学习 App。这天他打开了某款 AI 助手，准备用 AI 来帮忙头脑风暴首页的设计。

第一轮对话： > 小王："我要设计一款英语学习 App 的首页，主要用户是大学生。你能给我一些首页应该包含哪些模块的建议吗？" > > AI："当然可以！针对大学生的英语学习 App，首页应该包含以下几个核心模块……"（然后给出了 8 个模块的建议，包括每日一句、单词挑战、口语跟读、学习打卡、课程推荐、学习社区、AI 老师、成就系统）

第二轮对话： > 小王："我刚才想到一个点子。如果我们首页一进来不是直接显示课程，而是先让用户做一个 1 分钟的英语水平测试，根据测试结果推荐不同的入门路径，你觉得这个想法怎么样？" > > AI："这个想法很有意思！1 分钟的英语水平测试确实是一个很有创意的方案……"（然后给出了一些关于水平测试的设计建议）

第三轮对话： > 小王："好的，那针对这个测试功能，你觉得测试题目应该怎么设计？" > > AI："测试题目的设计是英语学习产品的核心环节之一，针对不同年龄段的用户，我们需要考虑……"（然后开始泛泛而谈，完全忘记了前两轮对话中讨论的"针对大学生"这个用户定位，也忘记了"测试结果推荐入门路径"这个产品逻辑）

看到没？AI 在第三轮的回答里，开始出现一种很典型的症状：它在"通用层面"给建议，但完全丢失了前面已经建立起来的具体上下文。它甚至开始说"针对不同年龄段的用户"，好像前面没聊过任何用户定位一样。

这就是典型的"上下文断裂"。小王如果想继续用 AI 帮忙，就只能每次都把前面已经说过的内容重新打一遍，或者干脆放弃使用 AI，转而自己去想方案。

1.1.2　AI"失忆"的技术根源

为什么会这样？要回答这个问题，我们需要先了解 AI（大语言模型，Large Language Model，简称 LLM）到底是怎样"工作"的。

我们用一个简单但精确的比喻来解释。把一个大语言模型想象成一个超级博学、但只有 5 分钟短期记忆的专家。

这位专家读过人类有史以来几乎所有的书籍、论文、网页，所以他什么知识都懂，你问他历史、问他物理、问他做饭、问他写代码，他都能给你头头是道的回答。但是，他有一个致命的弱点：他记不住你们之前的对话。

更准确地说，他不是"记不住"，而是每一次新的对话，对他来说都是一次全新的开始。当你打开一个新对话框，问他"我们刚才聊到哪了？"，他会一脸茫然地回答你："抱歉，我无法访问之前的对话记录。"

这是为什么呢？因为从技术原理上讲，大语言模型是无状态（stateless）的。所谓"无状态"，是指模型本身不会自动保存任何与你对话相关的信息。每一次你发送消息，AI 给出的回复，都是基于一个完整的输入——而这个输入，就是当前这一次对话窗口里所有的消息。

我们看一下 AI 看到的"输入"到底是什么样子。当你在第三轮对话里发送"测试题目应该怎么设计？"时，AI 实际接收到的输入大致是这样的：

``` 系统提示：你是 AI 助手。 用户：第一轮消息（小王关于英语学习 App 的问题） AI：第一轮回复（8 个模块建议） 用户：第二轮消息（关于水平测试的点子） AI：第二轮回复（针对水平测试的反馈） 用户：第三轮消息（关于测试题目设计） ```

看起来 AI 应该"看到了"前两轮对话啊？为什么还是忘了呢？

这里的关键在于：模型"看到了"这些文字，并不等于它"理解并记住了"这些文字背后的语义关联。

随着对话轮次越来越多，这个输入会变得越来越长。而当前的 AI 模型（即使是 GPT-4、Claude 这样顶尖的模型）都有一个硬性的限制：它们能处理的输入长度是有限的。这个限制叫做上下文窗口（context window），它的单位是 token（可以粗略理解为一个字或一个词片段）。

举个例子：

• GPT-3.5 的上下文窗口大约是 16K token（约 1.2 万个汉字）
• GPT-4 早期版本是 8K 或 32K token
• Claude 3 达到了 200K token（约 15 万个汉字）
• Gemini 1.5 Pro 达到了 1M-2M token（约 75 万-150 万个汉字）

虽然这个窗口在不断扩大，但它依然有一个上限。而且即使窗口足够大，模型在长上下文中的表现也会出现"中间遗忘"现象——它对开头和结尾的信息记得比较清楚，对中间部分的信息会变得模糊。这就像你背一篇很长的课文，开头和结尾记得最牢，中间段落最容易记混。

1.1.3　"失忆"的三个层次

为了让你更系统地理解 AI 的"失忆"问题，我们可以把它分成三个层次：

第一层：会话内失忆（In-conversation Amnesia） 就是上面小王遇到的那种情况。在同一个对话窗口里，AI 忘记了前几轮已经确立的信息。这类问题的根源主要是上下文窗口长度的限制，以及模型在长上下文中对信息检索能力下降的问题。

第二层：会话间失忆（Cross-conversation Amnesia） 你今天和 AI 聊了一个复杂的产品方案，关闭对话框后，第二天再打开，问它"昨天我们聊的那个方案你还记得吗？"，AI 一脸茫然。因为对于 AI 来说，每开一个新的对话框，就是一次全新的开始，它没有任何"昨天"的记忆。

第三层：知识截止失忆（Knowledge Cutoff Amnesia） AI 的训练数据有一个截止日期。比如某个模型的训练数据截止到 2024 年 4 月，那它就完全不知道 2024 年 5 月之后发生的事情。你问它"2024 年巴黎奥运会的奖牌榜是什么？"，它要么承认不知道，要么一本正经地胡说八道（也就是所谓的"幻觉"，hallucination）。

本书要讲的上下文工程，主要解决的就是前两层失忆问题。第一层是核心，第二层是延伸。我们会在后面的章节中详细讨论每一层的解决方案。

1.1.4　为什么"失忆"问题突然变得重要？

你可能会问：AI 的上下文窗口不是一直在扩大吗？现在 Gemini 都支持 200 万 token 了，为什么还需要专门的"上下文工程"？

这是一个非常好的问题。答案有两层：

第一层：窗口大 ≠ 用得好。就像给你一个超大容量的硬盘，并不等于你会自动成为一个好的数据库管理员。上下文窗口变大后，新的问题出现了——怎么在海量信息里找到最有用的内容？怎么避免无关信息干扰模型？怎么让模型精准定位到它需要的那个细节？这些问题，就是上下文工程要回答的。

第二层：实际应用远比聊天复杂。你在和 AI 聊天时，可能对话 10-20 轮就到头了。但在真实的企业应用里，一个 AI 系统可能要处理成千上万轮对话，要管理数十万字的文档，要协调多个 AI 助手协同工作。这种规模下，"让 AI 记得住"就变成了一门复杂的工程学科。

正是这两个原因，让"上下文工程"（Context Engineering）这个概念在 2024 年开始被业界频繁提起，并逐渐成为 AI 产品开发的核心技术之一。

---

1.2　上下文的本质：AI 的"工作记忆"

既然"上下文"这么重要，那它到底是什么？要理解"上下文工程"，我们必须先彻底搞清楚"上下文"这个词的真实含义。

1.2.1　一个生活化的比喻：AI 的"工作记忆"

让我们从一个你非常熟悉的场景讲起。

假设你正在参加一场重要的工作面试。面试官问你："请介绍一下你过去三年最有成就感的项目。"

你开始回答："好的，我 2022 年在 ABC 公司担任产品经理的时候，主导了一个用户增长项目。当时我们的日活只有 5 万，到年底我们做到了 30 万。我做了三件事：第一，重新设计了用户激励体系；第二，搭建了用户分层运营的框架；第三，引入了 AI 推荐算法。"

面试官听完，继续追问："你刚才提到的 AI 推荐算法，能具体讲讲吗？"

这时候，你的回答就会基于前面所有的对话内容。你不会从"AI 是什么"开始解释，而是直接接续前面的信息："好的，刚才说到 AI 推荐算法，我们当时用的是协同过滤加内容标签的混合推荐……"

在这段对话中，让你能够做出自然、连贯回答的关键是什么？是你脑子里那个正在被使用的、与当前对话相关的记忆。心理学家把这种记忆叫做"工作记忆"（working memory）。

工作记忆有几个关键特征： 1. 它是临时的：一旦面试结束，你可能很快就会忘记这段对话的细节。 2. 它容量有限：你没法把整个简历、所有项目、所有知识点都同时调进工作记忆。 3. 它是可以被外部信息影响的：如果面试官突然问你一个完全不相关的问题，你的工作记忆就会被打乱。 4. 它依赖于"激活"：你需要主动去"想起"某些信息，才能把它们放进工作记忆。

对于 AI 来说，"上下文"就是它的工作记忆。

每一次你和 AI 对话时，AI 实际"看到"的所有信息——包括系统提示、你之前的对话、你刚刚发送的消息、可能还有它从外部检索到的文档——这些全部加在一起，就是 AI 在这一时刻的"工作记忆"。这个工作记忆，就是 AI 用来生成下一句回复的全部依据。

1.2.2　上下文的四大组成部分

那 AI 的"工作记忆"里到底装着什么？从内容来源上看，可以分成四大类。我们用一张图来展示它们之间的关系：

```mermaid flowchart TD A[AI的上下文工作记忆] --> B[系统层上下文] A --> C[对话层上下文] A --> D[知识层上下文] A --> E[工具层上下文] B --> B1[系统提示词<br/>角色设定和行为规则] C --> C1[多轮对话历史<br/>用户和AI的往来消息] D --> D1[外部检索的文档<br/>数据库或知识库内容] E --> E1[可用工具列表<br/>函数调用的描述和结果] ```

第一类：系统层上下文（System Context） 这是最底层的上下文，通常以"系统提示"（system prompt）的形式存在。它定义了 AI 的"人设"和行为规则。比如："你是一位耐心的英语老师，回答问题时要先用中文解释，再用英文举例。"这一类上下文通常由开发者设定，对用户是不可见的。

第二类：对话层上下文（Conversational Context） 就是你和 AI 在当前对话窗口里的所有往来消息。它是你和 AI 互动的"主战场"。

第三类：知识层上下文（Knowledge Context） 当 AI 需要回答一些它训练数据里没有的问题时（比如你们公司的内部产品手册），它需要从外部数据库或知识库里检索相关信息，把这些信息塞进上下文。这一类上下文是动态生成的，会随着用户的问题变化。

第四类：工具层上下文（Tool Context） 现在的 AI 助手越来越强大，可以调用外部工具，比如查天气、订机票、操作数据库等。当 AI 调用工具时，工具的描述、调用参数、返回结果，都会被塞进上下文。这一类上下文让 AI 具备了"动手能力"。

这四类上下文共同构成了 AI 做出每一个判断的"信息基础"。上下文工程的核心任务，就是在合适的时候，把合适的信息，以合适的方式，放进 AI 的工作记忆里。

1.2.3　一个反直觉的事实：上下文不是越多越好

聊到这里，你可能会觉得：既然上下文是 AI 的工作记忆，那我是不是把所有相关信息都塞给它，它就能表现得越好？

这是一个非常常见的误解。在很多情况下，过多的上下文反而会让 AI 表现变差。

这个现象在学术界叫做"上下文污染"（context pollution）或"中间遗忘"（lost in the middle）。2023 年的一项著名研究（论文名为 *Lost in the Middle*）系统性地验证了这种现象：即使模型支持很长的上下文窗口，当相关信息被放在上下文的中间位置时，模型对这些信息的利用率会显著下降。

为什么会这样？这和人类的认知特点非常相似。

你想一下，如果你走进一个会议室，里面堆满了 100 份文件，有人问你"我们去年那个项目的预算报告在哪？"，你会怎么找？你可能会先扫一眼最显眼的（开头和结尾），然后随便翻翻中间，但很难精准定位。如果这 100 份文件里只有 5 份和这个项目相关，你找起来就轻松多了。

AI 也是一样的。在它的"工作记忆"中，信息越多、越杂，它就越难聚焦到真正重要的内容上。

所以，上下文工程的精髓不是"塞满"，而是"取舍"。哪些信息必须放进去？哪些信息可以不放？哪些信息需要突出强调？哪些信息需要弱化或省略？这些判断，就是上下文工程师的核心能力。

1.2.4　一个完整的"上下文请求"长什么样？

为了让你对"上下文"有一个更具体的认识，让我们看一下一个真实的 AI 系统在处理一次用户请求时，它的"上下文"实际是什么样子的。

假设用户问了一个问题："我们公司去年的年假政策是怎么规定的？"

这个 AI 系统可能会这样组装它的上下文：

``` === 系统提示（固定不变）=== 你是一位专业的 HR 助手，名字叫"小 HR"。 你的职责是回答员工关于公司政策的问题。 回答时要： 1. 准确引用相关条款 2. 如果不知道，要诚实说明 3. 保持友好、耐心的语气

=== 对话历史（最近的 5 轮对话）=== 用户：你好 AI：你好，我是小 HR，请问有什么可以帮你？ 用户：我想了解下病假政策 AI：关于病假政策，根据《员工手册》第 X 条…… 用户：明白了，那年假呢？ [这是当前的问题]

=== 检索到的相关文档（动态生成）=== [文档 1：《员工手册 - 年假政策章节》] 第 X 条：员工每年享有 X 天年假…… 第 Y 条：年假申请需提前 X 天提交……

[文档 2：常见问题 FAQ 第 Z 条] Q：年假可以跨年使用吗？ A：根据公司规定……

=== 用户当前的问题 === 我们公司去年的年假政策是怎么规定的？

=== 工具调用结果（如果有）=== [如果 AI 调用了"查用户工号"的工具] 工具返回：用户工号是 EMP-12345，入职日期是 2020-03-15 ```

上面这个完整的输入，就是 AI 在生成回答时所"看到"的一切。你看到的不是"AI 的回答"，而是"AI 回答时所基于的全部上下文"。这两者是不一样的。

理解这一点非常重要。因为所谓"上下文工程"，本质上就是精心设计、动态组装、持续优化上面这堆内容的艺术和技术。

---

1.3　上下文工程的概念边界：它和提示工程有什么区别？

讲到这里，你应该对"上下文"和"上下文工程"有了基本理解。但我猜你心里可能还有一个疑问：这和我经常听说的"提示工程"（Prompt Engineering）到底有什么关系？是不是一回事？

好问题。这两个概念确实很容易混淆，但它们的关注点和应用场景有显著区别。我们用一节的内容把这件事彻底讲清楚。

1.3.1　什么是提示工程？

提示工程（Prompt Engineering）是一个更早出现的概念，它的核心问题是：怎样写一句（或一段）好的指令，让 AI 给出更好的回答？

我们用一个具体的例子来说明。

假设你想让 AI 帮你把一段会议录音整理成会议纪要。一段没有经过任何优化的提示可能是这样的：

> "请把这段会议录音整理成会议纪要。"

而一个经过提示工程优化的提示可能是这样的：

> "你是一位专业的会议记录员。请把下面的会议录音转写文字整理成结构化的会议纪要，包含以下几个部分： > > 1. 会议基本信息：会议主题、时间（如果能从对话中推断出）、参会人员 > 2. 讨论要点：用要点列表的形式列出每个议题的核心观点 > 3. 决策事项：明确指出本次会议做出的决定 > 4. 行动项：列出每个待办事项、负责人（如果提及）、截止日期（如果提及） > 5. 遗留问题：列出本次未解决的争议或需要后续跟进的问题 > > 转写文字如下： > > [会议录音转写文字] > > 请注意： > - 如果信息不全，可以标注"未提及" > - 保持客观，不要添加转写中没有的内容"

你看，提示工程关注的是这一次具体指令的设计：用什么角色、用什么格式、加什么约束、举什么例子。它的"工程对象"是单次输入到模型的这段文本。

1.3.2　什么是上下文工程？

上下文工程则是站在更高的层面，关注的是：为了完成一个完整的任务，AI 的"工作记忆"里应该装什么、不应该装什么、怎么装？

它关注的不是"一次提示怎么写"，而是"整个会话甚至整个系统里，上下文怎么管理"。

我们用同样的例子来对比。如果用上下文工程的视角来看"会议纪要"这个应用，我们需要考虑：

• **每次请求的上下文怎么组装？** 系统提示是什么？检索哪些历史会议？是否包含公司术语表？
• **怎么管理多轮对话？** 用户追问"那个负责跟进张总提到的产品方案，具体是谁？"时，AI 怎么从前面的会议纪要里找到对应的负责人？
• **怎么处理跨会话的记忆？** 用户上周开了一个产品方案讨论会，这周又开了一个相关会议，AI 怎么把两次会议的内容关联起来？
• **怎么过滤无关信息？** 一次会议可能聊了 10 个话题，但用户当前只关心"招聘相关的讨论"，怎么只把这部分内容喂给 AI？
• **怎么动