上下文工程的崛起：定义、范畴与系统思维

上下文工程的崛起：定义、范畴与系统思维

当 Gemini 1.5 Pro 在 2024 年初宣布支持 100 万 token 上下文窗口时，许多从业者以为长上下文问题已经"被解决"。但随后一年里围绕 RULER、LongBench、NeedHaystack 的复测数据却给出了一个令人不安的结论：标称窗口大小的增长，与模型在该窗口内真正可被利用的能力，几乎呈非线性关系。在 8K 到 200K 之间，模型表现确实在抬升；但越过某个临界点后，曲线开始塌陷，而这条塌陷曲线在每个模型家族上都呈现出截然不同的形态。这一现象逼迫我们把"上下文"从输入框里的一段文本，抬升为一个独立的工程对象：上下文工程（Context Engineering）。它不是一个新名词的炒作，而是对大模型时代一类全新系统问题的命名：当我们不再只是"让模型回答问题"，而是让模型在一个跨越分钟、小时、天甚至月的会话中持续进行推理与决策时，上下文本身就成了系统的内存、磁盘和检索引擎，而我们需要为它设计一套完整的工程方法论。

本章将围绕三个层层递进的问题展开。第一，为什么"上下文窗口扩张"不能等同于"上下文能力提升"？第二，当我们承认上下文是一种需要被系统化管理的资源时，它应该具备哪些可被工程化的属性？第三，这些属性如何落地为一个可被团队复用、可被产品迭代的五层参考模型？我们将以业界公开的实测数据为锚点，结合一个会在后续章节反复迭代的"AI 个人助理"原型，把抽象的概念转译为可操作的设计语言。

1.1 从"参数竞赛"到"上下文竞赛"的范式转移

把时钟拨回 2020 年。彼时业界关于大模型能力跃迁的主流叙事是"scaling law"——参数、数据、算力，三者同步放大即可解锁更强能力。GPT-3 175B 的 2K 上下文窗口够用，因为那时的任务主要是补全、问答、改写，并不真的需要模型"看到"太多东西。但到了 2023 年，随着 GPT-4、Claude 2、Gemini 1.0 先后问世，应用场景迅速演化为两类对长上下文有强需求的方向：代码理解与多文件编辑（开发者希望模型一次性看完整个仓库的若干核心文件）以及对话型 Agent（模型需要在多轮会话中积累状态、引用早先的工具调用结果）。这两类需求推动 Claude 2 率先把窗口拉到 100K，GPT-4 Turbo 跟进 128K，Claude 3 进一步推到 200K，最终 Gemini 1.5 Pro 在 2024 年把窗口一举推到 1M，并在面向特定合作方的早期版本中测试到 2M——相当于约 150 万行代码或 2000 多页文本。

这条扩张曲线背后有三股驱动力同时在起作用。其一是注意力机制的边际成本：标准 Transformer 的自注意力复杂度是 $O(n^2)$，其中 $n$ 为序列长度，单纯的二次放大在工业级 KV Cache 上不可承受。其二是位置编码的可外推性：RoPE、ALiBi、YaRN 等相对位置编码方案各有其有效半径，超过训练时见过的最大长度后，外推质量会显著下滑。其三是推理算力的分配：在固定总 token 数下，更长的上下文意味着每 token 摊到的预填充算力减少，长文档推理的实际响应延迟由预填充阶段主导，窗口越大，首字延迟（TTFT）越敏感。这三股力量相互作用，决定了"扩窗口"从来不是免费的午餐。

更关键的是，2024 年后业界开始普遍认识到：推理时计算（Inference-time Compute）的总量，正在取代参数规模成为新瓶颈。Agent、工具调用、Chain-of-Thought、ReAct 式反思都在让模型在每次回答时消耗远超过去的"算力预算"。在这种范式下，模型在每一步推理中能"看到什么"——也就是上下文的组织方式——比"模型有多大"更直接地决定了任务成功率。这就是我们说的范式转移：从"参数竞赛"切换到"上下文竞赛"。

但范式转移并不等于问题解决。把窗口从 8K 推到 200K、推到 1M，只是把原先发生在 8K 处的"模型记不住"问题，平移到了一个更高量级上。我们接着要追问：当窗口真的变大时，模型真的变好用了吗？

1.2 长上下文的三个致命误区

围绕"长上下文"，业界长期存在三种相互纠缠却都需要被独立纠正的认知误区。它们分别是参数即能力、窗口即记忆、堆叠即理解。

1.2.1 误区一：参数即能力

第一种误区的核心是把模型参数规模当成"上下文能力的代理变量"。直觉上 GPT-4 比 GPT-3.5 强，自然应该也能在更长上下文上更强。但实证数据并不支持这种线性外推。Stanford CRFM 在 2023 年的一项研究中就发现，将同一组长文档问答任务分别在 GPT-3.5-16K 和 GPT-4-32K 上跑，模型在 32K 上下文上的表现并不是 16K 的简单"放大版"——某些任务上 GPT-4-32K 反而比 GPT-3.5-16K 更稳定，但另一些需要精细信息抽取的任务上，GPT-4-32K 在 24K 以后开始出现"近因偏好"（recency bias），对靠前的关键信息利用率明显下滑。这说明参数量与上下文利用率之间不是线性关系，而是依赖任务的复杂函数。

更深层的原因在架构层。标准 Transformer 的注意力机制可以被写为 $\text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^\top}{\sqrt{d_k}}\right)V$，其中 $Q, K, V$ 分别是 query、key、value 矩阵。当上下文从 $n$ 扩到 $kn$ 时，$QK^\top$ 的元素数量以 $k^2$ 倍增长。模型并没有因为参数增加而自动学会在更大的注意力矩阵上做更精确的检索——它只是被塞进了一个更大的算子空间里。如果不在训练时显式增加"长距离检索"类的合成数据，模型在长上下文上的有效寻址能力并不会自动诞生。换句话说：参数是上下文能力的必要条件，但远非充分条件。

1.2.2 误区二：窗口即记忆

第二种误区是把"上下文窗口"等同于"记忆"。这个误解尤其在产品端常见。许多团队在设计对话产品时，会假设模型"记得"会话开头的设定，于是用户在第 50 轮提到的偏好、第 100 轮提到的关键事实，到了第 200 轮依然能被准确引用。事实上，上下文窗口只是当前推理过程中的一次性工作内存——一旦会话结束、新会话开始，整个窗口会被清空。即便在同一会话内，当窗口被填满而早期消息被截断时，模型不仅会"忘记"那段内容，更可能基于不完整的历史做出错误推断。

更微妙的是，即便内容没有被截断，模型对早期上下文的"回忆"也呈现出非均匀的衰减曲线。Liu 等人在 2023 年的"lost in the middle"研究中，使用 Multi-needle 检索任务系统性地测定了这种衰减：信息的相关答案出现在窗口 0%、25%、50%、75%、100% 五个位置时，模型的回答准确率呈典型的"U 形"曲线——首尾表现良好，中段显著塌陷。这意味着上下文窗口不是一块平坦的内存，而是一条有"重力梯度"的记忆带：靠前与靠后的信息占据更高的注意力权重，中段在长上下文中几乎处于"注意力黑洞"。

1.2.3 误区三：堆叠即理解

第三种误区在工程团队中尤其普遍：把更多文档、更多对话、更多工具结果一股脑塞进上下文，就以为模型"读懂了"。但堆叠带来的不仅是冗余，更是一种系统性的注意力稀释。

考虑一个具体场景：一个法律 AI 助手收到用户上传的 50 份合同文件，加上用户历次对话记录，加上从知识库检索回来的 30 条相关判例，加上系统提示词，加上之前的工具调用历史——总共塞进接近 200K tokens。模型此时面对的不是"充分的上下文"，而是一片信息密度极度不均匀的语料荒漠。真正关键的事实——比如"用户在第 17 份合同第 23 条里加了一个违约金条款"——被淹没在大量无关段落中。模型的注意力机制在长上下文中倾向于"分散对焦"，对关键信号的捕获率急剧下降。

反映在指标上，这种稀释表现为信噪比的非线性塌陷。RULER 基准（Hsieh 等人，2024）针对 13 项长上下文任务设计了统一评测框架，包括 NIAH（Needle in a Haystack）变体、多跳检索、变量追踪、JSON 字段提取等。结果显示：当上下文长度从 4K 增加到 128K 时，几乎所有主流模型的"有效上下文利用率"都从 95%+ 跌到 50% 以下。所谓"有效上下文"，是指模型在该位置上检索或推理信息的成功率高于某个阈值（例如 80%）的实际窗口长度。Gemini 1.5 Pro 在 NIAH 单针任务上能将这个阈值推到接近 1M，但在多针、变量追踪、JSON 抽取等更复杂的子任务上，有效窗口会急剧回缩到 100K-200K 区间。

这三个误区共同指向一个结论：窗口大小是一个数字，但上下文能力是一个分布。它沿着位置、任务、信息密度、推理深度等多个维度展开。我们需要把上下文当成一个真正的工程对象来对待——可观测、可压缩、可替换、可持久、可计量。

1.3 标称上下文与有效上下文：来自三大基准的实测

为了让"标称 vs 有效"不再是抽象的口号，本节直接带读者走进三类被广泛使用的长上下文评测基准，看清主流模型在这条曲线上的真实形态。

1.3.1 Needle-in-a-Haystack：单针检索的最弱基线

NIAH（Needle in a Haystack）由 Greg Kamradt 在 2023 年提出，方法简洁：在一篇长文档中随机位置插入一段与文档主题无关的"针"句（例如"The best thing to do in San Francisco is to eat a sandwich and sit in Dolores Park on a sunny day."），然后询问模型这个事实。它测量的，是模型在最纯净形态下的精确寻址能力。

主流模型在 NIAH 上的表现差异巨大。Gemini 1.5 Pro 在 1M 上下文上仍然能稳定检索到任意深度的"针"，呈现一片几乎全绿的色块；Claude 3.5 Sonnet 在 200K 内维持高准确率；GPT-4 Turbo-128K 在前 70K 表现尚可，但 70K 之后准确率开始断崖式下降，到了 120K 附近对中段信息几乎完全失效。这张图给产品团队的直接信号是：单纯依赖 NIAH 高分来判断"长上下文可用"是危险的，因为 NIAH 是最容易的任务。

1.3.2 Multi-needle：从寻址到聚合

Multi-needle 是 NIAH 的自然升级：在同一长文档中插入多根"针"，要求模型同时返回这些事实，或者基于多个事实做组合推理。它直接暴露了 lost-in-the-middle 现象：当针的数量从 1 增加到 5 甚至 10 时，模型的综合准确率在不同位置上的方差急剧放大。在 Stanford 的复测中，Claude 3 Opus 在 200K 上下文、4-needle 任务下，整体准确率从单针的 99% 跌到 78% 左右；而 GPT-4 Turbo 在 128K、5-needle 任务上，中段 4 根针的整体命中率下降到不足 50%。

Multi-needle 的真正杀伤力体现在任务组合性上：当问题不再是"找出第 X 根针"而是"基于第 X 根针和第 Y 根针之间的关系做推理"时，即使是 Gemini 1.5 Pro 也会丢失约 15-25 个百分点的准确率。这说明长上下文能力不仅是寻址问题，更是在工作记忆上做多步推理的问题，后者对模型架构和训练数据提出了截然不同的要求。

1.3.3 LongBench：中文长上下文任务的横向切片

LongBench（Yushi Bai 等，2024）覆盖了 21 个数据集、6 大任务类别（单文档问答、多文档问答、摘要、少样本学习、合成任务、代码补全），平均长度约 6K-21K tokens。它是中文语境下最重要的长上下文基准之一。

LongBench 的数据揭示了两个耐人寻味的趋势。第一，模型在中文长上下文任务上的有效窗口通常比其英文对应任务更短，部分原因是中文 BPE 分词后字符密度更高，每"自然段"消耗的 token 数更多，等价语义长度对应的 token 序列更长。第二，任务类型间的有效窗口差异巨大——摘要类任务的最佳长度通常在 8K-16K，超过这个范围边际收益迅速衰减；而多文档问答类任务的最佳长度有时反而在 4K-8K，因为更多文档带来的注意力分散超过了长度本身的增益。

把这三类基准综合起来看，可以提炼出当前业界的一种粗略共识：

| 模型家族 | 标称窗口 | NIAH 单针有效率≈80% 的位置 | 5-Needle 综合有效率≈70% 的位置 | LongBench 中文任务有效窗口 | |---|---|---|---|---| | GPT-4 Turbo | 128K | ≈100K | ≈64K | ≈32K-48K | | Claude 3.5 Sonnet | 200K | ≈180K | ≈128K | ≈64K-96K | | Gemini 1.5 Pro | 1M | ≈900K | ≈400K | ≈128K-256K |

这张表是动态的，会随版本迭代变化，但形态是稳定的：没有任何模型能在所有任务类别上都把"有效"二字贴满标称窗口。我们必须在产品设计中显式承认这种差距，并为其设计兜底机制。这就是上下文工程存在的最直接理由。

1.4 上下文工程：一个新学科的诞生

上一节我们用数字证实了"窗口≠能力"。但仅停留在"批判"是不够的——我们需要构造一个正向定义，用以指导工程实践。

1.4.1 定义：上下文工程的研究对象

我们给出本书的核心定义：

> 上下文工程（Context Engineering） 是研究如何在大模型推理过程中，对进入模型的全部信息——包括系统提示、用户输入、历史对话、检索召回、工具结果、外部知识、长期记忆——进行系统化的设计、组织、压缩、检索、持久化与监控，以使模型在有限的注意力预算下获得最大任务收益的一门工程学科。

这个定义有三个关键约束。第一，上下文工程面向的是推理时（inference-time）的信息流，它和模型训练阶段是解耦的，但二者通过"哪些信息应该进入上下文"这一决策紧密相连。第二，上下文是有限预算下的资源——注意力不是免费的，每增加一段冗余信息，就稀释了对关键信号的注意力。第三，它是一套系统方法，而不是某个单点技术。这就要求它具备可观测、可压缩、可替换、可持久、可计量五大工程化属性。

1.4.2 五大工程化属性

为什么是这五个属性？它们各自解决了上下文工程中的某一类核心痛点。

可观测性（Observability） 是所有工程实践的前提。我们必须在每一轮推理中知道：当前上下文有多长？其中哪些信息被模型实际使用了？哪些被忽略？哪一段触发了模型的"上下文污染"（context pollution）？没有可观测性，任何优化都只能盲人摸象。

可压缩性（Compressibility） 解决的是注意力预算有限这一根本约束。当一段 200K 的对话记录被压成 200K 的关键事实摘要，模型的注意力权重会重新聚焦。可压缩性要求我们能用算法或模型对上下文做无损或可控损失的压缩，并在解压后仍保留可推理的语义单元。

可替换性（Replaceability） 解决的是上下文动态性问题。在 Agent 系统里，某些上下文片段（如同名实体引用、过期工具结果）需要在被模型真正消费前被替换。上下文必须支持模块化的替换、版本化与回滚。

可持久化（Persistence） 解决的是跨会话、跨任务的状态保留问题。传统的上下文窗口是"用完即弃"的，而现实应用需要的是跨小时、跨天、跨周的连续记忆。这要求我们把上下文的一部分外置到外部存储（向量数据库、知识图谱、结构化记忆库），并设计一套召回协议。

可计量性（Measurability） 则要求我们为上下文的每个组件打分——相关性、新鲜度、信息密度、风险等级——并通过这一套度量来调度有限资源。RAG 召回的分值、记忆条目的引用次数、压缩前后的语义距离都是可计量维度的实例。

把这五个属性并列起来，我们会发现它们构成了一组相互正交的工程基线：如果一个上下文组件只满足其中两三个，它就还不能称作"工程化"的。在后续章节我们会反复回到这五条基线，并用具体案例检验它们。

1.4.3 与传统软件工程类比

为了帮助读者建立直觉，我们把上下文工程的五大属性与更熟悉的传统软件工程概念做一次映射：

• **可观测性 ↔ 分布式系统的 Metrics、Logs、Traces**：模型推理的一次调用如同一个微服务调用，我们需要 tracing 来追踪每段上下文在推理链路上的实际效用。
• **可压缩性 ↔ 数据库的有损压缩与索引**：将长上下文压缩为稠密表示，与数据库的列式压缩、向量量化在思想上是同构的。
• **可替换性 ↔ 版本管理与依赖注入**：把上下文当作可替换的依赖项，便于在不同版本间安全切换。
• **可持久化 ↔ 持久化存储层**：向量数据库、KV 存储、知识图谱都是显式的外部记忆层。
• **可计量性 ↔ 资源调度与定价**：上下文窗口本身就是带价位的稀缺资源，分值体系是它的"定价"方式。

这种类比不是装饰性的。当我们在第 11 章讨论"上下文压缩算法"时，实际上就是在解决"用一个更小的稠密表示逼近一个长上下文的信息量"——这与数据库领域的 Summary Structures、Sketch 数据结构在方法论上是连续的。

1.5 五层参考模型与协作边界

有了定义和属性，我们还需要一个能把它们组装起来的结构化参考模型。本节给出本书的核心框架——五层模型，并讨论它与相邻学科的边界。

1.5.1 五层参考模型

一个典型的 LLM 推理请求，其"上下文"的构成并不是单一的扁平字符串，而是经过多层加工的层级结构。我们把它分解为五层：

```mermaid flowchart TD L0[Original Input Layer] --> L1[Encoding Layer] L1 --> L2[Compression Summary Layer] L2 --> L3[Retrieval Augmented Layer] L3 --> L4[Persistent Memory Layer] L4 --> L5[Application Layer Model Inference] ext_app[Application Requests Sessions Tools] -->