前言¶

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 社區目錄檢索。