Agent 记忆系统与上下文压缩——被摘要掉的那条约束

分层的价值在于每层的生命周期不同：工具返回几轮后就过期，规则层要活到任务结束，审计层根本不该占上下文（它归 trace 系统，见 T3-11）。开篇的故障，本质就是把"规则层"的内容当成"对话历史"一起送进了摘要器。

生产系统里基本不会只用一种。成熟的组合是：结构裁剪打底（先清工具结果这种大块低价值内容）+ 摘要压缩兜底（还不够再摘要）+ 关键信息置顶保真（规则层与任务层单独维护，不进摘要器）。

一个可直接抄的策略骨架（阈值需按自己的模型和任务校准）：

def manage_context(messages, state):
    if tokens(messages) < THRESHOLD:                 # 未到阈值不动
        return messages
    # ① 结构裁剪：优先清理大块低价值内容
    messages = drop_old_tool_results(
        messages, keep_recent_groups=5,
        protect_tools={"read_file", "memory", "task"},   # 关键工具结果不清
        min_free=5000)
    if tokens(messages) < THRESHOLD:
        return messages
    # ② 摘要压缩：但只摘要「对话与探索过程」这一段
    head, mid, tail = split(messages, keep_tail=10)
    summary = summarize(mid, must_preserve=MUST_PRESERVE_CHECKLIST)
    # ③ 关键状态不走摘要器，从结构化 state 重新渲染
    return [system(RULES), render(state), summary] + tail

第 ③ 步是重点：把"当前任务目标、已确定的决定、硬约束、未完成 TODO、关键 ID/句柄"维护成一份结构化的 state 对象，每次压缩后从 state 重新渲染进上下文，而不是指望摘要器把它们留下来。 这是开篇故障最直接的修法。

截至 2026-08 的实践共识是：不要等到上下文满了才压。 业界建议的触发点比很多人想象的早得多——轻量负载在 5k–20k token 量级就可以开始压，复杂长任务在 50k–100k 量级；作为参照，Claude Code 的自动压缩大约在有效窗口 98% 处兜底，但那是最后一道闸，不是常规策略。

理由是 context rot（上下文腐化，见 T1-12）：上下文越长模型越钝，陈旧的失败尝试、过期的工具输出会持续干扰注意力。压缩的收益不只是省钱，更是恢复注意力质量。

一个经常被漏掉、但面试里说出来很加分的点：压缩会打穿 prompt 缓存。

前缀变了，之前累积的 KV 缓存全部作废，压缩后的第一次调用是完整的冷读。所以压缩不能太频繁——它省的是后续每轮的重复 token，付的是一次摘要调用 + 一次缓存重建。压缩频率过高时，总成本可能不降反升。 这也是把稳定内容（规则层）放在上下文最前面的原因之一（见 T1-4）。

写压缩逻辑时，把下面这份清单变成显式的结构化字段，而不是交给摘要器自由发挥：

1. 原始任务目标（用户的原话，不是转述）
2. 硬约束与禁止事项（组织策略、"不要用 X"、审批要求）——优先级最高
3. 已做出的决定及其理由（"选了方案 B，因为 A 在并发下有问题"）
4. 未完成的 TODO 与当前所处步骤
5. 关键标识符：文件路径、ID、句柄、分支名、会话 token
6. 已经失败过的路径（否则压缩后会重蹈覆辙，这是很常见的返工来源）

表面是一回事，本质不是。 两者都是"从外部存储检索内容塞进上下文"，检索技术栈可以完全复用（分块、embedding、混合检索、rerank，见模块 2）。差别在四个地方：

所以记忆系统比 RAG 多出三个必须回答的问题：写什么（不是什么都值得记）、怎么更新与冲突消解、什么时候忘掉。回答 Q3-14 时，把"记忆需要写入策略和遗忘机制，而 RAG 语料不需要"讲清楚，就足以区分你和背概念的人。

一个务实的写入门槛：只有"跨会话仍然成立、且未来大概率会被用到"的信息才写长期记忆。会话内的中间结论不写；用户随口一提的偏好要打上置信度和时间戳；相互矛盾的记忆按时间戳覆盖，并保留一条变更痕迹便于排查。

• Letta（MemGPT 团队）：把上下文显式分成 in-context core memory 与 out-of-context 的 recall / archival memory，操作系统味道最重。
• Mem0：可插拔的长期记忆引擎，负责抽取、去重、实体链接与检索。
• Zep / Graphiti：时间感知知识图谱，天然处理"事实有有效期"的问题。
• LangGraph / LangMem：把记忆和状态机、checkpoint 绑在一起，和框架的 durable execution 一体。
• 框架侧的压缩能力也在内建化（如可配置压缩间隔与重叠窗口、自定义摘要模型），自己写之前先看看框架是否已经给了。

• 解决什么：突破上下文物理上限，让长任务能一直跑；同时清掉陈旧内容，缓解 context rot，恢复注意力质量。
• 代价是什么：① 信息不可逆丢失，且丢什么不可控；② 每次压缩要额外花一次模型调用（长上下文进、结构化出，不便宜）；③ 打穿 prompt 缓存，后续成本短期抬升；④ 通常是同步的——压缩时 Agent 得停下来等；⑤ 治理风险：以任务连续性为目标的摘要会悄悄抹掉安全约束。
• 什么时候不该用：任务本来就短（几轮就结束，压缩纯亏）；上下文里的内容需要逐字保真（合同条款、代码 diff、审计要求）——这类应该外置到文件系统并按需读取，而不是摘要；以及在一个子目标进行到一半时，宁可晚一点压。

• 别把规则层送进摘要器。系统指令、硬约束应从固定模板重新渲染，永不参与压缩。
• 别只靠摘要，先做结构裁剪。工具返回往往占了大头且价值衰减最快。
• 压缩后做一次自检：让模型基于新上下文复述任务目标和当前约束，不一致就回滚或补注入。这一步很便宜，能拦住开篇那类事故。
• 把状态外置到文件。长任务的中间产物写文件、上下文里只留路径，比什么压缩策略都有效。
• 记忆不是越多越好。低质量记忆是污染源——检索出三条互相矛盾的"用户偏好"，比没有记忆更糟。
• 给记忆写入也做评测。记了什么、召回准不准，要有指标，否则你永远不知道它在帮忙还是添乱。

Q3-12（记忆系统怎么设计）是一二面常规题。Q3-13（压缩怎么选、丢了关键决定怎么办）是二面的追问重灾区——它几乎是专门用来筛"真跑过长任务"的人的，因为没被压缩坑过的人根本想不到"丢了关键决定"是个问题。Q3-14（跨会话记忆 vs RAG）考的是概念辨析的清晰度。

连环追问路径：怎么设计记忆 → 上下文快满了怎么办 → 摘要丢了东西怎么办 → 那你怎么知道丢了 → 压缩对成本的影响是什么（这一问踩缓存）。

1. 先给四层框架，并强调四层的生命周期和失效模式不同。
2. 讲压缩时先讲分层预算，再讲三种手段的组合，不要一上来就说"我们用摘要"。
3. 主动抛出 MUST-PRESERVE 清单，并说明关键状态是从结构化 state 重渲染而不是靠摘要器保留。
4. 加一句成本视角："压缩会打穿 prompt 缓存，所以我们不敢压太频繁，阈值是实测出来的。"
5. 有故事就讲故事——开篇那类"压缩后行为改变"的事故是最好的素材。

只读过资料的回答：

• 只说"短期记忆放上下文，长期记忆放向量库"，再无细节。
• 认为压缩就是"让模型总结一下"。
• 说"上下文满了就压缩"，不知道该提前压。
• 认为记忆检索和 RAG 完全一样。
• 从没考虑过压缩会丢东西，更没想过丢的可能是约束。

真做过的回答：

• 给出分层上下文预算，并说清哪层绝不可压。
• 提到结构裁剪优先于摘要，能说出保留最近几组工具结果这类具体策略。
• 有 MUST-PRESERVE 清单，尤其提到"已经失败过的路径"要保留。
• 提到压缩打穿 prompt 缓存的成本影响。
• 提到压缩后自检 / 复述校验这种验证手段。
• 讲记忆时能说出写入策略、冲突覆盖、遗忘机制——这三点是记忆区别于 RAG 的核心。
• 提到把状态外置到文件系统，而不是死磕上下文。