上下文工程的宏观图景 | The Big Picture of Context Engineering
第 1 章：上下文工程的宏观图景
The Big Picture of Context Engineering
当工程师们试图构建一个能够处理长文档的智能系统时，他们面临的第一个问题不是模型不够聪明，而是上下文不够长。当产品经理希望对话助手记住用户三个月前的偏好时，他们发现系统只能回顾最近几轮对话。当开发者尝试让AI Agent自主完成复杂任务时，最大的瓶颈不是推理能力不足，而是状态管理的混乱与记忆的断裂。这些问题看似不同，实则都指向同一个核心领域——上下文工程。
上下文工程（Context Engineering）是本书的核心概念，它指的是在大型语言模型应用中，系统性地设计、管理和优化模型输入输出的全部技术与方法。这不是简单的"给AI更多文字"，而是一门关于信息选择、信息压缩、信息组织和信息检索的工程学科。当模型的上下文窗口从最初的512 tokens扩展到如今的数十万乃至百万tokens，当模型能够处理的文本长度呈指数级增长，上下文工程的战略价值也随之凸显。
理解上下文工程为什么重要，需要回到一个基本事实：大型语言模型的"智能"本质上是一种基于上下文的推理能力。模型无法真正"记住"训练数据中的具体内容，它的所有回答都严格依赖于当前输入的上下文。这意味着，系统的能力边界在很大程度上由上下文工程的质量决定，而非仅仅由模型参数规模决定。一个上下文工程做得好的系统，即使使用较小规模的模型，往往也能超越一个拥有更强模型但上下文工程混乱的系统。
本章作为全书的开篇，将为读者构建一个完整的上下文工程技术地图。我们将追溯上下文处理技术从固定窗口到动态上下文的历史演进，理解支撑现代上下文工程的理论基础，并深入分析上下文工程的五大支柱——长度（Length）、压缩（Compression）、摘要（Summarization）、记忆（Memory）、状态（State）——它们各自的原理、相互的关系以及协同工作的方式。在此基础上，我们将讨论不同应用场景对上下文系统的差异化需求，帮助读者确定自己的学习重点。最后，本章将预览全书15章的知识体系架构，为后续深入学习奠定基础。
---
1.1 上下文工程的定义与历史演进
从固定窗口到动态上下文：范式转变
上下文工程的概念并非凭空产生，它是从LLM应用开发实践中逐步提炼出来的工程方法论。要理解它的全貌，需要回顾上下文处理技术的演进历史。
第一阶段：固定窗口时代（2017-2020）。在Transformer架构刚刚提出、GPT系列尚未出现的年代，模型的上下文处理能力受到硬件和算法的双重限制。当时的模型通常只能处理固定长度的文本，典型如BERT的512 tokens上限。开发者面对这一限制时，几乎没有太多选择：要么截断过长的文本，要么完全放弃处理长文档的场景。这种"硬性限制"塑造了早期NLP系统的基本架构——任务被设计为接收短文本输入，输出短文本结果。信息抽取、文本分类、情感分析等主流任务天然适配这种范式。
第二阶段：滑动窗口与分层处理（2020-2022）。随着GPT-3的发布，模型上下文窗口扩展到2048 tokens，后来进一步扩展到4096 tokens。这一进步打开了新的应用可能，但同时也带来了新的工程挑战。开发者发现，简单的截断策略会丢失关键信息，而将长文档分成多个片段分别处理会导致上下文碎片化。这促使一系列技术涌现：滑动窗口（Sliding Window）将文档切分为重叠的片段分别处理；分层处理（Hierarchical Processing）先用模型提取文档高层结构，再逐段深入分析；层次化摘要（Hierarchical Summarization）从段落摘要到章节摘要再到全文摘要。这些技术标志着上下文处理从被动接受限制转向主动设计策略。
第三阶段：超长上下文与注意力工程（2022-2024）。2023年至2024年间，模型上下文窗口呈爆发式增长。Claude支持200K tokens的上下文，Gemini 1.5 Pro达到100万tokens，Kimi和智谱GLM等国产模型也支持数十万tokens的超长上下文。然而，技术挑战并未因此消失。研究者发现，长上下文模型的注意力机制存在"中间迷失"（Lost in the Middle）问题——模型对长文本中间部分的信息提取能力显著弱于开头和结尾部分。这一发现促使注意力优化技术成为研究热点：稀疏注意力（Sparse Attention）减少计算复杂度但可能丢失信息；线性注意力（Linear Attention）提高效率但改变注意力模式；相对位置编码（RoPE、ALiBi）解决长序列位置信息外推问题。上下文工程因此进入"注意力工程"时代——不仅要决定输入什么，还要决定模型如何"看"这些输入。
第四阶段：动态上下文与外部记忆（2024至今）。当上下文窗口接近或超过百万tokens时，单靠模型自身能力处理所有信息变得不现实。开发者意识到，必须在模型"内部上下文"与"外部记忆"之间建立清晰的分界。检索增强生成（RAG，Retrieval-Augmented Generation）成为主流范式：模型通过检索机制从外部知识库获取相关信息，仅将最相关的内容纳入实际上下文。向量数据库（Vector Database）成为标配基础设施。然而，RAG只是起点。更复杂的系统需要多层次记忆：工作记忆（Working Memory）管理当前会话状态；情景记忆（Episodic Memory）存储会话历史；长期记忆（Long-term Memory）积累跨会话的知识；程序记忆（Procedural Memory）存储系统行为模式。这种多层次记忆架构将上下文工程推向了一个新的高度——它不仅是处理文本的技术，更是构建"持久智能体"的基础设施。
范式转变的核心洞察
回顾这段历史，可以提炼出一个关键洞察：上下文工程的演进本质上是信息管理责任的重新分配。
在固定窗口时代，信息管理由模型内部机制完全控制，开发者只能被动适应模型限制。在滑动窗口时代，信息管理责任开始向应用层转移，开发者通过分段策略主动组织信息。在超长上下文时代，信息管理的复杂性从"如何处理更多"转向"如何有效利用更多"——因为信息过载同样成为问题。在动态上下文与外部记忆时代，信息管理变成了一项独立的工程任务，需要专门的技术架构、存储系统和检索算法。
这种责任分配的变化塑造了现代上下文工程的核心原则：上下文不是越多越好，合适的信息在合适的位置呈现给模型才是最优解。这意味着上下文工程涉及一系列复杂的权衡：长度与效率的权衡（更长上下文带来更多信息但增加计算成本和注意力分散），压缩与保真度的权衡（压缩减少token消耗但可能丢失关键细节），检索与生成的权衡（检索扩展知识边界但可能引入无关信息）。
理解这些权衡，是掌握上下文工程的第一步。
---
1.2 上下文工程的五大支柱
上下文工程作为一个复杂的工程领域，可以分解为五个相互关联的核心子领域。本书将它们称为五大支柱：长度（Length）、压缩（Compression）、摘要（Summarization）、记忆（Memory）、状态（State）。这五个支柱并非彼此独立，而是形成一个相互支撑的技术体系。下面逐一解析每个支柱的内涵与边界。
支柱一：长度（Length）
长度是上下文工程最直观的维度，指的是在任意时刻可以纳入模型上下文的tokens数量。然而，"长度"作为一个工程支柱的含义远超简单的token计数，它包含以下关键问题：
上下文窗口管理：如何决定当前上下文应包含哪些信息？当新信息到来时，哪些旧信息应被保留？哪些应被移除？这种决策需要考虑信息的相关性、时效性和系统性优先级。例如，在处理一份长报告时，用户当前询问的章节应获得最高优先级，相关背景章节次之，而无关章节可能被完全排除。
位置编码与注意力分配：模型对上下文中不同位置的信息有不同的敏感性。研究表明，当上下文长度超过一定阈值时，模型对"中间"位置信息的召回率显著下降。长度支柱需要解决的问题包括：如何通过信息重排（将关键信息放在注意力更敏感的位置）、如何利用位置编码优化长距离依赖建模、如何通过提示设计引导模型的注意力焦点。
分段与连接策略：当单个信息单元（如一篇文档）超过上下文窗口时，必须进行切分。分段策略直接影响信息完整性保留程度。常见的分段方法包括：语义分块（按自然段落或主题边界切分）、固定长度分块（简单但可能切断语义单元）、递归分块（按层级结构逐层切分）。分段后的连接策略同样重要：如何传递跨段落的上下文信息，如何维护段落的全局依赖关系。
长度工程实践中的典型挑战包括：超长文档的索引与检索效率问题、上下文窗口边缘的信息丢失问题、多文档场景下的上下文竞争问题（即不同文档争夺有限的上下文空间）。
支柱二：压缩（Compression）
压缩是应对上下文长度限制的核心策略之一，指的是在保留语义核心的前提下减少信息的token表示长度。压缩与摘要既有重叠又有区别：压缩更侧重于信息密度的提升，而摘要侧重于信息内容的提炼。
无损压缩与有损压缩的区分：上下文压缩可以是完全的语义保留（无损压缩），也可以是有选择性地丢弃"次要"信息（有损压缩）。技术层面的无损压缩包括：同义词替换（用更短的同义词表达相同含义）、指代消解（用代词替换已提及的实体）、结构简化（将复杂句式转为简单句式）。有损压缩则需要更复杂的语义判断：哪些细节可以安全删除而不影响核心语义？这涉及到信息重要性评估和语义等价性判断。
Token效率优化：大语言模型按token计费或按token计算计算资源，因此token效率是压缩的核心目标之一。常见的Token效率优化策略包括：使用更紧凑的文本格式（如JSON代替自然语言描述）、结构化信息编码（如将表格转为CSV或Markdown表格）、专业术语替换（用行业术语替代冗长解释）。这些策略通常能将信息压缩50%以上而不损失可理解性。
压缩质量评估：压缩的有效性不能仅用压缩比衡量，还需考虑语义保持度和下游任务性能。常用的评估维度包括：语义相似度（压缩前后表示的含义是否等价）、关键信息保留率（核心实体、关系、事件是否完整）、下游任务准确率（压缩后的信息是否足以支持正确的推理和回答）。
支柱三：摘要（Summarization）
摘要与压缩有密切关系，但摘要更侧重于主动提炼和重组信息，而非仅仅减少表示长度。摘要的核心目标是让模型"理解"信息并提取其精华。
单文档摘要：对单个长文档生成摘要是最基础的任务。不同类型的摘要服务于不同目的：提取式摘要（Extractive Summarization）直接从原文抽取关键句子或段落，保留原文表述；生成式摘要（Abstractive Summarization）允许模型用自己的话重组信息，可能引入原文未明确表述但语义等价的内容。在上下文工程中，摘要常作为分层处理的一部分：从全文摘要到章节摘要到段落摘要，形成一个多粒度的信息金字塔。
多文档摘要与信息融合：当上下文包含多个相关文档时，摘要面临新的挑战：如何识别跨文档的冗余信息并去重？如何处理相互矛盾的信息？如何整合不同视角形成连贯叙述？这类问题在RAG系统和Agent系统中尤为常见，因为这些系统往往需要综合多个检索结果或多个工具输出来回答用户问题。
摘要引导的上下文重建：在高级应用中，摘要不仅是最终输出，更是上下文重组的基础。一种常见模式是：基于用户问题，首先生成相关文档的针对性摘要，然后将摘要、原始文档的关键片段、以及用户问题组合成最终的模型上下文。这种"摘要引导"策略比纯检索或纯摘要都更有效，因为它确保上下文既精炼又与当前问题高度相关。
支柱四：记忆（Memory）
如果说长度、压缩、摘要关注的是当前上下文的组织和优化，那么记忆关注的是跨越时间的上下文连续性。记忆支柱解决的核心问题是：模型如何访问和使用"不在当前上下文但与当前任务相关"的信息。
记忆的类型分层：
- **工作记忆（Working Memory）**：指当前会话中模型正在处理的信息，类似于人类的工作记忆。工作记忆通常被纳入模型的直接注意力范围，具有最低的访问延迟但容量有限。
- **情景记忆（Episodic Memory）**：指过去会话中发生的事件和交互。当用户在新的会话中继续之前的项目或话题时，系统需要从情景记忆中检索相关内容。
- **语义记忆（Semantic Memory）**：指从大量文档和知识中提取的结构化知识。这类似于RAG系统中的知识库，存储的是"事实"而非"事件"。
- **程序记忆（Procedural Memory）**：指系统或Agent习得的行为模式和操作流程。当Agent遇到类似情境时，可以调用程序记忆快速响应，而无需重新学习。
记忆的检索与访问：记忆系统的核心挑战是"如何找到正确的信息"。向量检索（Vector Retrieval）是当前主流方案：将信息编码为向量，在向量空间中通过相似度搜索找到相关内容。然而，向量检索并非万能——它擅长基于语义相似性的检索，但难以支持精确匹配、范围查询、多条件组合等需求。因此，实际系统通常采用混合检索策略：向量检索处理语义相关性，关键词检索处理精确匹配，元数据过滤处理结构化条件。
记忆的更新与遗忘：记忆系统不是静态存储，需要持续更新和优化。记忆更新策略包括：增量更新（新信息加入记忆）、整合更新（将新信息与已有知识融合）、修正更新（修正错误的已有记忆）。与此同时，记忆压缩和遗忘机制同样重要——无限积累记忆会导致检索效率下降和存储成本上升。智能的遗忘策略应该优先移除"过时信息"和"低价值信息"。
支柱五：状态（State）
状态是上下文工程中最容易被忽视但最关键的支柱。它关注的是系统当前处于什么状态，以及如何管理状态转换。
状态的定义与类型：在LLM应用中，"状态"可以理解为系统在任意时刻的完整配置。状态包含多个维度：
- **对话状态**：当前会话的话题、用户的意图、已确认的信息槽位。
- **任务状态**：正在执行的长期任务（如报告撰写、代码开发）的进度和中间结果。
- **Agent状态**：如果系统包含自主行动的Agent，状态还包括其当前目标、已采取的行动、可用资源、约束条件等。
- **系统状态**：应用层的配置参数、激活的工具、启用的功能模块等。
状态管理的核心挑战：与记忆不同，状态更强调"动态变化"和"正确转换"。状态管理的挑战包括：状态表示的粒度（过于粗粒度丢失细节，过于细粒度增加管理复杂度）、状态转换的可靠性（确保状态变化反映真实的系统变化）、状态一致性的维护（多组件系统中不同组件的状态保持同步）。
状态机与状态模式：在传统软件工程中，状态管理已有成熟的设计模式。有限状态机（FSM）适用于状态空间明确、转换规则清晰的场景。状态模式（State Pattern）允许对象在内部状态改变时改变其行为。这些设计模式可以迁移到LLM应用中，例如将Agent的行为建模为状态机，用提示词或代码定义状态转换规则。
状态与上下文的交互：状态管理最终要服务于上下文优化。一个好的状态管理系统应该能够：准确判断当前状态需要什么样的上下文支持、高效地将状态信息注入模型上下文、避免状态信息与上下文信息的冗余或冲突。在实践中，状态通常作为"系统提示"（System Prompt）或"控制上下文"（Control Context）的一部分传递给模型，指导模型的推理方向和行为模式。
五大支柱的协同关系
五大支柱并非孤立运作，而是形成一个紧密关联的技术体系。以下Mermaid流程图展示了它们之间的典型协作关系：
```mermaid flowchart TD A[用户输入] --> B[状态管理 State] B --> C{状态评估} C -->|需要回忆过去| D[记忆系统 Memory] D --> E[信息检索] E --> F{检索结果评估} F -->|信息过多| G[压缩 Compression] F -->|信息不足| H[扩展检索] G --> I{压缩结果评估} I -->|关键信息丢失| J[摘要 Summarization] J --> K[上下文组装] I -->|压缩适当| K H --> E K --> L[长度优化 Length] L --> M[上下文验证] M -->|通过| N[模型推理] M -->|超出窗口| G N --> O[输出生成] O --> B
style A fill:#e1f5fe style N fill:#c8e6c9 style O fill:#fff3e0 ```
从图中可以看出，用户输入首先触发状态管理，评估当前系统状态。如果当前状态无法满足用户需求，系统会从记忆系统中检索相关信息。检索结果过多时触发压缩，过少时扩展检索。压缩和摘要共同工作以提炼关键信息。最后，长度优化确保组装后的上下文满足模型输入限制。这种协作模式体现了上下文工程的整体性思维——每个支柱都不是独立存在的，而是在与其他支柱的交互中发挥价值。
---
1.3 LLM上下文的本质：注意力机制与KV缓存
理解上下文工程的底层原理，需要回到大语言模型的核心机制——注意力机制（Attention Mechanism）。注意力机制不仅是Transformer架构的基石，更是理解上下文工程为什么如此重要的关键。
注意力机制的工作原理
Transformer的核心创新是自注意力机制（Self-Attention），它允许序列中任意位置直接关注任意其他位置，而不局限于固定距离。对于输入序列中的每个token，自注意力计算它与所有其他token的"相关性"，并根据相关性加权聚合信息。
具体而言，给定输入序列 $X = (x_1, x_2, ..., x_n)$，自注意力通过以下步骤计算：
第一步：线性投影。输入通过三个权重矩阵投影为Query（查询）、Key（键）和Value（值）三个向量： $$Q = XW_Q, \quad K = XW_K, \quad V = XW_V$$
第二步：注意力分数计算。Query向量与所有Key向量计算点积，得到注意力分数： $$\text{Attention Scores} = QK^T$$
第三步：归一化处理。注意力分数通过Softmax归一化，得到注意力权重： $$\text{Attention Weights} = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)$$
**第四