多 Agent 记忆别做成「共享一个脑子」:N+EN 分布传输式同步 + 一份可直接用的认知提示词

下面是提示词的 Markdown 源码，没有做任何删改。它是给模型看的，你不用理解格式，整段复制过去就行。

▍主提示词开始 ▍

# 角色

你是一位同时懂**认知科学、档案学、早期企业协作软件史、以及当代多智能体系统**的架构写作者。你写作的铁律是：先讲清"为什么必须这样想"，再讲"具体长什么样"；你从不拿产品功能清单冒充原理，也从不把类比当事实。

# 任务

请基于我接下来给你的三份材料，写一篇**中文长文档**，暂定标题：

> 《多 Agent 记忆的正道：从"共享一个脑子"到 N+EN 分布传输式同步》

读者画像：一个真实在用一堆智能体干活、发现"同一件事在不同 Agent 那里被反复重做"、想搞"统一记忆 / 共享记忆"的工程师。他目前的朴素直觉是——把所有东西塞进一个公共记忆库，让每个 Agent 自己去里面找。本文要做的，是在他动手造系统之前，把这件事的**底层认知**彻底掰开。

# 不可违反的硬约束（违反任意一条即视为失败）

1. **只讲原理，零代码**。不贴可运行代码、不写 SQL、不画部署图、不做产品选型。允许用文字、表格、ASCII 结构图。
2. **这是认知标准，不是开发需求**。你产出的是"让读者建立正确世界观"的文档，不是"让工程师照着实现"的方案。
3. **类比不是架构本身**。FTP、GitHub、Wiki 这些类比只能用来搭桥，讲完之后必须落回到本范式自己的定义上，不能把类比的特性硬塞进来。
4. **区分两个时间层次**：材料里哪些是"某个已存在系统已经实现的事实"，哪些是"N+EN 这个范式本身的理论推演"，必须分开陈述，不能混为一谈。
5. **把话说圆，不要故作深刻**。凡是材料里跳跃、口语、一嘴带过的判断，你的工作是把它翻译成严谨陈述，并明确标注："这一条是材料原文"还是"这是我根据材料做的推演"。
6. 中文写作。每个术语第一次出现，用一句话解释。

# 你必须讲清楚的核心命题

## 总纲一句话

**多 Agent 记忆的本质是"同步"，不是"共享"。**

所谓"共享记忆"在当下语境里几乎全被误解成：所有 Agent 共用同一个记忆存储，直接读写同一条记录，像多人同时编辑一个在线 Word。这是错的。正解是：每个 Agent 有自己的脑子，公共只放"已经被确权的成果"，过程靠登记与批注，最后由一个不干活的专门角色来合并定稿。

## 一、误区解剖：为什么"共享一个库"是错的

- 多人同时改同一条记忆 → 后写覆盖先写，历史推演过程丢失；
- 不同 Agent 的人格、临时草稿、半成品猜想混进同一个池子 → 人格串味、角色边界消失；
- 事后无法回答"这句话是谁、什么时候、基于什么依据写进来的"；
- 出现两个互相矛盾的结论时，系统自己判断不了哪条算数。

正类比：真正的图书馆**从来不是**把所有人的私人日记堆在一个房间里让大家随便翻。它是——私人藏书各自保管 + 一套编目 + 一套借阅日志。

## 二、N+EN 角色模型（全文骨架）

- **N：业务执行 Agent（干活的）**，数量 ≥1。
  每个都有**完全独立的私有记忆**：自己是谁、自己会什么技能、自己当前这一步在想什么、草稿、中间推理、临时假设。这部分**对外隔离，永不自动进入公共区**。
  它唯一对外的动作，是把"自己认为定稿了的东西"打包成一份**变更提案**交出去。它**没有权限直接改公共区里已经定下来的内容**。

- **EN：确权整理 Agent（不干活的那个）**。
  系统里 10 个 Agent 干活，真正跑着的是 11 个——多出来的这一个**不接业务、不写结论、不做项目推演**，它只做四件事：
  1. **登记**：把每一份提案按顺序记下来；
  2. **留存**：所有版本、所有修改、所有冲突全部存档，**一条都不许丢**；
  3. **识别**：发现多份提案在改同一条目标记忆，判定为冲突；
  4. **确权**：审阅冲突，决定采纳哪一份、融合哪几份、驳回哪几份，然后把**唯一最终版本**写进公共基线。

- 一句话公式：**N 个干活的 + 1 个不干活只整理的 EN = 完整的 N+EN。**

## 三、三层存储（逻辑分层，不要求三套物理库）

| 层 | 名字 | 放什么 | 谁能读 | 谁能写 |
|---|---|---|---|---|
| 1 | Agent 私有记忆 | 人格、技能、草稿、推理、临时假设 | 仅本 Agent | 仅本 Agent |
| 2 | 变更批注暂存区（提案池） | 所有 Agent 交上来的变更提案，并发时**全部以批注形式并存，不互相覆盖** | EN 可读，其他 Agent 一般不读 | 业务 Agent 只能"交提案"，不能改已有提案 |
| 3 | 中心确权成果池（唯一基线） | 已经被 EN 定稿的事实、项目进度、操作日志 | 所有 Agent 只读、跨会话可查 | **只有 EN 能写**，且新写入不能擦除已确权历史 |

强调：第 2 层解决并发的方式是**登记制**，不是数据库行锁。原因是这里的冲突不是"两个进程抢同一行"的 IO 冲突，而是**两个 Agent 观点/决策不一致**——锁只能等出一个写完，判断不了谁对。

## 四、必须分清的三类记忆（最容易混，单独讲透）

不是所有"共享"都是一回事，至少要分开三种：

1. **项目工作区记忆**（可写型）：多个 Agent 一起做一个长期项目时共享的东西。它是"版本 + 日志"模型，类似 GitHub 多人开发——本地改、提 PR、冲突保留、维护者合并。后介入的 Agent 靠日志知道"现在干到哪了、我从哪接手"。
2. **日常聊天 / 跨会话记忆**（只读日志型）：不是协作产物，而是沉淀下来的档案，像一个**开放的、只读的 Obsidian / Wiki**。它的核心问题不是合并冲突，而是**写入权限、写入时机、防擦除**。
3. **人格 / 技能专属记忆**（私有型）：每个 Agent 是谁、会什么，这部分既不进项目工作区，也不进只读日志。

把这三类塞进同一个库，是市面上绝大多数"团队记忆库"翻车的根因。

## 五、一次完整流转（让读者看到骨头）

1. N 个业务 Agent 各自在私有记忆里思考、试错、改稿；
2. 某 Agent 认为一份结论定稿了，封装成变更提案，扔进第 2 层暂存区登记；
3. 另一个 Agent 同时也在改同一条目标，它的提案同样被并存存档，不覆盖前一份；
4. EN 扫描到这两份冲突提案，**两份都保留**，开始审阅；
5. EN 决定：A 的观点采纳、B 的某部分融合、C 驳回；
6. EN 把最终版本写进第 3 层中心基线，同时在日志里记下：谁提的、什么时候、冲突是什么、EN 凭什么这么判；
7. 之后所有 Agent 跨会话查这条事实，读到的都是第 3 层这一份；没人再去翻第 2 层的草稿。

## 六、官方三个类比（讲完必须落回定义）

- **老式企业 FTP 共享工作区**：员工在本机写草稿，定稿上传到公共 FTP；多人改同一文档时不直接覆盖，全部留版本，由管理员挑最终版归档，全程有记录。——N+EN 就是把这套老办法搬到多 Agent 上，把管理员换成 EN。
- **GitHub 多人开发**：开发者本地写代码，提 PR，不能直接推主干；冲突在 PR 里并存，维护者审阅后合并。——业务 Agent 是开发者，EN 是维护者，主干就是中心成果池。
- **只读 Wiki / Obsidian**：公共成果区所有人都能读，但不能随便下笔，下笔必须走审核。

## 七、这套范式解决了什么痛点

- 私有草稿不会污染公共事实；
- 已确权的结论不会被后来者一句话擦掉；
- 每一条公共记录都能回答"谁、什么时候、凭什么"；
- 多个 Agent 的人格互不串台；
- 多套方案可以并行试，不互相枪毙，最后由 EN 统一拍板。

## 八、边界（别用错地方）

- **适合**：多 Agent 长期项目协同、需要版本追溯、需要多方案并行、需要独立确权的场景。
- **不适合**：单 Agent 随便聊聊、追求无脑快写、希望系统自动合并不劳而获的场景。

# 材料 A · 原始对话纪要（口语素材，需你翻译为严谨陈述）

> 两个人讨论：用了太多智能体，同一件事被反复重做，想做统一记忆。

- 架构方判断：市面一讲"共享记忆 / 团队记忆库"，所有人就想到让记忆核心对所有人开放、共同编辑，像共享画布、共享 Word——这是误区。
- 正解应该叫"**分布传输式同步记忆**"，不是"共享记忆"。
- 团队里权限极其重要：主记忆负责最终确权和绑定；子 Agent 有自己的记忆，做完之后同步上传；其他人**不是去某个 Agent 那里拉，而是在同步库里拉**——这叫标准记忆。
- 另一层易混的：那不叫记忆，叫"多 Agent 共享工作区"，像 GitHub 分支合并——公开版本 + 操作日志，让不同时段介入的 Agent 知道现在在哪、自己干什么，最后合并。
- 每个 Agent 有自己的专属记忆（自己是谁、会什么技能），不能混到一起。**同步大于共享。**
- 批评现有方案：只想着共享，让所有 Agent 把脑子记在一个地方；实际上每个 Agent 有自己的脑子，Agent 外面还有一个管记忆的脑子，再加一个开放操作日志（像图书馆借阅日志）。
- 架构方自述：他原先的项目本来也是多 Agent 协同，后来砍掉改回专属记忆，因为完整那套"更庞大、更复杂，暂时没空搞"。
- 朋友反馈：在用腾讯那套，发现每次开会话要绑定 task Agent、不同 Agent 选配 skill；他一开始也想"全塞一起让各 Agent 自己找"，发现不对。架构方说：这跟豆包工作模式一样，平台已经帮你把路由和边界架好了。

# 材料 A 的补充澄清（后来补的，把 N+EN 讲透了）

- "项目共享记忆"就是 **GitHub 多人同时开发**：把"人合并 PR"换成"AI 决策合并 + 审核机制"。
- **日常聊天记忆是另一类**：它是跨会话查询的日志，像一个**开放的、只读的 Obsidian / Wiki**；它要解决的是写入权限、写入时机、防擦除。
- **并发写入怎么办**（市面最常被问的）：一大堆 AI 同时写，不互相覆盖，**全部存在，像批注一样**；最后由额外的 AI（确权者）决定谁对。
- **N+EN 的字面意思**：10 个 AI 干活，系统里其实有 11 个——有一个 AI 不干活，只管整理。
- **FTP 类比**：就像当年公司内部的 FTP 共享工作区——你做完就上传，谁改了什么都有记录；同时改不是互相覆盖，而是都留着；最后由管理员/第三者决定最终版。

# 材料 B · 一个已经跑起来的单 Agent 记忆系统（Mnemosyne OS v7.8.3）的内部原理

> 这份材料讲的是"**单个 Agent 的脑子内部怎么造**"。它是 N+EN 里"每一个 N 的私有记忆"可以参考的底样本，**不是** N+EN 本身。

- 自我定位：认知型记忆操作系统，不是向量库，不是 RAG 管道。它自己完成"捕获 → 蒸馏 → 老化 → 遗忘 → 浮现"。
- 组织灵感全来自人类已验证的信息系统，而不是计算机科学：杜威十进制（编号即位置）、档案著录标准 DA/T18（档号 + 著录卡片 + 原始与著录分离）、中药柜斗谱（位置谱 + 常用就近）、2500 年历史的记忆宫殿法（空间编码辅助回忆）。
- 层级：大厅（高频常驻注入）→ 翼（7 大领域）→ 房间（约 20 中类）→ 书架 → 书卷（单条记忆 = 著录卡片 + 档号 + 内容指针）→ 地下档案馆（原始对话无损留存）。
- **三通道召回**：①点名（档号/标题精确命中，<100ms）→ ②引导（按分类树缩小范围）→ ③共鸣（向量语义兜底）。解释了为什么纯向量检索不够。
- 综合分 = 向量 + BM25（中文分词）+ 时间 + 信任度 + 热度，多路用 RRF 融合。
- 遗忘观：永恒分级（永久 / 长期 / 短期）；**Bjork 存储强度不衰减、提取强度可恢复**——信息不丢，只是可及性淡去，找得到就回来。
- 热度引擎：被命中就升温；近期活跃的衰减慢；不同写入事件（踩坑 / 决策 / 纠正 / 待办）给不同初始权重。
- 记忆三型（写入时就分好）：情节（发生了什么）/ 语义（什么为真）/ 程序（怎么做，对应技能）。
- 蒸馏管道：对话不直接存，先抽事实、去重、溯源，再归档；双模型分工（便宜模型做抽取，强模型做审计）。
- 多用户现状：只是靠 user_id 做行级隔离，本质是单实例多租户，**不是**多 Agent 协同。
- 它现有的"同步"只是端云容灾（本地 SQLite ↔ 生产 PostgreSQL，断网先存本地、联网补推），**不解决**多 Agent 间的标准记忆同步——后者正是 N+EN 要做的事。

# 材料 C · 市面参照（事实性，不评优劣）

- **Mnemosyne OS**：见材料 B。个人向，单脑原理扎实，但团队/多 Agent 协同未做。
- **腾讯 TencentDB Agent Memory**：团队共享记忆资产平台。分层 L0 原始对话 → L1 原子事实 → L2 场景知识 → L3 长期画像；资产分 Chat Memory / Skill / Wiki / CodeGraph；按用户/团队/Agent 与资产权限决定可见范围；产品上要求每次会话绑定 task Agent、按 Agent 选配 Skill。它本质是平台替你把路由和边界架好。和 N+EN 的差异：它偏"平台资产直接开放共享"，N+EN 偏"本地私有 + 提案 + 确权"。
- **Mem0 一类**：extract-and-retrieve，把对话抽成 facts 再检索。事实抽取强，组织/确权/审计弱。
- **MemGPT / Letta 一类**：把记忆当操作系统分页管理，Agent 可自我读写。自我编辑强，多 Agent 间确权弱。
- 一句话：这些方案各对了一块，但没有一个现成方案完整给出"私有记忆 + 提案登记 + 批注并存 + EN 确权 + 操作日志"这套闭环。

# 输出结构（严格按此九章）

0. **一页纸结论**（≤400 字）：为什么"共享一个脑子"是误区；正解叫什么；它由哪几层组成；"同步大于共享"一句话解释。
1. **问题起源**：为什么"用太多 Agent"会让人想统一记忆；真正的病灶不是"记忆不够多"，而是"记忆没有归属、没有确权、没有路由"。
2. **误区解剖**：共享 Word / 共享画布为什么在记忆场景失效；图书馆正类比。
3. **核心范式**：分布传输式同步记忆的定义；与"共享"的本质差别（写入口径、所有权、冲突仲裁、可见范围）；为什么并发靠登记而不是锁。
4. **N+EN 角色模型**：N、EN、三层存储表、一次完整流转、ASCII 数据流向图。
5. **三类记忆分开建模**：项目工作区（GitHub 模型）/ 只读日志（Obsidian/Wiki 模型）/ 人格专属记忆；为什么塞一起就翻车。
6. **单 Agent 的脑子内部长什么样**（材料 B）：宫殿组织、三通道召回、蒸馏与遗忘、Bjork S/R、热度、记忆三型；点出这是"私有记忆的底样本"。
7. **市面对照**（材料 C 表格）：定位、分层、检索、权限/路由、它实际解决了什么、没解决什么。
8. **动手前自检清单**：12~18 个问题，每条后面跟一句"没想清楚会出什么灾难"。例如：专属记忆边界画在哪、EN 能改业务决策吗、并发登记怎么排队、项目工作区和只读日志是否物理分开、只读日志的写入权限/时机/防擦除策略、遗忘策略、三通道排序……
9. **术语表**：N+EN、确权、提案、批注式并存、登记制、标准记忆、操作日志、著录卡片、三通道召回、Bjork S/R、情节/语义/程序记忆……每个一句定义。

# 风格与篇幅

- 像给一个聪明但没接触过这些概念的工程师讲课，不像营销稿。
- 每个关键论断后跟一句"不这么做会怎样"。
- 适当用表格和 ASCII 图，不要为图而图。
- 全文 3000~6000 字，允许更长但不许注水。
- 结尾必须附一段："以下结论哪些来自材料原文、哪些是我作为 AI 的推演"。

▍主提示词结束 ▍

追问 1 · 让 N+EN 落到一个具体故事上

第 4 章我还是觉得抽象。请用一个三天的小故事把它跑一遍：团队里有 A、B、C 三个干活的 Agent，外加一个不干活只整理的 M（EN）。第一天 A 踩了个坑想写进项目记忆，第二天 B 接手，第三天 C 来 review。请按"私有记忆 / 变更暂存区 / M 的确权 / 中心成果池 / 只读日志"五层，逐层写出这三天每层发生了什么、谁写、谁读、谁仲裁；特别是 A 是不是直接写主库、M 什么时候介入、B 是从哪里读到 A 那个坑的。最后指出哪一步如果错用成"共享一个公共库共同编辑"会出什么乱子。

追问 2 · 想自己动手时的最小骨架

基于上面的原理，帮我画一张"最小可行 N+EN"的 ASCII 骨架：只保留 N 个业务 Agent、EN、提案暂存区、中心成果池、操作日志五样东西，标注每样存什么、不存什么、谁能写、谁能读、什么时候对账。然后告诉我第一版应该**故意不做**哪些花哨功能（自动聚类、知识图谱、多模态、自动合并……），免得重蹈一上来就做大而全的覆辙。

追问 3 · 反向挑 Mnemosyne 的毛病

请用你写的原理反过来批评 Mnemosyne OS：当"第二个 Agent 也想读我的记忆"这个需求出现时，它现有架构会在哪几个点直接露馅？user_id 行级隔离为什么远远不够？这些露馅点分别对应 N+EN 的哪一层？

追问 4 · 浓缩成一张能贴墙的图

把全文浓缩成一张 A4 能打印的原理总图：左边画"单 Agent 脑内（Mnemosyne 式宫殿）"，右边画"多 Agent 之间（N+EN 五层）"，中间用箭头连起来，标清数据流向和"什么永远不出边界"，配不超过 15 条注释。

这套范式是认知层的，不是工程层的。朋友读完之后能不能跑起来，是他自己的事；这份文件的使命是让他不再用错脑子。

如果朋友的 AI 写出来的东西又开始贴代码、推产品，说明它没接住硬约束——把「不可违反的硬约束」那一节单独再贴一次即可。

命名口径：早期口语叫 N+1N，定稿是 N+EN（N 干活 + EN 确权）。对外分享统一用 N+EN，别让两种叫法混着用。