Mneme Bridge — 将 DeepSeek 网页端接入 mneme 记忆库

[SternChiri]

已阅读 CONTRIBUTING 的 Scope 部分。本项目属于平台适配类，按其中说明，此类项目不在优先范围，故在此说明情况。

项目

https://github.com/SternChiri/Mneme-Bridge

功能

DSH 与 DeepSeek 网页版的记忆目前互不相通。本项目将网页端的对话接入 mneme 的记忆库，使两侧共享同一份记忆：网页中产生的内容可在 DSH 中检索到，DSH 中形成的记忆也会按话题注入网页对话。

实现分为两个部分：负责网页侧的浏览器扩展（MV3），以及负责与 mneme 交互的本地 Node 服务。

与 mneme 的关系

本项目不是 fork，也不是 DSH 插件，不新建任何存储。embedded 模式下，桥接服务直接挂载 mneme 的 lib（createStore / createMirror / createService），检索与写入分别通过 searchMemories 与 saveWithDedupe 完成；remote 模式下则使用 mneme 的 standalone API。去重、合并、冲突裁决与检索均由 mneme 承担，本项目只负责调度与传输。

一个设计问题

DSH 关闭时 mneme 随之停止，桥接服务失去上游（remote 模式返回 502）。目前的做法是探测 8790 端口，不可用时回落到 embedded 直接访问库文件。希望确认是否有更合适的方案：

• 官方是否建议 mneme 独立常驻（如 daemon 模式），或使用自带的 stdio MCP server，以便被第三方服务长期挂载？
• 若有推荐方式，本项目愿意将其作为默认实现。

维护

Scope 部分提到 wrapper 类项目需要贡献者承诺长期维护，这一点本项目可以承担：上游接口变更引发的兼容问题，将跟进修复。

若这个方向不合适，或对 mneme 的引用方式有要求，请直接指出。

[modusensus]

先说态度:这个方向我个人很感兴趣。网页端会话与 DSH 共享同一份沉淀,本来就是我想做但一直没排上期的事,现在有人按 CONTRIBUTING 的规矩先来报备、而且代码质量比典型 wrapper 高出一截(原料不进 mneme 的缓冲层、蒸馏 prompt 与 salvage 对齐上游管线、会话清理的四重闸),这没什么可犹豫的,不需要 fork 也不要求插件化。下面逐条回应,直话直说。

关于「官方推荐的挂载方式」

mneme 对外目前有三种形态:

形态	实质	对你的场景
宿主内 API(/api/dsh-mneme/*)	随 DSH 进程存活	不可用
standalone HTTP API(8790,opt-in)	随 DSH 进程存活	DSH 关闭即断,即你遇到的 502
stdio MCP(bin/dsh-mneme-mcp.mjs)	数据面仍走 8790	同上,解决不了你的缺口

所以对「DSH 关闭后 mneme 停止」,眼下的答案就是你们 embedded 回落这条路——它与 mneme 的多进程设计一致(共享 memoryDir 本就是设计内场景:WAL + busy_timeout),我们认可。同时说一个正在准备的事:我们准备把 standalone 形态拆成一个可选的独立服务进程(daemon)——opt-in,默认仍是宿主内挂载,对现有用户是纯增量。它落地后,「第三方长期挂载」就有官方推荐姿势:届时你们的 remote 模式适合作为默认,embedded 降级为无网兜底;蒸馏与巩固的归属也会在立项时给机械保证,不靠用户自觉。进度会在本讨论知会。

在那之前,三点补充:

1. 单写者纪律目前只覆盖 autoDream 与 external API 端口。bridge 两者都不跑,现状无冲突;但请在文档写明「巩固(dream)仍由 DSH 侧负责」,避免用户误以为两侧等价。
2. saveWithDedupe 去重是先查后写,库层无 UNIQUE 约束,双进程并发写同一 (type, title, scope) 极小概率产生重复。已知限制,请勿当强保证宣传。
3. lib 挂载的定位:lib/ 是 src 的同步产物,内部签名没有稳定性契约,行号级耦合每次发版都可能断。建议:① 读安装包 package.json 做版本门控,超出已验证区间明确拒绝;② 把 mneme-verification.md 当作每次上游发版的回归项。我们这边会把最小装配面(createStore / createSettings / createMirror / createService / recoverMirror)标注为 de facto 接口,重构时不再随意变动——这是承诺上限,不等于语义冻结。

关于蒸馏端点

注意到你们仓库 docs/ 里已备了一份「请求 standalone API 开放蒸馏端点」的追帖草稿,先给初步态度,省一轮往返:

• 方向认可,这比 fork summarize 管线好得多。
• 但它超出 CONTRIBUTING 对 External API「保持不变」的承诺,需要单独立 issue 走设计(LLM 句柄归属、鉴权、审计 receipt 写到哪张表、与 quality-filter 的关系)。入库语义上倾向你们草稿里的姿态:只返回候选,由调用方走 saveWithDedupe;要不要提供「端点内直接走完整 save 管线(实体抽取 + 质量闸)」的可选项,留到 issue 里定。

检索质量:上游愿意补的部分

你们现在的短板不在架构,在检索上限,而且恰好都卡在「宿主接线、第三方复刻不了」的地方:

• 模式不对称:bridge 启动时定模式且进程内粘滞。remote 模式检索走宿主完整的 fuseRecall(向量/重排/实体随宿主装配可用),体验就是 DSH 本身的水平;embedded 模式只剩关键词 + BM25(embedder/reranker/extractor 都是宿主接线,你们组装时拿不到)。另外 remote 模式下 DSH 中途关闭,注入会静默失效直到重启 bridge。
• /memory/context 的 pins 启发式(交互词白名单匹配)明显是按你本机记忆内容调的,换个用户基本失灵——这段职责本来就该在上游。

上游愿意做三件事,全部是增量接口,不动现有路由与语义,存量用户零感知:

1. standalone API 增加 GET /context(命名/形态以 issue 讨论为准):一次返回 profile + rules + pins + related,候选走 DSH 同一套注入管线(fuseRecall、热度、scope 语义),替代你们自建的 pins 启发式——bridge 侧该段代码可整体删除;
2. 为 lib 挂载方出一份 local-embedder 最小接线文档(模型下载/校验/adopt 目前在宿主内完成),补上 embedded 模式的向量路;
3. POST /summarize(见上节)。

排期上不说满:这三条都走 issue 设计,不承诺时间;但方向认可,且属于「需要我这边做的部分」,我会按不影响现有用户的原则推进。

请写进 bridge README 的已知限制

1. 实体抽取:extractor 由宿主经 setEntityExtractor 接线,bridge 拿不到——网页记忆不进实体表,entity 检索通道看不见它们;
2. 质量闸:quality-filter(归档/降权)与 write-admission 是宿主管线环节,bridge 蒸馏条目绕过这两道门;
3. scope 不对称:bridge 写入是全局记忆(所有 DSH scope 可见),反向 DSH 侧显式标注 agent_scope 的记忆对 bridge fail-closed 不可见——即「网页进全局、只读全局」,不是双向全量共享。

(顺带:bridge 的检索会正常写 recall_runs,复用统计不受影响,这点你们做对了。)

隐私与安全(建议务必处理)

1. 注入出境:context 块(画像/规则/pins/相关)随每轮请求发送至 DeepSeek 服务器;sensitivity 在 mneme 侧只是标签、不参与可见性,当前没有任何过滤拦着敏感记忆出境。建议 /memory/context 组装侧默认排除带 sensitivity 标记的条目(或整体 opt-in),并在 README 明示数据流向。
2. 页面可读记忆库:inject.js 在 MAIN world,与 content script 经 window CustomEvent 通信——chat.deepseek.com 上任何脚本都能伪造 mneme-ext:cmd(type:'bg') 经 content 代发 getList/getContext,无需 bridgeToken 即可读出记忆库,也能伪造 ctx 操纵注入。至少请文档化;要收紧的话给 'bg' 转发加一次性握手 nonce。
3. 蒸馏会话清理器按逆向格式删 $DSH_HOME/sessions 下的目录——四重闸方向保守、可接受,但属于对 DSH 内部格式的耦合,请标注实验性,DSH 改版时优先怀疑这里。

维护与收录

维护承诺收到。负担会集中在两处:DeepSeek 私有接口改版(注入/收集/导入三条链)与 mneme 发版回归——后者涉及装配面或 REST 语义的变更时,我们会回到本讨论知会。下一步我们会在 README 增加「社区适配器」小节收录本项目。

[SternChiri]

v0.6.1 已发布，把审查中点名的建议全部落地了——bg 转发加了一次性握手 nonce，/memory/context 组装端默认排除带 sensitivity 标注的条目（embedded / remote 同口径），lib 挂载按 package.json 做了版本门控（超出区间拒绝启动）。README 已补记注入数据流向与已知边界（巩固归属 DSH 侧、不进实体表、绕过质量闸、scope 不对称、并发去重限制），会话清理器也标注了实验性。daemon 与 GET /context 立项时我们会跟进适配。