1. 范式转移：从提示工程到上下文工程的演进
在人工智能技术演进的宏大叙事中，大语言模型（LLM）的应用开发正经历一场静默却剧烈的范式转移。这一转变标志着行业重心从早期的「提示工程（Prompt Engineering）」——即通过巧妙的措辞诱导模型输出，向更为系统化、工程化的「上下文工程（Context Engineering）」过渡。这一演进并非偶然，而是随着企业级应用对智能体（Agent）连续性、个性化及复杂任务处理能力需求的指数级增长而产生的必然结果 1。
1.1 无状态模型的认知困境
大语言模型本质上是无状态的（Stateless）。每一次API调用对于模型而言都是全新的开始，除了预训练的参数权重外，模型不保留任何关于过往交互的记忆。这种「健忘症」特征在简单的问答任务中或许是可以接受的，但在构建长周期的智能助理或复杂的企业级工作流时，却构成了根本性的障碍 1。早期的解决方案试图通过超长提示词（System Prompt）一次性注入所有背景信息，但这种做法迅速遭遇了「注意力稀缺」的物理墙。尽管现代模型的上下文窗口（Context Window）不断扩大——从早期的4k Token扩展至Gemini 1.5 Pro的200万Token——但这并不意味着信息处理能力的等比例提升 5。
Anthropic的研究指出，上下文不仅仅是存储空间，更是一种有限的「注意力预算（Attention Budget）」。Transformer架构中注意力机制的二次方复杂度（
）决定了随着输入Token数量的增加，模型在众多信息中定位关键线索的能力会非线性下降 5。因此，单纯堆砌信息不仅会导致高昂的推理成本，更会引发「上下文腐烂（Context Rot）」，即模型在处理过量噪音时产生幻觉或忽略关键指令的现象 1。
1.2 上下文工程的定义与核心哲学
在此背景下，上下文工程应运而生。它不再仅仅关注如何「问」问题，而是关注如何「构建」问题发生的环境。Anthropic 将其定义为：在LLM推理过程中，对进入上下文窗口的所有Token（信息）进行策划、维护和优化的策略集 2。Google DeepMind 的研究团队则进一步将其具体化为：动态组装和管理LLM上下文窗口内信息的工程过程，旨在克服模型的无状态性，从而构建出有状态（Stateful）、智能的代理系统 1。
这一学科的核心哲学在于「认知资产的精算管理」。若将提示工程比作撰写一份精美的食谱，那么上下文工程则是管理整个厨房的供应链——确保在烹饪（推理）发生的当下，厨师（LLM）手边恰好有且仅有完成这道菜所需的最相关食材（信息），既不短缺导致风味不足（信息缺失），也不堆积导致操作混乱（注意力分散） 1。
表 1.2：提示工程与上下文工程的多维对比
| 维度 | 提示工程 (Prompt Engineering) | 上下文工程 (Context Engineering) |
| :—- | :—- | :—- |
| 核心目标 | 优化单次交互的输出质量 | 优化跨会话、长周期的系统表现与连贯性 |
| 操作对象 | 文本指令 (Text Instructions) | 完整的信息流 (Information Flow) 与系统状态 |
| 思维模型 | 创造性写作 (Creative Writing) | 系统架构设计 (Systems Architecture) |
| 处理范围 | 单一输入-输出对 | 记忆、工具、RAG、用户画像、环境感知 |
| 扩展性 | 难以规模化，依赖人工微调 | 为规模化设计，包含自动化ETL管道 |
| 调试重点 | 措辞微调 | 检查上下文窗口构成、Token流向、记忆检索逻辑 |
| 生命周期 | 一次性 (One-off) | 持续迭代 (Iterative & Lifecycle Managed) |
数据来源：9
上下文工程不仅是技术的升级，更是思维方式的转变。它要求开发者从「与聊天机器人对话」的思维中跳脱出来，转而思考如何构建一个能够感知、记忆并随环境动态调整的认知系统。这种转变使得AI开发更接近于传统的软件工程，需要考虑数据的一致性、系统的鲁棒性以及架构的可扩展性 3。
2. 上下文物理学：窗口机制与性能衰减
深入理解上下文工程，首先必须理解LLM处理信息的「物理规律」。上下文窗口并非一个完美的、均质的容器，而是一个充满「位置偏差」和「注意力竞争」的复杂力场。
2.1 上下文腐烂（Context Rot）的实证分析
虽然理论上模型可以处理数百万Token，但在实际应用中，性能往往在窗口填满之前就已经开始大幅下降，这种现象被称为「上下文腐烂」。Chroma 及相关研究机构通过「大海捞针（Needle In A Haystack）」测试揭示了这一现象的严峻性 7。
实验表明，随着无关上下文（Distractors）数量的增加，模型检索准确率呈现显著下降趋势。这并非仅仅是因为信息量大，而是因为语义相似的干扰项（Semantic Distractors）与目标信息产生了强烈的注意力竞争。例如，当在包含大量财务报告的上下文中检索某一个特定季度的利润时，其他季度的相似数据结构会极大地分散模型的注意力 14。这种腐烂效应在不同模型间存在差异，但普遍存在。Claude系列模型在某些测试中表现出较高的「拒绝回答」率，这通常是因为模型在面对大量噪音时无法确定信息的准确性而选择保守策略 14。
2.2 「中间丢失（Lost-in-the-Middle）」效应
除了总量的影响，信息在上下文中的位置也至关重要。多项研究证实了LLM存在显著的「中间丢失」效应：模型对于位于上下文开头（首因效应）和结尾（近因效应）的信息关注度最高，而对于位于中间长段落的信息，其检索和推理能力显著下降，形成了一个「U型」性能曲线 15。
这一发现对上下文组装策略产生了直接的指导意义：
1. 关键指令前置与后置： 系统指令（System Instructions）通常置于最前端，而用户的最新查询（User Query）置于最末端，这是利用首因和近因效应的最佳实践。
2. 动态重排序（Re-ranking）： 在检索增强生成（RAG）或记忆检索环节，单纯按相关性分数排序（由高到低）可能导致次高相关性的文档落在「死亡中段」。LangChain等框架为此引入了LongContextReorder算法，通过交替排列策略（如1, 3, 5…6, 4, 2），将高相关性的文档分布在上下文的两端，将低相关性的文档挤压至中间，从而最大化模型获取关键信息的概率 18。
2.3 注意力预算的经济学
从经济学角度看，每一个Token不仅消耗金钱（API成本），更消耗模型的「智力带宽」。在推理过程中，Transformer模型需要计算Token之间的两两相关性。当大量低价值信息占据上下文时，高价值信息所分配到的注意力权重必然被稀释 5。
因此，上下文工程的首要任务是「降噪」。这要求在数据进入模型之前，必须经过严格的过滤和压缩。通过上下文压缩（Context Compaction）技术，如摘要生成、关键信息提取等，可以将原始的、冗长的自然语言转化为高密度的信息载体，从而在有限的预算内承载更多的有效逻辑 1。这种对「信噪比」的极致追求，是区分普通聊天机器人与高性能智能体的关键分水岭。
3. 会话层（Session Layer）：短期认知的动态工作台
会话层是上下文工程中最基础、最活跃的组件。它模拟了人类的「工作记忆（Working Memory）」，负责处理当前正在进行的任务和交互。
3.1 会话的隐喻与结构
Google 的研究报告提出了一个精妙的隐喻：会话即「工作台（Workbench）」 1。当工匠（智能体）开始一项任务时，他会将所需的工具、原材料和临时笔记摆放在工作台上。这些物品触手可及，服务于当前的具体目标。一旦任务完成，工作台会被清理，只有最终的成品和重要的经验会被归档，而过程中的废料和草稿则会被丢弃。
在技术实现上，会话通常被定义为一个包含时间序列事件（Events）和状态（State）的容器 1。
* 事件（Events）： 记录了交互的详细流水账，包括用户输入、模型回复、工具调用（Function Calls）及其返回结果（Tool Outputs）。这些事件严格按照时间顺序排列，构成了对话的因果链条 1。
* 状态（State）： 这是一个结构化的数据存储区，用于保存当前任务的关键变量。例如，在订票任务中，目的地、日期、人数等信息会被抽取并存储在State中。这与LangGraph中的StateGraph概念不谋而合，后者强调状态在计算节点间的流转 19。
3.2 动态上下文管理策略
随着对话的深入，工作台上的「杂物」会迅速堆积。为了防止上下文溢出和腐烂，必须实施动态的管理策略：
#### 3.2.1 滑动窗口与智能截断（Intelligent Truncation）
最直接的方法是保留最近的
轮对话。然而，简单的截断可能会丢失早期的关键约束。智能截断策略会结合Token计数，动态地从历史记录中移除较早的、非关键的对话轮次，同时保留系统指令和长期记忆注入块。Google ADK中的ContextFilterPlugin即提供了此类功能，允许开发者配置保留的轮次或Token阈值 1。
#### 3.2.2 递归摘要（Recursive Summarization）
这是一种更为高级的压缩技术。当会话长度超过一定阈值时，系统会触发一个后台进程，调用LLM将前段对话压缩为一段自然语言摘要。新的上下文结构变为：[系统指令] + [过往对话摘�