先记住这个答案
裁剪顺序应为：最先移除最旧的、与当前意图无关的对话轮次；其次是重复示例与低价值文档；最后才考虑压缩需要长期参照的内容。保留system prompt、最近几轮用户指令及工具结果，因为它们直接影响本轮输出。边界在于：必须保留与当前任务有因果联系的早期信息，比如报错链。
- 先删最旧的低价值对话
- 冗余示例优先牺牲
- 保留最近指令与核心系统约束
为何旧内容更容易丢弃
Transformer的self-attention使每个token都能直接访问其它token，但在长序列中，较早的内容与当前输出之间的距离较远，其有效利用程度可能下降。实践中，模型生成时往往更受靠近输出的上下文影响，这是常见的经验观察，但并非绝对规则；较早的系统指令即便重要，也可能因距离较远而较少被利用。因此在token预算不足时，优先删除已被当前指令覆盖或与最新问题无因果联系的历史记录，有助于保留更高的信息密度。
围绕“信息增益”判断，不简单地按时间一刀切。例如用户在第2轮提供的偏好设定可能一直有效，但第5轮问过的“今天天气”已经无用。同样，演示过三遍的few-shot示例，在输入格式稳定后可以只留一份。裁剪的本质是降低每个token的边际噪声，而不是机械地截断一半。
200k 窗口的客服机器人裁剪决策
设一个客服机器人，窗口200k，当前已用183k。对话包含system指令、用户报修历史、一份50页产品说明书（约70k token）、以及多次重复的示例。方案：先删除最初15轮“咨询送货时间”等已办结对话，释放约30k；再把示例从每个类别3条降为1条，释放18k；最后把与本次“烧毁主板”无关的产品章节（如外观描述）截取，保留电气参数部分，释放25k。处理后占110k，新问题得以被窗口接纳。
为何这样处理：刚办结的对话轮次只提供语境而不参与当前故障判断；重复示例在用户已明确故障类型时近乎噪声；而与故障无关的文档章节只占配额不增加推理依据。保留的是最近3轮、原始发票图片描述和系统安全策略，它们对“是否赔偿”的决策起直接作用。
裁剪的失效场景与代价
裁剪并非总是安全。若应用是多步代码修复，用户在第40轮引用了第2轮的报错栈，把第2轮删除会导致当前推理断裂。此时必须保留该早期轮次，哪怕牺牲后面若干轮次的示例。判定标准是“是否存在当前问题明确指向的历史前提”，而不是时间久远。
但“保留前提”也要付出代价：它占住剩余配额后，新的长文可能装不下。工程解法是提前预估增量token，并设计改写压缩逻辑，而不是临时硬切。同时，若上下文结构本身带有位置标记（如轮次编号），删除后需重新编号，否则模型可能混淆引用，这一步的算力和调试成本也应计入。
容易答错的地方
- 总是删除最早的对话
- 这是错误的，因为早期可能有核心约束，比如用户一开始给出“我是会员，需要优先处理”，删除会丢失身份信息。应当优先删除中间冗余段落而非所有最旧内容。
- 给所有旧轮次打摘要来压缩
- 这个误区在于，摘要会丢失细节，且需要额外一次生成调用，若摘要质量不佳反而引入幻觉。优先直接删除无因果关联的轮次，而不是概括，但要注意摘要选型不是本问题讨论范围。
面试官还会怎么问？
怎么判断哪些旧轮次“低相关”？
可以按词法重叠与最新请求的意图匹配度预筛，再用小模型打分，但必须设定阈值，避免误删。实际落地可用嵌入相似度，成本低于让主模型自行判断。
如果窗口已经满了，系统提示词还能保留吗？
系统提示词通常很小，若必须压缩，可以精简其中长指令，但核心安全约束应保留，否则可能导致输出风险上升。压缩前应测试结构完整性。
裁剪后模型会记住被删内容吗？
不会，模型没有持久记忆，删除即不可见，所以只保证当前请求所需的信息依然在上下文中。若后续轮次再引用，则会发生事实断裂。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。