缘起

开发中我经常需要在不同项目之间同步信息——后端加了新接口，前端和 SDK 要跟进，但它们不在同一个 repo 下，有些上下文只能人工同步给 coding agent。之前一直在想 agent memory 这个方向，索性先做了一个 RememberIt，自己用起来感受一下。它通过 MCP 与 coding agent 集成（remember / recall tools），也提供 REST API 用于主动上报数据。

对于 memory 产品，我考虑了很久。需求看起来有，方案也摆在那里，但最难的其实是数据处理。很多人以为 memory 就是把对话全部存起来，向量存储、文本相似度、知识图谱一股脑用上，记忆功能就算做成了。但最大的难题是数据萃取和检索质量——如果只是把所有数据存起来，结果不外乎 garbage in garbage out。我们真正需要的记忆是从原始信息中提炼出来的「知识」，只有知识才值得保存。而知识本身也可能前后矛盾，重要度也会随时间变化。带着这些思考，我花了两周时间体验和改进 RememberIt。

实际体验

把项目跑起来之后，我发现单靠 MCP tools 很难覆盖所有对话信息，于是用 Claude hook 加了一条主动 ingest 的路径。主动加被动，开发中的对话基本都能保存下来了。但紧接着问题出现了：信息噪音太多，成千上万的对话记录里真正有用的不多；知识图谱的 entity 识别粒度太细，涌现了大量无用实体；每天 token 开销接近一美金。

于是我开始砍数据、提升 entity 识别质量，token 开销降到了原来的三分之一。但最终这笔开销花得值不值？我发现还有一个根本问题：coding agent 主动调用记忆的时机少之又少。除非我主动提示它去 recall，agent 一般不会自己查——哪怕我把规则写进了 Claude 的全局配置也一样。

经过这轮体验，我感受到 memory 产品最大的难点在三个地方：

  • 数据收集：工程化手段可以解决
  • 数据处理：需要持续调优萃取和检索质量
  • agent 主动检索：依赖 agent 自身的机制优化，目前最难突破

memory 是刚需吗

需要独立 memory 服务的典型场景是：开发者在多个项目之间切换，或者用多个 agent 开发不同产品，这时一个跨项目、跨 agent 的记忆层看起来是理想方案。

但这是刚需吗？从我自己的体验来看，没有这个记忆层对日常开发并没有带来太大不便，而使用它的成本至少 20 美元/月。agent 主动查询并得到有用结果的概率和频次，目前还抵不上为此付出的成本。

另外，memory 需求之所以存在，很大程度上是因为当前 coding agent 还没有做好长期记忆。但从最近半年使用 Claude Code 的体验来看，agent 在快速进化，可能不久之后就会内置个性化的长期记忆，效果超过很多第三方产品。靠给 agent 打补丁的创业方向，在 agent 快速迭代的当下，有被直接淘汰的风险。

那 memory 还值不值得做？取决于团队在数据处理上能做到什么程度。如果有技术优势，又还有时间窗口，可以一试。作为个人项目去探索肯定值得，但不宜寄望于它成为成功的商业产品——这一点留待一年后验证。