前言¶
在 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。
