来源：市场资讯

（来源：运筹OR帷幄）

在应用AI领域，经过几年的发展提示词工程已经占据了中心位置，随着提示词的进一步发展一个新的术语逐渐凸显出来就是 上下文工程（Context Engineering）。上下文工程要解决的核心问题是 如何有效配置上下文，才能最有可能让大模型产生我们想要的行为？

上下文工程 vs 提示词工程

你可能会说上下文不就是提示词吗？他们有什么区别吗？ 确实上下文工程可以看作是提示词工程的自然的一种演进。提示词工程是为了让大模型得到最优输出结果而编写和组织LLM指令的方法。

上下文工程是在LLM推理期间，用于整理和维护最优token集合的全部策略，其中包括在prompt中出现的信息，也包含那么没有直接出现在prompt但是会进入上下文窗口的其他信息。

他们两者的区别更多体现在：提示词工程更多的是一次性的，一个好的提示词确实可以让大模型聪明一下子。在LLM早期的应用中，大多数场景并不复杂，类似于日常聊天这种1-2次对话就可以解决问题的场景下，提示词工程已经是足够了。

随着我们开始采用LLM来处理更加复杂的问题，同时我们开始构建强大的agent的时候，我们不可避免地就需要LLM进行很多轮推理，这个时候仅仅依靠1-2次提示词就不够用了，我们需要能够管理整个上下文的状态的策略，包括系统prompt, tools，MCP，外部数据和历史消息等。

看到这里那你可能又会说这也不难啊，我把所有的信息都加到prompt里边都甩给大模型去处理就好了啊，也就是信息多一点，工具复杂一点嘛。问题没有这么简单，这就要讨论到一个关键的现象就是上下文腐烂的问题。

上下文腐烂问题

尽管LLM体现出了很牛逼的能力，主流的一些大模型也拥有越来越长的上下文窗口，但我们还是可以敏锐地观察到：当在同一个窗口对话的上下文越来越长的时候，LLM会逐渐忘记前面说过的内容，LLM的回答也越来越混乱，回答的速度也会越来越慢。这种现象被称之为上下文腐烂问题（Context Rot）: 随着上下文窗口中的token数量增加，大模型准确回忆起上下文中的相关信息的能力会下降。

虽然不同模型在这种能力的退化程度上有所差异，但这一现象在各种大模型中都普遍存在。就像人类有有限的工作记忆容量一样，LLM 也有一种“注意力预算”，它在解析大量上下文时会被消耗。每增加一个 token，都会在一定程度上耗掉这笔预算，因此我们就更需要精心筛选哪些 token 应该提供给 LLM。

这种注意力稀缺来自 LLM 的底层架构约束，我们知道当今的LLM无一例外都是基于 Transformer 架构，Transformer 让上下文中的 token 两两发生 attention 交互。这会在 token 之间形成 级别的成对关系。这是导致上下文腐烂的根本原因。

我们从Transformer的原理出发来进一步解释这个事情：对于给定输入的序列

每个 token 先被映射成向量表示。然后在某一层自注意力中，每个 token 会生成三个向量：

  • Quary:

  • Key:

  • Value: 对于第个位置，它会看到所有其他位置的key, 与自己的quary做匹配分数，即如下表达式：

然后再经过softmax:

最后得到该位置的输出：

这意味着：第个token的表示是对整个上下文所有token的加权汇总。如果序列长度是 , 观察式（1）我们很容易发现 每个位置都要和其他位置做相似度计算，这就是我们前文提到的“token 之间形成 级别的成对关系”。

然后观察式（2）我们发现对于某一个位置来说，它要在所有可见token里边分配注意力权重。那么当上下文很短时，可竞争的候选项少，真正重要的信息更容易脱颖而出。反之当上下文很长时，候选项暴增，模型就会面临一个更难的问题：

到底该把注意力分配给哪几个token?

哪怕真正有用的信息仍在窗口里，它也可能因为：

  • 被许多表面相似但无关的 token 干扰

  • 中间夹杂大量冗余内容

  • 在多头、多层传递中信号被冲淡 而没有获得足够权重。更准确说是：随着上下文的增长，干扰项会以平方级别变多，相关性判别难度大大上升。

但是要注意的是上下文不是简单的越长越差，而是存在边际收益。不是说上下文一长就一定坏。长上下文的价值也可能会非常大，因为它确实可以让大模型：

  • 看到更多证据

  • 跨文档推理

  • 做更复杂的 agent 任务 真正核心的问题的是：额外加入的上下文，边际收益会递减；当新增内容的信号密度不高时，就可能开始拖累性能。

所以关键不在于“上下文长不长”，而在于：

  • 新加的 token 是否真的有用

  • 结构是否清晰

  • 是否可检索

  • 是否经过压缩与筛选

  • 是否保留了最关键状态

这也正是原文强调 context engineering 的根本原因。

如何解决上下文腐烂的问题

既然 LLM 受制于有限的注意力预算，好的上下文工程就意味着：

找到尽可能小、但信号最强的一组 token，使其最大化实现目标结果的概率。

长时任务要求 agent 在较长动作序列中保持连贯性、上下文一致性和目标导向行为，而所需 token 总量往往会超过 LLM 的上下文窗口。对于持续数十分钟到数小时的任务，如大型代码库迁移或复杂研究项目，agent 必须采用专门技术来绕开上下文窗口大小的限制。

等待更大的上下文窗口，看起来似乎是一个显而易见的策略。但在可预见的未来，上下文窗口无论多大，对想要构建强大 agent 的场景来说，依然会受到上下文腐烂的问题。

解决策略1：压缩

压缩是指：当一段对话接近上下文窗口限制时，对其内容进行总结，并在新的上下文窗口中重新开始，使用这个总结后的版本。

这其实就是类似于写摘要一样，论文全文太长了没时间看，我们就读一下摘要，摘要本质上就是对冗长的全文的一种压缩。

压缩一定是有损的，它会丢失一些细节信息。压缩的艺术在于判断什么该保留、什么该丢弃。过于激进的压缩可能会丢失细微但关键的上下文信息。

解决策略2：结构化笔记

结构化记笔记，也称为 agent memory，是一种让 agent 定期把笔记写入上下文窗口之外的持久存储的技术。这些笔记之后可以在需要时重新拉回到上下文中。

这种策略以很低的开销提供了持久记忆。Claude Code 会创建待办事项列表；你的自定义 agent 也可以维护一个 NOTES.md 文件。这种简单模式使 agent 能在复杂任务中跟踪进展，维持关键上下文与依赖关系，而这些内容否则很可能在几十次工具调用之后丢失。

这一点其实和人类思考问题的模式非常相似，大脑不需要记忆所有信息，很多信息都可以通过记笔记的方式来存储，需要用的时候翻看笔记就行了。

解决策略3：子 agent 架构

子 agent 架构提供了另一种绕开上下文限制的方式。与其让单个 agent 试图维持整个项目的全局状态，不如让多个专门化的子 agent 各自处理聚焦任务，并拥有各自干净的上下文窗口。主 agent 负责维护高层计划与协调，而子 agent 负责执行深入的技术工作，或使用工具寻找相关信息。

每个子 agent 都可能进行大量探索，消耗数万 token 甚至更多，但最终只返回一份压缩提炼后的摘要，通常仅有 1000–2000 token。

这种方法实现了清晰的关注点分离——详细搜索上下文被隔离在子 agent 内部，主 agent 只专注于综合与分析结果。

类比到人类的话，主agent就像团队的leader，子agent就像团队成员。这样可以让每一个团队成员都专注做某一个事情，然后团队leader负责管理大家就行。

总结

上下文工程代表了我们使用 LLM 方式的一次根本性转变。随着模型越来越强，挑战不再只是写出完美 prompt，而是要认真策划：在模型有限的注意力预算下，究竟该让哪些信息进入上下文。无论你是在构建长时任务所需的压缩机制、设计 token 高效的工具，还是让 agent 即时探索环境，指导原则都是一样的：

找到最小的一组高信号 token，使它们最大化你想要的结果。

随着模型进步，我们讨论的这些技术也会继续演化。我们已经看到，更聪明的模型需要的显式工程引导更少，从而让 agent 能以更高自主性运行。 但即使能力不断提升，把上下文看作一种珍贵而有限的资源，仍将是构建可靠、高效 agent 的核心。

参考文献

【1】Effective context engineering for AI agents https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents