一切的一切始于那场 DeepSeek API 断网故障。
DeepSeek API 断网那天，一开始我并不慌。家里服务器上跑着两张卡，本地 Qwen3.8:27b 随便用。但是，当把模型从云端 DeepSeek 切换回本地之后，我开始慌了——会话中已有的上下文超出了本地模型的上限。
DeepSeek Harness 上下文压缩机制是通过大模型来概括精简上下文，但是云端大模型不可用，上下文压缩也就不可用。就在这时，一直在角落里默不作声的 Grok 提议：“你需要的并不是上下文压缩，而是上下文裁剪。不需要大模型参与，只需要剪掉超出限额部分的上下文就好”。于是，dsh-command-context-trim 插件项目就这样开始了。
插件最一开始的功能很简单，不靠大模型，只靠脚本搜索上下文，保留头部的系统提示和工具集，从最古老的对话部分开始，将对话成对剪掉（一则用户消息和一串模型回复为一对）。原则上保留最后一对对话，这样可以保证可以继续会话内容。
就这样度过了 DeepSeek API 的断网期。很快，迎来了 DSH v0.1.7-rc 更新。这一版更新为了配合 DeepSeek 云端 API，在上下文机制和计算上引入了头部预留（headroom），固定为 65536 tokens (64K)。本地模型的 128K 上下文顿时有一半不能用了。表现现象就是上下文还没填到 50% 就触发压缩（compaction）。于是，插件里面又添加了上下文计算调优功能。
总算解决了上下文计算，新的问题又出现了—— DSH内置的上下文修剪（prune）功能会将上下文中最后一组会话剪掉！ 表现出来的现象是，模型先读进一个文件 -> 文件太大触发修剪（prune）-> 刚读进来的代码被修剪掉 -> 模型再次读入同一个文件…… 如此循环。于是，插件中又多了上下文修剪调优功能。
DSH v0.1.7-rc 引入的另外一个大规模更新就是独立的插件设置页，对插件设置页的制作提出了规范化的要求。这是好事。于是，我又花了几天时间，指导AI适配新的插件设置页。
终于，在 DSH v0.2.0-rc.2 上线之际，插件的更新完成了！
