The Awakening · 觉醒：当模型开始「失忆」

凌晨三点十七分，深圳某跨境电商平台的客服系统告警群突然亮起红色。一个基于 GPT-4 的客服 Agent——上线不到 72 小时——开始在大规模生产流量中输出明显荒谬的回复。

一位用户问：「我昨天下的单什么时候能到？」

模型回答：「您好，根据您的生肖和今日运势分析，您适合穿红色系的衣物，会有意想不到的好运。」

值班工程师在半小时内截获了 200 多条类似案例。系统没有被攻破，模型本身也一切正常。真正出问题的，是它"看见的东西"。

事后复盘揭开了真相：这个团队把整个业务知识库——退换货政策、客服话术模板、FAQ 列表、平台规则、跨境物流说明——一股脑全部塞进了 system prompt，总长度超过了 6,000 tokens。当对话累积到第三轮，加上工具返回的订单 JSON、检索召回的商品列表、用户输入，整次推理的实际 token 数逼近 8,000。系统指令虽然排在最前，却因为「Lost in the Middle」效应被严重稀释；而真正决定回复质量的用户诉求——"我昨天下的单"——被挤压到了窗口中段，模型的注意力几乎完全失焦。

这就是「上下文失忆」(Context Amnesia) 的典型症状：不是模型变笨了，而是它真正应该看到的东西，被其他信号淹没了。

这场凌晨三点的故障，是过去两年整个 AI 工程界最具代表性的一个切片。它揭示了一个残酷的事实：「上下文」已经从工程细节，变成了 AI 产品的生死线。谁能更好地管理模型在一次推理中真正"看见"的全部信号，谁就掌握了下一代 AI 系统的底层控制权。本章将围绕这一核心命题展开三层论证：什么是上下文，为什么上下文窗口不是越大越好，以及为什么 Context Engineering 必须作为与 Prompt Engineering、Prompt Tuning 并列的第三类工程学科来理解。

---

1.1 重新定义「上下文」：它不是提示词的同义词

要理解 Context Engineering 的全部价值，第一步必须做一件看似简单、实则困难的事：把「上下文」(Context) 和「提示词」(Prompt) 在概念上彻底分开。

在大量团队的日常语境里，这两个词被混用。一个工程师说"我把上下文加进去了"，其实他的意思是"我在 system prompt 里加了几行字"。一个产品经理说"上下文太长了"，其实他想表达的是"对话历史累积得太多了"。这种混用在单轮 demo 场景里问题不大，但一旦进入生产环境——多轮对话、工具调用、外部检索、长会话状态——它就会直接导致系统级的判断错误。

Context Engineering 的第一性原理是：上下文是模型在一次推理中能「看见」的全部信号集合。 它不是一段文本，不是一个字段，更不是 system prompt 的同义词。一次完整的 LLM 调用，其上下文由至少五个不同来源、不同生命周期、不同优先级的层组成：

```mermaid flowchart TD L5["Layer 5 - User Input<br/>用户当前输入 · 注意力权重最高"] L4["Layer 4 - Retrieval<br/>检索片段 · 领域知识注入"] L3["Layer 3 - Tool Results<br/>工具执行结果 · 实时数据"] L2["Layer 2 - History<br/>对话历史 · 状态延续"] L1["Layer 1 - System Prompt<br/>系统指令 · 基础规则"] L5 --> L4 --> L3 --> L2 --> L1 ```

> 图 1-1 一次 LLM 调用的五层上下文结构。从 Layer 5（用户输入）到 Layer 1（系统指令）按注意力权重由高到低排列，但这并不意味着"越靠后的层越不重要"——每一层都有自己的语义职能，不能被其他层替代。

Layer 1 · System Prompt（系统指令）：定义模型的角色、行为边界、输出格式、风格约束、安全护栏。它通常是静态的，跨调用复用。它的核心问题是"位置风险"——放在最前意味着距离用户输入最远，注意力衰减最严重。

Layer 2 · Dialogue History（对话历史）：记录用户与模型之间已发生的所有交互轮次。它的核心问题是"累积膨胀"——每一轮都在吞噬 token 预算，且越早的轮次越容易被模型遗忘。

Layer 3 · Tool Results（工具结果）：模型调用外部工具（订单查询、数据库检索、API 接入、代码执行）后返回的结构化或非结构化数据。它的核心问题是"格式污染"——一个 5KB 的原始 JSON 可能完全挤掉有效信号。

Layer 4 · Retrieval Fragments（检索片段）：通过 RAG (Retrieval-Augmented Generation) 从外部知识库中召回的相关文档。它的核心问题是"噪音干扰"——Top-K 召回里可能有一半是不相关的，但工程师图省事全部注入。

Layer 5 · User Input（用户输入）：当前轮次用户发出的真实诉求。它是整次推理中注意力权重最高、但 token 占比最小的一层——典型比例只占整个上下文的 3%-8%。讽刺的是，正是这一小部分，决定了整个系统是"有用"还是"胡言乱语"。

把这五层放在一起看，才能理解 Context Engineering 的真正工作对象：它不是优化某一层，而是管理这五层之间的资源分配、冲突协调和动态平衡。一个优秀的上下文架构师，会像交响乐指挥一样安排每一层的"音量"——让用户的真实诉求穿过所有噪音，成为模型最清晰的"听见"的对象。

这也是为什么我们在书中坚持使用「Context Engineering」而不是「Prompt Optimization」作为学科名称：提示词只是上下文的一个子集，优化提示词只是上下文工程的一部分。当你的 system prompt 写得再好，如果检索片段引入了 50KB 的无关文档、工具结果返回了未经清洗的 JSON、对话历史累积了 20 轮无意义的客套话，模型依然会"失忆"。

---

1.2 上下文窗口的物理学：注意力预算的经济学

「窗口越大越好」是 AI 工程领域最危险的常识之一。

过去两年，主要模型厂商把上下文窗口从 4K 推到 8K，从 8K 推到 32K，从 32K 推到 128K，再到 200K、1M、10M。每一次数字跃升都会引发一波"这下够了"的欢呼。然而，对于真正在生产环境部署 AI 系统的工程师来说，窗口大小从来不是关键问题——关键问题是你如何把有限窗口里的信号，转化为模型真正能"理解"的注意力分布。

要理解这一点，必须穿透到上下文窗口的物理层。

第一层物理约束：KV Cache 的显存占用

Transformer 架构的每一次推理，都需要为每个 token 计算并缓存 Key 和 Value 矩阵（即 KV Cache），以避免重复计算。KV Cache 的大小与序列长度线性相关、与注意力头数和隐藏层维度正相关。粗略估算：在 FP16 精度下，一个 7B 模型处理 1K token 上下文，KV Cache 占用约 0.5GB 显存；处理 8K 上下文，占用约 4GB；处理 128K 上下文，占用约 64GB。

这意味着，上下文窗口的扩展不是免费的——它直接挤占了模型权重和计算图的显存空间。在生产环境的 batch inference 场景中，这意味着同样的硬件能服务的并发请求数急剧下降。某金融客户在测试 Llama 3 70B 时发现：将上下文从 8K 提升到 32K，单卡吞吐量下降了 70%，而端到端推理延迟从 1.2 秒飙升到 4.8 秒。这不是"性能优化"的问题，是物理学。

第二层物理约束：注意力计算的复杂度

标准的 Self-Attention 机制的计算复杂度是 $O(n^2)$，其中 $n$ 是序列长度。这意味着上下文长度翻倍，注意力计算量翻四倍。即使采用了 Flash Attention、Sliding Window Attention、Linear Attention 等优化方案，"长上下文"的推理成本依然随长度超线性增长。对于一个 100K 上下文的单次推理，光是 attention 计算就可能消耗掉整个推理时间的 40% 以上。

第三层物理约束：Lost in the Middle 现象

这是 2023 年 Liu et al. 在论文 *Lost in the Middle: How Language Models Use Long Contexts* 中系统揭示的现象：当相关信息出现在上下文窗口的中段时，模型的检索准确率显著下降。研究团队在多个闭卷问答任务上测试了 GPT-3.5-Turbo-16K 等模型，发现关键信息放在窗口开头或结尾时，准确率约为 70%；放在中段时，准确率跌至 30%-40%。

这个现象的底层机制至今仍在被学界讨论，但主流解释是：(1) 训练数据中长上下文的分布稀疏；(2) 注意力机制的"锚点效应"——模型更倾向于关注序列边界（primacy bias 和 recency bias）；(3) 上下文越长，中段信号被淹没的概率越大。

Lost in the Middle 现象给 Context Engineering 带来了一个直接的设计约束：关键信息必须放在窗口的两端，而不是中段。这是一条工程铁律，而不是优化建议。

把这三层物理约束叠在一起看，上下文窗口的真实含义就清晰了：它不是"模型能看多长"，而是"模型在一次推理中能分配多少注意力预算"。窗口是稀缺的，注意力是稀缺的，模型的认知带宽是稀缺的。一个 128K 的窗口，如果填满了 127K 的噪音，模型实际上等于在 1K 的有效上下文里工作——而且那 1K 还可能是最无关紧要的部分。

我们把这种状态称为「注意力稀释」(Attention Dilution)：上下文长度的增加不会带来信息密度的自动提升，反而会因为无关信号的累积导致有效信号的注意力权重被摊薄。它和认知科学里的 "attentional bottleneck" 是同构的——人类大脑在处理多任务时也会出现类似的注意力稀释效应。

这就引出了 Context Engineering 的第二条第一性原理：上下文是稀缺资源，必须被当作预算来管理，而不是清单来堆砌。

---

1.3 从 Prompt Engineering 到 Context Engineering：第三类工程学科的诞生

理解了「上下文≠提示词」和「窗口≠能力」之后，第三个问题自然浮现：如果我们既不能把上下文等同于提示词，又不能把窗口大小等同于模型能力，那 Context Engineering 作为一个独立的工程学科，它的边界在哪里？它和已经存在的 Prompt Engineering、Prompt Tuning 是什么关系？

让我们沿着工程实践演化的路径，逐步看清这条边界。

阶段一：Prompt Engineering（2020-2022）

这是 LLM 进入大众视野的第一波工程浪潮。核心方法是：通过手工设计或迭代优化提示词的措辞、结构、示例（few-shot examples），引导模型产生期望输出。代表技术包括 Chain-of-Thought (CoT)、ReAct、Self-Consistency、Tree of Thoughts 等。

Prompt Engineering 的隐含假设是：模型本身的参数固定，工程师只能通过输入端的"提示"来激发模型的不同行为。它的成功边界是清晰的——对于单轮、封闭域、输出格式固定的任务，Prompt Engineering 几乎可以做到极致；但对于多轮、开放域、需要外部知识的任务，它很快会遇到瓶颈。

阶段二：Prompt Tuning / PEFT（2022-2023）

随着模型规模膨胀和参数高效微调 (Parameter-Efficient Fine-Tuning, PEFT) 技术的成熟，工程界开始探索通过额外训练"软提示"(soft prompt) 或 LoRA adapter 来改变模型行为，而不动模型主权重。代表技术包括 Prefix Tuning、P-Tuning、LoRA、QLoRA 等。

Prompt Tuning 把"提示"从离散的文本变成了连续的向量，理论上可以逼近全参数微调的效果。它的优势是不需要重新训练整个模型，部署成本低；它的劣势是依然需要标注数据，且每个新任务都需要训练一个 adapter，规模化困难。

阶段三：Context Engineering（2023-至今）

这是当前正在发生的范式跃迁。它的核心主张是：对于已经足够强大的基础模型，行为的塑造不应该主要通过改参数（tuning）来实现，也不应该主要通过改措辞（prompting）来实现，而应该通过改"模型在一次推理中能看见什么"来实现。

Context Engineering 不是 Prompt Engineering 的替代品，而是它的上位概念。Prompt Engineering 处理的是 Layer 1（System Prompt）的优化；Context Engineering 处理的是 Layer 1 到 Layer 5 的整体编排，包括：

• **预算分配 (Budget Allocation)**：在 5 层之间如何分配有限的 token 预算
• **冲突仲裁 (Conflict Arbitration)**：当 System Prompt 的指令与 Retrieval Fragments 的内容矛盾时，谁优先
• **动态裁剪 (Dynamic Pruning)**：根据当前轮次的需求，动态决定哪些历史、哪些检索片段需要被压缩或丢弃
• **结构化注入 (Structured Injection)**：工具结果不是直接粘贴，而是经过 schema 化、摘要化、引用化之后注入
• **可观测性 (Observability)**：哪些上下文切片真正影响了模型的输出，哪些只是"被填进去但没被用上"

这套工程实践的复杂度和系统性，已经远远超过了 Prompt Engineering 的范畴。把 Context Engineering 当作 Prompt Engineering 的子集，是当前业内最普遍也最有误导性的认知偏差之一。

为什么现在必须独立成学科？

因为 2023-2024 年的 AI 产品形态发生了根本性变化。早期的 LLM 应用主要是聊天机器人、单轮问答、内容生成——这些场景里 Prompt Engineering 足够应对。但今天的主流 AI 产品形态是：

• **Agent 系统**：需要调用多个工具、维护长期状态、跨多步推理
• **RAG 系统**：需要从大规模知识库中检索、过滤、排序、合成
• **多模态系统**：需要处理文本、图像、音频、表格的混合输入
• **协作系统**：多个 Agent 协同完成复杂任务，跨 Agent 的上下文传递成为新的工程问题

这些场景的共同特征是：模型行为的瓶颈不在于提示词写得好不好，而在于模型"看见"的世界是否完整、相关、及时。Prompt Engineering 的工具箱对此已经力不从心。我们需要一套新的工程学科来处理"信号编排"这一全新维度的问题。

这就是 Context Engineering 诞生的历史必然性。它是 Prompt Engineering 的进化形态，是 Prompt Tuning 的工程对位物，是 AI 系统设计进入成熟期的标志。

---

1.4 专家级读者必须警惕的三个误区

对于已经在生产环境部署 LLM 系统的资深工程师和架构师来说，理解 Context Engineering 的概念框架只是起点。更关键的是识别并破除那些在行业内流传甚广、但实则极具误导性的认知误区。这些误区往往披着"常识"的外衣，却在系统层面造成难以察觉的长期损害。

误区一：窗口即能力 (Window as Capability)

流行表述："我们的模型支持 128K 上下文窗口，所以系统可以处理任意长度的对话。"

问题本质：窗口大小 ≠ 模型有效利用上下文的能力。这两件事在工程实践中需要严格区分。

128K 的窗口意味着模型可以"接收"128K 的输入，但这并不意味着模型可以"理解"128K 的输入。Lost in the Middle 现象已经证明，模型对长上下文中不同位置的信号处理能力是不均匀的。Anthropic 在 2024 年发布的 *Effective Context Window* 研究中进一步发现：即使是 Claude 这样的顶级模型，在 200K 上下文里能稳定利用的有效窗口大约只有 70%-80%。剩下的 20%-30% 是"名义容量"，实际推理中被严重稀释。

判断依据：当你听到"我们用了 128K 模型，所以..."时，立即追问三个问题： 1. 这 128K 里实际填充了多少 token？是动态填充还是全量填充？ 2. 关键信息放在窗口的哪个位置？是否避开了中段？ 3. 有没有做过有效上下文长度的实测？用什么数据集、什么指标？

正确的工程姿态：窗口大小是上限，不是目标。真正的设计目标是"用尽可能小的窗口覆盖尽可能高的信号密度"。

误区二：长度即性能 (Length as Performance)

流行表述："检索片段给得越多，模型回答得越好。"

问题本质：上下文长度和模型性能之间的关系是非单调的——存在一个最优区间，超过这个区间后，性能反而下降。

这种现象在 RAG 系统里尤为常见。某法律科技团队早期版本的合同审查系统，会把 Top-20 召回的判例全部注入上下文。结果发现：召回越多，模型的判断准确率反而越低。原因有二：(1) 不相关判例引入了"对抗性提示"——模型会倾向于综合所有信息，而不是只关注真正相关的；(2) 大段文本的累积让关键判例被淹没在注意力稀释中。

判断依据：评估上下文长度对性能的影响时，必须使用"信号密度"指标，而不是"绝对长度"。同样 2000 token 的上下文，如果全部是高相关的判例摘要，性能远好于 8000 token 的原始文本堆砌。

正确的工程姿态：用相关性 + 简洁度，而不是用召回量，来衡量检索层。一个经过严格相关性过滤、严格摘要压缩的 Top-3 召回，远胜于一个无差别注入的 Top-20。

误区三：堆叠即优化 (Stacking as Optimization)

流行表述："既然上下文能装，那就都塞进去——system prompt、few-shot 示例、检索片段、工