上下文工程概述：LLM应用的核心挑战

上下文工程概述：LLM应用的核心挑战

当开发者首次尝试将大语言模型（Large Language Model, LLM）接入实际业务系统时，往往会遭遇一个共同的困境：明明模型能力强大，API调用也正确无误，但系统在实际场景中却频繁出现理解偏差、回复不一致、上下文丢失等问题。这些问题的根源不在于模型本身，而在于开发者对上下文的理解和处理方式存在根本性的不足。

上下文工程（Context Engineering）正是为解决这一问题而诞生的系统性方法论。它关注的核心问题是：如何在有限的上下文窗口内，让模型获得足够精确、足够相关、足够一致的信息来完成特定任务。这不是简单的“给模型多喂点数据”或“写好提示词”所能涵盖的——它涉及信息压缩、语义表示、检索机制、状态管理等一整套技术栈的设计与实现。

理解上下文工程，对于任何希望在生产环境中可靠部署LLM应用的开发者而言，已经成为一项核心能力。本章将系统性地建立这一领域的认知框架，为后续各章的深入探讨奠定基础。

上下文工程的定义：管理LLM输入输出的系统方法论

从"提示词工程"到"上下文工程"的认知跃迁

在2022年至2023年间，"提示工程"（Prompt Engineering）曾是LLM应用领域最热门的术语。大量教程和最佳实践聚焦于如何设计更好的指令、如何组织Few-shot示例、如何构造Chain-of-Thought推理链路。这些技术确实有效，但它们逐渐暴露出一个根本性的局限：提示工程假设上下文是给定的、可控的、静态的——而在真实应用中，上下文往往是动态的、海量的、噪声密布的。

考虑一个典型的企业知识库问答场景：用户询问“去年第三季度的毛利率相比前年同期有什么变化？”要回答这个问题，模型需要的上下文包括：财务数据的查询权限、历史报表的访问路径、相关计算公式的理解，以及对"毛利率"这一指标业务含义的掌握。这远非一个精心设计的提示词所能覆盖——它涉及多源异构数据的整合、语义层面的精确检索、以及跨请求的状态保持。

上下文工程正是在这一认知跃迁中形成的：它将关注焦点从“如何写好提示”扩展到“如何管理模型所需的信息环境”。这包括信息从外部世界进入上下文的通道（上下文构建）、信息在上下文中的组织形式（上下文表示）、模型如何从上下文中定位目标信息（上下文检索）、以及跨交互轮次的信息连续性（上下文状态）。

上下文工程的正式定义

基于上述分析，我们可以将上下文工程定义为：一个系统性管理LLM输入输出质量的方法论，涵盖上下文的获取、压缩、表示、检索、组合与状态维护，以实现特定任务场景下的模型行为可控性与结果一致性。

这一定义包含几个关键要素：

系统性意味着上下文工程不是孤立的技巧集合，而是一套有内在逻辑关联的技术体系。从信息进入系统到最终输出，每一环节都有明确的工程考量。

管理强调这是主动的设计活动，而非被动的数据堆积。开发者需要决定什么信息进入上下文、以何种形式组织、如何权衡信息量与计算成本。

输入输出质量点明了上下文工程的目标：不仅要让模型"有东西可看"，更要确保模型"看到的是正确的、相关的、有效的"。

行为可控性与结果一致性是工程化的核心诉求。在生产环境中，我们不仅要求模型能力强大，更要求它的行为可预测、它的输出稳定可靠。

上下文工程的核心假设

理解上下文工程还需要把握它的核心假设。第一个假设是信息选择假设（Information Selection Hypothesis）：在大多数实际场景中，不是信息越多越好，而是相关且适量的信息才能带来最佳性能。LLM虽然理论上可以处理长上下文，但注意力机制的实际效果会随上下文长度增加而衰减，过多的无关信息反而会稀释关键信号。

第二个假设是结构化表示假设（Structured Representation Hypothesis）：信息在上下文中的组织形式直接影响模型的理解和推理效果。同样的内容，以不同的结构、不同的粒度、不同的语义编码呈现，会产生截然不同的模型行为。

第三个假设是状态连续性假设（State Continuity Hypothesis）：多轮交互中的上下文不是独立的片段，而是需要维护跨越轮次的信息连续性。这种连续性既包括对话历史的引用，也包括隐式的实体状态、用户偏好、任务进度等非显式信息。

这些假设构成了上下文工程方法论的基石，后续章节将围绕它们展开深入的探讨。

LLM应用的三大核心挑战

在明确了上下文工程的定义之后，我们需要深入理解它所要解决的核心问题。当前LLM应用开发面临三大根本性挑战，它们相互关联又各有特点，共同构成了上下文工程必须面对的复杂性来源。

挑战一：上下文长度限制

当代主流LLM的上下文窗口已经从4K tokens扩展到128K甚至1M tokens，表面上似乎已经"足够大"。然而，当我们将目光投向实际应用场景时，这个"大"往往是个假象。

以一个中等规模的法律文档分析系统为例：一份并购协议通常在50-200页，假设平均每页1500个中文字符，转换为tokens约为3000-5000 tokens。如果需要分析整个交易历史，可能涉及数十份此类文档。再考虑对话历史、检索结果的上下文、Schema约束、输出格式要求等，系统所需的上下文总量轻松突破模型的限制。

这种长度限制带来的挑战不仅是数量层面的，更是质量层面的。即使模型支持更长的上下文，实践经验表明：当目标信息位于上下文的较深位置时，模型的召回率会显著下降。这被称为中间丢失问题（Lost in the Middle）。研究者发现，当关键信息位于上下文窗口的中间三分之一时，模型的表现往往不如位于开头或结尾。

长度限制还带来了工程层面的复杂性。超过上下文限制时，开发者需要做出选择：是截断信息、是压缩信息、还是改变检索策略。每种选择都有代价：截断可能导致关键信息丢失，压缩可能损失细节信息，改变检索策略可能影响系统的通用性。

挑战二：信息密度不均

真实世界的数据天然存在信息密度的不均衡分布。以一份产品需求文档为例：文档开头通常包含概述性的高层信息，密度相对较低；核心功能描述部分信息密度最高，包含精确的规格、约束和业务规则；而变更历史、附录等部分则可能是大量低价值的格式化文本。这种不均衡给上下文工程带来了根本性的困难：如何将高价值信息从噪声中分离出来，如何以适当的粒度呈现不同密度的内容。

信息密度不均的问题在检索场景中尤为突出。传统的向量检索返回的是与查询语义相近的文本片段，但语义相近不等于信息密度高。一个包含查询关键词但缺乏实质内容的"填充段"，其向量相似度可能高于真正有价值的内容。这导致检索结果的相关性（relevance）与信息价值（informativeness）之间存在不可忽视的偏差。

另一个层面的密度不均来自时间维度。在持续运行的系统中，新增信息会不断累积，而历史信息的价值可能随时间衰减。以客服对话系统为例：用户最近几轮对话的信息密度显然高于早期对话，但模型对上下文的处理是位置加权的（虽然理论上注意力机制应该对所有位置一视同仁，但实际中仍然存在位置偏见）。如何动态调整信息密度分布，是上下文工程必须解决的问题。

挑战三：状态管理困难

状态管理是LLM应用中最为隐蔽但影响深远的挑战。在传统软件开发中，状态管理有成熟的模式：数据库、缓存、会话存储、事务机制等。但当"状态"需要被模型理解和利用时，情况变得复杂得多。

考虑一个多轮对话的推荐系统场景：用户在第一轮说"我想找一个适合周末家庭聚会的餐厅"，系统在第二轮返回了几个建议。用户回应"不要太辣"（排除了川菜、湘菜），同时"人少一点"（影响了餐厅规模偏好），并且用户提到"孩子喜欢吃意面"（新增了关键约束）。在第三轮，用户可能说"第二个不错，但要确认一下有没有停车位"——这里的"第二个"需要准确映射到第二轮返回的第二个选项。

这种状态管理涉及多个层面：显式约束的维护（不要太辣）、隐式偏好的推断（孩子喜欢意面→家庭友好型餐厅）、指代消解（第二个→具体选项）、以及跨轮次的上下文一致性。任何一环的失误都会导致用户体验的断崖式下降。

更困难的是，LLM对"状态"的理解与我们通常的软件状态有本质不同。模型没有持久化的变量存储，没有事务回滚机制，它的"状态"完全依赖于上下文中的显式提及。这意味着当上下文因长度限制而被截断时，状态信息可能随之丢失；当前一轮的关键信息被后续信息稀释时，模型可能遗忘重要的约束条件。

三大挑战的相互关联

这三大挑战并非独立存在，而是紧密交织。长度限制迫使我们进行信息选择，而信息选择的质量直接受限于信息密度不均的挑战；被选中的信息需要有效组织以便检索，而检索的准确性又依赖于对信息密度分布的理解；最终，无论是信息选择、检索还是组合，都需要在状态管理的框架下保持连续性。

一个典型的失败案例是这样的：某电商平台的智能客服系统，在处理退换货请求时频繁出现状态丢失。用户的退货请求可能跨越多条消息，提及订单号、商品问题、期望的处理方式等。当对话历史超过上下文窗口时，早期的订单信息被截断，模型无法关联到正确的订单，导致需要用户重复描述问题。这个案例同时暴露了三个挑战：上下文长度导致历史信息丢失，信息密度不均导致关键状态信息被淹没，状态管理机制未能有效维护跨轮次的约束。

理解这三大挑战的相互关联，是设计有效上下文工程方案的前提。后续章节将分别从压缩、表示、检索、状态四个层面提出针对性的解决策略。

上下文工程技术栈的四层架构

面对上述三大挑战，上下文工程形成了一套清晰的技术栈架构。这个架构将复杂的上下文管理问题分解为四个相对独立又相互协作的层次：压缩层、表示层、检索层和状态层。每一层解决特定类型的问题，同时为其他层提供支撑。

```mermaid graph TD A[用户Query] --> B[检索层] B --> C[表示层] C --> D[压缩层] D --> E[LLM]

F[外部数据源] --> G[数据接入] G --> B

H[对话历史] --> I[状态层] I --> C

J[Schema约束] --> C

B -.-> K[相关性过滤] C -.-> L[结构化组织] D -.-> M[信息精简] I -.-> N[状态聚合] ```

压缩层：信息的精简与提炼

压缩层位于技术栈的最前端，负责将海量的原始数据转换为适合进入上下文的精简形式。这一层解决的核心问题是信息过载：如何在保留关键信息的同时，将信息量控制在模型可处理的范围内。

压缩层的策略可以分为有损压缩和无损压缩两大类。无损压缩保持信息的完整性和可恢复性，典型技术包括：去重（Deduplication）——移除重复的文本段落；格式规范化（Normalization）——统一日期、货币、计量单位等格式；结构简化——去除冗余的HTML标签、Markdown格式等。

有损压缩则允许一定程度的细节损失，以换取更高的压缩率。常见技术包括：摘要生成（Summarization）——用生成式方法提取核心内容；关键信息抽取（Key Information Extraction）——从非结构化文本中提取实体、关系、事件等结构化信息；粒度调整（Granularity Adjustment）——将细粒度描述聚合为粗粒度概念，如将"每天早上8:00-9:00的会议"简化为"早间固定会议"。

压缩层的关键设计决策在于压缩率与信息保真度的权衡。不同任务场景对这一权衡有不同的要求：法律文档分析需要高精度，容错率低，应采用较低的压缩率；对话摘要可以容忍一定信息损失，可采用较高的压缩率；实时性要求高的场景（如搜索补全）需要在压缩速度和压缩质量间取得平衡。

表示层：信息的结构化组织

表示层关注的核心问题是信息如何组织才能被模型最有效地利用。不同的组织形式会导致截然不同的模型行为，这一现象在实践中反复得到验证。

结构化表示是表示层的核心策略。与其让模型从自由文本中提取关键信息，不如将信息以模型"容易理解"的格式呈现。JSON Schema是一种常见的选择，它明确定义了字段名称、数据类型、取值范围等约束。例如，询问"张三上个月的销售业绩"时，与其让模型从大量销售记录中检索，不如预先将数据组织为：

```json { "employee": { "name": "张三", "department": "华东区", "position": "高级销售代表" }, "performance": { "period": "2024-03", "revenue": 1,250,000, "deals_closed": 23, "quota_attainment": 115 } } ```

这种结构化表示不仅降低了模型解析文本的难度，还为后续的信息组合提供了清晰的接口。

层级组织是另一种重要的表示策略。当处理复杂文档时，可以构建多层级的摘要结构：文档级摘要提供全局概览，章节级摘要提供局部上下文，段落级细节保留关键论据。这种层级结构与模型的注意力机制相契合：模型可以先在高层级定位相关区域，再在低层级获取细节信息。

语义分组则关注信息之间的内在关联。将语义相近的内容组织在一起，可以提高检索效率和信息连贯性。例如，在处理用户投诉时，将投诉内容、相关产品信息、历史处理记录等语义相关的要素聚合，而非按时间顺序线性排列。

检索层：目标信息的精准定位

检索层解决的核心问题是如何从海量信息中快速、准确地找到模型当前所需的内容。这一层在传统软件中有成熟的技术积累，但在LLM应用的场景下需要适应新的需求特点。

向量检索是当前最主流的语义检索技术。它将文本转换为高维向量，通过计算向量之间的相似度来衡量语义相关性。向量检索的优势在于语义理解能力——它能捕捉"查询"与"文档"之间的深层语义关联，而非依赖关键词匹配。

然而，向量检索并非万能。它的局限性包括：计算成本随数据规模线性增长；检索结果的可解释性差——难以解释"为什么返回这个结果"；对于精确匹配需求（如查找特定订单号）表现不佳。因此，检索层通常需要结合多种检索策略：

混合检索结合向量检索与传统的关键词检索（BM25）。当用户查询包含精确术语时，关键词检索可以提供精确匹配；当查询是模糊的语义描述时，向量检索可以返回语义相关的结果。混合检索通过加权融合两种策略的得分，在精确性与语义相关性之间取得平衡。

重排序（Re-ranking）是另一项关键策略。向量检索通常在海量候选中快速筛选，返回一个初步排序的结果集。重排序模型（如Cross-Encoder）则对候选结果进行更精细的相似度评估，考虑更多上下文信息，给出更准确的排序。重排序的成本高于向量检索，但准确性也更高，适合对精度要求高的场景。

上下文感知检索将对话历史、用户画像、任务类型等信息纳入检索考量。例如，当用户追问"那个贵一点的"时，系统需要从之前检索结果中定位到"贵"的商品，并筛选出价格较高的选项。这种跨轮次的上下文理解是普通检索无法处理的。

状态层：跨交互的信息连续性

状态层是上下文工程中最具独特性的层次，它解决的核心问题是如何在多轮交互中维护信息的连续性与一致性。

状态层的首要职责是显式状态的维护。这包括：对话上下文——之前的轮次说了什么；用户约束——用户明确提出的需求和限制；任务进度——当前任务的完成状态。这些信息需要在每一轮交互中准确传递，不能遗漏也不能混淆。

状态聚合是提升状态传递效率的关键技术。与其每次都将完整的历史对话传给模型，不如预先将历史信息聚合为结构化的状态摘要。例如，对话历史可以聚合为：

```json { "user_preferences": { "cuisine": ["意大利菜", "日本料理"], "avoid": ["辣", "海鲜"], "budget_range": "200-400元/人" }, "active_constraints": { "party_size": 4, "occasion": "家庭聚会", "accessibility": "需停车位" }, "discussed_options": [ {"id": 1, "name": "意大利农场餐厅", "status": "已排除-距离远"}, {"id": 2, "name": "�的�的寿司", "status": "候选中"}, {"id": 3, "name": "家庭时光西餐厅", "status": "候选中"} ], "task_progress": { "current_phase": "选项比较", "next_action": "确认停车位" } } ```

这种结构化状态表示将零散的历史信息组织为清晰的约束、偏好和进度，使模型能够快速把握当前情境的全貌。

隐式状态的推断是状态层的高级能力。模型不仅需要传递显式提到的信息，还需要推断和跟踪隐含的状态。例如，用户说"谢谢"可能意味着当前问题已解决，可以结束对话；用户长时间不回复可能意味着在等待某个确认。这些隐式信号的识别和利用，是提升用户体验的重要手段。

四层协作的整体架构

四个层次并非线性串联，而是形成了复杂的协作关系。压缩层为表示层提供精简后的输入，表示层为检索层提供结构化的检索对象，检索层从表示层构建的信息库中返回相关片段，状态层则贯穿始终，为各层提供上下文信息。

一个典型的信息处理流程如下：用户Query首先进入检索层，结合状态层的当前状态信息进行上下文感知的检索；检索结果经过表示层的结构化组织，转换为模型友好的格式；压缩层根据上下文容量限制，对结构化信息进行适度的精简；最终，压缩后的信息与状态层的状态摘要、Schema约束等组合，形成完整的上下文输入给LLM。

这种分层架构的优势在于关注点分离：每一层都可以独立演进和优化，只要保持接口的稳定性。例如，当新的压缩算法出现时，只需替换压缩层的实现，无需改动其他层次；当检索需求变化时，可以调整检索层的策略，而不影响下游的处理流程。

上下文工程与提示工程的区别与联系

理解上下文工程与提示工程的关系，对于把握本书的定位至关重要。两者都是提升LLM应用质量的技术手段，但关注的层次和采取的策略有本质不同。

提示工程：聚焦于"指令的设计"

提示工程的核心关注点是如何设计prompt的结构和措辞，使模型产生预期的行为。这包括：指令的清晰性和无歧义性；Few-shot示例的选择和排列；Chain-of-Thought的引导方式；输出格式的约束等。

提示工程的技术栈相对集中，主要围绕prompt模板展开。它的典型问