什么是上下文工程？模型在回答之前接收到了什么

上下文工程是指设计语言模型在推理时接收哪些信息、以何种形式、按何种顺序以及保留多长时间。它比提示工程更广泛，因为模型上下文可以包括系统指令、用户消息、检索到的文档、工具结果、记忆、当前应用状态、示例、结构化数据和中间产物。目标不是最大化令牌数量，而是构建最小的有用上下文，保留当前任务所需的信息、约束和证据。

上下文工程真正意味着什么

每次模型调用都是在一个临时工作环境中进行的：当前指令、消息、检索到的证据、工具输出和状态，这些内容都适合放入活动上下文窗口。上下文工程就是有意构建该环境的学科。

关键词是有意。一个朴素系统只是把它拥有的一切拼接起来：完整历史、所有检索到的文档、每个工具响应和大型系统提示。一个经过上下文工程的系统会决定当前决策需要哪些信息，以及哪些信息应留在窗口之外直到需要时再使用。

这使上下文工程部分成为信息架构问题，部分成为运行时问题，部分成为评估问题。设计必须决定什么可以进入上下文、它来自哪里、哪个版本是当前的、冲突如何解决、保留多少细节以及结果如何测试。

最简单的例子

想象一个内部支持助手。用户问：“这个客户可以免费取消吗？”

模型可能需要五样东西：当前取消政策、客户当前合同类型、合同生效日期、相关例外规则以及用户的授权范围。

它不一定需要整个客户数据库、完整政策档案、每一次之前的对话或每一张支持工单。上下文工程就是选择并组装这五个有用部分，同时排除无关信息的过程。

从应用状态到模型上下文

1

1. 理解任务

对当前问题需要什么以及哪些信息类型可能影响答案进行分类。

2

2. 解析权威状态

读取不应从记忆中猜测的当前应用或业务状态。

3

3. 检索支持性知识

找到与特定任务相关的政策、文档或外部证据。

4

4. 应用资格和权限

排除当前用户或运行时不允许暴露给模型的数据。

5

5. 精简和结构化

删除重复内容，选择有用摘录，并保留关键元数据、条件和例外。

6

6. 排列上下文顺序

将指令、当前状态和决定性证据放在模型能够一致使用它们的位置。

7

7. 运行推理

模型接收组装好的上下文，并产生下一个答案或行动建议。

简单例子止步之处

真实系统更困难，因为某一步所需的信息可能在执行开始前并不已知。智能体可以通过工具发现新事实、创建中间文件、接收不断变化的外部状态，或跨越比一个上下文窗口更长的任务。

因此，上下文工程变得动态。第12步的上下文不应只是第1步上下文加上十一层累积输出。它应反映当前任务状态、仍然重要的决策以及下一步行动所需的证据。

什么可以进入模型上下文？

上下文工程与提示工程

提示工程和上下文工程解决不同层面的问题

	提示工程	上下文工程
主要关注点
典型范围
何时变化
典型失败
关系

Anthropic 明确将上下文工程描述为提示工程的自然演进，适用于模型必须与工具、外部数据、消息历史和长时间运行的代理状态协同工作的系统。这种实际区分很有用，因为写得再完美的提示也无法弥补缺失的权威数据或被矛盾状态污染的上下文。

上下文工程与检索

检索从外部语料库或来源中选择候选信息。上下文工程决定检索之后以及围绕检索发生什么。

检索器可能返回 30 个段落。重排序器可能将其减少到 10 个。上下文层可能选择四个段落，删除重复项，附加来源/版本元数据，将它们与当前应用状态结合，并将它们放在系统指令之后。

这就是为什么 RAG 系统可以检索到正确的段落却仍然回答得很差：失败可能发生在上下文组装期间，而不是检索期间。

上下文工程与记忆

记忆是在即时模型调用之外保留的信息，以便以后再次使用。上下文是实际加载到当前调用中的信息。

记忆系统可能包含数千个事实、笔记或先前的决策。上下文工程选择其中哪些应针对当前任务重新引入。在每一轮都加载所有记忆违背了拥有外部记忆层的目的。

这种区分对于易变状态变得至关重要。记忆中的项目状态或用户偏好可能有用，但在做出重要决策之前，可能需要重新读取当前的权威状态。

上下文工程与应用状态

应用状态是外部系统的当前状况：账户余额、工单状态、文件版本、工作流阶段、部署状态或任务进度。

状态可以摘要到上下文中，但摘要不是状态本身。对于重要操作，运行时可能需要在操作前立即重新读取权威系统，而不是信任模型先前可见的快照。

工具设计是上下文工程的一部分

工具不仅仅是为智能体提供能力。工具名称、描述、模式和结果都会成为模型可见的信息，从而影响决策。

Anthropic 当前的上下文工程指南强调使用 token 高效的工具，并警告不要使用功能重叠的臃肿工具集。一个连人类都难以区分的工具目录，模型也很难可靠地路由。

工具输出也需要上下文纪律。当智能体只请求一个错误条件时，却返回整个 20,000 行日志，会消耗注意力，并可能埋没决定性证据。

即时上下文与预加载上下文

提供信息的两种方式

	预加载上下文	即时上下文
方法
优势
风险
适用场景

Anthropic 描述了一种混合模式：一些稳定的上下文被预加载，而智能体在运行时检索额外信息。这是一种有用的架构模式，因为并非每个重要事实都值得在上下文窗口中永久驻留。

上下文是预算，不是存储系统

上下文窗口定义了容量。它并不保证每个 token 都会被同等有效地利用。模型必须在指令、历史、证据、工具和中间状态之间分配注意力。

因此，实际目标不是“填满窗口”，而是最大化有限注意力预算的效用。

Anthropic 将类似原则表述为：找到最小的、高信号的 token 集合，以最大化期望行为的概率。OpenAI 的上下文管理指南同样警告，未经整理的历史、冗余的工具结果和嘈杂的检索，即使对大型窗口也可能造成过载。

为什么更多上下文可能更糟

额外的上下文可能引入无关信息、过时状态、重复证据、矛盾指令或位置竞争。它还可能导致压缩系统丢弃后来变得重要的细节。

经典的“迷失在中间”研究表明，长上下文模型对信息的利用可能因相关内容出现的位置而异，当决定性信息被放在长输入的中间时，性能往往会下降。

这并不意味着长上下文本身不好。它意味着窗口内的可用性并不等同于可靠利用。

上下文排序应当是有意为之

上下文构建也是一个排序问题。关键指令、当前状态、决定性证据和任务特定约束不应被任意拼接。

并不存在适用于每个模型和任务的通用完美排序。因此，架构应测试重新排序证据是否会改变正确性，以及重要信息在现实上下文变化中是否仍然稳健。

一个稳定的答案在两条同等有效的段落交换位置后发生剧烈变化，这表明存在上下文敏感性，应当加以衡量而非忽视。

冲突的上下文需要明确的优先级

模型可能同时接收到旧政策和新政策、记忆中的偏好和当前的明确指令，或缓存的实时状态和实时API结果。系统不应期望模型从行文风格中推断优先级。

上下文工程应通过来源选择、元数据、排序或明确指令来编码优先级：当前权威状态覆盖过时副本；当前用户的明确指令覆盖较早的推断偏好；已批准的政策取代过时的草案。

压缩是上下文转换，而非无损存储

长期运行的系统最终需要裁剪、总结或压缩历史记录。压缩会创建先前上下文的新表示，使智能体无需重放每个令牌即可继续运行。

OpenAI的上下文管理示例使用裁剪和压缩来处理长时间运行的会话。Anthropic将压缩描述为在交互接近上下文限制时保持连贯性的主要技术。

困难之处在于决定哪些内容不能安全移除：未解决的任务、标识符、用户约束、安全边界、架构决策、异常情况、来源出处，以及使先前结论有效的条件。

保留有效性边界

重要结论应附带其仍然成立的条件：版本、日期、范围、假设、来源权威性以及未解决的分歧。

因此，上下文工程与答案有效性边界相关联。上下文组装器不应剥离决定证据是否仍然适用的元数据。

上下文工程也是安全边界

到达模型的数据已经跨越了一个重要的系统边界。因此，上下文组装必须遵守授权、租户隔离、保密性和数据最小化规则。

检索器在技术上可能找到当前用户无权访问的段落。正确的设计是阻止该段落进入模型上下文，而不是依赖模型忽略它。

工具输出也可能包含不可信的指令或对抗性内容。上下文工程应保留应用程序指令与外部数据之间的区别，使检索到的文本无法悄然获得指令权威。

一个实用的上下文工程架构

即使没有任何模块使用这个确切的名称，上下文组装器在概念上也很重要。在小型应用中，它可能只是普通的应用代码。在大型智能体平台中，它可能结合了会话管理、检索、记忆、工具中间件、压缩和策略执行。

一个实用的上下文构建策略

如何评估上下文工程

上下文组装是一个独立的 RAG 故障层

一个 RAG 流水线可能在检索上成功，却在下游失败。相关来源可能出现在第 2 位，但上下文组装器可能将其丢弃、截断、与过时的矛盾材料合并，或超出 token 预算。

这就是为什么应将检索轨迹与实际发送给模型的上下文进行比较。没有这种比较，上下文故障很容易被误诊为嵌入或模型故障。

原始实现证据

真相来源研究引擎：有界研究而非无限上下文

真相来源研究引擎将发现、获取、提取、验证、矛盾分析和综合分为有界的研究阶段，而不是将一个庞大的研究任务和所有累积材料发送到单次模型调用中。

其证据模型将来源、工件、主张、关系、矛盾和来源信息存储在模型上下文之外。模型可以接收当前研究步骤所需的子集，而持久证据保留在外部存储中。

这是一个具体的上下文工程模式：持久研究状态存在于模型窗口之外；活跃的模型上下文针对当前阶段重新构建。

Aaasaasa AI 客户端：运行时、权限和上下文是相互独立的关注点

Aaasaasa AI Client 将提供商/模型选择、运行时位置、工作区权限、本地资源和工具访问分离开来。这可以防止模型上下文成为授权或应用状态的所有者。

直接聊天和代理运行时可以具有不同的工具能力。工作区权限配置文件由运行时强制执行，而不仅仅是在自然语言上下文中描述。这一区别很重要：上下文可以告诉模型它应该做什么，而运行时仍然必须强制执行它实际被允许做什么。

这里的实现证据是架构分离，而不是声称本文中描述的每一种高级上下文管理技术都已经实现。

常见的上下文工程失败模式

常见误解

一个实用的上下文工程序列

从当前决策反向构建上下文

1

1. 定义下一个模型决策

明确模型在这一步必须回答、分类、规划或选择什么。

2

2. 识别所需事实和约束

列出能够实质性改变结果的最小状态、规则、证据和指令。

3

3. 解决权威性和权限问题

确定哪些来源是当前的、权威的，并且当前主体可以访问。

4

4. 按需检索或读取

获取必要证据和易变状态，而不是依赖过时上下文。

5

5. 降低噪声

去重、摘要或选择段落，同时不丢弃决定性例外或来源。

6

6. 结构化并排序

使指令、当前状态、证据和工具观察结果可以区分。

7

7. 适配 token 预算

优先使用高信号上下文，并将持久信息移到窗口之外。

8

8. 运行模型

在组装好的上下文上执行推理。

9

9. 观察失败

记录问题来自缺失、过时、噪声、冲突还是排序不佳的上下文。

10

10. 在模型/运行时变更后重新评估

上下文策略只对它所测试过的模型、工具和工作负载有效。

上下文工程检查清单

边缘情况和限制

有些任务足够简单，以至于上下文工程简化为一个简短的系统提示词和一条用户消息。添加检索、记忆和压缩只会引入不必要的架构。

有些任务需要高召回率，并且可能有意在后续综合之前包含更多上下文。研究、发现和法律审查可能更倾向于避免遗漏，而不是最小化 token 数量。

有些信息在使用前绝不应被摘要。精确合同、代码、密码材料、数值记录和监管文本可能需要逐字或结构化检索，因为压缩可能会改变含义。

长上下文行为在不同模型之间差异很大。在一个模型、上下文长度或工具框架上验证过的策略，不应自动转移到另一个上。

模型仍然可能忽略或误解优秀的上下文。上下文工程改善的是信息环境；它并不保证推理的正确性。

什么会改变这个答案？

未来的模型可能会对长上下文、位置效应和冲突信息变得更加稳健。这可能会减少所需的人工整理工作量。

架构上的区分仍然有用，因为权限、时效性、记忆持久性、来源权威性和外部应用状态无论上下文窗口大小如何都存在于模型之外。

预加载上下文与即时上下文之间的推荐平衡也会随延迟要求、工具可靠性、语料库规模、模型成本以及底层信息的动态程度而变化。

相关权威知识

上下文工程介于检索与生成之间。RAG 解释了外部知识如何被检索；R01 区分了嵌入、向量搜索和重排序；上下文工程解释了最终到达模型的是什么。

真相来源架构回答的是另一个问题：不是上下文中存在哪些信息，而是哪个来源被授权来确立一项主张。

现有文章《为什么更多上下文会让 AI 答案更糟》是这一权威定义的诊断性配套文章。它侧重于上下文污染、位置效应、top-k 增长、压缩损失和答案退化，而不是重新定义上下文工程本身。

常见问题

上下文工程常见问题

什么是上下文工程？

上下文工程是对语言模型在推理时接收到的信息进行的设计和运行时管理，包括指令、历史记录、检索到的证据、记忆、状态、工具和工具结果。

上下文工程与提示工程有何不同？

提示工程侧重于指令和示例的编写方式。上下文工程包括提示，但也决定将哪些外部信息、状态、历史记录、记忆和工具观察结果置于提示周围。

RAG 与上下文工程是一回事吗？

不是。RAG 检索外部信息。上下文工程决定检索到的信息如何被过滤、如何与其他状态结合，以及如何实际传递给模型。

记忆与上下文是一回事吗？

不是。记忆将信息持久保存在当前模型调用之外。上下文是加载到当前推理中的那部分信息。

为什么更多上下文会让答案更糟？

额外的上下文可能引入噪声、过时状态、相互冲突的证据、重复内容和位置竞争。大的上下文容量并不保证每个 token 都能被同样可靠地利用。

什么是上下文压缩？

压缩是将累积的历史记录总结或转换为更小的表示形式，以便长时间运行的系统可以继续运行而无需重放此前的每一个 token。

当前应用状态应该存储在上下文中吗？

它可以被表示在上下文中用于推理，但具有后果的操作通常应重新读取权威来源，因为上下文快照可能会过时。

上下文工程只对 AI 智能体有需要吗？

不是。智能体使上下文管理更加动态，但 RAG 系统、助手、副驾驶和多轮应用也需要有意识地构建上下文。

术语表

关键上下文工程术语

上下文工程

为特定推理步骤向语言模型提供的信息进行的设计和运行时管理。

上下文窗口

模型对输入的有限 token 容量，并且根据模型接口的不同，还包括相关的生成 token 或活动序列。

提示工程

旨在引出有用模型行为的指令、示例和提示结构的设计。

上下文组装

在推理之前选择、过滤、排序和格式化模型可见信息的过程。

即时检索

在当前任务需要时动态加载信息，而不是预加载所有可能相关的数据。

压缩

将累积的上下文缩减为更小的表示形式，同时尝试保留未来步骤所需的信息。

上下文污染

由无关、过时、矛盾或冗余信息占据模型工作上下文而导致的性能下降。

应用状态

外部系统、工作流或领域独立于模型上下文而存在的当前权威状况。

记忆

存储在即时模型调用之外、可能用于后续轮次或会话的信息。

检索上下文

由检索系统选择并全部或部分提供给模型的外部信息。

位置稳健性

当相关上下文的位置或顺序发生变化时，模型正确性保持稳定的程度。

有效性边界

结论仍然得到支持的范围、时间、假设、版本和证据条件。

结论

上下文工程是决定模型在回答之前能看到什么的那一层。这使它比提示更广泛，并处于检索的下游，同时又有别于持久记忆和权威应用状态。

强大的上下文架构不会将上下文窗口视为数据库。它将持久状态和知识保留在模型之外，加载当前决策所需的内容，保留权威性和来源，去除不必要的噪声，并在需要时刷新易变信息。

因此，实际目标不是最大上下文。而是为下一次模型决策提供最小充分、高信号、正确授权且保持有效性的上下文。

主要来源与当前指南

以下来源支持当前的上下文工程术语、长上下文行为以及可操作的上下文管理模式。项目部分明确属于实现证据，而非普遍性主张。

Anthropic — 面向 AI 智能体的有效上下文工程

官方工程指南，定义了上下文工程、即时检索、压缩、结构化记忆以及面向智能体的上下文策展。

OpenAI — 上下文工程：使用会话进行短期记忆管理

官方 cookbook 指南，涉及长时间运行的智能体会话的上下文管理、裁剪和压缩。

OpenAI — 智能体指南

OpenAI 当前面向开发者的指南，涉及智能体运行时、跨步骤上下文以及编排归属。

迷失在中间：语言模型如何使用长上下文

研究表明，长上下文模型的性能可能在很大程度上取决于相关信息在输入中的位置。