LLM 系列（十三）：解读 Context Engineering

引言

1、什么是上下文工程？

聊到与大模型（LLM）交互，你可能首先想到的是 “提示工程”（Prompt Engineering）。但今天，我们要聊一个更深、更广的概念——“上下文工程”（Context Engineering）。简单来说，如果说 提示工程 主要研究 如何巧妙地向模型提问，那么 上下文工程 则关注的是 如何为模型构建一个完整的信息环境，从而决定它在回答问题时到底 “知道些什么”。根据学术界和业界大牛们的观点，上下文工程可以被定义为：“一门设计和构建动态系统的学科，旨在为人工智能模型提供完成任务所需的所有信息和工具”。划个重点，它的目标是打造一个动态、全面的信息供给系统，而不仅仅是优化几句静态的指令。

2、为什么需要上下文工程？

Context Engineering 之所以在当前阶段的重要性被放大，其主要背景是如何更好的解决大模型自身存在的一些根本性局限问题。我们可以把这些局限归纳为以下几点：

• • 有限的上下文窗口：每个 LLM 都有一个类似计算机内存（RAM）的“工作记忆区”，也就是它的上下文窗口。这个窗口的大小是有限的，意味着模型能同时处理的信息量存在上限。在长对话或复杂任务中，信息会迅速堆积，很容易导致窗口溢出，不仅拖慢响应速度（延迟），还会让成本飙升。
• • 知识的“保质期”：LLM 的知识储备被“冻结”在了它训练数据截止的那一刻。这意味着它的信息会不可避免地过时，无法掌握最新的知识动态。而上下文工程的核心技术之一——外部知识检索，恰好能连接实时的外部信息源，从一定程度上缓解这个问题。
• • 模型幻觉：在缺少外部信息验证的情况下，LLM 有时会产生“幻觉”，也就是我们常说的“胡说八道”。上下文工程通过引入事实依据，将模型的输出“锚定”在可靠的外部知识上，从而提升其回答的准确性和可信度。
• • 残缺的“世界观”：一个不争的事实是，即便模型再强大，如果你只给它一个不完整、片面的信息视角，它的表现也会大打折扣。上下文工程的核心使命，就是针对具体任务，为模型提供一个完整、相关且及时的“世界观”，确保它掌握做出高质量决策所需的所有拼图。

上下文工程的基本原理

核心限制-无法挣脱的上下文窗口

上下文窗口是 LLM 架构中的一个根本性约束。想要玩好上下文工程，就必须先理解它的技术原理、内在缺陷，以及它所带来的性能与成本的博弈。

技术根源

上下文窗口的长度限制，主要源于 Transformer 架构中自注意力（self-attention）机制的计算复杂性。简单来说，计算量与输入序列长度（n）的平方（O(n²)）成正比。

这意味着，上下文长度每增加一倍，所需的计算资源和内存就会指数级增长。这种指数级的增长，无论在训练还是推理阶段，都构成了巨大的性能瓶颈和成本压力。尽管业界已经探索出一些优化方案（如分组查询注意力），但这个基本约束在当前主流模型中依然牢固存在。

“大海捞针”与“中间遗忘”现象

模型在上下文窗口内处理信息的能力也千差万别。比如 LLM 在处理长文本时，会表现出一种“中间遗忘”（Lost in the Middle）的现象，模型更容易记住和利用位于上下文开头和结尾的信息，而中间部分的内容则常常被忽略。这个现象在“大海捞针”（Needle in a Haystack）测试中得到了充分印证：当把一个关键信息（“针”）藏在一大堆无关信息（“草堆”）的中间时，模型很难找到它。这颠覆了 “上下文窗口越大，模型性能就越好” 的简单认知，也揭示了单纯加长窗口并不能保证性能的同等提升。

性能与成本的“跷跷板”

上下文的长度，与系统的运营成本和响应速度直接挂钩，而且通常是负相关。更长的上下文，意味着更慢的响应和更高的API调用成本（Token消耗）。这迫使开发者必须在 “提供更全面的信息以提升质量” 和 “维持可接受的用户体验及成本” 之间，做出艰难的平衡。

因此，上下文工程的核心挑战，正是在信息丰富度与系统效率之间找到那个最佳平衡点。这也解释了为什么业界对百万级 Token 上下文窗口的狂热追求，可能在某种程度上偏离了实际应用的核心。更大的窗口提供了更大的 容量，却不保证更优的 利用率，甚至可能因为引入过多无关信息而导致 “上下文干扰” 或 “上下文过载”，反而拉低了模型性能。

最初的设想是，更大的窗口能塞进更多信息，结果自然会更好。但 “中间遗忘” 等现象表明，上下文的数量与质量并非简单的正相关。同时，成本和延迟这两座大山也让开发者倾向于使用“小而美”的上下文窗口。所以，高级上下文工程的焦点，必须从简单粗暴的 “填塞提示词”，转向开发更精细化的信息检索、过滤、排序和压缩系统。其目标是为模型提供一个精炼、紧凑且高度相关的信息包。这使得动态管理上下文的技术，其重要性远超单纯依赖模型自身的窗口长度。

context 里有什么？

为了系统地设计和理解上下文，我们需要把它拆开看看。一个完整的上下文信息包，通常由以下几种不同类型的信息动态组合而成：

• • 指令（Instructions）：这部分内容定义了模型的行为框架和总体目标，包括系统提示（System Prompts）、角色定义（如“你是一个专业的医疗顾问”）和高级目标描述。
• • 用户输入（User Input）：用户直接提出的问题或命令。在交给模型前，原始输入可能会被进一步提炼或加工。
• • 对话历史（Conversation History / Short-Term Memory）：当前对话中的先前交互轮次。这是维持对话连贯性的关键。
• • 检索知识（Retrieved Knowledge）：通过实时查询从外部知识源获取的信息，如文档、数据库记录或 API 响应。
• • 工具定义（Tool Definitions）：向模型说明它可以调用哪些外部功能或 API，包括这些工具的用途和参数。
• • 工具输出（Tool Outputs）：模型调用工具后返回的结果。这些结果会成为新的上下文，供模型进行下一步思考。
• • 示例（Examples / In-Context Learning）：在提示中提供一或多个“输入-输出”的范例，用来向模型演示期望的行为或格式。
• • 记忆系统（Memory Systems）：从长期存储中召回的信息，例如跨会话的用户偏好、个人资料或历史交互记录。
• • 结构化输出模式（Structured Output Schemas）：规定模型必须遵循的输出格式，例如 JSON schema，以确保输出的结构化和可解析性。

上下文实现的核心技术

上下文工程的范畴虽然说是不限于单个 prompt 的撰写，但结构化和优化后的 prompt 仍然是构建高质量上下文的基础。

提示词结构与校准

这是上下文工程的基本功。在实际的工作中，我们会通过不通的角度来 PUA 模型，比如 使用明确的分隔符来区分上下文的不同部分；清晰地划分角色（系统、用户、助手）；使用祈使动词来精确定义任务 等等。

此外，还有一个更高级的概念叫 提示校准（Prompt Calibration）。 提示校准（Prompt Calibration） 的目标是消除因提示词的 格式、措辞或示例顺序 等因素给模型带来的内在偏见。

模型往往会因为提示词的表述问题导致结果的差异巨大，常规方式就是通过一些技术手段（如批量校准）来调整模型。

上下文学习（In-Context Learning, ICL）

ICL 通过在 prompt 在提供示例来引导模型的行为，这种方式的好处在于无需更新模型权重。

• • 零样本提示（Zero-Shot Prompting）：最基本的形式，只给指令，不给示例。
• • 少样本提示（Few-Shot Prompting）：在提示中提供少量（通常1到5个）输入输出的范例，向模型演示任务。这种方法能显著提升模型在特定任务上的表现和遵循格式的能力。
• • 动态少样本提示（Dynamic Few-Shot Prompting）：一种更智能的玩法。这里的示例不再是写死在提示里的，而是根据当前用户的提问，从一个更大的示例库中动态地、有选择性地挑出最相关的几个。这种方法可以看作是静态提示与完整RAG系统之间的一个过渡桥梁。

思维链提示（Chain-of-Thought, CoT）

CoT 是提升模型在复杂推理任务（如数学、逻辑推理）上表现的一项关键技术。

• • 机制：CoT 的核心思想是引导模型将一个复杂问题分解为一系列中间的、连续的推理步骤，模拟人类的解决问题过程 。这种分解允许模型将更多的计算资源分配到每一步，从而减少推理错误，得出更准确的结论。
• • 实现方式：CoT 可以通过两种方式实现。
  • • 零样本 CoT 通常通过在提示末尾添加一句简单的指令（如“让我们一步一步地思考”）来触发模型的逐步推理。
  • • 少样本 CoT 则是在提示中提供一个或多个包含完整推理步骤的示例，向模型明确展示如何进行分步思考。
• • 局限性：CoT 并非万灵药，它的效果与模型规模高度相关。在大型模型（如千亿参数以上）上，它能带来显著的性能飞跃；但对于小型模型，它反而可能因为生成不合逻辑的推理链条而导致性能下降。

记忆系统

由于 LLM 本身是无状态的，记忆系统是实现个性化和跨会话连续性的关键。记忆系统分为 短期记忆（会话内） 和 长期记忆（跨会话）。

img

img

短期记忆（STM）的技术实现

短期记忆管理智能体在单个会话中的 “工作记忆”

• • 暂存器（Scratchpad）：一个临时的、会话内的存储空间，用于存放智能体在执行任务过程中的中间思考、计划和观察结果。
  • • 基于工具的实现：为智能体提供 write_to_scratchpad()和read_from_scratchpad()等工具，使其能够显式地决定何时写入或读取信息。这种方法易于调试，因为记忆操作是智能体推理轨迹中的明确步骤，但会因工具执行而引入延迟。
  • • 基于运行时状态对象的实现：将暂存器作为智能体生命周期内一个持久化状态对象（如字典或类实例）的字段。开发者在每一步控制将状态的哪些部分注入到提示中，从而提供更精细的控制和更低的延迟，但代价是记忆管理与应用逻辑的紧密耦合。
• • 基于缓冲区的记忆系统：这是最常见的 STM 形式，用于管理对话历史。诸如 LangChain 之类的框架提供了多种实现策略：
  • • ConversationBufferMemory：最简单粗暴，存储完整的聊天记录。优点是简单，缺点是很快就会超出 Token 限制。
  • • ConversationBufferWindowMemory：只保留最近的k轮对话，解决了长度问题，但有丢失早期关键信息的风险。
  • • ConversationSummaryBufferMemory（混合模型）：这是一种先进的混合策略，它结合了窗口和摘要两种方法的优点。技术机制：维护一个近期消息的缓冲区，同时对超出预设 Token 限制的旧消息进行滚动摘要。当消息总长度超标时，最旧的消息会被一个（通常更小更快的）辅助 LLM 进行总结，然后并入一个不断滚动的总摘要中。这既保证了近期对话的完整性，又以压缩形式保留了长期历史的精髓。

长期记忆（LTM）的技术实现

长期记忆允许智能体无限期地 记住 信息，克服了核心模型的无状态特性。这通常通过将记忆外部化到一个可搜索的向量数据库来实现 。

• • 存储工作流（写入记忆）：
  1. 1. 交互捕获与分块：在交互后，捕获对话轮次并将其分割成语义连贯的文本块。
  2. 2. 嵌入与索引：使用嵌入模型将每个文本块转换为向量，并连同元数据（如时间戳）一起存入向量数据库。
• • 检索工作流（读取记忆）：
  1. 1. 查询嵌入：用同样的嵌入模型处理新的用户查询，得到查询向量。
  2. 2. 相似性搜索：在数据库中执行相似性搜索，找出与查询最相关的k个记忆片段。
  3. 3. 上下文增强：将检索到的记忆片段注入到 LLM 的提示中，为其提供相关的长期历史信息。
• • 提升LTM检索质量：
  • • 重排（Reranking）：在向量搜索初步召回结果后，再用一个更复杂的模型（如Cohere Rerank）对结果进行二次排序，把最相关的记忆顶到最前面，提高信噪比。
  • • 分层摘要：为了管理不断增长的长期记忆，可以采用类似“会议纪要”的递归摘要法。例如，每10条消息总结成一个“近期摘要”，每10个“近期摘要”再总结成一个“中期摘要”，以此类推，构建一个层次化的记忆系统。
  • • 向量化摘要：一种更前沿的方法是，用一个专门的摘要LLM处理长对话，然后直接从模型内部提取能够代表这段对话核心语义的向量表示并存储。这个“向量摘要”就像是对话的高度压缩的“语义指纹”，可用于后续快速恢复上下文。

动态上下文管理与优化

对于需要处理长对话或复杂任务的系统，必须采用动态管理策略来应对不断增长的上下文，以避免超出Token限制并控制成本。

上下文压缩

压缩的目的是减少上下文的 Token 数量，同时保留其核心信息。

• • LLM 作为压缩器：使用一个独立的（通常较小）的 LLM 来压缩上下文。这可以在不同粒度上进行：
  • • 令牌级：像 LLMLingua这类方法，通过分析语言模型的困惑度来识别并移除不那么重要的令牌。
  • • 句子级：训练一个模型来识别并移除与当前查询无关的整个句子。
  • • 摘要：这是一种更抽象的压缩，让LLM直接将上下文重写为更简洁的形式。
• • 迭代与锚定摘要：这是一种高效的摘要方法，它会持久化存储对话早期的摘要。当需要压缩时，只需对新增的部分进行摘要，然后与已有的摘要合并。这个过程由两个关键阈值控制：一个触发压缩的上限，和一个压缩后的目标下限。
  • • Tmax（压缩前阈值）：当总上下文大小达到 Tmax 时，触发压缩。
  • • Tretained（压缩后阈值）：压缩后，上下文被减少到 Tretained 个 Token。这两个阈值之间的差距控制着压缩的频率和激进程度。

选择性上下文过滤与剪枝

过滤与剪枝的目标是主动移除不相关或冗余的信息，而不是对所有内容一视同仁地压缩。这有助于减少噪声，让LLM专注于最关键的信息。

• • 向量相似度过滤：该技术用于修剪对话历史。历史中的每一轮消息都被嵌入。在构建新提示时，只有那些嵌入向量与当前查询向量的相似度得分高于某个阈值的历史消息，才会被包含在最终的提示中。
• • 等效性剪枝：在涉及搜索算法的复杂推理任务中（如使用 LLM 的蒙特卡洛树搜索），模型可能会生成多个语法不同但语义等效的推理步骤。专门训练的“等效性剪枝器”（EquivPruner ）模型可以识别并合并这些冗余的探索分支，从而节省大量计算资源。
• • 上下文剪枝：这是一种更直接的方法，它在每个文档块内部移除不相关的句子。剪枝模型会评估块中的每个句子与查询的相关性，并丢弃不相关的部分，从而在将上下文送入 LLM 之前 “净化” 每个文档块。

高级知识注入与代理框架

上下文工程的最终目标是构建能够主动与外部世界交互的智能代理。

图片来源：https://arxiv.org/pdf/2507.13334

工具集成与代理推理

通过在 LLM 的上下文中提供一组工具（如API、函数）及其描述，模型就获得了执行动作、获取实时数据和解决超越纯文本生成范围问题的能力。这是构建现代 AI Agent 的核心机制。

• • 基于 LLM 的路由：在复杂的智能体中，一个专用的“路由”节点可以使用 LLM 来指导工作流程。给定一个查询，路由器会根据工具的描述决定哪个信息源或工具最合适，并以结构化格式（如 JSON）输出其决策，从而有条件地将执行流引导至下一个节点。

知识图谱（KGs）

尽管基于文本的检索很强大，但它在序列化过程中常常会丢失知识图谱等结构化数据中丰富的实体关系信息。一些前沿技术正尝试将知识图谱的结构化知识直接注入LLM的上下文。

• • 核心机制：该方法利用模型将知识图谱中的实体和关系转换为向量表示，然后通过一个映射层，将这些向量“翻译”成 LLM能理解的“结构化Token”。最后，将这些“结构化Token”与用户的自然语言查询拼接在一起，作为LLM的最终输入
• • 技术优势：这种方法保留了知识的结构性，使得LLM能够进行比纯文本检索更复杂的符号推理，并且资源效率极高。

策略对比与落地挑战

如何选择上下文策略？

为 LLM 应用选择正确的上下文优化策略是非常重要的；不同的技术在成本、复杂性和适用场景上存在巨大差异。

提示工程 vs. RAG vs. 微调

这三种方法是定制 LLM 行为和知识的主要途径，它们并非相互排斥，在实际应用中常常结合使用。

• • 提示工程：通过优化输入提示来引导模型行为，不改变模型参数。
• • RAG：通过连接外部数据源来为模型提供实时、特定的知识，也不改变模型参数。
• • 微调（Fine-Tuning）：通过在特定数据集上继续训练来调整模型的参数，使其适应特定任务的风格、格式或专业知识。

权衡分析

下表提供了一个全面的决策框架，帮助从业者根据具体需求选择最合适的策略。

表1：上下文优化技术的比较分析

落地挑战与应对策略

将上下文工程系统从原型推向生产环境，会遇到一系列严峻的挑战，主要围绕数据质量、上下文管理和系统成本展开。

数据与检索质量挑战

• • “大海捞针”问题：如前所述，模型在大量无关上下文中定位关键信息的能力有限，这是系统面临的根本挑战。
• • 数据质量与预处理：“垃圾进，垃圾出” 的原则在此处体现得淋漓尽致。在企业环境中，数据质量差、格式不一、来源多样是主要障碍。因此，必须投入大量精力进行数据清洗、标准化和预处理。

上下文管理的“坑”

上下文管理系统可能会出现多种失效模式。下表总结了常见的“坑”及应对策略。

表2：常见上下文失效模式与应对策略

经济与性能

• • Token 成本爆炸：在生产系统中，高并发请求下，检索的文档和累积的对话历史所消耗的Token数量，可能导致运营成本高到无法承受。
• • 延迟过载：上下文处理流程中的每一步（检索、重排、压缩、生成）都会增加总响应时间，这对实时应用可能是致命的。这要求在响应质量和速度之间进行精细的工程权衡。

总结

本文系统地剖析了上下文工程的理论、技术和实践挑战。核心结论是：上下文工程是一个从提示词技巧到系统级架构的多层次学科，其成功落地依赖于解决数据质量、上下文管理和成本效率等一系列复杂的工程问题。整个领域的核心，都在于驾驭上下文质量、数量、成本和延迟之间的复杂权衡。

未来的系统可能将不再依赖于人工干扰介入的上下文，而是通过代码来程序化地生成、管理和交付上下文。这涉及到构建更高级别的抽象，例如：

• • 专用的上下文代理（Context Brokers）：作为系统的中枢，负责管理多代理系统中上下文的收集、验证、存储和分发。
• • 上下文图（Context Graphs）：将上下文表示为由相互连接的信息节点组成的图，而非线性的文本字符串，从而支持更复杂的知识遍历和推理。

这种转变，代表着一种架构模式的迭代更新：我们不再将 LLM 视为应用的中心，而是将其看作一个组件（类似“CPU”），嵌入到一个更大的、有状态的、具备上下文感知能力的软件架构中。