我让三个Agent共享了同一套记忆系统

大象AI共学

938人浏览 · 2026-05-27 21:33:34

大象AI共学 · 2026-05-27 21:33:34 发布

文章信息

预计字数：3200 字阅读时间：10 分钟难度等级：⭐⭐（小白友好，无需技术基础）

核心价值：Hermes 的 memory 又满了！从架构搭建到具体命令，手把手教你让多个 Agent 共享同一套记忆

你有没有遇到过这种情况：

在 Hermes 里总结了一条飞书 Token 刷新的经验。

转到 Codex 写代码，遇到同样的问题，它完全不知道 Hermes 那边已经搞定过。

同一件事，换个 Agent 问，就变成了"这是个新问题"。

这不是 Agent 的问题。

是你的记忆被分割了。

三个 Agent，三本不同的通讯录，谁也不知道别人记了啥。

我花了点时间，让我日常用的三个 Agent 系统共享了同一套记忆。

Hermes 记住的经验 Codex 直接查，Codex 学到的技巧进入我的知识库，所有内容自动同步到 Obsidian。

三个系统，一个数据库，一套记忆。

先说一个反常识的观点

🎨

记忆不是 Agent 的问题，是存储的问题。

每个 Agent 都有自己的记忆，但各存各的。

就像你手机存一份通讯录、电脑存一份、笔记本存一份，搬家全乱了。

Hermes 有内置记忆功能，能记住你的偏好。

Codex 也有。

但各存各的。

但都有上限，内容一多就记不住了。写着写着你就发现：Memory 满了！

然后我开始用 Obsidian 记所有东西。

Hermes 写代码时发现的经验，记在 Obsidian。

Codex 调 API 发现的坑，也记在 Obsidian。

按理说 Obsidian 是唯一事实源，没问题。

问题出在：Agent 们不会主动去读 Obsidian。

Hermes 有自己的记忆系统，启动时自动加载，但不会定时去 Obsidian 翻文件。

Codex 也一样。

结果就是，我辛辛苦苦写在 Obsidian 里的那些经验，对 Agent 来说是透明的。

它知道。

但另一台 Agent 不知道。

三层，不是一层

后来我搭了三级记忆系统。

听起来挺唬人，其实就是三个层次：

L1：会话摘要。
- 每次聊完天，系统自动生成摘要。
- 今天聊了什么，解决了什么，有什么新见解。
- 像聊天记录的目录。
L2：结构化知识。
- 从多段聊天里提炼出可复用的经验。飞
- 书 Token 怎么刷新、代码脱敏要清哪些路径、公众号文章的破折号不能超过几处。
- 像操作手册。
L3：核心洞察。
- 把多个经验聚合成做事的原则。
- 信息一致性铁律、Cron 自动化设计原则。
- 像做事的方法论。

🎨

三级记忆的关系：

L1 是原料（今天聊了什么）
L2 是成品（提炼出的可复用经验）
L3 是经典（多条经验聚合成做事原则）

每天自动从原料里挑出好的，加工成成品，再从成品里提炼出经典。

感兴趣的伙伴可以移步阅读：https://wcnoxi4wqsvx.feishu.cn/wiki/FeUGw4TLSioEcukigc2cqiNpnnb?from=from_copylink

真正的难点是共用

三级记忆系统本身不复杂。

真正的难点是让多个 Agent 读同一个数据库。

我的做法在这张图里：

核心就一句话：数据放一个地方，谁想查谁查。

SQLite 数据库存在 `~/.hermes/state/state.db`。

所有 Agent 读同一个文件。

Hermes 通过插件接口直连，Codex 通过命令行查。

实操：三步跑起来

如果我自己重新搭一遍，我会这么做：

第一步：建数据库和查询脚本

你不需要从零写。

核心就两个文件：

# 1. 数据库操作脚本 
memory_tiered.py    # 读写数据库、蒸馏、衰减、同步

# 2. 查询脚本（给其他 Agent 用）
memory_query.py     # 只查不写，简单干净

第二步：查询脚本的使用

查询脚本的用法极其简单：

# 案例：

# Codex 想查 Hermes 那边积累了哪些"飞书上传"经验
python3 /Users/dx/Hermes-agent/memory/memory_query.py search 飞书上传

# 输出：
# [L2-45] 飞书Token每分钟限500次
# [L2-22] feishu doc create参数详解
# [L2-12] 飞书Block API创建Callout流程

就这么一句话。Codex 每次启动都会读到，遇到不确定的事，先查再行动。

对非技术同学的翻译：

你不需要懂 SQLite 是什么。它就是个文件。

你的 Agent 们共享一份"经验笔记本"，谁遇到新问题就往上记一笔，谁需要经验就翻一翻。

第三步：搭自动化蒸馏管道

这是让系统真正"活起来"的关键。我设了 4 个定时任务，凌晨 3-4 点自动跑完：

时间 | 做什么 | 效果

02:00 | 自动抓取当天的聊天记录，提炼摘要 → L1 | 每天一条，不用手写
03:00 | 从 L1 里挑出有价值的内容 → 升级为 L2 | 有价值的经验自动沉淀
03:10 | 把数据库里的全部记忆同步到 Obsidian | 人能直接用文件管理
04:00 | 把多个 L2 中的通用经验 → 聚合成 L3 洞察 | 从经验升级为原则

全程不需要我动手。

每天早上起来，打开 Obsidian，多了几个新文件。

这就是我之前说的那个冷知识：我不写日报，Agent 帮我写。它每天都会沉淀有价值的内容。

三个实实在在的好处

用了大概一个多月了，说几个真实感受。

第一个，不再问重复的问题。

以前用 Codex 写代码，遇到一个 Python 缩进问题，查了一早上解决。

过两天 Hermes 遇到类似的配置问题，又得查半天。

虽然是不同 Agent，浪费的是我的时间。

现在 Codex 查到的经验自动进 L2。

Hermes 直接搜到，不需要我解释上下文。

第二个，长尾知识的利用率提升了。

有些知识一年用不了几次——比如代码脱敏要清理哪些路径、Obsidian 目录变更后要同步几个文件。

东西不大，但找不到的时候特别痛苦。

三级记忆相当于给这些零碎知识开了个公开仓库。

不管哪个 Agent 写过的，所有 Agent 都能查。

📍

真实数据：

L1=24 条（每日会话摘要），L2=93 条（可复用经验），L3=20 条（核心洞察，分 11 个分类）。

每天还在增长。

第三个，审计变得简单。

L3 只有 20 条，每一条都经过多次验证。

我做决策时会先翻 L3：这件事有没有对应的原则？有，就不需要从头想。

✏️

举个例子：L3 中有一条叫「唯一事实源+多处映射」原则。

所有记忆只维护一个版本，Hermes、Codex、Obsidian 都是读取端，不是存储端。

这条原则来自我踩的一个坑：

同一份铁律在 Hermes 和 Codex 各写了一份，更新了一边忘了另一边，导致上传失败。

后来归纳为一条洞察，所有决策先问自己"这个知识只有一份吗"。

踩的那个大坑

说到坑，分享一个真实的。

为了让 Codex 也能查到飞书上传的铁律，我把它写进了 Codex 的启动文件。

过了两天在 Hermes 这边更新了，忘了同步给 Codex。

结果 Codex 还在用旧版本，上传失败。

消息漂移了：一份配置在多个系统里有不同版本。

❌

信息漂移比 bug 更致命。

功能 bug 遇到了能马上修。信息漂移往往出错后才意识到，而且已经错了好久了。

一份知识在多个地方维护，改了一处忘了另一处，迟早出事。

我给自己定了一条铁律：唯一事实源原则。

三级记忆是所有记忆的唯一存储点。

Hermes、Codex、Obsidian 都是读取端。

改的时候只改数据库，不各自维护一份。

同步是自动的，不需要手动复制粘贴。

这听起来像常识，但我是在教训里才真正理解的。

Agent 之间的信息漂移比功能 bug 更致命。

功能 bug 遇到了能马上修，信息漂移往往出错后才意识到，而且已经错了好久了。

你需要怎么做

如果你也想试试，我建议从最简单的方式开始：

第一步：选一个存放点。
- Obsidian、Notion、飞书、本地文件夹，都可以。
- 条件是人和 Agent 都能读。
- 人能打开看，Agent 能通过命令行查。
第二步：建一个查询脚本。
- 不需要搞三层记忆。
- 只需要一个脚本，能让 Agent 通过关键词查到你的知识库内容。
- 10 行代码就能搞定。
第三步：告诉 Agent "先查再动"。
- 在启动模板里加一行指令，让它遇到不确定的事先查知识库再行动。