前言¶
DSH 的插件生態裏，記憶類插件通常有兩種做法：要麼讓 agent 自己建一套記憶庫，要麼把歷史會話抽取成條目後做向量檢索。這兩種做法都引入了第二份數據，和源文件之間會慢慢對不上。
dsh-wb-memory 走的是另一條路。它不建庫、不落副本，直接把 WorkBuddy 已有的 Markdown（SOUL / USER / MEMORY / topics）渲染進 system prompt 的一個獨立 section，寫回也作用在同一批源文件上。
插件由 Nero0427 維護，分類爲「記憶」，許可證 MIT，當前版本 0.1.2，倉庫在 https://github.com/Nero0427/dsh-wb-memory 。下面按「裝起來 → 配好 → 用起來」的順序介紹。
定位¶
一句話：把工作臺里人寫的長期記憶，原樣接進 DSH 的 system prompt。
它的前提是：記憶已經是一份人維護的 Markdown，不是需要從會話裏挖出來的東西。插件做的事情是「讀這份 Markdown → 渲染成一段 → 插進 system prompt → 讓 agent 按協議寫回同一份文件」。
工作流可以概括成：
~/.workbuddy/user-*-personal/
SOUL.md ┐
USER.md ├─ 渲染 ──▶ system prompt 的一個獨立 section（dsh-wb-memory）
MEMORY.md │ 不寫任何副本
IDENTITY.md │
topics/*.md ┘ 只放索引，正文按需 read
三個方向都要覆蓋：
- 讀：裝配 system prompt 時把身份、畫像、長期記憶渲染成一段，插在
dsh-purge注入之後、它的尾部錨點之前。 - 寫：同一段裏帶「記憶協議」，讓 agent 把踩坑、約定、決定寫回源文件，用的是宿主內置 edit 工具，不另造工具。
- 同步：按源文件 mtime 緩存。源一改，下一輪請求帶新內容；DSH 寫回後，另一個客戶端下次會話自然讀到同一份。
安裝與啓用¶
前提是宿主是 DSH，且記憶目錄已存在（默認自動探測 ~/.workbuddy/user-*-personal）。
推薦從 GitHub 倉庫安裝，這樣插件市場能識別來源，也能檢測並應用更新：
cd <DSH_HOME>/profiles/desktop
pnpm add github:Nero0427/dsh-wb-memory
也可以從 Releases 下載 dsh-wb-memory-<version>.zip，解壓後把整個插件目錄放到 node_modules/dsh-wb-memory。
開發時才用 link: 掛本地副本，指向倉庫根，不是 src/：
{
"dependencies": { "dsh-wb-memory": "link:/path/to/dsh-wb-memory" },
"dsh": { "profile": { "bundles": ["dsh-wb-memory"] } }
}
注意 link: 依賴屬於本地開發副本，插件市場不會爲它提供更新。
接下來在 profile 的 cordis.patch.yml 裏停用 AGENTS.md 加載器，並插入本插件：
- id: agent-instructions
name: '@deepseek-ai/dsh-agent-instructions'
disabled: true # 停用 AGENTS.md 加載器
- insert:
- id: dsh-wb-memory
name: dsh-wb-memory
inject: [systemPrompt, webServer]
config:
enabled: true
maxBytes: 60000
topicsMode: index
projectMemory: true
重啓 DSH，設置頁左側會出現「記憶」分區。
停用 AGENTS.md 加載器的原因有兩條：它會在 $DSH_HOME 下落一份 AGENTS.md 副本，和源文件是兩份數據；另外 dsh-purge 的 dropWorkspaceBaseline 在 strict / fallback 策略下會丟掉它的注入。直接注入 system prompt 沒有這兩個問題。
配置¶
配置項如下，全部有默認值：
| 鍵 | 默認 | 作用 |
|---|---|---|
enabled |
true |
關掉後 system prompt 不再帶記憶段 |
maxBytes |
60000 |
字節預算（下限 4000），超了從 topics 起截斷，SOUL 與 USER 永遠保留 |
topicsMode |
index |
index 只放一句話摘要 + 路徑；full 全文；off 不注入 |
projectMemory |
true |
注入記憶協議，並允許 agent 讀寫項目級 .workbuddy/memory/ |
includeIdentity |
false |
是否帶上 IDENTITY.md（與 SOUL / USER 內容重疊） |
workbuddyRoot |
空 | 源目錄，留空自動探測 ~/.workbuddy/user-*-personal |
配置有三層優先級：設置頁寫入的 <DSH_HOME>/dsh-wb-memory/config.json > cordis.patch.yml 的 config > 內置默認值。設置頁改完下一輪請求即生效，不必開新會話。
要壓體積時，優先級是：MEMORY.md 瘦身（把硬件、系統這類靜態段落挪進 topics）> 關主題索引 > 關協議。
典型用法¶
裝好後可以手動確認狀態和排查注入問題：
/memory 狀態（字節數、注入輪次、最近一次）
/memory render 清緩存重算
/memory preview 看正文
/memory path 源目錄與段名
比如改了 MEMORY.md 但本輪沒變，先用 /memory render 強制重算；爲什麼沒生效，用 /memory path 確認源目錄探測到了，再用 /memory preview 看正文是否爲空。
寫回過程不需要額外觸發。記憶段裏帶了協議，agent 在會話中判斷時機，用宿主 edit 工具直接改源文件。協議裏還要求：發現陳舊條目直接改掉或刪掉，不要在後面追加「已更新」；不要記工具原始輸出、大段代碼、一次性調試結論。
token 開銷方面，作者實測（2026-11-04）：SOUL.md 約 650 token，USER.md 約 500，MEMORY.md 約 1.3 K，topics 索引約 240，記憶協議約 450，合計約 3.3 K token，佔 1M 窗口 0.3%。因爲 DSH 每輪重發完整上下文且前綴緩存命中後按約 1/10 計價，這段固定不變的內容邊際成本幾乎爲零。
與 dsh-purge 的關係¶
兩者掛在同一個 system-prompt/assemble waterfall 上，但職責不同：
| purge | dsh-wb-memory | |
|---|---|---|
| 掛載點 | 同一個 waterfall，先註冊 | 同一個 waterfall，後註冊 |
| 改裝配的哪部分 | 替換正文、加尾部錨點 | 只 append 一個獨立 section |
| 順序保證 | 宿主補丁把 dsh-purge* 段強制排最前 |
記憶段固定落在錨點之前 |
實測順序是 dsh-purge → dsh-wb-memory → dsh-purge:anchor。不重複注入，不覆蓋 purge 正文。可以只裝其中一個；一起用時順序由這個規則保證，不需要額外配置。
適用場景與注意¶
適合的場景：已經在維護一份人寫的 Markdown 記憶（SOUL / USER / MEMORY / topics），希望多個 agent 客戶端複用同一份數據，同時接受「模型按協議自行寫回」的寫入方式。
需要留意的幾點：
- 插件以當前 DSH 進程權限運行，能讀寫源文件目錄。安裝前建議先讀一遍源碼與許可證（MIT），確認注入內容與寫回行爲符合預期。
- 文件結構是硬約定。
SOUL.md/USER.md/MEMORY.md/topics/*.md這些文件名由render.js約定，改名要同步改源碼。 - 一個進程讀一個源目錄，不做多用戶。
- 項目級記憶不自動注入，協議讓 agent 按
<cwd>/.workbuddy/memory/自己讀，省 token。 - 如果 purge 的
/rules用了complete（獨佔整個 prompt），記憶段會被宿主丟棄，/memory的注入輪次能看出來。
小結¶
dsh-wb-memory 的價值在於把「記憶」這件事壓縮到一句話：同一份 Markdown，兩個客戶端都讀它，agent 寫回也落在同一份上。不建庫、不抽取、不檢索，換來的是沒有副本漂移。
相關資料：
- 插件目錄頁：https://www.skillhub.cn/plugins/Nero0427/dsh-wb-memory
- GitHub 倉庫：https://github.com/Nero0427/dsh-wb-memory
- 許可證：MIT
