前言¶
在 DeepSeek Harness（DSH）里做长对话或长任务时，上下文会不断累积。触达阈值后宿主会做压缩，压缩往往只保留概要，先前的决策、约束和结论容易丢失。常见现象是：压缩前几十轮里有多条关键约定，压缩后只剩一句「前面聊过包管理器」，具体选择无从追溯。
社区插件 dsh-plugin-lrc（维护者 zhibaiYingChuan）走的是另一条路：不把主要希望压在「压缩瞬间抢救」上，而是在对话过程中把决策、约束、结论持续写入 LRC 长期记忆库，上下文里只保留一行状态快照；需要细节时再按需召回。分类上属于 DSH 插件目录中的「记忆」类；仓库当前星标为 0。生态上 DSH 奉行「一切皆插件」，SkillHub 目录 是社区站点，与 DeepSeek / 幻方无官方从属关系。
下面按定位、能力、安装、用法与注意事项说明该插件。
这是什么¶
dsh-plugin-lrc 把 LRC 的结构化长期记忆接入 DSH 的会话与上下文压缩相关流程，实现边聊边沉淀、按需召回、可纠错，目标是显著降低「因上下文膨胀而频繁压缩」带来的信息损失。
README 标明插件版本 0.2.0，MIT 许可证，适配 DSH >=0.2.0-rc.1 <0.3.0-0。package.json 中 npm 包版本为 0.2.1，与 README 版本号略有差异，以你安装来源的发布说明为准。
数据流可以概括为：
对话（线性、易失）
↓ 按轮次/步数/字符增量提炼
结构化记忆（决策 / 约束 / 结论 / 报错）
↓ 语义查重后写入
LRC 长期记忆库（持久、可检索）
↓ 回填一行状态快照
上下文（体量受控）
模型侧看到的上下文示例形态如下（摘自 README 说明）：
[LRC 状态] 已确定用 pnpm（放弃 npm 因兼容问题）；端口纪律 3099/3111。
细节在 LRC，需要时 recall。
核心功能¶
以下能力均来自仓库 README，安装成功后多数流程自动运行；也可通过插件注册的 DSH 原生工具主动调用。
| 能力 | 作用 |
|---|---|
| 自动沉淀 | 对话中的决策、约束、结论写入本地 LRC 记忆库 |
| 按需召回 | 新会话中可通过工具查询历史决策与用户偏好 |
| 主动纠错 | 发现错误记忆时可删除，避免污染后续 |
| 会话交接 | 上下文接近上限时整理交接摘要并新建会话 |
| 状态自检 | 查看插件是否正常、能力矩阵与阈值等 |
| 上下文裁剪 | 裁剪旧历史，支持长对话不中断 |
DSH 没有 LRC 原生的 MCP 客户端路径，因此插件将读、写、纠错等封装为 DSH 原生工具，供宿主侧 AI 直接调用。
提炼与筛选在插件端完成的三层逻辑（LRC 端不挂 LLM，保持毫秒级写入）：
- 硬规则：丢弃寒暄、代码围栏、常规终端日志、过短且无关键词的行。
- 宿主 LLM 提炼：通过系统提示让模型在回答末尾输出
<lrc_memory>…</lrc_memory>，插件用正则提取。 - 本地查重：Jaccard ≥ 0.85 视为复述，不再向 LRC 发 HTTP 请求。
沉淀触发条件（满足任一即可，另有 turn 结束时的兜底）：累计 8 步、8 轮正文、6000 字符；长任务末尾的最终报告依赖 turn 结束兜底。
README 中附有 2026-11 在真实 DSH 会话（1855 步）上的实测结论（缓存命中率、裁剪与成本对比等）。使用时应理解：上下文仍会因用户消息与工具输出增长，插件主要搬走结论性内容以压低增速；不承诺永不压缩，而是压缩频率大幅下降。记忆要发挥作用，往往依赖 AI 主动调用 lrc_recall，README 标明这一点并非百分之百可靠。
安装与启用¶
前置条件¶
- DSH
>= 0.2.0-rc.1 - Node.js
>= 20
从 GitHub 安装（README 推荐）¶
将 desktop 换成你的 profile 名（如 web）：
dsh plugin --profile desktop add github:zhibaiYingChuan/dsh-plugin-lrc
确认插件已进入配置：
dsh --profile desktop --dump-config | grep dsh-plugin-lrc
从 npm 安装（发布后可用）¶
dsh plugin --profile desktop add dsh-plugin-lrc
关于 LRC 本体¶
不必先单独安装 LRC。插件启动时会探测本地已有实例（环境变量或 3099 端口），否则按平台准备内置二进制并启动隔离实例（独立数据目录）；失败则降级为纯客户端模式并跳过沉淀。
数据目录因模式而异：
| 模式 | 数据目录 | 说明 |
|---|---|---|
external（复用已有实例） |
例如 ~/.loong-recall/global/data |
插件不拥有该数据；删 ~/.dsh/cache/lrc-plugin/data 清不掉它 |
managed（插件自启） |
$DSH_HOME/cache/lrc-plugin/data |
仅该目录为插件自有 |
清理测试数据前应根据日志区分「复用已有实例」与「已启动隔离实例」，避免删错目录。
安全提示：插件随当前 DSH 进程权限运行。安装前建议浏览 GitHub 源码 与 MIT 许可证，确认符合你的环境与合规要求。
典型用法¶
安装后一般无需额外操作即可自动沉淀与裁剪。需要时让 AI 调用下列工具（名称来自 README）：
| 工具 | 用途 |
|---|---|
lrc_recall |
召回相关记忆；涉及项目历史、偏好、先前决策时优先调用 |
lrc_forget |
删除错误记忆；id 取自 lrc_recall 输出 |
lrc_remember_now |
立即将当前对话沉淀到记忆库 |
lrc_handoff |
整理交接摘要并新建会话 |
lrc_status |
查看运行状态（能力矩阵、熔断、阈值、上下文画像等） |
配置¶
在 cordis.patch.yml 的 config: 下配置，或通过 DSH 配置界面修改。常用项如下（缺省值以 README 为准）：
| 配置项 | 缺省 | 说明 |
|---|---|---|
baseUrl |
空 | 指向已有 LRC 实例；留空则自动探测 / 启动 |
token |
空 | 服务端设置 LRC_API_TOKEN 时必填 |
project |
dsh |
记忆归属项目 |
offloadTurns |
8 |
每多少轮沉淀一次 |
offloadChars |
6000 |
累计多少字符沉淀一次 |
offloadSteps |
8 |
累计多少步沉淀一次 |
maxItems |
40 |
单次最多提炼条数 |
contextWindowTokens |
0 |
显式指定模型窗口；0 为自动探测 |
trimRatio |
0.03 |
裁剪阈值占窗口比例 |
trimMinTokens |
30000 |
窗口未知时的裁剪阈值 |
trimMinSteps |
10 |
两次裁剪之间最少间隔步数 |
pruneResultThreshold |
4096 |
工具输出超过该字符数才剪枝 |
若宿主对未知模型返回 1,000,000 一类哨兵窗口，插件会保守降级到 trimMinTokens=30000；确知模型上下文长度时，建议显式设置 contextWindowTokens。
适用场景与注意¶
适合谁：长期在 DSH 单 profile 下做架构决策、约束约定、跨会话延续任务，且愿意使用 LRC 作为本地长期记忆后端的开发者。
使用上应知道的限制（README「诚实说明」）：
- 结论性内容外溢的对话主体、工具大段输出仍会推高上下文。
- 召回效果依赖模型是否按引导调用
lrc_recall。 - 复用外部 LRC 实例时，数据生命周期与插件缓存目录解耦，运维时要按模式区分。
开发者本地构建与测试（可选）：
npm install
npm run build
npm test
结尾¶
dsh-plugin-lrc 把 LRC 的结构化记忆嵌进 DSH 会话路径，用持续沉淀与一行状态快照换更小的有效上下文，用原生工具补齐召回与纠错，面向「长对话少丢决策、跨会话可查约定」这一类需求。进一步信息见社区目录页 skillhub.cn/plugins/zhibaiYingChuan/dsh-plugin-lrc 与源码仓库 github.com/zhibaiYingChuan/dsh-plugin-lrc。
