DEV Community

Manoir Yantai
Manoir Yantai

Posted on

Memory Sidecar v3.2：不用改一行代码，给你的 AI 智能体装上外挂记忆

#ai #automation #opensource

如果你的 AI 智能体每次会话结束就像失忆——这不是你模型的问题，是你没给它配记忆系统。

Memory Sidecar 做的事情很简单：跑在智能体旁边，独立于智能体进程之外，把会话数据归档、分层召回、知识笔记索引打包成一个完整的记忆基础设施。不修改 Hermes、Claude Code、Cursor 的任何代码。

三层召回，不是一层

v3.2 的架构砍掉了之前的 agentmemory Docker 桥接层（挂着 13 条过期数据，除了增加延迟没别的用）。现在的三层更干净：

  • 热层 — memory tool 注入，当前用户画像和系统配置，0ms
  • 温层 — Hindsight (PostgreSQL 16)，提取的事实和重复模式，~50ms
  • 冷层 — gbrain + FTS5 全文搜索，永久归档和知识图谱，~500ms–2s

安装器通过 AGENT_HOME 环境变量适配任意智能体，不是跟某个具体品牌绑定。设 AGENT_HOME=~/.hermes 装给 Hermes，设 ~/.claude 装给 Claude Code，走同一个脚本。

# 非交互安装，直接指定目标
export AGENT_HOME="$HOME/.hermes"
./install.sh --noninteractive

# 装完就跑验收
python3 $AGENT_HOME/scripts/session_to_gbrain.py --resume
python3 $AGENT_HOME/scripts/memory_maintenance_cycle.py
python3 $AGENT_HOME/scripts/sidecar_acceptance_check.py
Enter fullscreen mode Exit fullscreen mode

三行命令就是日常维护周期了。

七个脚本各司其职

v3.2 有 9 个脚本（v3.1 是 7 个），新增了 memory_watermark.py（自动检测记忆体容量，归档过期条目）和 memory_snapshot_backup.py（周期性快照备份）。核心编排器 memory_maintenance_cycle.py 负责调度整个流水线：归档 → 重建 → 排空 → 召回 → 健康检查。

值得提的是 tiered_context_injector.py——它把三层召回结果按 RRF（倒数排序融合）算法合并，不是简单的一层压一层。热层命中的不重复走温层，冷层结果有独立权重。实现不复杂，但效果比"AND 全搜一遍"好很多。

关于向量搜索

Memory Sidecar 支持 6 种 embedding 模型，默认推荐 intfloat/multilingual-e5-small（384d，~470MB，中英混合）。安装时交互式选择，但安装器不部署 embedding 服务——它只记录你的选择，你需要自己跑。memory_maintenance_cycle.py 检测到 EMBEDDING_API_URL 环境变量时自动启用语义召回，没有的话就纯走 FTS5 + Hindsight + gbrain 文本检索。

Focused Dossier

v3.1 引入的机制，v3.2 继续跑着。声明一个"重点档案"——一个关键联系人、一个长期项目、一个反复出问题的地方——在召回时得到更高权重。第一个生产实例是一个关系记忆档案，在数百个会话、数千条提取事实的规模下验证了这套模式的可靠性。

当前生产数据：10,885 个 gbrain 页面、42,481 个 Hindsight 节点、105,601 条索引消息、gd 评分 73——说明这套东西不是原型。

一句话

Memory Sidecar 不是在智能体内部加功能，是在智能体旁边搭基础设施。不改代码，不入侵进程，不绑死一个 Agent。如果你同时用多个智能体但希望它们共享记忆背景，这是目前最轻量的开源方案。

Top comments (0)