上下文工程概论：重新思考人机交互的边界

上下文工程概论：重新思考人机交互的边界

当GPT-3的16,385个token上下文窗口在2020年看起来几乎是“无限”的时候，很少有人预见到仅仅三年后，模型需要处理数百万token的场景会成为工程实践中的常态。这个从“够用”到“不够用”再到“过度充裕”的转变过程，揭示了人工智能应用领域一个根本性的认知偏差：人们倾向于将模型的上下文窗口视为一个纯粹的技术参数，而忽视了围绕它的工程复杂性本身构成了一门独立的学科。当一个法律AI系统需要同时分析数百份合同条款时，当一个医疗助手必须整合患者数年的病史记录时，当一个对话代理要在长程交互中保持一致的人格特征时——这些场景的核心挑战都不在于模型“能不能”处理这些信息，而在于我们“如何组织”和“如何提供”这些信息。这个根本性的认知转变，正是上下文工程（Context Engineering）作为学科诞生的起点。

上下文窗口：从有限到无限的演进之路及其工程启示

理解上下文工程的必要性，必须从上下文窗口的技术演进说起。上下文窗口定义了大型语言模型在单次推理过程中能够“看到”的最大 token 数量——这些 token 包括用户的输入提示、对话历史以及模型生成的先前内容。2019年GPT-2发布时，其最大上下文窗口仅为1,024个token，这个规模大约相当于一篇中等长度文章的四分之一。站在当时的角度，这个限制看起来相当充裕，因为大多数对话交互远不会触及这个边界。然而，正是这种表面上的充裕掩盖了一个关键事实：模型的能力从未真正受到上下文窗口本身的制约，而是受到我们如何高效利用它的制约。

2020年GPT-3将上下文窗口扩展至2,048 token，随后2022年的Claude 1将这个数字提升至9,000 token左右。这一阶段的扩展开始暴露出一个重要现象：当上下文窗口足够大时，简单的“把所有相关信息都塞进去”的策略会遭遇根本性的失效。大规模上下文引入的位置编码衰减问题、信息检索的“中间丢失”（lost in the middle）问题、以及推理成本随上下文长度的非线性增长问题，都在这个阶段被研究者系统性地记录下来。Anthropic在2022年发表的研究表明，当关键信息位于上下文窗口的中间位置时，模型的召回率显著下降——这一发现对后来上下文工程策略的设计产生了深远影响。

2023年至2024年的军备竞赛将上下文窗口推向了新的量级。GPT-4 Turbo支持128K token，Claude 3支持200K token，而Gemini 1.5 Pro更是将这个数字提升至100万token。从表面看，这种扩展似乎应该彻底解决上下文工程的核心挑战——当模型能够“看到”一整本书、一千份文档、或整个代码库时，为什么还需要复杂的工程策略？答案在于一个被广泛忽视的非线性关系：推理成本、延迟、以及模型在超长上下文中的信息利用效率，都随着上下文长度的增加而呈现非线性恶化。更根本的是，即使上下文窗口在技术上“足够大”，人类用户和组织在实践中面临的信息管理挑战——如何选择、排列、优先排序、以及同步来自不同来源的信息——远远超出了单纯增加窗口大小能够解决的范围。

这种演进历程为上下文工程提供了三条核心启示。第一，有限性是常态而非例外——无论上下文窗口扩展到多大，总存在一个边界，超过这个边界后模型性能或工程效率会出现显著下降。第二，上下文窗口的技术极限与有效利用的工程极限往往不同步——模型可能支持100万token，但我们的应用场景可能在10万token处就已经遭遇信息过载。第三，上下文窗口的扩展并不消除上下文工程的必要性，而是改变了它的表现形式——从早期的“如何压缩信息以适应限制”演变为“如何在充裕空间中高效组织和检索信息”。

狭义上下文与广义上下文：本质区别与联系

在深入讨论上下文工程的策略之前，必须建立一个精确的概念区分。狭义上下文（narrow context）指的是模型输入序列的严格边界——即进入模型 transformer 结构进行计算的所有 token 的集合。当我们说“GPT-4的上下文窗口是128K tokens”时，我们谈论的就是这个狭义上下文。它的本质特征是：所有进入这个窗口的信息都以相同的方式被处理——无论是用户刚刚输入的一句话，还是三天前对话中的某个细节，在模型的注意力机制面前享有同等的“被看到”的机会（尽管实际效果因位置和内容而异）。

广义上下文（broad context）的概念则远超出这个技术边界。它涵盖了与当前任务相关的所有信息维度：用户的历史交互记录、来自外部知识库的检索结果、用户画像和偏好设置、系统级的状态信息、甚至当前对话发生时的情境信息。广义上下文的核心洞见在于：模型能够处理的信息（狭义上下文）与模型“应该”处理的信息（广义上下文）之间存在巨大的鸿沟。这个鸿沟不是模型能力的问题，而是信息组织和呈现方式的问题。

考虑一个具体的类比：狭义上下文像是会议桌的物理尺寸——它决定了最多能坐多少人；广义上下文则像是会议准备的质量——无论桌子多大，一场准备不充分的会议仍然会失败。当一个AI系统被要求“分析这份法律合同中的潜在风险”时，狭义上下文只包含这份合同的文本本身，而广义上下文可能需要包括：客户的行业背景、类似纠纷的历史判例、当前监管环境的最新变化、律师团队的偏好和关注重点、以及之前与该客户交互中形成的特殊约定。缺少这些广义上下文信息，模型可能在技术上是“正确的”，但在实践上是“无用的”。

理解这两种上下文的区别与联系，对于设计有效的上下文工程系统至关重要。狭义上下文是工程实现的约束边界——它的技术限制（token 数量、计算成本、延迟要求）直接决定了我们在广义上下文层面必须做出的选择和权衡。广义上下文则是工程设计的目标空间——它定义了“正确完成这个任务”所需的所有信息维度，而上下文工程的核心任务就是在这两个空间之间建立高效的映射关系。

上下文工程的五大支柱：压缩、摘要、检索、记忆、状态

在明确了上下文工程的定义和上下文的两种形态之后，可以进入其核心方法论层面。上下文工程作为一门学科，其技术体系可以分解为五个相互关联的支柱：压缩、摘要、检索、记忆、和状态管理。这五个支柱并非相互独立的技术模块，而是一个有机的方法论体系，它们共同回答了一个根本问题：如何在给定的狭义上下文约束下，最大化广义上下文信息的有效传递。

压缩（Compression） 是上下文工程最直观的支柱。它的目标是将大量原始信息转换为更紧凑的表示形式，同时尽可能保留对当前任务有意义的信息。压缩的重要性源于一个基本的工程约束：token 是有成本的——不仅是直接的计算成本，还包括延迟、模型注意力分散、以及“信息淹没”效应。当一份100页的合同以原始文本形式进入上下文时，模型需要处理大量对当前任务可能是“噪声”的内容（如标准条款的冗长表述），这些噪声会稀释真正重要的信号。

压缩策略可以分为有损压缩和无损压缩两大类。无损压缩试图在保持信息完整性的前提下减少表示长度，这在代码、表格等结构化数据场景中尤为重要。例如，将JSON格式的配置文件转换为更紧凑的表示形式，或将重复的代码模式进行抽象。有损压缩则主动丢弃对当前任务可能不重要或低价值的信息——例如，在分析合同风险时，将合同中大量例行公事式的陈述简化为“标准服务协议，含常规责任限制条款”。有损压缩的核心挑战在于判断“什么可以丢弃”：这需要结合任务类型、用户意图、以及领域知识来做出复杂的权衡。

摘要（Summarization） 是压缩的一种特殊形式，其独特之处在于它不仅仅减少信息量，还试图提取和凝练信息的“精华”。与简单的文本压缩不同，摘要需要模型进行一定程度的语义理解和推理——识别文档的核心主张、关键数据点、重要结论，并将它们以连贯的短文本形式重新表达。摘要技术可分为抽取式（直接提取原文中的关键句子或段落）和生成式（理解后重新组织语言）。在上下文工程中，摘要扮演着双重角色：一方面，它是将长文档纳入狭义上下文的必要手段；另一方面，它也是信息价值评估的一种形式——能够被有效摘要的信息往往具有较高的信息密度和结构化程度。

检索（Retrieval） 是连接广义上下文与狭义上下文的桥梁。在大多数实际应用场景中，我们无法将所有可能相关的信息都放入上下文窗口——既因为它们可能超出容量限制，也因为这样做会引入过多噪声。检索系统的核心功能是：从大规模的外部信息源（文档库、知识图谱、数据库、网页等）中，动态地找到与当前任务最相关的信息片段，并将它们插入狭义上下文。检索的质量直接决定了上下文工程系统的上限——如果检索返回了不相关的信息，那么无论后续的压缩和摘要做得多好，最终效果都会大打折扣。

检索技术的演进经历了从关键词匹配（TF-IDF、BM25）到语义检索（基于嵌入向量的相似度搜索）再到混合检索（结合关键词精确性和语义相关性）的过程。上下文工程中的检索面临一个独特的挑战：相关性判断必须考虑上下文窗口的当前状态。例如，用户在多轮对话中询问“这个条款的修改建议”，检索系统不仅需要理解“条款”和“修改”这些关键词，还需要结合对话历史判断用户指的是哪份合同、哪个条款、以及用户关注的修改方向。这种上下文感知的检索是现代RAG（检索增强生成）系统的核心技术难点。

记忆（Memory） 支柱解决的是信息跨时间持续存在的问题。与检索不同，记忆不是从外部来源获取信息，而是管理和维护模型“已经知道”的信息。在长程交互场景中，记忆系统需要处理多种类型的信息：对话历史中的关键事实、用户的长期偏好和约束条件、之前任务中建立的约定、以及累积的上下文理解。记忆系统的核心挑战在于选择性——不是所有历史信息都值得被记住，也不可能记住所有历史信息。

记忆管理策略可分为前馈式和反馈式两类。前馈式策略在交互开始前就决定什么信息值得记忆，如用户画像、固定配置等“静态”信息。反馈式策略则根据交互过程中的反馈动态调整记忆内容——例如，当模型在某次回复中出现事实错误时，系统可能选择记录这个错误以避免未来重复；而当用户对某个话题表现出明显兴趣时，系统可能强化与该话题相关的信息记忆。现代上下文工程系统越来越强调记忆的可塑性和层次性——不同类型的信息应该有不同的记忆强度和遗忘机制。

状态（State） 支柱关注的是系统在特定时刻的完整运行状态。状态管理的范围远超记忆——它不仅包括“知道什么”（信息层面），还包括“正在做什么”（任务层面）和“整体环境如何”（系统层面）。在一个复杂的AI工作流中，状态可能包括：当前正在执行的任务步骤、对中间结果的假设和推理链条、与用户交互的节奏和模式、以及与其他系统组件的同步状态。

状态管理的核心挑战在于一致性和同步。当一个上下文工程系统涉及多个处理阶段（如先检索、再压缩、最后生成）时，不同阶段看到的状态可能存在偏差。状态持久化也是一个关键问题——当系统需要暂停和恢复、或在多个会话之间保持连续性时，如何确保状态的完整性和可用性。状态压缩（将复杂状态编码为紧凑表示）和状态检索（在新上下文中快速恢复相关状态）是这个支柱的两个核心技术方向。

这五大支柱之间的关系可以用一个简单的框架来理解：检索从外部来源获取原始信息，记忆管理已获取信息的长期保留，压缩和摘要对信息进行提炼和组织，状态管理确保系统在各处理阶段的协调一致。它们共同构成了上下文工程的方法论基础，而后续章节将对每个支柱进行深入的技术探讨。

```mermaid graph TD A[广义上下文信息] --> B[检索 Retrieval] B --> C{相关性判断} C -->|相关| D[信息保留] C -->|不相关| E[信息过滤] D --> F[记忆 Memory] F --> G[状态 State] A --> H[压缩 Compression] H --> I[摘要 Summarization] I --> G G --> J[狭义上下文] J --> K[模型生成] K --> L[输出响应] L -->|反馈| F L -->|反馈| B

style A fill:#e1f5fe style J fill:#fff3e0 style K fill:#e8f5e9 style L fill:#f3e5f5 ```

典型失败案例：缺乏系统性上下文工程的后果

理论框架的必要性往往通过反面案例最能体现。以下三个典型场景分别展示了上下文工程缺失在不同领域造成的具体后果，每个案例都揭示了不同的系统性缺陷。

案例一：法律文档分析中的信息遗漏

某知名法律科技公司在2023年部署的合同审查AI系统遭遇了一次严重的客户投诉。该系统被用于帮助一家中型企业审查其供应商合同，目标是识别潜在的法律风险和不平等条款。在测试阶段，系统表现良好——它准确地标记了多个风险条款，包括不合理的违约金条款、单方面终止权、和知识产权归属模糊等问题。然而，在正式部署后，系统却遗漏了一个至关重要的条款：供应商提供的服务涉及客户的专利技术，而合同中包含了一个将相关改进技术反向授权给供应商的条款。这个条款将对客户的长期技术竞争力造成严重损害。

事后的技术复盘揭示了问题根源。该合同总长度为47页，超过60,000个token，远超当时系统设定的30,000 token处理限制。当合同被截断以适应上下文窗口时，重要的知识产权条款恰好位于被截断的部分。更关键的是，系统在截断时缺乏对合同结构的语义理解——它只是简单地按页面顺序截取前半部分，而没有优先保留通常位于合同末尾的知识产权、保密和专利相关章节。

这个案例暴露了两个层面的上下文工程缺陷。首先是信息选择问题：系统没有能力智能地判断文档的哪些部分对当前任务最重要，而是采用了简单的长度截断策略。其次是结构感知缺失：法律文档具有高度结构化的特征——标题、章节、条款编号——但系统将它们视为普通文本，没有利用这种结构信息来指导信息优先级排序。这个案例促使该公司重新设计了文档处理流程，引入文档结构解析、多阶段摘要生成、以及基于任务类型的信息提取策略。

案例二：医疗诊断系统中的上下文混淆

2024年初，美国一家医疗AI初创公司的AI辅助诊断系统在一家诊所进行了试点部署。该系统旨在帮助医生整理和分析患者的病历信息，生成初步的诊断建议。在试点初期，医生们对这个系统持积极态度——它能够快速汇总患者多年的就诊记录、检查结果、用药历史等信息，大大减少了医生阅读病历的时间。然而，两周后发生的一起事件让这个试点戛然而止。

一位老年女性患者因持续性头痛就诊。医生向AI系统询问“可能的诊断方向”，系统给出了包括偏头痛、紧张性头痛、高血压相关头痛等多个常见原因的列表，并建议进行相关检查。然而，当医生进一步询问“基于该患者病史的特殊考虑”时，AI系统犯了一个致命的错误：它将另一位同名患者的抑郁症病史和自杀未遂记录混入了当前患者的上下文中。结果是，AI系统“不必要地”建议考虑颅内肿瘤的可能性（因为该“另一患者”有此家族史），并建议进行昂贵的影像学检查，而完全忽视了真正应该考虑的方向——药物副作用导致的头痛（该患者最近更换了一种血压药物）。

事后的调查发现，问题出在患者ID的匹配机制上。当医生在电子病历系统中搜索患者姓名时，系统中存在两个同名患者的记录，而AI系统在从数据库检索历史记录时，使用了简单的姓名匹配而没有进行严格的ID校验。此外，在将多次就诊记录汇总时，系统没有有效区分不同就诊记录之间的时间线，导致不同患者的记录被错误地交织在一起。

这个案例揭示了上下文工程在医疗场景中的特殊挑战。首先是准确性要求的极端性——在医疗场景中，错误信息的危害远超其他领域，一处细节的混淆可能导致误诊。其次是数据来源的复杂性——医疗数据来自多个异构系统（门诊、住院、检验、影像等），每个系统有自己的数据格式和标识符，跨系统整合时极易引入错误。第三是上下文纯度的重要性——在医疗场景中，混淆来自不同患者的信息是绝对不可接受的，这要求上下文工程系统具有严格的信息隔离和验证机制。这个案例推动了医疗AI领域对“上下文纯净性”（contextual fidelity）概念的重视。

案例三：对话系统中的身份遗忘

2023年底，某大型科技公司推出的AI个人助理在社交媒体上引发了大量用户投诉。问题出在一个看似简单的功能上：用户可以创建自定义的“人格设置”，定义AI在对话中的称呼、说话风格、知识背景等个性化参数。然而，许多用户发现，当对话持续较长时间（超过50-100轮）或跨天继续时，AI开始“忘记”这些自定义设置——它会忘记用户给它起的名字，开始使用默认的称呼；或者忘记用户设定的正式/非正式风格，语气变得不一致；更严重的是，AI有时会混淆不同用户的设置，将用户A的偏好“传染”给用户B。

技术团队在排查后发现，问题出在系统的记忆管理策略上。该系统使用了一种基于“重要性评分”的记忆淘汰机制：当上下文窗口接近容量限制时，系统会评估对话中各信息的重要性，删除得分最低的内容。问题在于，这种重要性评估是基于当前的对话内容动态计算的——当用户长时间讨论某个话题时，与该话题无关但同样有价值的信息（如人格设置）的评分会下降，导致它们被错误地标记为可删除的低价值信息。此外，在多用户场景下，系统没有为不同用户的设置建立清晰的隔离边界，导致了跨用户的信息污染。

这个案例的启示在于，记忆管理不能仅仅依赖通用的重要性评估——不同类型的信息具有不同的“生命周期”和“价值衰减模式”。人格设置这种元信息应该具有更长的持久性，即使在当前对话的相关性评分很低，也不应该被轻易淘汰。同时，多用户场景下的状态隔离是一个容易被忽视但至关重要的安全要求。这个案例促使该公司重新设计了记忆管理的层次结构，为不同类型的信息设置了不同的淘汰策略和保护机制。

三个案例共同揭示了一个核心规律：上下文工程失败的后果不是均匀分布在所有场景中的——在准确性要求高、信息来源复杂、长程交互频繁的应用场景中，失败的后果会被急剧放大。这不是模型能力的问题，而是我们如何组织和管理上下文信息的问题。

上下文工程与模型能力的边界：什么应该由模型处理，什么应该由工程解决

在建立了上下文工程的概念框架和技术体系之后，一个根本性的问题浮现出来：在给定的AI应用场景中，哪些能力应该依赖模型本身，哪些应该通过工程手段来解决？这个问题之所以关键，是因为对它的不同回答会导致截然不同的系统架构和开发策略。错误地将应该由工程解决的问题交给模型，不仅会浪费计算资源，还可能导致系统行为的不稳定和不可预测；反之，错误地将应该由模型处理的任务交给工程，则会引入不必要的复杂性和信息损失。

模型擅长的任务类型相对清晰。第一，模型在语义理解和推理方面具有显著优势——给定足够清晰的上下文，它能够理解复杂的自然语言描述，进行逻辑推理，识别隐含关系和假设。第二，模型在开放式文本生成方面表现出色，能够根据上下文生成连贯、相关、有创意的文本输出。第三，模型在少样本学习方面具有灵活性——能够从上下文中提供的示例快速适应新任务。第四，当信息已经“恰好”出现在上下文中时，模型能够准确