DeepSeek Harness 上下文压缩是什么？dsh compaction 触发机制与 DSH plugin 设置

DeepSeek Harness 的上下文压缩（compaction）是一项可选能力：它把一段历史替换成一条摘要节点，在 pressure 或 context-overflow 时触发（来源）。 官方把它归类为一个能力 seam，不属于智能体循环主干，因此它的词汇定义在压缩子系统而不是核心子系统里。这篇把三件事讲清：它到底是什么、什么时候压与压了会丢什么、以及相关 DSH plugin 与设置怎么配合。

DeepSeek Harness 上下文压缩是什么：把长历史折成一条摘要

compaction 做的事就一句话：把被选中的一段 surface 历史，替换成一条摘要节点（来源）。 DeepSeek Harness 的会话是一份仅追加的事件日志，消息历史从日志派生而来、从不单独存储；压缩不删日志，而是在派生出的消息面（surface）上做一次替换。三个关键点：

1. 它是一个能力 seam，不是主干 — 和 bash 一样分为 Service Definition（dsh-compaction，暴露 ctx.compaction）、Service Provider（如 dsh-compaction-basic 后端）和面向用户的 Consumer（dsh-command-compact）。预期：换一个后端不影响上层调用方式。
2. 压缩写的是三条仅日志事件 — compaction/start、compaction/summary、compaction/end，它们记录锁、摘要、被选范围与被遮蔽的 seq，绝不直接进入消息面。预期：压缩过程本身对模型不可见。
3. 唯一改到消息面的地方是那条摘要 — 摘要承载在一条带 surfaceOp: { op: 'replace', startSeq, endSeq } 的 user/message 上。预期：模型下轮读到的是摘要，而不是被遮掉的整段历史。

为什么要做成「替换」而不是「删除」：因为会话日志是唯一真源，回放要从同一组事件重新派生。删掉事件会让回放对不上，而一条 replace 既缩小了模型可见内容，又让日志保持完整——这就是「压掉但可追溯」的实现方式。

要注意「dsh-compaction」这个词有两层含义，别混。 一层是官方压缩能力的 seam 包名 dsh-compaction，它只负责暴露 ctx.compaction 接口、属于 DeepSeek Harness 官方压缩子系统；另一层是社区里 ljsysfurryace/dsh-compaction 这个同名插件，它把默认的 LLM 摘要换成语义 + 物理双轨 KV 压缩，官方说明约为 28.4 倍 KV 压缩且不额外调用 LLM。一个是官方接口定义、一个是第三方实现，看到 dsh-compaction 时先看语境是官方文档还是插件条目，别把两者当成一回事。

dsh compaction 什么时候触发、压了会丢什么

自动压缩有两种触发原因：pressure（压力逼近）与 context-overflow（提供方确认溢出）；压缩一定有损，被折掉的细节不会留在摘要里（来源）。 拆开看：

1. pressure 压力触发 — 自动策略在 agent/pre-step 瀑布式事件里、请求推导之前运行；满足条件就先调可选的工具结果剪枝（ctx.toolResultPruner），再通过 ctx.tokenMeter 重新测量，必要时甚至不生成摘要就能推进 surface。预期：先剪掉超大的工具结果，再决定要不要总结。
2. context-overflow 溢出触发 — 当提供方已确认溢出时，策略可以比普通压力更激进地做一次有效缩减，作为恢复手段。预期：报错后能靠压缩把会话救回来，而不是只能开新会话。
3. 压了会丢什么 — 一次成功压缩会记录 shadowedRange（被替换的 surface 边界对）、shadowedSeqs（被遮蔽的节点 seq，按 surface 顺序）和 shadowedTokenCount（估算 token 数）。预期：你能知道「压掉了多少」，但摘要本身只保留要点，原文细节被有损丢弃。
4. 没有安全范围就不动 — 若选不出可安全压缩的范围（比如单个超大保留单元），compactIfNeeded 返回 null 且不写日志。预期：不会为了压而压，把会话压坏。

三种触发路径的力度和边界摆一起看更清楚：

还要注意一个硬边界：这三种触发都不会自动覆盖你放在不易被压位置的硬约束，比如接口签名、验收标准、密钥名；它们只按 surface 范围挑选，挑选逻辑不理解业务语义，所以「哪些内容必须留」得靠你自己安排位置。

还有个容易忽略的点：边界要保持工具调用与结果的配对。 区域边界会保证 assistant 的工具调用与其 tool/result 成对，但不要求保持整个轮次，所以一个过大轮次里较早闭合的步骤也能被压缩。真被压得不对时，恢复动作只在 surface replacement generation 前进后才返回重试——这不是随便重试就能绕过的。

DSH plugin 上下文压缩相关插件与设置

围绕压缩，社区有两类 DSH plugin：一类负责「看清上下文」（可视化），一类负责「真正缩小占用」（压缩引擎或自动压缩），安装与查找的统一入口是 DSH Plugin Hub。 分两类讲：

1. 可视化诊断类 — 代表是 dsh-context：提供 Context 面板与 /context 命令，把上下文组成、演进与压缩事件画出来，只读不写。预期：先看清是哪一块在涨、哪段被压了，再决定要不要压。
2. 压缩执行类 — 例如 dsh-compaction-instant（免 LLM 的近无损压缩，附带 recall/search 回溯）与 dsh-context-compactor（用量到 80% 时自动总结并校验 token 下降）。前者主打毫秒级、零模型调用，后者主打阈值自动触发与 overflow 自动恢复。预期：装上后长会话的占用曲线被压下来。
3. 怎么装 — 可视化类多为标准 npm 包，一条命令即可：
   bash

   dsh plugin --profile web add dsh-context
   

   预期：终端回显已加入 web profile，启动 dsh web 后左侧出现 Context tab。
4. 设置在哪 — 更新源、npm 镜像与代理、安装信任确认都在 Hub 的「设置」页统一配置；装了压缩类后若想改阈值（如 80% 触发线），以插件自身的设置卡片为准。预期：压缩类插件的触发阈值、缓存与安全确认集中可管。

一句话分工：可视化回答「现在装了什么」，压缩回答「怎么装得下更多」，别把诊断工具当瘦身工具用。

两个典型场景帮你对号入座。 场景一「只是在长，但没报错」：先装 dsh-context 看清是哪几轮把上下文顶上去的，若只是工具结果堆得太多，先靠自动压力触发里的工具结果剪枝顶住，不必急着换压缩后端；场景二「已经报 maximum context length」：这时重点是恢复，选带 overflow 自动恢复或近无损回溯的压缩类插件，把会话救回来再谈长期配置。两个场景选型方向完全不同——前者是「别乱压」，后者是「先救命」。

使用 DSH plugin 上下文压缩的注意事项与局限

记住「压的是视图、丢的是细节、原日志还在」这三点，压缩这块就不会误判。

1. 压缩是有损的：摘要只保留要点，接口签名、验收标准这类硬约束尽量放在不易被压的位置，或落进跨会话的记忆类 DSH plugin。
2. 别指望摘要给全文：要精确复现原文，按 seq 去读没过 replace 的底层日志，而不是在摘要里找。
3. 手动压缩看命令在不在：compactNow 对应的用户入口由 dsh-command-compact 提供，命令是否出现取决于 profile 装了哪个消费者插件。
4. 溢出别硬顶：真报 maximum context length，先按《上下文超限怎么排查》处理，压缩是恢复手段之一而不是万能解。
5. 先看现状再压：装压缩前后用《dsh-context 上下文可视化》对比组成，效果可验证，不靠感觉。
6. 别叠加同类：多个压缩类 DSH插件 同时装可能互相打架，先装一个跑顺再补。

与其在长会话里手动删消息、反复猜哪段该压，不如让 DSH Plugin Hub 把上下文类与压缩类 DSH插件 集中管起来——更新源、镜像与安装信任一屏配好，装上哪个、压成什么样都看得见。官网在 https://dsh-plugin.org/zh/。

来源：DeepSeek Harness 官方文档 - 压缩（compaction）子系统、DeepSeek Harness 官方文档 - 会话、dsh-context（DSH Plugin Hub）