四个 Agent 内存 bug：空闲压缩会静默丢弃工作上下文

打开一个长时间运行的 agent 会话，走开，回来。在至少一个广泛使用的 coding agent 中，紧缩（compaction）可能在会话空闲时触发，丢弃你仍然需要的上下文，且无法选择退出。这个 issue 标题比我说的更到位：空闲紧缩在长时间运行的会话中静默丢弃工作上下文。

这份报告并非孤例。翻阅主流 agent CLI 的公开 issue 追踪器，同样的几类故障反复出现。它们并非 exotic 边缘案例，而是当"记忆"本质上只是一个加装了摘要器的上下文窗口时必然会遇到的问题。

我从事 HyperMarrow 的工作，一个面向 agent 的本地优先记忆层。我把这些报告当作 backlog 来处理，而不是当作宣传素材。下面列出其中四个，来自各追踪器的原文摘录，以及每个 issue 所隐含的写入时规则。

Bug 1. "空闲紧缩在长时间运行的会话中静默丢弃工作上下文；无法选择退出"

来源：anthropics/claude-code issue 98747

问题现象：紧缩是一个后台任务。它在会话空闲时运行，而不是在安全时运行。在那个时刻，摘要器判定为低价值的内容一律消失，而用户从未有过投票权。另一个仓库中的一份镜像报告描述了子 agent 完成轮次跳过 preflight 紧缩，导致超过阈值的会话始终得不到紧缩。

规则：写入决策必须在紧缩之前发生，而不是之后。

在我们的设计中，紧缩不被允许作为第一个接触最近状态的操作。记录、决策和结论首先被写入本地存储，每条都带有来源标签和时间戳。只有在此之后，才能对工作上下文进行摘要或丢弃。如果摘要器扔掉了什么，耐久的副本已经在磁盘上了。这把紧缩从数据丢失问题变成了视图问题。

Bug 2. "memory_search 混合排名丢失了唯一包含完整查询的 chunk"

来源：openclaw/openclaw issue 162764

问题现象：检索质量被视为一个排名问题。实际上它通常是一个写入问题。如果你存储的已经是一份有损摘要，没有任何排名器能够恢复你所需的那句话。

规则：在写入时决定什么是事实、什么是决策、什么是噪声。

我们的层将三者分开存储。事实和决策原样存储、不可变。噪声作为指针存储，或者根本不存储。这样检索时就有精确的内容可以命中。当召回失败时，第一个问题不是"用哪个 embedding 模型"，而是"我们没有写下来的是什么"。

Bug 3. "子 agent 在停止后仍然残留在记忆中，需要手动移除"

来源：anthropics/claude-code issue 98804

问题现象：一切都被永远记住，所以过期的 agent、已死的会话和一次性实验不断积累，开始污染后续的决策。

规则：遗忘必须有界限、有调度，而不是手动触发的。

我们的层运行一个衰减过程。低价值记录沿曲线衰减，固定记录永不衰减，没有任何东西在仍被引用时被硬删除。用户不应该充当垃圾回收器。需要手动清理的记忆系统不是记忆系统，它是一个泄漏。

Bug 4. "跨会话引用的段落锚点"

来源：anthropics/claude-code issue 98768（一个功能请求）

问题现象：用户想指向早期会话中的一个段落。目前他们要么指向整个会话，要么什么都指向不了。

规则：连续性必须是可寻址的。

这个 issue 是作为功能请求提交的，而这正是有趣之处。从"我记得你上次的聊天"到"我能引用三次会话前的那段原文"，这之间的差距才是连续性真正存在的地方。

规则汇总

在写入之前先紧缩。耐久副本在摘要器运行之前就已存在。

在写入时分离事实、决策和噪声，而不是在查询时。

遗忘是有调度、有界限的；固定记录永不衰减。

连续性在会话之间是可寻址的，粒度可到段落。

所有内容默认保留在本地，隐私边界是一等公民设置，而不是事后补救。

这些都不 exotic。它们是大多数 agent 技术栈跳过的存储无聊部分，因为在演示中上下文窗口够用，账单来得更晚。

有意义的问题不是你的 agent 是否有记忆。而是那些记忆存在哪里，以及会话结束时它们会遭遇什么。如果答案是"在上下文窗口里"，这四个 bug 已经在你的 roadmap 上了，无论你是否曾经记录过它们。

我正在构建 HyperMarrow，也就是上文描述的本地优先记忆层。文档和客户端在这里：HyperMarrow。

如果你维护一个 agent 运行时：这四个你遇到了哪些，哪些你认为不可修复？

（披露：我是 HyperMarrow 的构建者，也就是上文描述的本地优先记忆层。）