约 9 分钟4 张卡

上下文管理

上下文管理决定每轮模型调用放入哪些信息、怎样排列，以及哪些内容可以作为指令。本文从上下文的组成入手，依次说明预算分配、前缀缓存、按需读取和信任边界。遗漏关键事实、混入过期结果或加入大量无关内容，都会影响模型完成当前任务。

1. 面试核心

先记住这几条，再读正文

上下文组成。 一次调用的上下文包含应用规则、工具定义、相关记忆、对话历史、工具结果、检索文档和当前请求。卡 · 综合题
前缀缓存。 稳定规则和工具定义放在前部、动态内容放在后部，有利于复用前缀缓存，降低输入费用与首 Token 延迟。卡 · 组装顺序与前缀缓存
渐进式披露。 渐进式披露先提供索引或摘要，再按任务读取细节，以更多调用轮次换取更小的单轮输入。卡 · 按需加载与渐进式披露
来源与授权。 执行权限由应用授权决定，检索文档和工具结果作为有来源的任务数据传入模型。卡 · 状态冲突与时效

2. 上下文的组成

组装上下文时，需要先分清每段内容来自哪里、用于什么目的。来源帮助应用核对事实，消息角色与内容边界则标明哪些是指令、哪些是待分析的数据。事实可靠性和指令权限是两个维度：工具成功返回，也可能带回过期网页或恶意文本。

内容	来源	处理方式
应用规则	开发者配置	放在对应的指令角色。
工具定义	本地配置或工具服务	审核用途与参数。
长期记忆	用户偏好或状态库	检查相关性、版本和权限。
检索到的内容	文档、网页、代码库	标注来源，作为数据引用。
历史消息	用户与模型	保留角色及工具调用关系。
当前请求	用户	在应用授权范围内解释。

这些内容的更新频率也不同。应用规则随版本发布而更新，工具定义随配置变化而更新。用户偏好变化较少，但也需要检查是否过期。检索文档与当前请求每轮变化，对话历史则随轮次增长。工具每执行一步，还会产生新的结果，需要保留调用 ID 和返回时间。

下面用一个示意说明规则、状态、历史与当前请求如何分层：

应用规则：任务范围、输出规范
相关状态：目标、约束、有效偏好
近期历史：用户消息、模型消息、完整工具交互
检索内容：来源、版本、摘录
当前请求：用户本轮输入

具体角色字段按所用 API 映射。在提供消息角色的接口中，用户消息对应 user，模型消息对应 assistant。工具结果使用接口规定的工具消息形式，并通过调用 ID 关联原请求。应用规则则放入该接口规定的指令位置。

用户偏好应作为有来源的状态传入，并按当前问题选择相关条目。比如，只把与本次任务有关的语言偏好或项目约束放入上下文。将外部记忆直接拼成系统规则，会让其中的文字获得更高指令权限，所以应保留它原有的来源和适用范围。

2.1 Token 预算与内容选择

预算分配要保证模型既能读完输入，也有空间继续生成。组装前先为输出和下一步工具结果留出空间，再把剩余预算分给固定指令、当前任务和相关证据。

组装后估算 Token 数。如果超出预算，按相关性、时效和必要性选择保留内容：

优先保留完成当前步骤所需的证据，移出离题文档和已经用过的旧工具结果。
同一事实有多个版本时，保留当前有效的版本，并记录来源与更新时间。
固定规则和当前请求中的必要条件要完整保留。必需文件本身超限时，可以分段处理。

摘录文档时，标题、版本和引用位置要一起保留。这样，模型给出结论后，程序或读者才能找到原文核对。

旧历史可用摘要缩短，具体方法见上下文压缩。

3. 组装顺序与前缀缓存

必会卡 · 用户消息、系统提示词、Memory 等信息如何组装并发送给模型？卡 · Prompt 中静态内容和动态内容应该怎样排列，才能更好地利用前缀缓存？

多个请求会重复使用相同的规则和工具定义。把这些稳定内容放在前部，服务就有机会复用相同前缀的计算，降低首 Token 延迟和输入费用。

前缀缓存的计算原理见大语言模型基础。这里重点说明应用怎样排列输入。

在保持消息角色和工具交互有效的前提下，可以按内容的变化频率组织：

工具定义和应用规则放在前部，在同一版本内保持稳定。
接着放较稳定的项目说明与相关用户偏好，并保留它们各自的来源。
再放对话历史，新消息追加到末尾，尽量保留已有内容。
最后放本轮检索文档和当前请求，时间戳、请求 ID 也放在这一变化区域。

缓存匹配的是序列化后的相同前缀，也就是接口把消息组织成模型输入后的开头部分。如果在开头插入每轮变化的时间戳，共同前缀就会变短。随机调整工具定义的顺序也有同样的问题。因此，工具顺序应固定，动态信息尽量靠后。

缓存能否命中还取决于提供方的最小长度、保存期限和请求路由等规则。OpenAI 提供缓存输入用量明细，Anthropic 提供自动缓存或显式缓存控制。启用方式与计费规则按所用接口核对，收益则通过实际用量（usage）验证。

压缩历史会改写前缀，变化位置之前的共同部分仍可复用。替换旧历史时，可以保留稳定规则，避免把整个输入一起重写。压缩会减少后续输入，却也会改变缓存命中量，所以要比较整次任务的费用与耗时。

4. 按需加载与渐进式披露

必会卡 · 文档读取结果如何使用渐进式披露，避免上下文快速膨胀？

大文件和大量工具定义如果一次全部加载，会很快占满窗口。渐进式披露先给出索引或摘要，让模型知道有哪些内容，再按当前任务读取细节。

索引需要包含稳定的文件或段落位置，模型选定后，工具才能准确读取。常见的四类按需加载对象如下：

文件与文档：先返回目录、文件列表或章节摘要，并给出总长度。模型确定目标后，再按行号、页码或章节读取。
工具定义：工具较多时，先提供类别或工具搜索入口。检索到需要的工具后，再加载完整定义和参数说明。
工具结果：大结果写入文件，上下文中只放摘要、关键错误、总行数和路径。后续需要原文时，再分页或搜索。
Skill：Skill 是包含任务说明和可选脚本的技能包。先展示名称和用途，匹配任务后再读取完整说明，按需加载脚本。

Skill 的加载机制见 Agent Skills。

渐进读取减少了单次输入，也让模型更容易找到当前步骤的重点，代价是增加工具调用轮次。是否采用，要看完整内容的大小与实际使用比例。如果文件很小，而且每轮几乎都要读全文，直接加载更简单。

5. 信任边界

必会卡 · 旧记忆与当前输入冲突时，如何确定有效信息？

上下文中的文档和网页会包含看起来像指令的文字。应用需要标明它们是待分析的数据，并由程序决定模型提出的操作能否执行。

组装时，要同时处理内容边界、数据范围和执行权限：

用明确标签包裹外部文档，比如 <document source="...">…</document>。在应用规则中说明其中内容只作参考，让模型更容易识别来源。
检索前按用户和租户过滤数据。凭证、无关内部规则和其他用户的数据应排除在本轮上下文之外。
工具结果引出高风险动作时，由程序校验权限与参数。模型负责解释文档，执行器负责判断操作是否获得授权。

标签只能帮助模型区分内容，无法独立阻止提示注入。具体防护机制见提示注入。