企业官网建设流程全解析

核心结论：

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

一、核心流程

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

二、为什么会超限？

真正发送给模型的是：

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

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

所以不能简单：

messages.length > N

也不能认为：

一个汉字 ≈ 两个 Token

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

预算应该理解为：

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

三、三种核心策略

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

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

四、前后端职责

前端：

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

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

后端：

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

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

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

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

例如：

用户界面： A1 A2 A3 ... A100 模型上下文： 历史摘要 + A90 ~ A100 + RAG 找到的相关历史 + 当前问题

因此可以做到：

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

六、主要矛盾与次要矛盾

主要矛盾：

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

次要矛盾：

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

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

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

一句话背诵

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