为 Agent 选记忆引擎：我为什么选了 Hindsight

一个月前我开始跑 Agent。我不是做研究，是在生产环境里搭一套能用的 Agent 治理体系。结果第一个月踩了 160 多个坑。

这些坑我得记下来。不记等于白踩。

于是问题来了：用什么存这些记忆？

这不是一个技术选型问题，是一个生存问题——你每天新增几十条踩坑记录、项目决策、产品知识，如果存储方案选错了，后面迁移一次哭一次。

我花了三天调研了五个方向，最后选了 Hindsight。这篇讲讲为什么。

我的需求是什么

先说我到底要存什么：

• 踩坑记录：COS 上传从 12KB/s 优化到 3.87MB/s 那条路是怎么走通的
• 项目决策：为什么用自研治理框架而不是再买一套商业方案
• 产品知识：产品的权限模型差异
• 配置快照：Hindsight v0.7.2 到 v0.8.0 的升级参数

一个月累计了 300 多条。每条都不长（几十到几百字），但相互之间有引用关系——比如「COS 加速方案」依赖「Hindsight 升级踩坑」里发现的存储引擎变更知识。

所以我的要求就三个：

1. 能存结构化的东西 — 纯文本不够，要能打标签、关联、版本化
2. 能自动关联 — 不用我手动维护"这篇引用那篇"的关系
3. 轻量 — 我不想为了记几百条笔记起一套微服务

我看过的方案

方案一：自己写文件存储

最直接的方案。JSON 文件一写，完事。

试了三天发现问题了：

• 查询靠 grep — 想找"所有跟 COS 相关的事实"，要么 grep 关键字要么全文扫描
• 关联靠手动 — 一条记录改了，跟它相关的十条全得自己追着改
• 版本化靠 git — 但 git 不能回答"上周三改了什么"这种问题

不是说不能用，而是随着记录从 50 条涨到 300 条，维护成本线性增长。50 条的时候还行，300 条的时候你就不想碰了。

方案二：Redis

Redis 快，内存操作，毫秒级响应。

但 Redis 的问题是无结构。你要存的不是 key-value 对，是带上下文、带关联、带版本的事实。往 Redis 里塞结构化数据，要么自己序列化 JSON 然后失去查询能力，要么自己搭索引——这不又回到了"自己写存储"的老路吗。

而且 Redis 的数据是易失的，持久化配置不对重启就丢数据。我踩不起这个坑。

方案三：MySQL / PostgreSQL

关系数据库，结构化存储没问题，查询能力强。

但问题是太重了。为了记几百条踩坑记录，我得上一个完整的数据库服务？建表、写 migration、配备份？这套流程走下来，记忆还没记几条，运维配置写了一堆。

而且关系的核心是表结构要稳定。但踩坑记录的知识结构是在演化的——今天多一个"关联产品"字段，明天多一个"严重级别"维度。关系数据库对 schema 变更的代价很高，不适合这种知识结构频繁演化的场景。

方案四：第三方记忆服务（Mem0 / MemGPT 等）

专门做 AI 记忆的服务，看起来很对口。

但我评估下来有两个问题：

第一，数据在别人手里。 我存的是产品参数、客户集成配置、生产环境拓扑——这些东西不可能放到第三方服务上。不是信任问题，是合规问题。

第二，定价不透明。 300 条记忆可能免费，3000 条呢？30000 条呢？这种基础设施级别的组件，如果定价权在别人手里，后面迁移成本会非常高。

方案五：Hindsight

Hindsight 是 Nous Research 开源的一个 Agent 记忆引擎。它的设计思路跟我的需求刚好对上了。

核心能力：

• 结构化记忆：每条记忆可以打标签、关联实体、标注来源。不是 KV 存储也不是全文索引，是介于两者之间的半结构化模型
• 自动关联：存入新事实时自动检测与已有事实的关联，形成知识图谱。你不用手动维护引用关系
• 嵌入式轻量：我用的时候 v0.7.2 默认用 SQLite，嵌入式部署，一个进程搞定，无需单独维护数据库
• 开源可控：代码在 GitHub 上，可以审查、可以改、可以本地部署，数据完全在自己手里
• 检索灵活：支持语义搜索（向量）和关键字搜索（全文索引），两种方式互补

Hindsight 的定位很明确：不是通用数据库，是专门给 Agent 用的记忆引擎。这个定位意味着它不会试图解决所有存储问题，但它解决的那几个问题正好是我的痛点。

五个需求，Hindsight 全部命中。

选型后的代价

选型不是选完就完了，每选一个方案都要承担它的代价。

Hindsight 的代价是：它还在快速迭代中。 而且迭代幅度不小。

我选的时候 Hindsight 还在 Nous Research 名下，v0.7.2 Docker 镜像默认用 SQLite，轻量省事。但没隔多久项目被 vectorize.io 接手，v0.8.0 全面重构，存储引擎换成了嵌入式 pg0（PostgreSQL 的嵌入式版本），API 和配置格式也变了。两个镜像来自不同的组织，SQLite 的数据文件 pg0 不认，数据不向前兼容。

这个代价我选型的时候其实是知道的，但当时我觉得"升级的时候注意一下就行"——结果我高估了自己的谨慎。

关于那次升级我踩了什么坑——下篇说。

选型有据可查，执行有坑要填。接下来是我用 Hindsight 后，一次升级把 300 条记忆干成了 29 条的真实经历。