# 上下文工程实践指南

## ✏️什么是上下文工程

**上下文工程的定义：是在有限的上下文窗口中，选择、组织并注入与用户输入或任务高度相关的信息，从而让大语言模型（LLM）能够在合理的边界内做出最佳推理和执行。**

上下文工程中最关键的是：**用最相关的信息填充 LLM 的上下文窗口**

如何为"用户输入"找到最相关的信息，是这个上下文工程系统的入口，也是衡量整个系统价值的核心指标，但这种"相关性"的实现并不会自然而然发生，它依赖开发者去设计、构建与优化整个系统。

### 与其他技术的区别

**与 RAG 的区别：** RAG 是上下文工程中的一个子集

**与提示词工程的区别：** 提示词工程是专注于 LLM 最前置的正确指令艺术，其主要是：在单个文本字符串中设计完美的指令集

> Karpathy的总结：人们通常将提示与日常使用中向 LLM 提供的简短任务描述联系起来。但在每个工业级 LLM 应用中，上下文工程是一门微妙的艺术和科学，它通过为下一步提供恰到好处的信息来填充上下文窗口。这是科学，因为正确地做到这一点涉及任务描述和解释、少量示例、RAG、相关（可能是多模态的）数据、工具、状态和历史记录、压缩等。太少或形式不正确，LLM 就没有正确的上下文来优化性能。太多或太不相关，LLM 的成本可能会上升，性能可能会下降。做好这一点非常不简单。而且，这也是艺术，因为围绕 LLM 心理和人们精神的指导直觉。

Karpathy的总结的链接：[https://x.com/karpathy/status/1937902205765607626?ref=blog.langchain.com](https://x.com/karpathy/status/1937902205765607626?ref=blog.langchain.com)


## ✏️为什么上下文工程重要

🌟🌟 **因为它可以帮助开发者构建真正有效的 AI 代理，为构建 Agent 提供开发方向**


## 上下文工程架构

![上下文工程架构图](../image/image%20(6).png)

上下文工程的核心由七种上下文组成，同时根据七种上下文可以延伸出来系统或者 Agent 中真正需要构建的模块是哪些，这些模块都是围绕上下文工程来构建的，这个时候我们可以知道构建 Agent 或者大模型应用时，需要哪些基础的技术。

其中最关键的，也是最特别的部分是：**相关上下文**，这个对于开发者来说是最有挑战性的，这个变动性是最大的，每一个 Agent 或许都有属于自己独特的相关上下文模块设计的架构。

### 相关上下文的应用场景

相关上下文是围绕用户输入的**背景知识**，是帮助大模型更好的回答用户输入的问题，例如：

1. **在一个编码 Agent 中**：一段代码问题是用户的输入，那么根据代码库检索到的这段用户输入相关的代码片段，代码文件，代码关系就是相关上下文
2. **在一个客服 Agent 中**：客服手册，常见问题集合，回复规范这些都可以是用户输入的相关上下文
3. **在一个医疗问诊 Agent 中**：用户输入"描述自己最近的症状"，那么用户病例、药物使用史，体检报告解释相关上下文
4. **在一个项目管理 Agent 中**：用户输入"我们项目 X 的进度怎么样"，那么项目文档，任务进度，周报等就是相关上下文

RAG 只是相关上下文实现的其中一种技术手段，其实还有更多的实现方式，例如：组合记录、标签检索，日期检索等。

相关上下文和用户记忆的获取都使用了 RAG（增强检索技术），但是它们的侧重点不同：

+ 相关上下文的侧重点是"用户输入"的相关背景知识
+ 用户记忆的侧重点是"用户"的相关数据

然而，**一个 Agent 并不需要同时使用全部七种上下文**。不同的场景、不同的目标，往往只需要其中的若干种组合就能发挥很好的效果。这需要开发者们进行选择。


## 上下文组成

![上下文组成图](../image/image%20(7).png)

上下文由以下七种类型组成：

1. **系统提示词**：遵守一些提示词工程的要求定义的提示词，例如：期望输出，结果限制，任务要求
2. **问题相关上下文**：解决和回答这个问题想要的背景知识
3. **用户记忆**：和用户相关的知识，例如：用户年龄，用户的习惯，用户的偏好等
4. **工具定义和输出**：提供相应的工具或者 MCP 给模型调用
5. **会话历史记录**：一个会话窗口的历史聊天记录
6. **结构化输出**：对于大模型输出的结果有格式的要求：例如：JSON，XML，CSV ，TSV 等
7. **用户输入**：用户在当前对话中输入的原始问题或指令，是整个上下文工程的起点