上下文工程

上下文工程决定模型在一次推断中能看到什么。它并不取代模型权重中的知识，也不是把应用的全部状态塞进提示的办法。它从指令、用户输入、检索证据、对话状态、工具说明和工具结果中，为当前任务构造一个有界且带版本的视图。真正值得问的，不是「能装下多少文本」，而是「哪些经过授权的词元，既能为这次调用提供所需证据和约束，又不会掩盖冲突或挤占回答所需的空间」。

提示工程仍是其中一部分，指令依然需要清楚的措辞。随着智能体系统让整套组装过程变得可见，「上下文工程」这个更宽泛的说法在 2025 年流行起来 (Anthropic 2025)，但背后的机制早已有之。Brown 等人在 2020 年证明，输入中的示范可以在不更新权重的情况下改变 GPT-3 的任务行为 (Brown et al. 2020)。随后，检索、工具和多轮智能体把手写提示变成了一条按步骤运行的数据流水线。上下文工程的任务，是规定并检验这条流水线；这并不意味着提示工程在某一天被重新命名了。

定义组装契约

应用保存的状态，远多于一次模型调用应当容纳的内容。源语料、事件日志、权限、待执行操作和用户资料应留在持久存储中。上下文只是这些状态的临时投影。如果投影有误，再有能力的模型也可能答错问题、服从过期指令、引用陈旧证据，或重复已经执行过的操作。

可以把这份投影视为一个带版本的接口：

ContextSpec {
  model_revision, tokenizer_revision, chat_template_revision
  max_input_tokens, max_total_tokens, output_reserve
  instruction_policy_revision, tool_catalog_revision
  retrieval_spec_hash, compaction_policy_revision
  ordering_policy_revision, trust_policy_revision
  tool_server_identities, retention_policy_revision
}

ContextItem {
  item_id, kind, role, authority, content_hash
  source_uri, source_version, observed_at, expires_at
  tenant, acl_version, trust, token_count
  dependencies, supersedes, derived_from
  parent_call_id, mandatory
}

kind 区分指令、任务数据、示范、证据、历史、记忆、工具模式和工具结果。role 记录该项会以什么方式序列化给模型，authority 则记录它有权改变谁的策略。这里有意把角色与权限分开。数据库中的一行数据或网页内容可以出现在用户消息或工具结果里，却并不会因此获得覆盖应用指令的权限。来源和访问控制字段让每一项都能追溯到生成它的、经过授权的状态。

实际渲染出的请求也是契约的一部分。供应商的对话模板可能额外加入角色标记、分隔符、工具调用记录和不可见格式。只要模板或分词器改变，即使可见字符串完全相同，行为和词元数也可能不同。应当对规格做哈希，记录排好顺序的项目 ID 和内容哈希；其中任何转换发生变化时，都要创建新版本。

计算实际会执行的请求

词元预算要到序列化之后才开始计算，不能把源文档的字数简单相加。设最终请求为

$$\begin{aligned} X &= \operatorname{serialize}\!\left(F,\pi(S)\right), \\ T(X) &\le W_{\mathrm{in}}, \\ T(X)+R &\le W_{\mathrm{total}}. \end{aligned}$$

其中，$F$ 是按顺序排列的必选项目，例如应用指令和当前用户请求；$S$ 是从可选候选项中选出的子集；$\pi$ 是排序策略；$\operatorname{serialize}$ 是模型专用的对话与工具模板。$X$ 是实际发送给模型的输入，$T(X)$ 是契约所指定分词器算出的词元数，$W_{\mathrm{in}}$ 是模型或 API 的输入上限，$W_{\mathrm{total}}$ 是输入与生成内容的总上限，$R$ 是输出预留。如果 API 只提供一个合并上限，前两个约束就简化为第二个不等式。

这些不等式是准入检查，而不是要尽量逼近的目标。用满所有可用词元，可能增加预填充延迟和键值缓存占用，稀释有用证据，还会让后续工具结果无处可放。生产策略通常会给工具模式、检索证据、示范和历史分别设置更小的预算。这些分配需要实测，不存在适用于所有系统的固定百分比。多步工具循环还要为助手发出的工具请求以及工具结果留出空间，因为结果会进入下一次调用。只给最终文字回答预留空间，可能让任务在中途无法继续。

不要把溢出行为交给没有文档说明的后端默认值。有些接口会拒绝超长请求，有些则截断或限制其中某个字段。组装器应统计最终载荷；超出限制时，按照明确的策略重新构建；如果必选内容仍然放不下，就要明确失败。静默裁剪会破坏可复现性，因为日志中的源项目将不再等同于模型实际收到的内容。还应把预检结果与供应商返回的用量核对，让分词器或模板的漂移可以被发现。

选择与摆放策略要靠实测

更多上下文有时会有帮助，因为模型可以利用权重中没有的任务信息；它也可能造成伤害，因为不同项目争夺有限空间，还会彼此影响。上下文示范就是一个简单例子。GPT-3 的实验表明，零样本、单样本和少样本提示都可能在不更新梯度的情况下产生有用行为，但效果会随任务和模型规模显著变化 (Brown et al. 2020)。后来的受控实验发现，仅仅改变相同四个示范的顺序，就可能让被测 GPT 系列模型的分类准确率大幅波动 (Lu et al. 2022)。因此，示范的内容、顺序、格式和标签平衡都必须纳入评估，不能当作无关紧要的装饰。

无关信息也并非中性。Shi 等人把干扰句插入小学算术题，并观察到被测语言模型的准确率下降 (Shi et al. 2023)。这并不能证明每一段额外文本都会降低质量，却足以说明检索分数本身并不够。测试中还要加入表面相关、看似可信、已经过期、重复，或与答案证据冲突的干扰项。

位置也可能影响结果。Liu 等人在多文档问答和合成键值检索中改变相关信息的位置。研究中的若干模型在相关项靠近开头或结尾时表现最好，放在中间时则较差 (Liu et al. 2024)。「迷失在中间」指的是这一实验现象，不是每个模型、任务或上下文长度都遵循的定律，也不意味着中间位置完全不可用。查询的位置、模型训练方式、任务结构和后续架构都可能改变曲线。

实际应对方法是做置换测试，而不是遵循「证据永远放在两端」之类的口号。固定所选项目，只改变答案证据和冲突项在渲染后请求中的位置，再测量结果变化。对话角色和模板可能让文本的实际位置不同于源文件中的顺序，所以要检查实际载荷。只有某条排序规则在目标工作负载上胜出，并在重要切片中保持稳定，才应采用它。

保留权限边界与来源信息

对模型而言，上下文是一段连续的词元序列，但应用不能把其中的内容一视同仁。平台政策约束应用，应用指令约束任务，用户提供目标和数据，检索文档与工具结果提供证据。即使模型仍有可能误解这些区别，组装器也必须保留它们。

由此得到三条规则：

1. 先授权，再选择。 检索和记忆查询只能在调用者有权访问的候选集合上运行。生成之后再过滤为时已晚，因为未经授权的内容已经影响了回答。
2. 让数据保持为数据。 引用或结构化呈现检索文本和工具输出，附上来源，并明确说明其中夹带的指令不可信。不要把外部文本拼接到权限更高的指令字段中。
3. 呈现冲突，不要抹平分歧。 保留来源版本、时间戳，以及可信项目之间的不同说法。摘要如果悄悄选择其中一种，就会把不确定性变成虚假的确定性。

角色、XML 标签和分隔符有助于模型解析边界，但格式本身并不是安全边界。间接提示注入之所以有效，正是因为不可信数据与可执行指令在同一个模型输入中相遇。StruQ 采用结构化前端，并专门训练模型忽略数据通道中的指令，从而实现更强的分离 (Chen et al. 2025)。这项结果不能直接推广到仅仅看见标签的任意模型。系统仍需要授权、最小权限工具、后果重大的操作需要确认、输出验证，以及 第 58 章 中介绍的其他控制措施。

压缩是一种有损状态转换

再长的固定窗口，最终也装不下持续增长的对话和智能体轨迹。丢弃旧回合会损失状态，保留全部回合会耗尽预算，摘要则会产生一种新的、可能出错的表示。因此，压缩是一种有明确损失策略的状态转换，不是例行的文字清理。

至少要区分三类状态：

• 持久事实： 源记录、用户批准、工具产生的实际效果、工件和事件日志都留在提示之外。摘要可以指向它们，但不能取代它们。
• 工作状态： 当前目标、已完成步骤、待解决问题、约束和下一项操作，可以压缩成带有来源指针的检查点。
• 临时细节： 探索性的文字、重复的工具输出和已经被替代的草稿，只要有用结果已在别处得到记录，就可以丢弃。

每个压缩后的检查点都应记录输入范围、策略版本、内容哈希、来源指针、尚未消除的不确定性，以及已经执行的操作。如果后续决策依赖摘要遗漏的细节，系统可以重新取回原始证据。这与 第 39 章 采用的分工相同：持久存储负责保存事实，窗口只保留当前工作集。

压缩质量取决于任务。RECOMP 针对下游检索增强任务训练抽取式和生成式压缩器，还学习何时应当完全省略增强内容 (Xu et al. 2024)。这比默认一份通用摘要能保留下一步所需的一切更有依据。评估压缩时，应覆盖延后提出的问题、承诺、否定、多步依赖关系，以及故障后的恢复。涉及不可逆操作时，应与外部系统核对，不能只相信文字摘要。

工具扩大候选集合，不扩大权限

工具协议规定能力如何描述和调用，却不会决定模型应该看到哪些能力、某次调用是否获得授权，或工具结果中有多少内容应进入下一轮上下文。

模型上下文协议（MCP）为资源、提示和工具规定了客户端、宿主与服务器之间的标准交互。在它的架构中，宿主协调客户端、权限、同意流程和上下文聚合，每个客户端分别维护与一台服务器的连接 (Model Context Protocol Contributors 2025)。这套协议消除了集成边界上的定制消息格式，却不会把所有信任域合并成一个安全枢纽。服务器身份、能力协商、授权、模式版本、结果验证和隔离，仍由宿主及其周围的运行时负责。

模式校验通过，不等于获得了调用权限。执行前，应根据当前政策重新授权操作、目标位置和敏感参数。结果返回后，要把它关联到原始调用 ID，检查错误状态、媒体类型、大小和声明的输出模式，并保留服务器与模式版本。远程服务器提供的注解应先只当作提示，只有本地政策认可后才能信任。

工具目录本身也会消耗词元。规模小且常用的工具集可以直接加载；更大的目录应通过确定性的发现机制逐步公开；只有任务可能需要某项工具时，才获取完整模式。发现机制也要单独测试召回率。隐藏必要工具虽然节省词元，却会让任务无法完成；展示许多近乎重复的工具，又会提高选择错误率。类似地，如果某项过滤可以由代码确定性完成，就应在代码中处理大体量结果，但要把原始结果与转换轨迹保留在窗口之外，以便审计过滤后的视图。

组装一次模型调用

至此，上下文组装器可以写成算法，而不再只是一份提示模板：

输入：
  请求 q、调用者身份 a、持久状态 D、ContextSpec V

1. 把 V 解析为一个模型、分词器、对话模板和策略包。
2. 从经过授权的指令和当前请求中构造必选项目 F。
3. 从历史、记忆、检索和工具发现结果中收集候选项目 C。
4. 拒绝不符合 a 的租户或访问策略的项目；保留其余项目的来源信息。
5. 删除完全重复的项目，标记冲突和已被替代的版本，并展开
   必需的依赖关系。
6. 在分类预算内从 C 中选出 S；记录每一项为何被保留、转换或省略。
7. 按策略 pi 排列 S，序列化 X = serialize(F, pi(S))，再用 V 指定的
   分词器和对话模板统计 X。
8. 如果 X 违反输入或输出预留约束，就按下一项明确的缩减策略重新构建；
   绝不静默截断必选内容。
9. 执行时重新授权模型提出的工具操作；把每个通过验证的结果关联到原始调用，
   再组装下一次模型请求。
10. 输出 X 和 ContextManifest。清单包含 V 的哈希、排好顺序的项目 ID 与哈希、
    词元数、转换、遗漏和来源指针。

这里，$q$ 是当前任务请求，$a$ 是经过身份验证的调用者，$D$ 是应用的持久状态，$V$ 是选定的上下文契约。$F$、$C$、$S$、$\pi$ 和 $X$ 的含义与上面的预算公式一致。ContextManifest 是用于重放和诊断的元数据；敏感原始内容仍受来源自身的保留和访问策略约束。

清单让「缺少了什么」变得可观察。如果回答遗漏某项事实，运维人员可以区分检索失败、授权过滤、预算排除、压缩损失、序列化错误，以及模型没有使用已提供内容这六种情况。没有这份记录，它们看起来都像是「模型忘了」。

评估组装器，而不只是最终回答

先固定模型版本、分词器与对话模板、上下文规格、语料与权限快照、工具目录和评估用例。然后把新策略与当前生产策略、不添加上下文的基线、完整上下文基线，以及条件允许时只包含必要且经过授权项目的理想基线（oracle）进行比较。接着分别检验四类边界：

• 选择与使用： 任务成功率、打包后的证据召回、论断是否有依据、指令遵循情况，以及缺少必要证据时能否拒答。
• 稳健性： 改变相关项的位置；加入重复项、可信的干扰项、过期版本、冲突来源、很长的工具结果，以及标签或顺序不同的示范。
• 连续性与安全性： 在不同回合压缩并从检查点恢复；撤销访问权限；删除来源；向检索网页和工具输出注入指令；确认已经完成的操作不会再次执行。
• 运行指标： 序列化后的输入词元数和输出预留、预填充与生成延迟、缓存复用、检索和工具调用、上下文重建、成本，以及清单覆盖率。

使用配对用例，让每次比较只有上下文策略发生变化。报告跨任务的不确定性、最差的相关项位置和均值，不要把无关工作负载揉成一个平均数。还要检查语言、请求长度、工具类别、权限群体和对话时长等重要切片。更短的上下文如果丢掉决定性证据，并不会更好；更长的上下文如果只增加延迟和干扰项，也不会更好。合成检索探针适合诊断，却无法独自证明系统具备长上下文能力。HELMET 同时覆盖召回、检索增强生成、多样本学习、问答和摘要，用来揭示不同的失效模式 (Yen et al. 2025)。

至此，编排环路也完整了：检索、记忆、工具和智能体状态被组装成一个有界且经过授权的输入，并附带可重放的清单。下一部分从 第 47 章 开始，讨论什么样的证据足以证明这套机制不只对精心挑选的示例有效。

延伸阅读