一文看懂上下文工程（Context Engineering）

为什么最近大家都在聊 Context Engineering？

这个词似乎突然爆火，但这个概念并不是新的概念，而是从大语言模型诞生并进入应用层之后一直存在。

只不过随着 AI 能力的发展和实际应用需求的提升，它终于被重新放到了聚光灯下。在 Andrej Karpathy^[1] 6 月 25 日的推文助推下，更多人开始关注它。

Andrej Karpathy 关于 Context Engineering 的推文截图

1. TL;DR

对于不想看全文的，可以直接看摘要：

本质来说上下文工程（Context Engineering）和提示词工程（Prompt Engineering）是一个东西，前者是一个更加 fancy 的叫法，也从狭义的提示词扩大到上下文的维度，涵盖更加广的上下文工程实践。

用 Agent 的例子来说明，就是 Agent 每次执行的时候都需要有合适的上下文（太多太少不够准确的都不行），这些上下文可以是预设的（比如预先写好的系统提示词），也可以是运行时获取的（通过工具调用外部获取），配合一些诸如 RAG、Memory、读写、Compact/Compression 等手段可以更好地管理上下文，因此上下文工程就是如何将合适的信息填充到有限的上下文里的艺术和科学。

2. Prompt vs Context

在与大语言模型（LLM）打交道的过程中，我们其实一直在围绕两类输入工程打转：提示词工程（Prompt Engineering）和上下文工程（Context Engineering）。

前者更像是在告诉模型它是谁，而后者是喂给模型它需要知道的相关信息

其实非常好理解，在基于 LLM 的应用运行期间，需要一些预设背景信息，且拥有合适的上下文信息，尤其是现在以 Agent 为主的应用，多轮次交互中每一轮次都需要不同的、合适的且准确的上下文信息，才可以最大化 Agent 的效果。

3. 提示词工程 Prompt Engineering

最早底层模型能力还没有被大幅提升的时候，大家都在利用提示词挖掘底层模型的能力，我还记得当时 Sam Altman 还说过写提示词这个东西有些人很有天赋，一下就知道怎么写。

早期大家都是管理一堆的提示词，用于不同的使用场景，这也衍生出了一些诸如：GPTs、Character.AI、星野等这些"Cosplay"的 AI 应用，这类应用本质上就是允许用户去编写提示词来驱动模型以某种形式去回复用户的问题。

通过提示词控制也是相对符合直觉的一个行为，提示词工程里还有一些更加高阶一点的手段，比如：

少样本提示（Few-shot Prompt）：给出几个类似的示例，引导模型模仿
零样本提示（Zero-shot Prompt）：不给任何示例，让模型自主决定输出
思维链提示（Chain-of-Thought Prompt）：引导模型一步步说出来的自我思考过程，重点是提示格式而不是答案示例

少样本提示（Few-shot Prompt）：

文本：我太喜欢这部电影了！情感：正面
文本：这道菜太难吃了。情感：负面
文本：还行吧，我觉得。情感：

零样本提示（Zero-shot Prompt）：

文本：还行吧，我觉得。情感：

思维链提示（Chain-of-Thought Prompt）：

文本：还行吧，我觉得。  情感分析：我们来分析一下这句话。"还行吧" 表示中等、不好不坏，"我觉得" 表示语气不确定或者没有强烈的情绪。整体来看，这句话情绪不强烈，偏向中性。  情感：中性

因此本质上提示词工程就是在告诉模型开始处理任务之前的一些预设，可以很有效地帮助模型做一个锚定，在此之后就让模型在这个范围内和方向上自我发挥。

在这个阶段模型没有任何外部知识，也没有记忆等，全部依赖于提示词本身。

4. 上下文工程 Context Engineering

上下文窗口一直是模型能力的重要衡量指标之一，原因就是 上下文对于模型应用效果非常关键

前面提到最早通过较为直觉的方式来写提示词，随着底层模型的发展和模型应用的普及，对于效果的追求也越来越高，从最早的泛娱乐式消费，到生产力提升的需求，上下文是相对于模型微调来说更加低成本且可操作性更高的方式来提升整体的效果。

在上下文工程领域延伸出很多手段：

RAG（Retrieval-Augmented Generation，检索增强生成）：通过语义化向量搜索，从知识库中检索与用户问题最相关的文档片段，并拼接到上下文，提升回答准确性
Memory（记忆）：引入长短期记忆，帮助模型回顾过往记录
Tool Calling/MCP（工具调用）：通过结构化提示词告诉模型如何调用预定工具（如数据库查询、API 调用等）来获取外部信息，是一种与世界连接的输入增强方式

上下文工程的主要手段示意图

我们可以参考 Context Engineering for Agents 里所做的分类（主要针对 Agent 语境下的分类）：

写上下文（Write Context）：上下文窗口有限，需要把过往的上下文存到外部，必要时召回
选择上下文（Select Context）：从已经保存的数据中选择合适的部分注入到上下文窗口中，帮助 LLMs 更好完成任务
压缩上下文（Compressing Context）：上下文超出的情况下，对上下文进行合理的压缩保留必要的最小内容
隔离上下文（Isolating Context）：拆分并分配不同的上下文给不同的子智能体或子任务，提高效率和清晰度

目前大家都在上下文工程领域持续深耕。简单说，就是底层模型的性能提升是取决于几家头部模型厂商的，在有限的情况之下，应用层都是在拼上下文处理能力以及用户交互的 UI/UX。

因此我们其实可以留意到目前 AI 应用都是围绕这两点展开的，如何帮助模型更好的获取上下文去完成用户的需求 + 如何用更好的交互方式让用户与模型交互。而 UI/UX 已经是一个体系化的学科，所以一个 AI 应用能否足够好用，就取决于上下文工程的能力。这样想我们就能知道为什么上下文工程如此重要且受关注面这么广。

我们可以看到早期的 RAG 就是一种相对固定的外部信息获取，一般我们在 RAG 里做召回会用 topk，也就是最匹配的 k 份材料（chunk）给到模型，本质上就是因为上下文是有限的，如何获取最合适的材料，就是 RAG 里需要不断去摸索的方向。

记忆模块也是一部分，现在也有很多人在这块投入研究，我觉得是一个非常值得投入研究的领域，记忆可分为长时记忆和短期记忆，通过 ChatGPT 这个 APP 我们也可以看得到一些实践，现在它可以召回以前的对话（本质上也是向量搜索这类方式），这样就是通过对话来实现记忆 recall 的一个过程，同时它也会在日常对话中去记录一些关键点到记忆条目里，这样就能建立一个长期记忆（最早记忆是会满的，我觉得没理由让用户去手动删除和管理记忆，现在就没有这个问题了）。

前段时间疯狂流行的 MCP，也就是和以前的 Function Tool，或者 Tool Calling 一样，就是让模型能调用一些预设的工具，去获取对应的信息来做决策，也是上下文工程的一种，这个方向是对于现有服务和基础设施，甚至是物理世界交互的一个标准接口，所以意义深远。

总体而言，上下文工程涵盖的就是很简单的东西，给到模型的上下文内容，但是期间涉及的手段有很多值得研究和发展的领域和方向。这个也为未来 AGI 方向提供了一个必要的基础。

5. 界限并没有那么清晰

通常系统提示词不太会变，这个是有别于上下文的，否则严格意义上来说，提示词也是上下文的一部分，所有模型能看到的内容都统称为上下文。因此实际上现在讨论 Context Engineering 并不是一个全新的概念，而是自大语言模型诞生之初就一直存在的，只不过现在正变得规范化、专业化和学科化。

现在越来越多人认识到，随着底层模型能力的提升，Prompt 的需求程度在降低，现在演变出一个更加 fancy 的叫法，就是上下文工程 Context Engineering，从更加广义的角度来定义，上下文工程自此进入人们的视野，也使得越来越多人开始关注它。

因此可以认为这两个工程都是为了同样的目的：目标很明确，就是通过合理地处理组装上下文，让模型效果最大化

举例来说，我们来看看 Claude Code 的系统提示词（System Prompt）：

Claude Code 系统提示词截图（一）

Claude Code 系统提示词截图（二）

Claude Code 系统提示词截图（三）

从 Claude Code 的 System Prompt 中可以看出，它融合了 角色设定、少样本提示、工具调用 等手段，同时通过 Tool 使用能力动态扩展上下文，比如支持查看文件、编辑代码、提交 Git、拉取图片等。这种设计结合了提示词工程与上下文工程，是一种典型的 Prompt + Context 混合型应用，本质上构建出了一个具备自主决策能力的 Agent

6. 新学科的出现

Context Engineering for Agents^[2] 这篇文章中有一段话，我觉得描述得很好：

As Andrej Karpathy puts it, LLMs are like a new kind of operating system ^[3]. The LLM is like the CPU and its context window ^[4] is like the RAM, serving as the model’s working memory. Just like RAM, the LLM context window has limited capacity ^[5] to handle various sources of context.

And just as an operating system curates what fits into a CPU’s RAM, “context engineering” plays a similar role. Karpathy summarizes this well:

[Context engineering is the] “…delicate art and science of filling the context window with just the right information for the next step.”

把 LLMs 类比成新的操作系统（OS），而上下文窗口（Context Window）则是 LLMs 的内存，内存是有限的，因此需要用一些辅助手段在磁盘、网络间去置换合适的数据到内存里，上下文窗口也是同理，在运行时需要合适的数据加载到上下文窗口内，才可以让 LLMs 发挥最大效果。

随着 LLM 的流行和应用，未来会涌现更多不同的学科，我觉得上下文工程就是其中一个方向，是一门为 LLM 设计和管理输入上下文的新兴技术学科。可以预见，在未来的一段时间内，随着 AI 工程化的复杂程度提升，LLM 与外界交互变多的情况下，上下文工程是一个极其重要的研究方向，可以进一步决定 LLM 能发挥出多大的潜力和能力。

从应用到具身智能，都离不开模型对于外界信息的获取和感知，外界信息是无穷多的，如何在有限的上下文内把最有价值的信息提供给模型，决定了这个学科研究的方向。

在未来，Context Engineer 也许会成为 AI 团队中的关键角色之一，就像数据工程师之于机器学习团队那样重要。

如果说 Prompt 是语言的编程，那么 Context Engineering 就是系统级调度与资源管理，决定了模型能否发挥巨大的潜力