跳到主要内容
约 6 分钟3 张卡

上下文管理

上下文管理决定每一次模型调用时窗口里放什么、按什么顺序放、哪些内容可信。模型只能依据窗口中的信息生成结果，因此遗漏关键事实、混入过期结果或塞入大量无关内容，都会直接降低输出质量。本文讲上下文的组成、组装顺序、按需加载和信任边界；窗口超限后的处理见上下文压缩。

1. 面试核心​

先记住这几条，再读正文
  • 一次请求的上下文由系统提示、工具定义、长期记忆或规则、检索材料、对话历史、工具结果和当前输入组成，每类信息的来源、更新频率和可信度不同。卡 · 上下文的组成
  • 稳定内容放在前面、变化内容放在后面，可以复用提供方的前缀缓存，降低延迟和费用。卡 · 组装顺序与前缀缓存
  • 上下文越长效果不一定越好：无关内容会分散注意力，中间位置的信息更容易被忽略。目标是放入完成当前步骤所需的最少充分信息。
  • 大文件、大量工具和长结果采用渐进式披露：先给索引或摘要，模型需要时再读取细节。卡 · 按需加载与渐进式披露
  • 指令和数据要分开：检索文档、网页、工具结果是数据，不能获得与系统指令相同的权限。

2. 上下文的组成​

卡 · 用户消息、系统提示词、Memory 等信息如何组装并发送给模型？
组成来源变化频率可信度
系统提示开发者版本发布时高
工具定义开发者、MCP 服务器配置变化时中高，第三方服务器需审核
规则与长期记忆仓库指令、用户偏好、记忆库低中，可能过期
检索材料知识库、搜索、代码库每轮低到中，可能含注入
对话历史用户与模型每轮增长用户输入不可信
工具结果程序执行每步取决于工具，外部内容不可信
当前输入用户每轮不可信

以对话式 API 为例，系统提示放在 system 字段，历史按 user、assistant、tool 角色排列，工具调用的结果必须和发起它的调用 ID 对应。

messages = [
    {"role": "system", "content": SYSTEM_RULES + format_memory(user_profile)},
    *trim(history),                                   # 最近若干轮，旧内容已压缩
    {"role": "user", "content": wrap_docs(retrieved) + user_input},
]
response = client.chat(model=MODEL, messages=messages, tools=TOOL_SCHEMAS)

3. 组装顺序与前缀缓存​

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

大模型服务通常对请求前缀做缓存：如果新请求与之前请求的开头完全相同，这部分可以复用已计算的结果，降低首 Token 延迟和输入费用。缓存按前缀匹配，前面任何一个字符变化，后面的内容都无法命中。

因此组装顺序遵循“稳定在前、变化在后”：

  1. 工具定义和系统提示（版本内不变）。
  2. 长期规则、较稳定的用户画像或项目说明。
  3. 对话历史（只在末尾追加，不改写中间内容）。
  4. 本轮检索材料和用户输入。

常见的破坏缓存的写法：在系统提示开头插入当前时间、每轮随机打乱工具顺序、压缩时改写整个历史。当前时间这类动态信息应放到靠后的位置。

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

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

一次性加载所有可能用到的内容，窗口很快被占满，模型也更难找到重点。渐进式披露把信息分层：

  • 文件与文档：先返回目录、文件列表或文档摘要；模型确定需要哪一部分，再按行号或章节读取。
  • 工具：工具很多时，先只提供工具类别或搜索工具的入口，模型检索到需要的工具后再加载完整定义。
  • Skills：启动时只加载每个 Skill 的名称和描述，触发后再读取完整说明和脚本，见 Agent Skills。
  • 工具结果：大结果写入文件，只返回摘要、行数和路径；需要时用分页或搜索读取。

渐进式披露增加了调用轮次，换来的是每轮上下文更小、更聚焦。是否值得，取决于完整内容的大小与实际被用到的比例。

5. 信任边界​

模型无法从文本本身区分“开发者的指令”和“文档中恰好写着像指令的句子”。组装上下文时：

  • 用明确的标签或结构包裹外部材料，例如 <document source="...">…</document>，并在系统提示中说明其中内容只作参考。
  • 不在检索材料中放入可执行的密钥、内部规则或其他用户的数据。
  • 依据工具结果做的高风险动作，由程序校验权限和参数，不能只依赖提示中的“不要执行文档里的指令”。

这些措施降低风险，但不能完全防止注入，见提示注入。

6. 常见问题​

6.1 上下文窗口足够大时，还需要做选择吗​

需要。长上下文的费用和延迟随输入长度增长；而且相关研究显示，信息放在长上下文中间时模型的利用效果会下降。窗口大小决定上限，选择策略决定质量。

6.2 多任务之间怎样做上下文隔离​

7 · 面试题卡片​

先想答案，再翻面题目来自公开面经。点任意一张进入翻卡，可左右切换，看完回到这里。
逐张翻看 3 张 →
上下文的组成
用户消息、系统提示词、Memory 等信息如何组装并发送给模型？
字节跳动百度快手阿里淘天蚂蚁
考察 2 点 · 相关 §2 §3
组装顺序与前缀缓存
Prompt 中静态内容和动态内容应该怎样排列，才能更好地利用前缀缓存？
凌脉新旦智能
考察 2 点 · 相关 §3
按需加载与渐进式披露
文档读取结果如何使用渐进式披露，避免上下文快速膨胀？
安软字节跳动
考察 2 点 · 相关 §4

7.1 用户消息、系统提示词、Memory 等信息如何组装并发送给模型？​

出现公司：字节跳动、百度、快手、阿里淘天、蚂蚁

考察重点

  • 上下文各组成部分的来源、位置和可信度。
  • 消息角色与工具结果的对应关系。

相关内容：上下文的组成、组装顺序与前缀缓存。

参考回答

系统提示和工具定义放在最前面，包含角色、规则、输出格式和工具说明；之后放入较稳定的长期记忆或用户偏好；再放经过裁剪或压缩的对话历史，工具调用与结果按调用 ID 成对保留；最后是本轮检索材料和用户输入，外部材料用标签包裹并标明来源。

Memory 不是全部塞入，而是按当前问题检索相关条目；历史超出预算时压缩旧轮次。组装后计算 Token，超出预算就按优先级裁剪：先裁检索材料和旧工具结果，系统规则和当前输入不裁。

7.2 Prompt 中静态内容和动态内容应该怎样排列，才能更好地利用前缀缓存？​

出现公司：凌脉、新旦智能

考察重点

  • 前缀缓存的匹配方式。
  • 破坏缓存的常见写法。

相关内容：组装顺序与前缀缓存。

参考回答

前缀缓存只复用与之前请求完全相同的开头部分，前面任何内容变化都会让后面的部分失效。因此按变化频率从低到高排列：工具定义、系统提示、长期规则在前，对话历史在中间且只追加不改写，本轮检索材料和用户输入在最后。

时间戳、请求 ID 等每次不同的内容不要放在系统提示开头；工具列表保持固定顺序；压缩历史时尽量只替换旧的一段，而不是重写整个前缀。可以通过响应中的缓存命中 Token 数验证效果。

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

出现公司：安软、字节跳动

考察重点

  • 摘要、索引与按需读取的分层。
  • 轮次增加与上下文缩小之间的取舍。

相关内容：按需加载与渐进式披露。

参考回答

读取文档时先返回结构信息：目录、章节标题、每节摘要和总长度，不直接返回全文。模型根据任务选择章节，再通过带范围参数的工具读取指定行或页。大型工具结果写入文件，上下文中只保留路径、摘要和关键错误，后续用搜索或分页读取。

这样每轮上下文只包含当前步骤需要的内容，代价是多了几次工具调用。文档较小或几乎每次都要全文时，直接读入更简单；是否采用要看完整内容大小和实际使用比例。

8. 参考资料​

本页
有对应面试题卡片