Agent 的长期记忆系统：跨会话信息持久化设计

AI Agent 会遗忘。不是因为它们懒，而是因为单个对话窗口根本不适合保存你曾经告诉它们的一切。让一个 Agent 跨越数十个会话、项目和知识源持续运行，上周还有用的上下文很快就会消失得无影无踪。

Memory Sidecar（github.com/mage0535/hermes-memory-installer，192★，MIT，Python 3.9+）正是为解决这个问题而构建的。它是一个运行在 Agent 旁边的外部记忆系统，无需修改 Agent 本身——它是一种 sidecar，而不是给 Agent 动手术。

为什么选择 Sidecar，而不是修改核心

要让 Agent 获得长期记忆，有两种方式：

• 修改 Agent 核心——侵入性强，每次升级都可能失效，而且会把你绑定在单一厂商上。

• 运行 sidecar——读取 Agent 的数据目录，归档会话，构建长期知识，并在未来的工作中注入相关的记忆召回结果。

sidecar 方案胜在一个简单的原则：稳定的数据边界。它读取 AGENT_HOME、state.db、会话文件、Hindsight facts、gbrain pages 以及 Markdown 知识笔记，但绝不会触碰 Agent 自身的代码。这意味着，同一套记忆系统可以用于 Hermes、Claude Code、Codex、Cursor，以及任何将数据保存在目录中的 Agent。

sidecar 遵循一个五步循环：

1. 从 AGENT_HOME 读取 Agent 的状态和会话数据

2. 将新会话归档到 gbrain 和会话搜索索引中

3. 重建治理索引和精选知识笔记索引

4. 将分层的记忆召回上下文注入 Agent 的下一轮交互

5. 通过健康检查和验收检查进行验证，让故障始终可见

第 5 步是大多数记忆系统都会忽略的环节，但它恰恰是生产环境中最重要的部分。一个悄无声息地停止归档的记忆流水线，甚至比完全没有记忆更糟，因为你还会误以为它仍在正常工作。sidecar 随附 28 个运行时脚本，包括 sidecar_acceptance_check.py、runtime_drift_check.py、gbrain_stale_maintenance.py 和 alert_queue.py，从而让记忆系统的故障以告警的形式浮出水面，而不是在意外发生时才被发现。

分层召回：Hot、Warm、Cold 与 Curated

仅靠一个位于 prompt 本地的记忆文件，不足以实现持久的记忆召回。Memory Sidecar 融合了四个层级：

其中最值得关注的是 Curated knowledge。将一本操作手册放入 $AGENT_HOME/knowledge/notes，它就能与会话搜索、Hindsight facts 和 gbrain 结果一起参与融合检索。这样一来，项目约定会开始影响未来的每一次回答，而不再局限于那些你记得把约定粘贴到 prompt 里的场景。

三条命令完成安装

git clone https://github.com/mage0535/hermes-memory-installer.git
cd hermes-memory-installer
export AGENT_HOME="$HOME/.hermes"   # or ~/.claude, ~/.cursor, ~/.agent
./install.sh

安装程序在设计上与具体 Agent 无关：它完全由 AGENT_HOME 驱动，会部署 28 个运行时脚本，并支持三种依赖辅助模式（3：自动模式，2：引导模式，1：仅检测模式），同时提供双语输出（--lang en|zh）。

运行要求：Python 3.9+、PostgreSQL 16，以及正在运行且可以访问的 Hindsight 和 gbrain。

它究竟改善了什么

与“单个 prompt 本地记忆文件”这一基准方案相比，它带来了三个具体收益：

• 会话输出会被归档到持久化存储中，而不是随着对话窗口一起消失。archive_sessions.py + session_to_gbrain.py 会把昨天完成的工作转化为明天可用的上下文。

• 记忆召回来自多个层级，而不是单一文件。如果 Hindsight 漏掉了一条 fact，gbrain 中仍然保留着对应的 page；如果 gbrain 的数据已经过时，会话索引中仍然保存着完整记录。

• 知识笔记能够影响记忆召回。项目操作手册、架构决策和 wiki 页面都会成为检索路径中的一等公民。

真正可以审计的生产级加固

当前版本（v3.5.x）主要完成了运维层面的加固，这一点体现在许多细节中：

• 优先 dry-run 的 gbrain 规划——安装程序会先展示它准备执行的操作，然后才真正执行

• 隐私安全的评估注册表——无需泄露数据，即可使用合成记忆和私有记忆进行评估

• 五项质量指标，并支持评估趋势对比

• 增量式治理策略元数据——支持策略有效性检查和冲突检查

• 干净的公开仓库——代码仓库中不包含特定服务器的路径或凭据

有两个运维辅助脚本（memory_watermark.py、memory_snapshot_backup.py）特意没有默认安装——它们是面向 Hermes 的维护脚本，对宿主环境有更强的前提假设。公开提供的安装路径则始终保持通用性。

与 Knowledge-and-Memory-Management 搭配使用

如果需要更完整的知识工作流，可以将 sidecar 与 Knowledge-and-Memory-Management（8★）搭配使用：

• Memory Sidecar = 运行时 + 安装程序（将材料转化为可召回的上下文）

• KMM = 上游采集层（结构化采集流水线、wiki 管理、40 多种摄取工具）

二者结合起来，便回答了整个问题：知识从哪里来，又该如何维护？

记忆并不是一个可以随手拼接到 prompt 上的功能。它是一套运维系统：采集、归档、索引、召回、验证。Memory Sidecar 正是以这种方式看待记忆——可安装、可观测，并且与具体 Agent 无关。如果你让长期运行的 Agent 跨越大量会话持续工作，那么这正是你所缺少的那一层。

本文源自对 Hermes + Hindsight + gbrain + PostgreSQL 生产环境的实际维护经验。项目采用 MIT 许可证，欢迎反馈和贡献。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。