Context Engineering —— 知识与记忆的窗口

本文是Agent四大工程支柱的第二篇： Context Engineering 部分内容扩展创作，深入探讨上下文工程的技术体系、核心挑战与最佳实践。

一、什么是 Context Engineering？

大语言模型每次回答时，并不是"自动知道所有东西"，而是只能基于当前上下文进行推理。如果上下文里缺少关键信息、混入无关材料、包含过时知识或存在相互冲突的内容，模型就可能给出看似合理但实际错误的回答。

Context Engineering（上下文工程）关注的是模型在一次推理或一次任务执行中**"应该看到什么信息"。它的核心目标是把正确、相关、可信、可追溯**的信息放到模型面前，同时减少噪声、冲突和安全风险。

与 Prompt Engineering 关注"怎么问"不同，Context Engineering 关注的是"给模型看什么"。二者共同构成了 AI 应用的信息输入体系：Prompt 决定了指令的精确性，Context 决定了信息的完整性。

二、上下文窗口的演进：从"装得下"到"会选择"

2.1 上下文窗口的技术演进

上下文窗口（Context Window）决定了模型在一次推理中能直接"看到"多少 token。它的演进经历了几个阶段：

时期	典型窗口大小	代表模型	设计挑战
2022 年	2K-4K tokens	GPT-3.5, LLaMA 1	如何在有限窗口内压缩信息
2023 年	8K-32K tokens	GPT-4, Claude 2	长文本如何保持注意力
2024 年	128K-1M tokens	GPT-4 Turbo, Claude 3, Gemini 1.5	信息密度与检索精度
2025 年	1M+ tokens	Gemini 2.0, 各类长窗口模型	有效信息筛选与成本控制

窗口变长并不等于信息质量变高。研究表明，即使上下文窗口足够大，模型对窗口中间位置的信息关注度显著低于开头和结尾（即"Lost in the Middle"现象）。将无关、重复、过期或冲突的内容塞进上下文，反而会干扰模型判断，降低输出质量。

因此，Context Engineering 的核心不是简单追求"塞更多内容"，而是管理哪些信息必须保留，哪些信息应被摘要、检索、刷新或剔除。

2.2 "Lost in the Middle" 问题

2023 年 Stanford 等机构的研究发现，大语言模型在长上下文中存在明显的"中间丢失"效应：模型对上下文开头和结尾的信息利用最好，而对中间部分的信息利用显著下降。

这意味着，单纯把更多文档塞进上下文窗口，并不能保证模型正确利用这些信息。工程上需要：

将关键信息放在上下文的首部和尾部
对中间内容进行结构化标注
使用 RAG 等技术将长文档转化为精准检索

三、上下文窗口管理：在有限预算中做最优分配

上下文窗口是有限资源，可以将其视为"注意力预算"。Context Engineering 的核心任务就是动态安排各类信息的优先级和位置。

3.1 上下文的结构化分层

一个典型的 Agent 上下文由以下层次组成，按优先级从高到低排列：

scss 复制代码

┌─────────────────────────────────┐
│  系统指令 (System Prompt)        │  ← 最高优先级，定义行为边界
├─────────────────────────────────┤
│  安全规则与权限约束               │  ← 硬约束，不可被覆盖
├─────────────────────────────────┤
│  当前任务描述与目标               │  ← 核心任务信息
├─────────────────────────────────┤
│  检索到的关键证据/文档            │  ← 任务相关的知识支撑
├─────────────────────────────────┤
│  近期对话历史 (摘要)             │  ← 保持对话连续性
├─────────────────────────────────┤
│  工具调用结果                    │  ← 外部交互的反馈
├─────────────────────────────────┤
│  工作状态 (任务进度/中间产物)     │  ← 当前执行状态
└─────────────────────────────────┘

3.2 上下文管理的核心操作

工程上，上下文管理需要处理以下五种核心操作：

保留（Retain）：确定哪些信息必须保留在上下文中。关键判断标准包括：

与当前任务的直接相关性
是否包含不可替代的精确数据（如数字、代码、命令）
后续步骤是否需要引用

丢弃（Drop）：移除不再需要的信息，释放窗口空间。包括：

已完成步骤的中间推理过程
已被更优结果替代的旧版本
与当前任务无关的历史信息

摘要（Summarize）：将长内容压缩为关键信息。常见策略：

对长对话历史进行阶段性摘要
将多轮工具调用结果合并为结论
保留关键事实，丢弃推理过程

刷新（Refresh）：更新过时或已被修正的信息：

当工具返回更新后的数据时，替换旧数据
当任务目标发生变化时，更新任务描述
当发现错误时，标记并修正错误信息

按需检索（Retrieve-on-Demand）：不将全部信息预先加载到上下文，而是在需要时触发检索。这是 RAG 技术的核心思想。

3.3 安全与权限控制

上下文管理还需要处理敏感信息问题：

确保不同权限级别的用户看到的信息不同
防止敏感文档内容通过上下文泄露
在多租户场景下，确保上下文隔离

四、RAG：把外部知识带入模型回答

4.1 RAG 的技术原理

RAG（Retrieval-Augmented Generation，检索增强生成）是 Context Engineering 中最核心的技术之一。它通过在推理时检索外部知识库，将模型参数记忆与外部知识结合，提升知识密集任务中的事实性、时效性和可追溯性。

标准 RAG 流程包括以下步骤：

复制代码

用户问题 → 查询改写 → 检索召回 → Rerank 重排序 → 上下文拼装 → 生成回答 → 引用输出

每一步都充满工程挑战：

查询改写（Query Rewriting）：用户的问题往往不是最优的检索查询。例如用户问"那个东西怎么用？"，需要结合上下文改写为"XX产品的安装配置步骤"。常见技术包括：

基于历史对话的指代消解
查询扩展（添加同义词、相关术语）
子问题拆分（将复杂问题拆分为多个简单查询）

检索召回（Retrieval）：从知识库中召回相关文档。关键技术选择包括：

稀疏检索：BM25，适合关键词匹配
密集检索：基于 Embedding 的语义相似度搜索
混合检索：结合两者优势，当前主流做法

Rerank 重排序：初步召回的文档可能包含大量噪声，需要使用更精准的模型进行二次排序。BGE-Reranker、Cohere Rerank 等是常用工具。这一步直接影响最终答案的质量。

上下文拼装：将检索到的文档片段与系统指令、用户问题、对话历史等组合成最终的上下文。关键是控制信息密度和顺序。

引用输出：在生成答案的同时，标注信息来源，实现可追溯性。

4.2 从 Naive RAG 到 Agentic RAG

Naive RAG（朴素 RAG）通常采用单轮检索和固定流程，适合事实查询、FAQ、文档问答等路径明确的任务。其流程是线性的：查询 → 检索 → 生成。

Agentic RAG（智能体化 RAG）则是 RAG 的智能体化编排形态。模型或 Agent 会根据任务状态主动决策：

是否检索：当前上下文是否已经足够回答问题？
如何改写查询：原始查询是否需要重写以提高召回率？
是否拆分子问题：复杂问题是否需要分解为多个子查询？
是否继续检索：当前检索到的信息是否足够？是否需要多轮检索？
是否打开原文：检索到的片段是否需要展开查看完整上下文？
是否汇总证据：多个来源的信息如何综合？

Agentic RAG 的典型流程是循环式的：

erlang 复制代码

→ 分析问题 → 决定检索策略 → 检索 → 评估结果 → 信息不足？→ 改写查询 → 再次检索 → ...
→ 信息充足 → 综合证据 → 生成回答 → 标注引用

Agentic RAG 适合复杂问题、跨文档推理、企业知识库分析和多步证据收集，但会带来更高的延迟、成本和治理复杂度。

4.3 RAG 的关键评估指标

评估 RAG 系统不仅仅是看"答案对不对"，还涉及多个维度：

维度	指标	说明
检索质量	Recall@K, NDCG	相关文档是否被召回
答案忠实度	Faithfulness	答案是否基于检索到的文档，而非模型幻觉
答案相关性	Answer Relevance	答案是否直接回答了问题
上下文利用	Context Utilization	检索到的信息是否被有效使用
引用准确度	Citation Accuracy	引用是否指向正确的来源

五、动态上下文组装：从固定模板到智能编排

5.1 为什么需要动态组装

在生产级 AI 应用中，上下文并非固定不变，而是根据以下因素在运行时动态组装：

用户身份：不同角色（管理员 vs 普通用户）看到的信息不同
当前任务：不同任务需要不同的知识库和工具集
历史状态：之前的交互结果影响当前上下文
业务规则：某些场景下需要强制加入合规声明或免责条款

5.2 组装的工程原则

动态上下文组装需要遵循以下原则：

顺序控制：信息的排列顺序直接影响模型注意力。核心规则应放在首位或末位，参考信息放在中间，噪声信息尽量剔除。

优先级管理：当窗口空间不足时，按优先级裁剪：

必选项（系统指令、安全规则）→ 不可裁剪
核心项（任务描述、关键文档）→ 优先保留
增强项（历史对话、详细示例）→ 空间不足时裁剪
可选项（辅助参考、背景信息）→ 空间不足时移除

信息密度控制：每一条进入上下文的信息都应该经过"价值密度"评估------它是否值得占用有限的 token 预算？

边界控制：既要让模型看到足够证据，也要避免噪声、冲突和越权内容进入上下文。

5.3 上下文组装的典型架构

scss 复制代码

                     ┌──────────────────┐
                     │   上下文组装器    │
                     └──────┬───────────┘
                            │
          ┌─────────────────┼─────────────────┐
          │                 │                 │
    ┌─────▼─────┐   ┌──────▼──────┐   ┌──────▼──────┐
    │  用户画像   │   │  权限控制器  │   │  业务规则引擎 │
    │ (角色/偏好) │   │ (数据可见性) │   │ (合规/格式)  │
    └───────────┘   └─────────────┘   └─────────────┘
                            │
          ┌─────────────────┼─────────────────┐
          │                 │                 │
    ┌─────▼─────┐   ┌──────▼──────┐   ┌──────▼──────┐
    │  RAG 检索  │   │  记忆系统   │   │  工具结果   │
    │ (外部知识)  │   │ (历史/状态) │   │ (实时反馈)  │
    └───────────┘   └─────────────┘   └─────────────┘

六、长文本压缩与记忆管理

6.1 长文本压缩策略

长文本和长任务需要同时处理压缩与记忆，核心操作包括：

裁剪（Truncation）：移除无关、重复和低优先级内容。裁剪策略需要基于语义理解而非简单的 token 计数------同样长度的文本，代码片段和闲聊对话的信息密度完全不同。

摘要（Summarization）：对历史对话、长文档和执行轨迹进行压缩。摘要需要保留关键事实、决策逻辑和待办事项，而非仅仅是"说了什么"。推荐使用结构化的摘要格式：

yaml 复制代码

会话摘要:
  主题: API 接口设计评审
  关键决策:
    - 采用 RESTful 风格
    - 版本号放在 URL 路径中
    - 认证使用 JWT + OAuth2
  待解决问题:
    - 限流策略待定
    - 批量操作接口设计待确认
  已完成操作:
    - 创建了项目骨架
    - 定义了数据模型

证据定位：保留真正支撑答案的原文片段，而非整篇文档。这对于可追溯性至关重要------用户需要知道答案来自哪里。

6.2 三级记忆架构

记忆系统是 Context Engineering 的重要组成部分。行业普遍采用三级记忆架构：

短期记忆（Working Memory）：服务当前推理，位于上下文窗口中。包含：

当前对话轮次
正在执行的任务状态
最近的工具调用结果

中期记忆（Task Memory）：服务当前任务会话，记录任务状态。包含：

任务目标与计划
已完成的步骤
失败记录与重试策略
中间产物（如生成的代码、分析结果）

长期记忆（Persistent Memory）：沉淀用户偏好、项目规范和可复用流程。包含：

用户偏好设置（语言、风格、详细程度）
项目编码规范和架构约定
历史踩坑经验与解决方案
可复用的工作流模板

6.3 上下文衰减与上下文漂移

两个尚未被充分解决的问题：

上下文衰减（Context Decay）：即使上下文窗口未满，随着对话轮次增加，模型对早期信息的关注度也会持续下降。这比"Lost in the Middle"更隐蔽------不是因为信息被挤出了窗口，而是模型"忘记了"。

缓解策略：

定期在系统指令中重申关键约束
使用结构化状态文件记录任务进度
在关键步骤前触发"回顾"操作

上下文漂移（Context Drift）：长时间运行后，Agent 逐渐偏离原始任务目标。由于每轮对话都基于上一轮的结果，微小的偏差会逐步累积，最终导致 Agent 在做完全不同的事情。

缓解策略：

定期校验当前状态与原始目标的一致性
设置任务目标作为"锚点"，在关键节点回溯
引入外部监督机制（如另一个 Agent 做目标对齐检查）

七、多模态上下文：不止于文本

7.1 多模态上下文的范畴

现代模型的上下文不再只包含文本，还可能包含：

模态	典型内容	技术挑战
图片	截图、照片、图表、UI 设计稿	区域定位、OCR 对齐
表格	Excel 数据、数据库查询结果	结构保留、数值精度
网页	完整页面截图或 HTML	元素关联、交互逻辑
代码	源代码、配置文件	语法语义保留、跨文件引用
日志	系统日志、错误堆栈	时序关系、异常模式识别
音频	会议录音、语音指令	转写精度、说话人识别
视频	录屏、监控画面	帧采样、时序理解

7.2 多模态对齐的关键挑战

多模态上下文的核心挑战是信息对齐------如何将不同模态的信息统一到同一个任务目标中。

图片与文本对齐：模型需要知道图片中哪个区域对应文本描述中的哪个实体
表格与推理对齐：表格的结构信息（列名、行关系）需要被正确传递到推理过程
代码与执行结果对齐：代码片段与其执行日志需要关联，便于调试
时序对齐：不同模态的信息可能存在时间差，需要维护时序一致性

多模态上下文扩展了模型的能力边界，同时也显著增加了证据对齐、权限控制和可追溯性的挑战。一个包含截图的上下文，如果截图中的敏感信息被泄露，追溯和审计都比纯文本更加困难。

八、总结

Context Engineering 是 AI 工程化中承上启下的关键环节。它承接 Prompt Engineering 的"怎么问"，为 Harness Engineering 和 Loop Engineering 提供信息基础。

其核心原则可以概括为四点：

选对信息：不是越多越好，而是越精准越好。RAG、Rerank、查询改写等技术服务于此。
管好窗口：上下文窗口是有限资源，需要动态分配优先级。保留关键信息，剔除噪声。
记住状态：通过三级记忆架构（短期/中期/长期），在任务中保持连续性和一致性。
对齐多模态：不同模态的信息需要统一到同一个任务目标中，确保证据可追溯。

Context Engineering 的本质不是技术堆砌，而是一种信息管理哲学------在有限的信息带宽内，让模型看到最值得看到的内容。

上一篇：Prompt Engineering ------ 意图的精确表达

下一篇： $Harness Engineering ------ 系统的安全护栏$