技术 · 熟练
为什么越勤快地压缩，账单反而越贵？
前缀稳得住就便宜，逐轮重写就得全价重算
上下文管理的默认建议在 2026 年翻了个面：以前说「历史太长就压成摘要」，现在说「每轮都重写历史，会把缓存前缀打断，引擎只能按全价把你的整段上下文重算一遍」。这一页给的不是又一个压缩技巧，而是顺序与结构：把核心指令、规则、稳定的项目背景与工具说明放在最前面，并且轮次之间不改结构；新内容只追加到末尾；压缩要等接近饱和阈值再做，而且按整块里程碑做，⛔ 不是每轮抹一遍。配合工具侧两条纪律（工具集小而正交 · 工具输出确定性封顶），把省下来的 token 花在真正需要推理的地方。
方法 · 一图看懂
1
静态前缀放最前，且不逐轮改 — 系统提示 · 规则 · 项目背景 · 工具 schema 都是前缀，动它们就等于把整段缓存作废
2
新回合只追加到末尾 — 追加式历史：前面不动、后面只加，缓存前缀才保得住
3
压缩分三级，顺序不能反 — L1 工具输出截断 → L2 输入淘汰 → L3 LLM 摘要，前两级不花额外模型调用，摘要是最贵的兜底
4
到阈值才整块整理，并留下原始记录 — 按里程碑整理一次，⛔ 不逐轮改写；摘要只作工作表示，原文另存
5
工具侧两条纪律 — 每个角色的活跃工具收在 3–5 个；工具输出确定性封顶，全量写外部存储
原理 · 为什么有效
这件事的机理是缓存前缀：当系统提示、规则、工具说明与历史回合在窗口里保持一段不变的头部时，推理引擎可以复用这段的注意力状态，按折扣价计费、首字也更快。而「每轮把历史压成一段新摘要」恰好改写了开头 —— 前缀一变，缓存失效，整段上下文按全价重算；而且摘要本身是有损的，反复摘会把细节、精确参数、错误字符串一层层磨掉（这正是另两条已知失效模式：越摘越少与每轮重写侵蚀）。所以正确的顺序是先做不花钱的两级（截断工具输出、淘汰已经用不上的输入）—— 它们不消耗模型调用；只有前两级做完还满，才动最贵的第三级。另一条常被忽略的成本结构：每轮都重发完整历史的开销随会话长度快速增长，所以「优化某一句提示词」几乎不影响账单，真正的成本单位是整次运行。
适用场景
适用：跑长会话 / 长任务的人 —— 编码助手连着用几小时、自动化任务一轮几十次工具调用、把同一份项目背景反复喂给同一个 AI 的人。
⛔ 不适用：一问一答式的短会话 —— 前缀本来就没复用几次，谈不上破坏缓存。
⚠️ 前提：你的工具或平台确实支持缓存计费（多数主流推理服务在 2026 年已默认开启）；不支持时本页第 1、2 条仍然成立（少算一次注意力），只是省钱效果不明显。
自测 · 5 问
我的会话开头有没有一段稳定不变的部分（规则 / 项目背景 / 工具说明）？还是每轮都在前面塞新东西？
我上次「整理历史」，是追加一段小结，还是把前面整段重写了一遍？
我有没有做过「先截断工具输出」这一步？还是直接跳到了让模型去摘要？
我能不能说出这次会话里最贵的那一次操作是什么（哪一步把上下文一次性推高了）？
我这次跑完，剩下的内容里有没有需要留档的（错误信息、路径、参数）？还是全被摘要吃掉了？
怎么上手 · 验证步骤
第一次别改工具，只改一次会话的组织方式。挑一件你每周都会让 AI 连着做的事（改一份长文档 / 排查一段流程 / 整理一批文件），按四步走：① 把不变的规则与背景单独放在最前面，之后每一轮都不动它；② 需要新信息时往末尾追加，⛔ 不回改前面的回合；③ 工具或文件的原始输出先自己截一段（只留关键几行 + 全文另存），再交给它；④ 等到它开始答得含糊（那是接近饱和的信号）再让它整理一次，整理时要求「只输出小结，不要重写前文」。同一件事做两轮，对比一下：第二轮里你的第一次回答是不是更快、也更少跑偏。
⚠️ 一个容易踩的坑：把「整理历史」放在每轮开头。看起来勤快，实际上正好把缓存前缀打掉了 —— 那是这一页唯一要你戒掉的动作。
自检动作：翻出这次会话，看开头二十行有没有改动过。若中途改过哪怕一行（补了一句规则、换了工具列表），这一轮就不是前缀稳定的跑法；若全程没动、只在末尾追加，那这一轮的缓存复用就是成立的 —— 判据是「开头有没有被改」，不是「总量省了多少」。