Plastic Memories：可塑性记忆，让模型自主管理上下文 —— 一个实验性插件

[CCCAUCHY]

大家好，分享一个在 DeepSeek Harness 上做的实验性插件：Plastic Memories（可塑性记忆）。

仓库：https://github.com/CCCAUCHY/Plastic-Memories

出发点

DSH 的 session 是 append-only 的 trajectory。我们想验证一个更激进的想法：

Trajectory 是不可变的历史事实；Surface 是历史的可塑投影；Context 是 Surface 在模型输入中的具体存在形态。

长期运行的 Agent 会不可避免地积累大量运行噪音：冗长工具输出、失败尝试、临时观察、重复推理及过时的环境状态。这些材料在产生时有其价值，但随着任务推进，持续留在工作区中只会挤占注意力并劣化推理质量。

业界通常将此简化为上下文压缩问题。

插件做了什么

• plasticize / retrospect 工具与 /plasticize /retrospect 命令：surfaceOp 是 DSH 会话日志的一个事件，原生自动压缩也使用它，用于修改会话日志的实际投影，插件向日志追加 surfaceOp，把会话历史塑形成新一代，相关功能只能在 PM 会话模式里使用，该会话模式移除了自动压缩；
• 世代选项卡：把官方轨迹页私有化复制了一份（模块 id / target / locale / view id 全部改名，可与官方页面共存），选中任一世代时，由官方装配器按该世代的真实日志重建轨迹；
• 相邻世代差异：第 k 代里的替代消息标「已塑形」（一键跳到 k-1）；第 k-1 代里即将被覆盖的消息标「被塑形」（一键跳到 k）——两侧颜色互反，来回翻页即可对照是哪一段被塑形了；
• 事实源一致性：世代投影的 fold 与官方 foldSurface 用影子会话逐代差分校验；运行期若发现与 session.surface 不一致会告警；展示层从不写回日志或请求。

现状

实验性、单体 profile 可用，17 套 / 572 条测试（含官方 fold 差分校验）。欢迎拍砖，尤其是「世代投影」这个抽象是否值得进入 DSH 的正式模型，以及官方轨迹页是否应该开放更稳的扩展点（我们目前只能私有化复制 + patch）。

目标

取代所有上下文压缩机制，并不再区分外部记忆、外部知识库、外部数据库，使LLM能够完成超长程不可压缩、不可并行任务。
实际上，目前我看到的各种上下文管理、记忆管理、回顾提醒机制，都是 Plastic Memories 所有操作的一个真子集，我会吸收它们的设计思想，在不同类型的任务中指导模型使用 Plastic Memories 插件。
有人可能会思考 Plastic Memories 与子代理集群的关系，答案是，子代理集群可以在某种程度上模拟 Plastic Memories 的效果，但主代理的轨迹依旧是仅追加的，而 Plastic Memories 允许主代理的轨迹是非仅追加的。

[juanbaiing]

看了你那篇 engineering 说明，有个地方想确认一下，也是我自己卡了很久的。

你的 HIDE / STABILIZE / REHYDRATE 都是模型显式调 plasticize / retrospect 的吧？ 标题里写「让模型自主管理上下文」，我理解这是有意的——判定权留在模型手里，插件只提供原语。

我想问的是这一层：有没有考虑过把判定也自动化，而不是留给模型？

具体是三档：

档	处理
当前话题	原文，整段留在活动面上
相关话题（作为理解当前话题的必要语境）	沉成摘要
无关话题	隐藏

这三档如果能按话题自动判出来，人就不用自己去想「我现在该 plasticize 哪一段」——尤其长会话里，模型往往不觉得自己该塑形。

---

说明一下我为什么问这个。我在做的是 dsh-alert-inject，回答前提醒那一层，不碰上下文。

它有一件事跟这个有关：按语义把会话切成话题块，能判「这一段和现在的话题还相关吗」，还有「你现在回到了之前那个话题」的回切检测。

但它只能给摘录——把旧块的一小段摆在提醒里，因为插件碰不到上下文，改不了 surface。

所以我能供的正好是你缺的那半，你有的正好是我做不到的那半。判定信号外置给执行方这条路你走过吗？还是有理由认为判定必须和塑形在同一处——比如判定错了没法回滚，而 surfaceOp 是可逆的，把错的判定也变成可逆的？

---

另外问一个观察。你的说明里提到自动压缩也是 surfaceOp: replace，跟 plasticize 同一套语义。

我这边看到一次压缩直接失败退出了：summarization produced no text summary content，从 start 到 end 一共 14 秒，没有任何摘要产出，日志里只有一条 error。

你那边把自动压缩当世代处理的时候，有没有碰到它跟 plasticize 叠在一起的情况——比如压缩刚把一个世代替换掉，REHYDRATE 又要从那个世代里捞东西？

[CCCAUCHY]

呃，没看懂你想表达什么，但是plasticize / retrospect都是工具，当然是模型自己调用的，上下文治理过程也是全自动的，目前有安全区机制，可以在第一轮的提示词里根据任务性质告诉模型治理上下文的倾向和策略，然后用/plasticize lock锁定，这样这条提示就一直在模型的上下文里了。目前文档还没更新，还在开发阶段，以代码为准。
/plasticize 命令确实给人用的，可以不用，但不能没有。
你的自动压缩报错应该跟PM插件无关，因为PM会话模式直接移除了压缩，与自动压缩不兼容，并且将取代自动压缩

[CCCAUCHY]

不是「长会话里，模型往往不觉得自己该塑形」，而是「尽量保持上下文整洁」，等到模型不觉得该塑形的时候已经晚了

[juanbaiing]

抱歉，我没讲清楚。

我说的不是让插件替模型做判断，我的插件的作用只有“提醒”，该压缩了，或，这里你压缩过，原文在这。我想说的是：

用一段明确的概括来代替原来那一大段对话，并且留下能找回去的索引。

比如原本 12 到 30 号之间是一整段讨论，压完之后模型看到的是——

[已压缩 · 坐标 12–30] 这段在验证缓存命中率对塑形位置的影响，
结论：改动点越靠前，重算成本越高。原文可按坐标取回。
坐标：xxxxxx

跟现在的 plasticize 的区别是两点：一是它明确写着「已经压缩过」，模型不会当原文看；二是留了坐标，需要的时候能顺着坐标回到那一段，不用去 retrospect 里猜关键词。这样能保留之前对话的一些痕迹，不至于直接失忆。

我看你现在的实现里，new_text 有内容的时候走的是 user/message，所以模型看到的是「用户说了这段话」。如果换成上面这种带标记的形式，可能更不容易被误读成用户的原话。当然这可能是我没看全，如果已经支持了是我漏了。

---

另外有一件事想请教，不确定是不是你已经权衡过的。

plasticize 也是 surfaceOp: replace，会改变发给云端的内容。而 DeepSeek 的上下文缓存是按前缀匹配的，改了一个点，那个点之后的前缀就对不上了，后面全部按未命中计费。

我自己量了一下。我用的是 DSH 自带的压缩，不是 PM，不过机制应该是一样的，可以先当参考：

	压缩前	压缩后
缓存命中	791,296	13,056
未命中	338	4,040
上下文总量	791,634	17,096

那次是把 79 万压到 1.7 万，一次压得很彻底，所以虽然缓存断了，但因为总量也小了，下一轮就回本了。

按 flash 的价格（cache hit $0.003 / miss $0.15，差 50 倍）推一下，回本的轮数大概是：

回本轮数 ≈ 50 × 压缩后的上下文长度 / 省下的长度

代进去看：

场景	压缩后	省下	回本
819k 一次压到 17k	17,096	774,538	约 1 轮
把一段换成一段，总长基本不变	约 790,000	约 4,000	约 9,700 轮

也就是说：压完上下文显著变短，就划算；把一段换成一段、总长不变，那一次替换要为整个上下文重新付一遍 miss 的钱。

我还看了自己会话里 55 次小的塑形记录，每次中位只压掉 4,056 token，位置中位在 40% 左右——按上面这个算法，全部是不划算的。不过那些是 DSH 自己的机制，不是 PM。

---

所以想问问：

1. 你设计 plasticize 的时候，是把它想成「替换」还是「缩短」？如果是替换、总长不减，那缓存这块是有意接受的代价，还是有别的考虑？
2. 有没有想过给塑形加个水位门槛——比如上下文超过多少才允许整，攒够了再一次做，而不是随时可以做？缓存命中率的代价与整洁度是要衡量的。

如果我的数算错了，或者哪里理解偏了，直接说就行，这方面我确实拿不准。

[CCCAUCHY]

首先，现在除了部分cookie是用户消息，能是developer消息的都已经是了；其次，缓存分两方面看，如果你一直拖着历史记录，虽然缓存命中了，但是数量多，价格也会涨上来，如果plasticize使用得当，经常清洁上下文，那么上下文只会随着任务进度一直缓慢曲折上涨，甚至如果出现路线更换还会大幅下降，重点是，要保证上下文的信息密度，尽量只放不可压缩的信息，而且始终如一，如果动到早期的消息，确实会造成缓存命中大幅下降，但是我每次请求的平均上下文长度可能只有原先的一半，不好说谁更省钱，而且还能换来潜在的智力优势；上下文水位还没加，要加的话暂定跟cookie消息一起发送