主题
第 1 章 记忆为什么成为一等原语
一个已经上线八个月的客服 Agent，某天开始给老客户推荐已经退订的产品。排查花了两天，结论既不是模型退化，也不是 prompt 被改坏，而是三个月前的一次数据迁移把「退订」这条记忆写进了错误的命名空间。Agent 没有忘记，它记错了地方；而系统里没有任何一处能在写入当时告诉运维「这条记忆进错了库」。
这类事故的形状很固定：模型能力没有问题，工程链路也没有断，问题出在记忆这一层缺少自己的正确性定义。上下文窗口、会话状态、检索结果，三者都被当作「模型输入的一部分」来处理，于是谁都不对「这条记忆是否该存在、该存在哪里、是否还成立」负责。
过去两年，记忆被反复讨论为一种「增强」。增强的意思是：有它更好，没它也能跑。这个定位在短会话、低风险场景里成立，一旦 Agent 开始承担跨天、跨周的任务，它就不成立了。任务连续性依赖记忆，成本控制依赖记忆，合规审计依赖记忆，而这三件事没有一件可以「有它更好」。
本章要确立的判断是：记忆已经是一等原语，它同时是上下文的输入、运行时的状态、治理的证据；这三重身份各自有独立的正确性要求，把它们合并成「一段存起来的文本」来处理，是当前多数记忆事故的共同根因。本章先复盘记忆失效的真实形态，再拆解三重身份，然后给出 2026 年尚未解决的三对根本矛盾，最后划定记忆系统的能力边界。
1.1 从上下文到记忆：一次失效的复盘
1.1.1 上下文窗口变大并没有解决问题
一个常见的推论是：既然模型上下文已经能装下几十万 token，把历史对话都塞进去，记忆问题就消失了。这个推论在两处断裂。
第一处断裂在成本。全上下文注入意味着每次调用都重新计费整段历史。Mem0 在 2026 年公布的一组对照数据是：其检索式方案每次调用约 6,900 token，全上下文方案在 25,000 token 以上。差距不是几倍，而是一个数量级；在日活上千的场景里，这个差距直接决定产品能否定价。
第二处断裂在信噪比。LongMemEval 的论文（arXiv:2410.10813）报告了一个更麻烦的现象：商业聊天助手与长上下文模型在持续交互中，记忆类问题的准确率出现约 30% 的下降。注意这不是「记不住」，而是「记得越多越容易取错」——当历史里同时存在「我对花生过敏」和「昨天吃了花生没事」时，把两条一起塞进上下文并不能让模型更聪明，只会让它更犹豫。
因此上下文窗口解决的是「能装多少」，记忆系统解决的是「该取哪条」。两者不是替代关系。
1.1.2 三种被混为一谈的「记住」
工程语境里的「记住」至少指三件不同的事，而它们的正确性标准完全不同。
会话内记住：同一轮任务里，模型需要知道自己刚才做了什么。这由上下文与运行时状态承载，失效表现是「忘了上一步」，修复手段是状态外置与检查点。
跨会话记住：下一次对话开始时，系统需要知道上次聊到哪、用户偏好是什么。这由长期记忆承载，失效表现是「每次都要重新自我介绍」，修复手段是写入与召回管线。
组织级记住：多个 Agent、多个用户、多个团队共享同一批事实。这由语义层与治理机制承载，失效表现是「同一个客户在两个系统里有两个状态」，修复手段是作用域隔离与冲突消解。
三者共用「记忆」这个词，但把它们的实现合并成一个组件，就会出现 1.1 开头那类事故：会话状态、用户偏好、业务事实混在同一张表里，谁也说不清某条记录的权威来源是什么。
1.1.3 失效的四种典型形态
把近两年公开的记忆事故归类，形态收敛为四种。
| 失效形态 | 表现 | 根因 | 可观测信号 |
|---|---|---|---|
| 记错地方 | 记忆存在，但落在错误的作用域 | 作用域靠共享表加过滤条件实现 | 跨租户读取测试失败 |
| 记了不该记的 | 凭据、隐私、被撤回的偏好仍在库中 | 写入前无准入检查 | 敏感度扫描命中 |
| 该忘的没忘 | 旧事实持续干扰新判断 | 只有追加、没有失效机制 | 时序冲突率上升 |
| 忘了但证不出 | 删除了源记录，派生结论仍在 | 删除只做第一层 | 级联依赖未清 |
表 1-1 记忆失效的四种形态与可观测信号
这张表的价值在于：四种形态对应四套完全不同的机制，而它们经常被同一个「记忆模块」笼统承诺。选型时如果对方只能说清「我们支持增删改查」，这四种形态里至少有两种是没有被处理的。
1.1.4 为什么现在才成为问题
三个条件同时成熟，把记忆从「增强」推到「必需」。
其一是任务时间跨度变长。Coding Agent 率先证明了这一点：一次重构可能跨越数小时、数十次模型调用、上百个文件，任务必须在实例被替换后继续。此时「记住」不再是体验优化，而是正确性前提。
其二是多 Agent 协作常态化。当工作助手、个人助理、健康顾问共享同一用户时，谁有权写、谁有权删、冲突如何仲裁，变成必须在架构层回答的问题。
其三是合规要求具体化。删除权、数据驻留、可审计性从「最佳实践」变成合同条款，而这三项恰好都要求记忆系统能拿出证据，而不是拿出日志。
1.2 记忆的三重身份
1.2.1 作为上下文的输入
这是最被熟悉的一重身份：记忆被召回、被排序、被裁剪，最终成为 prompt 的一部分。此处的核心指标是单位 token 的信息密度与相关性下限。
工程上有两个反直觉的结论。
第一，召回得多不等于效果好。当返回条数从 5 增加到 20，命中率可能上升，但回答质量经常下降——模型对长上下文中段的注意力天然衰减，无关条目会稀释真正相关的那一条。这就是为什么成熟的记忆系统会设置相关性下限，宁可不返回也不返回噪声。
第二，截断比不返回更糟。一句话被截掉后半段，可能语义反转；模型不会告诉你它读到的是半句。因此预算控制必须按完整单元丢弃，而不是按字符数截断。Mnemosyne 的 profile_card 把这一点做成硬约束：max_tokens 超限时按层丢弃（situation → open → preferences），从不句中截断。这个设计看似细节，实际决定了注入内容是否可信。
1.2.2 作为运行时的状态
记忆的第二重身份容易被忽略：它是任务可恢复的事实依据。任务进行到哪一步、哪些外部调用已生效、下一步该谁执行——这些不是「对话内容」，而是状态事实。
把它当作可检索文本来存，会立刻遇到三个问题：顺序丢失（不知道哪条在前）、原子性丢失（一次状态变更被拆成两条记录）、幂等丢失（重试时重复执行外部动作）。这也是为什么运行时状态与长期记忆必须分开承载：前者要求强顺序与事务，后者要求可检索与可遗忘。
1.2.3 作为治理的证据
第三重身份是审计对象。当 Agent 做出一个影响用户的决定，企业需要回答：它基于哪条记忆、这条记忆从哪来、谁改过、现在是否仍有效。
这里有一个必须说清的边界：哈希链能证明「未被篡改」，不能证明「已不存在」。前者是完整性问题，后者是删除问题，两者需要不同机制。把二者混为一谈的系统，在合规审查时通常只能提供前者，然后用「我们删了」的口头承诺填补后者。
1.2.4 三重身份为何不能合并
合并的诱惑在于实现简单：一张表、一个检索接口、一套权限。代价是三套正确性要求互相妥协。
上下文要求「按相关性裁剪」，运行状态要求「按顺序完整」，治理要求「按证据不可变」。当三者共用一份存储时，裁剪会破坏完整性，不可变会阻碍失效，顺序会被检索排序打乱。Mnemosyne 的选择是在存储层分文件、在接口层分工具：recall 面向注入，task_record 面向状态，audit / memory_trace 面向证据。代价是调用方必须理解三种语义，学习曲线比「一个 search 接口」陡。
1.3 2026 年的三对根本矛盾
1.3.1 写入与遗忘
第一性问题：新事实到来时，旧事实怎么办。三个约束互相拉扯——事实不能丢、成本不能失控、用户必须能推翻。
2026 年出现了一次值得记录的收敛。Mem0 在这一年把写入管线改为单遍 ADD-only 提取：一次模型调用，只增不覆盖不删除，官方称提取速度约为原来的两倍，历史完整保留。而 Mnemosyne 从第一版起就是单遍 ADD-only。
这个收敛的意义需要正面说出来：「只增不改」已经不再是差异化卖点，而是行业共识。它被采纳的原因也很清楚——没有任何重写操作时，一次糟糕的提取最多引入噪声，永远不会摧毁一条真实事实。对记忆系统而言，这个下限比上限重要。
但它同时说明另一件事：既然方向已被主流采纳，单靠「我们也是 ADD-only」无法构成选型理由。真正的差异转移到后续问题上——存储如何不单调膨胀、新旧冲突如何裁决、删除如何做到可验证。
ADD-only 的代价是明确的：存储单调增长，必须配合分层（热/温/冷）与无损压缩来管成本。Mnemosyne 的做法是把记忆压成「指针 + 结构化事实 + 内容原子」，数字、日期、金额、型号在任何层级完整保留，expand() 可字节级恢复原文并校验哈希。代价是压缩与展开各多一次计算，且压缩率受内容结构影响——结构化程度低的对话，压缩收益有限。
1.3.2 召回与精度
第二个问题：返回多少、返回哪条。这一对矛盾在 2026 年最容易被基准分数掩盖。
基准层面的困难是真实的：没有两个厂商的分数可以直接比较。数据集版本、judge 实现、prompt 模板、检索轮数，任何一项不同都足以造成十几分差距。LongMemEval 报告的「持续交互约 30% 准确率下降」则指向更根本的问题——短对话上的高分，在长周期使用中可能系统性崩塌。
工程层面的判断反而清晰：精度优先于召回。召回一条错误或过时的记忆，对用户体验的伤害大于没有记忆；而「没有记忆」至少是诚实的。这个判断是产品决策，不是工程决策，因为它决定了系统在不确定时的默认行为——宁可说「我不知道」，也不要自信地引用一条三个月前的偏好。
1.3.3 自主与可控
第三个问题：谁来决定记什么、忘什么。
一条路线把决策权交给 Agent 自身：记忆块由模型通过工具调用自主编辑，系统只提供分页与检索。好处是灵活，Agent 可以根据任务需要组织自己的记忆；代价是决策黑盒——当 Agent 做出糟糕的摘要或归档，排查「上下文去哪了」需要逐层追溯。
另一条路线把决策权留在调用方：每一次写入由显式工具调用触发，每一次操作写入审计账本，每一个结论可沿指针链回溯。好处是可解释、可审计；代价是调用方要承担设计记忆策略的责任，Agent 无法自适应地整理自己的记忆。
这不是对错问题，而是场景匹配问题。个人助理与研究型 Agent 里，灵活性优先于可审计性；企业流程与合规敏感场景里，一条无法解释的记忆就是一次审计风险。
1.3.4 三对矛盾的共同结构
三对矛盾有一个共同结构：每一对都是在「安全下限」与「体验上限」之间取舍。ADD-only 保下限，衰减策略争上限；精度优先保下限，召回优先争上限；显式写入保下限，自主编辑争上限。
这意味着不存在「全面更优」的系统。选型的正确问法不是「哪个更强」，而是「在我的场景里，哪一侧的下限是我不能破的」。第 21 章会把这个问题展开成决策树。
1.4 记忆系统的能力边界
1.4.1 它能做什么
把边界说清楚，比罗列功能有用。一个成熟的记忆系统在 2026 年可以可靠做到：
- 在无外部依赖的条件下完成写入与召回（内置提取器与确定性嵌入器可离线工作）
- 按作用域物理隔离数据，使跨租户泄露不依赖「过滤条件写对」
- 用多路信号融合召回，并在嵌入服务不可用时退化为词法检索
- 用哈希链证明审计记录未被篡改，并定位到具体哪一条
- 用级联删除处理源记录、派生结论、缓存与依赖摘要四个层次
- 用无损压缩降低存储成本，同时保留数字、日期、金额等关键原子
- 用渐进式披露把注入成本从 O(全部) 降到 O(目录 + 少量展开)
这些能力有共同特征：都能被验证。验证方式不是读文档，而是跑脚本、看返回值、做对照实验。
1.4.2 它不能做什么
同样重要的是另一边。截至 2026 年 10 月，没有任何系统在生产中解决了以下问题：
- 事实的交叉验证。用户说「我对花生过敏」但医疗记录显示没有时，系统无法自动裁决该信哪个。所有系统都默认「用户说的事实就是记忆」。
- 跨 Agent 共享记忆的冲突仲裁。物理隔离支持「不共享」；共享则需要上层自建权限模型，而权限模型的复杂度会随 Agent 数量爆炸。
- 删除的可验证性。能证明「未被篡改」，不能证明「已不存在」，且没有标准化的审计格式。
- 用户主动管理记忆时的行为质量。现有基准测的都是被动检索，没有任何基准测「用户编辑、删除、重新表述记忆」时系统的响应质量。
- 跨系统的成本-质量曲线。没有公开数据，选型只能依赖经验。
把这两份清单并列，会得到一个不太舒服但必要的结论：记忆系统当前的能力集中在前半段（写入、存储、检索、审计），后半段（裁决、共享、证明、成本）基本空白。任何宣称「端到端解决记忆问题」的说法，都在这后半段上做了超出事实的承诺。
1.5 本章小结
本章确立了四条判断。
第一，记忆已是一等原语，不是增强功能。 它同时是上下文的输入、运行时的状态、治理的证据，三重身份各有独立的正确性要求。把它们合并成「一段存起来的文本」，是当前多数记忆事故的共同根因——记错地方、记了不该记的、该忘的没忘、忘了但证不出，四种形态对应四套不同机制。
第二，上下文窗口变大没有削弱记忆系统的必要性。 它解决「能装多少」，记忆系统解决「该取哪条」。全上下文注入在成本上差一个数量级，在信噪比上会因历史互相矛盾而降低准确率；LongMemEval 报告的约 30% 下降正是这个机制的表现。
第三，2026 年的三对矛盾已经出现部分收敛，但收敛不等于问题解决。 ADD-only 成为行业共识，说明「不摧毁事实」这个下限被普遍认可；代价是存储单调增长与冲突裁决后移。精度优先于召回成为工程共识，代价是系统必须敢于说「不知道」。自主与可控的取舍则仍按场景分化，没有统一答案。
第四，记忆系统的能力边界必须被明说。 写入、存储、检索、审计已经可验证；事实裁决、跨 Agent 共享、删除证明、成本曲线仍然空白。选型时若对方在这四项上给出肯定承诺，应当要求其提供可复算的证据，而不是接受表述。
这四条判断留下一个具体问题：既然三重身份不能合并，那么一个记忆系统应该被拆成哪些责任域，各自承担什么保证？这是第 2 章要回答的架构问题。