大模型窗口是什么？ 上下文窗口就是大模型在一次对话中能记住的信息总量 度量单位：token
有什么用？ 1.决定处理的文本长度 2.影响对话质量
但是，当上下文超过100K时，模型会发生上下文衰退，也就是中间迷失，延迟30S以上 同时，API成本翻倍，能力衰退
用户核心意图最开始进入工作记忆，随后大量调用工具、报错信息越来越多，会发生上下文溢出，该怎么办？ 滑动窗口：系统自动把最早的对话部分切除，窗口没变大，但是窗口里的内容在随时间滑动更新 语义压缩：用LLM提炼出核心事实，提升有效对话长度
语义压缩如何实现？ 1.语义摘要summarization 达到阈值时，自动提取历史消息生成Summary块，替换旧对话 2.选择性修剪 不碰用户对话，只针对性剔除很长的工具输出信息，或者无用的日志 3.动态分配UT-ACA 基于Token级的不确定性，动态回滚并扩展上下文窗口 模型在逐字生成token时，系统实时监测，发现有幻觉风险，立刻触发回滚机制
但压缩不是免费的，什么时候压缩很重要 固定阈值触发：例如token达到180K，或者对话达到50轮 机会主义触发（langchain deep agent）：例如：完成一个代码文件编写后；拿到一个明确的搜索结论后
行业主流的阈值设定红线 langchain 85% codex 95%(180k-244k) claude 150k
Claude API：compaction_strategy forge code：看token + 推理链保留（执行压缩时，框架会扫描被淘汰的历史消息，提取出thought标签里的内容，强制附加到新的上下文中）
坑点： 1.为了监控180K的阈值，如果在每次请求前把几十万字的上下文让Tokenizer算一遍，系统延迟严重 基于字符长度做快速估算，只在逼近红线时，才做精确计算 2.一旦执行压缩，历史内容变化，积累的上下文缓存，缓存失效 利用大模型的缓存断点cache breakpoints特性,把系统提示词，核心文档放在最顶端并锁定缓存，不管怎么压缩，顶部的缓存永远生效
把压缩上下文封装成一个tool交给大模型，让他自己调用工具，清理自己的记忆
