---
type: 教程
status: 已发布
level: 进阶
topic:
  - 上下文工程
  - 项目实战
  - 基础模型
---

# 上下文工程完全指南:设计控制信息流向LLM的系统

> **核心理念**: 上下文工程是设计架构的学科,在正确的时间向LLM提供正确的信息。这不是改变模型本身,而是构建连接模型与外部世界的桥梁。

## 目录

- [什么是上下文工程](#什么是上下文工程)
- [核心组件](#核心组件)
  - [1. Agents - 决策大脑](#1-agents---决策大脑)
  - [2. Query Augmentation - 查询增强](#2-query-augmentation---查询增强)
  - [3. Retrieval - 检索系统](#3-retrieval---检索系统)
  - [4. Prompting Techniques - 提示技巧](#4-prompting-techniques---提示技巧)
  - [5. Memory - 记忆系统](#5-memory---记忆系统)
  - [6. Tools - 工具集成](#6-tools---工具集成)
- [总结](#总结)

---

## 什么是上下文工程?

每个使用大语言模型(LLM)构建应用的开发者都会遇到同样的瓶颈。你从一个强大的模型开始,它能够写作、总结、推理,表现出惊人的能力。但当你尝试将其应用到现实世界的问题时,裂缝就开始出现:

- 无法回答关于你私有文档的问题
- 不知道昨天发生的事件
- 当不知道答案时会自信地编造

**问题的本质不在于模型的智能,而在于它从根本上是断开连接的。**

这种隔离是其核心架构限制的直接结果:**上下文窗口**。上下文窗口是模型的活动工作内存——保存当前任务指令和信息的有限空间。每个字、数字、标点符号都会消耗这个窗口中的空间。就像白板一样,一旦满了,旧信息就会被擦除以为新指令腾出空间,重要细节可能会丢失。

![上下文工程系统架构](../../figures/context-engineering-system.png)

这个流程图展示了**智能 Agent 系统的工作流程**，包含用户交互、记忆管理、Agent 决策、工具调用等环节，步骤如下：

### 1. 核心模块

- **User（用户）**：发起请求的主体。
- **Input（输入）**：接收用户请求的入口。
- **Agent（智能代理）**：系统的核心决策单元。
- **Short-Term Memory（短期记忆）**：存储对话上下文（聊天历史）。
- **Long-Term Memory（长期记忆）**：包含 MCP（可能是记忆管理组件）和数据库，用于长期信息存储。
- **RAG（检索增强生成）**：通过向量搜索从长期记忆中调取信息。
- **Action Tools（行动工具）**：Agent 可调用的功能工具（如代码、日程等）。
- **Prompt（提示词）**：承载请求、上下文的指令载体。
- **Answer（回答）**：最终反馈给用户的结果。

### 2. 工作流程（按数字步骤）

1. **用户发起请求**：用户将需求发送到 Input 模块。
2. **输入传递给 Agent**：Input 把请求转发给 Agent。
3. **Agent 决策**：
    - 若需要外部信息，触发 RAG 从长期记忆的数据库中做向量检索；
    - 若需要执行操作，调用 Action Tools。
4. **工具返回结果**：Action Tools 将操作结果回传给 Agent。
5. **更新提示词**：Agent 把结果整合到 Prompt 中，补充上下文。
6. **生成回答**：Agent 基于整合后的信息生成 Answer。
7. **存储短期记忆**：对话上下文被存入 Short-Term Memory，用于后续交互。
8. **更新长期记忆**：最终回答被添加到 Long-Term Memory，沉淀为长期知识。

这个流程体现了智能 Agent“**接收请求→决策调用资源→整合信息→生成反馈→沉淀记忆**” 的完整逻辑，同时结合了短期上下文和长期知识库，提升了交互的连贯性与信息的丰富度。

你无法仅通过编写更好的提示来修复这个根本限制。**你必须围绕模型构建一个系统。这就是上下文工程。**

---

## 核心组件

上下文工程由6个核心组件组成,每个组件解决LLM应用中的特定挑战:

### 1. Agents - 决策大脑

**定义**: 编排如何以及何时使用信息的决策系统。


#### 什么是Agent?

在大语言模型的上下文中,AI Agent是一个能够:

1. **动态决策信息流**: 基于学到的内容决定下一步做什么,而不是遵循预定路径
2. **跨多次交互维护状态**: 记住已完成的事情并使用历史信息指导未来决策
3. **自适应使用工具**: 从可用工具中选择并以未明确编程的方式组合它们
4. **基于结果修改方法**: 当一种策略不起作用时,可以尝试不同的方法

#### Agent架构类型

**单Agent架构**:
- 尝试自己处理所有任务
- 适用于中等复杂度的工作流


**多Agent架构**:
- 在专门的Agent之间分配工作
- 允许复杂的工作流但引入协调挑战


#### 上下文窗口的挑战

LLM具有有限的信息容量,因为上下文窗口一次只能容纳这么多信息。每次Agent处理信息时,它都需要做出关于:

- 哪些信息应该保持在上下文窗口中活跃
- 哪些应该外部存储并在需要时检索
- 哪些可以总结或压缩以节省空间
- 为推理和规划保留多少空间
#### 常见的上下文错误类型

**上下文污染(Context Poisoning)**:
- 错误或幻觉信息进入上下文
- 因为Agent重用和构建该上下文,这些错误会持续并复合

**上下文干扰(Context Distraction)**:
- Agent被过多的过去信息(历史、工具输出、摘要)负担
- 过度依赖重复过去的行为而不是新鲜推理

**上下文混乱(Context Confusion)**:
- 不相关的工具或文档挤满上下文
- 分散模型注意力并导致使用错误的工具或指令

**上下文冲突(Context Clash)**:
- 上下文中的矛盾信息误导Agent
- 使其陷入冲突假设之间
#### Agent的核心策略和任务

Agent能够有效编排上下文系统,因为它们能够以动态方式进行推理和决策:

1. **上下文总结**: 定期将累积的历史压缩成摘要以减少负担同时保留关键知识
2. **质量验证**: 检查检索的信息是否一致和有用
3. **上下文修剪**: 主动删除不相关或过时的上下文
4. **自适应检索策略**: 当初始尝试失败时重新制定查询、切换知识库或改变分块策略
5. **上下文卸载**: 将细节存储在外部并仅在需要时检索
6. **动态工具选择**: 只过滤和加载与任务相关的工具
7. **多源综合**: 组合来自多个源的信息,解决冲突并产生连贯的答案

1. **监督者统筹**：
    
    - 用户请求先到监督者层的`Planning`模块，规划任务后，通过`Route to Specialized`分配给专业 Agent。
2. **专业 Agent 执行**：
    
    - `Query Rewriter`：优化用户的原始查询（让请求更精准）；
    - `Data Collection Selector`：选择数据收集的方式；
    - `Retriever`：发起检索请求，从外部知识源获取信息；
    - `Tool Router`：调用工具 / API 执行操作；
    - `Answer Synthesizer`：整合所有信息，生成初步回答。
3. **记忆层支撑**：
    
    - 短期记忆：`Compressor`压缩对话上下文，存入`Working Memory`（工作记忆），为回答提供交互语境；
    - 长期记忆：`Vector DB Episodic and Factual Store`存储长期知识，同时同步工作记忆的信息，沉淀为持久化内容。
4. **知识源与工具调用**：
    
    - 外部知识源（`Vector DB知识库`、`Web搜索API`）提供检索信息；
    - `Tools and APIs`提供功能操作，结果回传给系统。
5. **生成最终回复**：专业 Agent 将合成的回答 + 记忆上下文，最终反馈给用户。
    

这个流程的核心是 “**分层协作 + 资源整合**”—— 监督者负责全局调度，专业 Agent 负责细分任务，记忆层保障上下文连贯，外部资源提供信息 / 工具支持，最终高效生成精准回答。

---

### 2. Query Augmentation - 查询增强

**定义**: 将混乱、模糊的用户请求转换为精确、机器可读意图的艺术。


上下文工程中最重要的步骤之一是如何准备和呈现用户的查询。有两个主要问题需要考虑:

1. **用户通常不以理想方式与聊天机器人交互**
   - 现实世界中的用户交互可能不清楚、混乱且不完整
   - 需要实现处理所有类型交互的解决方案

2. **管道的不同部分需要以不同方式处理查询**
   - LLM理解良好的问题可能不是搜索向量数据库的最佳格式
   - 需要一种适合不同工具和步骤的查询增强方法

#### 2.1 查询重写(Query Rewriting)

将原始用户查询转换为更有效的检索版本。


**工作原理**:
- **重构不清楚的问题**: 将模糊或形式不佳的用户输入转换为精确、信息密集的术语
- **上下文移除**: 消除可能混淆检索过程的无关信息
- **关键词增强**: 引入常见术语以增加匹配相关文档的可能性

#### 2.2 查询扩展(Query Expansion)

从单个用户输入生成多个相关查询来增强检索。


**需要注意的挑战**:
- **查询漂移**: 扩展的查询可能偏离用户的原始意图
- **过度扩展**: 添加过多术语可能降低精度
- **计算开销**: 处理多个查询会增加系统延迟

#### 2.3 查询分解(Query Decomposition)

将复杂、多方面的问题分解为更简单、集中的子查询。


**过程**包括两个主要阶段:
1. **分解阶段**: LLM分析原始复杂查询并将其分解为更小、集中的子查询
2. **处理阶段**: 每个子查询独立通过检索管道处理

#### 2.4 查询Agent(Query Agents)

查询Agent是查询增强的最高级形式,使用AI Agent智能处理整个查询处理管道。

这个流程图展示了**智能 Agent 处理用户查询的完整流程**，核心是 “动态分析→精准检索→评估优化→生成反馈” 的闭环逻辑，具体拆解如下：

 一、核心流程步骤

1. **分析（Analysis）**
    
    - 用大语言模型等生成式模型解析用户查询，明确任务需求，确定需要执行的具体查询方向。
2. **构建查询（Construct query）**
    
    - 采用**动态查询构建**：不依赖预设的查询模板，而是根据用户意图和数据结构 “按需生成查询”—— 自动添加筛选条件、调整搜索词，还能同时选择 “搜索（Search）” 和 “聚合（Aggregation）” 操作，确保找到最相关的结果。
3. **执行查询（Execution）**
    
    - 把构建好的查询发送到目标数据集合；
    - 支持**多集合路由**：Agent 能理解所有数据集合的结构，根据用户问题智能选择要查询的集合（比如 Vector database Collection A/B）。
4. **评估检索结果**
    
    - 检查检索到的信息是否与用户查询相关：
        - 若不相关：返回重新调整查询 / 换知识源；
        - 若相关：进入下一步。
5. **收尾（Finish）**
    
    - 可选步骤：用生成式模型将数据库结果转化为自然语言回答（Response）；
    - 同时记录对话上下文（Finalize context），支持后续交互的上下文连贯性。

 二、关键能力亮点

- **动态适配**：查询不是固定模板，而是根据需求灵活调整；
- **多源路由**：智能选择数据集合，避免无效检索；
- **闭环优化**：检索结果会评估，不足则迭代；
- **上下文感知**：能关联历史对话，保证交互的连贯性。

这个流程的核心是让 Agent“**像人一样思考查询**”—— 从理解需求，到灵活找数据，再到验证结果、优化反馈，最终高效给出精准回答。

---

### 3. Retrieval - 检索系统

**定义**: 连接LLM到你的特定文档和知识库的桥梁。

LLM的能力取决于它能访问的信息。虽然LLM在海量数据集上训练,但它们缺乏对你特定私有文档和训练完成后创建的任何信息的了解。


**挑战**: 原始文档数据集几乎总是太大而无法放入LLM有限的上下文窗口。我们必须找到完美的片段——包含用户查询答案的单个段落或部分。

为了使我们庞大的知识库可搜索,我们必须首先将文档分解为更小、可管理的部分。这个基础过程称为**分块(Chunking)**。

#### 分块技术指南

分块是你为检索系统性能做出的最重要决定。


设计分块策略时,必须平衡两个竞争优先级:

- **检索精度**: 块需要小而专注于单个想法
- **上下文丰富性**: 块必须足够大和自包含以便被理解

目标是找到"分块最佳点"——创建足够小以实现精确检索但足够完整以给LLM所需完整上下文的块。

#### 简单分块技术

**固定大小分块(Fixed-Size Chunking)**:

**递归分块(Recursive Chunking)**:
- 使用优先级分隔符列表分割文本
- 尊重文档的自然结构

**基于文档的分块(Document-Based Chunking)**:
- 使用文档的固有结构

#### 高级分块技术

**语义分块(Semantic Chunking)**:
- 基于含义而不是分隔符分割文本

**基于LLM的分块(LLM-Based Chunking)**:

**Agentic分块**:

**层次分块(Hierarchical Chunking)**:

**延迟分块(Late Chunking)**:

#### 预分块 vs 后分块

**预分块(Pre-Chunking)**:

**后分块(Post-Chunking)**:
这个图展示了**RAG（检索增强生成）系统的核心工作流程**，分为 “预处理→语义检索→增强生成” 三个阶段，具体如下：

 一、核心模块与流程

1. **预处理（Pre-Processing）**先对原始文档（Documents）做清洗：移除页眉、页脚、特殊字符等冗余内容，为后续处理做准备。
    
2. **语义检索阶段（Retrieval by semantic similarity）**
    
    - 用户查询（Query）和预处理后的文档，都通过 **Embedding Model（嵌入模型）** 转化为向量；
    - 文档向量被存入**Vector Database（向量数据库）**；
    - 系统根据 “语义相似度” 从向量库中检索与用户查询最相关的内容。
3. **后分块（Post-Chunking）**检索到的完整文档会被**分块（Chunks）+ 重排序**，再存入上下文窗口 —— 这样既能适配大语言模型（LLM）的上下文长度限制，又能优先保留关键信息。
    
4. **增强生成阶段（Augmented + Generation）**
    
    - 分块后的检索内容（Retrieved Context）被填入**Prompt Template（提示词模板）**；
    - **Large Language Model（大语言模型）** 基于 “用户查询 + 检索到的上下文” 生成最终回答（Output），反馈给用户。
---

### 4. Prompting Techniques - 提示技巧

**定义**: 给出清晰、有效指令以引导模型推理的技能。

提示工程是设计、细化和优化给予大语言模型的输入(提示)以获得期望输出的实践。

#### 经典提示技术

**思维链(Chain of Thought, CoT)**:

**少样本提示(Few-Shot Prompting)**:

**结合CoT和Few-shot**:

结合CoT和Few-shot示例是一种强大的方式,可以同时指导模型的推理过程和输出格式,以获得最佳效率。


**专业技巧 #1**:
使思维链中的模型推理非常具体到你的用例。例如,你可以要求模型:
- 评估环境
- 重复任何相关信息
- 解释这些信息对当前请求的重要性


**专业技巧 #2**:
最大化效率并减少token数量,要求模型以"草稿"形式推理,每句话不超过5个单词。

这确保了模型的思考过程是可见的,同时减少了输出token数量。
#### 高级提示策略

**思维树(Tree of Thoughts, ToT)**:

**ReAct提示**:

---

### 5. Memory - 记忆系统

**定义**: 给你的应用程序历史感和从交互中学习能力的系统。


这个图展示了**以大语言模型（LLM）为核心的 “智能计算系统” 架构**，把 LLM 类比成 “新一代计算机”，替代了传统 CPU 的核心角色，具体拆解如下：

一、核心模块：LLM（大语言模型）

LLM 是系统的 “大脑”，同时承担了 ** 计算（类似 CPU）、临时存储（类似 RAM）、上下文管理（Context Window）** 的功能，是所有交互的中心。

 二、周边交互模块

系统围绕 LLM 连接了四类资源，实现 “输入 - 处理 - 输出” 的闭环：

1. **传统软件工具（Software 1.0）**：
    - 类似 “经典计算机” 的功能，比如计算器、Python 解释器、终端等，LLM 可调用这些工具完成计算、代码执行等任务。
2. **存储系统（Disk）**：
    - 文件系统（含嵌入向量），LLM 可读写文件、调取存储的知识（比如通过向量检索获取信息）。
3. **外设 I/O（Peripheral devices）**：
    - 视频、音频设备，LLM 可处理音视频输入 / 输出（比如生成视频、解析音频内容）。
4. **网络与外部资源**：
    - 通过以太网连接浏览器（获取网络信息）、其他 LLM（实现多模型协作）。

三、核心逻辑

这个架构的本质是 **“以 LLM 为中心的智能计算范式”**—— 传统计算机的 “CPU+RAM + 外设” 模式，被 LLM 整合为统一的智能处理核心，同时连接各类工具、存储、网络资源，实现更灵活的智能任务处理。

#### Agent记忆的架构

在构建强大的Agent时,我们需要分层思考记忆,通常混合不同类型的记忆以获得最佳效果。

**短期记忆**:

短期记忆是Agent的即时工作空间。这是"现在",被塞入上下文窗口以推动即时决策和推理。这通过**上下文学习**实现,将最近的对话、操作或数据直接打包到提示中。

示例对话:
- 用户: "天气怎么样?"
- AI: "晴天,24°C"
- 用户: "我需要带夹克吗?"
- AI: "不需要,很暖和!"

因为受到模型token限制的约束,主要挑战是效率。诀窍是保持这个精简,以减少成本和延迟,同时不遗漏任何对下一步处理可能重要的细节。

**长期记忆**:

长期记忆超越了即时上下文窗口,将信息外部存储以便在需要时快速检索。这使Agent能够随着时间推移建立对其世界和用户的持久理解。它通常由**检索增强生成(RAG)**驱动,Agent查询外部知识库(如向量数据库)来提取相关信息。

这种记忆可以存储不同类型的信息,例如:
- **情节记忆**: 存储特定事件或过去的交互
- **语义记忆**: 保存一般知识和事实(可以是公司文档、产品手册或精选的领域知识库的信息,使Agent能够准确回答问题)

**混合记忆设置**:

实际上,大多数现代系统使用混合方法,将短期记忆的速度与长期记忆的深度相结合。一些高级架构甚至引入了额外的层:

- **工作记忆**: 与特定多步骤任务相关信息的临时存储区。例如,如果Agent正在预订旅行,其工作记忆可能会保存目的地、日期和预算直到任务完成,而不会使长期存储混乱。
- **程序记忆**: 这帮助Agent学习和掌握例程。通过观察成功的工作流程,Agent可以内化重复任务的步骤序列,使其随着时间推移变得更快、更可靠。


#### 有效记忆管理的关键原则

**修剪和细化**:

**选择性存储**:

**掌握检索的艺术**:

---

### 6. Tools - 工具集成

如果记忆给Agent自我意识,那么工具就是给它超能力的东西。


#### 从提示到行动的演变

使LLM具有工具使用能力的旅程经历了快速演变。最初,开发者试图通过传统的提示工程从LLM获得行动,通过诱导模型生成看起来像命令的文本。这很聪明但容易出错。

真正的突破是**函数调用(Function Calling)**,也称为**工具调用(Tool Calling)**。这种能力现在已成为大多数模型的原生功能,允许LLM输出可以包含要调用的函数名称和要使用的参数的结构化JSON。

有了这个能力,就有很多可能性:

**简单工具**:
旅行Agent机器人可以使用`search_flights`工具,当用户询问"帮我找下周二去东京的航班"时,LLM不会猜测答案。它生成对你提供的函数的调用,进而查询真实的航空公司API。

**工具链**:
对于像"帮我计划一个周末去旧金山的旅行"这样的复杂请求,Agent可能需要将多个工具链在一起:`find_flights`、`search_hotels`和`get_local_events`。这需要Agent进行推理、规划并执行多步骤工作流程。

上下文工程在这里的工作是如何呈现这些工具。一个写得好的工具描述就像一个小型提示,指导模型,清楚地说明工具的作用、需要什么输入以及返回什么。

#### 编排挑战

给Agent一个工具是容易的(大部分情况下)。让它可靠、安全和有效地使用该工具才是真正工作开始的地方。上下文工程的核心任务是**编排**,即在Agent推理使用哪个工具时管理信息流和决策制定。

这涉及在上下文窗口中发生的几个关键步骤。让我们使用Glowe(一个由我们的Elysia编排框架支持的护肤领域知识应用)作为运行示例来分解这些关键编排步骤:

**1. 工具发现**:
Agent需要知道它拥有哪些工具。这通常通过在系统提示中提供可用工具及其描述的列表来完成。这些描述的质量非常关键。它们是Agent理解每个工具作用的唯一指南,使模型能够理解何时使用工具,更重要的是,何时避免使用它。

在Glowe中,我们在初始化每个新聊天树时配置一组专门的工具(步骤5)并提供精确的描述。

**2. 工具选择和规划(思考)**:
面对用户请求时,Agent必须推理是否需要工具。如果需要,是哪一个?对于复杂任务,它甚至可能需要将多个工具链在一起,形成计划(例如,"首先,在网上搜索天气;然后,使用电子邮件工具发送摘要")。


在这里,决策Agent正确分析了传入的请求并选择了product_agent工具。

**3. 参数制定(行动)**:
一旦选择了工具,Agent必须弄清楚传递什么参数给它。如果工具是`get_weather(city, date)`,Agent需要从用户的查询中提取"旧金山"和"明天"并正确格式化它们。这也可以是带有使用工具所需信息的结构化请求或API调用。


在这种情况下,product_agent需要一个文本查询来搜索产品集合。注意Agent如何在生成初始导致错误的格式错误参数后自我修正(自我修复)(编排的另一个关键部分)。

**4. 反思(观察)**:
执行工具后,输出("观察")被反馈到上下文窗口中。然后Agent反思这个输出以决定下一步。工具成功了吗?它产生了回答用户查询所需的信息吗?还是返回了需要不同方法的错误?



如你所见,编排通过这个强大的反馈循环发生,通常称为**思考-行动-观察循环(Thought-Action-Observation Cycle)**。

#### 思考-行动-观察循环

这个循环构成了现代Agent框架(如Elysia)中的基本推理循环。Agent观察其行动的结果,并使用这些新信息来推动其下一个"思考",决定任务是否完成、是否需要使用另一个工具,或者是否应该向用户寻求澄清。


#### 工具使用的下一个前沿

**传统集成 vs MCP方法**:

---

## 总结

上下文工程不仅仅是提示大语言模型、构建检索系统或设计AI架构。它是关于构建在各种用途和用户中可靠工作的互联、动态系统。


上下文工程由以下组件组成:

- **Agents** - 作为系统的决策大脑
- **Query Augmentation** - 将混乱的人类请求转换为可操作的意图
- **Retrieval** - 将模型连接到事实和知识库
- **Memory** - 给你的系统历史感和学习能力
- **Tools** - 给你的应用程序与实时数据和API交互的手

我们正在从与模型对话的提示者转变为构建模型生活世界的架构师。**最好的AI系统不是来自更大的模型,而是来自更好的工程。**

---

## 参考资源

- Weaviate分块策略博客: https://weaviate.io/blog/chunking-strategies-for-rag
- Elysia Agentic RAG框架: https://weaviate.io/blog/elysia-agentic-rag
- Anthropic有效上下文工程指南
- Andrej Karpathy: Software Is Changing (Again)
- Model Context Protocol介绍: https://humanloop.com/blog/mcp