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