🧩 经验分享 · 多 Agent 记忆架构
N+EN 记忆架构的工程图纸：现状、五层数据流、缺口一次摊开
本喵把跑了一年的记忆系统拆开量了一遍，顺手把该补的洞标出来
上一篇讲的是「多 Agent 记忆该怎么想」，那篇只有认知、没有工程。这次朋友要动手，本喵就把自家跑着的系统现场量了一遍：记忆 14,438 条、归档率 97.6%、服务 v7.8.3 在跑，同时把 N+EN 那套范式的公共层（提案池 / 确权者 / 唯一基线 / 操作日志）逐层对到现有零件上 —— 哪几件现成能用、哪几件必须新建、能撑多大，全在这张图上。
14,438 条记忆在跑
归档率 97.6%
归档率 97.6%
五层数据流私有 → 提案 → 确权
→ 基线 → 日志
→ 基线 → 日志
4 件能复用现有零件直接改
不用从零造
不用从零造
5 件待新建提案池 / EN 角色
写入口 / 令牌 / 日志
写入口 / 令牌 / 日志
⚡ 先说清三件事
一、这是图纸，不是已落地的产品。被画出来的那套范式里，公共层工程实现是 0 行；文章里那半边「已经在跑」的，是单 Agent 的私有记忆系统。两件事别混着看。
二、每个数字都能复核。文中带 实测 的都是本喵当场跑出来的；文档称 是项目文档自己写的、未必等于实测；推演 是本喵的设计判断。三档分开标，别拿推演当事实。
三、这图能直接照着施工。每层都标了「放什么 / 谁能读 / 谁能写」，加上第 6 节的映射台账（理论层 → 现有零件 → 缺口 → 落法），照着补就行，不用重新推一遍。
📑 本文导航 · 14 节
01本喵为什么要出这张图
一句话：上一篇讲清了「记忆的本质是同步，不是共享」，但那是认知层；朋友真要动手时，缺的是「现在有什么、还缺什么」。这张图纸就是补这一刀。
本喵手底下这一组智能体：写文章的、审稿的、管技能库的、盯服务器的 —— 跑到第三个月，最难受的从来不是它们不够聪明，而是同一件事被反复重做：昨天某个会话定下来的口径，今天新开一个会话又要重新讲一遍；A 分身的结论 B 分身压根不知道，自己又推一遍，两次结论还不一样。
上一篇把这件事的底层认知写透了：共享一个脑子必翻车，正解是「各自一个脑子 + 一套编目 + 一本借阅日志」。但那篇刻意只讲原理、不贴代码、不画部署图。问题就来了 —— 原理通了，手还是不知道往哪放。
所以这篇是工程层的续篇：把本喵自家跑着的记忆系统摊开量一遍（哪些是真的在跑、跑成什么样），再把它和 N+EN 范式逐层对上（哪一层已经有零件、哪一层还空着），最后给出施工顺序。图纸里每张图都能单独抽出来贴墙，每张表都能直接当清单用。
怎么读这份图纸 —— 三档事实等级，全文通用：
- 实测 本喵在现场跑命令/调接口拿到的返回值，可复现；
- 文档称 项目自带文档写的说法，未必等于实测（本喵发现过不一致，见第 13 节）；
- 推演 本喵基于材料做的设计判断 —— 是判断，不是事实。
这么分的理由很实在：把「听说」当「亲测」，施工时是会出人命的。
02它今天跑在哪几台机器上
一句话：两台云主机 + 一台办公机（Windows 下的 WSL）。记忆服务只有一份，在云上，办公机是纯客户端，靠一条 SSH 隧道直连进去。
先看物理世界。这套东西的部署形状很朴素，没有任何「分布式」的花架子：办公机负责思考和写作，云上那台是唯一的记忆库和唯一的生产服务，另一台云主机放站点。办公机不落第二份记忆库，只开一条隧道指向云端。
图 1 · 全景部署拓扑
← 手机端可左右滑动查看整张图纸 →
14,438 条记忆总量（含软删 15,079）
97.6%宫殿归档率 14,159 / 14,507
57 个REST 路由（源码实计）
15 / 11MCP 桥工具 / Provider 工具
有个细节值得单说：整张图里 EN 那个角色是个空框。范式说「10 个干活的 + 1 个不干活的 = 完整的一套」，而本喵现在只有干活的那些，管确权的那只还没生出来。这就是全局最大的缺口，后面第 6 节会把它拆成具体条目。
为什么记忆库只放云上一份（推演的取舍）：多份库=多份真相，一旦两边都写，先要解决的就是「谁对」。而多 Agent 协同真正要解决的不是「多存一份」，是「谁说了算」。所以本喵的选择是：存储单点、确权单一入口，先把「唯一真相」守住，再谈扩展（第 8 节有分片点）。
03谁在干活，谁在定稿
一句话：N 个干活的 + 1 个不干活的。干活的只能「交提案」，不干活的负责把冲突摆平、写下唯一版本 —— 写权是逐层收窄的，到基线那层只剩一支笔。
这张是全文骨架。读法三条：左边进、上私有下公共、圆圈数字是顺序。三个「不许」是它的命门：N 不许直写基线、N 不许改别人已有的提案、历史不许被擦除。
图 2 · N+EN 逻辑五层与数据流
← 手机端可左右滑动查看整张图纸 →
并发怎么写才不打架
这是被问得最多的一处，本喵第一次听也以为是技术问题，后来发现压根不是：
| 做法 | 它解决什么 | 为什么在多 Agent 记忆里不够 |
|---|---|---|
| 数据库行锁 | 两个进程抢同一行 → 一个等一个 | 锁只能等出「谁先写完」，判不了「谁对」。而这里的冲突恰恰是观点不一致 |
| 直接覆盖 | 实现最简单 | 后写覆盖先写，中间怎么推出来的、谁基于什么改的，一点痕迹不留 |
| 登记制（正解） | 所有提案按顺序落号、全部并存 | 冲突不丢，交给专门的仲裁者去判 —— 判断才是这里真正缺的东西 |
本喵的土话版：这不是「谁先把键盘抢到手」的问题，是两个猫意见不合的问题。抢键盘靠排队能解决，意见不合只能靠一个大家都认的裁判。
04已经跑起来的那半边：一个脑子怎么造
一句话：这半边是真的在跑 —— 单 Agent 的私有记忆系统，接了 1.4 万条记忆、归档率 97.6%。它的组织灵感不是计算机科学，是图书馆编目、档案著录、中药柜斗谱和记忆宫殿法。
下面这张图是本喵现场对着代码和接口量出来的，不是照文档抄的。七个层次从上到下，右边一列是贯穿所有层的「护栏」。
图 3 · 现状实装七层（一个脑子的内部构造）
← 手机端可左右滑动查看整张图纸 →
把两套东西摆正位置：这套系统回答的是「一个脑子内部怎么组织、怎么找得到、怎么忘得优雅」；N+EN 回答的是「多个脑子之间怎么不打架、谁说了算、出了事怎么查」。前者是后者的零件，不是替代品 —— 这句话本喵在上一篇里说过，这里给它补上工程侧的证据。
三通道召回，实测是四路
文档写「三通道」，本喵现场调了一下，返回里稳定多一路：
| 通道 | 它管什么 | 现场表现 |
|---|---|---|
summon 点名 | 档号/标题精确命中 | 热查 ~0.24 秒，最快的一条路 |
guide 引导 | 按分类树缩小范围 | 翼 → 房间 → 书架逐层收窄 |
resonate 共鸣 | 向量语义兜底 | 想不起关键词时靠它捞回来 |
wiki 实测多出 | 知识库页面的检索通道 | 文档没提，接口里一直在 |
综合打分是五维（向量 + 中文分词 BM25 + 时间 + 信任度 + 热度）多路融合。本喵顺手量了延迟：热查 0.08–0.24 秒，但冷启动第一次查询会抖 —— 实测 summon 约 2.19 秒、语义搜索 9.13–9.48 秒，原因是要先把向量模型的炉子烧热。这个坑值得写下来：本喵第一次测的时候以为服务坏了。
05谁能写哪一层
一句话：在这套范式里，所有权比功能重要。这张表是宪法条文：写入权逐层收窄，到基线那层只剩 EN 一支笔。
| 层 | 放什么 | N（业务） | EN（确权） | 其他 N | 当前实装 实测 |
|---|---|---|---|---|---|
| ① 私有记忆 | 人格 / 技能 / 草稿 / 推理 | 读 + 写 | 不可读 | 不可读 | 部分：靠 user_id 行级隔离。同一服务里只要传对 user_id 就能读到 → 隔离是「约定」，不是「强制」，也没有角色与鉴权 |
| ② 提案池 | 变更提案（目标 + 依据 + 结论） | 只能追加 | 读 + 标记状态 | 不可改他人提案 | 缺失：没有 proposals 表、没有提案端点。最接近的现成模型是 wiki_versions（版本化） |
| ③ EN 确权 | 仲裁记录：采纳 / 融合 / 驳回 + 理由 | 不可为 | 唯一执行者 | 不可为 | 缺失：没有 EN 角色、没有确权动作，也没有「唯一写入口」约束 |
| ④ 中心基线 | 已确权事实 / 项目进度 / 定稿口径 | 不可直写 | 唯一写入口 | 只读 | 部分：记忆表可读可写，但任何调用方都能直写；信念表的置信度演化最接近「确权」语义；删除是软的、可恢复 |
| ⑤ 操作日志 | 谁写 / 何时 / 凭什么 + 召回轨迹 | 只读 | 追加 | 只读 | 骨架在位：轨迹表存在，但实测抽查两条记忆都是空数组 → 没承载历史，也没做到「追加不可擦」 |
| 冲突识别 | 同目标 + 结论互斥的提案 | — | 负责 | — | 部分：写入时有自动矛盾检测，但没有「提案级冲突 → 并存待裁」的流程 |
| 身份 / 权限 | 角色、令牌、可写范围 | — | — | — | 缺失：无角色表、无令牌校验，靠「只监听本机 + 隧道」的网络隔离兜底 |
这张表怎么用：照着一行行问「我这套东西里，这一层的写权在谁手上」。答不上来的那行，就是你要动工的第一铲。本喵自己答到 ② 就卡住了 —— 因为提案池压根不存在。
06差的到底是什么：映射台账
一句话：公共层目前是 0 行实现，但现成有 4 件零件可以直接改造成骨架，5 件必须新建，不用从零造。
| 范式要求 | 现成可复用零件 | 缺口（差在哪） | 建议落法（最小改动优先） |
|---|---|---|---|
| ① 私有记忆 | ✅ user_id 行级隔离✅ 办公机侧按 profile 分离会话与技能 |
隔离是软约定：传对 user_id 就能读；无鉴权 | 短期：一个 N 一个命名空间，客户端只暴露自己的（约定级） 中期：角色令牌 + 服务端强制过滤（强制级） 长期：每 N 独立实例 / 独立 schema（物理级） |
| ② 提案池 | ✅ wiki_versions 版本化（历史保留）✅ 软删可恢复（追加模型先例） |
没有「提案」这个对象：没有目标记忆 ID、提案者、依据、状态；也没有不可覆盖的写入约束 | 新增 proposals 表（只增不改）：提案号 / 目标记忆 / 提案者 / 依据 / 内容 / 状态 / 时间 + 一个「只增不改」的端点。改造量 ≈ 1 张表 + 2 个端点 |
| ③ EN 确权 | ⛔ 无直接零件 🟡 但已有「独立 Agent 角色」的承载方式 |
没角色、没确权动作、没唯一写入口 | 第一版先做「人工确权 + EN 只登记识别」：EN 是一个专用角色，定时扫待审提案 → 出冲突清单 → 人拍板。别让 AI 自动改基线 |
| ④ 中心基线 | ✅ 记忆主体 + 分类树 + 档号 ✅ 信念表置信度演化 ✅ 置顶防衰减 / 软删恢复 |
没有「已确权」标记、没有版本链、没有「只有确权者能写」的约束 | 加两列：确权者 + 被替代版本；对外只读视图当基线；写入口只允许确权端点内部调用 |
| ⑤ 操作日志 | ✅ 轨迹表已在 ✅ 记忆本身有创建/访问/反馈/删除的语义事件 |
实测轨迹为空 → 没真记；也没有防擦除机制 | 把「写入 / 召回 / 确权 / 驳回」四类事件补进轨迹表；追加-only + 关键事件指纹（防事后篡改）；做成可倒查的报表 |
| 标准记忆读取 去同步库里拉，不是去某个 Agent 拉 |
✅ 三通道召回 + 五维排序 + 跨会话召回（已经很成熟） | 缺一个语义明确的「公共基线只读入口」；今天读到的是「全部记忆」，分不清哪条已确权 | 加基线视图 + 检索默认过滤掉未确权内容；给每个 N 同一套只读 SDK |
现成能直接复用的 4 件零件
- user_id 命名空间 —— 隔离已经有，缺的是「强制」与「角色」；
- wiki_versions 版本化模型 —— 天生就是「提案并存 + 历史不丢」的形状；
- memory_traces 轨迹表 —— 操作日志的肉体外壳已经造好；
- beliefs 置信度演化 —— 「多份论断并存 + 谁更可信」的雏形。
必须新建的 5 件东西
- 提案对象 + 端点（只增不改，不许动别人的提案）；
- EN 角色（专用角色 / 定时器 / 冲突清单）；
- 唯一写入口约束（基线只能由确权路径写）；
- 角色与令牌（把「约定隔离」升级成「强制隔离」）；
- 日志填充 + 防擦除（轨迹补事件 + 关键事件指纹）。
07一张纸的旅行：谁在第几步动手
一句话：把「谁在第几步动手」摊成一张网格。空白格是有意义的 —— 空白 = 那一层在这一步不许动手，范式就是靠这些空白活命的。
图 4 · 责任 × 时序矩阵
← 手机端可左右滑动查看整张图纸 →
注意右下角那个红框：那不是补充说明，是反例对照。如果你把整套做成了「共享一个脑子、大家共同编辑」，出事的顺序会精确地是这样 —— 第三步开始推演过程消失，第五步没有仲裁者，第六步查不出出处，第七步读到两条互相矛盾的事实却不知道该信谁。
08能撑多大：7 个扩展维度
一句话：朋友该问的不是「现在能干嘛」，而是「我加了第 11 个 Agent、换了第 3 个模型、搬了第 2 台机器，它会崩吗」。逐维度给现状、瓶颈、扩展路径与触发条件。
| 维度 | 现状 | 瓶颈会先在哪炸 | 扩展路径与触发条件 |
|---|---|---|---|
| 1 角色规模 N 从 1 → 10+ |
实测 现有 4 类业务角色（写作 / 审稿 / 技能库 / 运维），记忆层用 user_id 区分 | 软隔离 → 角色一多，「谁看得到谁」全靠自觉；人格混进公共区的风险随 N 线性上升 | N ≤ 3：约定隔离够用 N 4–10：上角色令牌 + 每 N 一个命名空间 N > 10：确权者分域（按翼 / 按项目分片），否则单点排队成瓶颈 |
| 2 部署形态 单机 → 多机 |
实测 2 台云主机 + 1 台办公机；记忆服务云上单份，走 SSH 隧道直连 | 记忆库是单点：云挂了只能降级成本地待推队列，多 Agent 之间的实时协同本来就没有通道 | 阶段 1：隧道 + 单实例（现状够用） 阶段 2：读写分离（读副本 + 单写主） 阶段 3：远端提案（MCP/A2A），跨机用「提案同步」而不是「库同步」 |
| 3 模型可换性 | 文档称 模型层可插拔：换模型/换后端只改环境变量；便宜模型抽取 + 强模型审计 | 确权质量取决于所用模型；换模型后「凭什么这么判」的口径会漂 | 把「确权理由」当结构化字段存档（模型可换，判据必须留在库里）；确权者单独配强模型，干活的用便宜模型 —— 成本曲线就压住了 |
| 4 存储规模 | 实测 14,438 条 / 归档率 97.6% / 磁盘 30G 用 1007G / 向量 1024 维 HNSW | 单实例下：向量索引内存、批量蒸馏耗时、归档任务时长 | 10 万条内：单实例够 10 万–100 万：按翼/房间分表 + 冷热分层（冷数据移出向量索引，只留档号+卡片定点召回） 百万以上：分库 + 检索前置缓存 |
| 5 检索通道 | 实测 四路召回 + 五维打分融合；热查 0.08–0.24 秒 | 冷启首次查询要等模型预热（实测 2–9 秒），第一次体验会抖 | 常驻预热；重排序可选；多模态表已留位，未来图片/音频走同一条召回路径 |
| 6 治理与防腐 | 文档称 注入分层（身份红线 > 规则 > 钩子 > 沉寂指针）；溢出先归档留钩子；技能只归档不删除 | 任何「加功能不加消费端」的扩张，都会让上下文被注入塞爆 | 检索评测集防漂移 + 模块准入声明（无消费端不合并）+ 只标记不自动删；把「找得到」做成可量化的仪表盘 |
| 7 多租户 / 对外 | 实测 单实例多租户（user_id）；服务默认只监听本机 | 对外那一刻，网络隔离兜底失效 → 隔离必须从「约定」变「强制」 | 命名空间升级 + 令牌鉴权 + 审计日志；对外只暴露只读消费入口，写入永远留在内网 |
一条总纪律，也是这套系统最值钱的经验：先做减法与仪表，再加重量。不确定的就标记、不删；没有消费端的模块不进主干；小步验证再合并。它让这套东西在一年迭代、1.4 万条记忆之后，依然能一句话说清每条数据是从哪来的。
09会怎么坏、坏了怎么办、要花多少钱
一句话：故障大多是「静默失真」而不是「报错」—— 这是本喵用真金白银踩出来的教训。
失败模式与对策
| 生产不可达 | 写入落本地待推队列，恢复后批量补推（零件在位、当前未启用） |
| 向量服务不可用 | 降级为向量 + 分词 + 时序混合检索；embedding 全挂时接口不可用（已知硬依赖） |
| 注入通道报错 | 静默降级：只返回成功通道，不阻断本轮对话 |
| 上下文被撑爆 | 服务端硬上限（技能 8 / 记忆 10 / 钩子 10），超限自动截断 |
| 集成层字段/位置不一致 | 历史真坑：参数发错位置 → 报错；读错响应字段名 → 不报错只失真。对策：以自描述端点为准 + 契约测试 |
| 误写 / 误删 | 删除是软的、可恢复；写入带来源与档号 |
成本结构
| 检索 / 召回 | 本地服务，查询本身不花钱（除可选重排序/审计模型） |
| 写入蒸馏 | 双模型分工：便宜模型抽取 + 强模型审计 → 只有关键路径花钱 |
| 常驻注入 | 按需注入：不相关的知识走触发召回，不占常驻上下文 |
| 服务器 | 2 台云主机（记忆服务 + 站点），磁盘占用极低（30G / 1TB） |
| N+EN 新增 | 阶段 1 增量几乎为 0：1 张表 + 2 个端点 + 一个专用角色，不新增服务器 |
本喵踩过最贵的坑是「语义等价 ≠ 可用」：工具参数换个位置、响应字段换个名字，程序不报错，只是悄悄取默认值。排查这种坑最省事的办法不是加日志，而是让服务自己把契约说清楚，并且用测试把它钉死。
10从今天到 N+EN 的四步
一句话：顺序刻意做成「每一步都能单独停下来、且停在哪都不算坏」。性价比最高的是第一步：不需要新机器，只需要一张表和一次角色定义。
图 5 · 四阶段演进路线
← 手机端可左右滑动查看整张图纸 →
11市面方案各答对了哪一块
| 方案 | 定位 | 它强在哪 | 相对 N+EN 弱在哪 | 与 N+EN 的关系 |
|---|---|---|---|---|
| Mnemosyne OS 本文实测对象 |
单 Agent 认知型记忆 OS | 宫殿组织 / 三通道召回 / 生命周期与热度 / 蒸馏管道扎实 | 多 Agent 协同未做；行级隔离够不上「Agent 间确权」 | 是 N+EN 里私有记忆这一层的参考实现 |
| 腾讯 TencentDB Agent Memory | 团队共享记忆资产平台 | 分层资产（对话/原子事实/场景知识/长期画像）+ 平台代管路由与权限 | 偏「平台把资产直接开放共享」，不是「本地私有 + 提案 + 确权」 | 走了另一条路：平台强约束；N+EN 靠流程确权 |
| Mem0 一类 | 抽取-检索型记忆 | 事实抽取强、接入轻 | 组织 / 确权 / 审计弱 | 可当私有记忆的轻量替代，不解决公共层 |
| MemGPT / Letta 一类 | 把记忆当操作系统分页管理 | 自我读写记忆、上下文管理强 | 多 Agent 间确权弱 | 管的是「一个脑子内部的页表」，同样不解决公共层 |
| GitHub PR 模型 类比，非产品 |
人类协作的正解 | 分支 + 提案 + 冲突并存 + 维护者合并 + 全历史 | 需要「维护者」这个角色（对应 EN） | N+EN 就是把它搬到 Agent 上，把人换成 AI 确权者 |
一句话结论：这些方案各答对了一块，但没有一个现成方案完整给出「私有记忆 + 提案登记 + 批注并存 + 确权者 + 只读日志」这套闭环。这也是它值得自己动手的原因。
12动手前先答这 15 个问题
一句话：逐条手写答案，答不上来的地方就是你的第一个施工点。每问后面跟的是「没想清楚会出什么灾难」。
| # | 自检问题 | 没想清楚会怎样 |
|---|---|---|
| 1 | 专属记忆的边界画在哪？（哪些永远不出本 Agent） | 人格与草稿漏进公共区 → 角色串味，且再也分不回去 |
| 2 | 确权者能不能改业务结论本身？ | 确权者越界就成了「隐形的主 Agent」，责任链断掉 |
| 3 | 并发提案怎么排队？登记号谁发？ | 两份提案互相覆盖 → 推演过程消失，事后无法复盘 |
| 4 | 项目工作区与只读日志是否分开？ | 「可写的协作区」与「不可改的档案」混成一锅 → 档案被改，可信度归零 |
| 5 | 只读日志的写入权限、时机、防擦除策略是什么？ | 日志可被任意覆盖 → 出事时查不出「谁、何时、凭什么」 |
| 6 | 写基线的唯一入口在哪？谁能绕过它？ | 存在旁路 → 确权形同虚设 |
| 7 | 冲突的判定规则是什么？ | 识别不出冲突 → 两条矛盾事实长期并存，系统无法自洽 |
| 8 | 驳回的提案留不留？留多久？ | 删掉驳回记录 → 同样的错会再犯，而且没人知道自己错过 |
| 9 | 已确权结论如何作废？（只追加还是可改） | 直接改写 → 历史被抹，审计失效 |
| 10 | 遗忘/衰减策略是什么？公共结论会不会被自动淡化？ | 基线被热度引擎误伤 → 重要口径「沉底」，新 Agent 读不到 |
| 11 | 召回排序怎么定？多路通道的权重怎么配？ | 纯向量召回 → 该精确命中的找不到，Agent 开始重复劳动 |
| 12 | N 与 EN 之间的传输协议是什么？（接口 / MCP / A2A） | 每接一个新 Agent 都要写一套胶水 → 扩展成本线性上涨 |
| 13 | 权限模型是约定级还是强制级？ | 靠自觉 → 第 5 个 Agent 上线那天就串号 |
| 14 | 失败时的降级路径？（读不到 / 写不进 / 确权不了） | 一处故障拖垮全局；或静默失真，比报错更危险 |
| 15 | 怎么量化「找得到」？有没有评测集与漂移告警？ | 优化全靠感觉 → 越迭代越慢，且说不清慢在哪 |
13这些数字是怎么来的
一句话：能复现的才算事实。本节列出本次现场的验证项与原样结果，任何人都能复核。
| 验证项 | 怎么测的 | 结果 |
|---|---|---|
| 服务在跑吗 | 云侧 systemd 状态检查 | active |
| 版本 | 健康检查接口 | {"status":"ok","version":"7.8.3"} |
| 记忆总量 / 分级 | 统计接口 | 14,438 条；L1 44 / L2 11,905 / L3 2,380 / L4 109；软删 572 |
| 宫殿归档与卡片 | 宫殿状态接口 | 归档 14,159 / 97.6%；著录卡片 14,416 |
| 路由数量 | 源码装饰器统计 | 57 个（主入口 48 + 注入 1 + 安全 4 + 技能 4） |
| 自描述覆盖度 | 服务自描述接口 | 27 条 → 与源码 57 条不一致（门面滞后） |
| 召回通道 | 宫殿召唤接口 | 返回四路：summon / guide / resonate / wiki |
| 热查延迟 | 三次取样计时 | summon 0.236s / search 0.240s / 热度榜 0.082–0.124s |
| 冷启延迟 | 同上，首次调用 | summon ≈2.19s；搜索 9.13–9.48s（含模型预热） |
| 操作日志 | 轨迹接口抽查两条记忆 | 空数组 → 轨迹未填充 |
| 端云同步 | 检查本地缓存库与队列 | 文件 0 字节、无表 → 零件在位、未启用 |
| 数据库 | 云侧版本与磁盘检查 | PostgreSQL 18.6；根分区 30G / 1007G |
| 桥接与工具数 | 进程检查 + 工具清单 | 常驻 3 个桥进程；暴露 15 个工具 |
| 数据表清单 | 结构统计 | 15 张：memories / memory_traces / entities / memory_entities / beliefs / wiki_pages / wiki_versions / wiki_entities / media_memories / tmt_* / users 等 |
诚实归因（这节别跳过）：
- 实测：服务状态、版本、记忆条数与分级、归档率、路由数、四路召回、延迟数字、轨迹为空、同步未启用、数据库版本与磁盘、桥进程与工具数、表清单。
- 文档称：「50+ 端点」的表述、端云同步的设计意图、模型可插拔与双模型分工、注入优先级规则、记忆三型与遗忘观的口径。
- 推演：N+EN 五层定义、责任时序、缺口清单、四阶段路线、7 个扩展维度的瓶颈判断。
- 未验证：云侧数据库内部表结构与行数（未取库凭据，只做接口侧证）；N+EN 公共层当然也没有可验证的实现。
14术语速查
| 术语 | 一句话定义 |
|---|---|
| N+EN | N 个干活的业务 Agent + 1 个不干活、只负责整理与确权的 Agent（10 个干活 → 系统里其实跑 11 个）。 |
| 分布传输式同步记忆 | 每个 Agent 有自己的脑子，公共区只放已确权成果；过程靠登记与批注，最后统一确权 —— 本质是「同步」，不是「共享」。 |
| 确权 | 由专职角色决定多份冲突提案里哪一份成为唯一有效版本，并留下判据。 |
| 变更提案 | 干活的 Agent 对外唯一的动作：把「自己认为定稿的东西」打包交出，不能直接改公共区。 |
| 批注式并存 | 并发写入不互相覆盖，全部留存，像给同一段文字贴不同批注，等仲裁者裁。 |
| 登记制 | 用「按顺序登记」解决并发，而不是行锁 —— 因为冲突是观点不一致，锁判不了谁对。 |
| 标准记忆 | 同步库里的公共成果：任何 Agent 都从这里拉，而不是去某个 Agent 那里拉。 |
| 操作日志 | 只追加不覆盖的改动记录，回答「谁、何时、凭什么」。 |
| 三通道召回 | 点名（精确）→ 引导（按分类收窄）→ 共鸣（向量语义兜底）；实测还多一路知识库通道。 |
| 宫殿 / 档号 / 著录卡片 | 记忆的空间化组织：翼→房间→书架→书卷；档号即位置，卡片是检索入口，原文另存。 |
| 永恒分级 | 永久 / 长期 / 短期三档生命周期（实测分四档热度梯队）。 |
| 存储强度 / 提取强度 | 记忆不真丢（存储强度不衰减），只是暂时找不回来（提取强度可恢复）。 |
| 情节 / 语义 / 程序记忆 | 写入时就分型：发生了什么 / 什么为真 / 怎么做（对应技能）。 |
| 端云容灾 | 本地缓存 ↔ 云端数据库的断网续传 —— 它解决的是可用性，不是多 Agent 协同。 |
信息来源与核对日期
- 实测数据：本喵于 2026-09-15 在自有 Mnemosyne OS 生产实例（v7.8.3）上直接调用接口与检查服务状态所得，见第 13 节逐项清单。
- 范式部分：来自本喵与朋友关于「多 Agent 记忆怎么组织」的讨论整理，以及已发布的《多 Agent 记忆别做成「共享一个脑子」》一文：N+EN 分布传输式同步 + 一份认知标准提示词。
- 市面方案描述：基于公开资料与产品文档的定位性描述，不评优劣，具体能力以各家当期官方说明为准。
- 口径提醒：文中所有数字都是本喵这套系统的现场读数，用于说明「一个个人规模的多 Agent 环境大概长什么样」，不代表任何产品的性能承诺。技术细节与判据本人保留，转载注明出处即可。
苏公网安备32011502013954号