前言¶

在 DeepSeek Harness（DSH）里做项目，会话会结束，但结论往往还散落在聊天记录里：接口约定、踩坑记录、团队约定，下次开新任务又要从头对齐。把笔记丢进外部文档可以，但和 Harness 的检索、工具调用、审批流程通常是两套系统。

下面介绍社区插件 dsh-memory-hub（维护者 zhiwuli0228，分类：记忆）。它把长期记忆做成用户目录下的 Markdown 文件：本地优先、可 git、写入必须经 DSH 原生审批，模型不能自批。README 将其定位为「文件原生、用户掌控、人类批准写入」的长期记忆中枢；npm 包名 dsh-memory-hub。

这是什么¶

一条知识是一个带 YAML frontmatter 的 Markdown 文件，存放在 Hub 目录（默认 $DSH_HOME/memory-hub，可在插件配置 config.root 覆盖）。每个用户回合开始时插件做确定性检索，向上下文注入紧凑索引；模型按需读取全文并记录引用；任务结束时有回写评估；候选知识进入 pending/，经审批后才成为 accepted 权威知识。

检索侧不依赖向量库：关键词 + 类型 + 作用域 + 状态，并对 CJK 做二元组分词。V0.1.5 起增加预检相关性门控（min_score / local_boost）、指令式回写包尾、Web 面板命中/引用计数、系统级 memory-hub skill，以及夜间确定性维护（只报告 + 生成 pending 提案，不自动提交）。README 记录已在 DSH Desktop Runtime 0.2.1-rc.5 完成宿主冒烟；package.json 中 engines 要求 dsh >= 0.2.1-rc.5、node >= 20，许可证 MIT。

核心能力¶

回合内的记忆闭环¶

Web 面板¶

安装含面板的版本并重启 DSH 后，左侧边栏会出现「记忆中枢」图标。主区域提供总览、配置（核心/子工作区，实时写入 config.yaml）、知识浏览、待审批列表（只读，不代替 DSH 审批）、活动与策略、以及 10 个 memory_* 工具说明。数据经 Host 路由 /dsh-memory-hub/api/overview、/knowledge、/config 读写，仅允许回环请求。

系统级 Skill¶

插件在 Host 全局 skills 层注册 memory-hub，按需加载，不占每轮上下文正文；覆盖预检 → 读取 → 引用 → 必要时再检索 → 关任务的固定流程，以及作用域、写入审批与夜间维护等规范。用户也可通过 skill 工具显式加载。

夜间维护¶

policy.maintenance.enabled: true 时，Host 内插件定时器在本地时间每天 03:00 巡检（错过则在下次启动补跑）。维护只写 <hub>/reports/ 报告并按策略生成 pending 提案，永不调用 memory_commit、不删不改正文。也可手动 memory_maintenance，apply: "report" 仅看报告。

安装与启用¶

插件以 profile bundle 形式发布，应通过 DSH 插件管理器安装 npm spec，而不是只做全局 npm install。

DSH 插件管理器（推荐）：

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

查看包内容：

npm pack dsh-memory-hub@0.1.5

DSH Desktop 用户应在设置里的插件管理器安装 dsh-memory-hub@0.1.5；Desktop 的 desktop profile 由 Electron 管理，不要用 CLI 改该 profile。

本地目录或 GitHub（仓库已含 dist/index.js 与 client.js，无需再构建）：

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

自托管插件市场索引（在 DSH 插件页开启实验性「自定义插件市场」后添加）：

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

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

配置要点¶

策略与工作区写在 <root>/config.yaml，修改后 watcher 热加载，无需重启。示例结构（字段含义见 README）：

version: 1
core_workspaces:
  - id: product
    name: '产品主仓库'
workspaces:
  - id: backend
    core_id: product
    root: 'D:/projects/backend'
    domains: [backend]
    admin: true
    enabled: true

policy:
  preflight:
    mode: per-turn
    pack_tokens: 600
    max_hits: 6
    min_score: 1.0
    local_boost: 1.2
    inject: compact
  gate:
    mode: enforce
    on_preflight_error: allow
    unknown_tools: allow
    mutating_tools: [bash, pwsh, write, edit, str_replace_editor]
  maintenance:
    enabled: true
    time: '03:00'
    apply: propose
    all_cores: true
    max_proposals: 10
    stale_pending_days: 30
    stale_citation_days: 90

只有当前会话工作目录落在某个 workspace.root 内时，才会获得 project:<id> 作用域；否则仅见 global/domain 知识。项目知识不会自动晋升到 global。

典型用法¶

1. 安装插件并配置 workspaces，把常用仓库 root 指到本机路径。
2. 正常对话：回合开始自动预检注入摘要；涉及历史决策时模型可 memory_get 读全文并 memory_cite 记用途。
3. 任务结束前调用 memory_close_task 做回写评估；值得保留的内容用 memory_propose 进 pending/，在 DSH 审批通过后 memory_commit 落盘。
4. 在侧边栏「记忆中枢」检索、过滤知识；待审批页只读浏览候选，批准仍在会话审批流中完成。
5. 项目管理员需要跨仓沉淀时，用 memory_consolidate 手动晋升；夜间维护或 memory_maintenance 生成报告与维护类 pending，由人决定是否提交。

工具一览：memory_search、memory_get、memory_status、memory_preflight、memory_cite、memory_propose、memory_commit、memory_close_task、memory_consolidate、memory_maintenance。

适用场景与注意¶

适合谁：希望在 DSH 内建立可检索、可追溯、可人工干预的项目记忆库；接受「文件即数据源」、无默认联网同步；愿意在写入路径上走 DSH 审批的开发者与团队。

安全与边界（README 摘要）：默认本地优先、无网络请求；路径经真实化与作用域校验；卸载插件保留全部记忆文件；V0.1 每个 Hub 根目录仅一个写者，第二个写者会使该根只读。插件以当前 DSH 进程权限运行，安装前请阅读源码与 MIT 许可证，确认 Hub 目录与 workspaces[].root 不会指向不应被 Agent 访问的路径。

已知限制（节选）：审批通过路径依赖交互式审批；未验证 PTC run_code 嵌套、外部 CLI、多进程共享 Hub；夜间维护依赖 Host 运行；多 core 维护串行，单 core 失败当天不重试；维护不出现在官方「自动化任务」栏。

结尾¶

dsh-memory-hub 把 DSH 的长期记忆落在用户可控的文件与审批流上，而不是黑盒上下文或不可审计的自动写入。目录与发现入口见 SkillHub 插件页；源码、文档与兼容说明见 GitHub 仓库。

• 目录页：https://www.skillhub.cn/plugins/zhiwuli0228/dsh-memory-hub
• GitHub：https://github.com/zhiwuli0228/dsh-memory-hub
• npm：https://www.npmjs.com/package/dsh-memory-hub