你是否感觉当下的AI Agent技术听起来很厉害，但实际使用时却常常“掉链子”，尤其是在处理复杂任务时容易半途而废？你可能会认为这是模型能力不足。然而，业内的共识是：多数AI Agent的失败，并非模型能力的失败，而是上下文工程（Context Engineering）的失败。
那么，这个听起来高大上的“上下文工程”究竟是什么？它和我们熟悉的提示词工程（Prompt Engineering）、检索增强生成（RAG）以及模型上下文协议（MCP）又是什么关系？本文将带你彻底搞懂这个AI应用开发的核心话题。
一、重新定义“上下文（Context）”
首先，我们需要明确一个核心问题：什么是上下文（Context）？
很多人会简单地理解为“聊天记录”，但这只触及了表面。从本质上讲，上下文是提供给大语言模型的、用来完成下一步推理或生成任务的全部信息集合。 这个集合比我们想象的要丰富得多，可以系统地分为三大核心类别：
1. 指导性上下文（Guiding Context）
这类上下文的核心功能是指导模型该做什么以及如何去做，为模型的行为设定框架、目标和规则。我们熟知的提示词工程（Prompt Engineering），主要就是在优化这类上下文。
- 系统提示词 (System Prompt)：定义模型的角色和行为准则。
- 任务描述 (Task Description)：明确当前需要完成的具体任务。
- 少样本示例 (Few-shot Examples)：提供范例，指导模型输出的风格和逻辑。
- 输出格式定义 (Output Schema)：规定模型应以何种格式（如JSON）返回结果。
2. 信息性上下文（Informational Context）
这类上下文的核心功能是告诉模型需要知道什么知识，为其提供解决问题所必需的事实、数据和知识。
- 检索增强生成 (RAG)：从外部知识库中检索相关信息。
- 记忆 (Memory)：包括短期记忆（如Claude Code的临时TODO）和长期记忆。
- State & Scratchpad：模型的“草稿本”，用于记录中间的思考过程和状态。
3. 行动性上下文（Actionable Context）
这类上下文的核心功能是告诉模型能做什么以及做了之后的结果，赋予模型与外部世界交互的能力。
- 工具定义 (Tool Definition)：描述模型可以使用的工具及其功能。
- 工具调用和结果 (Tool Calls & Results)：记录模型调用工具的动作和返回的结果。
- 工具追踪 (Tool Traces)：追踪工具调用的完整链路。
所以，上下文是一个多维、动态、服务于特定任务的系统性概念，远不止聊天记录那么简单。
二、什么是上下文工程（Context Engineering）？
理解了上下文的构成后，我们再来看什么是上下文工程。两位AI界的大佬对此有非常精辟的描述：
Tobi Lütke (Shopify CEO): 它更好地描述了一种核心技能，那就是提供所有上下文的艺术，以便让大语言模型能够合理地解决任务。
Andrej Karpathy (OpenAI创始成员): 在所有的工业级大模型应用中，上下文工程是一门微妙的艺术与科学，目的是在上下文窗口中填入恰到好处的信息，为下一步的推理做准备。
结合两人的观点，我们可以将上下文工程定义为：
一门系统性的学科，专注于设计、构建并维护一个动态系统，该系统负责为Agent执行任务的每一步，智能地组装出最优的上下文组合，从而确保任务能够被可靠、高效地完成。
Karpathy用了一个绝妙的比喻：如果将Agent视为一个操作系统，那么大语言模型是CPU，上下文窗口是内存（RAM），而上下文工程就是这个操作系统中的内存管理器。它的职责不是简单地把数据塞满内存，而是通过复杂的调度算法，决定在每一个“时钟周期”，哪些数据应该被加载、哪些应该被换出、哪些应该被优先处理，从而保证整个系统的流畅运行。
上下文工程 vs. 提示词工程 vs. RAG
它们并非互相排斥，而是处于不同层级、互相协作的关系：
- 提示词工程：更细粒度，专注于优化单次交互中的“指导性上下文”。
- RAG：是上下文工程的一部分，专注于从外部知识库中“检索”信息，填充“信息性上下文”。
- 上下文工程：范畴远大于前两者，它是一个完整的系统，不仅要决定“检索什么”，还要考虑如何将检索到的信息与指导性、行动性上下文进行动态组合，甚至在RAG失败后该如何应对。
三、我们为什么需要上下文工程？
随着基础模型能力的提升，Agent表现不佳的原因越来越少归咎于模型本身，而更多地指向了上下文信息的缺失或冗余。
案例1：上下文缺失的代价
想象一个AI助手收到一封邮件：“Hi，明天有空聚一下吗？”
- 上下文贫乏的Agent：它只看到这句话，回应可能是机械的：“感谢您的消息，我明天有空。请问您希望约在什么时间？” 这种回应无法推进任务。
- 上下文充足的Agent：在回应前，它会动态组装一个丰富的上下文：
- 信息性：检索你的日历发现明天已满；识别发件人Jim是重要伙伴；分析过往邮件确定应采用非正式语气。
- 行动性：知道自己拥有
send_calendar_invite这个工具。 - 最终回应：“Hi Jim！我明天日程完全满了，周四上午有空，你看方便吗？我发了一个暂定的邀请链接，如果你时间合适请确认一下。”
这里的“魔力”并非来自更强的模型，而是来自一个能够动态组装上下文的系统。
案例2：上下文冗余的陷阱
是不是把所有信息都丢给模型就好了？当然不是。在一个需要几天完成的大型代码库重构任务中，如果简单地将每一次交互（指令、文件读取、编译错误、工具调用）都累加到上下文中，会产生灾难性后果：
- 性能下降：早期无关紧要的细节会稀释当前步骤的核心信息，造成“上下文干扰”。
- 成本与延迟激增：上下文线性增长，API调用成本失控，响应变慢。
- 系统崩溃：当信息总量超过模型的上下文窗口上限，将导致“上下文溢出”，任务直接失败。
因此，上下文工程不仅要解决“信息不足”的问题，更要解决“信息过载”的挑战。
四、如何实施上下文工程：四大核心实践
业界已经总结出了一套系统性的应对框架，可以分为四个部分：写入（Write）、选取（Select）、压缩（Compress）和隔离（Isolate）。
1. 写入 (Write)
将上下文持久化，超越窗口限制，以便未来按需取用。
- 会话内写入 (Session-level Write)：将中间思考、计划等写入临时的“草稿纸（Scratchpads）”，用于管理当前任务的复杂性。
- 持久化写入 (Persistent Write)：将用户偏好、关键事实等长期有价值的信息存入外部记忆系统（如向量数据库），实现跨会话的知识积累和“成长”。
2. 选取 (Select)
在每次模型调用前，从所有可用信息源中，动态拉取与当前子任务最相关的信息，保证上下文的信噪比。
- 确定性选取：根据预设规则加载上下文（例如，固定加载项目根目录下的某个配置文件）。
- 模型驱动选取：利用模型自身的能力筛选海量信息源。
- 检索式选取：最主流的方式，通过相似度检索（RAG的核心）从记忆或知识库中选取信息。
3. 压缩 (Compress)
在信息进入上下文窗口前进行压缩，用更少的Token承载最核心的信号。
- 自动压缩 (Auto-compact)：在上下文窗口接近溢出时，自动总结历史对话，保留最重要的部分。
- 修剪策略 (Trimming)：如硬截断超过长度限制的历史记录，但这可能导致语境丢失。
4. 隔离 (Isolate)
这是一种系统架构层面的策略，通过在多信息流之间设置边界来管理复杂性，可以视为一种跨信息流的宏观压缩。
- 核心思想：由子流程先行消化海量原始信息，仅向上层提交关键的、压缩后的要点。
- 经典应用：多Agent架构。子Agent作为领域专家，在各自领域内隔离工作，然后将提炼后的洞见提交给主Agent。这极大减轻了主Agent的认知负担，避免了上下文干扰和冲突。
- 压缩 vs. 隔离：压缩作用于单一信息流，提升其内在信息密度；隔离作用于多条信息流，管理系统复杂性。一个成熟的系统往往会同时运用这两种策略。
五、结论：从“提示词”到“系统”的思维转变
上下文工程并非一个空洞的概念炒作，而是AI应用从“演示”走向“工业级”所必然产生的开发哲学。我们的工作重心，正不可逆转地从“如何找到那句完美的提示词”，转向“如何设计一个能够为模型在每一步都动态组装出完美上下文的、健壮可靠的系统”。
最后，再回看模型上下文协议（MCP），我们会恍然大悟。MCP本质上是为“行动性上下文”和部分“信息性上下文”的交互提供标准化的接口，让Agent能更顺畅、安全地与外部工具和数据通信。因此，MCP正是实现稳健上下文工程所必需的关键基础设施之一。
归根结底，请记住：无论是精巧的提示词、强大的RAG，还是标准化的MCP，它们都指向同一个目标——在模型做出决策之前，为它准备好一份恰到好处的上下文。
希望本文能够帮助你更好地理解上下文工程这个概念。感谢阅读！