上下文工程概述：从定义到边界

第 1 章：上下文工程概述：从定义到边界

当一个用户向客服机器人描述问题时，如果对话历史中混杂着大量无关信息，模型很可能会遗漏关键细节，导致回答偏离用户需求。当一位开发者使用代码助手修复 Bug 时，如果上下文窗口被数百万行代码填满，模型要么拒绝处理，要么生成与当前任务毫不相关的建议。当一位分析师要求模型总结一份三百页的年度报告时，由于文档过长，模型只能看到开头和结尾部分，中间最关键的发现被完全忽略。这些场景并非个例，而是大语言模型（Large Language Model, LLM）在实际应用中普遍面临的核心挑战。本章将系统回答一个问题：如何系统化地设计、管理和优化大语言模型与外部信息的交互？这个问题的答案，就是上下文工程（Context Engineering）的核心所在。

1.1 现实应用中的上下文困境

理解上下文工程的必要性，最好的方式是从真实应用场景中观察它所解决的问题。本节通过三个典型场景，展示上下文管理不当如何导致应用失效，以及这些问题的共同本质是什么。

1.1.1 场景一：客服机器人的上下文迷失

考虑一个典型的在线客服机器人场景。用户张明（化名）正在与某电商平台的智能客服对话，尝试解决一个复杂的订单问题。张明首先描述了问题：“我上周订了一个背包，但收到的颜色和图片不一样。”客服机器人回应了初步的歉意并询问订单号。张明提供了订单号 A12345。接着，对话进入了一个漫长的排查过程：客服询问是否收到了错误的商品，张明确认；客服询问是否需要退款或换货，张明表示希望换货；客服询问是否有合适的尺码，张明查看了库存并选择了黑色款；客服确认了换货流程并告知预计三到五天送达。

这个看似简单的对话，实际上包含了一个复杂的上下文管理问题。在对话进行到第十轮时，张明突然补充道：“对了，这个背包是给我父亲买的，他今年七十五岁，腰不太好，我特意选了带腰垫的款式，希望退货换货的时候能注意一下。”对于人类客服来说，这个信息会被自然地关联到原始订单并传递到后续处理流程中。但对于缺乏有效上下文管理机制的模型而言，这条补充信息很可能在对话历史不断增长的过程中逐渐被“淹没”——当模型处理第十六轮或第二十轮对话时，早期的关键细节（如用户的父亲年龄、腰部问题、选择带腰垫款式的初衷）很可能已经被后续无关对话所稀释，导致模型在处理退货请求时完全忽略了用户的个性化需求。

这个场景揭示了上下文工程的第一个核心问题：信息的选择与优先级。不是所有历史信息都同等重要，模型需要在不断增长的对话历史中识别、保留和检索最相关的上下文片段。

1.1.2 场景二：代码助手的上下文过载

代码助手是另一个上下文管理挑战尤为突出的领域。以 GitHub Copilot、Cursor 或类似工具为例，当开发者在一个大型代码库中工作时，上下文窗口的容量成为硬性约束。一个拥有数百万行代码的企业级项目，其完整上下文远超任何模型的处理能力。

假设开发者李华正在修改一个微服务架构中的用户认证模块。她面对的场景是：整个项目包含 200 个代码文件，总计约 50 万行代码。她当前正在编辑的文件是 `auth_service/users/permissions.py`，需要添加一个新的权限检查逻辑。在这种情况下，最理想的上下文应该包括：当前文件的完整内容、相关的依赖模块（如 `auth_service/base/roles.py`）、最近的 Git 提交记录、以及该模块的单元测试文件。然而，如果代码助手缺乏有效的上下文管理机制，它可能会将不相关的大量代码文件塞入上下文窗口——比如无关的数据库连接代码、已废弃的旧模块、甚至完全不相关的服务代码。

这种上下文过载的后果是双重的：一方面，模型可能因为上下文超出限制而完全无法工作，现代模型虽然支持长上下文（如 GPT-4 Turbo 支持 128K tokens，Claude 3 支持 200K tokens），但处理过长的上下文会显著增加延迟和成本；另一方面，即使上下文勉强能容纳，模型在噪声过多的上下文中也更容易产生错误的推理——它可能引用错误的函数签名、误解代码的依赖关系，或者生成与当前任务无关的代码建议。

这个场景揭示了上下文工程的第二个核心问题：信息的筛选与压缩。如何在有限的上限内最大化有效信息密度，是代码助手类应用必须解决的技术难题。

1.1.3 场景三：文档分析的信息截断

文档分析是第三个典型的上下文困境场景。当用户希望大语言模型分析一份长文档时——比如一份三百页的财务报告、一份完整的法律合同、或一个完整的技术规范文档——模型的上下文窗口限制会导致严重的信息截断问题。

以财务分析场景为例。某投资机构的研究员王芳需要分析一份上市公司年报。这份年报包含约四百页内容，涵盖公司业务概览、财务报表、管理层讨论、风险因素、股东信息等多个章节。现代大语言模型的上下文窗口虽然已经显著扩展（部分模型支持 100 万 tokens 以上的输入），但在处理如此长度的文档时仍面临两个问题：第一，模型的注意力机制虽然理论上可以处理长序列，但实证研究表明，模型对长文档中间部分的信息召回率显著低于开头和结尾部分，这种现象被称为“中间丢失”（Lost in the Middle）；第二，将整份文档放入上下文会消耗大量计算资源，导致响应时间延长和推理成本攀升。

更糟糕的是，王芳的分析任务通常不是简单的文档总结，而是带有特定目标的深度分析。比如，她可能需要分析“公司过去三年应收账款周转率的变化趋势，以及这与行业平均水平的关系”。这意味着模型不仅要看到完整的文档，还需要关联特定的财务数据点、进行计算、并与行业基准进行对比。如果缺乏有效的上下文管理机制，模型很可能在处理长文档时遗漏关键的财务数据，或者无法准确关联前后文中的相关数据点。

这个场景揭示了上下文工程的第三个核心问题：信息的组织与检索。模型需要能够快速定位、提取和关联散落在长文档各处的相关信息，而不是被动地依赖序列化的文本输入。

1.1.4 问题的共同本质

上述三个场景看似分别涉及对话管理、代码处理和文档分析，但它们共享一个共同本质：信息的选择、组织与流动。具体而言：

信息的选择（Selection）涉及判断哪些信息应该进入上下文，哪些应该被丢弃或保留在外部存储中。在客服场景中，需要选择哪些对话历史是当前任务相关的；在代码场景中，需要选择哪些代码文件与当前编辑任务相关；在文档场景中，需要选择文档的哪些章节或段落与分析目标最相关。

信息的组织（Organization）涉及如何结构化地排列选定的信息，使其能被模型高效利用。上下文中的信息不是简单堆叠，而是需要考虑位置效应（开头和结尾的信息更容易被记住）、层次结构（重要信息应该突出显示）、以及关联性（相关信息应该放在一起）。

信息的流动（Flow）涉及如何管理信息的时间维度——随着任务推进，上下文需要动态更新，新信息加入、旧信息退出或降权。这要求系统具备状态管理能力，能够追踪任务进度并相应调整上下文内容。

理解这三个维度（选择、组织、流动）是把握上下文工程全貌的基础。接下来的章节将系统阐述上下文工程的定义、核心主题及其与相邻领域的区别与联系。

1.2 上下文工程的定义与核心主题

在明确现实问题之后，本节给出上下文工程的正式定义，并系统介绍其五大核心主题。这些主题构成了本书后续章节的知识骨架，也是读者在实际应用中需要掌握的核心技术领域。

1.2.1 上下文工程的正式定义

上下文工程（Context Engineering）是一种系统化设计、管理和优化大语言模型与外部信息交互的技术学科。它涵盖从信息获取、预处理、存储、组织到检索和更新的完整流程，旨在确保模型在任意时刻都能获得恰到好处的上下文支持，从而高效、准确地完成用户任务。

这一定义包含几个关键要素需要进一步解释。首先，“系统化设计”意味着上下文工程不是零散的技术技巧，而是一套有组织的原则和方法论。它需要从全局视角考虑上下文的管理策略，而非头痛医头、脚痛医脚。其次，“外部信息”是一个重要限定——上下文工程关注的是模型外部（即显式输入给模型）的信息管理，这与模型内部的参数化知识（通过预训练获得）形成对比。再次，“交互”一词表明上下文工程不仅关注单向的信息输入，还涉及信息如何随着对话或任务的推进而动态变化。

与提示工程（Prompt Engineering）的核心区别在于：提示工程关注的是如何表达指令和问题——即输入文本的措辞、格式、示例选择等；而上下文工程关注的是输入什么信息以及这些信息如何组织。举例而言，在提示工程视角下，设计一个好的系统提示（System Prompt）需要考虑角色设定、输出格式、约束条件等表达层面的问题；而在上下文工程视角下，则需要考虑应该向模型提供哪些背景信息、这些信息来自何处、如何保证其时效性和准确性等结构层面的问题。两者相辅相成：一个设计精良的提示，如果缺乏恰当的上下文支持，将如同巧妇难为无米之炊；反之，丰富的信息上下文，如果没有良好的提示引导，也可能被模型误解或低效利用。

1.2.2 五大核心主题概览

上下文工程作为一个新兴的技术学科，其内容可以归纳为五大核心主题。这五大主题相互关联，共同支撑起上下文管理的完整体系。

主题一：长上下文处理（Long Context Processing）研究如何有效利用模型支持的大上下文窗口能力。现代大语言模型的上下文窗口已经从最初的 4K tokens 扩展到 128K、200K，甚至部分模型达到 1M tokens 以上。然而，长上下文并非简单地“塞入更多文本”即可，而是需要处理注意力分散、信息召回不均、推理成本激增等问题。长上下文处理的技术包括滑动窗口（Sliding Window）、稀疏注意力（Sparse Attention）、递归处理（Recursive Processing）等，本书第二章和第三章将深入探讨这些技术。

主题二：上下文压缩（Context Compression）研究如何在保持关键信息的前提下缩减上下文长度。压缩不是简单的文本截断，而是一种智能的信息提炼过程。高级的压缩方法会保留语义精华、实体关系和关键数值，同时丢弃冗余和噪声。上下文压缩的技术包括提取式摘要（Extractive Summarization）、生成式摘要（Generative Summarization）、语义压缩（Semantic Compression）等，本书第四章将详细讨论这些技术及其适用场景。

主题三：检索增强记忆（Retrieval-Augmented Memory）研究如何通过外部知识库和检索系统来扩展模型的“记忆”能力。当上下文窗口无法容纳所有相关信息时，系统需要能够按需检索并注入相关信息。检索增强生成（Retrieval-Augmented Generation, RAG）是这一主题的核心技术范式，它涉及文档分块（Chunking）、向量嵌入（Embedding）、近似最近邻搜索（Approximate Nearest Neighbor Search）等技术，本书第五章至第七章将系统介绍这些技术。

主题四：状态管理（State Management）研究如何在多轮交互中跟踪和管理会话状态与任务进度。与静态的文档分析不同，动态任务需要模型能够记住之前的动作、中间结果和未完成步骤。状态管理涉及会话上下文维护、工作记忆建模、长期记忆存储等能力，本书第八章和第九章将探讨这些技术。

主题五：成本与性能优化（Cost and Performance Optimization）研究如何平衡上下文质量与资源消耗。上下文工程不仅是技术问题，也是经济学问题——更长的上下文、更复杂的处理意味着更高的计算成本和延迟。本主题涵盖 Token 计数优化、缓存策略、批处理、模型选择等技术，本书第十章将专门讨论这些优化实践。

这五大主题的关系可以用一个简单的框架来理解：如果将上下文管理看作一个信息管道，那么长上下文处理关注的是管道的容量上限，上下文压缩关注的是在管道中流动的信息密度，检索增强记忆关注的是信息的来源和获取方式，状态管理关注的是信息的时序演化，而成本优化则关注整个管道系统的效率。

1.3 与相关领域的对比与边界

上下文工程并非凭空出现，它与提示工程、知识图谱工程、MLOps 等领域存在密切联系，也存在重要区别。明确这些关系有助于读者理解上下文工程的独特价值主张，以及它在整个 AI 工程体系中的位置。

1.3.1 上下文工程与提示工程

提示工程是当前最广为人知的 LLM 应用优化领域，许多读者可能已经熟悉其基本概念。简要而言，提示工程关注的是如何设计输入给模型的文本指令，使其能够引导模型产生期望的输出。这包括系统提示（System Prompt）的设计、few-shot 示例的选择、输出格式的指定、思维链（Chain-of-Thought）的引导等技术。

上下文工程与提示工程的核心区别可以从两个维度来理解：关注层次和优化目标。

在关注层次上，提示工程主要在表达层工作——它关心的问题是“我如何说”才能让模型理解我的意图。例如，在设计一个翻译助手的系统提示时，提示工程师会考虑：是否需要明确指定翻译风格（如“学术论文风格”或“口语化表达”）？是否需要提供翻译示例？如何指示模型处理专业术语？这些都是关于信息如何被表达的问题。

上下文工程则在信息层工作——它关心的问题是“我提供什么信息”以及“这些信息如何组织”。延续翻译场景的例子，上下文工程师会考虑：翻译任务需要哪些背景信息（如原文的应用领域、目标读者群体、专业术语表）？这些信息应该从哪里获取？当用户提到“我上周发给你的那篇论文”时，系统如何关联到之前上传的文档？如何处理需要参考译文的场景（如翻译风格一致性要求）？

在优化目标上，提示工程的优化指标通常是输出质量——通过调整提示，使模型输出更准确、更符合格式要求、更有帮助。上下文工程的优化指标则更为多元：除了输出质量，还需要考虑信息覆盖率（关键信息是否都被纳入上下文）、上下文效率（是否在有限窗口内最大化有效信息）、计算成本（处理上下文所需的 Token 数量和推理时间）等。

两者之间也存在协同关系。良好的提示设计可以提高模型对上下文的理解效率——例如，明确指定“以下是用户之前提出的三个问题，请逐一回答”可以帮助模型更好地组织响应。反之，良好的上下文管理可以为提示创造更好的发挥基础——例如，在检索增强场景中，准确的检索结果可以被当作高质量的 few-shot 示例。理解这种协同关系，有助于在实际应用中灵活运用两种技术。

1.3.2 上下文工程与知识图谱工程

知识图谱（Knowledge Graph）是一种结构化的知识表示形式，它通过实体（Entity）、关系（Relation）和属性（Attribute）来组织知识，形成一个可推理的知识网络。例如，"上海"是一个实体，它属于“城市”类型，与“北京”具有“同为直辖市”的关系，与“长江”具有“位于入海口”的关系。

知识图谱工程（Knowledge Graph Engineering）涉及知识图谱的构建、维护和应用。这包括本体设计（Ontology Design）——定义图谱的schema结构；知识抽取（Knowledge Extraction）——从非结构化文本中提取实体和关系；知识融合（Knowledge Fusion）——整合多个来源的知识并解决冲突；知识推理（Knowledge Reasoning）——基于图谱结构进行逻辑推断。

上下文工程与知识图谱工程的关系可以概括为：知识图谱是上下文工程的一种实现手段，而非目的。具体而言，在需要复杂推理或需要精确关联实体关系的场景中，知识图谱可以作为一种高质量的上下文信息来源。例如，在一个法律咨询应用中，如果用户问“根据最近的判例，甲公司是否对乙公司的损失负有责任”，系统可能需要检索相关判例、提取法律关系、判断适用性——这一过程可以通过知识图谱来组织和加速。

然而，知识图谱并非上下文工程的唯一甚至首选方案。其局限性在于：构建和维护高质量知识图谱需要大量的人工投入，图谱的实时更新也是挑战；并非所有知识都适合图谱化表示（如模糊的常识、隐含的背景信息）；图谱的查询和使用需要专门的推理引擎，增加了系统复杂度。

因此，在实际应用中，上下文工程更常见的实现手段包括：向量检索（Vector Retrieval）——通过语义相似度搜索相关文档或段落；全文检索（Full-text Search）——基于关键词的精确匹配；数据库查询（Database Query）——结构化数据的按需提取。知识图谱在这些方法不足以满足需求的场景下，作为高精度知识表示的补充手段被引入。

1.3.3 上下文工程与 MLOps

MLOps（Machine Learning Operations）是一套将机器学习模型部署到生产环境并持续监控、维护的实践方法论。它涵盖了模型训练、模型评估、模型部署、模型监控、模型更新等完整生命周期中的工程实践。MLOps 的核心目标是确保 ML 系统在生产环境中的可靠性、可扩展性和可维护性。

上下文工程与 MLOps 的关系在于：上下文工程可以视为 MLOps 在大语言模型时代的扩展维度。传统的 MLOps 主要关注模型的训练和部署——如何高效训练模型、如何将模型上线、如何监控模型在生产中的表现。但对于基于大语言模型的应用，模型的“智能”很大程度上取决于它被输入的上下文。这使得上下文的质量成为决定应用效果的关键因素，从而催生了对上下文工程的需求。

从工作内容来看，MLOps 工程师关注的是模型层面的问题：模型版本管理、模型性能监控、模型漂移检测（Drift Detection）、模型再训练等。上下文工程师关注的是信息层面的问题：上下文构建策略、上下文质量评估、上下文更新机制、上下文与模型输出的对齐等。

两者也有交叉地带：模型选择本身就是一种上下文决策（为任务选择合适的模型，权衡上下文窗口、推理能力、成本等因素）；模型输出监控也会反过来指导上下文策略的调整（例如，如果发现模型在特定类型的上下文中表现不佳，可能需要改进上下文的组织方式）。

1.3.4 工程边界：什么放在模型内部，什么放在模型外部

明确上下文工程的边界，一个关键问题是：什么信息应该放在模型的上下文窗口中（模型内部），什么信息应该保留在外部存储中（模型外部）？

这个边界问题没有绝对的答案，它取决于多个因素的权衡。

信息的使用频率是首要考量。如果某些信息被频繁访问（比如用户的基本信息、常用设置、核心业务规则），将它们持续保留在上下文中可以减少检索开销。如果信息很少被使用，每次使用都需要从外部获取，那么持续保留可能造成浪费。

信息的时效性是另一重要因素。高度动态的信息（如实时库存、当前天气、最新股价）不适合被“固化”到上下文中，而应该每次按需获取。相对静态的信息（如公司政策、产品目录、历史数据）则可以持久存储，在需要时检索注入