引言
毫无疑问，大型语言模型（LLM）可以做出令人惊叹的事情。但除了其内部知识库，它们极大地依赖于你提供的信息（即上下文）。上下文工程的核心，就是精心设计这些信息，使模型能够成功地完成任务。
当工程师们意识到仅仅编写巧妙的提示词不足以应对复杂应用时，这个概念逐渐流行起来。如果模型缺少某个必需的事实，它无法凭空猜出。因此，我们需要将所有相关的信息组合在一起，让模型真正理解当前任务。
“上下文工程”这一术语之所以受到关注，很大程度上源于 Andrej Karpathy 的一条广泛传播的推文，他说：
与 “提示工程” 相比，我更倾向于 “上下文工程”。人们认为提示就像日常使用 LLM 时的一小段简单任务描述，而在所有工业级 LLM 应用中，上下文工程是一门巧妙而精准的艺术与科学，要在上下文窗口中填入恰当的信息，才能引导模型完成下一步。
本文会偏向理论性，但我会尽可能简洁明了。
什么是上下文工程？
假设我收到一个请求：“嘿 Kanwal，你能写一篇关于 LLM 工作原理的文章吗？” 这就是一个指令。我可能会写出适合中等水平读者的内容。但如果受众是入门者，他们几乎理解不了；如果是专家，他们可能觉得内容过于基础或者脱离语境。
因此，我需要更多指令，例如：目标受众水平、文章长度、偏重理论还是实践、写作风格……这样才能写出真正契合读者的文章。
同样的，上下文工程意味着要为 LLM 提供一切必要信息：从用户偏好、示例提示，到检索的事实与工具输出，让它彻底理解目标。
下面是我制作的 LLM 上下文示意图：
上下文工程图解：
上下文可以包括 指令、用户画像、对话历史、工具、检索文档等 | 图片作者自制
这些元素都可以视为模型的上下文窗口的一部分。上下文工程关注的就是：哪些信息要纳入，如何组织，按照怎样的顺序呈现。
上下文工程与提示工程有何不同？
我不会让解释变得冗长。简而言之：
- 提示工程：专注于编写一个精心设计的单一提示（一个直接的问题或指令），以获取合理回答。
- 上下文工程：关注 LLM 周围的整个输入环境。
如果说提示工程是在问“我该如何提问？”，那上下文工程关注的是“我该展示给模型什么？我该如何管理这些内容，以保证它能顺利完成任务？”
上下文工程如何运作
上下文工程通常通过三个紧密衔接的环节来实现，这些环节帮助模型在恰当时机看到正确信息，从而作出更优决策。
1. 上下文检索与生成
在这一步，系统会拉取或生成与任务相关的信息，帮助模型更好地理解。包括：历史对话、用户指令、外部文档、API 结果、结构化数据等。
例如：回答 HR 问题时，可以检索公司政策文档；或使用 CLEAR 框架（简明 Concise、逻辑 Logical、明确 Explicit、可适应 Adaptable、反思 Reflective）来生成结构化提示。
2. 上下文处理
这是将所有原始信息优化给模型的阶段。包括：
- 超长上下文技术：如位置插值、内存高效注意力（grouped-query attention、Mamba 模型等），以支持处理超长输入。
- 自我改进：模型通过反思迭代提升输出质量。部分新框架甚至允许模型自我反馈、评估表现，并利用自生成与筛选的示例进行自主进化。
3. 上下文管理
这一部分关注跨会话的信息存储、更新与调用，尤其适用于客户支持或长期运行的智能体（agent）。
常用技术包括：长期记忆模块、记忆压缩、滚动缓存、模块化检索。
这里不仅要考虑放入哪些上下文，还要保证其高效、相关且实时更新。
上下文工程中的挑战与应对
设计完美的上下文，并不是简单地“多放点数据”，而是需要平衡、结构与约束。主要挑战与解决办法包括：
无关或噪音上下文（分散注意力）：过多无关信息会让模型困惑。
→ 采用基于优先级的上下文组合、相关性评分与检索过滤。延迟与资源消耗：复杂上下文会增加计算与内存开销。
→ 截断不必要的历史；部分计算下放到检索系统或轻量模块。工具与知识整合冲突（上下文冲突）：外部数据或工具输出可能存在格式或事实冲突。
→ 使用模式说明或元标签（如 @tool_output）；必要时让模型表达不确定性。多轮对话中的一致性维护：模型可能丢失事实或出现幻觉。
→ 跟踪关键信息，在适当时机重新引入。
Drew Breunig 提到的 “上下文投毒” 与 “上下文混乱” 也是重要问题，值得进一步阅读。
总结
上下文工程不再是可选技能，而是决定 LLM 能否 真正理解 的基础。
对终端用户来说，它几乎是“隐形”的，但它定义了输出是否有用、是否智能。
本文只是对其概念与工作原理的一次温和介绍。