这是什么

一个生产测试数字值得记：AI 客服对话超过 40 轮、用最朴素的"先进先出"截断策略，"意图对齐率"会下降 28%。背后是当下大模型落地最被忽视的工程活——上下文淘汰（Context Eviction）。

先还原场景：模型的"上下文窗口"（即单次对话能"记"住的文本总量）逼近 128K Token（计费最小单位，约等于几百到一千汉字）。下一轮请求发出去，API 直接报错 context_length_exceeded——用户看到"对话崩了"，开发者看到"工程债"。

这是必然会触发的边界：上下文满了就必须丢消息，问题在于丢哪些？最早的消息往往包含系统提示词、用户最初需求说明这些最关键的内容。最朴素的"丢最老"做法，代价最大。

文章给出的工程思路是给每条消息打"权重"：优先级、是否被后续消息引用、最近被访问时间、是否被"固定"（pinned，任何策略都不能丢）。然后按策略淘汰价值最低的部分，常见做法包括 LRU（最近最少使用）、按语义密度淘汰等。

行业怎么看

支持者：这才是真工程。大模型落地的分水岭，正在从"能不能对话"转向"能不能稳定对话几十轮"。谁能写好这一段，谁的 AI 产品就能撑住真实业务，而不是演示。

也有冷静的反面：这是被严重"明星化"的工程细节。主流框架（LangChain、LlamaIndex 等）的默认实现早就不止"丢最老"——还在为淘汰策略立旗的人，工程可能还没入门。把这件事包装成"新分水岭"，有过度营销嫌疑。

更根本的质疑：上下文窗口正从 128K 飙到 1M、10M。今天花大力气做的淘汰机制，12-18 个月后可能变成历史包袱——你解决的是正在消失的问题。

对普通人的影响

对企业 IT：把"长对话会不会崩"写进采购需求文档（RFP），作为 AI 客服供应商的硬指标之一，别只看 demo。

对个人职场：用 AI 助手做长任务时，主动拆成几个独立任务、自己管"记忆"。在工具进化之前，这是更可靠的姿势。

对消费市场：你以后会注意到，好的 AI 客服"记性"明显更好——背后是有人在给每条消息算权重、付工程成本，这不会免费。