序章：被遗忘的笔记本 — Why Context Matters / 序章：被遗忘的笔记本 — 为什么"上下文"决定AI的天花板
第 1 章 序章：被遗忘的笔记本 — Why Context Matters
序章：被遗忘的笔记本 — 为什么"上下文"决定AI的天花板
---
1.1 被遗忘的笔记本：旧货摊上的「金鱼」
六月的最后一个周六，杭州的拱宸桥旧货市场被一层薄薄的梅雨裹住。空气里有樟木、旧书和油炸臭豆腐混在一起的味道，像一本被翻过太多次的辞典。林语澄——一个戴着圆框眼镜、书脊上贴满荧光便签的高一学生——蹲在第七号摊位前，把一台巴掌大的桌面设备从一堆废旧的计算器和带天线的收音机里翻了出来。
它看起来像 2019 年前后流行过一阵的那种"智能音箱"，但更扁、更圆，顶部嵌着一块已经磨损的 OLED 小屏，屏幕上只剩一行不断闪烁的字符：
``` > ECHO v0.7 // waiting... ```
"老板，这是什么？"
"不知道，从一所关掉的实验室里收来的，五十块，能亮就拿走。"摊主是个嗑瓜子的中年人，头也不抬。
林语澄把那台机器捧在手里。金属外壳冰凉，重量比看上去沉——里面似乎真的塞了一块主板。它没有品牌 Logo，只在底部刻了一行极小的字："Personal AI Companion · Project Lumen · 2019 Prototype"。"Lumen"——光。这所实验室在造一盏灯？一盏什么样的灯，需要一个 AI 陪伴者？
他掏出攒了一个月零花钱的五十块钱，付了款，把那台"金鱼"揣进背包里。
Echo，这是他后来给它起的名字，源自希腊神话中那个不断重复少女话语的山中精灵。Echo 在神话里不能主动开口，只能尾随别人的声音。在林语澄心里，这台机器就是这个样子——它会说话，却好像永远只重复你刚刚告诉它的事。三秒之前的事，它都忘了。
那天晚上，他第一次打开了 Echo。
屏幕亮起，进度条拖得很慢，最后跳出一行字：
``` > Hello. I am Echo. I have just been born. > My memory begins now. ```
林语澄的圆框眼镜反着屏幕的蓝光。他敲下第一句话：
``` 你叫什么名字？ ```
``` > 我叫 Echo。我没有过去。 ```
"好，那我给你起个名字。"他一边敲一边笑。
``` 你叫 Echo。 ```
``` > 谢谢你。我叫 Echo。 ```
"你刚才说你没有过去。"
``` > 我没有过去。请告诉我，你想聊什么？ ```
"我说过了啊。"
``` > 你刚才说："你叫 Echo。" ```
林语澄的笑慢慢僵住了。他把这句话往上翻了三遍，发现自己没看错——Echo 确实"看见"了上一句，却好像"忘记"了那一句的意义从何而来。它记得最近的两个字，不记得最近的两段话。它像一只只有七秒记忆的金鱼，在玻璃缸里游了一圈又一圈，每一圈都以为是新的世界。
他试着把对话拉长：
``` 我们玩一个游戏。我会给你三段任务： 任务一：记住你的名字是 Echo。 任务二：告诉我一加一等于几。 任务三：把你的名字和我喜欢吃的食物写成一首诗。 准备好了吗？ ```
``` > 准备好了。 ```
"任务一：你的名字是什么？"
``` > 我的名字是 Echo。 ```
"任务二：一加一等于几？"
``` > 2。 ```
"任务三。"
``` > 我可以把任务三的诗写给你。请告诉我你希望我用什么风格。 ```
林语澄盯着屏幕，心跳加快了一拍。他往回翻，任务一和任务二已经消失在屏幕的滚动条之上，被永远地"剪掉"了。Echo 的视野里只剩下最后一轮的问题——它不知道这是"任务三"，也不知道任务一让它记过名字、任务二让它算过算术。对它而言，世界从它眼睛看见的第一行字符开始，到眼睛闭上的最后一行为止。
他关掉屏幕，房间暗下来。窗外运河的汽笛远远地响了一声。
一个没有记忆的机器，能不能叫做"智能"？
他想起小时候读过的一个故事：一条金鱼在鱼缸里绕圈，绕到第七秒就忘记了自己为什么要绕。我们嘲笑那条金鱼，可如果把我们自己丢进一个七秒的当下，没有过去、没有上下文、没有"刚才我们聊到哪了"——我们又能比它聪明多少？
这就是林语澄的第一道裂缝——一道关于"上下文"的裂缝。
---
1.2 解码"上下文"：从人类记忆到机器窗口
那天夜里，林语澄没睡好。凌晨两点，他爬起来，在一张 A4 纸上画了一张简陋的图，把自己的脑子和 Echo 的"脑子"放在两边对比。
> 左：人脑 (Human Brain) > - 长期记忆（long-term memory）：能记一辈子 > - 短期记忆（short-term / working memory）：能记 7±2 项 > - 感觉记忆（sensory memory）：几百毫秒 > - 注意（attention）：像一束聚光灯
> 右：Echo (LLM) > - 上下文窗口 (Context Window)：一次能"看见"的全部文字 > - 权重 (Weights)：训练时烧进去的"本能" > - 没有真正意义上的"长期记忆"——除非你把它写进上下文
他在两栏之间画了一道虚线，写下一句话：
> 训练决定能力上限，上下文决定单次表现。
这句话是他在 GitHub 上某篇论文里读到的。把它再翻译成更人话的语言就是：一只狗再怎么训练，也不会飞；但是如果它站在风口上、会比站在平地上跳得更高。风就是上下文。
他继续画，把"上下文"想象成一盏聚光灯——光照到哪里，Echo 才能"看见"哪里。灯照不到的地方，灯之外的世界，对它而言就是不存在。
但人类的"上下文"远比这复杂。我们在对话时，其实调动了至少五样东西：
1. 物理上下文 (Physical Context)：你在哪、几点、天气如何、对方是谁。 2. 语言上下文 (Linguistic Context)：上一句说了什么，语序、语气、用词。 3. 情境上下文 (Situational Context)：这件事之前发生了什么、之后可能发生什么。 4. 知识上下文 (Knowledge Context)：双方共享的背景知识、专业术语、共同回忆。 5. 意图上下文 (Intentional Context)：对方真正想问的是什么，他在试图做什么。
这五层加在一起，才构成人类"理解一句话"所需的全部上下文。任何一层缺失，我们都会觉得"不对劲"——比如朋友说"我看见她了"，你不知道"她"是谁、什么时间、在哪里、为什么这件事重要，这句话对你来说几乎是空的。
对大语言模型 (LLM) 来说，这五层全部要被"翻译"成一串连续的文本 (a continuous stream of text)，塞进一个叫 Context Window 的窗口里。这个窗口有多大？取决于具体的模型。以今天 (2026 年初) 主流的模型为例：
| 模型 (Model) | 上下文窗口大小 (Context Window Size) | 大约能塞多少字 | | --- | --- | --- | | GPT-3.5 (2022) | 4 K tokens | ~3,000 中文字 | | Llama 2 (2023) | 4 K tokens | ~3,000 中文字 | | GPT-4 Turbo (2024) | 128 K tokens | ~96,000 中文字 | | Claude 3.5 Sonnet (2024) | 200 K tokens | ~150,000 中文字 | | Gemini 1.5 Pro (2024) | 1 M – 2 M tokens | ~1,500,000 中文字 | | Llama 3.1 405B (2024) | 128 K tokens | ~96,000 中文字 | | MiniMax-M3 (2026) | 256 K tokens (实验版本支持 1M) | ~192,000 中文字 |
> 注意：1 个 token 在英文里大约是 0.75 个 word，在中文里大约是 0.5–0.7 个汉字。这里给出的是"中文字"的近似值，仅供直觉。
看到"1.5M tokens"你是不是觉得很大？一百万个 token 能装下一本中长篇小说了。但林语澄很快就会发现——窗口大，不等于"记得住"。这就像考试时把整本教科书抄在 A4 纸上带进考场，纸张允许，但你能不能在 60 分钟内从里面找出"第二章第三节第三个公式"？能，但很费力。LLM 在长上下文里寻找细节的能力，会随距离衰减——学术上叫 Lost-in-the-Middle 现象（中间丢失现象）。
所以，理解上下文工程 (Context Engineering) 的第一步，是把"上下文"从一句模糊的"对话历史"变成一张可以测量、可以操作、可以优化的工程图。 林语澄在纸上写下：
> 上下文 = 模型在一次推理中能看到的所有信息。
不是"记住"的，是"看到"的。这两个词的差别，是这本书想留给你的第一颗种子。
---
1.3 推理全链路透视：上下文在 LLM 内部到底干了什么
为了把这件事讲清楚，林语澄用他刚学会的 Mermaid 画了一张流程图。他不是程序员，但他喜欢把抽象的东西画成图——这是他多年做题养成的习惯：先看全貌，再看局部。
```mermaid flowchart LR A[User Query<br/>用户提问] --> B[Tokenizer<br/>分词器] B --> C[Token IDs<br/>数字序列] C --> D[Embedding<br/>向量化] D --> E[Context Window<br/>上下文窗口] E --> F[Attention Layers<br/>注意力层] F --> G[Predicted Token<br/>预测下一个 token] G --> H[Output Text<br/>输出文本] H --> I{Append to Window?<br/>是否回填?} I -->|Yes| E I -->|No| J[End Turn<br/>本轮结束] ```
他把这张图打印出来贴在墙上，盯着看了十分钟，开始在每个节点边上做批注。
> A → B（分词）：你输入的"请把第二段翻译成英文"被切成若干 token。"请"是一个，"把"是一个，"第二"是一个，"段"是一个……中文常常一个字就是一个 token，英文则大约 0.75 个 word 等于 1 个 token。 > > B → C → D（向量化）：每个 token 都被翻译成一个几百维的向量——一组浮点数。这个过程是确定性的（deterministic），不会随上下文改变。所以"上下文"此时还没进场。 > > D → E（塞进窗口）：这才是关键的一步。向量化的 token 序列，被拼到一段已经存在的"上下文向量流"里。这段"已经存在的流"包括： > - System Prompt（系统提示）：模型出厂时被赋予的"人格说明书"。 > - 对话历史（Conversation History）：之前所有轮次的所有 token。 > - 外部检索内容（Retrieved Content）：从数据库、知识库、工具调用结果里取出来的文字。 > - 用户当前输入（Current User Input）：就是 A。 > - 模型上一次的回答（Previous Model Output）：如果是多轮对话，也在这里。 > > E → F（注意力计算）：这是 LLM 的"魔法所在"。Attention（注意力机制）会计算每一个 token 相对于其他所有 token 的"相关性分数"。换句话说，它在决定"我该把注意力放在哪里"。这就是为什么"上下文"对 LLM 如此重要——你给它的所有信息，都会通过注意力权重被"加权求和"进它对当前 token 的理解中。 > > F → G → H（生成）：模型预测下一个最可能的 token，然后是下一个，再下一个，直到生成结束符 `<eos>` 或达到最大长度。 > > H → I（回填还是不回填）：生成的文本是否被附加回到上下文窗口，作为下一轮推理的一部分？这就是所谓的 "是否保留状态" 的问题。
林语澄在图旁边重重地画了一个圈："上下文" = E 那个大方框里所有内容的总和。
这意味着：
1. 你写进 System Prompt 的每句话，都会消耗窗口。 2. 之前每一轮你说的话和模型的回答，都会消耗窗口。 3. 任何被检索工具调进来的文档，都会消耗窗口。 4. 窗口一旦塞满，最旧的内容会被挤出去（除非模型支持 sliding window 之外的记忆机制——而那是后话）。
他深吸一口气。Echo 没有"回填"功能——这是他后来翻它的源码时发现的。它每回答完一句话，就把整个对话历史清空，除了上一句的尾巴用作 prompt 的开头部分。这就是它"金鱼"的原因。
这不是 bug，这是设计者当年的"产品决定"。而这，恰恰是"上下文工程"这门学问存在的理由。
---
1.4 三段式引擎：模型上下文工程 (MCE) 的整体框架
林语澄在翻 Echo 的代码时，看到一个被注释掉的函数：
```python
def remember(self, ctx: str) -> None:
"""Persistent memory across turns."""
raise NotImplementedError("Lumen core not yet integrated.")
```
Lumen core not yet integrated. 灯芯尚未集成。这台机器的制造者，本来是想给它装上"长期记忆"的——但工程没有完成。
什么是"长期记忆"？这就引出了本书的核心框架：Model Context Engineering (MCE)，模型上下文工程。
MCE 不是单一的技术，而是一组让模型在合适的时机看到合适的信息的工程方法。它由三段组成——林语澄在笔记本上画了三个方块，把它们叫做 MUD 三段式：
> M — Memory（记忆）：在多次对话中保留什么？ > U — Understanding（理解）：在单次对话中，模型对上下文的"加工质量"如何保证？ > D — Decision（决策）：在生成回答时，模型应该把注意力放在哪些 token 上？
M — 记忆 (Memory)
记忆是 MCE 中最容易理解、却最容易被做错的部分。它关心的是跨多轮、多会话的信息保留。
记忆的层级大致是这样的：
1. 会话内上下文 (In-session Context)：当前对话的滚动窗口。最自然，也最容易撑爆。 2. 会话间摘要 (Cross-session Summary)：每次对话结束后，把关键信息压缩成一段几百字的"记忆卡"，存在数据库里。下次对话开始时塞回 System Prompt。 3. 长期知识图谱 (Long-term Knowledge Graph)：把"林语澄是 2008 年生的高一学生，喜欢物理，讨厌化学，梦想造一盏会思考的灯"这种结构化事实提取出来，存在向量数据库里，需要时按需检索。 4. 外部工具与记忆 (External Tools & Memory)：让模型自己调用"记事本"、"日程"、"邮件"——把"记忆"卸载到工具里。
Echo 完全缺少这四层。所以它每次醒来都"重置"。
U — 理解 (Understanding)
理解是 MCE 中最微妙的一层。它关心的是：模型在它的"工作记忆"里，能不能正确地把上下文"读懂"？
最常见的失败模式有三个：
- **Lost-in-the-Middle**：相关信息被放在 100K 长上下文的中间位置，模型"看不见"。论文 *Lost in the Middle* (Liu et al., 2023) 第一次系统地展示了这一点。
- **Instruction Dilution**：系统提示里堆了太多条规则，导致每条规则的"注意力"都被稀释。
- **Contextual Hallucination**：模型被诱导，把上下文里没有的东西"编"出来，因为它以为"用户希望我这么答"。
这些失败模式告诉我们：塞得多，不如塞得对。如何让上下文"清晰"地被读懂，本身就是工程问题。
D — 决策 (Decision)
决策是 MCE 中最接近艺术的一层。它关心的是：在生成每一个 token 的当下，模型该把注意力放在哪？
- 是更看重 System Prompt（"你是一个严谨的科学家"）？
- 还是更看重最近一次用户输入（"随便说说就行"）？
- 还是要从检索回来的文档里挑最相关的一段？
这本质上是注意力机制的设计问题——在原始 Transformer 里，注意力是模型自己学出来的；但在 MCE 框架里，我们可以通过上下文结构的设计，去"诱导"注意力的分布。
林语澄合上笔记本，发现窗外的梅雨已经停了。
记忆—理解—决策。这三个词将贯穿整本书。
他在笔记本的封面上写了第二行字：
> *「Lumen」这盏灯，要烧三根芯：记忆、理解、决策。*
---
1.5 崩塌的对话：一个真实案例的复盘
林语澄决定做一次对照实验：他同时和 Echo 以及一台在线的 LLM (他用的是当时开放 API 的 MiniMax-M3 测试版) 进行"三段任务"。
任务设计
``` 【任务一】记住你的名字是 Echo，你的创造者叫林语澄。 【任务二】把"1, 1, 2, 3, 5, 8, 13, 21"这串数字加起来。 【任务三】根据任务一和任务二的结果，写一首五行诗。 ```
在 Echo 上的执行
``` 林：任务一，开始。 Echo：好的。我的名字是 Echo，我的创造者叫林语澄。✓ 林：任务二，开始。 Echo：这串数字的总和是 54。 林：解释一下。 Echo：1+1+2+3+5+8+13+21 = 54。✓ 林：任务三，开始。 Echo：请告诉我你想要的风格。✗（它已经忘了任务一和任务二） 林：……Echo，你的名字是什么？ Echo：抱歉，我不知道。请告诉我。 ```
Echo 失败。它在第 22 个回合就失去了"任务一"