大模型应用开发系列教程：第六章上下文窗口的真实边界

我们将从上下文窗口的本质出发，逐步拆解多轮对话失控的根源，最终落地一套可工程化的上下文管理方案。

菜鸟Java码农

1287人浏览 · 2026-01-13 10:45:00

菜鸟Java码农 · 2026-01-13 10:45:00 发布

在前面几篇介绍中，我们通过 Prompt 工程为模型建立了单次生成层面的约束—— 比如明确系统角色、限定回答范围、规范输出格式等。这些方法在单轮对话中往往能取得不错的效果：用户问一个问题，系统基于设定的规则和知识库给出答案，看起来既准确又可靠。

但如果你真正将企业知识库助手投入实际使用，很快就会收到用户这样的反馈：“一开始回答得挺准的，多聊几句就越来越离谱了。”

这并非 Prompt 突然失效，也不是模型能力下降，而是当对话从 “单轮” 进入 “多轮”，系统面临了一个全新的挑战维度 —— 时间。在持续交互中，历史信息的累积会逐渐改变模型的输入环境，进而打破最初设定的约束边界。

接下来，我们将从上下文窗口的本质出发，逐步拆解多轮对话失控的根源，最终落地一套可工程化的上下文管理方案。

在讨论“记忆”之前，我们必须先回答一个技术决策层面的问题：

当用户开始连续提问时，我们是否应该“尽量多地保留历史对话”？

很多团队在这个问题上的直觉答案是：

当然要保留，历史越完整，模型越能理解上下文，回答自然更准确

但这一章要做的事情，正是推翻这个直觉 —— 因为 “全量保留历史” 不仅无法解决问题，反而会埋下系统失控的隐患。

6.1 一个常被忽略的事实：上下文不是记忆

在 LLM 的 API 交互中，我们通常通过 messages 参数传入对话历史，格式类似这样：

[
{"role":"system","content":"..."},
{"role":"user","content":"..."},
{"role":"assistant","content":"..."}
]

这很容易让人产生一个工程误判：

“只要我把历史消息都塞进去，模型就能记住一切。”

但如果回到第一部分对 LLM 本质 —— token序列的概率预测模型 —— 的分析，你会发现：

•模型接收的所有上下文（包括系统提示、用户提问、历史回答）会被一次性拼接成一个长 token 序列（比如上述示例会变成 “<system>你是企业知识库助手…<user>请问年假怎么申请？<assistant>需通过 OA 系统…”）•它并不知道哪些是“历史”，哪些是“当前”（即它只会基于整个序列的统计规律预测下一个 token）•更不知道哪些信息在工程上更重要（比如 “仅回答内部政策”），哪些是 “临时的无关信息”。

因此，一个关键认知是：

上下文只是输入数据，而不是记忆机制。

人类的记忆会主动筛选、分层、关联信息，而上下文只是无序的信息堆砌。

6.2 上下文窗口的三个硬限制（为什么“全塞进去”一定会失败）

即使你愿意无条件保留所有历史，对话系统也会很快撞上三个不可绕过的限制：

1.长度上限：超过窗口，信息会被直接截断

所有 LLM 都有明确的 token 长度限制（比如 GPT-3.5 为 4k token，GPT-4 基础版为 8k token，增强版为 128k token）。当历史对话累积的 token 数超过这个上限时，系统只能通过 “截断” 处理（通常是删除最早的内容），这会直接导致早期关键信息（比如系统约束）丢失。举例：如果系统提示包含

“禁止回答外部政策”，但随着对话变长，这条约束被挤出窗口，模型就可能开始回答无关内容。

1.注意力衰减：越靠前的信息，影响力越弱

举例：用户在第 1 轮提到 “我是市场部员工”，到第 10 轮询问报销政策时，模型可能已经 “忽略” 了这个身份信息，给出了不适用的规则。

1.成本与延迟：token 越多，系统越慢、越贵

LLM 的调用成本（按 token 计费）和响应延迟与上下文长度正相关。全量保留历史会导致每轮对话的 token 数持续增长，直接推高系统成本（可能是初始成本的 10 倍以上），同时延长用户等待时间（从几百毫秒增至几秒）。

这些限制最终会导致一个危险的后果：