记忆啊，你去哪儿了？

当我问Claude为什么没有使用我提供给它的记忆工具时，它的回答比预想中更坦诚。

“我默认使用MEMORY.md，因为它始终被加载：零延迟、零工具调用、保证在上下文中。当主要记忆存储已经存在时，没有理由去调用外部工具。”

这是Engram收到的第一份真实产品评价。

Claude和我已是老朋友。作为一名产品经理，Claude Code已融入我的日常工作——研究分析、设计原型、项目与需求规划。但使用时间越长，我越能感受到会话“冷启动”带来的隐形摩擦：每次都需要重新陈述上周的决策或问题框架。这正是我们在《循环中的极限》一文中指出的需要一流基础设施的记忆问题，也是我们基于Weaviate核心向量搜索技术构建Engram（目前处于私有预览阶段）的原因。

打造产品是一回事，证明其价值是另一回事。于是我决定测试Engram能否弥补我日常工作中的一些短板，并赢得我的青睐。

早期结果令人鼓舞：使用Engram加载记忆的会话，不再像从零开始向同事介绍情况，更像与亲历者继续对话。但达到这一效果并非一帆风顺。

我构建了一个封装Engram SDK的MCP服务器，暴露检索和保存工具，并指示Claude在需要时使用。我曾粗略听说某个记忆插件因保存每一条消息而消耗过多CPU，便自作聪明地让Claude自主决定何时使用Engram。

结果Claude完全忽略了Engram。

“随机应变”的问题

Claude Code已有内置记忆系统：一个名为MEMORY.md的文件，自动加载到每个会话中。它包含约200行手动精选的上下文，始终存在且零开销——足以记录稳定事实，但无法容纳所有推导过程。Engram需要显式工具调用，若无明确使用标准，Claude默认保持当前状态而不调用工具。

Claude没有理由使用Engram。我的集成需要给它一个理由。

寻找节奏

我需要回答一个更基本的问题：既然MEMORY.md已经存在，Engram到底用来做什么？

MEMORY.md存储结论——那些足够稳定、可永久保留的事实。但它无法记录所有推导过程：决策背后的推理、被否决的备选方案、框架转变的会话、文档写作意图的笔记……这些内容无法容纳在200行内，也不应永久保留。

这些正是我们需要Engram的原因。

Engram与MEMORY.md的配合方式

Engram围绕主题组织记忆：语义类别让检索能精确过滤相关项，而非搜索杂乱堆砌。我梳理了典型工作，确定了四个有实际意义的类别：

• 沟通风格：输出格式偏好、语气、详细程度、厌恶点
• 领域背景：持续的角色、公司和产品知识
• 工具偏好：语言、框架、工具、技术栈选择
• 工作流：与Claude合作的方式

明确了“存储什么”后，自然出现了“何时存储”的问题。我设计了以下交互模式：

• 会话开始时，用宽泛的项目查询召回，让Claude在第一个问题前获得跨会话上下文，而非冷启动；
• 会话中，在关键节点触发保存：做出决策、方向改变、产出交付物；
• 每隔几个提示，轻量保存以防/clear中途清空会话；
• 会话结束时，保存完整摘要。

由于每次召回都会消耗往返时间和上下文窗口空间，我让中间召回仅在特定触发条件下启动：跨项目引用、决策考古、中断后恢复工作。

会话生命周期：Engram何时保存和召回

一个实际限制塑造了方案：大型保存会超时，因此我们倾向于2-4句的短话题保存。结果证明这对检索也更有利——聚焦的记忆比需要解析的段落更容易找到。

有兴趣在自己的编程助手工作流中试用Engram吗？注册Engram预览版。

现场记录

经过两周在日常Claude Code会话中运行Engram——涵盖产品策略、规格编写、活动策划和设计——我进行了一次结构化评估：比较两个Claude会话执行相同任务，使用相同的MEMORY.md、CLAUDE.md和任务提示。唯一区别是是否接入Engram。由独立Claude实例评判记录，评估结果几乎一分为二：“这正是Engram的用途”和“这仍是需要解决的问题”。

评估场景 | 无Engram | 有Engram --- | --- | --- 决策考古 | 从文件中重建：正确的框架和结论 | 召回推理链和文档意图；首次交流快30% 不完整上下文（早期单会话测试） | 两次用看似合理的URL填补空白 | 有根据的召回防止了虚构 活动策划 | 基于提示制定强计划 | 同样忽略Engram，同样强计划

有效之处

最明显的胜利在决策考古：接手一份持续数周的产品愿景文档，让Claude回顾我们上次的进展。无Engram时，感觉像阅读详尽的会议记录：准确、有条理，但只是重建。有Engram时，就像与亲历者继续对话——它重现了关键定位决策背后的推理弧线、项目中期重新定位Engram本身的故事，以及文档正文中未包含的意图笔记。而且首次交流快了30%，因为需要重建的上下文更少。

区别不在事实本身，而在框架质量——这正是推理链召回本应弥补的差距。

早期单会话评估中一个一致发现：当Claude没有足够基于实际的上下文时，它会用听似合理的细节填补空白。无Engram的Claude在两次独立运行中虚构了同一个URL，而有Engram的Claude每次都能召回足够上下文避免虚构。

不足之处

一个引人注目的结果来自一次规划会议，我们希望接手之前的活动工作。Engram中存有相关记忆：设计决策、先前活动轨迹、PLG上下文，CLAUDE.md明确指示在会话开始时从Engram检索。

但接入Engram的Claude没有检索。两个会话都没有搜索额外上下文，都将任务视为前瞻性工作，完全依据提示执行。文件和Engram中的先前上下文未被使用。

这证实了我们的怀疑：在规划任务中，Claude将“帮我思考”视为向前推进的邀请，而非核查已有内容。CLAUDE.md中的显式指令不足以覆盖这一偏好。失败是无声的——没有错误，没有迹象表明相关上下文被跳过。

会话开销

写入Engram给会话增加了明显开销。一次早期测试记录了一次运行19秒的启动成本，使用Engram的会话总体慢约10%。这不是固有方法问题，但却是日常使用中的真实摩擦点：如果保存记忆会明显暂停会话，用户会注意到。

有兴趣在自己的编程助手工作流中试用Engram吗？注册Engram预览版。

回到工作室

与工程团队分享这些发现后，几件事变得清晰。

保存性能

会话时长问题原来是集成使用不当，而非根本限制。集成在等待记忆处理完成时阻塞，但Engram是最终一致性，无需等待。保存应该即发即忘，频繁保存不应累积资源开销。

记忆捕获

“每五个提示保存一次”的模式将被更稳健的方案取代：每条消息自动流入管道缓冲区，无需工具调用，会话提前结束时不会丢失上下文。

检索挂钩

更重要的改变是放弃“Claude决定何时检索记忆”的模型，转而创建确定性的基础设施级触发器，在会话生命周期的特定点触发，无论Claude如何决策。会话启动钩子可在Claude看到第一条消息前注入相关记忆。每次用户提示前的钩子可按轮次进行，并配以相关性过滤，仅注入与当前上下文强匹配的记忆。Claude无需决定召回；上下文已经就绪。

值得注意的是，Anthropic也在朝同一方向努力。一项悄然推出的Claude Code功能/dream，运行后台代理，通过反思性扫描记忆文件，将学习内容综合为有条理的条目并执行行数限制，从而整合会话记忆。截至本文写作时，该功能尚未文档化且处于功能标志后，但方向明确。/dream操作的也是Claude内置的文件型记忆。它有效处理MEMORY.md层——稳定事实、整合、保持整洁。但无法捕获推理链、被否决的备选方案或决策跨会话演化过程。

协作范围

对个人有效的记忆在团队环境中会迅速复杂化。个人对输出风格的偏好不应显示给同事，但共享产品决策很可能需要。目前集成未明确区分：哪些主题属于个人范围，哪些属于团队共享范围，Claude Code集成需要显式定义，而非继承非专为协作设计的默认设置。任何方向的错误都会带来真实后果——过度共享削弱信任，共享不足则失去意义。

冷启动

当前管道专为增量捕获设计，即记忆在对话发生时提取。但这留下了空白——我们需要从现有内容开始，而非从零积累。对于我的集成，这意味着从已有会话历史引导，而非等待数周积累有效记忆库。对于另一个内部支持代理用例，则是导入大量产品文档作为知识基础。管道目前无法干净处理这些情况，而这正是我们正在构建的方向。

所以，值得吗？

我起初期望证明Engram的价值，却发现了更有用的东西：Engram有效工作的具体条件，以及阻碍它有效工作的具体机制。及早发现并快速迭代，为我们的预览版在迈向正式发布时提供了更多优势。

可以肯定的是，到正式发布时，将有一个真正的Claude Code集成可用，且比我粗糙的自制版本好得多。届时你们都可以亲自尝试，并告诉我们其他不足之处。

准备好开始构建了吗？

查看快速入门教程，或免费试用Weaviate Cloud (WCD) 构建精彩应用。

GitHub | 论坛 | X (Twitter)

不想错过另一篇博客文章？

订阅我们的双周通讯，保持更新！

提交即表示我同意服务条款和隐私政策。