为什么你的 AI 总在「金鱼记忆」？— 上下文工程导论

为什么你的 AI 总在「金鱼记忆」？— 上下文工程导论

1.1 一个让产品经理崩溃的真实故事

凌晨 1 点 47 分，李薇盯着屏幕上 AI 给出的第 27 轮回复，眼睛快冒火了。

她过去两个小时在做一件看似简单的事：让 AI 帮她把一份 60 页的产品需求文档（PRD）压缩成一份给老板看的 3 页摘要。她按照自己多年的经验，先让 AI 总结文档的「核心目标」，再让它「列出关键功能模块」，然后让它「针对每个模块抽取 1-2 个最重要的验收标准」，再让它「把这些标准按优先级排序」……一切看起来非常顺利。AI 的回答逻辑清晰、措辞专业，李薇几乎觉得自己找到了完美的工作伙伴。

直到第 27 轮。

「请把上面的内容整理成 PPT 大纲，每页一个核心观点。」

AI 的回答是：

> 当然！以下是基于我们之前讨论的产品需求文档的 PPT 大纲： > 1. 产品愿景（此处内容缺失） > 2. 核心功能模块（此处内容缺失） > 3. 用户体验设计（此处内容缺失） > ……

「此处内容缺失」——AI 仿佛一个失忆的助手，礼貌地告诉你它记得你们聊过，但完全忘了你们聊过什么。

李薇刷新了一次，又试了一次。AI 还是同样礼貌地、同样空空地回复她。她尝试在第 28 轮把所有上下文重新粘贴一遍。这次 AI 终于又开始正常回答了——但两小时的对话积累被一次性清零。

她把这件事发到工作群里，得到的回复是清一色的「+1」：每个用过 ChatGPT、Claude、文心一言、通义千问的人都遇到过类似的事情。为什么？为什么我说了这么多轮，前面提过的需求它就是记不住？为什么明明是同一段对话，它却表现得像一条金鱼？

这就是我们要回答的第一个问题。

李薇遇到的不是 prompt 写得不好的问题。她写的 prompt 在业内可以打 90 分。她遇到的是一个更深层的问题：她从来没有管理过 AI 真正「看见」的东西。 她以为 AI 记住了对话历史，其实 AI 只是在每一轮重新读取一个正在滑动的窗口。她以为她在一个连续的对话里工作，其实她在一个不断被截断的截屏里工作。

这本书要解决的，就是李薇遇到的、以及你可能正在遇到的、所有和「金鱼记忆」相关的问题。我们不卖 prompt 模板，不教你怎么写「让 AI 听话的 100 句咒语」。我们要教你的，是如何管理 AI 真正能看见的全部信息。这门手艺，叫 Context Engineering（上下文工程）。

---

1.2 到底什么是「上下文」（Context）？

在我们谈如何「管理」之前，我们必须先搞清楚一个更基础的问题：当我们说「上下文」的时候，我们到底在说什么？

1.2.1 上下文 ≠ 提示词（Prompt）

很多初学者会把「上下文」和「prompt」混为一谈。这是一个常见的、但代价很高的误解。

简单地说：

• **Prompt（提示词）**：你这一轮对 AI 说的话。是「你怎么要求它」。
• **Context（上下文）**：AI 在这一次推理时能「看见」的全部输入。包括你的 prompt，包括历史对话，包括任何你塞进去的文档、工具返回值、记忆摘要……一切。

打个比方。如果 AI 是一个正在做数学题的学生，那么：

• **Prompt** 是「请解出这道题」。
• **Context** 是他桌上能看见的所有东西：题目本身、草稿纸、教科书、公式表、甚至同桌递过来的小抄。

学生能不能解对题，不仅取决于你怎么问他，还取决于他桌上摆了什么。如果公式表没在桌上，再聪明的学生也只能瞎猜。

Context Engineering 的核心，就是那张「桌子」的管理。

1.2.2 上下文窗口（Context Window）：那张桌子的尺寸

AI 模型处理信息的能力是有限的。这个限制由一个核心参数决定：上下文窗口（Context Window）。

上下文窗口是模型一次推理时能「看见」的输入（加它要生成的输出）的最大 token 数。你可以把 token 简单理解成「词的一部分」。一个汉字通常对应 1-2 个 token，一个英文单词通常对应 1-2 个 token，代码、表格、特殊符号各有不同的换算规则。

不同模型的上下文窗口差异巨大：

• 2020 年的 GPT-3：约 2,048 个 token（约 1,500 个汉字）
• 2023 年的 GPT-3.5：约 4,096-16,000 个 token
• 2024 年的 GPT-4 Turbo：128,000 个 token（约 9-10 万汉字）
• Claude 3 / 3.5：200,000 个 token
• Gemini 1.5 Pro：1,000,000 个 token（百万级）
• 2025 年的部分新模型：2,000,000 甚至更高

「上下文窗口变大」听起来像一个纯粹的好消息。但它带来了三个非常微妙的副作用，我们会在后续章节详细讨论。这里先剧透三点：

1. 「大海捞针」问题：上下文窗口变大，并不意味着模型在长上下文里能稳定地找到相关信息。研究表明，模型对上下文「中间部分」的注意力往往弱于对「开头」和「结尾」。这就是所谓的 Lost in the Middle（迷失在中间） 现象。 2. 成本问题：上下文窗口越大，单次调用的费用越高。如果你每次都塞满 100 万 token，钱包会比 AI 更先崩溃。 3. 延迟问题：上下文越长，推理越慢。实时交互场景里，把一本 1000 页的书塞进去等 30 秒不是用户能接受的体验。

所以，「上下文窗口」是约束，不是礼物。它是一张桌子的物理尺寸——桌子越大，能摆的东西越多，但摆放的艺术越复杂。

1.2.3 上下文的五个「成分」

为了后续讨论方便，我们把上下文拆成五个成分。这五个成分是任何 AI 系统在工作时的「必备配件」：

1. 系统指令（System Prompt / Instructions）：模型的人设、规则、约束。比如「你是一位资深律师，回答必须引用具体法条」。 2. 用户输入（User Query）：用户这一轮说的话。 3. 历史对话（Conversation History）：之前几轮的 user 和 assistant 消息。 4. 检索内容（Retrieved Content）：通过 RAG（Retrieval-Augmented Generation，检索增强生成）从外部知识库拉来的文档片段。 5. 工具调用结果（Tool Outputs）：AI 调用外部工具（搜索、计算器、API）后返回的数据。

一个完整的 context，就是这五样东西的拼盘。它们的比例、顺序、组织方式，每一项都决定 AI 的回答质量。

李薇的失败，正是因为她让历史对话无限制地膨胀，挤掉了其他成分的空间，最后连她最初的问题都被「挤出」了有效窗口。

1.2.4 一个直观的小实验

为了让你立刻感受到 context 的力量，请你做一个小实验。

实验 A（无 context）：

> Prompt：「这个产品的核心功能是什么？」

AI 会回答：「请告诉我您指的是哪个产品。」

实验 B（带 context）：

> Prompt：「以下是某 SaaS 产品的 PRD 文档：[此处粘贴 5000 字文档]。这个产品的核心功能是什么？」

AI 会基于文档给出具体回答。

实验 C（带错误 context）：

> Prompt：「以下是某 SaaS 产品的 PRD 文档：[此处粘贴 5000 字完全不相关的天气预报]。这个产品的核心功能是什么？」

AI 会基于那段天气预报，给你一个啼笑皆非的回答。

三个 prompt 的句式几乎一样，唯一区别是「喂给 AI 什么」。这就是 Context Engineering 的全部秘密：AI 的输出质量，几乎完全由它的输入决定。 你不是在与 AI 对话，你是在为 AI 编排它的世界。

---

1.3 Prompt Engineering vs Context Engineering：两门手艺的边界

既然「喂什么」这么重要，那为什么过去两年大家都在喊 Prompt Engineering？这两个概念到底是什么关系？

1.3.1 历史的快速回顾

2022 年末 ChatGPT 发布后，「Prompt Engineering」这个词突然爆火。当时大家的共识是：「写好 prompt 就能让 AI 听话。」 涌现出了一批「Prompt 神教」的布道者，传授「魔法咒语」、「思维链（Chain of Thought）」、「角色扮演（Role Prompting）」等技巧。那是一个 prompt 至上的时代。

但 2024 年开始，事情起了变化。两个关键事件改变了整个行业的思维框架：

事件一：长上下文模型普及。 GPT-4 Turbo、Claude 3、Gemini 1.5 把上下文窗口推到了 10 万到 100 万 token。这意味着你不再需要「巧妙地把信息塞进 prompt」，你可以直接把整个文档库塞进去。「如何选择该放什么进去」开始成为一个独立问题。

事件二：Agent（智能体）浪潮。 AutoGPT、LangChain、Manus、各种 Coding Agent 的出现，让 AI 走出了「一问一答」的简单模式。AI 开始主动调用工具、规划多步任务、循环迭代。在 Agent 场景里，「这一轮要给模型喂什么」是 Agent 设计者必须实时决策的核心问题。一个设计糟糕的 Agent，会把整个工具调用历史、原文档、所有失败尝试都堆进 context，导致 prompt 写得再好也无济于事。

这两个事件叠加在一起，催生了一个新的概念：Context Engineering。这个词最早在 2024 年初由几位独立研究者提出，到 2024 年中已被 Anthropic、LangChain 等头部公司在官方文档中频繁使用。

1.3.2 精确的区分：它们是「表」与「里」

用一个比喻：

• **Prompt Engineering** 是「如何问问题」。它优化的是「你说的那句话」本身。
• **Context Engineering** 是「如何布置桌面」。它优化的是「AI 这一次能看见的全部东西」。

如果 AI 是一个要参加考试的学生：

• Prompt Engineering 关心的是「你能不能问对问题」（比如「请用三段式回答」、「请举例说明」）。
• Context Engineering 关心的是「他桌上摆了什么」（教科书、草稿、笔记、公式表是不是齐备）。

这两件事互斥吗？ 不互斥。它们是互补的。但它们的故障域（failure domain） 不同：

| 故障类型 | Prompt Engineering 解决？ | Context Engineering 解决？ | |---|---|---| | 回答格式不对（要 Markdown 但给了纯文本） | ✅ 是 | ❌ 否 | | 回答风格不对（要正式但很随意） | ✅ 是 | ❌ 否 | | 回答逻辑不对（推理有漏洞） | ⚠️ 部分 | ✅ 是（喂思维链） | | 回答内容缺失（忘了文档某段） | ❌ 否 | ✅ 是 | | 回答牛头不对马嘴（理解错需求） | ⚠️ 部分 | ✅ 是（喂澄清文档） | | 答非所问（理解了 prompt 但 context 错） | ❌ 否 | ✅ 是 | | 多轮后突然失忆 | ❌ 否 | ✅ 是（管理历史） | | 长文档关键信息没被注意到 | ❌ 否 | ✅ 是（检索 + 提示） |

看这张表，你会发现：当 AI 出错时，绝大多数问题出在 context 而不是 prompt。 这一点和普通用户的直觉恰好相反。普通用户的直觉是「AI 答错了，一定是我的 prompt 写得不够好」。但事实是，很多时候 prompt 写得完美，context 一塌糊涂，回答必然是一塌糊涂。

1.3.3 一个反直觉的判断标准

有一个非常实用的判断标准，能帮你快速决定现在的问题该往哪个方向查：

> 如果你的 prompt 在简单、少 context 的场景下能正常工作，但在多轮、长文档、多工具的场景下失灵——99% 是 Context Engineering 问题。

李薇的故事就是这个模式的教科书。她的 prompt 在第 1 轮表现完美（少 context 场景），到第 27 轮完全失灵（多轮、长 context 场景）。她反复改 prompt 没用，因为病根不在 prompt。

1.3.4 为什么这门手艺之前不叫 Context Engineering？

一个合理的疑问是：既然「喂什么」这么重要，为什么过去没人叫它 Context Engineering？

答案是：过去模型太弱，「喂什么」没什么可设计的。

2020-2023 年，主流模型的上下文窗口只有 4K-8K token。这意味着你根本塞不下什么东西。能塞的只有 prompt 一句话。在这种约束下，「如何写好一句话」几乎就是全部问题。Prompt Engineering 自然成为显学。

但当上下文窗口放大 100 倍，工具调用成为常态，Agent 多步推理成为现实——「如何往里面放什么、按什么顺序放、什么时候更新它」突然成了一个独立的、有深度的问题。这门手艺从 prompt engineering 的枝叶，长成了一棵独立的大树。

2024 年，是 Context Engineering 作为独立学科诞生的一年。 这本书记录的，就是这门学科在它婴儿期的方法论。

---

1.4 上下文工程五层模型：一张地图

好了，到这里你已经有了两个核心认知：

1. AI 的输出质量由它的输入（context）决定。 2. Context 是一张桌子，由系统指令、用户输入、历史对话、检索内容、工具结果五样东西拼成。

但「桌子怎么摆」具体怎么操作？我们需要一个工程化、可复用的框架。这就是我们要介绍的上下文工程五层模型（5-Layer Context Engineering Model）。

1.4.1 模型总览

```mermaid flowchart TD A[User Query<br/>用户原始问题] --> B[Layer 1: Raw Data<br/>原始数据层] B --> C[Layer 2: Retrieval<br/>检索层] C --> D[Layer 3: Compression<br/>压缩层] D --> E[Layer 4: Injection<br/>注入层] E --> F[Layer 5: Model<br/>模型层] F --> G[Final Output<br/>最终输出] H[External Knowledge Base<br/>外部知识库] --> C I[Tool APIs<br/>外部工具] --> E J[Long-term Memory<br/>长期记忆] --> E ```

这张图描绘了从用户提问到模型给出答案的完整流水线。每一层都有自己的职责、自己的算法、自己的失败模式。Context Engineering 的全部工作，就是把这五层做好。

让我们一层一层拆解。

1.4.2 第一层：原始数据层（Raw Data Layer）

这是最底层，也是整个流水线的「原料仓库」。它包含：

• 企业的知识库文档（PDF、Word、Notion、Confluence）
• 产品数据库（用户信息、订单数据、日志）
• 历史对话记录
• 第三方 API 返回的实时数据
• 用户上传的临时文件

这一层的关键设计问题是：如何组织这些数据，使它能被高效检索和访问？

需要做的工程包括：

• 文档预处理（清洗、分段、向量化）
• 数据库 schema 设计
• 元数据管理（哪些文档是权威源？哪些已过期？）
• 权限和隐私控制

李薇的故事里，她的「原始数据层」是一份 60 页的 PRD 文档。这个原料本身没问题，但她没有在源头做任何处理，导致后续每一层都在裸奔。

1.4.3 第二层：检索层（Retrieval Layer）

当用户提问时，模型不能「看见」所有原始数据（太多了）。它只能看见「与这个问题最相关的一小部分」。负责挑出这一小部分的，就是检索层。

检索层最常见的技术是 RAG（Retrieval-Augmented Generation，检索增强生成）。RAG 的基本流程是：

1. 把用户的问题转换成一个向量（embedding）。 2. 在向量数据库里找最相似的 K 个文档片段。 3. 把这 K 个片段送入下一层。

但检索远不止「向量相似度」这么简单。2024-2025 年业界已经发展出一系列高级检索策略：

• **混合检索（Hybrid Search）**：同时使用向量检索和关键词检索（如 BM25），取并集。
• **重排序（Re-ranking）**：用更强的模型对初筛结果再排一遍。
• **HyDE（Hypothetical Document Embeddings）**：让模型先「假想」一段答案，再拿这个假答案去检索。
• **多跳检索（Multi-hop Retrieval）**：根据初步检索结果，再发起第二轮检索，解决需要串联多个文档的问题。
• **查询改写（Query Rewriting）**：对用户的模糊问题先做改写、扩展，再检索。

李薇的故事里，「检索层」基本是缺失的——她没有做 RAG，她把所有内容都直接塞进 context。这是一个典型的「绕过检索层」的反模式。

1.4.4 第三层：压缩层（Compression Layer）

检索回来的内容往往还是太多。这一层的工作是把信息压缩到一个更小的体积，同时保留关键信息。

压缩有两种思路：

思路一：摘要压缩（Summarization Compression） 把长文档压缩成短摘要。比如把 10 轮历史对话压缩成 2 行摘要：「用户希望总结某 PRD 的核心功能、验收标准、优先级排序。已完成核心功能提取。」

思路二：抽取压缩（Extraction Compression） 只保留关键实体和关系。比如从一篇产品文档里抽出「功能 A → 依赖技术 X → 优先级 P1」这样的事实三元组，丢掉所有修饰语。

思路三：模型自动压缩（LLM-based Compression） 让模型自己判断哪些信息重要、哪些可以丢掉。这是一种「软压缩」，效果通常比硬规则好，但成本也更高。

**思路四：toke