Mneme Memory

dsh-mneme

🌏 简体中文 · English

---

🧬 给 LLM 装上会自我进化的记忆

dsh-mneme 是 DeepSeek Harness (DSH) 的跨会话记忆插件。它不只「存得下」，更「管得好」：后台自动去重合并、矛盾先冻结等你裁决、全程可回放审计、记忆只落在本机，还支持导出成人可读的 Markdown。

Mneme（Μνήμη）源自希腊记忆女神 Mnemosyne。她掌管记忆与梦境——正如 autoDream 在后台默默巩固你的记忆库。

📰 最近更新

日期	版本	头条
2026-10-21	v0.9.4	三条链各自补上「最后一环」 — 这一版的三件事同一种形状：东西早就造好了，只差没人能叫它。① agent 主动整理（#231）：引擎在 v0.8 就落在 src/organize.js（先 dryRun 出比对报告 → agent 判断 → apply 落库，筛除只归档不删，全程复用 dream_runs 回执），可它没有任何调用入口——工具表里没有它、两张 API 脸 0 命中、全仓 .organize( 零调用点，只有测试能调到。现在它有工具了：memory_organize，organizeEnabled 默认关（关 = 工具根本不注册，模型看不到就不会调）。② 画像能被反向提取了（#497）：面板「用户画像」加一个按钮，读活跃记忆、花一次宿主模型调用，产一段「助手眼中的用户」草稿——只出草稿：采用是你在面板上再点一次，你手写的原文不会被模型改写；空库和模型不配合都直接报错，绝不回一张空草稿冒充「这次没提炼出东西」（profileExtractEnabled 默认关）。③ 人格不再无条件进别人的会话：default 卡以前会落给所有没建卡的身份，于是宿主里自带身份的外部 bot 每一帧都收到两句「你是谁」撞在一起，而界面上「关掉这张卡」实际不生效——新增 personaStrictAddressing（默认关，历史行为逐字节不变）把「身份没建卡」与「卡被显式关掉」都收回到不注入。同版补上蒸馏的转录围栏 + 解析失败护栏（#494：一条会话被同一个窗口卡死、重试 20 次越试越贵的根因；失败行现在恒带原始输出形状，事后能回答「模型到底吐了什么」），并把面板里那段自称「注入生效文本」的只读区改成由后端渲染——它以前既没有人格三行也没有表头和前缀，标题却承诺了模型实际看到的东西。
2026-10-20	v0.9.3	M.O. 从「挖得出来」跑到「会被叫去挖」 — 沉淀链的算法自 v0.9.1 起就写完了（多帧 zstd → 重复序列 → 缺席对照 → draft 草稿），可它在运行时没有任何调用点：全仓引用只出现在测试里。机器挖得出来、却永远不会被叫去挖——缺的从来不是算法，是归属与触发。这一版把三处接上：按会话头里的 cwd 反查项目桶（桶名是路径的有损变形，规则不在本仓，查不到就整跑跳过，而不是降级成全局普查——后者会把 A 项目的动作算到 B 头上，且结果看起来完全正常）；新增 nudgeForProject 把「归属 → 挖掘 → 落盘」收成一个入口；挂 turn/end 按项目跑，冷却 10 分钟、单次预算 4 秒、延到宏任务、一次一个项目、抛错只 warn。它只产提议，不产草稿（#489）：升格仍然要人批，面板也多了「现在沉淀一次」，与自动跑同一条入口、区别只有不改仓库。同版修掉三处「坏了却不报」：作用域反查自 v0.8.0 起每次都抛错走降级、canonical 归一与成员校验静默失效（#487）；/nudge 的写盘口只拦 PUT/POST，带 token 的 PATCH/DELETE 会静默写盘、归属解析不看预算、桶名边收边截把「没看全」报成「确实没有」；多帧 zstd 的反证断言绑了 Node 的整块解语义，24.22.0 起过期（#490）。
2026-10-19	v0.9.2	让「看不见的失败」显形 — 这一版修的大多不是「缺功能」，是「坏了却不报」：功能开关一直是启动期生效，面板「已改」只说明值进了库，于是新增第三态「待重启」（#481）；巩固的 dreamMaxTokens 默认值被原样当 max_tokens 发出去，撞上服务商上限后 180 次巩固 0 次成功，现在面板能改、超上限还会按服务商自己声明的上限自动降级（#478）；自动蒸馏写入的行 100% 拿不到向量，注释承诺的「提交后补跑」从未存在（#477）；CLI 把 -- 开头的值当成新旗标——这个缺陷只在 token 前两位恰好掷中 -（约 1/4096）时现形，潜伏了整整一个发布周期。另新增作用域级可逆闸门（#471，默认关）：让一路记忆能被单独按下与松开，不改配置、不重启。

只记大改动，逐条细节见 CHANGELOG。

它解决什么问题

每次新开对话，AI 都像第一次认识你？

dsh-mneme 给 DeepSeek Harness 装上跨会话记忆。 你聊过的项目、提过的偏好、做过的决定，AI 都记得——即使关掉了窗口，下次打开还在。

场景	没装插件	装了插件
周一聊完项目需求，周三继续	"能再描述一下你的项目吗？"	"你指的是上周提到的博客重构吗？当时你说想用 Astro。"
告诉 AI 你的编码习惯	每轮都要重复交代	一次设定，长期生效
整理大量资料后关窗口	资料丢了	自动归档，随时检索找回

但 dsh-mneme 的可信之处，恰恰在你看不见的后台。下面这些，才是它和「一个会存东西的插件」的本质区别。

为什么可以信任它

• 🧾 可回放、可追责 — 每次自动整理都留一张「决策凭证」：输入快照 + 决策明细 + 结果哈希，同样的整理可复现回放，不默默吞错、不留无法追溯的改动。
• ⚖️ 矛盾先冻结，等你裁决（可关）— 两条记忆打架时，不擅自替你做主。可疑冲突会挂起待审，状态页冲突队列里并排对比、一键裁决（保留 A / 保留 B / 仅标记），确认后才生效。复杂判断，人永远在线。
• 🔐 记忆按 agent 与工作区隔离（可关）— scopeEnabled 开启后，每条记忆标注由哪个 agent、在哪个工作区写入；检索时本会话作用域优先（命中加权，他 scope 降权仍可见）；strictScope 再进一步——显式声明收窄到他者作用域的记忆在检索/注入里完全不可见（载体自动标注只降权，不硬挡）。多 Agent、多项目互不串台。
• 🌙 夜深人静才动手（可关）— 空闲时自动分层归档：常看的留在热区、久不用的压成摘要、陈旧的彻底归档。记忆库越用越精炼，不膨胀。
• 🧠 语义检索可以完全离线 — 把 embedProvider 设为 local 后检索走本地 Embedding 与精排，不需要 API Key；没配嵌入时关键词 / BM25 检索照样能用。
• 📝 Markdown 双向同步 — 记忆就是本地 .md 文件，随时打开编辑；人工改动会被优先尊重，不会被机器覆盖。
• 💾 删对话 ≠ 删记忆 — 记忆是跨会话的全局知识，清空聊天窗口，已保存的记忆仍在（v0.7.11 起不再与会话绑定）。

它和 Zep / Mem0 / Letta / Hindsight 比呢？ 有一张逐项对照表——存储底座、检索、写入时抽取、离线巩固、冲突处理、遗忘、作用域、可审计性、多宿主、离线、许可证共 11 行，「—」不等于「差」：能力对比。

5 分钟上手

# 安装插件（最省事的一条：npm 包名）
dsh plugin --profile web add @modusensus/dsh-mneme
dsh web

4 種類のインストール元

DSH の 設定 → プラグイン → Add plugin と dsh plugin add では、4 種類の指定方法を利用できます。入力したものがそのままインストールされます。このリポジトリはモノレポです。リポジトリルートにある package.json はリポジトリの外殻にすぎず（private で、dsh フィールドはありません）、実際にインストールできるプラグイン本体は dsh-mneme/ にあります。そのため、Git または tarball を使う場合はサブディレクトリを指定する必要があります。指定しないと外殻がインストールされてしまいます。

インストールできない外殻を、なぜリポジトリルートに置いているのでしょうか？ dshfind のプラグイン検出など、一部のモノレポ検出ツールはリポジトリルートのマニフェストだけを認識します。マニフェストがないと、このリポジトリは「インストールできないプラグインパッケージ」と判定されますが、この判定は実際にインストールできるかどうかとは関係ありません。ルートのマニフェストを private、0.0.0 にし、dsh フィールドを付けていないのは、こうしたツールがサブパッケージを見つけられるようにしつつ、プラグイン本体としてインストールまたは公開されることを確実に防ぐためです。

インストール元	入力するもの	備考
npm パッケージ名	@modusensus/dsh-mneme	推奨。バージョン @0.9.0 を指定することもできます
Git リポジトリ	git+https://github.com/slow-stack/mneme.git#path:/dsh-mneme	#path: は省略できません。省略するとリポジトリルートにある外殻（0.0.0、dsh フィールドなし）がインストールされ、ホストはプラグインとして認識しません
tarball	C:\\path\\to\\modusensus-dsh-mneme-0.9.0.tgz	dsh-mneme/ 内で npm pack を実行して作成します。pnpm pack は bin スクリプトの CRLF が原因で失敗します
ローカルディレクトリ	C:\\path\\to\\mneme\\dsh-mneme	絶対パスである必要があります。相対パスはホストによって直接拒否されます（a local path must be absolute）

# 从源码装（本地目录，改完代码重启即生效）
git clone https://github.com/slow-stack/mneme.git
dsh plugin --profile web add "$(pwd)/mneme/dsh-mneme"

# 或者直接从 Git 装（不落源码，适合只要个能跑的版本）
dsh plugin --profile web add 'git+https://github.com/slow-stack/mneme.git#path:/dsh-mneme'

パネルの「Install guide and examples」には、パッケージ名を使う方法しか載っていません。上記の 4 種類はいずれも実際に動作確認済みです。Git と tarball を使う場合、インストール時にホストがリポジトリへの到達性を確認します（タイムアウトの既定値は 5 秒です）。

インストール後、すぐに利用できます。5 分以内に効果を確かめるには、次の手順をお試しください。

1. 話す：新しい会話を開き、自分の好みや進行中のプロジェクトについて AI と少し話します（例：「コードを書くときは 4 スペースのインデントが好みです」）。
2. 待つ：ウィンドウを閉じて、新しい会話を開きます。さっきのことを覚えていれば、記憶が書き込まれています。
3. 調整する：「設定 → 記憶庫の設定」で、必要に応じて以下の 3 つのスイッチをオンにします（「クイック設定」を参照）。

クイック設定（任意）

要件	設定項目	既定値	変更方法
完全オフラインで実行	embedProvider	openai	local に変更
バックグラウンドで記憶を自動整理	autoDream	true	false に変更すると無効になります
構造化エンティティの自動抽出	entityExtractionEnabled	false	true に変更
複数の Agent／プロジェクト間で記憶を分離	scopeEnabled（より強い分離が必要な場合は strictScope も追加します。強制分離は明示的に宣言した場合にのみ有効です）	false	true に変更

これらはすべて DSH の設定パネル → 記憶庫の設定で変更できます。すべての設定については設定の章を参照してください。

記憶庫の配置先に関する推奨事項

記憶庫の既定の保存先は ~/.dsh/memory で、ホストのプロファイルのスコープ外です。ただし、実際の保存先は memoryDir の設定で決まります。プロファイルのスコープ内（…/profiles/<名字>/… の形式）を指定すると、ホストがプロファイルを削除または移行する際に、記憶庫も一緒に移動されます（#218 の最終コメントに記録された実際の事故です）。プラグインは起動時にこのような保存先を検出すると警告を出します。通知するだけで、記憶庫は移動しません。安全に運用するには、memoryDir をプロファイルのスコープ外にしてください（既定値のままで構いません）。記憶庫を移行する場合は、書き込みを停止 → ディレクトリ全体をコピー → 設定を変更して新しい場所を指定 → 再起動、の順に行います。

記憶の循環を図で理解する

  写入 ──► 质量过滤（无用信息先拦下）
    │
    ▼
  SQLite + 本地 Markdown 镜像
    │（空闲时）
    ├─ autoDream ：去重 / 合并 / 归档 / 修正 / 冲突冻结
    └─ Sleep Mode ：分层压缩 + 模式发现 + 关系补全（可关）
    │
    ▼
  召回（混合检索 + 精排）──► 注入会话上下文

🧭 M.O.：「どう実行するか」もリポジトリに置く（v0.9 beta）

記憶庫にはなぜそうするのかを記憶できますが、実際にどう進めるのかは記憶できません。ワークフローをどこに置くかによって、変更できるかどうかが決まります。記憶庫に置けば差分のない一行の文章にすぎず、セッションに置けば一度きりのプロンプトになり、人の頭の中に置けば変更できず、記録にも残りません。

そこで v0.9 では、ワークフローをプロジェクトリポジトリに移し、1 つのワークフローを 1 つのファイルで管理します。

<项目>/.mneme/pipelines/<id>.json     ← 项目层（能提交、能 diff、能 PR、能被 CI 读）
<插件包>/pipelines/<id>.json          ← 全局层（兜底，今天包里没有这个目录，这是有意的）

役割分担は一言で言えます。記憶は「なぜ」、リポジトリは「どう実行するか」、図は「どのように見えるか」です。

• レールではなくガードレール — 図には、正当な逃げ道を必ず 1 つ残す必要があります。エージェントが今回この手順は適切でないと判断した場合、リスクレベルに応じて「記録して先に進む」か「立ち止まって人に尋ねる」かを決めます。スキップ＝今回はこのステップを使わない（3 回以上提案されたら、このステップの削除を提案します）。迂回＝この経路全体が適切でない（3 回以上提案されたら、この経路の見直しを提案します）。2 つの指標は別々に数えます。混同すると、どちらの提案も出せなくなります。
• 候補はリポジトリに入れない — 下書きは <memoryDir>/candidates/<项目键>/ に保存され、ローカルにのみ置かれます。1 日に 10 件できて 9 件が失敗するようなものをリポジトリに入れれば、ゴミになってしまいます。昇格には「2 回実行したこと（少なくとも 1 回は成功）」かつ「反実仮想を書けること」が必要です。条件を満たすと、システムは提案のみを行います。コミットとプッシュの決定権は、常に人が握っています。
• パネルに表示される図と、エージェントが読む図は同じデータを使う — 図だけを描いても保存しなければ、エージェントは何も読み取れません。ノードの状態（refuted / trusted / stale / candidate）はすべて実行記録から導き出され、作者が固定するものではありません。現在は実行記録の保存先がまだないため、全ノードが常に candidate になります。だからこそ、beta というラベルを目立つように表示する必要があります。

既定ではオフです（actionPipelineEnabled）。設計上のトレードオフと実際に遭遇した問題については、docs/WORKFLOWS.mdを参照してください。

インターフェイスのプレビュー

パネルは中国語と英語に対応しており、DSH のインターフェイス言語に合わせて表示されます。以下は中国語のスクリーンショットです。英語版は末尾のEnglishセクションをご覧ください。

記憶を記録、閲覧、絞り込みます。

記憶からエンティティを自動抽出し、属性付きの関係グラフを作成します。

ステータスパネルで、ベクトルインデックス、LLM の使用量、自動統合の記録をひと目で確認できます。

検索、エンティティ抽出、記憶の統合に関するスイッチを、設定画面でまとめて管理できます。

任意の書き込み保護トークンとローカライズされたフィードバックチャネルにより、記憶庫を完全にローカルで監査可能な状態に保ちます。

プライバシーへの取り組み

• 記憶はローカルにのみ保存されます。SQLite ストレージと、手動で編集できる Markdown ミラーを使用し、mneme のサーバーを経由しません。
• 記憶は Markdown ファイルなので、人が読んで手動で編集できます。
• mneme 独自の API Key は不要です。統合と要約には、設定済みのホストモデルを使用します（autoDream / autoSummarize は既定で有効です）。
• 統合も完全にオフラインで行いたい場合は、ホストをローカルモデルに切り替えます（dreamProvider / dreamModel と summarizeProvider / summarizeModel を空にしてください。これら 2 組を設定するとホストを経由せず直接接続するため、ホストを切り替えても反映されません）。または、autoDream / autoSummarize を無効にします。
• テレメトリ、分析、リモートログはありません。

用在其他 AI 工具里（MCP）

插件自带零依赖 stdio MCP server（独立 npm 包 mneme-memory，bin 名 mneme-mcp），任何 MCP 客户端都能挂载记忆六件套（memory_save / memory_search / memory_list / memory_get / memory_update / memory_delete）。

前置条件（一次性）：

1. DSH 在运行且插件已安装（MCP 数据面走插件的独立 API 127.0.0.1:8790）
2. 在 DSH 面板「设置 → 外部访问 API」生成 token

各客户端挂载（<你的token> 替换为上一步生成的值）：

客户端	挂载方式
Claude Code	项目根 .mcp.json：{"mcpServers": {"mneme-memory": {"command": "mneme-mcp", "env": {"MNEME_TOKEN": "<你的token>"}}}}
Cursor	设置 → MCP → Add Server，command 填 mneme-mcp，env 加 MNEME_TOKEN
Codex	~/.codex/config.toml：[mcp_servers.mneme-memory] 段，command = "mneme-mcp"，env = { MNEME_TOKEN = "<你的token>" }
Hermes	~/.hermes/config.yaml 的 mcp_servers: 段：mneme-memory: {command: "mneme-mcp", env: {MNEME_TOKEN: "<你的token>"}}，重启生效
OpenCode	opencode.json：{"mcp": {"mneme-memory": {"type": "local", "command": ["mneme-mcp"], "environment": {"MNEME_TOKEN": "<你的token>"}}}}
OpenClaw	openclaw mcp add mneme-memory --command mneme-mcp --env MNEME_TOKEN=<你的token>，或 Control UI → Settings → MCP

旧挂载兼容：已部署的 dsh-mneme-mcp + DSH_MNEME_TOKEN 写法继续有效（bin 与 env 变量均保留，无需迁移）。未全局安装 npm 包时，把 command 换成 npx 并追加参数 -p mneme-memory mneme-mcp（Claude Code/OpenCode 写进 args 数组，Codex 写 args = ["-p", "mneme-memory", "mneme-mcp"]）。配置细节与安全注意事项见完整文档。

不开 DSH 也能服务（独立服务 daemon）

dsh-mneme-serve 把记忆库跑成常驻数据面——DSH 关着，第三方集成（网页端桥接、脚本、自有面板）照样读写同一份记忆：token 与 DSH 面板/CLI 共用，路由与「外部访问 API」同源，端口被占直接报错（与 DSH 外部访问二选一）。第一期无 LLM（巩固/蒸馏仍属 DSH 宿主）；检索默认 local 嵌入（首次启动自动取件模型，--embed off 可关）。

npm i -g @modusensus/dsh-mneme
dsh-mneme-serve          # 默认 ~/.dsh/memory + 127.0.0.1:8790

社区适配器

社区项目把 mneme 接入更多平台——它们不是本仓库的一部分，兼容性由各自维护者跟进：

项目	平台	说明
Mneme-Bridge	DeepSeek 网页端	浏览器扩展 + 本地服务：网页端会话蒸馏进 mneme 记忆库、DSH 侧记忆按话题回注，两侧共享同一份记忆。embedded（挂载 lib）与 remote（standalone API，不开 DSH 时配合上面的 daemon）双模式

想被收录？在 Discussions 开帖介绍你的项目，或直接提 PR 补充本表。

文档

文档	路径
插件完整文档（功能 / 安装 / 配置 / 架构）	dsh-mneme/README.md
stdio MCP server——Claude Code / Cursor 等任意 MCP 客户端接入记忆六件套	dsh-mneme/README.md · MCP Server
独立服务 daemon（不开 DSH 常驻数据面）	dsh-mneme/docs/DAEMON.md
配置说明（全键参考）	dsh-mneme/docs/CONFIGURATION.md
蒸馏原文留存与记忆级溯源（#399）	dsh-mneme/docs/DISTILL.md
实体结构化设计	dsh-mneme/docs/ENTITIES.md
工作流（M.O.）：本体住仓库、证据住记忆库	dsh-mneme/docs/WORKFLOWS.md
语义架构	dsh-mneme/docs/SEMANTIC.md
本地模型部署指南	dsh-mneme/docs/LOCAL_MODEL.md
与 Zep / Mem0 / Letta / Hindsight 的能力对比	docs/COMPARISON.md
版本历史	dsh-mneme/CHANGELOG.md
安全策略	SECURITY.md

🗺️ ロードマップ

🧬 记忆基因 → 🛡️ 审计加固 → 💤 睡眠维护 → 🕸️ 召回融合与图谱 → ✨ 面板增强 → 🌡️ 自进化记忆 → 🔐 作用域隔离 → 🌐 生态（MCP / daemon）→ 🧭 M.O.（项目级工作流）

バージョン	テーマ	状態
v0.3	記憶の遺伝子：エンティティ／属性（タイムライン付き）／関係	✅
v0.4	Sleep Mode：アイドル時の4段階ディープメンテナンス	✅
v0.5	想起の融合と記憶の可視化：BM25 + グラフ + ホットメモリ	✅
v0.6	セッションのライフサイクル：会話の削除 ≠ 記憶の削除	✅
v0.7	自己進化する記憶：熱度の減衰 + スリープ時の二重保護 + デスクトップワークベンチ／機能フラグ	✅
v0.8	スコープの分離（agent/workspace の二重分離 + 検索の重み付け + opt-in のハードフィルター）+ 競合キューの人手による裁定 + 所属の明示的な宣言 + エコシステム化（stdio MCP server／グラフ想起軸／コールドスタート／注入の切り捨てとステータスバー／蒸留の信頼性／注入形式と agent による自発的な整理インターフェース／設定の説明と issue テンプレート）	✅ リリース済み（v0.8.16 まで）
v0.9	M.O.（Modus Operandi）beta：プロジェクト単位のワークフローオントロジー + 候補の階層化と昇格基準 + パネル一覧／グラフの同時表示；設定パネルの折りたたみ境界を「初心者向け以外」に合わせて再設定（#427）；セキュリティ監査とサプライチェーンの強化（宣言的ルーティング認可、OSV によるブロック、リリース署名）；v0.9.1 で書き込み側を追加：実行ウィンドウ、実行ログ、所属候補、観察の並行記録と乖離検出、ステップの assert/optional、定着チェーンのドラフト抽出、人格定義ページ（agent ごとの複数カード）；v0.9.2 で見えない失敗を可視化：機能フラグの第3状態「再起動待ち」、スコープ単位の可逆ゲート（#471）、強化処理で max_tokens が上限を超えた場合の自動ダウングレード（#478）；v0.9.3 で自動定着を接続：セッションヘッダーの cwd からプロジェクトバケットを逆引きし、turn/end にフック、クールダウン10分、1回あたりの予算は4秒で、提案のみを生成しドラフトは生成しない（#489）。さらに、v0.8.0 以降にスコープの逆引きが無言でダウングレードしていた問題（#487）、/nudge の書き込み側で PATCH/DELETE のブロックが漏れていた問題、複数フレームの zstd による反証アサーションが Node 全体の意味解析に結び付いていた問題（#490）も修正；v0.9.4 で3つのチェーンの最後のピースを追加：agent による自発的な整理インターフェースにツールを追加（memory_organize、organizeEnabled はデフォルトでオフ。オフの場合、モデルにはこのツールが表示されません）、記憶からプロファイルのドラフトを抽出可能に（profileExtractEnabled はデフォルトでオフ。ドラフトのみを生成し、採用するにはユーザーがもう一度クリックする必要があります。手書きの原文はモデルによって書き換えられません）、人格の default カードが無条件に「カード未作成」のアイデンティティに入らないよう変更（#497、personaStrictAddressing はデフォルトでオフ）。パネルの「注入される有効テキスト」はバックエンドが単一のソースとしてレンダリングするよう変更し、蒸留トランスクリプトの囲みと解析失敗時のガードレールも追加（#494）	✅ リリース済み（v0.9.4）

各マイナーバージョンの詳細な説明は CHANGELOG をご覧ください。

🧪 ローカル開発

cd dsh-mneme && npm install
npm test        # 2302 个测试
npm run stress  # 三轴线压测
npm run sync    # src → lib 同步

---

🙏 謝辞

autoDream の理念の出典（理念を参考にし、実装は独自に行っています）：

• Claude Code の Auto Dream（Anthropic、Memory 2.0）：理念の源流です。セッションの合間にバックグラウンドのサブエージェントが記憶ファイルを整理します（重複の削除、矛盾の修正、減衰した記憶の整理）。
• Sleep-time Compute: Beyond Inference Scaling at Test-time（UC Berkeley & Letta、arXiv:2504.13171）：Auto Dream の「オフライン強化」という発想の背景にある学術的な流れです。
• cc-haha：初期の実装アイデアの参考の一つです。

上記の取り組みを踏まえ、dsh-mneme は独自のエンジニアリングを発展させました。K-Means++ によるクラスタリングの事前グループ化、型付きの判断リスト（keep / merge / archive / conflict / update、および sleep 側の supersede / differentiate）、再生可能な sha256 要約監査チェーン（dream_runs / receipt_chain）を実装しています。記載漏れのある着想元があれば、issue でお知らせください。

📚 関連研究

dsh-mneme のメカニズム設計は、以下の公開研究と相互に裏付け合っています（引用はすべて arXiv の収録ページと照合済みです。メカニズムとの対応付けは私たち独自のものであり、原論文の主張ではありません）：

• オンライン書き込み + オフライン強化：Dual-Layer Agentic Memory with Fast Write Routing and Slow Consolidation（arXiv:2608.22215）——autoDream の「高速書き込みと低速強化」の役割分担と同型です。
• 熱度の減衰とアクセスによる強化：FadeMem（arXiv:2601.18642）——heat による記憶の熱度モデル（指数減衰 × アクセスによる強化 × 重要度による調整）に学術的に近い研究です。
• 競合の裁定と状態の追跡：StateMemBench（arXiv:2608.19652）——記憶システムが進化状態を追跡するための試験です。C1 の競合裁定（supersede 後に古い値を再引用しない）は、これを受け入れ基準としています。
• 忘却すべきタイミング／scope のゲーティング：PersistBench（arXiv:2602.01146）；表示レイヤーでの緩和策は Structured Memory（arXiv:2608.08300）を参照——scope の意味領域ゲーティングに関する問題の出典と、契約を変更しない修正方法です。
• 分野の全体像：Write–Manage–Read サーベイ（arXiv:2603.07670）——「書き込み／管理／読み取り」の3段階とプラグイン全体の構成を相互に裏付けています。
• 数か月規模の信頼性エンジニアリング：Memory as Infrastructure（arXiv:2609.05510）——sha256 監査チェーンやフェイルセーフなダウングレードと同様に、「記憶をインフラとして扱う」アプローチに属します。
• 関連システム（比較対象）：Zep（時系列ナレッジグラフ）、Mem0（本番向け抽出型メモリ）、Hindsight（retain / recall / reflect の3操作）は、「書き込み時の LLM による抽出 + ベクトル／グラフ検索」というアプローチを採用しています。dsh-mneme の違いは、強化には LLM が関与するものの、生成物はすべての過程で記録され再生可能であり、競合は凍結して人手による確認を待ち、記憶はローカルマシンにのみ保存される点です。

🧬 進化する記憶を LLM に

dsh-mneme は、DeepSeek Harness (DSH) 用のセッション横断型メモリプラグインです。記憶をただ 保存 するだけでなく、管理 します。バックグラウンドで重複を削除して統合し、競合は確認のために凍結し、完全に再生可能な監査証跡を残します。記憶はお使いのマシンに保管され、人が読める Markdown にエクスポートできます。

Mneme（Μνήμη）は、記憶と夢を司るギリシャの女神 Mnemosyne に由来します。autoDream がバックグラウンドで静かに記憶ストアを強化するように。

📰 最近の更新

日付	バージョン	見出し
2026-10-21	v0.9.4	3つの連鎖に、それぞれ欠けていた最後のリンクが加わりました — 今回のリリースに含まれる3つの項目には共通点があります。機能はすでに実装されていたのに、呼び出す手段がありませんでした。① エージェント主導の整理 (#231)：エンジンはv0.8の時点でsrc/organize.jsに実装されていました（dryRun比較レポート → エージェントが判断 → 適用して永続化、対象外にした項目は削除ではなくアーカイブ、各ステップの記録をdream_runsに残す）。しかし、エントリーポイントがまったくありませんでした — ツール一覧になく、どちらのAPIにも呼び出しがなく、リポジトリ内にも.organize(の呼び出し箇所はゼロで、独自のテストからしか実行できませんでした。今回、organizeEnabledで制御されるツールmemory_organizeが追加されました。デフォルトでは無効です（無効時はツール自体が登録されないため、モデルから見えず、呼び出されることもありません）。② ついにプロフィールを生成できるようになりました (#497)：パネルのプロフィールカードにボタンが追加され、アクティブなメモリを読み取り、ホストのモデル呼び出しを1回使って「アシスタントから見た」下書きを返します — 下書きのみです。適用するには別途クリックが必要で、手書きのテキストがモデルによって書き換えられることはありません。ストアが空の場合やモデルの動作に問題がある場合はエラーになり、「今回は抽出するものがありません」と装った空の下書きにはなりません（profileExtractEnabled、デフォルトでは無効）。③ ペルソナが他人のセッションに漏れなくなりました：以前は、カードを持たないすべてのIDにdefaultカードが渡されていたため、同じホスト上で独自のIDを持って動作するサードパーティ製ボットには、各ターンで「あなたは……」という主張が2つ渡されていました。また、パネルで「このカードをオフにする」を選んでも何も変わりませんでした。新しいpersonaStrictAddressing（デフォルトでは無効、既存の動作とバイト単位で同一）により、「このID用のカードがない」場合と「カードが明示的にオフにされている」場合のどちらも、何も注入しないようになりました。同じリリースでは、蒸留のトランスクリプト境界と解析失敗ガードも追加されました (#494：あるセッションが同じウィンドウで停止し、20回再試行されるたびに処理コストが増えていた根本原因を解消します。失敗した行には常に生の出力形式が記録されるため、「モデルが実際に何を出力したか」を後から確認できます）。また、パネルの読み取り専用カードは「注入されたテキスト」と称していましたが、今ではバックエンドによって描画されます。以前は、表示すると称していたペルソナの行もヘッダーもプレフィックスも表示されていませんでした。
2026-10-20	v0.9.3	M.O.が「掘り起こせる」状態から「実際に掘り起こすよう呼び出される」状態へ — 蒸留の連鎖はv0.9.1から完全に実装されていました（複数フレームのzstd → 反復シーケンス → 不在との対比 → 下書きのワークフロー）。それにもかかわらず、実行時の呼び出し箇所がありませんでした。リポジトリ内の参照はすべてテストにしかありませんでした。機械には掘り起こす能力がありましたが、実際に呼び出すものがなかったのです。不足していたのはアルゴリズムではなく、帰属とトリガーでした。このリリースでは3つの要素を結び付けました。セッションヘッダーのcwdからプロジェクトのセッションバケットを解決します（バケット名はパスを情報損失を伴って変換したもので、その規則はこのリポジトリの外にあります。照合に失敗した場合は、全体を対象にした走査へフォールバックせず、実行全体をスキップします。後者ではプロジェクトAの操作がプロジェクトBに帰属し、結果が一見正常に見えてしまうためです）。新しいnudgeForProjectは「帰属 → 採掘 → 永続化」を1つのエントリーポイントにまとめます。そして、各プロジェクトに対して10分のクールダウン、4秒の予算、マクロタスクへの延期、同時に1プロジェクトずつの実行、エラー時は警告のみという条件で動作するturn/endフックを追加しました。生成されるのは提案であり、下書きではありません (#489)：昇格には引き続き人間の承認が必要です。パネルには同じエントリーポイントを使う「今すぐ蒸留」ボタンも追加されました。違いは、リポジトリに触れないことだけです。同じバージョンでは、「壊れていても何も通知しない」不具合も3つ修正されました。v0.8.0から毎回例外を投げ、その後黙って機能低下していたスコープの逆引きにより、正規化とメンバーシップチェックが無効になっていました (#487)。/nudgeの書き込みゲートはPUT／POSTしか阻止しなかったため、トークン付きのPATCH／DELETEで提案が黙って永続化されていました。また、帰属の解決では予算が無視され、収集中にバケット名が切り詰められていたため、「すべてを確認できなかった」が「本当に何もない」と報告されていました。さらに、複数フレームのzstdに対するカウンター検証は、Nodeのバッファ全体のデコード仕様に依存していましたが、24.22.0でその前提が失効していました (#490)。
2026-10-19	v0.9.2	見えない失敗を見えるように — このリリースで修正した大半の問題は、機能が欠けていたのではなく、壊れていても何も通知されなかったものです。機能フラグは起動時にのみ反映されていたため、「変更済み」バッジが点灯しても、値がデータベースに届いたことしか意味しませんでした。今回、再起動待ちという3つ目の状態が加わりました (#481)。デフォルトのdreamMaxTokensはそのままmax_tokensとして送信され、プロバイダーの上限を超えていました。8日間で180件の統合、成功は0件でした。パネルから値を編集できるようになり、上限を超えるリクエストはプロバイダー自身が宣言する上限で1回再試行されます (#478)。自動蒸留で書き込まれた行にはベクトルがまったく付与されていませんでした。コメントが約束していた「コミット時に延期」は、実際には存在しませんでした (#477)。また、CLIは--で始まる値を新しいフラグとして扱っていました。ランダムなトークンがたまたま-で始まったときにしか現れない（約4096分の1）不具合だったため、リリースサイクル全体を通じて発覚しませんでした。新機能として、設定を編集したり再起動したりせずに、特定のスコープを一時停止できるスコープ単位の可逆ゲートも追加されました (#471、デフォルトでは無効）。

見出しのみです。全項目については、CHANGELOG をご覧ください。

どのような問題を解決しますか

新しいチャットを始めるたびに、AI が初対面のように振る舞うことはありませんか？

dsh-mneme は DeepSeek Harness にセッションをまたいだメモリを提供します。 これまでに話し合ったプロジェクト、伝えた好み、下した決定を、ウィンドウを閉じた後も AI が覚えています。

シナリオ	プラグインなし	プラグインあり
月曜日のプロジェクトの話を水曜日に再開する	「プロジェクトについてもう一度説明してもらえますか？」	「先週のブログのリファクタリングのことですね。Astro を使いたいとおっしゃっていました。」
コーディングの習慣を AI に伝える	毎回のセッションで繰り返す	一度設定すれば、ずっと記憶される
調査を整理した後にウィンドウを閉じる	メモが失われる	自動でアーカイブされ、いつでも取得できる

ただし、dsh-mneme の信頼性を支えているのは、目に見えないバックグラウンドの仕組みです。ここでは、「単に保存するだけのプラグイン」とは一線を画す特長を紹介します。

信頼できる理由

• 🧾 再現可能で、説明責任を果たせる — 統合のたびに「判断レシート」が残ります。入力のスナップショット、判断の詳細、結果のハッシュが記録され、同じ実行からは同じ結果が再現されます。気づかれない誤統合も、追跡できない変更もありません。
• ⚖️ 競合は保留し、判断はユーザーに委ねます（オプトイン） — 2つのメモリが矛盾しても、どちらか一方を選ぶことはありません。競合の疑いがあるものは確認用に保留され、ステータスページの競合キューで並べて比較し、ワンクリックで解決できます（A を保持／B を保持／確認済みとしてマーク）。難しい判断には、人が関与し続けます。
• 🔐 メモリをエージェントとワークスペースごとに分離します（オプトイン） — scopeEnabled を有効にすると、各メモリに書き込んだエージェントとワークスペースが記録されます。検索では現在のスコープが優先され（該当スコープの一致は重み付けされ、スコープ外のものは降格されますが表示されます）、strictScope を有効にするとさらに、他のエージェント／ワークスペースに明示的にスコープ設定されたメモリは検索や注入の対象外になります（自動キャリアラベルは降格のみで、完全にブロックされることはありません）。複数のエージェントやプロジェクトを使っても、相互に干渉しません。
• 🌙 眠っている間も動作します（オプトイン） — アイドル時間に段階的なアーカイブが実行されます。頻繁に使うメモリはすぐに参照できる状態に保ち、古くなったものは要約に圧縮し、さらに古いものはアーカイブします。ストアは、成長しても軽量な状態を保ちます。
• 🧠 完全オフラインでも動作するセマンティック検索 — embedProvider を local に設定すると、ローカルの埋め込みと再ランキングを使って検索できます。API キーは不要です。埋め込みモデルがなくても、キーワード検索／BM25 検索は引き続き動作します。
• 📝 双方向の Markdown 同期 — メモリはローカルの .md ファイルなので、開いて編集できます。人による編集は尊重され、機械によって上書きされることはありません。
• 💾 セッションの削除 ≠ メモリの削除 — メモリはセッションをまたいで共有されるグローバルな知識です。チャットウィンドウを消去しても、保存済みの内容は保持されます（v0.7.11 以降、セッションとの紐付けは解除されています）。

Zep／Mem0／Letta／Hindsight との違いは？ ストレージ、検索、書き込み時の抽出、オフラインでの統合、競合、忘却、スコープ設定、監査可能性、複数ホスト、オフライン対応、ライセンスを行ごとに比較した表があります。全11項目です。「—」は「劣っている」という意味ではありません：機能比較（中国語）。

5分で始める

# Install the plugin (the easy path: npm package name)
dsh plugin --profile web add @modusensus/dsh-mneme
dsh web

4 種類のインストール元

Settings → Plugins → Add plugin と dsh plugin add では、4 種類の指定形式を受け付けます。貼り付けたものがそのままインストールされます。このリポジトリはマルチパッケージリポジトリです。ルートの package.json は単なるリポジトリシェル（private で、dsh フィールドなし）で、インストール可能なプラグインは dsh-mneme/ にあります。そのため、Git と tarball の指定ではこのサブディレクトリを指定してください。そうしないと、シェル自体がインストールされます。

インストールできないシェルをリポジトリのルートに置くのはなぜですか？一部のマルチパッケージ検出ツール（たとえば dshfind のプラグイン検査）はルートのマニフェストしか確認しないためです。これがないと、このリポジトリは「インストール可能なプラグインパッケージではない」と判定されますが、実際にインストールできるかどうかとは関係ありません。ルートのマニフェストが private ＋ 0.0.0 で、dsh フィールドを持たないのは、こうしたツールが実際のサブパッケージを見つけられる一方で、ルート自体はプラグインとしてインストールも公開もできないようにするためです。

インストール元	貼り付ける内容	備考
npm 名	@modusensus/dsh-mneme	推奨です。バージョン範囲も指定できます（@0.9.0）
Git リポジトリ	git+https://github.com/slow-stack/mneme.git#path:/dsh-mneme	#path: は必須です。指定しないとルートシェル（0.0.0、dsh フィールドなし）が取得され、ホストはこれをプラグインとして扱いません
tarball	C:\\path\\to\\modusensus-dsh-mneme-0.9.0.tgz	dsh-mneme/ 内で npm pack を実行して生成します。bin スクリプトの CRLF 改行のため、pnpm pack は失敗します
ローカルディレクトリ	C:\\path\\to\\mneme\\dsh-mneme	絶対パスである必要があります。相対パスはそのまま拒否されます（a local path must be absolute）

# From source (local directory; edit code, restart, done)
git clone https://github.com/slow-stack/mneme.git
dsh plugin --profile web add "$(pwd)/mneme/dsh-mneme"

# Or straight from Git (no checkout; good for just running a version)
dsh plugin --profile web add 'git+https://github.com/slow-stack/mneme.git#path:/dsh-mneme'

「インストールガイドと使用例」パネルでは npm 形式のみを紹介していますが、上記の 4 種類はいずれも検証済みです。Git と tarball のインストール元は、インストール時にリポジトリへ到達できるかを 1 回確認します（デフォルトのタイムアウトは 5 秒です）。

そのまま使えます。5 分で価値を実感するには、次の手順を試してください。

1. チャット — セッションを開始し、好みやプロジェクトについて AI に伝えます（例：「インデントは 4 スペースが好みです。」）。
2. 確認 — ウィンドウを閉じて、新しいウィンドウを開きます。伝えた内容を思い出せれば、記憶が保存されています。
3. 調整 — Settings → Memory Settings を開き、必要に応じて以下の 3 つのスイッチを切り替えます。

クイック設定（任意）

必要な機能	設定キー	デフォルト	変更方法
完全オフライン	embedProvider	openai	local に変更
バックグラウンドでの統合	autoDream	true	無効にするには false に変更
構造化されたエンティティ抽出	entityExtractionEnabled	false	true に変更
エージェント／ワークスペースごとのメモリ分離	scopeEnabled（より強い分離には strictScope を追加。ハードブロックは明示的な宣言のみに適用されます）	false	true に変更

これらの設定はすべて DSH Settings → Memory Settings にあります。設定の詳細はConfiguration セクションを参照してください（中国語、バイリンガルファイル）。

メモリライブラリの保存場所

ライブラリのデフォルトの保存場所は ~/.dsh/memory で、通常はホストのプロファイル範囲の外です。実際の保存場所は memoryDir の設定に従います。プロファイル範囲内のパス（…/profiles/<name>/… のようなパス）が指定されている場合、ホストがプロファイルをクリーンアップまたは移行すると、ライブラリも一緒に削除されます（#218 に実際の事例が記録されています）。プラグインは起動時にそのような場所を検出すると警告をログに記録しますが、注意喚起のみであり、データを移動することはありません。安全な方法は、memoryDir をプロファイルの外に置いておくことです（デフォルトではそのようになっています）。移行するには、書き込みを停止 → ディレクトリ全体をコピー → 設定を新しい場所に変更 → 再起動、の順に行います。

1 つの図で見るメモリのループ

  write ──► quality filter (drop noise first)
    │
    ▼
  SQLite + local Markdown mirror
    │ (when idle)
    ├─ autoDream   : dedupe / merge / archive / fix / freeze-conflict
    └─ Sleep Mode  : tiered compression + pattern discovery + relation completion (opt-in)
    │
    ▼
  recall (hybrid search + rerank) ──► inject into the conversation

🧭 M.O.：「どのように行うか」をリポジトリに置く（v0.9 ベータ）

メモリストアは、なぜその方法で行ったのかは記憶しますが、実際にどのように動作するかは記憶しません。ワークフローがどこに置かれているかで、そもそも変更可能かどうかが決まります。メモリストア内の一文では差分を確認できず、セッションプロンプトとしては一度しか存在せず、誰かの頭の中にあれば編集できず、痕跡も残りません。

そこで v0.9 では、ワークフローをプロジェクトリポジトリに移し、ワークフローごとにファイルを1つ用意します。

<project>/.mneme/pipelines/<id>.json   ← project layer (commit, diff, PR, readable by CI)
<plugin>/pipelines/<id>.json           ← global layer (fallback; the package ships none today, on purpose)

役割分担を一文で言うと、**メモリは「なぜ」、リポジトリは「どのように」、グラフは「どのように見えるか」**です。

• レールではなくガードレール — グラフには、正規の迂回路を残す必要があります。エージェントが「今回はこの経路は間違っている」と判断した場合、リスクレベルに応じて、そのまま進んで記録するか、停止して確認します。スキップは、このステップが不要だったことを意味します（3回以上 → ステップの削除を提案）。バイパスは、経路全体が間違っていたことを意味します（3回以上 → 経路の見直しを提案）。それぞれ別に集計します — 一緒にまとめると、どちらの提案も発生しなくなります。
• 候補をリポジトリに入れない — 下書きは <memoryDir>/candidates/<project-key>/ にローカルのみで保存されます。1日に10件作っても9件が使われないなら、リポジトリに入れるとただのゴミです。昇格には「2回実行済み（少なくとも1回は成功）」と「反実仮想を説明できる」の両方が必要です。それでもシステムが行うのは提案だけで、コミットとプッシュは人間が判断します。
• パネルとエージェントは同じデータを読み取る — 表示専用では、エージェントは何も読み取りません。ノードの状態（refuted / trusted / stale / candidate）は実行記録から導出され、手動で設定するものではありません。現時点では実行記録の保存先がないため、すべてのノードが candidate です。だからこそ、ベータのラベルを画面に表示する必要があります。

デフォルトではオフです（actionPipelineEnabled）。設計上のトレードオフと注意点については、docs/WORKFLOWS.md（中国語）を参照してください。

スクリーンショット

パネルはバイリンガルで、DSH のインターフェース言語に従います。以下は英語版のスクリーンショットです。ローカライズされた UI は中国語セクションを参照してください。

メモリを記録、閲覧、絞り込みできます。

メモリからエンティティを抽出し、属性を含む関係グラフを構築します。

ステータスパネルでは、ベクトルインデックス、LLM の利用額、統合処理の状況を一目で確認できます。

検索、エンティティ抽出、統合の切り替えをすべて1か所で設定できます。

完全ローカルで監査可能な構成にするための、任意の書き込み保護トークンとフィードバック経路です。

プライバシー

• メモリはお使いのマシン上に保存されます。ローカルの SQLite ストアと編集可能な Markdown ミラーを使用し、mneme サーバーを経由しません
• メモリは人が読んで編集できる Markdown ファイルです
• mneme API キーは不要です。統合と要約には、すでに設定済みのホストモデルを使用します（autoDream / autoSummarize はデフォルトでオンです）
• 統合も完全にオフラインにしたい場合は、ホストにローカルモデルを指定し、dreamProvider / dreamModel と summarizeProvider / summarizeModel をクリアしてください（これらのルートを設定するとプロバイダーに直接接続するため、ホストを切り替えるだけでは解決しません）。または、autoDream / autoSummarize をオフにしてください
• テレメトリ、アナリティクス、リモートロギングはありません

他の AI ツールで使う（MCP）

このプラグインには、依存関係ゼロの stdio MCP サーバー（スタンドアロン npm パッケージ mneme-memory、実行ファイル mneme-mcp）が付属しています。任意の MCP クライアントから、6 つのメモリツール（memory_save / memory_search / memory_list / memory_get / memory_update / memory_delete）をマウントできます。

初回のみ必要な準備：

1. DSH を起動し、プラグインをインストールしておきます（MCP データプレーンは、プラグインのスタンドアロン API 127.0.0.1:8790 を経由します）
2. DSH パネルの Settings → External API でトークンを生成します

クライアントごとの設定（<your-token> を前の手順で取得した値に置き換えてください）：

クライアント	設定
Claude Code	プロジェクトルートの .mcp.json：{"mcpServers": {"mneme-memory": {"command": "mneme-mcp", "env": {"MNEME_TOKEN": "<your-token>"}}}}
Cursor	Settings → MCP → Add Server を選択します。コマンドは mneme-mcp、環境変数は MNEME_TOKEN です
Codex	~/.codex/config.toml：[mcp_servers.mneme-memory] セクションに、command = "mneme-mcp"、env = { MNEME_TOKEN = "<your-token>" } を設定します
Hermes	~/.hermes/config.yaml の mcp_servers: セクションに、mneme-memory: {command: "mneme-mcp", env: {MNEME_TOKEN: "<your-token>"}} を設定し、再起動します
OpenCode	opencode.json：{"mcp": {"mneme-memory": {"type": "local", "command": ["mneme-mcp"], "environment": {"MNEME_TOKEN": "<your-token>"}}}}
OpenClaw	openclaw mcp add mneme-memory --command mneme-mcp --env MNEME_TOKEN=<your-token> を実行するか、Control UI → Settings → MCP を選択します

従来の接続設定も引き続き使えます：dsh-mneme-mcp と DSH_MNEME_TOKEN は引き続きサポートされています（実行ファイルと環境変数はどちらも維持されるため、移行は不要です）。npm パッケージがグローバルにインストールされていない場合は、コマンドに npx を指定し、引数に -p mneme-memory mneme-mcp を指定してください（Claude Code/OpenCode では引数配列、Codex では args = ["-p", "mneme-memory", "mneme-mcp"]）。設定の詳細とセキュリティ上の注意事項については、完全なドキュメント（中国語）を参照してください。

DSH なしでメモリを提供する（スタンドアロンデーモン）

dsh-mneme-serve は、メモリストアを長時間稼働するデータプレーンとして実行します。DSH を終了しても、サードパーティの連携（web-bridge ツール、スクリプト、独自のパネル）から同じメモリを引き続き読み書きできます。Bearer トークンは DSH パネル／CLI と共有され、ルートは外部 API と同じです。また、ポートが使用中の場合はエラーとなります（デーモンと DSH の外部 API のいずれか一方を選択してください）。フェーズ 1 は LLM を使用せず（統合／蒸留は DSH ホスト側で引き続き行います）、検索ではデフォルトでローカル埋め込みを使用します（ランタイムとモデルは初回起動時に自動で用意されます。無効にするには --embed off を指定します）。

npm i -g @modusensus/dsh-mneme
dsh-mneme-serve          # defaults: ~/.dsh/memory + 127.0.0.1:8790

コミュニティ製アダプター

mneme をさらに多くのプラットフォームと連携させるコミュニティプロジェクトです。このリポジトリには含まれていません。互換性情報は各プロジェクトのメンテナーが管理しています。

プロジェクト	プラットフォーム	説明
Mneme-Bridge	DeepSeek web	ブラウザー拡張機能とローカルサービスです。ウェブチャットを mneme ストアに蒸留し、トピックに応じて DSH のメモリをチャットに注入することで、両方から同じメモリを共有します。組み込み（ライブラリをマウント）モードとリモート（スタンドアロン API。上記のデーモンと組み合わせて使用）モードがあります

プロジェクトの掲載を希望する場合は、Discussion を開くか、この表に行を追加する PR を送ってください。

ドキュメント

ドキュメント	パス
プラグインの全ドキュメント（機能／インストール／設定／アーキテクチャ）	dsh-mneme/README.md（中国語）
stdio MCP サーバー — 6 つのメモリツールを任意の MCP クライアント（Claude Code / Cursor / …）に接続します	dsh-mneme/README.md · MCP Server（中国語）
スタンドアロンデーモン（DSH を使わずにメモリを提供）	dsh-mneme/docs/DAEMON.md（中国語）
設定リファレンス（全キー）	dsh-mneme/docs/CONFIGURATION.md（中国語）
蒸留記録の保持とメモリレベルの来歴（#399）	dsh-mneme/docs/DISTILL.md（中国語）
エンティティ構造の設計	dsh-mneme/docs/ENTITIES.md
ワークフロー（M.O.）：ワークフローはリポジトリに、証拠はメモリに保存されます	dsh-mneme/docs/WORKFLOWS.md（中国語）
セマンティックアーキテクチャ	dsh-mneme/docs/SEMANTIC.md
ローカルモデルガイド	dsh-mneme/docs/LOCAL_MODEL.md
Zep / Mem0 / Letta / Hindsight との機能比較	docs/COMPARISON.md（中国語）
変更履歴	dsh-mneme/CHANGELOG.md
セキュリティ	SECURITY.md

🗺️ ロードマップ

🧬 Gene → 🛡️ Audit hardening → 💤 Sleep maintenance → 🕸️ Recall fusion & graph → ✨ Panel enhancement → 🌡️ Self-evolving memory → 🔐 Scope isolation → 🌐 Ecosystem (MCP / daemon) → 🧭 M.O. (project-level workflows)

バージョン	テーマ	ステータス
v0.3	遺伝子：エンティティ／時間制限付き属性／リレーション	✅
v0.4	スリープモード：アイドル時の4フェーズ深層メンテナンス	✅
v0.5	想起の融合と可視化：BM25 + グラフ + ホットメモリー	✅
v0.6	セッションのライフサイクル：セッションの削除 ≠ メモリーの削除	✅
v0.7	自己進化型メモリー：重要度の減衰 + スリープ時の二重保護 + デスクトップ作業環境／機能切り替え	✅
v0.8	スコープの分離（エージェント／ワークスペースの記録 + 検索時の重み付け + オプトイン式の厳密なフィルター）+ 競合レビューキュー + 明示的な帰属情報 + エコシステム（stdio MCP サーバー／グラフ想起軸／コールドスタートのブートストラップ／注入の切り詰めとステータスバー／蒸留の信頼性／注入の調整とエージェント主導の整理／設定リファレンスと課題テンプレート）	✅ リリース済み（v0.8.16 まで）
v0.9	M.O.（Modus Operandi）ベータ版：プロジェクトレベルのワークフロー + 候補の階層化と昇格基準 + パネルのリスト／グラフ表示；設定パネルを「初心者向けを超えて」の段階に合わせて再編（#427）；セキュリティとサプライチェーンの強化（宣言型ルート認証、OSV ゲート、署名付きリリース）；v0.9.1 で書き込み側を追加：実行ウィンドウ、実行台帳、帰属候補、ドリフト検出付き観測サイドカー、ステップの assert／optional、セッションログからのドラフト抽出、ペルソナページ（エージェントごとのカード）；v0.9.2 でサイレントな失敗を可視化：機能フラグの第3の状態「再起動待ち」、スコープレベルの可逆ゲート（#471）、統合処理での max_tokens の自動ダウングレード（#478）；v0.9.3 で自動蒸留を接続：セッションヘッダーの cwd からプロジェクトバケットを解決し、turn/end をフック、クールダウン10分、予算4秒、提案のみでドラフトは作成しません（#489）。さらに、v0.8.0 以降サイレントに機能が低下していたスコープの逆引き（#487）、/nudge の書き込みゲートで PATCH／DELETE が欠落していた問題、および Node のバッファ全体のデコード仕様に依存する複数フレーム zstd のカウンターアサーションを修正（#490）；v0.9.4 で3つの連鎖に欠けていた最後のリンクを追加：エージェント主導の整理インターフェースにツール（memory_organize）を追加（organizeEnabled の背後で、デフォルトではオフ。オフの場合、モデルはこのツールを認識することすらできません）、メモリーからプロフィールのドラフトを作成可能に（profileExtractEnabled はデフォルトでオフ。ドラフトのみで、適用には別途ユーザー操作が必要です。また、手書きのテキストがモデルによって書き換えられることはありません）、カードを持たない ID にペルソナの default カードが渡されないように変更（#497、personaStrictAddressing はデフォルトでオフ）；パネルの「注入されたテキスト」カードを単一のバックエンドソースから描画するようにし、蒸留トランスクリプトのフェンスと解析失敗ガードを追加（#494）	✅ リリース済み（v0.9.4）

マイナーバージョンごとの完全な変更履歴はCHANGELOGをご覧ください。

🧪 ローカル開発

cd dsh-mneme && npm install
npm test        # 2302 tests
npm run stress  # three-axis stress test
npm run sync    # src → lib sync

---

謝辞

autoDream のコンセプトの由来（アイデアの出典を明記し、実装は独自）：

• Auto Dream in Claude Code（Anthropic、Memory 2.0）：コンセプトの起源です。バックグラウンドのサブエージェントがセッション間にメモリーファイルを統合します（重複の排除、矛盾の解消、減衰した内容の整理）。
• Sleep-time Compute: Beyond Inference Scaling at Test-time（UC Berkeley & Letta、arXiv:2504.13171）：オフライン統合のアイデアの背景にある学術的な研究です。
• cc-haha：実装アプローチに関する初期の参考例です。

これらを踏まえ、dsh-mneme は独自のエンジニアリングを加えています。K-Means++ によるクラスタの事前グループ化、型付きの判断リスト（keep／merge／archive／conflict／update、およびスリープ側の supersede／differentiate）、再生可能な sha256 ダイジェスト監査チェーン（dream_runs／receipt_chain）です。インスピレーションの出典に漏れがある場合は、issue を作成してください。

関連研究

dsh-mneme の設計は、以下の公開研究に着想を得ています（以下の引用はすべて arXiv のページで確認済みです。機構との対応付けは論文の主張ではなく、私たち独自のものです）。

• 高速な書き込み＋低速な統合：Dual-Layer Agentic Memory（arXiv:2608.22215）— autoDream のオンライン書き込み／オフライン統合の分離に対応しています。
• ヒートの減衰とアクセスによる強化：FadeMem（arXiv:2601.18642）— ヒートモデル（指数関数的減衰 × アクセスによる強化 × 重要度による調整）に近い学術研究です。
• 競合解決と状態追跡：StateMemBench（arXiv:2608.19652）— 変化する状態を追跡するためのベンチマークです。C1 の競合裁定（置き換え後に古い情報を読み取らない）は、これを受け入れ基準としています。
• 忘却するタイミング／スコープの制御：PersistBench（arXiv:2602.01146）、および Structured Memory（arXiv:2608.08300）におけるプレゼンテーション層での緩和策です。
• 分野の概観：Write–Manage–Read survey（arXiv:2603.07670）— 書き込み／管理／読み取りの分類は、プラグインの全体的な構造と一致しています。
• 数カ月規模の信頼性：Memory as Infrastructure（arXiv:2609.05510）— sha256 監査チェーンやフェイルセーフな機能縮退と同じ「インフラとしてのメモリ」という学派です。
• 隣接システム（対比）：Zep（時間的ナレッジグラフ）、Mem0（本番環境向けの抽出）、Hindsight（保持／想起／内省）は、書き込み時に LLM で情報を抽出し、ベクトル／グラフを使って検索します。一方、dsh-mneme は完全な監査証跡とともに統合処理を再実行可能な状態に保ち、競合を人間によるレビューのために凍結し、デフォルトではメモリをローカルに保持します。

📜 ライセンス

MIT