前言¶

DSH 的组织方式强调「一切皆插件」。对使用 DSH 做智能体编排的人来说，一个实际问题是：会话之间没有稳定的长期记忆，上一轮里确认过的偏好、工作目录约定或任务规则，到了下一轮又要重新交代。

下面介绍 dsh-goodmemory。它是 hjqcan 维护的 DSH 插件，使用 GoodMemory 作为记忆后端，在 DSH 模型步骤前召回相关记忆，并在成功回合后写回已完成的人/助手对话。

这是什么¶

一句话定位：dsh-goodmemory 为 DeepSeek Harness 提供 automatic, durable, cross-session memory，后端是 GoodMemory。

它解决的是 DSH 会话上下文跨会话延续的问题：插件在模型调用前把相关记忆作为可识别的 DSH user/message 放进上下文，在回合成功后把选定文本写回 GoodMemory。这样模型可见上下文仍可从 DSH session log 重建，同时不同会话可以共享长期记忆。

插件不复制 DSH JSONL 日志，也不创建第二套记忆 schema；它只把选定文本发给 GoodMemory，GoodMemory 仍是记忆和存储的单一事实来源。许可证为 MIT。

核心功能¶

1、自动记忆读写：在 DSH 模型步骤前召回相关记忆；在一个 DSH 回合成功完成后写回已完成的人/助手交换。

2、可控召回条件：召回只在最终的 agent/pre-step batch 包含 direct user text 时运行；仅工具调用、插件注入上下文等不会触发另一轮查找。

3、限定写回内容：写回包含 direct user text 和 final assistant text；排除 tool calls/results、reasoning、images、recalled memory 和 injected context。

4、保持上下文可追溯：召回进来的上下文是一个被识别的 DSH user/message，因此模型可见上下文仍可从 session log 重建。

5、两种运行模式：
- managed 模式：默认模式，启动 goodmemory-http-bridge sidecar，在随机 loopback 端口工作，使用内存 bearer token，并将 SQLite 数据放在 $DSH_HOME/goodmemory/memory.sqlite。
- external 模式：连接已有的 GoodMemory HTTP bridge；激活时会验证 health、精确的 phase-39.http-memory.v1 contract，以及 authenticated recall。

6、失败处理：runtime 的 recall/writeback 失败会记录日志，DSH 回合继续；startup 失败仍然 fatal。

7、首版范围：0.1.1 版本不增加 model tools、MCP server、DSH command 或管理 UI。

安装与启用¶

先确认版本。dsh-goodmemory@0.1.1 支持如下组合：

DSH 仍是 RC。dsh-goodmemory 固定 DSH peers；新的 DSH RC 在集成测试通过前不支持。

从 npm 安装并启用 web profile：

dsh plugin --profile web add dsh-goodmemory@0.1.1
dsh --profile web --dump-config
dsh --profile web

第一条安装插件，第二条查看合并后的配置，第三条启动 web 组合。

如果要使用 headless 组合，将上面的 web 替换为 headless：

dsh plugin --profile headless add dsh-goodmemory@0.1.1
dsh --profile headless

本地源码安装：

pnpm install
pnpm pack
dsh plugin --profile web add ./dsh-goodmemory-0.1.1.tgz

经过上面的步骤后，插件 bundle 会插入一个 goodmemory row；后续 profile、home 或 CLI patch 层可以替换它的完整配置。

Managed mode¶

Managed mode 是默认模式。它会启动已发布的 goodmemory-http-bridge，在随机 loopback 端口上运行，创建 in-memory bearer token，启用 recommended retrieval preset，并把 SQLite 数据写到：

$DSH_HOME/goodmemory/memory.sqlite

使用前先安装 Bun。若 Bun 可执行文件不在默认位置，可以用 GOODMEMORY_BUN_BINARY 指定：

export GOODMEMORY_BUN_BINARY=/path/to/bun

如果要改数据库路径，可在 profile 的 cordis.patch.yml 中覆盖 goodmemory row：

- id: goodmemory
  name: dsh-goodmemory
  config:
    mode: managed
    databasePath: /absolute/path/to/memory.sqlite

在正常 HMR 或进程退出时，插件会等待进行中的 writeback，然后终止 managed sidecar。如果 sidecar 在激活后崩溃，插件不会自动重启它；DSH 会记录失败并继续运行，直到插件重新加载。

External mode¶

External mode 连接已有的 GoodMemory HTTP bridge。token 放在环境变量中，不放在 DSH config 里：

export GOODMEMORY_HTTP_BRIDGE_TOKEN='replace-with-a-secret'
goodmemory-http-bridge --recommended

在 cordis.patch.yml 中配置 external：

- id: goodmemory
  name: dsh-goodmemory
  config:
    mode: external
    baseUrl: http://127.0.0.1:8739
    tokenEnv: GOODMEMORY_HTTP_BRIDGE_TOKEN

激活时会验证 health、精确的 phase-39.http-memory.v1 contract，以及 authenticated recall。配置无效、缺少 token、授权失败或 contract 不匹配都会导致插件激活失败。

Scope 与记忆边界¶

默认 scope 是 DSH-isolated。GoodMemory 的 durable scope 会排除 sessionId，因此相同 user/workspace/agent scope 下的不同 DSH 会话可以共享长期记忆。

如果你需要和另一个 GoodMemory host 共享记忆，需要显式配置相同的 userId、workspaceId 和 agentId；当另一侧省略可空的 workspace 或 agent 字段时，把对应字段设为 null。

管理入口¶

首版不引入 model tools、MCP server、DSH command 或管理 UI。健康检查、review、revision、export、forgetting 等管理动作继续使用 GoodMemory 的 CLI 和 Inspector：

goodmemory inspector serve

适用场景与注意¶

适合以下情况：

• 你在使用 DSH 组合智能体流程，并希望跨会话保留长期记忆。
• 你愿意用 GoodMemory 作为记忆后端，并需要 managed sidecar 或 external bridge 两种接入方式。
• 你希望模型可见上下文仍可从 DSH session log 重建。

需要注意：

• DSH 是 RC，dsh-goodmemory 固定 DSH peers，新的 DSH RC 需要等待集成测试通过。
• 插件以当前 DSH 进程权限运行；安装前应检查源码、依赖和 MIT 许可证。
• runtime recall/writeback 失败会记录并让 DSH 回合继续；startup 失败仍然 fatal。
• managed sidecar 崩溃后不会自动重启，需要重新加载插件。
• external mode 的 token 应保留在环境变量中，例如 GOODMEMORY_HTTP_BRIDGE_TOKEN。
• 首版不提供额外模型工具、MCP server、DSH command 或管理 UI。

结尾¶

dsh-goodmemory 的价值在于把 GoodMemory 接进 DSH 的模型步骤：pre-step 前召回相关记忆，成功回合后写回选定文本，同时保持 DSH 会话日志可重建。

GitHub：https://github.com/hjqcan/dsh-goodmemory

目录页：本文材料未提供可核实 URL，可按插件名 dsh-goodmemory 在 DSH 社区目录检索。