主流做法在窗口溢出时一刀切截断较早的回合,把其中的工作知识连同退路一起丢弃。flowctx-dsh 是一个 DeepSeek Harness (DSH) 上下文引擎插件,换一种取舍:按与当前任务的距离分档保真 —— 离得越远,压得越狠;离得越近,保得越全;当前正在做的事,分毫不动。原文则始终可按需还原。于是前缀缓存稳、推理不掉速、任务不断线 —— 三者兼得,而非彼此让步。三档:
flowctx_retrieve(hash) 字节级取回 —— 压缩视图有损,原文无损。assemble() 读时投影,磁盘永远是未压缩的原文真相源。会话刚起步,还没有历史。每个回合 DSH 调用引擎的 assemble(),消息按引用原样透传流入窗口 —— 字节不变、服务商 KV 缓存始终命中、不调 LLM。此刻只有当前这一轮、窗口占用还很低,没有任何压缩发生,右侧全是原文。
轮次积累,装配量升到约 52k(仍未越过 100k 门控),所以还不需要摘要。flowctx 先做结构化压缩:已离开当前任务的过往轮里,那些超大工具结果(读过的整份源码、跑过的长日志)按内容类型确定性压缩(零 LLM、可字节级还原);中间结构相似的若干轮直接省略。当前轮始终原文不动。
sha256[:24] 存储,替换为标记:[flowctx: code compressed 8400→190 chars · flowctx_retrieve(hash="a91f…")]光靠结构化压缩,窗口占用还是逼近了 100k 门控。这时 flowctx 才动用摘要,而且很克制:不会一口气把历史全压掉,只把最旧的那一段切出来、折成一个 leaf 节点(d0-1-3)。更旧的其余历史排在后面,轮到了再逐段折;离得近的过往轮此刻仍是结构化压缩,并不摘要。折出来的这一段,留下一份交接笔记 —— 失败的做法、关键的标识符,一字不落,原文也随时能按哈希取回。
caller=context-engine.turn.maintenance · 输入 12,875 → 输出 3,400 tok · $0.059leafChunkTokens,越过门控才触发 —— 摘要是最后一档手段。对话继续,更旧的历史一个 chunk 接一个 chunk地被折叠成独立 leaf(d0-1-3 · d0-4-6 · d0-7-16 …)—— 每个 chunk 按话题独立成块、互不稀释,早期话题不淡出。当同层 leaf 累积到 condenseFanout 个,flowctx 把它们 condense 成一个深度 +1 的上层节点 d1-1-31,子 leaf 被遮蔽、只注入这一块 —— 极长会话摘要块数量始终有界。这才是「渐进折叠」:从单个 chunk,到多 chunk,再到 condense。
d1-1-31 · childIds=[d0-1-3 · d0-4-6 · d0-7-16 …]系统进入稳态,右侧呈现清晰的三档:更早历史收敛为有界的 condense 节点 · 临近过往轮结构化压缩 · 当前轮始终原文、分毫未压。原文、scratchpad、各层摘要全部持久化到 SQLite,经 flowctx_retrieve(hash / node) 字节级还原,重启零 LLM 重建。这套分层同时守住前缀缓存、推理性能与任务完成率。