主题
第 23 章 未解问题与 2027 路线图
前面二十二章的方法都建立在一个前提上：记忆系统能判断"什么是该记住的"。这个前提在多数时候成立，但在五处不成立，而这五处恰好是记忆从"功能"走向"基础设施"必须跨过的关口。
本章不试图给出解法。它的价值在于把边界画清楚：哪些问题已经被解决到可以生产使用，哪些仍处在"有方案但没有验证"的阶段，哪些连问题本身都还没被定义。这个区分对投入决策很关键——为一个已解决的问题投入是重复劳动，为一个未被定义的问题投入是赌博。
23.1 五个未解问题
23.1.1 记忆的正确性由谁定义
所有系统都默认"用户说的事实就是记忆"。这个默认在多数场景下合理，但在三种情况下失效：用户记错了、用户说反了、用户故意误导。
具体场景：用户说"我对花生过敏"，但此前的医疗记录显示没有过敏史。系统应该记住哪一个？如果相信用户，可能造成不必要的饮食限制；如果相信记录，可能在用户真的过敏时造成危险。
技术上可以做的裁决手段有限。交叉验证需要外部事实源，而多数系统没有接入；时间优先假设"新的更准"，但新信息也可能来自更不可靠的来源；来源优先假设"正式的更准"，但正式来源也可能过期。
真正的问题在于：这个裁决规则是业务规则，不是技术规则。它应该由使用方定义，而当前所有系统都把它硬编码成"相信用户"。这意味着系统在替使用方做医疗、金融、法律层面的判断，而这个判断的依据从未被明示。
截至 2026 年 10 月，没有一个系统在生产中实现了可配置的事实裁决规则。这是第一个未解问题，也是最基础的一个。
23.1.2 多 Agent 共享记忆的冲突仲裁
当一个用户的三个 Agent（工作助手、个人助理、健康顾问）共享同一份记忆时，谁有权写入、谁有权删除、冲突如何仲裁？
物理隔离支持"不共享"——每个 Agent 一个作用域，各自独立。这是当前唯一可靠的方案。代价是用户需要在三个 Agent 之间重复表述同样的偏好。
共享则需要权限模型，而权限模型的复杂度会随 Agent 数量与共享范围爆炸。三个 Agent 两两共享有 3 种关系，五个 Agent 有 10 种，且每种关系需要定义读权限、写权限、删除权限、可见性范围。
当前的产品级方案大致有两类。一类是"共享读、隔离写"：多个 Agent 可以读同一份受治理的记忆，写入仍各自隔离。这避免了写冲突仲裁，代价是共享层需要定期合并，存在延迟。另一类是"组织级共享仓库"：把共享记忆做成一个独立的、由组织拥有的仓库，各 Agent 按权限访问。这类方案通常要求云托管环境，本地部署的 Agent 无法参与。
两类方案都没有解决核心问题：当两个 Agent 对同一事实给出不同结论时，谁对？这个问题在单 Agent 场景下不存在，在多 Agent 场景下必然出现，而当前没有仲裁机制。
23.1.3 遗忘的可验证性
第 13 章已经展开：哈希链能证明"未被篡改"，不能证明"已不存在"。
这个问题的难点不在技术，在逻辑。要证明一个否定命题（"某信息已不存在于系统中任何位置"），需要穷举所有可能位置并逐一验证。而位置清单本身会随系统演进变化——今天加了缓存层，昨天做的证明就失效了。
更麻烦的是证明本身会留下痕迹。为了证明"已删除"而保留一份删除记录，这份记录包含"曾经存在过某条信息"这一事实，可能构成新的个人信息。这是一个自指困境。
可能的方向是把否定命题转化为可核查的清单比对：不证明"不存在"，而是记录"在哪些位置、由谁、在什么时间、执行了何种处理"，并允许第三方复核这些处理是否覆盖了其已知的所有位置。这个思路降低了难度，但截至 2026 年 10 月还没有形成标准格式。
23.1.4 基准与真实使用之间的鸿沟
现有基准测的都是被动检索：给定一个查询，看系统能否返回正确的记忆。
但真实使用中，用户会主动管理记忆——编辑、删除、重新表述、追问"你为什么记得这个"。这些交互模式与被动检索的评估范式完全不同。
具体场景：用户发现系统记错了自己的职业，说"不对，我是设计师不是工程师"。系统正确响应需要三步：识别这是一次纠正、定位到错误记忆、更新并确认。现有基准不测这三步中的任何一步。
后果是：一个在 LongMemEval 上拿到高分的系统，可能在用户纠正时反复犯错——它记住了新信息，但旧信息仍在，下次检索可能返回旧的。这个失效在基准上完全不可见。
第二个鸿沟是长周期使用。LongMemEval 论文报告的约 30% 准确率下降已经提示了这个问题，但下降的机制没有被充分研究。是记忆条目增多导致检索精度下降？是旧事实干扰？还是用户偏好本身在变化？不同机制需要不同解法，而当前无法区分。
23.1.5 成本与质量的帕累托前沿
单次记忆写入的模型调用成本、嵌入生成成本、检索时的融合计算成本，与召回质量之间的关系，没有公开的跨系统数据。
这意味着选型时无法回答一个基本问题：多花一倍成本，能换来多少质量提升？
具体场景：一个团队在"配置更强的嵌入模型"与"增加重排器"之间选择。前者每次写入成本上升，后者每次检索成本上升。哪个更划算？答案取决于写入与检索的比例、语料特征、以及对召回精度的实际需求。而这些参数在真实场景中差异极大，任何单一建议都不适用。
可行的方法是自己做小规模对照实验：固定一批查询与 ground truth，分别测三种配置的召回率与成本。这个方法可靠但费时，而多数团队在选型阶段不愿意投入。
没有公开的成本-质量曲线，选型只能依赖经验与厂商推荐，而厂商推荐天然有偏向。
23.2 2027 路线图
| 方向 | 2026 状态 | 2027 预期 | 关键不确定性 |
|---|---|---|---|
| 可配置的事实裁决 | 全部硬编码"相信用户" | 出现可配置的裁决策略（来源优先/时间优先/人工确认） | 使用方是否愿意承担配置责任 |
| 跨 Agent 记忆治理 | 物理隔离为主，共享读为辅 | 共享读成熟，共享写出现参考实现 | 权限模型复杂度是否可控 |
| 遗忘的可验证性 | 各家自定义处理记录 | 出现可交换的删除审计格式 | 标准化组织是否介入 |
| 主动管理行为的评测 | 无基准覆盖 | 出现针对纠正、删除、追问的评测集 | 标注成本高，难以规模化 |
| 成本-质量曲线 | 无公开数据 | 头部厂商公布对照数据 | 公布数据即暴露成本结构 |
| 中文与非英语场景 | 少数实现做针对性优化 | 出现独立的非英语基准 | 数据集构建与标注成本 |
表 23-1 2027 年可预期的演进方向
这张表的第四列比第三列更重要。每一个方向的进展都受制于一个非技术因素：使用方是否愿意承担配置责任、权限模型复杂度是否可控、标准化组织是否介入、标注成本是否可承受、厂商是否愿意暴露成本结构。技术能力不是瓶颈，激励结构才是。
23.3 给五类角色的行动建议
23.3.1 开发者
不要在建"又一个记忆存储"。存储层已经过剩，单遍 ADD-only 加多信号检索是公开可复制的方案。
机会在三处。第一处是观测层：trace、审计、质量监控、成本归因。这些工具目前普遍薄弱，而它们决定了系统出问题时能否被快速定位。第二处是场景适配层：中文分词、专有名词检索、行业术语，这些是通用方案覆盖不到的。第三处是前置条件建模：如何把"经验"与"建议"区分开，如何让经验的适用条件可被机器校验。
三处的共同点是：它们都不需要新算法，需要对具体场景的深入理解。
23.3.2 架构师
在 2027 年的选型中，把"是否支持逐条来源追溯"作为硬性门槛。
理由不是追溯本身有价值，而是没有追溯能力的系统在事故复盘时无法定位。一次记忆导致的事故，如果无法回答"这条记忆从哪来"，复盘就只能停在"系统表现异常"，无法进入"为什么异常"。
第二项门槛是"删除是否分级"。只会做单条删除的系统，在合规场景下不达标；只做物理删除的系统，在产品场景下过度销毁。
第三项是"隔离是否可举证"。不是问"是否隔离"，而是问"能否用三项测试证明隔离"。
23.3.3 产品负责人
用户对记忆的信任，取决于用户能否理解系统记住了什么以及为什么。
三个具体做法。第一，分层展示：把记忆按稳定身份、偏好约束、当前情境分层，让用户看到结构而不是平铺列表。第二，纠正成本最小化：用户说"不对"之后，系统应当在一次交互内完成定位、更新、确认三步。第三，给"别记这个"一个中间选项：完全删除会破坏连续性，完全不删违背用户意愿，掩码是两者之间的实用折中。
三个做法都不需要新技术，需要的是把记忆当作产品界面来设计，而不是当作后台功能来实现。
23.3.4 合规与安全
2027 年最紧迫的工作不是增加检查项，而是把删除的预览输出纳入变更管理。
一条被删除的用户偏好可能已经影响了三次推荐结果。删除的爆炸半径必须在执行前可见，而这个可见性需要流程支撑——预览、审批、执行、归档四步，缺任何一步都会在审查时被追问。
第二项工作是区分"我们删了"与"我们能证明按流程删了"。前者是陈述，后者是证据。多数团队停在陈述，而审查方要的是证据。
第三项是不要为"已彻底清除"背书。当前技术给不出这个证明，承诺它会在第一次深度审查时崩塌。
23.3.5 研究者
工业界最缺的不是新算法，而是可复现的失败案例集。
一个公开的"记忆系统失败模式基准"，记录每个系统在特定场景下的具体崩塌方式，其价值会超过任何单个系统的 headline 分数。原因是：分数告诉你好不好，失败案例告诉你哪里会坏，而后者对工程决策更有用。
第二个方向是主动管理行为的评测。用户纠正、删除、追问时系统的响应质量，是当前完全空白的区域，也是真实使用中最频繁的交互。
第三个方向是成本-质量曲线的公开测量。这件事需要中立第三方，因为厂商没有动力公布对自己不利的数据。
23.4 结语
记忆系统的成熟标志不是记住更多。
一个记住一切的系统，在用户看来是可怕而非可靠——因为它无法被推翻。一个记得精准但无法解释的系统，在运维看来是黑盒而非工具——因为出问题时无从下手。一个能删干净但证不出来的系统，在合规看来是隐患而非资产——因为它的承诺无法被验证。
因此真正的成熟标志是三条：能被解释（每个结论可追溯到来源）、能被推翻（用户纠正后系统确实改变）、能被彻底遗忘（删除覆盖全部层次且有据可查）。
三条都不涉及"记得更多"。它们涉及的是控制权——用户对记忆的控制权，运维对系统的控制权，合规对证据的控制权。
2026 年的技术条件已经足以实现前两条。第三条受制于一个尚未解决的自指困境，短期内不会消失。承认这一点，比宣称解决它更接近工程诚实。
记忆最终会像数据库一样，成为一个不需要被反复讨论的基础设施。到那时，人们不再问"你的记忆系统用什么算法"，而是问"它能不能被审计、被推翻、被遗忘"——就像今天问数据库"能不能事务、能不能备份、能不能恢复"一样。
那一天到来之前，本书讨论的这些取舍仍然需要被逐项做出来。