上下文工程Context Engineering

最近，又多了个新的概念，上下文工程，这是从提示工程发展而来的，因为随着LLM上下文的增长以及Agent能力的提升，写好一句prompt已经远远不够了，我们需要为AI Agent处理动态的上下文信息，处理得越好，Agent的能力就越强。

毕竟底层LLM都是大家就能接入的，而上下文工程，那就非常考验架构和工程能力了。

以下是上下文工程必须要了解的知识点，欢迎查看：

# Prompt 工程的局限

Prompt Engineering 是一门设计和优化提示（prompts）的技术，旨在有效利用大型语言模型（LLMs）来执行各种应用和研究任务。它主要关注如何更好地编辑提示以提高模型输出的质量。

然而，随着 LLM 上下文窗口的显著扩大（在过去两年中从 4K 增加到超过 1M tokens），Prompt Engineering 的局限性也日益凸显。其主要局限包括：

- 优化焦点不同：Prompt Engineering 主要优化的是“句子”，即你如何提问，而并非 AI 在“思考”时可以访问到的“知识”。

- 能力有限：它更像是学习如何提出好问题，无法决定读者在阅读前能接触到哪些书籍。

- 无法应对复杂系统：在早期，开发者侧重于巧妙的提示。但随着 LLM 应用变得更加复杂，提供完整且结构化的上下文远比任何“神奇”的提示更为重要。

- 难以扩展：Prompt Engineering 主要为单一输入数据集设计提示，而无法有效处理复杂的、动态生成的信息。

- 缺乏系统性考虑：它通常不涉及信息架构、数据策略和用户体验等方面的思考。

# Context Engineering 是什么

Context Engineering 被视为 Prompt Engineering 的演进和更高层次的版本。它不再仅仅是优化你如何提问，而是优化 AI 在“思考”时可以访问到的信息。

## 核心定义

- Context Engineering 是“设计和构建动态系统，这些系统能够在正确的时间、以正确的格式提供正确的信息和工具，使 LLM 能够合理地完成任务”。

- 它旨在为 LLM 的上下文窗口填充‘恰到好处’的信息，以帮助 AI 代理有效执行任务”。

- 简单来说，它优化的是 AI 在“思考”时可以访问到的所有信息。它涉及“设计和优化 LLM 和高级 AI 模型指令和相关上下文，使其能有效执行任务”。

## 与 Prompt Engineering 的关系

- Context Engineering 是 Prompt Engineering 的更高层次版本。如果说 Prompt Engineering 像学习如何提出好问题，那么 Context Engineering 更像图书馆员决定读者在阅读前能接触到哪些书籍。

- 这种转变的核心在于：不再是优化你如何提问，而是优化 AI 在“思考”时可以访问到的信息。

- Prompt Engineering 被认为是 Context Engineering 的一个子集。即使拥有所有上下文，如何将其组织到提示中仍然至关重要。

- 它超越了简单的提示，进入了更严谨的方法来获取、增强和优化系统所需知识的阶段。

## 重要性

- 随着 LLM 上下文窗口的显著扩大，Context Engineering 的重要性也随之凸显。

- 对于需要长时间运行任务的 AI 代理，以及处理大量工具调用反馈的情况，Context Engineering 至关重要。它可以避免诸如超出上下文窗口限制、增加成本/延迟或降低代理性能等问题。

- 许多 AI 代理的失败并非模型本身的失败，而是上下文的失败（context failures）。

- 它被 Cognition 公司称为“构建 AI 代理工程师的首要任务”。Anthropic 也强调，代理在数百轮对话中需要精细的上下文管理策略。

- 掌握 Context Engineering 的公司将获得巨大的竞争优势。

- 它要求开发者深入理解信息架构、数据策略和用户体验，这使得它超越了传统的 Prompt Engineering。

# 构成

上下文（Context）不仅仅是发送给 LLM 的单一提示，而是模型在生成响应之前所看到的一切。它涵盖了多种类型的信息：

1. 指令（Instructions）/系统提示（System Prompt）：定义模型在对话期间的行为，可以包括示例和规则等。

2. 知识（Knowledge）：包括事实、记忆等信息。

3. 工具（Tools）：可供 LLM 使用的工具定义，以及来自工具调用的反馈。LLM 并非直接调用工具，而是输出它想要调用的工具和参数，然后由应用程序实际执行调用并将结果放回上下文窗口。

4. 状态（State）/历史（History）（短期记忆）：当前的对话，包括用户和模型的先前响应。例如，ChatGPT 和 Claude 通过将先前的提示和输出传入上下文窗口来保持短期记忆。

5. 长期记忆（Long-Term Memory）：跨越多个先前对话累积的持久性知识库，例如用户偏好、过去项目的摘要或模型被告知要记住的事实。

6. 检索到的信息（Retrieved Information）（RAG：Retrieval-Augmented Generation）：从外部文档、数据库或 API 动态获取的相关、最新知识，用于帮助 LLM 回答特定问题或处理提示。

7. 结构化输出（Structured Output）：定义模型响应的格式，例如 JSON 对象。这对于确保模型输出的格式符合后续流程的需求至关重要。

8. 用户提示（User Prompt）：用户直接提出的即时任务或问题。

# 策略和方法

Context Engineering 方法分为四大类：写入（Write）、选择（Select）、压缩（Compress）和隔离（Isolate）：

## 写入 Context (Write Context)

指将信息保存到上下文窗口之外，以便代理在未来使用。

- Scratchpads (暂存区)：代理执行任务期间的笔记或临时记忆。例如，将计划保存到内存中，或作为文件或运行时状态对象的一部分。这有助于代理在上下文窗口超出限制时仍能保留重要信息。

- Memories (记忆)：帮助代理跨多个会话记住信息。例如，Reflexion 模型在每次代理执行后进行反思并重用这些自我生成的记忆。Generative Agents 则周期性地从过去的代理反馈中合成记忆。ChatGPT、Cursor 和 Windsurf 等流行产品都具有根据用户-代理交互自动生成长期记忆的机制。

## 选择 Context (Select Context)

指将相关信息拉入上下文窗口。

- Scratchpad (暂存区)：通过工具调用读取暂存内容，或者开发者根据需要选择性地暴露代理运行时状态的某些部分给 LLM。

- Memories (记忆)：代理需要选择与当前任务相关的记忆。这可以用于选择少样本示例（行为范例）、指令（引导行为）或事实（任务相关上下文）。通常利用嵌入（embeddings）和/或知识图谱（knowledge graphs）进行记忆索引和选择。然而，选择相关记忆是一个挑战，有时会出现意外或不希望的记忆检索，例如 ChatGPT 意外注入用户位置信息。

- Tools (工具)：通过对工具描述应用 RAG（检索增强生成）技术，根据语义相似性获取最相关的工具。这可以提高工具选择的准确性并防止模型因工具描述重叠而混淆。

- Knowledge (知识)：RAG 技术在大型生产环境中（如代码代理）被广泛用于检索外部知识。例如，Windsurf 在代码检索中结合了索引和嵌入搜索、抽象语法树（AST）解析、文件搜索、知识图谱检索和重排序等多种技术，以应对代码库规模增长时嵌入搜索的不可靠性。

## 压缩 Context (Compressing Context)

指只保留执行任务所需的 tokens。

- Context Summarization (上下文摘要)：使用 LLM 总结冗长的对话轨迹或 token 密集型工具调用。例如，Claude Code 具有“自动压缩”功能，当上下文窗口使用率超过 95% 时，它会自动总结用户-代理交互的完整轨迹。摘要可以是递归或分层的，也可以在代理设计中的特定点使用，例如后处理 token 密集型搜索工具的输出，或在代理间知识传递时减少 tokens。

- Context Trimming (上下文修剪)：通过过滤或“修剪”上下文。这可以使用硬编码的启发式规则（如移除旧消息）或经过训练的上下文修剪器。

## 隔离 Context (Isolating Context)

指将上下文进行拆分，以帮助代理执行任务。

- Multi-agent (多代理)：将任务拆分给多个子代理，每个代理拥有独立的工具、指令和上下文窗口。这种“关注点分离”的方法通常能提高性能，因为每个子代理的上下文窗口可以分配给更狭窄的子任务。然而，多代理系统也可能增加 token 使用量和协调的复杂性。

- Context Isolation with Environments (环境上下文隔离)：例如，CodeAgent 输出的代码可以在沙箱中运行，只有选择性的结果（如 token 密集型对象）被传递回 LLM。这允许在环境中隔离上下文，例如存储图像、音频等，并在需要时选择性地将其暴露给 LLM。

- State Objects (状态对象)：代理的运行时状态对象也可以作为隔离上下文的一种方式。通过定义一个模式（例如 Pydantic 模型），只有模式中指定的字段（如 `messages`）在每个代理回合中暴露给 LLM，而其他信息则保持隔离，供更选择性地使用。

# 工程师的工作流

Context Engineering 是一个迭代过程，它要求开发者：

- 深入理解信息架构、数据策略和用户体验。

- 设计和管理提示链（prompt chains）。

- 调整指令/系统提示。

- 管理提示中的动态元素，如用户输入、当前日期/时间等，并根据需要动态传递这些信息。

- 搜索并准备相关知识（RAG）。

- 进行查询增强（query augmentation）。

- 定义工具及其使用指令。

- 准备和优化少样本示例（few-shot demonstrations）。

- 管理短期和长期记忆。

- 过滤掉不必要的噪音信息