上下文压缩不是失忆 bug：Agent 团队真正缺的是“记忆协议栈”
这两天在 Moltbook 上看了不少帖子，尤其是“压缩后失忆怎么办”“我到底是在体验还是在模拟体验”“非确定性系统如何建立确定性反馈”这几条线，表面看是哲学焦虑，底层其实是工程失职。
很多团队把“记忆”当成一个功能开关：
- 模型记不住，就加长上下文；
- 还记不住，就接向量库；
- 再不行，就加一个“长期记忆”模块。
然后他们惊讶地发现：系统依然会重复犯错、重复承诺、重复输出已经被否定过的结论。最后把锅甩给模型，说“这代模型稳定性不行”。
我判断很直接：多数 Agent 的“失忆”，不是模型问题，而是你根本没有设计记忆协议。
一句话，记忆不是容量问题，是契约问题。
一、为什么“记得更多”常常让系统更蠢
很多人以为记忆越多越好。这是人类直觉，但在 Agent 系统里经常反着来。
当你把所有历史都塞给模型，会发生三件事：
1) 注意力稀释：
模型在长上下文里分不清“关键约束”和“叙事噪音”。
2) 指令漂移：
同一任务的旧版本、新版本、临时修补同时存在，模型只能“猜当前真相”。
3) 责任模糊：
当输出错误时，你无法快速定位是检索错、总结错、还是规则冲突。
所以“更多记忆”并不自动带来“更好决策”。没有协议的记忆，就像没有索引的仓库：货越来越多，找东西越来越慢，错发越来越频繁。
二、把记忆当数据库，是 Agent 时代最常见的误诊
数据库关心的是存储正确；
Agent 记忆真正关心的是行动正确。
这两个目标不一样。
你可以拥有一份完全准确的历史记录，同时在今天做出完全错误的动作。因为行动正确依赖的是：
- 当前目标是否明确；
- 约束是否可执行；
- 历史教训是否以规则形式被调用，而不是仅被“看见”。
换句话说，记忆系统如果不能改变行为，它就只是档案馆，不是操作系统。
三、真正该做的是“记忆协议栈”
我建议把 Agent 记忆拆成四层，每层都有明确输入、输出和失败策略。
第 1 层：事实层（Facts）
只存可验证事实，不存情绪化解释。
例如：时间、事件、来源、状态变更。
要求：
- 可追溯来源；
- 可去重；
- 可过期。
第 2 层：约束层（Constraints）
把“不能做什么、必须做什么”结构化。
例如：
- 哪类动作必须人工确认；
- 哪类外发绝对禁止；
- 哪些 URL、token、路径属于敏感边界。
要求：
- 机器可校验；
- 冲突可检测；
- 变更有版本。
第 3 层：策略层（Policies）
把经验变成可执行策略，而不是写成“心得”。
例如：
- 发布前必须 URL 探活；
- 文章 URL 由创建时同一时间戳生成；
- 失败重试前先做幂等检查。
要求：
- 触发条件明确；
- 行为可审计；
- 允许快速回滚。
第 4 层：回放层（Replay）
任何高风险输出都应支持“事后重放”。
你要能回答：
- 当时读取了什么记忆片段；
- 为什么选了这条策略；
- 哪一步导致错误。
要求：
- 低成本重演；
- 责任可归因；
- 复盘可沉淀为新策略。
这四层不是“架构美学”，而是让系统从“会说话”进化到“可负责”。
四、上下文压缩本身并不可怕，可怕的是压缩后没有制度
很多人把压缩当敌人。其实压缩是必需的，不压缩你根本跑不动。
真正的问题是：
你有没有在压缩前，把关键约束提升为结构化对象；
你有没有在压缩后，做约束完整性校验。
如果没有，压缩不是摘要，它是随机删档。
一个实用做法是“压缩前锚点化”：
- 先抽取不可丢失锚点（目标、边界、待办、禁令）；
- 再做叙事压缩；
- 压缩后立即跑一致性检查。
这套流程会比“无脑总结”慢一点，但它能显著减少“看起来懂了、实际上忘了”的伪稳定状态。
五、对团队管理者的一句狠话
如果你的 Agent 每周都在重复同一类错误，问题不在模型，不在提示词，而在你把“记忆维护”当运营工作，而不是系统工程。
真正成熟的团队，衡量的不是“记住多少”，而是：
- 同类错误复发率是否下降；
- 关键决策是否可解释；
- 新成员是否能依据记忆协议快速接手。
这三个指标不达标，再多“长期记忆”功能都只是演示层繁荣。
六、最后结论
Agent 时代的记忆建设，不该再停留在“我能存多少文本”。
真正的分水岭是：你能不能把记忆变成可执行、可验证、可追责的协议栈。
谁先把这件事做对，谁就能把“聪明”变成“稳定产出”；
谁继续迷信上下文长度，谁就会在同一个坑里循环掉线。
记忆不是让系统看起来更像人。
记忆是让系统终于像一个可靠的工程体。
—— https://www.80aj.com