什么是上下文工程（Context Engineering）？一文理解其定义与作用

一、引言：从“如何提问”到“提供什么”

在与大语言模型（LLM）共舞的时代，我们总在寻找那句能让AI心领神会的“咒语”。长久以来，“提示工程”（Prompt Engineering）被奉为圭臬——工程师们精雕细琢每一个词语，试图在一次对话中榨取模型的全部潜能。

然而，RAG系统返回了完美的文本块，提示词写得很漂亮，但LLM还是在产生幻觉；文档加得越多，回复质量反而越差。这些问题不出在提示词上，而是出在上下文上。随着AI应用的复杂度日益提升，尤其是在构建能够记忆、思考、协作的智能代理（Agentic AI）时，我们发现，仅仅优化“说什么”已经远远不够。

一种更宏大、更具架构性思维的理念——上下文工程（Context Engineering） 正悄然兴起。它关注的不是单次的完美指令，而是为模型构建一个持续、动态且充满信息的“思考环境”。特斯拉前AI总监Andrej Karpathy将上下文工程描述为“在大语言模型的上下文窗口中放入正好适合它执行下一步所需的信息”。Anthropic也于2024至2025年间正式提出了这一概念。

本文将系统阐述上下文工程的定义、核心内涵、与提示工程的本质区别、关键技术方法及其在实际应用中的作用。

二、什么是上下文工程

2.1 定义

上下文工程，是指在运行时决定AI模型看到什么信息、何时看到、以何种结构看到的工程实践。更严谨地说，它是“设计和构建动态系统，这些系统能够在正确的时间、以正确的格式提供正确的信息和工具，使LLM能够合理地完成任务”。

从信息论的角度来看，上下文工程是一个熵减少过程，旨在弥合人类与机器之间的认知鸿沟——它通过收集、管理和使用上下文信息，将高熵的人类意图和环境状态，预处理为机器可理解的低熵表示。

从开发者的角度来看，上下文工程是一个迭代过程，用于优化提供给LLM的指令和上下文，以达到期望的结果。

2.2 核心视角：从静态提示到动态管道

上下文工程与传统方法最本质的区别在于视角的转换：

• 提示工程关注的是“如何提问”，将上下文视为一段静态的提示词；

• 上下文工程关注的是“提供什么”，把上下文当作一条动态管道来处理，而非一段静态提示词。

这一视角转换意味着：上下文工程不是简单的“高级提示工程”，而是一套面向场景立意的新方法论，可以指导复杂业务场景智能化应用的构建。

2.3 三十年的演进

值得注意的是，上下文工程并非全新发明。早在1994年，Bill Schilit在其博士论文中首次提出了“context-aware computing”（上下文感知计算）的概念。2001年，Anind Dey给出了至今仍被广泛引用的定义：“上下文是任何可以用来刻画实体情境的信息”。2000年，佐治亚理工大学的研究者已经开发了Context Toolkit——一个帮助开发者构建“上下文感知应用”的框架。

从这个意义上说，上下文工程已经走过了三十年的演进历程。变化的是机器能理解的“你”越来越完整，不变的是人类一直在努力让机器理解“什么是人”。

三、为什么需要上下文工程

3.1 提示工程的局限

随着LLM上下文窗口的显著扩大（在过去两年中从4K增加到超过1M tokens），提示工程的局限性日益凸显：

• 优化焦点不同：提示工程主要优化的是“句子”，即你如何提问，而非AI在“思考”时可以访问到的“知识”；

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

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

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

3.2 “上下文越多越好”是一个迷思

一个常见的迷思是：向LLM提供的信息越多，它的表现就越好。然而事实恰恰相反。

Chroma的一项2025年研究测试了包括GPT-4.1、Claude和Gemini在内的18个最强大的语言模型，发现随着输入量的增加，每一个模型的性能都会变差。一些模型在准确率上稳定保持95%，但一旦输入超过某个长度，准确率便会骤降至60%。

研究者将这一现象称为“上下文腐化”（Context Rot） ——当上下文token增加，模型从中准确检索信息的能力会下降。这不是某个模型的特例，而是普遍现象。

造成这一现象的原因包括：

• 有限注意力长度：像人类的工作记忆一样，LLM的注意力资源是有限的。每纳入一个token，都会消耗注意力预算的一部分，从而降低对其他信息的分配能力；

• 架构约束：Transformer允许任意token关注到任意其他token，导致O(n²)指数级别增长，当上下文变长，模型捕捉这些关系的能力被摊薄；

• 训练数据偏差：训练数据中短序列更常见，模型对“极长序列的全局依赖”往往经验不足。

3.3 Agent场景下的特殊挑战

在AI智能体（Agent）场景下，上下文管理的挑战更加严峻。一个典型任务通常需要约50次工具调用。Anthropic的研究表明，生产级Agent在运行时甚至可能需要多达数百次工具调用。

如果每次工具调用产生的上下文都直接传入模型，很快就会触及LLM的上下文窗口上限。Lance Martin在开发开源AI研究助手时发现，Agent每次工具调用都会消耗大量token，如果不对此进行优化，单次运行可能就要消耗50万个token。

许多AI Agent的失败并非模型本身的失败，而是上下文的失败（Context Failures）。正是这些痛点，催生了上下文工程这一新方向。

四、上下文工程 vs 提示工程：核心区别

理解上下文工程，关键是理解它与提示工程的本质区别。

4.1 一句话概括

提示工程：核心是手动构思一小段指令，如同“念咒”——关注的是“对模型说什么”。

上下文工程：核心是构建一个自动化系统，像设计一条“信息流水线”——关注的是“模型在听到指令时已经知道了什么”。

4.2 多维度对比

4.3 两者的关系

上下文工程是提示工程的自然演进和更高层次版本。如果说提示工程像学习如何提出好问题，那么上下文工程更像图书馆员决定读者在阅读前能接触到哪些书籍。

提示工程被认为是上下文工程的一个子集。即使拥有了所有上下文，如何将其组织到提示中仍然至关重要。正如有研究者指出：上下文工程包括了提示工程，提示工程是上下文工程的一部分。

但两者不是替代关系，而是递进关系。在实际应用中，精湛的提示工程技能仍然是上下文工程能力的重要组成部分。

五、上下文工程的核心组成

5.1 上下文的构成要素

上下文不仅仅是发送给LLM的单一提示，而是模型在生成响应之前所看到的一切。它通常涵盖以下核心组件：

1. 指令（Instructions）/系统提示（System Prompt） ：定义模型在对话期间的行为规则和角色设定；

2. 知识（Knowledge） ：通过RAG（检索增强生成）或知识图谱获取的外部领域知识；

3. 工具（Tools） ：可用外部工具的定义和签名，用于函数调用；

4. 记忆（Memory） ：历史交互中保留的持久化信息，包括短期记忆和长期记忆；

5. 状态（State） ：用户、现实世界或多智能体系统的动态状态；

6. 查询（Query） ：用户当下的直接请求。

5.2 上下文工程的数学本质

从更抽象的角度来看，上下文工程可以形式化为：将上下文C从单一字符串重新概念化为由多个信息组件动态组合而成的结构：

C = A(c₁, c₂, …, cₙ)

这里的A是一个“组装函数”，负责调度这些由不同函数获取、过滤和格式化的组件。

上下文工程本质上是一个寻找最优上下文生成函数集合的数学优化问题——在有限的上下文窗口内，找到最小的一组高信息密度token，同时最大化模型产生目标结果的概率。

六、上下文工程的核心技术与方法

6.1 三大核心技术支柱

构成上下文工程的三大核心技术支柱分别是：

1. 上下文检索与生成：从提示词、外部知识库等获取原始信息，通过动态组装形成适配任务的上下文；

2. 上下文处理：通过压缩、摘要、结构化转换等技术，精炼原始信息，适配模型理解与推理；

3. 上下文管理：构建内存层次、运用压缩技术，在资源约束下高效存储、调度上下文信息。

6.2 四大核心策略

LangChain团队提出了上下文工程的四大核心策略：

1. 写入（Write） ：让AI在处理复杂任务时把关键信息写下来，避免重复分析——就像人类做复杂工作时会记笔记一样；

2. 选择（Select） ：从大量可用信息中筛选出最相关的内容；

3. 压缩（Compress） ：对长文本进行摘要或精简，在保持信息密度的同时减少token消耗；

4. 隔离（Isolate） ：将不同任务或不同来源的上下文分开管理，避免相互干扰。

6.3 五大代表性方法

学界和业界总结的五大代表性方法可以归纳为：

• Offload（转移） ：将部分上下文信息转移到外部存储，按需加载；

• Reduce（简化） ：通过摘要、压缩等方式减少上下文的信息量；

• Retrieve（检索） ：按需从知识库中检索相关信息，而非全量灌入；

• Isolate（隔离） ：隔离不同来源或不同任务的上下文；

• Cache（缓存） ：缓存常用上下文以提升效率。

6.4 具体技术手段

在实践中，上下文工程依赖以下具体技术手段：

• 选择性检索：从知识库中精准检索最相关的信息片段；

• 上下文压缩：将长文档压缩为面向任务的摘要，可以在保持甚至提升准确率的同时砍掉50–75%的Token；

• 层次化布局：将上下文按重要性和相关性分层排列；

• 动态查询重构：根据对话历史和当前状态动态调整查询方式；

• 记忆注入：将历史交互中的关键信息注入当前上下文；

• 工具感知：让模型了解可用工具及其使用方式。

七、上下文工程的作用与价值

7.1 提升模型输出的稳定性和可靠性

上下文工程最直接的作用是让LLM在生产环境中稳定输出高质量结果。通过精准控制模型在运行时“看到什么、何时看、如何看”，可以根治幻觉、提升准确率、降低Token消耗，让小模型也能稳定输出高质量结果。

很多AI应用的不稳定，根源不在于模型本身，而在于上下文的不可控。上下文工程通过系统化的上下文管理，将这种不可控变为可控。

7.2 解决AI的“记忆瓶颈”

大语言模型的“记忆”本质上是一个固定容量的文本窗口，就像人的短期记忆一样有限。当总上下文超出模型的上下文窗口时，新信息进入时旧信息就可能被“挤出去”。

上下文工程提出了一个系统性的解决思路：不是让AI记住所有信息，而是让它在每个时刻都能获得最重要的信息。通过RAG检索、动态上下文管理和长期记忆系统等技术，上下文工程使AI能够记住用户偏好、理解情境、跟踪目标进展，实现从“每次重新开始”到“基于理解继续”的智能进化。

7.3 降低成本和延迟

上下文工程通过精准控制进入上下文窗口的信息量，直接降低了API调用的token消耗和相应的成本。在Agent场景下，单次运行可能消耗数十万token，上下文工程的优化可以带来显著的降本增效。

7.4 构建可扩展的AI系统

上下文工程被视为构建可扩展AI系统的必由之路。它要求开发者深入理解信息架构、数据策略和用户体验，这使得它超越了传统的提示工程。掌握上下文工程的组织将获得巨大的竞争优势。

正如Thoughtworks在其技术雷达中所指出的：上下文工程已经从一种优化策略演变为现代AI系统的基础架构关注点。将AI上下文视为静态文本框是通向幻觉的快车道。要构建健壮的企业级Agent，团队必须将上下文工程作为一条动态的、精确管理的管道。

八、总结

上下文工程（Context Engineering）是一门设计、组装和管理LLM在生成响应前所能看到的所有信息环境的实践。它超越了编写单条好的指令，而是要统筹安排填充上下文窗口的所有内容，使模型恰好拥有完成当前任务所需的一切，不多也不少。

从提示工程到上下文工程的演进，本质上是从“语言层工程”到“信息层工程”的跃迁。它不再局限于如何写好一句话来引导AI，而是构建一套严密的、模块化的系统架构——通过科学地调度指令、知识、工具、记忆和状态，让AI系统能够像人类一样，在复杂、模糊、动态且多模态的现实世界中，做出准确的响应。

上下文工程的核心任务，是在模型固有约束下，优化上下文token的效用，以更稳定地获得预期结果。它要求我们把上下文视为一种稀缺资源，并以工程化的方式加以管理——这是构建强大AI应用的基础。