上下文工程：它是什么以及我如何用它构建更好的AI智能体

目录

发布于2026年7月。

TL;DR： 提示工程关注词语选择；上下文工程关注信息架构。你拥有有限的上下文窗口，每个token都是一种权衡。我将智能体上下文分为四层：系统提示、对话历史、检索内容和工具输出。将窗口视为预算而非空白画布，比切换模型更能提升可靠性。

[运营者说明] 我管理着30多个生产环境中的智能体。过去一年中最有效的改进既不是更好的模型，也不是更复杂的框架——而是更有意识地控制什么进入上下文窗口、什么保持在外。上下文工程现在是我评估智能体工作时寻找的核心技能。

大多数人仍然将”提示工程”视为与AI工作的关键技能。提示工程是真实存在且重要的。但它只是更大学科的子集——将其视为全部工作正是许多在演示中表现良好的智能体在生产中崩溃的原因。

为什么”提示工程”成了错误的框架

“提示工程”暗示关键杠杆是你写在系统提示或用户消息中的文本。花足够的时间精心制作正确的指令、正确的措辞、正确的格式，模型就会按你需要的方式行事。

这在一定程度上是正确的。一个写得好的系统提示是必要的。但模型的行为是由上下文窗口中的所有内容决定的——不仅仅是你的系统提示。它受以下因素影响：

• 对话历史（之前回合中发生的事）
• 你检索并注入的文档或数据
• 模型迄今为止看到的工具调用结果
• 每段信息的token数量和位置

如果你只考虑提示措辞而忽略了填充上下文窗口的其余内容，你在优化一个输入的同时，让其他输入处于无管理状态。这就是为什么”上下文工程”是严肃智能体工作更准确的框架。

上下文工程究竟是什么

上下文工程是关于决定哪些信息进入模型的上下文窗口、以何种顺序、在对话的哪个时间点的学科。

上下文窗口是模型的工作记忆。它是有限的。你放入的每个token都会挤出其他东西——或增加成本。与人类工作记忆不同，模型无法在窗口之外”查找某些内容”（除非你给它工具来做到这一点）。它所看到的就是它拥有的一切。

上下文工程是将该窗口视为需要有意管理的资源的实践：

• 模型需要知道什么来完成这一步？
• 它在之前的步骤中需要知道什么，但现在不再需要？
• 什么在运行之间是稳定的，什么是每个请求动态变化的？
• 窗口中每段信息应该出现在哪里？

这些不是关于提示措辞的问题。这些是信息架构问题。答案对智能体可靠性的影响与模型选择一样大。

我设计的四个层次

我构建的每个智能体都有四个不同的上下文层。我单独考虑每一个。

第1层：系统提示

这是稳定的、独立于回合的基础。它定义了智能体是谁、能做什么、不能做什么，以及应该如何处理边界情况。

大多数人在这里犯的错误是写一次系统提示然后将其视为完成。实际上，系统提示需要明确回答三个问题：

1. 这个智能体是做什么的？（模型需要精确的范围，而非模糊的使命。）
2. 当输入模糊或不完整时应该怎么做？
3. 它永远不应该做什么？（负面约束很重要。）

保持系统提示最小化。每个不必要的句子都是与动态内容竞争的开销，而真正的推理发生在动态内容中。

实用提示：如果你在使用Claude API，在系统提示上使用cache_control。一个大型稳定的缓存系统提示每次请求的成本约为未缓存的10%。

第2层：对话历史

在多回合智能体中，对话历史是动态的，每个回合都在增长。没有管理，它会成为上下文膨胀的最大驱动因素。

问题：早期回合包含模型不再需要的信息。保留所有这些信息会浪费token，并可能因为给模型提供过时的上下文而使其感到困惑。

我的做法：

• 当历史超过阈值时截断或总结旧回合。
• 只保留仍然相关的工具调用结果。
• 永远不要让历史在长期运行的智能体中无限增长。

第3层：检索内容

这是将平庸智能体与优秀智能体区分开的层次。大多数智能体需要在运行时提取外部数据。

我应用的两个原则：

只检索与当前步骤相关的内容。 当前步骤只需要一个部分时，不要注入50页的文档。

位置很重要。 上下文开头和结尾的信息比中间的信息受到更多重视。如果有一段检索内容模型绝对必须使用，不要把它埋在长注入的中间。

第4层：工具输出

在智能体循环中，模型调用工具并获得结果。这些结果在上下文窗口中积累。与对话历史不同，人们很少考虑管理它们。

解决方案相同：工具结果实现其目的后，你不需要将其保留在窗口中。在多步骤智能体中，我向前传递”我们迄今为止建立了什么”的结构化摘要，而不是每个先前步骤的原始输出。

上下文预算：包含什么和删减什么

我使用一个简单的心理模型：上下文窗口是预算，每个token是一笔支出。在每个智能体回合之前，我问：

• 模型现在需要知道什么来执行这一步？
• 我可以省略或总结什么而不丢失任何重要内容？
• 各层之间有什么重复？

目标是用每步最高信噪比的信息填充窗口，而不是面面俱到。

我在生产中犯的三个上下文工程错误

1. 稳定前缀中的浮动时间戳。 我在系统提示顶部放了当前日期：{{日期}}。该字符串每天都会改变，这会悄悄地每24小时使我的提示缓存失效。将易变信息——时间戳、用户ID——移到稳定前缀之后的上下文末尾。

2. 将工具输出视为只追加。 我运行智能体循环，其中每个工具调用结果都保留在上下文中。到第8个回合，模型从80%由过时工具输出构成的上下文中推理。

3. 在上下文更改时跳过评估。 上下文更改就是模型行为更改。我现在对上下文更改运行与对提示更改相同的评估框架。

我实际的上下文工程工作流程

在写一行智能体代码之前，我先草拟上下文层：

系统提示：       ~500 tokens，稳定，已缓存
历史预算：       ~2000 tokens最多，每步后总结
检索上下文：     每步~1000-3000 tokens，仅相关片段
输出预算：       仅当前步骤，向前总结传递

模型选择问题在这之后才来。一旦我知道需要做什么上下文工程，我就选择在正确的上下文配置下维持可靠性标准的最便宜模型。

常见问题

提示工程和上下文工程有什么区别？

提示工程专注于系统提示和用户消息的措辞。上下文工程是更广泛的学科：决定哪些信息进入完整的上下文窗口——包括对话历史、检索数据和工具输出——以何种顺序，以及以什么token成本。

我的系统提示应该多大？

尽可能小的同时保持具体。我对大多数智能体的目标是800 tokens以下。试图预见每个场景的系统提示最终会太长，模型无法可靠地读取。

上下文工程对某些模型比其他模型更重要吗？

对所有模型都重要，但对较小的模型风险更高。大型前沿模型有时可以从结构不良的上下文中恢复；预算更紧的较小模型则不能。

我如何知道我的上下文工程是否有效？

跟踪你对任何可靠性变化都会跟踪的相同指标：评估集上的成功率、每个成功结果的成本，以及按步骤的错误分布。

我应该始终压缩或总结历史吗？

对于短暂的事务性智能体：不需要。对于执行超过5-6次交换的多回合智能体：是的，始终如此。我使用的经验法则——一旦历史预算超过我总上下文预算的30%，我就开始总结。