上下文工程概论：智能系统的记忆架构

第1章：上下文工程概论：智能系统的记忆架构

上下文工程的核心张力在于此：大型语言模型拥有令人惊叹的通用能力，却天生缺乏对特定情境的持久理解。当开发者试图让模型记住对话历史、领域知识或用户偏好时，他们面临的不是简单的“存储”问题，而是一个深刻的系统设计挑战——如何在有限的上下文窗口内，高效地表示、检索和更新信息。这一挑战的解决思路和工程方法论，构成了上下文工程（Context Engineering）这门新兴学科的核心内容。

本章将建立上下文工程的系统性认知框架。我们首先明确上下文工程的基本定义和核心范畴，厘清它与相关概念（如提示工程、知识库构建）的边界。随后，我们分析大语言模型时代上下文处理经历的范式转变，理解这一转变为何催生了对系统性方法的需求。接着，我们深入探讨上下文工程的三大支柱——记忆（Memory）、压缩（Compression）和检索（Retrieval）——揭示它们如何协同工作以构建智能系统的上下文基础设施。最后，我们通过真实工程案例展示不当上下文设计的后果，以及系统化方法如何扭转局面。通过本章的学习，读者将建立上下文工程的思维方式，为后续章节的深入探索奠定基础。

1.1 上下文工程的定义与核心范畴

上下文工程是设计与优化大型语言模型上下文表示的系统性方法论，旨在使模型能够在有限的上下文窗口内有效利用相关信息，以完成特定任务或维持持续的交互能力。这一术语的提出，源于对当前LLM应用开发中一个普遍痛点的回应：开发者往往将注意力集中在模型能力本身（模型选择、提示设计、参数调优），而忽视了上下文作为信息中介的系统性设计。

理解上下文工程需要将其置于三个相关概念的对比框架中加以辨析。

上下文工程 vs. 提示工程（Prompt Engineering）：提示工程关注的是如何设计输入提示的措辞、格式和结构，以引导模型产生期望的输出。其核心问题是“我应该如何表达指令”。上下文工程则更进一步，关注的是“上下文窗口中应该包含哪些信息、以何种形式组织”。换言之，提示工程是上下文工程在输入层面的具体实践，而上下文工程提供了更宏观的设计视角和系统性框架。

上下文工程 vs. 知识库工程（Knowledge Base Engineering）：知识库工程聚焦于结构化知识的获取、存储和组织，其产出是可供查询的知识图谱或向量数据库。上下文工程则关注如何将知识库中的信息转化为模型可利用的上下文形式，并动态管理这一转化过程。知识库是上下文工程的输入来源之一，但二者解决的问题不同。

上下文工程 vs. 检索增强生成（Retrieval-Augmented Generation, RAG）：RAG是上下文工程在特定场景下的具体实现方案之一，侧重于通过检索机制向模型提供外部知识。上下文工程是一个更宽广的概念范畴，涵盖了记忆管理、上下文压缩、对话状态维护等RAG未涉及的内容，同时也包含超越简单检索的更复杂策略。

上下文工程的核心范畴可以划分为三个层次。表示层（Representation Layer）处理的是信息在上下文中的编码方式：文本、代码、数字等不同形态的信息如何以模型友好的方式呈现，信息的粒度如何选择，冗余与完整性的平衡如何把控。管理层（Management Layer）关注的是上下文的生命周期：何时添加新信息、何时更新既有信息、何时遗忘过时内容、如何在多轮对话中维持状态连贯性。基础设施层（Infrastructure Layer）则涉及支持上下文操作的底层系统：向量数据库、缓存机制、滑动窗口策略、混合检索策略等技术组件的选型与集成。这三个层次相互依存，共同构成上下文工程的完整知识体系。

上下文工程之所以在当前阶段变得至关重要，与大语言模型的核心特性密切相关。现代LLM采用Transformer架构，其注意力机制虽然强大，但在计算复杂度上随序列长度呈二次方增长。主流模型的上下文窗口虽然已从初期的2K tokens扩展到128K甚至更多，但相对于真实应用场景中的信息需求而言，这一限制仍然是根本性的。与此同时，模型本身不维护状态，每次交互都需要完整的上下文输入。这些技术现实使得上下文工程从“锦上添花”的优化技巧转变为“不可或缺”的系统工程。

1.2 大语言模型上下文处理的范式转变

理解上下文工程的必要性，需要回顾大语言模型上下文处理经历的三次重要范式转变。这些转变揭示了为什么我们需要超越简单的“塞入更多文本”的思维，进入系统性设计的新阶段。

第一次转变：从固定模板到动态上下文

在LLM应用的早期阶段，开发者普遍采用固定模板（Fixed Template）模式。系统提示（System Prompt）包含角色定义、任务描述、输出格式要求等静态内容，用户输入直接追加其后。这种模式的优势在于简单直接，但很快就暴露了其局限性：固定模板无法适应对话进展的动态需求，无法根据用户行为调整上下文内容，无法处理超出模板预设范围的边界情况。

一个典型的失败场景是客服对话系统。当用户在第15轮对话后才提及关键偏好（如“我对海鲜过敏”），而系统的固定模板只包含前三轮的寒暄和需求确认，这位用户的健康信息根本不会被模型考虑。固定模板模式缺乏将“重要但延迟出现”的信息纳入后续决策机制的能力。

动态上下文（Dynamic Context）模式应运而生。系统开始追踪对话状态，维护一个随着对话进展而增长的上下文池（Context Pool），并根据特定策略决定何时将新信息纳入上下文、如何压缩已积累的内容。这种转变的本质是从“预设-执行”的静态思维转向“观察-适应”的动态思维。

第二次转变：从全量记忆到选择性关注

当动态上下文模式被广泛采用后，开发者很快遇到了新的瓶颈：上下文长度限制。全量记忆（Full Memory）策略——即保留对话历史的完整记录——在多轮交互场景下迅速耗尽有限的上下文窗口。一个典型的产品咨询对话可能持续30-50轮，累积数千个tokens；如果同时加载产品目录、用户历史档案、行业知识库，上下文溢出会成为常态而非例外。

这一困境催生了选择性关注（Selective Attention）范式的兴起。系统不再追求“记住一切”，而是发展出判断信息重要性的机制，优先将高价值信息置于上下文中。这一判断可以基于显式规则（如“用户明确表达的需求永远优先”）、基于模型能力（如“最近的交互通常更相关”）、或基于学习机制（如“从历史数据中学习哪些信息模式导致好的结果”）。

这一转变带来的核心变化是：从“存储-回忆”模式转向“评估-选择-呈现”模式。上下文工程的核心任务不再是“如何保存信息”，而是“如何在约束条件下做出最优的信息选择”。

第三次转变：从被动响应到主动预测

当前，我们正经历第三次范式转变：从不完整的被动响应到基于预测的主动上下文管理。在被动响应模式下，系统只是在用户明确提问后才将相关信息加载到上下文；这种模式固有的延迟意味着某些需要前瞻性考虑的信息可能永远无法及时到达。

主动预测（Proactive Prediction）模式试图预判用户的信息需求，在需求显现之前就准备相关上下文。这需要系统具备用户意图建模、任务规划、以及跨会话状态维护的能力。例如，当一个用户在过去三个月内多次查询某类产品的技术规格时，系统可以主动预加载该类产品的最新评测报告，而无需等待用户明确请求。

这一转变对上下文工程提出了更高要求：系统不仅需要管理当前会话的上下文，还需要维护用户画像和任务图谱，并基于这些长期知识做出上下文预判。当前，实现这一转变的技术成熟度仍不均衡，但它是上下文工程未来发展的核心方向。

理解这三次范式转变，有助于读者把握上下文工程演进的内在逻辑。每一次转变都回应了前一次范式的核心局限，同时也带来了新的设计挑战。上下文工程正是应对这些挑战的系统性方法论。

1.3 上下文工程的三大支柱：记忆、压缩、检索

上下文工程的工程实践围绕三大支柱展开：记忆（Memory）提供信息持久化的机制，压缩（Compression）解决信息密度的问题，检索（Retrieval）建立信息获取的路径。这三者并非孤立存在，而是相互依存、协同工作，共同支撑起智能系统的上下文基础设施。

1.3.1 记忆：信息的持久化与状态管理

在上下文工程的语境中，记忆远不止于简单的数据存储。它是一套关于“如何定义记忆单元、如何组织记忆结构、如何决定记忆生命周期”的系统性设计。

记忆单元的划分是第一个设计决策。记忆单元可以基于时间（如“会话中第N轮”）、语义（如“关于产品X的所有讨论”）、功能（如“用户的支付偏好”）或混合原则进行划分。单元划分的选择直接影响后续操作（检索、压缩、更新）的粒度和效率。以客服机器人为例，如果记忆单元被定义为“每个用户问题的完整上下文”，则系统可以独立处理每个问题；但如果用户在一个问题中涉及多个产品，系统可能需要进一步拆分记忆单元以支持更精细的检索。

记忆的组织结构决定了信息的可访问性。扁平结构（Flat Structure）简单但难以表达复杂关系；层次结构（Hierarchical Structure）可以反映记忆之间的从属或依赖关系；图结构（Graph Structure）则允许任意记忆单元之间的语义连接。每种结构都有其适用场景和权衡。例如，在法律文档分析系统中，采用层次结构组织记忆（案件→事件序列→证据→论证）比扁平结构更符合专业人士的认知模型。

记忆的生命周期管理涉及创建、访问、更新和遗忘四个核心操作。创建（Creation）决定何时生成新的记忆单元；访问（Access）定义如何使记忆可被后续交互使用；更新（Update）处理记忆内容的修改和同步；遗忘（Forgetting）——这往往被忽视但同样关键——决定何时以及如何清除不再需要的记忆。过于频繁的遗忘会导致信息丢失，过于保守的遗忘则会造成上下文污染和性能下降。

一个典型的记忆管理挑战出现在多会话状态同步场景中。假设用户在一个会话中更新了联系方式，而该信息需要立即在所有相关子系统中可用（不仅影响后续会话，还可能影响当前正在进行的其他会话分支）。这要求记忆系统支持原子性更新和一致性传播，增加了设计的复杂度。

1.3.2 压缩：信息密度的工程化优化

上下文压缩是应对有限上下文窗口约束的核心技术手段。其目标是在保持语义完整性的前提下，以更紧凑的形式表示信息。然而，“压缩”在上下文工程中不仅是技术操作，更是一种设计哲学：承认上下文容量有限，主动管理信息密度，而非被动地等待溢出。

文本压缩是最直观的压缩形式。其技术手段包括：去除停用词和冗余修饰语、使用指代代词替代完整实体、提取关键句子而非保留完整段落。文本压缩的挑战在于平衡压缩率与语义保真度——过度激进的压缩可能丢失关键细节，而过于保守的压缩则无法有效利用有限空间。

语义压缩（Semantic Compression）超越了字面层面的简化，试图捕获信息的本质含义。摘要生成（Summarization）是语义压缩的典型应用：给定一段长文本，生成一个短得多的摘要，同时保留核心信息。更复杂的语义压缩可能涉及信息提取和结构化转换，例如将一段产品描述转换为结构化的属性-值对，或将一段对话转换为“用户目标-系统行动-结果”的事件序列。

选择性加载（Selective Loading）是一种特殊的压缩策略，其核心思想不是压缩现有内容，而是选择性地决定“加载什么”。在检索增强生成（RAG）场景中，当向量检索返回10个相关文档片段时，系统可以选择只将最高相关性的3个片段放入上下文，而非全部加载。选择哪些片段的决策可以基于相关性分数、位置多样性、时效性等多种因素。

混合压缩策略是实践中的常见选择。系统可能同时采用多种压缩手段：对于对话历史，使用摘要压缩；对于外部知识，使用选择性加载；对于用户画像，使用结构化提取。关键在于针对不同类型的信息选择最适合的压缩方法，并确保各种压缩结果在上下文中能够协调共存。

压缩的边界判断是工程实践中的难点。一个实用的原则是任务相关压缩（Task-Relevant Compression）：压缩时不仅考虑信息的原始重要性，更考虑其与当前任务的关联度。一段关于用户早年偏好的描述可能在全局上“不重要”，但如果当前任务恰好是推荐怀旧产品，它就变得关键。压缩算法需要具备这种上下文敏感性。

1.3.3 检索：信息获取的路径设计

检索（Retrieval）建立了从外部存储或记忆系统向上下文窗口传递信息的路径。在上下文工程中，检索不仅是“查找-返回”的技术操作，更涉及检索策略、时机和呈现方式的系统性设计。

检索触发策略决定“何时检索”。常见策略包括：基于用户输入的显式检索（当用户明确询问特定内容时触发）、基于上下文的隐式检索（系统判断当前上下文不足以回答时自动触发）、以及基于预测的主动检索（预判用户需求而提前检索）。显式检索简单可控，但灵活性不足；隐式检索增加了系统复杂度，但提升了自动化程度；主动检索技术难度最高，但潜在收益也最大。

检索范围界定“去哪里检索”。可能的检索目标包括：长期记忆库（用户历史交互的累积）、领域知识库（产品手册、技术文档、行业标准）、实时数据源（当前库存、最新报价、即时新闻）、以及会话上下文（当前对话中已出现的信息）。不同检索目标可能使用不同的检索技术和更新策略。

检索结果的组织影响其可利用性。原始检索结果可能包含大量冗余或噪声，需要经过重排序（Re-ranking）和过滤（Filtering）处理。重排序根据与当前任务的相关性重新排列检索结果；过滤则移除明显不相关或有害的内容。经过处理的结果还需要决定呈现方式——是直接作为文本插入上下文，还是转换为结构化格式（如JSON），或仅传递检索结果的“摘要印象”。

检索与记忆的协同是上下文工程的高级主题。记忆系统中存储的信息本身也可以被检索，而检索结果又可能成为新的记忆。这种递归结构要求系统具备一致的检索接口和状态同步机制。一个设计良好的上下文工程系统应该使开发者能够以统一的方式访问记忆和外部知识，无需关心数据实际存储在哪里。

三大支柱的协同可以概括为：记忆提供了信息的持久化存储，检索建立了从存储到上下文的通道，压缩确保了信息能够以合适的形式和密度通过这一通道。三者缺一不可：没有记忆，信息无法积累；没有检索，记忆无法利用；没有压缩，检索结果无法承载。

1.4 当前上下文工程面临的技术挑战

尽管上下文工程已形成基本概念框架，其工程实践仍面临诸多尚未完全解决的技术挑战。认识这些挑战有助于读者理解后续章节内容的背景和价值，同时也能帮助实践者在具体场景中做出更明智的权衡决策。

1.4.1 上下文窗口的结构性限制

现代大语言模型的Transformer架构存在固有的上下文窗口限制。虽然顶级模型的上下文窗口已扩展至128K至200K tokens，但相对于真实应用场景的信息需求，这一限制仍然是根本性的。更重要的是，上下文窗口的tokens并非等价的——位置衰减效应（Positional Decay Effect）已被多项研究证实：模型对位于上下文开头和结尾的信息记忆更好，而对中间部分的信息关注度相对较低。这意味着即使在窗口未满的情况下，填充过多信息也会导致模型对关键内容的捕捉能力下降。

此外，注意力机制的计算复杂度随序列长度增长，即使窗口容量足够，过长的上下文也会带来推理延迟和计算成本的显著上升。在对响应时间敏感的生产环境中，这一因素往往比窗口限制更具约束力。

1.4.2 检索质量的边界问题

基于向量相似度的检索是当前主流的检索技术，但其质量存在明显边界。语义相似性与任务相关性之间并非总是正相关。一段与用户问题字面语义高度相似的文本，可能在具体任务场景下并不真正有用。例如，当用户询问“iPhone 14的电池续航”时，关于“iPhone历史演进”的长文可能因包含丰富的相关词汇而获得高相似度分数，但其核心内容并非用户所需的续航数据。

多跳推理（Multi-hop Reasoning）场景对检索提出了更高要求。当答案需要综合多个信息源才能得出时，单次检索往往只能返回部分相关线索，系统需要具备跨检索结果进行推理的能力。当前主流的“检索-读取”单轮模式在面对复杂问题时表现欠佳，需要发展更复杂的检索-推理循环机制。

1.4.3 记忆一致性与状态同步

在多智能体或多子系统协作的复杂系统中，上下文状态的一致性维护是一个严峻挑战。当多个子系统各自维护独立的上下文，且需要定期同步状态时，系统可能陷入状态不一致（State Inconsistency）的困境：子系统A认为用户的最新偏好是X，而子系统B基于稍早的记忆认为偏好是Y。

会话中断（Session Interruption）和恢复（Resumption）进一步加剧了这一挑战。当用户在移动设备上开始对话、在PC上继续时，系统需要正确地重建完整的上下文状态，包括隐式推断的状态（如“用户正处于产品比较阶段”）。跨设备、跨会话的状态连续性是尚未被很好解决的问题。

1.4.4 压缩保真度与自动化评估

上下文压缩的核心挑战在于保真度评估——如何判断一次压缩是否成功保留了必要信息？传统的信息论指标（如压缩比、困惑度变化）无法捕捉“任务完成度”这一最根本的标准。当前实践中，压缩质量往往依赖人工评估或间接通过下游任务表现来推断，缺少可靠的自动化评估方法。

这一挑战的深层原因在于：信息的重要性是任务依赖和上下文依赖的。在一个场景中被安全压缩掉的内容，在另一个场景中可能至关重要。通用的压缩算法难以适应所有场景的动态需求。

1.4.5 安全与隐私的上下文风险

上下文工程引入了新的安全和隐私风险维度。当外部知识被检索并加载到上下文时，注入攻击（Injection Attack）的风险随之增加。恶意构造的文档可能包含操纵模型行为的指令，而如果检索系统不加区分地加载这些内容，攻击者可能借此实现prompt injection。

隐私泄露风险同样值得警惕。上下文窗口中的信息可能被模型在后续交互中无意引用。如果记忆系统管理不当，用户的敏感信息可能被混入上下文，在某些边界情况下被模型输出。

这些技术挑战并非不可逾越，但它们的解决需要更深入的研究和更成熟的工程实践。本书后续章节将针对这些挑战逐一展开讨论，介绍当前可行的应对策略和前沿研究方向。

1.5 知识体系的逻辑架构

前文的讨论已经勾勒出上下文工程的基本轮廓。为帮助读者建立全局视角，我们将本书的知识体系架构可视化如下：

```mermaid graph TD A[上下文工程] --> B[理论基础] A --> C[核心支柱] A --> D[工程实践] A --> E[应用场