为什么”把聊天记录全塞进去”是 LLM 产品最常见的自杀行为

一句话结论：无限追加聊天历史不是”给模型的上下文越多越好”——它会在四个维度同时崩盘：硬天花板、成本爆炸、延迟倍增、信号被噪声淹没。成熟的 AI 产品用分层上下文架构替代全量追加。核心思路不是”给更多信息”，而是”给每个 token 更值钱的信息”。

四个同时发作的问题

直觉很自然：用户聊了 30 轮，把每一轮都喂给模型，答案不就更有上下文了吗？

前十轮没问题。二十轮依然连贯。到四十轮左右，事情开始崩了：

这不是偶发 bug，是系统性必然。原因有四层，层层叠加。

GPT-4o 上限 128K token，Claude 200K，Gemini 2.5 Pro 1M。

数字看着大，但一个健谈用户在单次长会话里就能烧掉 100K。撞到天花板时你只有两个选择：从头截断（丢掉关键早期上下文），或者拒绝继续。两个都是烂体验。

就算永远撞不到窗口上限，经济账也算不过来。

50 轮对话的输入 token 成本比 5 轮高 10 倍，而输入 token 正是多数定价模型的主要开销。

如果有几百万用户，这不叫担忧——这叫直接走向不可持续的单位经济。每多追加一条消息，都在烧真金白银。

更长的 prompt = 更长的推理时间。Attention 的计算量随序列长度二次增长。

把聊天历史翻倍，延迟不是翻倍，是可能翻四倍。

在用户期待近乎即时回复的流式聊天产品里，4 秒已经让人感觉”坏了”。再乘以数千并发用户，基础设施成本跟响应时间一起爆炸。

把 40 轮聊天全倒进 prompt，模型要在问候语、题外话、澄清、纠正和死胡同里翻找，才能找到跟当前问题真正相关的东西。

旧指令和新指令混在一起。模型抓住 15 轮前的一个细节不放——因为它在统计上看起来突出——尽管用户早已翻篇。

结果：回答不聚焦、自相矛盾、奇怪地执着于过去。

更多上下文≠更好的答案。更多上下文往往=更嘈杂的答案。

目标不是”把所有东西都给模型”。目标是**”给模型当前任务最相关、最干净、性价比最高的信息”**。

分层架构长这样：

最近 3-5 轮交流原样保留。这保证对话连贯性——代词指代、即时引用、当前讨论流程，模型都能追踪。

超出近期的部分，逐步压缩为摘要。提取关键决策、重要事实、待办事项和用户偏好，丢弃填充内容。

好的摘要用极小 token 成本保留语义价值。

用户身份、持久偏好、目标、反复出现的话题——提取到结构化的记忆存储中。不往每个 prompt 里塞，而是在需要时选择性注入，通常通过轻量检索。

当用户问到涉及对话早期（甚至跨会话）的特定内容时，检索系统搜完整历史，只把最相关片段注入当前 prompt。这就是把 RAG 用在对话历史上。

生产系统用启发式规则自动决定何时摘要或裁剪，而非手动操作：

这些信号触发压缩和重组上下文的动作。不要让开发者手动判断——这是系统该做的事。

全量追加聊天历史是原型和产品之间的分水岭。

原型这么干没问题。产品这么干会在四个维度上同时崩：窗口限制、成本失控、延迟爆炸、质量劣化。

分层上下文架构——最近逐字、较早摘要、持久记忆、按需检索——用更少的 token 交付更相关的信号。

最关键的一次思维转变：从”怎么给模型塞更多信息”变成”怎么让每个 token 消耗换回最值钱的信号”。