DSH 开发中，决策、约束、偏好和项目事实往往被困在 Session 当中。手动复制这些信息既繁琐又容易出错，而 unrestricted global memory（不受限制的全局记忆池）又可能引入无关上下文或隐私风险。dsh-memory-spaces 旨在解决这一矛盾，它提供了一种替代方案：用户自治的本地记忆空间。
下面介绍这个插件的核心逻辑与使用方法。
它是什么¶
dsh-memory-spaces 是一个独立社区插件（MIT 协议），由用户 icearia0219 维护。它位于插件生态的“记忆”分类中，核心价值在于：让用户显式地选择哪些 Session 产生内容，哪些 Session 可以读取内容。
插件不将所有对话纳入一个自动读写开关，而是将记忆管理权交给用户。它维护一个本地 SQLite 数据库，提供持久化、可检查的记忆存储，且默认是私有的。
核心功能¶
该插件主要包含以下能力：
- 用户自治的本地记忆空间：记忆属于本地，由用户定义和管理。
- 持久化与可检查性：提供不依赖全局池的持久化记忆，且支持查看历史。
- 显式分享：明确指定哪些 Session 是“源”（贡献者）或“消费者”（使用者）。
- 可预览与版本化：记忆支持版本回溯，且在使用前可预览。
- 来源可追溯：支持 provenance-aware（来源感知）的 recall（检索）。
- 默认私有：Session 默认无法读取任何空间记忆，直到用户显式连接。
- 独立的源/消费者关系：一个 Session 可以既是源又是消费者，也可以只是其中之一。拥有关系并不意味着历史或未来对话的自动复制。
- 人工治理：空间创建、关系变更、生命周期决策等操作必须由用户在 UI 中执行，插件不会将这些作为模型工具暴露。
- 发送前审核：在 composer 中自动匹配的记忆可以被用户检查或抑制。
- 本地 SQLite 存储所有权：数据存储在本地，不依赖远程同步。
安装与启用¶
安装前请确认 DSH 版本。该插件兼容 DSH aggregate releases >=0.1.5-rc.3 <0.2.0。
在 Web Profile 下安装指定版本：
dsh plugin --profile web add dsh-memory-spaces@0.1.1
安装完成后，重启 dsh web 即可启用。
典型用法¶
使用流程分为三个阶段：创建与保存、建立连接、使用与审核。
-
创建与保存
打开一个 Session，在 UI 中选择 Memory spaces。创建一个新的空间，然后显式地选择该 Session 中需要保存的消息。这一步完成了“源”的建立。 -
建立连接
将另一个本地 Session 连接为该空间的“消费者”。此时该 Session 获得了读取该空间记忆的权限，但并不自动拥有写入权。 -
使用与审核
在消费者 Session 中发送与记忆相关的 Prompt。在发送前，检查 composer 中的候选记忆。如果不需要某些记忆，可以将其抑制或修改后再发送。
适用场景与注意事项¶
适用场景：
* 需要在多个 Session 间共享特定上下文，但不想污染全局上下文的开发者。
* 需要对注入给模型的记忆进行严格审查的场景。
* 需要管理项目历史事实、决策约束的开发者。
注意事项：
* 非模型工具：关系变更和破坏性治理操作（如删除、清除来源）不会暴露为模型工具，必须由用户直接操作。
* 不可信输入：存储的记忆被视为不可信输入。插件虽然提供预览和审核，但无法保证对 prompt injection 的完全防御。
* 本地存储风险：Profile-local SQLite 数据库未加密。如果进程拥有文件系统或 shell 访问权限，可以修改数据库。
* 无远程同步：插件不支持远程邀请或跨实例同步。
* 敏感内容警告：在存储对话、历史摘要或快照前，会出现敏感内容警告。
总结¶
dsh-memory-spaces 通过将记忆管理从“自动全局”转变为“显式本地”，让开发者对 DeepSeek Harness 的上下文流拥有了更精细的控制权。它适合那些希望在不牺牲安全性和可控性的前提下，在多个对话间复用知识库的用户。
