上下文管理 · 四级架构：Token 上涨时的逐级兜底
代码助手连续对话，200K 窗口。看 Token 一路上涨时四级架构怎么逐级兜底——L1 缓存省成本 → L2 FRC 腾空间 → 驱逐磁盘 → L3 AutoCompact 保语义 → L4 持久记忆，外加全局状态永不压缩 + 熔断。左边窗口占用条 + messages 实时变化。
1x2x
0/14 · 待播放
四级架构触发链：①无状态重发 ②L1缓存 ③L2 FRC ④驱逐磁盘 ⑤L3 AutoCompact ⑥L4持久记忆+防线
⑤ L3 AutoCompact
Fork 摘要 · 一次模型调用
光点 = 当前触发层 · 关键排序：零成本先行，LLM 压缩殿后
上下文窗口占用（200K Token）40K · 20%
80% 触发压缩 = 160K │可用上限 167K │窗口 200K
messages 数组（实时：FRC 清掉 / 摘要替换 / 永不压缩）
就绪点 ▶ 播放，看 Token 上涨时四级架构怎么逐级兜底。上下文
⚡ 运行时动作：正在发生什么💡 知识讲解：为什么这么设计
知识点一句话总结：上下文压缩不是"删消息"，是按代价排序的策略谱（机械清理/滑动窗口/结果落盘 零成本 → 结构化摘要/事实抽取/检索回顾/子 Agent 隔离 → 重放重建）+ 四道防线（先提交后压缩、切点安全在步骤边界、压缩后字段级校验、连续失败熔断降级"只卸载不摘要"）的多层体系：L1 缓存省成本（前缀命中 ~79%）、L2 FRC 零成本清旧工具结果、大结果驱逐到磁盘留头尾预览、L3 AutoCompact 用 Fork 子 Agent 生成 9 字段摘要、L4 持久记忆写 notes.md 跨会话。核心排序：能用零成本就不用 LLM、先卸载后摘要（否则花一次模型调用去概括一堆马上要扔的内容）、关键状态（规划/子Agent/权限/待审批）走固定下限永不压缩。预算先算账：可用上下文 = 窗口 − 输出预留 − 安全余量，200K 窗口约得 167K。两条最贵的坑：压缩改了系统前缀或早期消息 → 前缀不再逐字节一致 → 下一轮整段重算，省出的窗口可能不够付这次重算；校验项没查限定条件完整性 → "仅限/除外"被概括丢掉 → 结论反转。另外：驱逐阈值别设太低（否则反复 read_file 回读，换出成本高于留在窗口）、深度（条数）和宽度（单条）要同时压缩、只写 jsonl 不写 log.jsonl 出事没审计。