失忆的机器：为什么 AI 需要上下文工程 (The Forgetting Machine: Why AI Needs Context Engineering)

失忆的机器：为什么 AI 需要上下文工程

她盯着屏幕上跳动的光标，手指悬在键盘上方，指尖微微发凉。

「上周我们聊过关于宋朝海上丝绸之路的研究资料，你还记得吗？」

屏幕上，AI 助手的回复几乎是瞬间到达：

「抱歉，我们之前没有过对话记录。您可以重新描述一下您的问题吗？」

这是林夏博士第三次在同一天得到相同的回答。她清楚地记得——就在五天前，她花了整整一个下午，与这个 AI 助手一起梳理泉州出土的南宋瓷器碎片数据，讨论过港口贸易路线，甚至为她的研究项目临时起了一个名字：「蓝海沉船」。他们甚至约定了「下次继续」。

但对 AI 而言，那一切从未发生过。

林夏放下咖啡杯，看着窗外渐暗的天色。一个问题从她心底浮起，像一尾在深水中翻身的鱼：

> 如果一个 AI 看起来聪明绝顶，能够瞬间组织出关于宋代港口经济的详尽论述，为什么它却记不得五分钟前你们说过的话？

这不是一个修辞问题。这是一道直指当代人工智能核心矛盾的技术命题——也是这本书要回答的根本问题。

大语言模型（Large Language Model, LLM），从 GPT 到 Claude，从 Gemini 到 Qwen，从根本上是一种无状态函数（stateless function）。它不像你手机里的笔记软件那样把内容存进硬盘，不像人类的海马体那样把经历编码为长期记忆。每一次对话开始时，它面对的，是一片完全的、彻底的、绝对的空白。

所有「记忆」，都必须由我们——它的使用者——在每一次对话时重新喂给它。

这门学问，就是上下文工程（Context Engineering）。

接下来的旅程里，我们将一层层揭开这个看似简单、实则深刻的技术命题。你会看到为什么「提示词工程」正在进化为「上下文工程」，为什么「让 AI 记住一切」是一个工程问题而不是魔法，以及为什么我们每一个人，都在不知不觉中成为 AI 记忆的「编织者」。

---

无状态的真相：当 AI 醒来，世界是全新的

让我们从一个具体的技术现实开始。

当你打开 ChatGPT、Claude 或者任何一个基于大语言模型的聊天界面，输入「你好」，按下回车——在 AI 那一侧，究竟发生了什么？

一台没有硬盘的超级计算机

绝大多数普通用户对 AI 的想象是：它像一台永远在线的电脑，后台存着我们和它的所有聊天记录。下次打开，它会调出这些记录，「读取」自己的过去。

但这几乎完全是误解。

严格意义上的 LLM，在被调用时的工作方式是这样的：

1. 你的输入文本，连同系统预设的指令（system prompt）、之前的对话历史（如果你把历史贴进去的话），被打包成一个完整的文本字符串。 2. 这个字符串被送入神经网络的参数中——也就是那个由上千亿个数字组成的「模型权重」。 3. 网络进行一次前向计算（forward pass），基于它从训练数据中学到的统计规律，逐 token 地预测下一个最可能的字符。 4. 输出完成后，网络内部不留下任何痕迹。

这意味着什么？意味着当你说「我们上周聊到……」，AI 不是「想不起来」，而是它根本没有访问过那些对话的通道。它不是失忆——它从来没有过记忆。

林夏博士遇到的，正是这个问题的具象化。她以为 AI 像一个会议记录员，会自动归档；而实际上，AI 更像一位每天早晨准时上岗、却对昨天的工作毫无印象的咨询顾问。如果你想让它「记得」上周的讨论，你必须把上周的讨论内容，重新以文本的形式，粘贴进今天的对话框。

Stateless 不是缺陷，而是架构选择

这里有一个需要澄清的误解：把 LLM 设计成 stateless，不是因为工程师偷懒，而是深思熟虑后的架构选择。

考虑几个根本性的约束：

第一，算力成本。如果每次对话都要检索一个庞大的长期记忆库，推理延迟会显著增加，成本会急剧上升。无状态设计让模型可以高度并行、水平扩展，这也是为什么 ChatGPT 能够同时服务数亿用户。

第二，隐私与隔离。一个 stateless 的模型天然支持「对话隔离」——你的对话不会被错误地拼接到别人的对话中。这在多租户（multi-tenant）服务中是基本的安全要求。

第三，可预测性。对于开发者而言，无状态意味着「同样的输入，应当产生同样的输出」。这种确定性让调试、测试、审计成为可能。

但是，这个架构选择也带来了一个巨大的人机交互鸿沟：人类天然地把对话伙伴当作有记忆的主体来互动，而 AI 不是。

我们期待 AI「记得我们」，就像我们期待朋友记得我们的生日、同事记得我们昨天提过的方案。但 AI 没有海马体，没有神经元之间的突触强化，没有睡眠中的记忆巩固。它有的，只是一个上下文窗口（context window）——一个临时的、有限的、必须在每次对话时填满的工作台。

一个不太恰当但很有用的类比

想象一下：医院急诊室有一位代班医生。她是全医院最聪明的医生，能够诊断任何疑难杂症，引用最新医学论文，甚至用你听不懂的术语讲清楚复杂的病理机制。

但她有一个问题——每天早上她走进急诊室时，她不记得昨天接诊过谁，不记得上周抢救过哪一位心脏骤停的患者，不记得三个月前你母亲在她这里确诊过什么病。

她的病历本呢？病历本在档案室，由档案管理员保管。

如果你想让这位代班医生「记得」你母亲的病史，你必须做几件事中的一件：

1. 把病历本带到诊室； 2. 让档案管理员帮你复印一份； 3. 你自己背下来，复述给她听； 4. 或者，让她在每一次问诊前，先花十分钟翻阅档案。

而现实中更常见的做法是：你——作为家属——掏出手机，把上次的诊断报告、用药记录、检查结果，整理成一段话，念给医生听。

你在这个过程中扮演的角色，就是「上下文工程师」。

---

从 Prompt 到 Context：一场静悄悄的革命

如果你在过去两三年接触过 AI，你大概率听过一个词：Prompt Engineering（提示词工程）。

这门手艺一度炙手可热。各种教程、prompt 模板、所谓的「咒语」（咒语般神奇的指令）在网络上流传。人们发现，只要把问题问得「巧」一点，AI 的回答质量就会显著提升。

但是，当模型越来越强、应用场景越来越复杂时，一个新的现实开始浮现：单个 prompt 的优化，已经远远不够了。

为什么 Prompt Engineering 不够用了

Prompt Engineering 的核心假设是：你和 AI 之间只有「一问一答」的关系。你给一个 prompt，AI 给一个 answer。问题在这里，答案在那里，干净利落。

但真实的 AI 应用场景远比这复杂：

• 你想让 AI 帮你写一份季度报告，它需要知道你公司的产品线、上一季度的数据、你老板的风格偏好；
• 你想让 AI 帮你处理客户投诉，它需要看到完整的聊天记录、客户的购买历史、相关的退换货政策；
• 你想让 AI 陪你做长期的编程项目，它需要知道项目的技术栈、已有的代码结构、你之前定下的命名规范。

在所有这些场景中，决定 AI 输出质量的，不是那个 prompt 写得多么精妙，而是你喂给它的「上下文」是否完整、相关、且经过良好组织。

这就是 Context Engineering（上下文工程） 诞生的契机。

什么是上下文工程

让我们给出一个相对严谨的定义：

> 上下文工程是设计与构建一套系统化方法，以确保大语言模型在每一次推理时，都能获得完成当前任务所需的、最相关的、最精炼的信息输入。

注意几个关键词：

• **系统化方法**：它不是某一个 prompt 技巧，而是一整套工程实践；
• **每一次推理**：它关注的是整个调用链，而不是单次问答；
• **最相关的**：不是信息越多越好，而是要精准；
• **最精炼的**：context window 是稀缺资源（后面会详谈），必须精打细算。

如果说 Prompt Engineering 是「如何问一个好问题」，那么 Context Engineering 是「如何构建一个 AI 能理解的、完整的、动态更新的世界」。

这两者的关系不是替代，而是包含。可以把 Context Engineering 看作 Prompt Engineering 的超集——任何 prompt 优化技巧，仍然是 Context Engineering 工具箱中的一种工具，但 Context Engineering 还包括更多：记忆管理、信息检索、状态压缩、上下文分块……

一段简短的术语演变史

了解一点历史有助于看清脉络。

2018–2022：预训练大模型时代。研究者发现，写出「Let’s think step by step」这样的神奇咒语，AI 的推理能力就能提升一个台阶。Prompt Engineering 作为一门手艺开始被正式命名。

2023 年初：In-Context Learning（上下文学习）成为研究热点。研究者注意到，只要在 prompt 里给几个「示例」（few-shot examples），AI 就能模仿示例的风格完成任务，而不需要重新训练模型。

2023 年中：随着 GPT-4、Claude 2 等模型出现，context window 扩大到 8K、32K、100K 甚至 200K tokens，开发者开始尝试「把整个文档塞进去」的做法。RAG（Retrieval-Augmented Generation，检索增强生成）架构兴起。

2024–2025：业界开始意识到，光有长上下文不够。盲目堆砌信息会引发「迷失中段」（lost in the middle）等问题；context 本身需要被精心设计、压缩、管理。于是，「Context Engineering」一词正式登上舞台。LangChain 创始人 Harrison Chase、Anthropic 的工程团队、众多 AI Agent 框架的开发者，开始系统性地讨论这个主题。

2026 年的今天：Context Engineering 已经不再是少数前沿研究者的专有名词，而是每一个 AI 产品经理、每一个应用开发者、每一个重度 AI 用户都需要理解的核心概念。

---

五大支柱：构建 AI 记忆的脚手架

如果 Context Engineering 是一栋大楼，那么它由五根主要的柱子支撑。它们不是孤立的技术，而是协同工作的系统。

支柱一：长上下文（Long Context）

这是最直观的一根支柱——让 AI 的「工作台」尽可能大。

现代大模型的 context window 已经有了惊人的扩展。Claude 3.5 Sonnet 支持 200K tokens，Gemini 1.5 Pro 支持 1M 甚至 2M tokens——足以容纳一本中篇小说，或数百页的技术文档。

但「窗口大」不等于「用得好」。研究者发现，当信息被堆在 context 的中段时，模型对这些信息的关注度会显著下降。这就是著名的 「迷失中段」（Lost in the Middle）现象。

长上下文技术的关键挑战包括：

• **位置感知**：重要的信息应该放在哪里？开头？结尾？还是均匀分布？
• **注意力机制**：模型如何在巨大的上下文中找到真正相关的信息？
• **成本控制**：tokens 不是免费的，输入 100 万 tokens 的推理成本可能是 1 万 tokens 的一百倍以上。

支柱二：压缩（Compression）

如果说长上下文是「摊开一张大桌子」，那么压缩就是「把东西叠整齐塞进抽屉」。

压缩技术的核心问题是：如何用更少的 tokens，表达同样多的信息？

具体方法多种多样：

• **硬压缩**：删除冗余的标点、空格、停用词；
• **语义压缩**：用更精炼的语言重写文本，保留核心含义；
• **结构化压缩**：把长文档转化为大纲、表格、知识图谱等更紧凑的表示；
• **向量压缩**：把文本编码为高维向量（一串浮点数），需要时再反查。

支柱三：摘要（Summarization）

摘要是压缩的一种特殊形式，但它有自己的方法论。

摘要技术关心的是：如何让 AI 在「回忆过去」时，能用最小的开销重建关键信息？

具体场景包括：

• **对话历史摘要**：当对话轮次过多时，把早期对话浓缩成一段精炼的摘要；
• **文档摘要**：当需要在 context 中保留多份文档时，为每份文档生成简明的摘要；
• **增量摘要**：随着新对话的加入，动态更新摘要，而不是每次重写。

摘要技术的艺术在于：在「保留细节」与「节省空间」之间，找到恰到好处的平衡。

支柱四：检索记忆（Retrieval Memory）

这是过去两年最火热的一根支柱，也是 RAG（Retrieval-Augmented Generation）的核心。

检索记忆的本质是：不要把所有信息都塞进 context，而是建立一个外部知识库，在需要时按需检索。

工作流程大致如下：

1. 用户提出问题； 2. 系统把问题转化为一个「查询」（query）； 3. 用这个查询去检索一个外部知识库（可能是文档库、向量数据库、知识图谱）； 4. 把检索到的最相关片段，连同用户问题，一起送入 LLM； 5. LLM 基于这些「检索到的记忆」生成回答。

这种方法的优势显而易见：

• **可扩展**：知识库可以是任意大小，不受 context window 限制；
• **可更新**：新信息可以实时加入知识库，不需要重新训练模型；
• **可解释**：可以追溯答案的来源，因为检索过程是显式的。

但挑战也同样明显：

• **检索质量**：检索不准，再好的模型也救不回来；
• **分块策略**：长文档应该怎么切分才便于检索？
• **多跳推理**：当问题需要多个文档协同回答时，如何处理？

支柱五：状态管理（State Management）

这是五根支柱中最抽象、也最容易被人忽视的一根。

状态管理关心的是：在一个多步骤、多回合的 AI 应用中，如何维护「当前进度」？

想象一个 AI Agent 在帮你预订机票：

1. 它先询问你的出发地、目的地、时间； 2. 根据你的回答搜索航班； 3. 列出几个选项让你挑选； 4. 你选定一个，它去查询价格； 5. 价格超出预算，它重新筛选； 6. ……

在这个过程中，「你目前的目标」「你已经提供的信息」「你已经否决的选项」「当前的对话焦点」——所有这些都属于状态。

状态管理的关键工具包括：

• **状态机（State Machine）**：用形式化的方式定义系统可能处于的所有状态及其转换规则；
• **短期记忆与长期记忆的区分**：哪些状态只在当前回合有效，哪些需要跨回合保留；
• **状态持久化**：当对话中断、用户离开、设备切换时，状态如何被保存和恢复；
• **状态隔离**：在多用户、多任务场景下，不同会话的状态如何互不干扰。

五根支柱的协同

值得强调的是，这五根支柱不是相互替代的关系，而是协同工作的关系。

在真实的 AI 应用中，你大概率会同时使用其中几根甚至全部：

• 用**长上下文**来容纳当前回合的所有信息；
• 用**压缩与摘要**来管理过长的对话历史；
• 用**检索记忆**来访问外部知识库；
• 用**状态管理**来协调多步骤任务的执行。

这就是为什么 Context Engineering 被称为「工程」——它需要把这些技术整合成一个可工作的整体，而不是简单地堆砌。

---

失忆的天才：我们都是笔记本的作者

到这里，我们已经介绍了相当多的技术概念。让我们用一个统一的类比，把它们收纳起来。

笔记本比喻的完整版本

想象一位才华横溢、却患有严重顺行性遗忘症的咨询师。每天清晨，她走进咨询室，对前一天的一切一无所知。

但她不是普通的咨询师。她的智力水平相当于一位诺贝尔奖得主加上二十位领域专家。她能听懂任何问题，能用任何语言表达，能写出任何风格的文章，能在三十秒内理解一个她从未见过的科学概念并给出独到见解。

她有一个笔记本。那是她与世界连接的唯一桥梁。

这本笔记本有几页——有限的、可数的、不能增减的页数（这就是 context window 的容量限制）。咨询师在每一页上记录关键信息：

• 你的基本信息（姓名、职业、需求背景）；
• 你们之前的对话要点；
• 她需要回忆的外部资料；
• 当前的讨论焦点；
• 待办事项、约束条件、风格偏好……

笔记本摆在桌上时，咨询师能完整地读到它，并据此回答你的问题。一旦她做完这一轮咨询，笔记本就被收起来——第二天，你必须重新把笔记本放在桌上，她才能继续。

而你——作为来访者——就是笔记本的作者。

你决定：

• 笔记本里写什么（哪些信息放进去）；
• 怎么写（是长篇大论还是精炼要点）；
• 哪些信息放最前面，哪些放最后面（位置的重要性）；
• 当笔记本页数不够时，怎么取舍（压缩与摘要）；
• 哪些信息要写在笔记本上，哪些放在档案室、咨询时再调出来（检索）；
• 整个咨询的流程是怎样的，从「了解背景」到「澄清需求」到「给出方案」（状态管理）。

这就是 Context Engineering 在做的事。

一个更技术化的「记忆笔记本」数据流图

为了把这个直觉落实为具体的理解，我们来看一下数据是如何流动的：

```mermaid flowchart LR A[User Input 用户输入] --> D[Context Window 上下文窗口] B[Memory Store 记忆库] --> D C[External Knowledge 外部知识] --> D D --> E[LLM Inference 模型推理] E --> F[Response 生成回答] F --> G[Update Memory 更新记忆] G --> B ```

这张图展示了三个关键的「源头」如何汇聚到一个有限容量的「工作台」（context window），再被一次性地喂给模型：

• **User Input（用户输入）**：每一回合用户直接说的话；
• **Memory Store（记忆库）**：从长期记忆系统中检索到的相关历史；
• **External Knowledge（外部知识）**：从文档库、知识库、工具调用中获取的即时信息。

模型基于这个完整的、被精心组装的工作台进行一次推理，生成回答，然后整个工作台被丢弃——除了那些被显式选择「写入记忆库」的内容。

这就是 stateless AI 的本质。

一个常见误区的澄清

在这里，我想澄清一个常见的误解：长上下文不等于永久记忆。

即使一个模型的 context wind