📌 项目地址：vectorize-io/hindsight | ⭐ 15,093 颗星 | 🔧 Python | 📜 MIT
agent 对话一长就容易失忆。大多数记忆系统解决的是“把之前聊过的内容找回来”，Hindsight 想解决的是另一件事：agent 怎么从过去的经验里提炼规则，下次直接用。
“记住”是把旧文翻出来，“学习”是从旧文里沉淀判断。README 里原话是：“Most agent memory systems focus on recalling conversation history. Hindsight is focused on making agents that learn, not just remember.”这两者的差异，决定了 Hindsight 的技术路线跟常见的 RAG 方案完全不同。
为什么 RAG 和知识图谱做不到“学习”
RAG 的流程是向量召回相关片段，拼回 prompt。问题是，召回来的内容是原始对话记录，没有提炼。比如用户三次在同样场景下纠正了同样的错误，RAG 三次都能检索到，但 agent 还是可能第四次犯同样的错，因为它看到的是零散记录，不是“在这种情况下的统一结论”。
知识图谱擅长结构化关系抽取，但对话里的隐性经验很难抽成三元组。比如一个用户说“我发文件给你的时候，默认先压缩再传”，这是经验，不是事实关系，知识图谱很难处理。
Hindsight 的做法是让记忆以结论的形式沉淀，而不是以原始记录的形式保存。这跟“翻聊天记录”是两码事。
LongMemEval 第一，但更值得注意的是复现方式
README 说 Hindsight 在 LongMemEval benchmark 上达到了 state-of-the-art。LongMemEval 是评估对话 AI 长期记忆能力的常用基准，覆盖多种会话场景。
比排名更有意思的是这句话： “The benchmark performance data for Hindsight has been independently reproduced by research collaborators at the Virginia Tech Sanghani Center for Artificial Intelligence and Data Analytics and The Washington Post. Other scores are self-reported by software vendors.”
弗吉尼亚理工大学 Sanghani Center 和华盛顿邮报的研究人员独立复现了 Hindsight 的成绩。其他同类系统的分数是厂商自己报的。这个复现细节在 arXiv 论文（编号 2512.12818）里可以查。
一个开源项目愿意让人独立复现 benchmark，这个动作本身就比分数可信。
接入方式：自动 wrapper 和手动 API，两条路
LLM Wrapper 是最省事的接入方式。
README 说 2 行代码就能把当前的 LLM client 换成 Hindsight wrapper。之后每次 LLM 调用，记忆的存储和检索自动完成。你不用管什么时候存、什么时候取，它自己处理。
这个方式适合已经有 agent 跑起来、想快速加记忆能力的团队。代价是你把记忆策略的控制权交给了 wrapper，具体怎么触发存储、怎么决定召回，要看它的内部逻辑。
手动 API 适合需要精细控制的场景。
如果你想知道“为什么这个时候存储记忆”“为什么召回这几条而不是那几条”，可以用 SDK 或直接 HTTP 调 API。README 说这套 API 简单，参数细节在官方文档里。
对 coding agent 还有一个便利功能。README 提供了文档 skill，装完就能在 IDE 里直接查文档：
npx skills add https://github.com/vectorize-io/hindsight --skill hindsight-docs支持 Claude Code、Cursor 等工具。
部署：一条 Docker 命令跑起来
官方推荐 Docker 方式，README 给的命令：
export OPENAI_API_KEY=sk-xxx
docker run -it --pull always --name hindsight --restart unless-stopped -p 8888:8888 -p 9999:9999
-e HINDSIGHT_API_LLM_API_KEY=$OPENAI_API_KEY
-v hindsight-data:/home/hindsight/.pg0
ghcr.io/vectorize-io/hindsight:latest跑起来后 API 在 8888 端口，UI 在 9999 端口。数据存到 Docker volume hindsight-data 里，容器删除数据不丢。
LLM provider 可以换，设置 HINDSIGHT_API_LLM_PROVIDER 环境变量。README 列出的合法值：openai、anthropic、gemini、groq、ollama、lmstudio、minimax、atlas。
ollama 和 lmstudio 出现在列表里，说明官方支持本地模型。数据不用出机器，对敏感场景有意义。
Hindsight 已经在 Fortune 500 企业的生产环境里跑着，这个在 README 里有写。
三个没人替你评估的问题
第一，token 成本。Wrapper 自动做记忆存储和检索，每次 LLM 调用背后多一层处理。README 没给 token 估算数字，因为实际开销跟你的 prompt 长度、调用频率、记忆提取策略强相关。我建议先小流量跑一段时间，看真实账单再决定要不要全量接。
第二，自动提取的不可见性。Wrapper 自动判断什么时候存、什么时候取，这个判断逻辑你看不到。如果 Wrapper 存了不该存的，或者没存该存的，你只能通过结果反推。需要精细控制的场景，手动 API 更适合。
第三，生产环境的数据安全不等于模型调用安全。很多部署数据在本地只解决了一部分问题。Hindsight 本身依赖 LLM 做记忆提取，如果你用的是 OpenAI，对话内容还是要发到远端 API。数据敏感程度高的话，得搭配本地模型（ollama 或 lmstudio）一起用。
我的结论
agent 落地的长期记忆是个真问题，Hindsight 的价值是把答案开源出来，给了一个标准化的接入方式，而不是让每个团队自己拿 RAG 拼 prompt 去试错。15,093 个 star、独立复现的 benchmark、MIT 协议——三个条件都满足，值得花一小时跑一遍。
但“跑一遍”和“上生产”是两回事。调用频率低、对话轮次少的应用，用不用 Hindsight 差别不大。对话多、需要从历史里学经验的应用，值得认真测一测。