一文读懂上下文工程(Context Engineering)

最近在深度使用Claude Code作为主力编程工具，工作过程中，与自己原来使用的github copilot、Cursor以及Trae等AI Coding工具对比，效果非常好。看过一些资料讲Claude Code在上下文管理上的特点，但是都没有讲得太透。

节前，Anthropic发布了一篇研究博文 Effective context engineering for AI Agents^[1]，从Claude Code开发者的角度深入讲解了他们对上下文工程的理解，很有启发。

结合自己的实际工作，再加上最近看到的一些资料，在本文中以Anthropic的这篇文章为纲，写写自己的理解。

什么是上下文（Context）？

大模型(LLM)是一个概率模型，它只能根据你的输入，通过预测下一个token的概率分布，来生成文本。

在深入分析前，有一点需要明白，所有的语言模型都是无状态的(Stateless)。这意味着，模型在生成文本时，只依赖于当前输入的token，而不依赖于之前的token。

但是就像我们人类平时沟通一样，如果没有足够的信息，我们也很难准确地把握对方的意图，这时我们一般会多问几个问题，了解一下前因后果，帮助自己做些判断。

大语言模型也是这样的，它如果对你问的问题了解的更多，那么它的回答也更加准确、更有针对性，帮助可能也更大。

而我们添加给模型的额外信息，就叫做上下文（Context）。大概的形式有以下几种。

用户提示(User Prompt)

我们平时在电脑上或手机上使用豆包、混元、Deekseek时，一般的用法是写一个问题或指令，模型会给予一个应答。

而如果我们直接上来问"我是谁"，那么它就没有办法回答了。

我们的提出问题就叫做用户提示(User Prompt)。

而在多轮对话中，User Prompt与模型的回答，共同组成对话历史，它是上下文构成的基础。

除了对话的历史(History)，为了让大模型的输出更加有效和有帮助，我们也可以对User Prompt进行优化，从而让模型更好地理解我们的意图和需求。

而优化的方法，其实就是在User Prompt中添加一些额外信息，让模型了解更多的语境（其实就是上下文Context）。

比如，界定受众的人群，让它按我们要求的方式回复：

在没有界定"5岁孩子"这个语境时，它的输出只是非常普通的科普文，而给5岁孩子讲解时表达要更加活泼有趣。

系统提示(System Prompt)

如上所述，通过对话历史可以让大语言模型更加了解我们，而如果我们想让模型只按某种角色与我们交流，那么这里我们可以使用系统提示(System Prompt)。

现在大多数工具（豆包、混元、Deekseek等）不支持用户自定义的系统提示，只能使用默认的系统提示。而Gemini、OpenAI等也只是在开发者环境可以使用系统提示(System Prompt)。

但是，我们可以在对话开始时，先做一个基础设定，那么后续的很多回复都可以基于这个设定，它大致能起到系统提示的作用。

如，在DeepSeek中，对电影分类的表述进行情绪的判断：

在这个例子中，我们在第一条消息中，进行了一些基础的设定（这个是在通用工具中使用系统提示的一种折衷的方法），并使用少样本(Few Shot)方式，提供了一些说明，要求模型只按我们的要求回复（不要输出一大堆说明性的文字），那么它就会按我们的要求进行回复。

其实在Claude Code等coding agent中，后面会有更复杂的系统提示进行驱动。

消息历史(Messages History)

上面我们已经讲过在对话过程中，每次交互的组合形成了这次对话的历史信息。

再次提示：大模型是没有记忆的，它只是接受每次的请求，然后进行应答而已。

那么它是怎么了解到我们聊天的历史信息呢？

其实都是要我们组织好传送给它。

以Deepseek接口(它兼容OpenAI的接口标准，适用于大多数模型)的为例，在每次交互时，在接口中都会有一个messages字段，接口文档的定义如下：

messages是一个数组，它包含以下几类信息：

1. 1. System message。就是系统提示，每次调用时都需要上传给大模型。
2. 2. User message。就是用户提示。
3. 3. Assistant message。这个是模型的回答，每个User message会对应一个Assistant message。
4. 4. Tool message。这个是模型调用工具的回答，每个Tool call会对应一个Tool message。在后面会讲解。

一个完整的messages数组，就像下面这样：

这些所有的消息都需要开发人员在调用接口时每次都要重新上传给大模型。

这种会话的历史，一般是按用户登录后的会话进行保存，这样就可以在会话中每次将这些信息传送给大模型。

会话(Session)在技术上一般时与用户的登录状态绑定的，在用户退出后，就不会再保存了，这个称为短期记忆(Short-term Memory)。

这些信息也可以保存到后台的数据库中，从而实现长期记忆(Long-term Memory)。即以后可以根据用户的信息读取。

工具信息(Tool Use)

现在的大模型在一般回复时，都是使用预训练中的内部知识集，这些知识一般是有截止时间的，比如，下面的Deepseek：

最新版本的deepseek的内置的预训练知识是截止2024年7月的。你如果直接问它"现任的美国总统是谁？"，它会回答你是"拜登"（有兴趣可以自己试试)

在这种情况下，模型都是利用内部的信息进行回复的。而通过增加一些工具，就可以让大模型与外界进行沟通，从而获取一些最新的知识信息。

这就要使用到工具调用，即Tool Use。

现在所有的模型都会支持一些标准的工具，如代码执行、在线搜索等。

还有，现在的大模型都是文字模型，它可以做一些数学计算的工作，但是对于复杂的运算，它会出错，如下：

这里我们就需要给大模型提供工具来帮助大模型做一些工作。

比如，在deepseek中，我们可以打开"联网搜索"，问刚才那个同样的问题，如下：

可以看到deepseek会自动去网络上查询最新的信息，并且准确回复。

这个调用的过程，有些模型会开放给用户(如deepseek)，而有些模型不会开放给用户(如OpenAI等)，但是这些工具调用的过程生成的内容也是上下文的一部分。

现在流行的MCP(Model Context Protocol)本质上就是使用Tool Use的标准协议，使用MCP，各种服务都可以通过工具的形式提供给模型，而模型根据实际的情况进行调用。

外部知识(External Knowledge)

我们可以有两种方式将外部知识提供给模型：

1. 1. 预先准备好外部知识，如先查询数据库，然后将查询到的信息放在用户提示(User Prompt)中，提供给大模型，这是传统RAG(Retrieval-Augmented Generation)的方式。
2. 2. 让大模型在回答问题的过程中，自己去搜索必要的知识，这里使用的是特定的Tool Use工具。然后，这些Tool Use过程的信息就会放在messages作为上下文提供给大模型。这是Agentic的方式。

由于使用的方式都上面已经讲过，这里不再赘述。

推理信息(Reasoning Message)

去年年底，OpenAI O1的推出，将推理能力提升了一个台阶。而今年2月，deepseek将自己实现的推理过程开放给用户，结果整个业界带来了很大的震动。

现在几乎所有的主流模型在回复问题前，都会提供大段大段的推理信息，比如，

在大模型处理时，一般会要求不要将推理信息放在上下文(Context)中，

我们一般不会将这个推理过程放在上下文中，但是大家要知道有这样的信息产生。

上下文总结

根据上面的分析，我们有这几类信息组成了上下文的内容：

在Claude的博文中，通过上下文工程(Context Engineering)与提示工程(Prompt Engineering)的比较，

与编写提示这一离散任务相比，上下文工程是迭代的，并且每次我们决定要传递什么给模型时，都会进行策划阶段。

为什么要进行上下文工程（Context Engineering）？

上下文长度(Context Length)是有限的

大模型的上下文已经从最初的几K Tokens增加到现在的上百万 Tokens:

下表是一些主流模型上下文窗口长度的比较：

现在的主流大模型的上下文长度最大已经达到 1M Tokens。

但是，对于复杂的页面来讲，比如今年爆发的 Agent 应用，它往往会有多轮模型自主的工具调用，这意味着，上下文很快就会出现问题。

所以，上下文工程(Context Engineering)最核心的目标是在任务执行的过程中避免塞爆上下文空间。

上下文随着长度增加而变得复杂

在Claude的博文一开始就提到了这一点：

尽管 LLM 速度快，并且能够管理越来越大的数据量，但我们观察到，LLM 和人类一样，在某一点上会失去焦点或感到困惑。关于“大海捞针(needle-in-a-haystack)”式基准测试的研究揭示了上下文腐烂(context rot)的概念：随着上下文窗口中 token 数量的增加，模型从该上下文中准确回忆信息的能力会下降。

这说明了虽然上下文窗口越大，模型能够处理的信息就越多，但是，上下文必须被视为一种边际收益递减的有限资源。

也就是你虽然可以给模型塞100万 Tokens，但是很多时候，就也意味着它的回答质量的下降。

还有，在这项Chroma关于模型上下文内容研究^[2]中，评估了 18 个 LLM，包括最先进的 GPT-4.1、Claude 4、Gemini 2.5 和 Qwen3 模型。研究的结果显示，模型并不能一致地使用其上下文；相反，随着输入长度的增长，它们的性能变得越来越不可靠。

这些现实意味着，不仅是长度，深思熟虑的上下文对于构建强大的智能体至关重要。

更多的上下文失效的分析可以看这篇：Context Engineering：长上下文是如何失效的？

如何进行上下文工程(Context Engineering)？

Agentic模式的即时上下文策略

目前对模型的使用方式大致有以下几种：

而现在主流的智能体化的处理模式，其实就是一个循环，如Claude所讲：

在《构建有效的 AI 智能体》中，我们强调了基于 LLM 的工作流程与智能体之间的差异。自我们撰写那篇文章以来，我们逐渐倾向于一个对智能体的简单定义：在一个循环中自主使用工具的 LLM。

在这个过程中，大模型自主制定计划并且调用相关的工具完成指定的任务：

对于开发者，这个过程其实是可控的，而上下文工程就是在这个过程中，不断调整上下文，使上下文更加有效。

今天，许多 AI 原生应用都采用了某种基于嵌入的预推理时间检索来为智能体提供重要的上下文以供其推理。随着该领域向更具智能体化的方法过渡，我们越来越多地看到团队用“即时”上下文策略来增强这些检索系统。

与预先处理所有相关数据不同，采用“即时”方法构建的智能体维护轻量级标识符（文件路径、存储的查询、网页链接等），并使用这些引用在运行时使用工具动态地将数据加载到上下文中。

上下文处理的方法

为了生成有效(Effective)的上下文，Claude的博文在博文中提供了几种方案：

压缩(Compaction)

压缩是指将一个接近上下文窗口限制的对话，总结其内容，并用该摘要重新启动一个新的上下文窗口的做法。压缩通常是上下文工程中驱动更好长期连贯性的第一个杠杆。其核心是，压缩以高保真度的方式提炼上下文窗口的内容，使智能体能够以最小的性能下降继续工作。

压缩的核心就是减少上下文中不必要的信息，从而让模型得到更准确的上下文。

在这篇文章(Context Engineering: 如何修复上下文)中讲述了非常具体的方法：

• • 工具装载(Tool Loadout): 仅选择相关的工具定义添加到上下文当中。
• • 上下文修剪(Context Pruning): 从上下文中移除无关或不必要的信息。
• • 上下文摘要(Context Summarization): 将累积的上下文浓缩为精简的摘要。
• • 上下文卸载(Context Offloading: 将信息存储在大语言模型的上下文之外，通常通过用于存储和管理数据的工具来实现。

是进行压缩处理的各种方法。这种的权衡非常重要。

压缩的艺术在于选择保留什么与丢弃什么，因为过于激进的压缩可能会导致 subtle 但关键的上下文丢失，而其重要性只在稍后才显现出来。

在Manus的这篇论文(AI代理的上下文工程：构建Manus的经验教训)中，写的使用遮蔽(Mask)(深入学习Manus最新论文: 2个必学基础，1个惊人洞察)，就是对工具装载的一种实现方式，因为工具的信息不仅是上下文中的一部分(在调用接口中，工具是需要通过参数提供给模型的)。

而工具数量太多，也会给大模型造成困扰，从而在选择工具时无法精准选择。

这些都需要在迭代循环的过程中根据实际的情况进行选择。

结构化笔记(Structured note-taking)

这点在Claude Code中有很强的感受。

在整个编程过程中，Claude Code会生成大量的markdown文件，比如技术要求、业务说明，还有过程中的Todo list，都是使用文件方式放在工作目录下。

这种策略以最小的开销提供了持久的记忆。就像 Claude Code 创建一个待办事项列表，或者您的自定义智能体维护一个 NOTES.md 文件一样，这个简单的模式允许智能体跟踪复杂任务的进度，保持关键的上下文和依赖关系，否则这些信息会在数十次工具调用中丢失。

个人认为，我们还有各种持久化的工具可以使用，如保存在SQL数据库、向量数据库或各种存储系统中。

而在保存，以及相应的检索时，都需要根据当前的具体情况，即时进行处理。

子智能体架构

在这篇文章中也提到相似的建议，即上下文隔离(Context Quarantine: 将不同的上下文分隔在各自专用的线程中。

它的核心是，将一个大的任务分解为小的任务，小的任务由一个专门的智能体完成，这样对于这个智能体来讲，只需要知道它需要知道的一些信息即可，即完成特定的任务。

在完成特定的任务后，将结果提交给一个主控的智能体对各个子智能体的数据进行汇总，分析，整合，最后生成最终的结果。

子智能体架构提供了另一种绕过上下文限制的方法。与其让一个智能体试图在整个项目中维护状态，不如让专门的子智能体用干净的上下文窗口处理集中的任务。主智能体用一个高层次的计划进行协调，而子智能体则执行深入的技术工作或使用工具来寻找相关信息。每个子智能体可能会进行广泛的探索，使用数万甚至更多的 token，但只返回一个浓缩、提炼过的工作总结（通常是 1,000-2,000 个 token）。

结论

不论是上下文工程(Context Engineering)，还是提示工程(Prompt Engineering)，目的都是向大模型提供更有针对性，更有价值的信息，在这种情况下大模型才能有更好的输出。

我们平时在使用各种聊天工具时，多了解一些提示工程，可以在不设置系统提示的情况得到更好的回答。

而在进行AI系统开发，尤其是智能体架构的开发时，针对业务特性进行的数据内容、数据保存形式等的设计至关重要，因为它是组织模型上下文的核心。

与本文相关的一些文章：

• Context Engineering：不要构建多代理

• Context Engineering: 来自LangChain的剖析

• Context Engineering: 为提示词引入工程严谨性

• Context Engineering：长上下文是如何失效的？

• Context Engineering: 如何修复上下文

• AI代理的上下文工程：构建Manus的经验教训

• 深入学习Manus最新论文: 2个必学基础，1个惊人洞察

• Anthropic: 如何构建多智能体研究系统

• Google: Agents白皮书

• OpenAI:构建Agent的实用指南

• Anthropic:构建有效的Agent

引用链接

[1] Effective context engineering for AI agents: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
[2] Chroma关于模型上下文内容研究: https://research.trychroma.com/context-rot