前言¶
在 DeepSeek Harness（DSH）里做长会话时，宿主会把较早的对话压成一条摘要。压一次往往还能接受；多压几轮之后，「当初为什么否决方案 A」「参数定的是 0.75 还是 0.8」「测试到底有没有跑过」这类细节会从上下文里消失，模型有时还会推翻刚才已经确认过的结论。
单靠对话历史无法可靠地保留这些「已定结论」。社区插件 dsh-track（维护者 Saretheya，目录分类为记忆）的做法是：让模型在里程碑处写入检查点，插件把检查点存进插件自有目录，并在每次压缩之后重新注入系统提示词，使关键状态不随有损摘要一起被冲走。检查点不会写入你的工作区。
这是什么¶
dsh-track 是面向 DSH 0.2.x 的 Cordis 插件（npm 包名 dsh-track，当前版本 1.0.1，MIT 许可）。它不负责改 DSH 的压缩算法，而是把检查点放在系统提示词中不参与压缩的区段里，作为跨越多次压缩的权威副本。
插件在 SkillHub 社区目录中的简介与 GitHub 一致：模型写入检查点，插件在每次压缩后将其重新注入系统提示词；数据只落在插件目录，不污染工作区。
核心功能¶
检查点读写与上下文状态¶
插件向模型暴露以下工具（名称以 README 为准）：
| 工具 | 作用 |
|---|---|
checkpoint_write |
写下或更新检查点；旧代自动归档，保留最近 20 代 |
checkpoint_read |
读回全文，或按关键词过滤行 |
context_status |
查看真实 token 占用、窗口，以及当前检查点为何被注入或未注入 |
context_compact |
在宿主提供压缩服务时预约一次主动压缩；若拿不到压缩服务则只落盘并如实告知 |
写入检查点时，README 强调跨会话召回务必填写 topic 与 keywords，否则跨会话时往往只会得到一行指针而非摘要卡片。
四档注入策略¶
插件不会每轮都把整份检查点塞进上下文，而是按检查点与会话的关系选择体量：
| 情形 | 注入内容 | README 记载的实测体积 |
|---|---|---|
| 同一会话 | 全文（单份注入上限 12000 字符） | 起约 240 字符 |
| 跨会话、7 天内、主题相关 | 摘要卡片（≤900 字符） | 约 175 字符 |
| 跨会话、过期或主题不相关 | 一行指针 | 约 95 字符 |
| 尚无检查点 | 不注入 | 0 字符 |
「主题相关」由检查点里的 topic 与 keywords 做关键词级判断，不是语义 embedding；误判方向偏保守，宁可少给也不白占 token。
主动提醒与压缩后唤醒¶
除常驻提示词段和随包分发的 context-checkpoint 技能（里程碑、压缩后对账、上下文压力等触发条件）外，插件会在上下文占用跨越档位时向会话注入提醒（同一档位只提醒一次）：
| 档位 | 触发阈值 | 提醒要点 |
|---|---|---|
warm |
占用 ≥ 窗口 50% | 先 checkpoint_write 落盘，再 context_compact |
near |
占用 ≥ 80% | 立刻更新检查点 |
over |
占用 ≥ 90% | 立即更新检查点 |
压缩执行完成后，插件还会注入后续消息，提示检查点已落盘、历史已压缩，要求模型直接接着做、不要重述已完成工作。
数据存放位置¶
全部数据在 DSH 插件目录下，工作区不会新增文件：
<DSH_HOME>/plugins/dsh-track/data/
├── checkpoints/<工作区标识>/
│ ├── current.md
│ ├── current.meta.json
│ └── gen-NNN.md
├── active-variant.lock
├── tmp/
└── logs/
README 说明：单份写入上限 60000 字符（超出拒绝）；单份注入上限 12000 字符（超出截断并提示，全文仍可用 checkpoint_read）；跨会话卡片有效期 7 天；context_compact 在落盘超过 10 分钟新鲜度窗口时会拒绝预约。
安装与启用¶
需要 DSH 0.2.x（README 记载在 0.2.1-rc.5 实测）。官方安装命令如下：
dsh plugin --profile desktop add dsh-track
安装后重启 DSH。插件不修改你的 cordis.patch.yml，也不写 settings.yaml；卸载后数据随插件目录消失。Node 引擎要求见 package.json：^22.19.0 || >=24.0.0。
典型用法¶
下面介绍一条可复现的主线，细节以 README 为准。
- 在长任务中于里程碑（根因确定、方案定稿、测试通过、用户确认决策等）调用
checkpoint_write，写清当前目标、已定结论、否决方案及原因、待办与证据；并填写topic、keywords以便日后跨会话召回。 - 当占用接近上限时，按插件提醒先更新检查点再调用
context_compact（若环境支持）；压缩后依赖系统提示词中的检查点副本继续执行，无需从零复述。 - 需要核对注入策略或 token 占用时，调用
context_status；需要全文或按行检索时，调用checkpoint_read。 - 若任务长期占用低于 50%、几乎不触发压缩，README 建议在项目
AGENTS.md中约定里程碑纪律（例如每个模块改完调用一次checkpoint_write），避免完全依赖自动提醒。
适用场景与注意¶
适合谁：在 DSH 桌面或 Web 上做长时间编码、排查或方案迭代，且担心多轮上下文压缩导致结论与证据丢失的开发者。
已知限制（来自 README）：插件不会自动总结对话，「写什么」仍由模型（及你在 AGENTS.md 中的纪律）决定；主动压缩是否可用取决于 DSH 装配；同一 data/ 目录只允许一个插件实例生效，多实例指向同一目录时后到的会休眠。
安全与信任：插件以当前 DSH 进程的权限运行，检查点内容可能包含任务细节。安装前应阅读 GitHub 仓库 源码与 MIT 许可证，确认符合你的环境与合规要求。SkillHub 目录（saretheya/dsh-track）是社区站点，与 DeepSeek / 幻方无官方从属关系；DSH 生态理念是「一切皆插件」，本文介绍的是社区维护的 memory 类插件之一。
结尾¶
经过上面的步骤，你可以把 dsh-track 理解为：在压缩碰不到的系统提示词区段里放一块「路标」，用可控 token 成本的注入策略，让任务状态在压缩之后仍能接上。
