主流 Agent CLI 存在会话可寻址性丢失、幽灵项目列表、不支持按会话隔离上下文等存储与寻址层 bug。
会话发现:对话变得无法触及,以及幽灵项目和重复项目条目
主要 Agent CLI 的公开 issue 追踪器是了解"我的 agent 忘了什么"实际样貌的最佳场所。其中最详细的一份报告标题如下(逐字抄录):

会话发现问题:对话变得无法触及,以及幽灵项目和重复项目条目
报告者大约有十个活跃对话。问题不是模型变弱了,而是对话不再可寻址:其中一些完全无法打开,项目列表出现了幽灵条目和同一项目的重复项,所以没有明显的地方可以返回。
两个并列报告从不同角度描述了同一类失败:
一项功能请求要求 CLI 在恢复大型或过时会话时建议开始新对话,因为恢复它会拖入不再描述工作的上下文。
第二份缺陷报告要求对话作用域可见性,以便为一个通道服务的 agent 可以回忆起该通道中的兄弟线程,而不会触及它服务的其他通道。
这些都不是狭义上的召回质量问题。它们是存储和寻址问题,而且它们位于其他一切的基础层。
重写 prompt 无法修复它。Prompt 是输入,不是存储。它没有索引、没有源指针,三个会话后也没有地址。如果需要的东西从未被写在某个可寻址的地方,再多的 system-prompt 工程也无法找回它。
更大的上下文窗口也无法修复它。这只是把墙往后挪了一点。Compaction 仍然按自己的时间表触发,无论当时没有持久存储的内容都会丢失。这不是假设:同一追踪器中的另一份报告描述了一个空闲会话在 prompt cache 过期前就被压缩了,且无法选择退出,并且被当作手动操作一样记录。
共同点是在 transcript 和模型之间缺少了一层:能够记录事实、给每个事实分配地址、并且能够从不同会话中再次找到它。
这些是我在 HyperMarrow(Windows 上面向 agent 的本地优先内存层)中最终强制执行的规则。它们按生效顺序排列,因为上述失败是在写入时决定的,而不是在查询时。
1. 在压缩之前写入。 一个偏好、决定或结论必须先落地到具有来源和时间戳的持久本地存储,然后才能总结或丢弃工作上下文。空闲压缩报告通过反例论证了这条规则。一旦持久副本优先存在,总结器就从单点故障降级为便利功能。
2. 在写入时确定它是哪种记忆。 明确的偏好必须逐字保留;结论是持久的但可重写的;日常闲聊则是噪音。事后分类为时已晚,因为原始措辞已经被丢弃了。实践中这意味着三个桶配三种保留策略,而不是一个未分类的向量池。
3. 召回返回的是你的原话,而不是你原话摘要。 如果存储下来的已经是有损的,再好的排序器也无法恢复你实际需要的那句话。这就是为什么规则 2 比召回调优更重要:召回质量被写入质量所限制。
4. 遗忘是按计划执行的,且有界限,被钉住的记录永不衰减。 无界限的记忆不是功能。停止相关的会话应该按计划自然淘汰,而不是永远被携带向前,而明确钉住的记录则不受此限制。上面那份过时会话请求正是用户在要求这个,只是向上了一层。
两条约束贯穿整个规则集:记忆默认是本地的,隐私边界是一个设置而不是一份承诺。记录存在哪里,以及某条记录是否可以离开机器,这是一个配置决策,而不是政策条款。
对话变得无法触及。 每个会话获得一条稳定的本地记录,带有不依赖滚动条或 CLI 自身会话列表的地址。召回直接查询存储。
幽灵和重复项目条目。 项目条目从存储记录派生而不是分开累积,所以列表不会偏离实际存在的内容。
恢复大型或过时会话。 检索是带作用域和排序的,所以恢复并不意味着重新注入一切。旧记录按计划衰减;钉住的则不会。
对话作用域可见性。 作用域是记录的属性,所以召回可以限定在一个通道的线程内,而不会暴露其余部分。
模块包括 record、recall、consolidation 和 file-bridge,通过 MCP 暴露,这样 agent 不需要为每个工具做定制集成。
上述报告是合理的批评,所以明确说出局限是值得的:
混合排序确实很难。 短查询对长记录的失败率仍然高于我所愿,而且引用句并不总是能排在一段复述之前。
会话寻址完全取决于宿主给我们的会话标识符。 如果 CLI 重命名或回收了它们,内存层就必须调和,而调和可能出错。
任何依赖模型来分类记忆类型的方案都会有一部分时间分类错误。 它比丢失数据失败得更安静,但仍然会失败。
如果你在多个会话中运行 agent:你一直需要重新建立的是什么?如果你提交过其中一份报告,我更愿意听听这个模型在哪些地方仍然不符合你所看到的。
HyperMarrow 是一个 Windows 桌面内存层。本地优先构建在这里:HyperMarrow
披露:我构建了 HyperMarrow,所以请带着这个前提阅读上文。这里引用的 issue 报告都是真实的、公开的,文章中没有编造任何数字、用户数或用户证言。