摘要只配当导读：让 AI 长对话不失忆的分层压缩架构（附业界对比）

日期：2026-09-13 ｜ 性质：技术分享文档（供公开发布）

来源：MFS（Memory Flow System，单用户本地 AI 记忆系统）上下文压缩架构的完整设计与实测记录，对照业界公开方案整理而成。

姊妹篇：《贵的不是上下文长，是前缀形状变了几次：MFS 的 KV-cache 命中优化与注入分层》——本文回答"发什么"（压缩），它回答"按什么顺序发"（缓存命中的完整设计：损失公式、注入分层、缓存经济学）。

阅读提示：本文呈现的是一套完整的压缩架构——为什么这么设计、业界怎么做、MFS 怎么做、代价是什么。所有数字均出自实测或公开资料，诚实标注已知缺陷与取舍。

长对话 AI 的"失忆"不是玄学，而是压缩机制的结构性缺陷。本文从根因出发，逐层拆解一套以"分层段块 + 双逐字轨"为核心的压缩架构，并与 Claude Code 等业界方案正面对比。

0. 摘要

一句话结论：在"上下文压缩"这一单项上，MFS 的设计深度超过业界所有公开方案——"分层段块 + 双逐字轨 + 经济闸 + 终态链 + 确定性降级"的完整结构，业界没有任何一家有公开对等物。但 CC（Claude Code）的 20:1 摘要是数百万用户验证过的服役下限；MFS 用约 4 倍机制复杂度换精细度，在单用户本地场景值得，多租户产品场景未必划算。

压缩哲学三句话：

1. 摘要只配当导读，逐字才是主轨——前沿模型摘要 ≈ 原文 1/7 信号量（arXiv:2607.09691），确定性选择 + 逐字保留原文片段 ≈ 全上下文效果、token 只要 1/3；
2. 压缩必须付缓存税，所以要么不动、要动就一刀动到底——KV-Cache 让旧字节按 0.1 折续费，但每次改前缀形状 = 改写点后全部全额重付（"过路费"）；频繁小压 = 每次按全额付费，越频繁越贵；
3. 保真不靠"压得少"，靠四层兜底各管一段——事实轨管数字/路径/命令，原话轨管用户原话，尾部原文管新近上下文，recall_history 管定点取回；散文压到 20:1 也不丢关键信息。

实测基线（详见正文）：真 LLM 段生成 4.2s、压缩比 5.4%；全链路 77,900 → 38,360 token（44.1%）；缓存命中 99.3%；覆盖完整性检查 3,000 段 3.6ms；写回体量 128k 档 miss −84%、1M 档 −99%；用户真话预算存活率 30% → 90%。

一、问题定义

1.1 现象与根因

现象：AI 助手"失忆"——旧摘要越压越短、早期细节消失。

根因有两层（实测确认，第二层比第一层更严重）：

1. 单份覆盖重压：旧实现每轮把"已压缩的旧摘要"与"新增内容"一起重压成一份——最早的信息每压一次掉一层。业界证据一致：一次压缩留 53%、五次只剩 10%（Compaction Cliff）；递归合并放大幻觉（ACL 2025）。
2. 口径错位（真因）：cut_idx 用 _messages 的下标计算，却拿去切 _full_messages。第 2 次裁剪起，真正被裁掉的轮次从未进过压缩器（被静默丢弃），压缩器反复压的是最老的、已压过的 1–2 轮；同时 _full_messages 因长度比较同步已冻结，永不更新。

1.2 改造前的七种并存机制

MFS 原有 7 种压缩/裁剪机制并存（C1–C7），全部锚在写死的阈值上（20 轮 / 150k 字符 / 200k 硬顶），不随模型窗口走，且多路径直接改写历史原文：

1.3 新设计必须满足的四约束

1. 同一条原文只压一次，且"被压缩的输入 == 被移除的轮次"可断言（否则口径错位复发）；
2. 历史原文不可变——一切裁剪/清理/摘要只作用于发送副本（护前缀缓存、护写盘原料、护向量提炼原料）；
3. 阈值必须随模型窗口走（比例制），不写死；
4. 工具结果与对话记录手法分开：工具结果用零模型处理，对话记录才用 LLM 摘要。

1.4 效果目标（G1–G8）

二、业界基线（2026-09 查证）

2.1 四家方案对照

六条结论性方向（实施依据）：

1. 每轮全量发送 + 窗口比例兜底压缩（三家共性）——大窗口 + prompt cache 才是"记忆好"的真正原因；
2. 触发与占用判断锚在真实 usage，不是字符估算；
3. 工具结果是清理重点（清它省最多、几乎不损决策信息）；
4. 压缩时保留最近少量消息原文 + 一条摘要；
5. "重压旧摘要"已被证实衰减（Anthropic 官方、ACL 2025），"不重压摘要"已有生产实现（Pydantic AI 锚定增量更新）；
6. 压缩必须可见：CC 的静默 microcompact 曾致有效上下文被削到 40–80k，社区强烈反弹。

2.2 九条关键外部证据（支撑设计转向）

2.3 延伸：记忆系统层面的对比

AgentMemBench（2026-08）给出压缩策略（CBS）实测定位：长程回忆 Recall@5 = 0.556，仅次于稠密向量检索（0.573），远超滑窗/图谱/联网（≤0.005）——压缩+检索双轨是有效路线，MFS 正是"压缩后的段散文留在 payload + 逐字事实仍可检索"的混合形态。

一句话定位：业界在做"事实卡片库"（查得快、答得准、可治理），MFS 在写"一本有人格的书"（有因果、有情感、有厚度、知道自己在重复什么经历）。

三、总体架构：S0–S3 四层流水线

3.1 分层总览

3.2 S0｜token 统计地基

按窗口百分比触发，若建立在 chars÷2 粗估上，百分比就是虚的。三层结构：

① 真实 usage 锚点（主）：每次 LLM 响应后从 provider usage 取总输入 token 记为 anchor；拿不到 usage 的轮次（流式中断、异常）只估算、不更新锚点——防把坏锚点当真；口径统一为仅输入；同时记录"结构指纹"（消息条数 / 末条消息 id / 槽内容哈希），tools 集合不计入（按轮变化，计入则锚点每轮作废）。锚点随会话 dump 持久化、重启恢复（修复前锚点只在内存，重启即丢 → 预热静默失效）。

② 增量估算（只算新增）：pressure_next = anchor + estimate(本轮新增)。分类估算按字符类别加权：CJK ÷1.5、拉丁单词 ÷4、代码/JSON ÷3.2、数字/标点 ÷3；连续串数字必须按串建模（实测 32 位数字 = 12 token，逐字符估差一倍）。固定开销不估算——anchor 已包含。

③ 结构变化时重置：压缩/裁剪/槽重写 → 指纹变化 → 退回全量估算，用下一次真实 usage 重新锚定。误差不累积。

④ EMA 自动校准：k ← (1−α)·k + α·(真实增量/估算增量)，α=0.3；偏差持续 >15% 告警一次，不打断对话。

⑤ 双保险触发：

实测基线：离线 fixture MAE 8.3%；整请求估算 29,310 vs 真实 27,485，偏差 +6.6%。

3.3 S1｜全量发送（内置，不可配置）

• 每轮请求 = 当前会话全部消息（system + 知识槽 + 完整历史 + 全部工具结果）；无"最近 N 轮"裁剪；
• 代价（如实）：单轮输入随会话长度增长 → S0 统计、hard guard、413 兜底、成本监控是必需项，不是可选项；
• 固定开销必须扣掉：system+tools+槽实测每请求 26k+ token → 32k 档不可用、64k 档余量很小；
• 三处判据同一把尺：主对话 + 自主循环 + 第三套硬编码阈值，统一收敛到 context.profile；
• 换模型 = 改 window_tokens 档位字段，代码零改动。

3.4 S2｜旧工具结果清理（零 LLM，最省 token）

纯函数（入参发送副本、返回新列表，绝不碰历史原文），三档处理顺序执行：

启用时机：压力 ≥ warn 线即开（零成本）。硬约束：不能出现"有 tool_calls 没有结果"的孤立对。实测（40 轮合成会话）：清理 72 条 + 剪枝 8 条，省 167,552 字符；清理后压力低于压缩线 → 跳过本轮 LLM 压缩（省一次调用）。

3.5 S3｜摘要保真清单

保留: 完成任务与结果 / 重要决策与理由 / 进行中任务状态 /
      关键文件与变更(文件名+摘要+关键行号) / 用户重要偏好与约束 / 路径·命令·报错串·数字(逐字)
丢弃: 工具详细输出(只留结果) / 中间步骤细节 / 已解决错误的细节
输出: 条目式要点清单 + 可累加(旧摘要的关键项并入, 不整段重写) + 数字/路径/原话照抄(硬要求)

两个"不采用"： - 不采用四栏结构化模板：模板不产生信息、只产生格式税，还诱导模型为凑栏位写"无"； - 不采用语义线索表（关键词抽取"目标/要求"类语义行）：实测挤占数字轨预算（数字命中 8/9 → 4/9），且属于"系统替用户判断什么重要"——重要性判断由 AI 助手自己的台账（record_value / set_user_profile）当场落库承载。

3.6 发送视图构成

发送视图 = system(静态) + 知识槽 + [ L1 ][ L2 ][ L0-a ][ L0-b ] + 最近 K 轮原文
           └── 固定开销，锚定在 anchor 里 ──┘ │    ↑ 已固化层：只在收拢时变
                                              │    ↑ 未固化增量：新段永远追加在末尾
                                              └── 段块 = 固化层 + 增量（由旧到新，时间正序）

3.7 存储三层与清理

段（压缩产物）的三层存储：

压缩进度四处留痕：段结构（随 persist 落库，"压到哪了"的主体）、压缩摘要 sidecar、token_usage_log 账本（source='compact'，每次压缩器调用的时间/token/miss）、会话 dump（一切可重放的兜底）。

清理设计逻辑（有存储就有清理，不接受死数据）：快照类有 TTL（persist 6 个月 / 垃圾桶 7 天）；真源类不自动清（dump/md 只随用户删对话连带删）；账本类按期滚删（token_usage_log 180 天，最远先删走索引）。

四、核心机制：分层段摘要

为什么不用"单份覆盖摘要"：重压旧摘要会逐层衰减（外部多方证据一致），且原实现存在口径错位（§1.1）。"不重压摘要"已有生产实现背书（Pydantic AI incremental=True：旧摘要作为锚定块原地更新）。MFS 的差异化 = 多级分层 + 整体收拢 + 逐字事实轨。

4.1 五步循环与块形状演化

块形状演化（实测轨迹）：

全程 uid 区间单调递增、覆盖零丢失；收拢后块形状回到 [L1][L0][L0][L0]——递增、反复、形状稳定。

标签约定：渲染标签按位置编号（从最老固化核起 L1、L2、L3…，未固化增量统一 L0）；内部 level = 压实深度，只用于合并判据。两者有意分离——若判据也用位置编号，"同层成组"永远找不到成对成员，分层递归失效。

4.2 触发档（谁先成立谁触发）

档① 为什么默认关：它是"摘要的摘要"（递归合并放大幻觉，E3），且每次改块 = 一次前缀 miss——128k/600 轮产生 597 次、64k/800 轮 732 次（生产冷却下约 60 次），是档②（3 次）的 20 倍；有界性实测完全不依赖它（三档零丢弃）。

两道经济闸（"整体到 80%"是收拢的必要条件、不是充分条件——不满足就整单放弃保留原段）：

1. 回本闸 payback = miss ÷ freed ≤ 40 轮：miss ≈ 段块之后的全部 token（改块即其后全部重新 miss），freed = 块前 − 块后。已知结构性限制（如实）：合并输入被 _SCOPE_CAP_CHARS（120k）钉死 ⇒ freed 有常数上界，而 miss ∝ 窗口 ⇒ 大窗口下回本闸结构性难通过（1M 档实测 213 连败）。定位：大窗口由档⓪ 应急豁免兜底，档⓪ 稳态主导；
2. 变小闸 freed ≥ 0.35 × 块前——防"合出来跟输入一样大"。档⓪ 应急时放宽为"只要真的变小"（应急时唯一替代是 413 或丢段，任何真实收缩都更优）。

一次合并的固定代价与块大小无关、收益 ∝ 块大小——晚合并永远优于早合并（实测小层块被拒 no_shrink(1456→343)；大层块成功 13,032 → 5,472）。

4.3 终态链（深度到顶后的降级序列）

• 确定性下沉（零 LLM）：事实行并集 + 散文每段截 120 字符，并把最冷的 L0 一并吸入；
• 整段淘汰：丢导读地图保命，免经济闸——它是保命终态，不做比值判据，只留效果检查"淘汰后 payload ≤ 0.9W"；
• 深度硬上限 max_consolidations=3：一次压缩留 53%、五次只剩 10%（E4）。

4.4 fit 切点轮对齐（生产事故修出的规则）

合并/压缩范围必须先裁到装得进输入预算（segment_input_cap_chars=120000），否则渲染文本超 prompt 上限时中段没进过摘要而 uid 声明已覆盖 ⇒ 内容静默消失。

v2.5 生产实测 missing=23 现形后补的三件套：切点按字符预算从最老端裁，可落在轮中间（含 u_k 不含 a_k），被劈掉的轮尾 assistant 永远无人认领 ⇒ 覆盖不变量违规。修复：

1. fit 后逐条回退到最近轮起点（下限与 min_messages 一致）；
2. 对齐不回去的由 make_segment 内部截断闸（truncated>0 ⇒ 降级段）零丢失兜底；
3. 挑食门槛——冷区间 token 不足 → 记 range_too_small 跳过：区间留在 payload、不漏不压，宁可不压也不产出低质量小段。

4.5 双轨内容（治"数字被改写"）

• 清单必须有独立预算：实测 run_shell 日志与 grep 的"路径:行号"命中率 100%，不给预算等于原文（压缩率 0）；纯中文语义对话命中率 0%（语义内容靠散文 + 台账承载）；
• 预算：2400 tok / 40 行 / 单行 200 字符（头 150 + 中略 + 尾 50），超预算按优先级（报错/命令/路径 > 纯数字）截断并标注；
• 主次定调（E2）：逐字事实清单是主轨、段散文只是导读——清单为准，散文可能写错数字，清单不会。

4.6 异步预压生命周期

1. 压力达 warn 线排后台任务，把已冷却历史压成 L0（只读原文、只写新段）；
2. 快照必须在进入线程前做完（线程内禁止读 _messages，防竞态）；
3. 任务显式持引用；每会话并发 1；取消 = 放弃结果；
4. 原子提交：提交前校验 uid 区间仍连续存在且逐条哈希一致，否则丢弃记 commit_rejected；
5. 达线时段未就绪 → 用"已有段 + 最近 16% 原文"先发，后台继续压；
6. 最小区间门槛 max(2000, 2×段目标)：小输入压了白压（实测 271 token 输入只能压到 86%）；
7. 重启预热（preheat）：重启恢复会话后立即预检一次压力，达档即提前排预压，不等首轮发送撞墙；四级日志出口（warn/compress/hard → 排预压；ok → 留痕跳过；异常 → 静默）。

4.7 失败降级

确定性降级段（零 LLM）：区间内每条消息保留头 120 / 尾 60 字符 + 逐字事实清单；标 degraded=true；允许一次"追赶升级"（仅限段块末尾 1 个段，升级后长度必须严格下降）。

4.8 段边界六条硬约束

1. 切点落在完整 tool 组之外（不切 tool_calls↔tool 配对）；
2. 落在登记的 turn 起点——"轮"不由 role=="user" 界定：四个入口（user / 自主任务 / 定时 / 感知）统一登记并打单调 uid，纯自主窗口同样能分段；
3. 覆盖区间不得包含 system[0] / 知识槽 / 段块自身 / 当前轮起点之后；
4. 必须整条包含 <summary> 与轮内注入的临时 system；
5. 尾部保留与 min_keep_messages 同时成立：retain 按轮累计，最后一轮自身超 retain 则整轮保留；
6. 提交前校验 uid 区间仍连续存在且未被覆盖，否则丢弃本次段。

4.9 压缩器输入裁剪与写回体量

_tool_digest()（零 LLM 确定性裁剪）：工具正文进压缩器时只给首 400 字符 + 尾 200 字符 + 前 12 条事实行——数字/路径已由事实轨逐字抽走，让压缩器逐字读日志是白烧输入。实测输入 59,994 → 15,010 字符（省 75%）。发送视图完全不受影响。

写回体量定则：段块位于 payload 前部 ⇒ 任何一次改块都让它之后的全部内容重新 miss ⇒ "每次只压一点点、却频繁发生" = 每次按全额付费（抖动）。因此：

1. 预压区间先裁到输入预算内再压，且切点对齐回轮起点；
2. 输出目标按区间比例给（clamp(区间 × 0.50, 1000, 16000)），不钉死固定值——旧默认钉死 1,000 token 导致 34:1 压缩比 + 抖动。

触发时机的设计依据（为什么"攒满一刀 + 0.85 提前排"而不是定期压）：定期压缩产生次满事件——每刀吃不到预算，事件次数翻倍，而每次改段块的过路费 ≈ P 几乎不变 ⇒ 总过路费 ∝ 1/Δ，越频繁越贵。三档触发实际是提前压：warn 0.85 排后台预压 + S2 零 LLM 清理先手（能白嫖清掉的先清掉），只有 hard 0.95 是"马上死才压"的救命档。频繁压不提升保真——保真由四层兜底保证、与频率无关，只会把段切得更碎、加速收拢与衰减。

五、保真结构：六不变量与四层兜底

5.1 六条不变量

5.2 I① 覆盖完整性的全链四道防线

洞既可能被制造（压缩选不出起点）、也可能被静音（出口白名单误吞）⇒ 防线必须分层设防，不靠单点：

教训实录：白名单曾漏认降级标记，把设计行为误报成生产 ERROR；后又发现"视图洞叠加降级标记时，白名单会把真洞静音成预期结果"——日志文案必须自解释，否则读者会把设计行为读成漏洞。

5.3 四层保真兜底（各管一段）

5.4 用户原话轨（v1.4）

为什么必须有：事实轨只认含数字/路径/命令的行，用户说过的"以后所有脚本一律用 LF 换行"这类纯语义需求恰好落在夹缝里——事实轨不要它（无技术串）、散文轨会把它压薄、台账靠模型当场自觉（不保证）。改为按来源保底：role == "user" 的原话一律逐字保留，不进摘要、不进压缩器。

硬约束：不做"最近 20k 的滚动窗口"——那样它每轮都变，把"只追加"的尾部变成每轮重写区，省的钱全部赔回去。

六、缓存协作要点

本文与姊妹篇《贵的不是上下文长，是前缀形状变了几次：MFS 的 KV-cache 命中优化与注入分层》分工：本篇回答"发什么"（压缩），缓存侧的完整设计——损失公式与 E8 实证、payload 七区结构、注入分层 L0–L3、0.1 折续费账本、过路费模型、台阶式淡出、编号即寻址、"宁陈旧不抖动"、双路径同构与量化验收——全部收录于姊妹篇。这里只保留与压缩器直接相关的三条协作纪律：

1. 一次压缩事件 = 段块改动点起全部 miss（128k 窗 ≈85k token 单次）——所以回本闸双门槛（freed ≥ max(0.35 × 压缩前体量, miss ÷ 40 轮)）必须过，不过不压；
2. 原话轨重建只发生在压缩事件当轮——与段块改写绑同一列车，同一次全价、两份变动（搭便车）；
3. 合并、收拢、旧 summary 剥离同一窗完成——"少动、动到底"，绝不连续多轮各动一点。

七、用户消息处理：分清谁在说话

7.1 三类错收与危害

原话轨曾按 role == "user" 一刀切整条逐字收轨，三类消息被错收：

危害排序：语义污染（最隐蔽）> 预算挤占 > 文档无摘要层。

7.2 方案论证与裁决

三方案对比（来源标记 A / 文档指针化 B / LLM 判定 C）后的两个关键发现：

1. B 单独不成立——它只治文档，不治引用 AI（引用 AI + 用户批注必须收全文，否则批注丢失），只能作为 A 框架下"文档条目"的处置策略；
2. C 违反"能向量不 LLM"——判定"是不是用户说的"本质是相似度问题，正是向量的主场，用 LLM 是杀鸡用牛刀还引入新失败模式。

裁决：A 框架 + B 作为文档子处置 = "来源判定 + 分类处置"——判定层零 LLM，处置层按来源分类施策。

7.3 判定层（三级优先级，零 LLM）

• 质量闸（防伪向量）：embedding 服务的真实故障模式是静默返回垃圾而非抛异常——失败时可能返回 sha256 伪向量。利用伪向量的确定性：同文本必然算出同向量，闸门内逐条用 _embed_fallback 重算精确比对，命中即伪向量 → 整体降级 owner；
• 降级完整口径：任何环节失败 → 该消息按 owner 处理，原话轨退回现行行为，压缩管线永不阻塞；
• 判定顺序的理由：显式标记是用户亲手指定的来源，比任何推断都准；引用判定优先于长度——用户贴很长的 AI 输出时"引用 AI"语义更准。

7.4 处置层（四类条目，四样施策）

渲染示例：

[#102] 帮我把连接池参数改成 30

[#109] [引用AI] （用户复述 AI 原话全文）

[#130] [引用AI+批注] （引用内容…用户的批注…）

[#188] [文档] 部署日志第 3 节的性能问题帮我分析下
【文档引用】workspace/attachments/a3f2b1c8d4e5f607-部署日志.md
（导入时快照：128,402 字符 | 首行：部署日志摘要——9月12日灰度…）

7.5 前端三通道（治本第一环）

根因是前端没有让用户表达"我发的是什么"的通道——一切只能靠后端推断。业界教训：自动注入来源不可靠（Cursor "最近浏览文件"自动附带导致大量 stale context 事故），显式引用是唯一可靠形态：

粘贴阈值 1500 字符的论证：低于后端 1500 token 判定阈值（前端快照化先行，指针永远先于判定到位）；ChatGPT web 是唯一"粘贴自动文件化"先例（5,000 字符自动转附件），MFS 与之同构但阈值更激进——因为 MFS 有更硬的理由：粘贴文本逐字进原话轨（预算 ~19k token），5000 中文字符一条吃掉 18% 预算。

7.6 快照制（git 对象风格）

裸路径（活引用）有三个致命问题：变动问题（文档改了路径不变 → 非确定性，ChatGPT Project Files 官方立场即静态快照）、缓存破坏（每轮按路径重读最新 → 文件一变全额 miss）、审计缺失（三个月后回看"当时发的是什么版本"无据可查）。

裁决：纯内容寻址快照——workspace/attachments/{hash16}-{原文件名}.md：

路径内嵌内容哈希，指向不可变副本：改内容 = 重新导入 = 新哈希 = 新路径；路径字符串写进消息后字节恒定 → 前缀稳定；与 append-only 哲学完全同构。

7.7 快照清理联动（生有来源，灭有依据）

裁决：快照寿命 = 三处引用痕迹全灭 + 48h 宽限，两条清理线共用三处并集查证 _snapshot_referenced（DB dump ILIKE ∪ broker 活跃会话 ∪ chat_*.md）：

关键设计点：restore 会把 dump 从 DB 删掉（活跃会话原始对话只在内存）——若只查 DB 会误删活跃会话正在引用的快照，故必须三处并集；记忆指针不保快照（切片里的文档指针在快照退役后指向"原文已回收"，但精炼内容 + 因果链骨架仍在——原文可退役，记忆不可）。

7.8 落地效果（v1.4，测试 72/72 + 两轮独立审查通过）

场景：一轮压缩事件里，用户贴 3 篇 5000 字文档 + 引用 2 段 AI 长发言并批注 + 说了 5 句真话：

同样 9.8k 预算（64k 窗）下，用户真话的存活空间从可能不足 30% 提升到 ~90%，91% 预算留给用户原话。四条硬收益：语义污染清零、缓存纪律零破坏（渲染逐字节稳定）、故障全兜底（BGE 挂 → 整体降级 owner，不会错收只会少判）、快照生灭有据。

BGE 止损规则（防无限调参）：探针显示 owner 误标率 > 5% 或两档分布重叠不可分 → 整体裁撤 BGE 推断层，判定退化为"显式协议 + 长度兜底"，止损点写死。

八、正面对比：MFS vs Claude Code

前文各章已拆解 MFS 的机制细节，本章回到最初的对比问题：与 Claude Code（CC）的滚动窗口单段摘要相比，这套"台阶式 + 双轨 + 台账"的复杂度到底换来了什么？先用一张机制对照图看清两者的根本形态差异，再逐维度对照，最后给出三点不回避的保留意见。

8.1 机制形态对照

CC 的形态是滚动窗口：窗口逼近上限时，把全部历史一次性交给 LLM 压成一段摘要，摘要替换原文成为新的"历史"，尾部保留最近若干轮对话。MFS 的形态是台阶式：多次小步压缩，每次只动一小段，且事实、原文、摘要各有归宿。

一句话概括形态差异：CC 把历史压成一团"记忆摘要"，MFS 把历史拆成"事实账本 + 原话档案 + 摘要导读"三层各有职责的存储。前者的风险集中——一次摘要失败或失真，全部历史受损；后者的风险分散——任何一层出错，其余层仍可兜底。

8.2 八维度对比表

8.3 结论与三点诚实保留

结论：两种形态是不同约束下的产物，而非简单的优劣关系。CC 服务于云端多租户——机制必须极简、延迟必须低、单用户成本必须可摊薄，单段摘要是合理的工程选择；MFS 服务于单用户本地——KV-Cache 经济学成立、延迟可容忍、追求极限保真，台阶式 + 多层兜底才有施展空间。§二 的外部证据（E3 递归合并放大幻觉、E6 缓存与压缩对冲）说明 CC 形态存在已知的结构性风险，MFS 的复杂度正是花在规避这些风险上。

但有三点必须诚实说清：

1. 验证规模不可比。CC 的 20:1 是数百万用户日常使用中"够用"的服役下限；MFS 的指标（MAE 8.3%、81.1% 命中、116 项门禁）来自单环境实测与构造测试，未经过同等规模的分布外考验。"设计上更保真"与"大规模下更保真"之间还隔着距离。
2. 4 倍复杂度换精细度，只在本环境成立。S0–S3 四层 + 双轨 + 快照制的每一层都有其理由，但也意味着每一层都是潜在的维护点与故障面。单用户本地场景中这份复杂度由设计者本人消化；若迁移到多租户云端，运维与调试成本很可能反噬精细度收益——届时 CC 式极简反而是对的。
3. 深压延迟是真实代价。台阶式的"多次小步"在极端场景（1M 档、深压）下意味着本地模型 prefill 2.7~5.5 分钟的等待。CC 用户永远不会遇到这个量级的压缩延迟。MFS 用异步预压与 preheat 预热缓解，但无法消除——这是"结构保真"向"响应速度"收取的费用。

九、工程化：降级、透明与门禁

机制设计只是纸面方案，能否在生产环境存活取决于三件事：依赖故障时怎么办（降级）、用户能否看见发生了什么（透明）、改动是否被持续验证（门禁）。本章记录 MFS 在这三件事上的做法——其中审查修复部分特意保留原始缺陷描述，因为"如何发现自己错了"与"如何设计"同样值得分享。

9.1 LLM 端点自动降级（状态机 + 运行时切换）

压缩器复用会话模型端点——主端点宕机意味着对话链与压缩链同时失血：不仅无法对话，上下文也无法压缩，恢复全靠重启。为此在 openai_compat.py 模块级驻留一个降级状态机，覆盖两个咽喉点（对话流式调用与压缩链共用的非流式调用）：

三条判定规则值得注意：

另有一条朴素防御：fallback 三件套（url/key/model）齐全才启用，缺任一项视为未配置（单端点原样抛）——半套降级配置比没有更危险。

9.2 审查修复实录（双子代理逐项审查，5 项）

这轮审查最有价值的产出不是修复本身，而是暴露的缺陷形态——每一项都是"看起来在工作"的隐性断路：

1. P0 · 流式 5xx/429 绕过降级：异常归一化函数只认四类自定义异常 + 超时/传输错误，漏了 httpx.HTTPStatusError（且它不是 TransportError 子类）——流式主端点 500/429 原样抛出、状态机零感知，而非流式路径行为正常。两条路径行为不对称，本身就是缺陷证据。修复：补 isinstance 分支，≥500/429 映射为连接错误进降级。
2. P0 · WS 广播链路断裂：事件处理白名单只有 5 种事件类型，llm_* 与 ctx_* 全落 else 丢弃——连此前增补的压缩状态条事件也一直是断的（推送了、没人收）。修复：else 前补前缀透传分支，一处救两族通知。
3. P1 · .env 毒化：保存坏温度值（如 "abc"）先写盘再校验，接口返回成功——下次重启时 float() 直接抛错、服务起不来，保存当下毫无报错的延时炸弹。修复：写盘前先验，坏值拒绝保存。
4. P1 · 线程安全：压缩链跑在工作线程，asyncio.Queue.put_nowait 非线程安全、状态机读-改-写有竞态。修复：广播经 call_soon_threadsafe 转发主事件循环；状态机函数加锁，广播调用移到锁外（防持锁做 I/O）。
5. P1 · 测试真实性：测试桩只记 model 不记 URL——门禁"证明请求打到了新端点"实为空断言。修复：桩改记 (url, model) 元组 + URL 级断言；新增回归用例（流式 500 零 token → 自动切备）直接验证第 1 条修复。

9.3 前端透明度（六条硬要求）

Claude Code 的静默 microcompact 教训（用户不知道上下文被动了）被列为反面教材，透明度是硬要求而非可选项：

1. used_percentage 实时状态（仅输入口径）；
2. 一次性提示：已清理 N 条旧工具结果 / 上下文已压缩：Xk → Yk；
3. 压缩账目：时间 / 压掉 token / 摘要长度 / 当时档位；
4. 绝不静默；
5. 「工具轨迹」+「上下文分层」两个标签页：轨迹从后端唯一真源（只读接口）还原，分层页肉眼核对段机制（层序、新段在尾、收拢形状、覆盖缺口）；
6. 压缩进行中状态条：压缩后台跑几分钟、聊天流零提示时，"下一轮变慢"不可解释（本地压缩器 prefill 与主推理抢带宽）。两个 WS 事件驱动悬浮条两态："正在整理上下文…" → "已整理（下一轮响应稍慢）"，完成后 3 秒淡出。明确不做的：进度百分比（压缩是单次 LLM 调用，无中间进度）；低频修复路径的推送（账目面板可见即可）。

9.4 门禁体系（机制在 ≠ 机制会被走到）

门禁是这套系统的第三根支柱，共 C21–C117 合计 116 项（含原话轨 4 项、成本文档生效链 3 项、端点降级 14 项、fit 截断轮对齐 1 项），另有用户消息处理 uv_origin 系 72 项。全部为假 provider + 合成长对话仿真（零真 LLM 依赖），每步改动必过。

门禁体系里最重要的单条经验来自"砖机事件"教训：38 道门禁全部用 merge_leveled_enabled=True 去验证机制，而出厂默认路径从未被走过——机制在配置里存在，不等于默认配置下它会被调用。此后立规：凡改默认值者，必须先过只读默认值的门禁。验收清单中对应的硬指标包括：200 轮每一轮被移出 payload 的消息 100% 被某段覆盖（覆盖完整性）、普通轮前缀命中 ≥99%、同输入跑两遍得到相同覆盖集与相同段文本（确定性）。

十、技术决策精选（D1–D16）

16 项决策完整记录于设计文档，此处收录全部 16 项的一览表——每项都标注了放弃的方案，因为被放弃的理由往往比被选择的理由更有信息量：

D16 的捆绑项值得单独强调：改一个参数必须连同它的耦合项一起改。压缩比从 6/9/12 放宽到 10/15/20，前提是事实轨预算翻倍（否则深压后单段覆盖扩大，逐字 100% 不保）、总段 token 上限窗口化（否则 1M 档收拢等效 70:1、需 24 刀）。设计文档为此专门列出"落地必须捆绑的耦合项"清单——参数不是旋钮，是齿轮组。

十一、边界与已知缺陷

11.1 明确不做的六条（边界即设计）

1. 不做盲目检索式召回（全文搜索/归档检索）——uid 定点取回已覆盖需求（D10）；
2. 不做聊天记录自动进记忆切片（向量化 auto_save）、工具细节不进向量库——记忆入库是有意识的动作，不是流水线副产品；
3. 不做 knowledge 槽分层重构——只保留 system[0] 静态化，槽位大改的收益配不上风险；
4. 不学 dsh 的"无自动跨会话记忆"——MFS 的记忆库/事件/话题/联想能力更强，不倒退；
5. 机制参数开关不进设置面板——只留配置文件 + 门禁把关，防止用户误关保真机制；
6. 轨迹不写入聊天记录文件——会污染记忆切片原料的内容哈希检测。

11.2 已知缺陷（如实记录，不粉饰）

十二、结语：五条机制定则

全文压缩到最后，是五条可以迁移到任何上下文压缩系统的定则：

1. 保真由"输入:输出比"决定，不由"能看到多少"决定。任何一次压缩保持小比例（≤4:1）。抬高输入不抬输出，只会把比例推向 75:1，更糟。
2. 块有界 + 历史无限 ⇒ 压缩比必然无限增长。能无限增长的只能是有界结构——逐字事实是主轨，散文允许越来越薄。
3. 只留一条合并机制。合并路径多于一条，意味着"摘要的摘要"有多条演化分支，每一分支都需要单独验证。
4. 语义要点由台账承载。目标、方向、用户要求、偏好由 AI 助手自己落库（record_value 等），压缩器不替它判断"什么重要"——重要性的判断权归用户与 AI 自己。
5. 诚实标注。每个压缩段的段头有一行刻意不含任何数字的常量声明："以下每段都是压缩产物，细节原文已不在上下文中；涉及具体数值/路径/原话时，用 recall_history 按段头 uid 区间取回原文核对，不要把这里的概述当原文引用。"——不含数字 ⇒ 逐字节恒定 ⇒ 不成为新的前缀失效源；诚实声明 ⇒ 模型知道自己记的是"二手信息"。

回头看这套系统的本质：它不是一个更聪明的摘要器，而是一套让"遗忘"变得可控、可审计、可追责的记账制度。摘要只承担导读，事实走台账，原话有归档，取回靠寻址，每一层压缩都有账目，每一个参数都有门禁。业界主流把上下文压缩当作模型的内部机制，MFS 把它当作系统的核心账务——这或许是本文最值得带走的一句话。

本文基于 MFS 内部设计文档《上下文压缩架构设计 v2.9》与《用户消息处理设计方案 v1.4》整理，面向公开读者重新组织。文中所有实测数字（MAE 8.3%、81.1% 命中、-98.6% 等）均来自单环境实测与构造测试；业界数据引用自 2026-09 查证的公开资料，已在正文对应位置标注。