Hindsight：一个给 AI 装上真正记忆的插件

如果 AI 每次对话都从零开始，那它再聪明也只是一个函数。

我给写作助手接了一套记忆系统，跑到现在三个多月，存了 9000 多条真实记忆——我什么时候说过哪些选题要求、每天的节奏是什么、哪些事踩过坑——全在里面。今天这篇文章，讲讲这套东西到底怎么设计的。

它叫 Hindsight。

一、它是什么

一句话：给 AI agent 装的记忆插件。

它不是你 agent 的一部分，是挂在旁边的独立服务。你的 AI 跟它说话，它负责存；你的 AI 需要回忆，它负责取。agent 本体的代码几乎不用改。

底下就是一个 PostgreSQL 数据库。没有额外的向量数据库、没有知识图谱服务、没有一堆需要运维的组件。 这在 2026 年的记忆系统里算少见的省心。

它支持 25 家 LLM 厂商（OpenAI、Claude、Gemini、各种本地模型、LiteLLM 网关都行），也内置了 MCP，所以 Claude Code、Cursor 这类工具可以直接连。

二、整体架构：一句话看懂

Hindsight 的架构可以理解成三层。

往下拆开讲。

记忆层是重点：三层，一层比一层"想得多"

这是 Hindsight 最核心的设计，也是它跟普通记忆系统最不一样的地方。

用"人做笔记"打比方：

关键在于：它不是只存剪报，它会自己整理笔记。

多数记忆系统停在第一层——存事实、查事实。Hindsight 多了一步：后台自动把零散事实合并成结论。这个过程叫巩固（consolidation），我后面第五节详细讲。

存储层：一张表撑起所有

我直接查过它的数据库。23 张表，但真正的主角是 memory_units 一张。一条记忆长这样：

id            这条记忆的唯一编号
bank_id       属于哪个 agent（隔离用）
text          记忆正文
embedding     向量（1024 维，用来算"意思像不像"）
event_date    什么时候记下来的
occurred_*    事情实际发生的时间
fact_type     事实 / 观察 / 经历
proof_count   这条结论有多少条证据支撑
source_ids    它是从哪几条原始记忆推导出来的
tags          属于哪次会话

这里有个细节值得注意：它把"什么时候记下来的"和"事情什么时候发生的"分成两个字段存。

为什么要分开？因为你今天才想起来"我 2019 年就在用 Linux 了"——写入时间是今天，事件时间是 2019 年。分不开的话，按时间检索就全乱了。

我这套里 writer 这个 agent 的数据分布是这样的：

• 事实：507 条
• 观察：411 条
• 经历：49 条（AI 自己做过的事）
• 心智模型：0 条（后面会说为什么）

观察占了 80%，说明"自动整理笔记"这步是真在跑，不是摆设。

三、机制一：怎么存（retain）

你跟 AI 聊完一轮，Hindsight 拿到的是原始对话：

"上周那个选题你说不行的，太无聊了。我还是想写那个关于内存泄漏的，那个读者会喜欢。"

这句话三个月后你自己都看不懂——什么选题？哪个读者？

Hindsight 存的时候做两件事。

第一，用 LLM 把对话拆成独立的事实句。

上面那段会变成：

• 用户否决了上周的选题，理由是太无聊
• 用户倾向于写"内存泄漏"相关的内容，认为这类题材有吸引力

注意，它不是把原文存进去，而是把原文的意思提取出来，让它脱离上下文也能读懂。这是普通记忆系统和它的第一个分水岭——存原文，三个月后就是一堆没有主语的碎片。

第二，给每条事实分类：

• 世界事实（world）：关于外部世界的，就是上面那两条
• 经历事实（experience）：关于 AI 自己行为的，比如"AI 建议了用 Go"

分类有用，因为检索的时候可以分开对待——你问"我说了什么"和"AI 做了什么"，答案不该混在一起。

四、机制二：怎么取（recall）

取一次，四路同时开火。

我用一个生活化的说法解释这四路各自在干什么：

举个具体例子。我问："我平时用什么设备写稿？"

• 语义通道：理解"设备"和"MacBook Pro"说的是一回事
• 关键词通道：字面找"设备""电脑""写稿"这些词
• 图谱通道：从"写稿"这个动作，连到"我常用的编辑器"，再连到"编辑器装在哪台机器"
• 时间通道：如果我补一句"上个月那台"，它就知道该翻哪段

四路各出一份名单，然后合并成一个。

合并的规则很巧妙，值得单独说：它不看谁分数最高，只看谁的排名靠前。

如果一条记忆在四路里都排第 3、第 5、第 2、第 4，那它一定比"只在语义通道排第 1、其他三路都没出现"的更相关——因为四路都认可它。这个算法叫 RRF，是排序领域的经典老办法，几十年前就有人提了。

合并完还有一步：一个更聪明的模型逐条读"我的问题"和"候选记忆"，判断到底哪个真的对得上，把真正相关的顶上去。这一步比前面的向量计算慢，但准得多。

最后还有个容易被忽略的细节：它会按时间段分桶，保证返回的结果里有过去也有现在。

不这么做会怎样？向量检索有个特性——离你现在的状态越近的，语义上越像。所以搜"我现在是什么身份"，可能十条全是你上个月的旧状态。时间分桶就是强行保证答案里有新信息。

五、机制三：事实怎么长成信念

这是我认为 Hindsight 最值得讲的一节。

前面说的"存"和"取"，很多系统都有。这一步是 Hindsight 独有的。

一个具体例子

三个月的聊天里，你陆续说过：

• "我一直在写 Python"
• "我不太喜欢 Java"
• "我现在主要用 Go"

在只存事实的系统里，这是三条互不相干的记录。半年后你问"我主要用什么语言"，系统可能三条全给你，因为三条语义都沾边。

Hindsight 的巩固流程会把它们合并成一条观察：

用户后端主要使用 Go，早期偏好 Python，对 Java 持负面态度。

一条。带上下文。直接能回答问题。

关键：信念不是被覆盖的，是被改写的

假设十月份你说："我现在转 Rust 了。"

系统不会把上面那句删掉重写成"用户主要用 Rust"。它做的是：

第一步，把原结论改写成带时间的样子

用户早期使用 Python 和 Go，2026 年 10 月起转向 Rust。

第二步，证据计数 +1

原来这条结论有 3 条原始记忆支撑，现在 4 条了。证据越多，检索时排得越前——这个权重是真的在生效的。

第三步，把这次改写完整存进一张单独的表

你哪天问"我一直是怎么看 Java 的"，它能给你讲出完整的演变过程，而不只是"你现在不喜欢 Java"这个结论。

记忆会长大，但不会失忆。 这是我觉得这套设计最漂亮的地方。

顺便说三个工程细节

我翻过它的实现，有三个地方我觉得很聪明，也很想在文章里记下来。

① 状态变化走"改写原条目"，不新建平行条目

官方给的例子：某人卖掉了她的车。

系统不会创建"某人卖车了"这条新观察，而是把原来那条"某人拥有一辆 2019 Honda Civic"原地改成"某人曾拥有一辆 2019 Honda Civic，已于 3 月 15 日售出"。

为什么不新建？ 因为如果新建，半年后你搜"车"，会同时捞到"拥有一辆"和"卖掉了"两条互相矛盾的记录，而且系统不知道哪条更新了。

② 强迫 AI 解释每次决策

每一条新建或改写，都必须附带一句理由，写清楚"我考虑过哪几条已有结论，为什么都不匹配"。

这个理由是用来事后查重的——专门抓那种"明明有一条几乎一样的，却还是新建了一条"的重复。

我觉得这个设计很值得夸：它没有假装 LLM 不会犯错，而是承认会犯错，然后用最笨的办法兜住——你不解释清楚，就不让你过。

③ 提前堵一个会静默出错的 bug

它的提示词里明确写死了一条：同一条结论在一批更新里只能被更新一次。

因为 LLM 经常犯这种错：两条新事实都指向同一条旧结论，它就输出两条更新记录，结果后写的把先写的悄悄覆盖了，没有任何报错。

直接在提示词里堵死。粗暴，但有效。

六、机制四：reflect：不只是查，是真的想

前三个机制都是"取"，reflect 是"想"。

reflect 会启动一个循环，让 AI 可以反复调这几个工具：

• 找心智模型
• 找观察
• 召回记忆
• 深挖线索
• 收口给答案

最多转 10 圈。

跟 recall 的区别在哪？

recall 给你一堆原始事实，你自己判断。reflect 直接返回一个综合过的答案。

用哪个：你要自己拿材料做判断（比如在写 RAG 管道）用 recall；你就要一个答案（比如 agent 在回答用户提问）用 reflect。

代价是延迟——recall 是纯检索，几十到几百毫秒；reflect 要跑大模型，秒级。

顺便说心智模型

心智模型是三层结构最上面那层，用途是"高频问题的标准答案"，读一次就是一次数据库查询，不用调大模型。理论上很快。

但我这套跑了三个多月，心智模型是 0 条。

不是坏了，是场景不匹配。心智模型适合那种"同一个问题被问一万遍"的场景——比如客服机器人回答退款政策。而我这边是写作 + 定时选题任务，问题太长尾，算不出标准答案。

所以如果你看完去部署，心智模型大概率也是空的。真正在干活的是中间那层"观察"，和 reflect 那个多轮循环。

这不是说心智模型没用，是说它是被营销讲得最响的那部分，实际用起来一般。

七、每条结论都知道自己从哪来

这个设计容易被忽略，但我觉得是它跟普通系统拉开差距的第二点。

Hindsight 的每一条观察，都明确记录了它是哪几条原始记忆推导出来的——数据库层面的真关联，不是文本里写句"参考来源 A"应付一下。

我数据库里一条真实记录：

观察：复盘表路径是 /mnt/nas/workspace/选题库/公众号复盘表.md，要填 4 项，发文后第二天补录。

支撑它的原始记忆：2 条
证据计数：2

这为什么重要？

因为它让"AI 说错了"变成一件可以查证的事。你能直接追到原始对话，看它是从哪句话推出来的。

普通 RAG 系统给你 5 段原文，AI 从里面总结出一个答案，你只能选择相信或者不信。Hindsight 给你的是：一条结论 + 明确的证据链 + 每条证据的出处。

还有个更微妙的好处：当新证据进来时，它知道该强化哪条、削弱哪条。 如果新来的事实推翻了某条结论的基础，系统有办法把矛盾标记出来，而不是默默地把两条对立的记忆都留着。

八、怎么装

三种方式，从懒到全：

最懒：包一层

from hindsight_litellm import wrap_openai
client = wrap_openai(
    OpenAI(),
    bank_id="user-123",
    hindsight_api_url="http://localhost:8888",
)

之后所有对话自动记忆自动召回，别的代码不动。底层挂个 LiteLLM，一百多个模型都支持。

中间：直接用 API

三个接口（retain / recall / reflect），官方给了 Python、Node.js、Go 和命令行工具的客户端。

最全：自己部署

一条 Docker 命令，或者直接 pip install hindsight-api 裸装。已经有现成的 agent 框架的话，它还提供了几十个集成。

我这台机器的配置

给你参考个真实的样子：

• 服务：systemd 常驻，用独立的低权限用户跑，不是 root
• 存储：PostgreSQL + 向量扩展，三个月 217 MB
• 事实抽取模型：MiniMax-M3
• 向量模型：bge-m3，1024 维
• 隔离方式：6 个记忆库，每个 agent 一个，互不串味
• 数据量：9267 条记忆、7601 个实体、14 万条实体关系边

14 万条关系边对 9267 条记忆——平均每条记忆挂着 15 条关系。这个密度说明图谱那套是真在跑，不是宣传材料。

九、几点边界

最后说几条用之前该知道的。

它没有权限系统。 没有 RBAC、没有 ABAC、没有用户角色。鉴权只有一个静态 key，而且默认是关的。要做多租户隔离，得自己写扩展。从研究工具到合规生产，这是最大的一道坎。

benchmark 分数要打折看。 它在 LongMemEval 上排第一，这个成绩确实被第三方独立验证过（这点比同行强——其他家的数字基本都是自报）。但要留意：那个分数是在比较宽裕的检索预算下测的，同样精度下 token 成本比某些竞品高。跑分和实际体感是两件事。

抽取这一步没法百分百稳定。 我在自己数据库里发现过，同一批中文记忆里混进了一条英文的——因为抽取时没锁语言。observation 的来源字段也经常填不完整。不影响检索，但别指望它像数据库约束那样严格。

版本要一起升。 我这台机器上服务端和客户端差了半个大版本，目前跑得好好的，但升级的时候最好两边一起动。

写在最后

如果只记住一句话：

Hindsight 做的事，比"存起来能查到"要多一步——它会自己把碎片整理成结论，并且知道每条结论是从哪来的、现在还成不成立。

存记忆不难，难的是让记忆会长大、也会老化、并且能追溯。这三件事做对了，剩下的检索算法、存储方案，甚至那些看起来很土的工程补丁（提示词里堵 bug、用 AI 的自我解释当查重手段），都变得顺理成章。

这也是我觉得它值得单独写一篇的原因——不是分数最高，是它对"记忆"这件事的理解，比多数同类工具深一层。