记忆中枢 zhiwuli0228/dsh-memory-hub

dsh-memory-hub

DeepSeek Harness（DSH）的长期记忆中枢：文件原生、用户掌控、人类批准写入。

让 DSH 记住项目里值得留下的结论：可检索、可追溯、可干预。

V0.1.5 已发布：在 Host 插件 + Web 面板（含核心/子工作区配置）之上，加入预检相关性门控（min_score / local_boost）、指令式回写包尾、面板命中/引用计数、系统级 memory-hub skill，以及夜间确定性维护（只报告 + 生成 pending 提案，绝不自动提交）。已在 DSH Desktop Runtime 0.2.1-rc.5 完成宿主冒烟；npm 0.1.5 与 GitHub Release v0.1.5 均已发布。验证记录见 docs/COMPATIBILITY.md。

左侧边栏会新增「记忆中枢」图标。安装包含面板的版本后如果暂时没出现，重启一次 DSH 即可；本机已在运行中热加载成功。

它是什么

一条知识是一个带 YAML frontmatter 的 Markdown 文件，放在用户目录下的 Hub 里。每个用户回合开始时，插件做一次确定性检索，注入一份紧凑索引；模型按需读取全文、记录引用；任务结束给出回写评估；候选知识经 DSH 原生审批后才成为权威知识。

| 能力 | 说明 |
| 自动预检 | 每个用户回合第一步检索 accepted 知识，幂等键 (sessionId, turn) |
| 紧凑注入 | 只注入 ID、标题、一句话摘要、作用域；细节按需读取 |
| 检索与读取 | 关键词 + 类型 + 作用域 + 状态；CJK 二元组分词，无向量库 |
| 引用 | 区分"检索命中"与"实际使用"；记录 ID、版本、用途 |
| 候选与提交 | 候选写 pending/；提交必须经过 DSH 审批；模型不能自批 |
| 门禁 | 变更工具需要本回合有效预检；预检故障默认放行（可配置为拒绝） |
| 收尾 | 每个关闭任务都有评估；未评估的回合自动记 deferred |
| 汇总 | 管理员手动把项目知识晋升为 global 候选；按 promoted_from 幂等 |
| 夜间维护 | 每天 03:00 确定性巡检所有 core / 子工作区，写报告并按需生成 pending 提案；不自动提交 |
| 系统级 Skill | memory-hub 注册到 Host 全局 skills 层，按需加载检索/回写流程；不占每轮上下文 |

Web 面板

重启后，左侧边栏出现「记忆中枢」图标，主区域提供六个标签页：

- 总览：状态、计数、精简的能力标签、记忆闭环示意、工作区与最近知识
- 配置：核心工作区与子工作区（一对多）管理；可添加核心、添加子工作区并实时保存到 config.yaml
- 知识：搜索、类型/状态过滤、全文详情与来源
- 待审批：pending/ 候选列表（只读，不代替 DSH 审批）
- 活动与策略：最近任务、预检/门禁/证据要求
- 能力：10 个 memory_ 工具的详细说明

面板通过 Host 路由 /dsh-memory-hub/api/overview、 /dsh-memory-hub/api/knowledge 和 /dsh-memory-hub/api/config 读取/保存数据，只允许回环请求；知识审批仍走 DSH 原生流程，面板不绕过。

安装

已发布到 npm：dsh-memory-hub。

DSH 插件管理器（推荐）

插件是 profile bundle，直接安装 npm spec，不要只做 npm install -g：

dsh plugin --profile <name> add dsh-memory-hub@0.1.5

只想查看包内容时可以用：

npm pack dsh-memory-hub@0.1.5

Desktop（由 Electron 管理的 Profile）

通过 DSH 设置里的插件管理器安装 dsh-memory-hub@0.1.5。Desktop 的 desktop profile 由 Electron 管理，不要用 CLI 修改它。

本地目录 / GitHub

仓库包含构建产物 dist/index.js 与 client.js，安装本地目录或 GitHub 包时不需要再构建：

dsh plugin --profile <name> add <本地目录或 github:用户/仓库>

插件市场索引

DSH 的插件市场是自托管 JSON 索引。本仓库提供一份：

https://cdn.jsdelivr.net/gh/zhiwuli0228/dsh-memory-hub@main/site/index.json

在 DSH 插件页打开实验性「自定义插件市场」，添加上述索引源即可在「发现」中安装。

安装后重启 DSH，或等待插件管理器热加载。插件加载只会在 ~/.dsh/memory-hub（或 $DSH_HOME/memory-hub）下创建配置与目录，不会拖垮宿主启动。

配置

Hub 根目录默认是 $DSH_HOME/memory-hub，也可以在插件行的 config.root 里覆盖。策略与工作区放在 <root>/config.yaml：

version: 1
core_workspaces:
- id: product
name: '产品主仓库' workspaces:
- id: backend
core_id: product # 归属到核心工作区 product（可选） root: 'D:/projects/backend'
domains: [backend]
admin: true # 允许运行汇总 enabled: true

policy:
preflight:
mode: per-turn # per-turn | off
pack_tokens: 600
max_hits: 6
min_score: 1.0 # drop weak matches; 0 keeps every hit
local_boost: 1.2 # prefer the current project over core knowledge
inject: compact
gate:
mode: enforce # enforce | off
on_preflight_error: allow # allow | deny
unknown_tools: allow
mutating_tools: [bash, pwsh, write, edit, str_replace_editor]
maintenance:
enabled: true # Host 运行时每天巡检；错过的时间在下一次启动后补跑 time: '03:00' # 本地时间 HH:mm apply: propose # report | propose；propose 只创建 pending，不提交 all_cores: true max_proposals: 10 stale_pending_days: 30 stale_citation_days: 90

- 只有工作目录落在某个 workspace.root 内的会话才获得 project:<id> 作用域；其他会话只看到 global/domain。
- config.yaml 修改会被 watcher 热加载，不需要重启。
- 目录与文件格式见 docs/KNOWLEDGE-FORMAT.md。

工具

| 工具 | 用途 |
| memory_search | 检索 accepted 知识 |
| memory_get | 读取条目全文与来源 |
| memory_status | 根目录、工作区、计数、索引诊断 |
| memory_preflight | 手动/强制预检（没有自动任务时会创建一个可恢复任务） |
| memory_cite | 记录实际使用 |
| memory_propose | 创建候选（create / update / deprecate） |
| memory_commit | 经审批提交候选 |
| memory_close_task | 关闭任务并给出评估 |
| memory_consolidate | 管理员手动晋升项目知识 |
| memory_maintenance | 巡检当前/全部 core，写报告并可选生成 pending 维护提案 |

memory_commit 会触发 DSH 原生审批；审批不可用（headless、审批关闭）时提交被拒绝，候选保持 pending。模型参数里没有可伪造的批准令牌。

夜间维护

policy.maintenance.enabled: true 后，Host 每 60 秒检查一次本地时间；到点当天只跑一次，错过的时间在下一次 Host 启动后补跑一次。它使用插件内部定时器，不是 DSH schedule，因此不会出现在官方「自动化任务」栏；控制入口是 config.yaml。

多个 core 时是一个全局定时器，按 core_workspaces[] 配置顺序串行巡检，fallback 最后；每个 core 独立写 <hub>/reports/<timestamp>.md 和 latest.md，然后：

- 精确重复（标题 + 摘要 + 正文哈希一致）→ 生成 deprecate pending 提案；
- 带 core / shared / reusable / promote 标签的子工作区知识 → 生成晋升到核心作用域的 pending 提案；
- 近似重复、过期 pending、长期未引用、加载诊断、超长正文、作用域异常 → 只写报告，留给人判断。

维护任务永不调用 memory_commit、不删除、不改写正文；同一指纹已有 pending 时跳过，避免每晚重复。也可以随时手动调用 memory_maintenance，用 apply: "report" 只看报告。

多 core 的完整顺序、单 core 失败语义、状态文件和配置含义见 docs/01-architecture/maintenance.md；每日检查与排障见 docs/06-operations/maintenance.md。

系统级记忆 Skill

插件还会在 Host 的全局 skills 层注册 memory-hub。它是一项按需加载的操作规范，不占用工具名额：

- 模型在任务涉及历史决策、约束、API、流程、回写，或用户说“记住/记录/以后按这个来”时加载；
- 用户也可以直接调用 skill 工具加载；
- 正文不进入每轮上下文，catalog 只显示 description 和 whenToUse；
- 覆盖固定流程（预检 → memory_get → memory_cite → 必要时 memory_search → memory_close_task）、作用域选择、写入审批、核心回填、夜间维护和反模式；
- 宿主没有 skills 服务时只记录 warning，插件继续运行。

命名冲突：当前官方/内置 skill（agent-experience、cordis-、office 等）没有 memory-hub，也没有旧的通用名 memory-management。DSH 同 layer 内按 rank 取第一个，runtime（250）会盖住 bundled（600），所以通用名一旦撞上官方 skill 会静默遮蔽而不是报错。因此本插件改用产品自有名 memory-hub，并在 tests/skill.test.ts 锁定当前官方名称快照；完整审计见 docs/02-harness/context-policy.md。

安全与边界

- 默认本地优先、无网络请求；知识是用户目录下的普通文件，可直接编辑、git、备份。
- 路径经过真实化与作用域校验；项目知识不会自动晋升到 global。
- 夜间维护只写报告和 pending 提案，不自动提交、不删除、不改写正文；审批仍由人完成。
- 插件不修改 DSH 核心、不写 Profile 的 package.json/cordis.patch.yml；卸载保留全部记忆文件。
- V0.1 是每个根目录一个写者：第二个写者只让该根降级为只读，不会并发写，也不会波及其他工作区；跨机拷贝或进程退出留下的锁，在确认不是本机活写者后自动回收（<root>/records/.writer.lock）。

开发

npm install
npm run typecheck
npm run test # 59 个单元/集成/插件/面板注册/skill/维护/锁测试
npm run build # 产出 dist/index.js
npm run check # typecheck + build + test

实现结构：

src/
index.ts # Cordis 入口（apply / inject） runtime.ts # 初始化、钩子、watcher、上下文注册、面板 API service.ts # 预检、门禁、引用、提案、关闭、汇总、维护、面板数据 maintenance.ts # 确定性巡检：重复/晋升/过期/诊断，报告渲染 maintenance-schedule.ts # 本地日期/时间判断 store.ts # Markdown + JSONL + 序列 + 版本归档 search.ts # CJK 分词与倒排索引 frontmatter.ts # 知识/候选文件解析与序列化 skill.ts # 系统级 memory-hub skill 定义与注册 config.ts hub.ts lock.ts atomic.ts ledger.ts ... client.js # 侧边栏面板（模块加载器格式，无需构建） tests/ # 59 个测试（10 个文件） docs/ DESIGN.md # V0.1 设计 KNOWLEDGE-FORMAT.md # 知识文件格式 COMPATIBILITY.md # 宿主验证记录与已知限制 00-project/decision-log.md # 按日期的决策与改动记录 01-architecture/maintenance.md # 多 core 夜间维护执行模型 01-architecture/decisions/ # ADR-0004 skill、ADR-0005 夜间维护 06-operations/maintenance.md # 维护操作与排障

发布

推送 v tag 会触发 GitHub Actions：在 Windows 上运行 typecheck、build、test，打包 npm tarball，通过 npm Trusted Publisher（OIDC）发布 npm，并创建 GitHub Release。首次使用前需要在 npm 包设置里绑定仓库和 release.yml，无需 NPM_TOKEN。步骤见 docs/06-operations/release.md。

git tag v0.1.5
git push origin v0.1.5

已知限制

- 审批通过路径依赖交互式审批；本机验证时审批提示被关闭，只验证了失败关闭。门禁的宿主级拒绝路径由单元测试覆盖，未在真实会话中强制触发。
- 未验证 PTC run_code 嵌套调用、外部 CLI、多进程共享 Hub。
- 上下文注入按"每个任务一份包"设计；长会话的累积效应尚未做规模测量。
- Web 面板的客户端模块已在本机运行中热加载（client.advertised: true，sidebar.panellist 与 main 均 active）；点击后的完整视觉布局尚未在本会话中截图确认。
- 面板只读，不提供批准按钮；提交仍需在会话中经过 DSH 审批。
- 夜间维护依赖 Host 运行；Host 关闭时不会执行，下一次启动且当天未跑过会补跑一次。
- 多 core 维护串行执行，总耗时是各 core 之和；一个 core 失败当天不重试。
- 维护不出现在官方「自动化任务」栏，不能在那里暂停/编辑/立即运行；控制入口是 config.yaml。
- reports/ 目前不自动清理；条目多时可定期归档或删除旧报告。

许可

MIT © 2026 zhiwuli0228