Context Engineering

Context Engineering（上下文工程）是对传统提示词工程（Prompt Engineering）的超越和系统化。它不再仅仅关注"给模型写一段什么指令"，而是关注"进入模型上下文窗口的全部信息如何被选择、组织、排序和优化"。上下文工程将提示词、检索结果、对话历史、工具定义、系统指令等所有进入模型上下文的内容视为一个完整的工程系统。

从 Prompt 到 Context

传统提示词工程聚焦于单一维度：写一段好的指令文本。但在实际的 LLM 应用中，进入模型上下文窗口的信息远不止这一段文本。它包括系统提示（System Prompt，定义了模型的行为边界和角色）、检索到的知识片段（可能多达几十个 chunk）、前几轮对话的历史（可能已经达到几千 token）、可用工具的 Schema 定义（JSON Schema 格式的函数签名）、以及用户当前的输入。这些信息被拼接在一起形成模型的完整输入，而这个拼接过程的质量直接决定了模型输出的质量。

上下文工程关注的是这个拼接过程的设计和优化。它涉及信息选择（哪些信息值得进入有限的上下文窗口）、信息排序（检索结果的排列顺序如何影响模型的注意力分布）、去重与去噪（多个来源的重复或冲突信息如何处理）、格式组织（用 Markdown、XML 还是 JSON 结构化上下文更有效）等一系列工程决策。

核心维度

信息选择与过滤

上下文窗口是有限的资源，即使在 128K 甚至 1M token 的窗口模型中，有效注意力仍然集中在窗口的头部和尾部（即"Lost in the Middle"现象）。不相关的信息不仅浪费 token 预算，还可能干扰模型的判断。上下文工程需要在有限的窗口内精准选择最相关的信息。

选择策略分为多级：第一级是检索时的相关性过滤（通过 Embedding 相似度或 BM25 分数筛选候选片段），第二级是去重（语义相似的片段只保留信息量最大的一个），第三级是冲突检测（多个片段对同一事实给出矛盾描述时，标记冲突或按来源可信度排序）。Rerank 模型（Cross-encoder）在这一环节扮演关键角色——它比 Embedding 相似度更准确地判断片段与问题的相关性，但计算成本更高，通常用于"粗筛 Top 50 → 精排 Top 5"的两阶段 pipeline 中。

信息排序与结构

上下文窗口中不同位置的"注意力权重"是不均匀的。大量研究表明，模型对窗口开头和结尾的内容关注度最高，对中间位置的内容关注度最低。这意味着将最关键的背景信息放在窗口的开头或结尾能显著提升回答质量。

结构化组织同样重要。将检索到的多个知识片段简单地用换行符拼接，与用 XML 标签包裹每条并标注来源标题和日期，模型从中提取和引用信息的能力差异明显。一个常见的实践是用 XML 或 Markdown 格式标注每条上下文的元信息：

<context>
  <document title="医保报销政策2026版" date="2026-01-15" source="gov.cn">
    参保人员在定点医疗机构发生的符合规定的住院医疗费用...
  </document>
  <document title="异地就医结算办法" date="2025-06-01" source="gov.cn">
    跨省异地就医直接结算适用于...
  </document>
</context>

这种结构化的好处在于：模型可以精确引用特定文档（"根据 2026 年 1 月的医保报销政策..."），而非笼统地声称"根据相关资料"。结构化标注也为后续的引用验证（Citation Verification）提供了基础——当模型声称引用了某份文档时，可以事后检查该文档是否确实在上下文中，以及其中的信息是否与模型的陈述一致。

缓存与复用

在多轮对话中，系统提示和工具定义这些"静态"部分在每轮中都是相同的，但大部分 LLM API 的上下文处理方式要求每轮都把完整的上下文重新发送。Prompt Caching 技术通过在 API 层面缓存上下文的前缀部分来减少延迟和成本。上下文工程需要考虑哪些内容适合被缓存（稳定的、跨轮次不变的），哪些内容在每轮中动态变化（用户最新输入、新检索到的知识），并将静态内容集中放在窗口的前缀位置以最大化缓存命中率。

压缩与摘要

当对话历史积累到接近上下文窗口上限时，需要执行压缩。全量清空会丢失所有对话记忆，粗暴地截断最早的消息可能丢失关键信息。上下文工程的做法是：将早期的对话自动摘要为一段简洁的背景描述，保留最近几轮的完整消息。摘要的质量直接影响后续对话的连贯性——如何在不丢失关键决策和约定的前提下压缩历史，是一个需要持续工程投入的问题。

压缩的完整工程体系——触发时机（固定阈值/异步后台/语义边界）、三种压缩层次（截断/滑动窗口/摘要）、分层组合策略（L0 原文 + L1 轻摘要 + L2 背景摘要）、与 KV Cache 的交互——见上下文压缩。

与传统提示词工程的关系

上下文工程不是提示词工程的替代，而是它的外围扩展和系统化。提示词本身仍然是上下文中最关键的组成部分之一——好的系统提示定义了模型的"人格"和行为约束。上下文工程关注的是系统提示之外的那些"变动部分"的管理：知识检索的多级过滤、对话历史的压缩策略、工具定义的合并与去重、以及结构化的上下文编排。

从技能层次来看，团队中通常需要一位"上下文工程师"来负责整个上下文的编排流程——这是一个结合了信息检索、数据工程和 LLM 行为理解的复合角色。提示词的编写只是这个流程中的一个环节，而不是全部。