Mnemon 是什么
Mnemon 是一个面向编码 agent 的持久记忆引擎，用 Go 写成，采用 Apache-2.0 许可。它的 README 把出发点说得很直白：agent 在会话之间会忘光一切，上下文压缩会丢掉关键决定，长对话会把早先的信息挤出窗口。Mnemon 给出的答案是：把记忆放进一个比会话活得更久的存储里。
它主打的差异在于「智能跑在哪里」。多数记忆工具把一个 LLM 塞进流水线内部；Mnemon 说你的宿主 LLM 才是监督者。二进制负责确定性工作——存储、图索引、检索、衰减——由模型来判断该记住什么、怎么连边、何时遗忘。README 把这套做法称为「LLM-supervised」，并把它与归到 Mem0、Letta 名下的「LLM 嵌入式」模式对照。
这个区别就是产品本身，也正是 DSH 的接入故事被拆成两个仓库的原因——见下一节。
它是怎么接到 DeepSeek Harness 上的
DSH 并不是直接接进 Mnemon 的。README 让它经由一个独立插件 dsh-mnemon 接入，由后者把 DSH 自身的运行时记忆、受管的项目文档、以及 Mnemon 的长期记忆空间，叠成 README 所说的「一套受监督的三层记忆系统」。
而本目录这个包实际安装的东西，比名字给人的印象要窄。它的清单是 @mnemon-dev/dsh-mnemon，版本 0.1.0，Apache-2.0，只附带三个文件：cordis.patch.yml、README 和 LICENSE。它的 dsh 字段只声明了一件事——bundle.patch: ./cordis.patch.yml。其余全部来自它唯一的依赖 dsh-mnemon: "latest"；README 也确认，从 Mnemon 仓库安装会解析到 dsh-mnemon 的 latest npm 版本，因此在 Mnemon 仓库里发布新插件版本不需要同步改动，而已经装好的实例会停在已解析的版本上，直到重装或更新。
有两条老实话要补。第一，上面那个带 scope 的名字是清单自己的名字，但公开存在的是不带 scope 的 dsh-mnemon：npm 注册源提供 dsh-mnemon（写作时为 0.5.x），而 @mnemon-dev/dsh-mnemon 返回 404。第二，这两个文件里没有任何一处说明这个包装包会安装或内置 mnemon 可执行文件，它也没有声明操作系统或 CPU 限制、没有安装脚本、没有可选平台包。README 里「npm 会安装与宿主匹配的原生 Go 可执行文件」那句，说的是独立核心 CLI 的安装路径；顺手推断 DSH 包装包也会准备好二进制，正是这份条目拒绝做的跳跃。
记忆机制到底是什么
记忆存在一个本地数据库里——一套 SQLite 模式，里面是由四类边连接的 insight：时间边、实体边、因果边、语义边。README 示意图的图注描述了一张真实的图：「87 条 insight、2150 条边，跨四类图」。数据默认落在磁盘上的 ~/.mnemon（可用 MNEMON_DATA_DIR 改），README 把项目的地基描述为「一个 ~/.mnemon 数据库，任何受支持的 agent 都能读写」。README 的长期方向提到 PostgreSQL 或 Neo4j 可能成为同一协议下的后续适配器；今天的后端是 SQLite。
召回不是关键词检索，也不只是向量检索。README 把意图感知召回列为「图遍历 + 可选向量检索（RRF 融合）」，对所有查询默认开启；此外还有内建去重：remember 会检测重复与冲突，然后跳过或自动替换。读写通过三个原语表达——remember、link、recall；README 称之为「意图原生协议」而非数据库语法，返回带所谓信号透明度的结构化 JSON。某一次写入是否有 LLM 参与，是你这边 agent 的判断，不是流水线里固定的某一环。
运行要求与你要做的事
按 README 的安装章节，核心 CLI 走 npm 需要 Node.js 22 或更新，支持 macOS / Linux / Windows。注意这里有个落差：本插件自己的 package.json 声明的是 engines.node: ">=20"。两个数字都出自来源，它们描述的不是同一件事。
而 DSH 插件本身所需的 Harness 版本下限，在这两个来源里哪儿都没写——README 只是定性描述 DSH 集成，清单里既无 Harness 版本字段、也无 peer 范围或 dsh.compatibility 块。因此本条目不记录 dshTarget，验证等级止于 L2，而不是替来源断言一个它没有声明的兼容性。
Homebrew、go install 和源码构建是文档给出的替代方式，均为 macOS / Linux；源码构建需要 Go 1.24+。Windows 支持核心 Memory 命令，而 mnemon agency——面向 Pi agent 的独立预览面，与记忆无关——在具备 README 所说的原生 Windows 安全边界之前，在 Windows 上不可用。基础功能不依赖任何外部服务。唯一的可选依赖是 embedding 提供方：默认是 http://localhost:11434 上的本地 Ollama，也可以是 OpenAI 兼容服务器。监督者不需要 API key，因为根本没有内嵌的 LLM。
然后是配置：README 的 DSH 章节让你打开 Settings → Plugin Config → Mnemon 选择存储范围（storage scope），再在会话里的 Memory System 标签页创建或激活记忆空间。
那些 LLM 调用由谁付费
按 README 的说法，不额外付费。因为监督者就是你本来就在跑的宿主 LLM，Mnemon 自称「无中间商、无额外推理成本」，README 还给 Claude Max / Pro 订阅者留了一句：Mnemon 完全走既有订阅、不需要另配 API key。这句话应读作关于归属的陈述，而不是关于开销的陈述：记忆相关的判断由你已经在付费的模型做出，因此它体现在你平时的用量里。至于你送出去了什么，是另一回事——一次召回或写入是否把你的记忆图带进托管模型，取决于那个模型跑在哪里，而来源对此未置一词。
README 还提到子 agent 委派是可选的：当运行时支持时，主 agent 可以让更便宜或隔离的 worker 去执行 mnemon remember。这是一种执行策略，不是架构的必需部分。
作用范围、共享，以及什么会离开这台机器
README 直接回答了共享问题：默认所有会话共用同一个 default 存储，所以在某个会话里记住的决定，在未来每个会话里都可用。隔离可以用命名存储（mnemon store create work）、MNEMON_STORE 环境变量，或 DSH 插件里的存储范围设置来实现。README 的 Vision 章节把意图写得很明确——「你本地所有 agentic AI，跨会话、跨框架，共享同一个活记忆池」——一个 ~/.mnemon 数据库，Claude Code、Codex、Cursor、DSH 以及其他列出的运行时都能读写。
这一切都不是云功能。来源里没有出现同步服务、托管账号或备份端点。内容仍然可能以两种被记录在案的方式离开这台机器：其一，可选的 embedding 提供方——如果你把它指向 Voyage AI 这类托管 API 而不是 localhost，记忆文本会被提交去做 embedding；其二，宿主模型本身会怎么处理它读到的东西，README 没有讨论。遥测与否，两个方向都没有提及。文件权限、静态加密、隐私政策同样没有提及；请不要自行脑补。
来源真正为审计提供的，是凭据（receipts）：可导出经过哈希的操作凭据，用于「记忆边界审计，且不包含原始记忆内容或查询」。这是边界审计的辅助手段，不是内容级的访问日志。
已知限制
容量有上限，且清理是自动的。MNEMON_MAX_INSIGHTS 默认 1000 条活跃 insight（设为 0 可关闭自动清理），MNEMON_AUTO_PRUNE_MIN_AGE 默认给出 24 小时的宽限期。每次自动删除都是软删除，会以 prune 操作出现在 oplog 里，并在触发命令的 auto_pruned_ids 字段中按 ID 报告——也就是说删除可追溯，但它们确实会在没人询问的情况下发生。
准确性没有量化。README 没有发布任何基准、没有精确率或召回率数字，也没有横向评测；页面上唯一的数字是一张示意图的 insight 与边数量。去重被描述为「检测 + 跳过或替换」，这是一种行为，并不保证两条你认为不同的记忆一定会保持不同。
集成深度因运行时而异，README 自己也这么说。MiniMax Code 是「刻意只做 skill」，因为 3.0.65 版本不派发可靠自动召回所需的 user-prompt 钩子；ZCode 会忽略项目级钩子配置；有的运行时拿到 skill，有的拿到钩子与插件，有的拿到 TypeScript 扩展。至于 DSH 具体支持哪些命令、标签页和工具，这些来源没有复述。
还有若干读者容易默认成立、但来源里根本没有的东西：没有「一切都留在你机器上」的表述，没有相对其他记忆工具的准确性优势声明，这个 0.1.0 包装包也没有发布说明或打包信息，更没有任何清单列出 DSH 插件除了它声明的那份 patch 文件之外，到底往你的 profile 里写了什么。
什么时候用它、什么时候不要用
如果你想要记忆活得比会话更久，又不愿意在流水线里为一个额外模型按 token 付费，并且喜欢「一个共享存储、其他 agent 也能读」这个想法，那就可以用它。四图模型、衰减与清理生命周期、以及凭据导出，是读者真正能拿项目去兑现的部分。
四种情况下请跳过，或者至少带着清醒的预期使用。如果你的需求严格限定在会话内的上下文，那这不是那个工具，它的 README 也没有声称要取代 Harness 自己的上下文处理。如果你要求每一次写入都必须先经过人工批准才能落地，请注意这份 README 没有记录这样的门禁：写入走的是 agent 的判断加一份行为指南，所以写入可能在你看到之前就已经发生。如果你在 Windows 上并且需要 mnemon agency，它还没到。如果你的环境禁止第三方可执行文件出现在 PATH 上，请记住它的架构是一个由 CLI 命令调用的独立二进制，而不是加载进 Harness 的库。
还有一处对比值得做，因为同一个目录里就放着另一个记忆插件：dsh-memento 把存储放在 $DSH_HOME/dsh-memento/memory.db 里，是纯 Node、没有原生代码，并且强制每一次写入都经过 DSH 的审批缝。Mnemon 维护的是 ~/.mnemon 下跨框架的存储，附带一个原生 Go 引擎，并且用你自己的模型而不是审批提示来监督写入。memento 自己的 README 在它的对比表里把 dsh-mnemon 列为「memory store helper」，用来对照它自身「协议 + 门禁 + 审计」的定位。
FAQ
Mnemon 需要 API key 或付费 LLM 账号吗？
按 README 的说法不需要 API key。监督者就是你本来就在跑的宿主 LLM，README 还明确提到 Claude Max 与 Pro 订阅者可以直接用既有订阅。全文唯一提到的凭证是可选的 MNEMON_EMBED_API_KEY，用于需要鉴权的 OpenAI 兼容 embedding 服务器。
我的记忆存在哪里，会有东西被上传吗？
默认存在本地 ~/.mnemon 数据目录里，是一个 SQLite 支撑的图，并支持按存储隔离。默认不上传任何东西。被记录在案的例外是可选的 embedding 提供方：把 MNEMON_EMBED_ENDPOINT 指向 Voyage AI 这类托管服务，你的记忆文本就会被送去做 embedding。关于遥测，来源两个方向都没有主张。
「单个二进制」这个说法成立吗？
对核心引擎来说基本成立：README 称引擎是一个按宿主操作系统与 CPU 安装的原生二进制，Node.js 只被 npm 启动器使用。但对这个 DSH 插件不成立。这里的清单是一个很小的 patch 包，只有一个依赖；它不含可执行文件，没有声明操作系统或 CPU 限制，它的 README 也没说会替你安装 Mnemon 二进制。
它会取代 Harness 的上下文或压缩处理吗？
不会，它的 README 也没有这样的主张。Mnemon 自己的生命周期图把压缩前那一刻当作四个提醒阶段之一，目标是只保留「关键连续性」——它是宿主上下文管理的补充，而不是替代。
记忆会在项目之间共享吗？
默认会：所有会话共用一个 default 存储。如果你想要隔离，README 记录了命名存储、MNEMON_STORE 变量，以及 DSH 插件里的存储范围设置。需要注意的是，README 没有记录命名存储的数据具体落在磁盘的哪个位置，所以「每个存储的文件布局」应视为未说明。