dsh-degeneration-kit (auto-checkpoint)

DSH 防退化套件 —— ⚠️ 两个插件，两个都得装才完整

English | 中文

上下文越长，模型越容易陷进「我要做 X」的空转（复读），而且回合看起来还是成功的， 不加检测根本发现不了（本机实测：24 个真退化块里 18 个回合正常结束，只在思考里烂）。

这个仓库里有两个插件，各治一半：

• 少产生 —— thinking-guard：把退化的思考块从模型可见的历史里折叠掉，不让它每轮重放；
• 清库存 —— dsh-auto-checkpoint：到水位压缩（把已经累积的污染整体清掉），或换一个新会话。

缺一个都会漏（理由见下表后面的三条）。只装一个也比裸奔强，但要真想彻底解决，两个都要装。

复读长什么样：两种形态，判据完全不同

「复读」不是一种东西。我们把本机 493 个会话日志里全部 reasoning 块按同一个口径过了一遍 （ra = 同一段里同一句的最高重复次数），它们分成两类：

	A 型 · 同一句死磕	B 型 · 短句轮换
重复次数	10³–10⁴	20–200
上下文	短（29k–42k）	长，随长度单调上升
典型样子	（读×3369、做×1024、「好」×10848	Let me write it. → Go. → Now. → OK.
读起来像	正常思考：有主语、有下一步动作、句句合规，信息量为 0	正常推进 —— 最难认出来的就是它
多不多	罕见（中文单元全机 5 例）	常见
跟模式的关系	只在「强制中文思考」的模式里见过（其它 31 个会话：0 例）	无关

⚠️ 两条容易搞反的：

• 「中文更容易退化」是体感，不是数据。 成立的是「最严重的案例全是中文」（差 1–2 个数量级）； 按数量算，最常见的是英文碎片型。体感记住的是最扎眼的那一个，不是最多的那一个。
• 中文那 5 例全部出现在同一个模式里，所以「是中文的锅」还是「那套格式约束的锅」， 我们分不开 —— 别把相关当因果。

B 型为什么特别难抓：判据原本要求「单个单元占窗口句数 ≥20%」，而轮换让每个短词只占 ~15%， 没有一个够门槛 ⇒ 整块放行。实测：英文为主的 8 个块全被这道门拦掉。 这就是第二把尺子 rotationGuard 存在的原因（细节见 thinking-guard/README.md）。

为什么复读会自己喂自己：DSH 会把历史里的 reasoning 块原样回传上游。 所以一条复读不只是一步出错 —— 它留在上下文里，之后每一步都再发一遍， 模型读到的是「我刚才一直在重复这个」。thinking-guard 折叠的就是它。

为什么是两个、而且两个都需要

插件	干什么	时机
thinking-guard	把退化的思考块从模型可见的历史里折叠掉	当场（下一次 pre-step，趁它还没被反复回传）
dsh-auto-checkpoint	到水位压缩（清掉累积污染），或换一个新会话	事后

三条理由，缺一条都会留下漏洞：

1. 折叠管不到一次生成内部。 一条复读正在生成的时候它拦不住 —— 只能等下一步再剪。那一步的污染已经产生、已经回传过一次。
2. 只有压缩能清"库存"。 多次漏检攒下来的污染块，折叠一块块剪很慢；压缩能一次性把累积的压下去（本机实测：一个会话 12 次压缩，凡有累积污染时压缩后都下降，最强一次 43 → 0，此后零复发）。
3. 压缩之间还有步子。 只装压缩的话，两次压缩之间的每一步仍在被污染重放 —— 那正是折叠负责的那一段。

⇒ 一句话：折叠 = 少产生，压缩 = 清库存。两个都在，才是闭环。

💡 两个插件之间有一处联动（2026-10-15 补）：thinking-guard 里的急停阀当场掐断复读之后， dsh-auto-checkpoint 会顺带压一次 —— 不看水位阈值，也不看那会话在面板上选的处理方式。 阀清的是"正在喷的那一段"，压缩清的是"历史累积"，接得上。 ⚠️ 这一步要有阀才有（只装 dsh-auto-checkpoint 的话没有）；想关掉只能全局改常量 AUTO_COMPACT_ON_VALVE_ABORT（默认 true）再重启，详见 auto-checkpoint/README.md。

实测：一个会话跑满 23 亿 token 也没崩

这是一个真实会话的用量面板：383 轮、9,227 步、累计 23.2 亿 token（缓存命中 99.6%）， 上下文占用仍然只有 24%。

原因不神秘：dsh-auto-checkpoint 到水位就压缩或换会话，不让历史无限堆积； thinking-guard 把退化的思考块折叠掉，不让它每一轮重放。

⚠️ 这张图只说明会话没崩，不构成「它比别的方案更快更省」的证明。

装（3 分钟）

→ 看 INSTALL.md（两条命令 + 验证方法 + 常见问题）

它不解决什么（以及配套推荐）

这套件治的是「别崩」：模型陷进复读，或者上下文里堆了污染，它当场掐掉、把库存清掉。 它不治「别失忆」。三件事分开看：

你怕丢的	压缩会不会弄丢	归谁管
人格（说话风格、它是谁）	不会。人格在系统提示词里，而压缩的范围明确排除系统提示词（dsh-compaction-basic 文档原话：位于 surface 节点 0 的系统提示词永不会被遮蔽）	preset / 模式配置
任务状态（做到哪、下一步、改了哪些文件）	不会。压缩前会先落档，新会话读那份检查点接着干	本套件（dsh-auto-checkpoint）
会话里谈出来的结论（「我们说好用 A 不用 B」、踩过的坑、你的偏好）	⚠️ 会。压缩之后模型眼里只剩一份摘要，那些共识不在里面	⚠️ 本套件不管

第三行才是缺口。本套件保证「会话不崩、任务能接着干」，保证不了「它记得我们之前定过什么」。

要补这一块得另找一个跨会话的长期记忆插件。我们自己在用的是一个第三方开源项目，列在这儿只是供参考：

• @aiwayds/dsh-topics-memory：https://github.com/fan56/dsh-topics-memory（MIT）
• 不是我们写的，也不由我们维护。它的定位和本套件互补，装法看它自己的 README。
• 它对「记什么」做了很苛刻的取舍，原话是：一个 topic 只记四件事 —— 从什么问题开始、得出了什么结论、 影响什么、依赖什么；至于得出结论的过程（讨论、试错、绕过的弯路）一概不记。
• ⚠️ 它的「语义检索」需要一个本地 embedding 服务（只支持 ollama，默认 127.0.0.1:11434）—— 远程 embedding 被它明确挡在热路径外。没装 ollama 时它自动退回词法检索，这是明确降级、不是故障。

⚠️ 别把它当成「保人格」的方案 —— 人格靠的是模式配置（比如把人格写进 preset 的 persona 行）， 记忆插件负责的是「结论级」的跨会话记忆。两件事，别混。

另一个常被混淆的痛点：嫌 token 花钱（而不是嫌上下文长）

这是另一回事：上下文长是「贵在每轮都要重发」，而「要不要为 token 付钱」是单价问题。

我们自己在用的是 dsh-our-free-model（https://github.com/Ebony-Vinyl/dsh-our-free-model，MIT）—— 装上不用填 Key，就能用一批前沿模型。

🛑 四条免责，请逐条看完再决定：

• 不是我们写的、也不由我们维护。 列在这里只因为我们自己天天在用。它是个成熟的公开项目（约 1.9 万 star）， 有问题请去它自己的仓库提，别提到我们这儿。
• 它治「单价」，完全不治「上下文长度」：记忆插件的注入照占窗口、照拖慢每一轮。 要省上下文，得调记忆插件自己的注入档位（topK、注入预算、用 pointer 形态而不是 digest）。
• 你的请求发往它自己的上游（目前是 OpenCode 的 Zen 网关，https://opencode.ai/zen/v1/*，不经第三方中转）—— 不是本地推理。对代码或对话内容出机器敏感的话，先想清楚再装。
• 免费额度能持续多久，不由我们也不由你决定：上游改规则、限速、下架模型，随时可能发生。 别把依赖建在它上面。

两个插件各自

插件	规模	README
thinking-guard/	约 760 行（lib/ 三个文件，含急停阀），零宿主服务依赖	中文｜English
auto-checkpoint/	4,292 行，8 个宿主服务	中文｜English
auto-checkpoint/	4,621 行，8 个宿主服务	中文｜English

压缩出岔子时，它会自己救

自动压缩不是"压就完事"，失败方式有好几种，每一种的处理都不一样。

情况	以前	现在
上游瞬时断开（Connection error.）	1 秒失败，之后什么都不发生，会话卡在阈值上方不压	本轮内退避重试（多次，间隔递增），不等下一个回合
瞬时失败	记一次 strike，抖两下就把好会话降级成"只提醒"	不记 strike，也不进入冷却，能马上再试
网络抖动 vs 真的压缩失败	混为一谈	分开：瞬时错误重试，真失败才计入
派话给另一个会话	先猜对方忙不忙，再决定投递方式 —— 实测那个判断会错	不猜，一律按「下一步」投递：忙就插当前回合，闲就立刻开新一轮
落档时间戳看着够新	只看"比上次压缩晚"，本周期内早早写过又跑了半天的档会被误判成新鲜	锚定到本次压缩周期的起点：不够新就催办，催满仍没有才照压（绝不把压缩卡死）
落档"刚被碰过"其实没写新东西	只看修改时间，cat >> 追加一行就能骗过去	两层判据：时间层之外再加内容层 —— 「这一轮定下的结论」那节正文必须与上次判定时不同

这两条都是真事故：

• 落档写于 22:18，03:58 压缩时判定「新鲜」直接压了，中间 5 小时 40 分的对话没进任何落档。
• 补了时间层之后又栽在 cat >> 上：落档 mtime 是 01:04（那次只往末尾追加了一段）， 正文实际停在 18:19 —— 01:25 的压缩没被催办、直接放行， 而当轮几件产物的编号在那份落档里 grep 0 命中。 ⇒ 只盯「文件被碰过没有」永远不够，得盯内容里有没有这一轮的东西。

补投用户原话时可以用 raw: true 让内容原样透传、不加任何前缀 —— 否则对方会以为这是一条派活回报。

阈值推荐（dsh-auto-checkpoint）

你的窗口	任务边界	落档 / 换会话
256K（DSH 默认）	150k	180k
≥512K	250k	350k
≥1M	350k	350k–500k

350k 是我们自己长期在跑的值，不是比例 —— 512K 和 1M 用同一组数，窗口再大也别乘上去。

⚠️ 这里是一个取舍，按你更怕哪个来挑：

• 怕退化（复读） → 靠 350k 这边。上下文越长，单轮越贵越慢，模型陷进复读的风险也越高。
• 怕压缩太勤 → 可以放到 500k。每次压缩都是一次全上下文请求，还会打散 prompt 缓存， 对高频长任务可能反而更费。350k–500k 是经验值（我们自己的使用体感）， 不是实测出来的分界线 —— 我们没在 500k 上长期跑过，也没有「压缩频率 vs token 花费」的对照数据。

怎么调阈值（不用重启）

面板有两个入口，看到哪个用哪个，改的是同一份配置：

• 装了桌宠插件 dsh-cost-whale —— 面板就在桌宠的菜单里，点开就是滑块；
• 没装桌宠也没关系 —— 本插件自带一个右下角浮动面板，默认收成一个小按钮，点一下展开： 三个滑块、「干完这些就换新会话」勾选框、模式下拉都在里面。

浮动面板没自动冒出来的话，在地址后面加 ?acfloat=1 强制打开，例如 http://127.0.0.1:3081/?acfloat=1。 （地址里已经带着 ?token=... 这类参数时别再加问号，直接在最末尾加 #acfloat 就行。）

拖动滑块是运行时生效的（面板往运行时接口发一次 POST，内存和磁盘同时更新），不用重启； 只有改包里 cordis.patch.yml 的那些键才需要重启。

状态

• AS-IS，MIT。
• 验证过的版本：DSH 0.2.1-rc.2（真跑过整轮）。0.2.0-rc.2 只核对过源码、没真跑过——两个版本的 dsh-llm 都含同一条 developer 过滤逻辑，所以折叠说明一律走 user/message，不依赖版本。两个插件都用了 DSH 的内部服务与内部事件，大版本升级可能一起失效。
• 没在规模化真实环境里验证过；欢迎 fork / PR。

为什么折叠说明是 role: "user"

折叠后留下的那条说明走的是 user/message，不是 developer/message。这是踩过坑之后的选择。

developer/message 转上游本来是 role: "system"，语义更对。但宿主在把消息送上游之前会把不在工具更新名单里的 developer 消息静默丢弃 —— 不报错、不留日志。实测：会话日志里折叠事件完全正确、deriveMessages() 也返回 developer，可真实 HTTP 请求体里一条都没有——查了三处探针、抓了代理包才定位到这一行。

user/message 是唯一能真正送达的通道。代价是模型可能把它误当成"用户说的话"，所以文案做了两件事：首句自报身份（⟪thinking-guard⟫），以及一个祈使句都没有（"请…""不要…""直接…"这类句子是"用户下了个命令"的强信号，正是它会让模型开始编造用户说过的话）。