面试题：AI 对话上下文超限怎么办？

核心结论：

超限本质是 Token 超过模型上下文窗口，不是消息条数过多；前端负责预估和预警，后端负责最终 Token 校验与上下文裁剪，根据业务组合滑动窗口、摘要和 RAG。

一、核心流程

text 复制代码

用户提问
  ↓
Token 预算计算
  ↓
接近上限？
  ↓
后端 Context Manager
  ↓
┌───────────────┐
│ 滑动窗口：近期 │
│ 摘要：长期核心 │
│ RAG：按需检索 │
└───────────────┘
  ↓
最终 Token 校验
  ↓
组装 Prompt
  ↓
调用大模型

二、为什么会超限？

真正发送给模型的是：

text 复制代码

System Prompt
+ 历史对话
+ 当前问题
+ 工具调用结果
+ RAG 检索结果
+ 输出 Token 预留

这些内容经过 Tokenizer 后，如果超过模型上下文窗口，就会超限。

所以不能简单：

text 复制代码

messages.length > N

也不能认为：

text 复制代码

一个汉字 ≈ 两个 Token

Token 数量必须以具体模型的 Tokenizer 为准。

预算应该理解为：

text 复制代码

输入 Token + 输出预留 + 安全余量
≤
模型上下文窗口

三、三种核心策略

策略	解决什么问题	适合场景	核心缺点
滑动窗口	控制近期上下文长度	闲聊、短会话	老信息直接丢失
摘要	压缩长期业务信息	客服、任务型长会话	存在信息损失
RAG	按需找回历史信息	长期、多主题会话	有召回误差和额外成本

核心不是三选一，而是组合：

text 复制代码

近期对话 → 滑动窗口
     +
长期事实 → 摘要
     +
特定历史 → RAG

四、前后端职责

前端：

text 复制代码

Token 预估
 ↓
提前预警
 ↓
展示上下文整理状态
 ↓
保留完整聊天记录 UI

前端估算只是体验优化，不能作为最终裁剪依据。

后端：

text 复制代码

统一 Token 计算
 ↓
判断预算
 ↓
执行滑动窗口 / 摘要 / RAG
 ↓
最终 Token 校验
 ↓
调用模型

最终裁剪必须以后端为准。

五、最容易被追问的关键点

用户看到的历史 ≠ 模型每次发送的历史。

例如：

text 复制代码

用户界面：
A1 A2 A3 ... A100

模型上下文：
历史摘要
+
A90 ~ A100
+
RAG 找到的相关历史
+
当前问题

因此可以做到：

用户历史不丢，模型上下文不超限。

六、主要矛盾与次要矛盾

主要矛盾：

如何在有限 Token 预算内保留对当前任务最有价值的信息。

次要矛盾：

text 复制代码

前端如何预警
摘要如何压缩
历史如何检索
用户如何感知
不同业务如何取舍

所以面试时不要把重点放在"删除前几条消息"，而要回答：

text 复制代码

Token Budget
    ↓
Context Manager
    ↓
信息分层
├── 近期 → 滑动窗口
├── 长期 → 摘要
└── 按需 → RAG
    ↓
后端最终 Token 校验
    ↓
LLM

一句话背诵

AI 上下文超限的核心是 Token 预算管理：前端负责预估预警，后端负责最终控制；近期信息用滑动窗口，长期信息用摘要，特定历史用 RAG，最终统一做 Token 校验。