claude-mem：给AI Agent装上跨会话记忆

AI 编程 Agent 每次新开会话都像失忆：你昨天让它搭好的项目结构，今天换个终端窗口它就不知道了。thedotmack/claude-mem 要解决的就是这个具体问题——让 Agent 在不同会话之间记住自己干过什么。

它记录 agent 在会话中的操作，用 AI 把原始记录压缩成可检索的摘要，然后在后续会话里注入与当前任务相关的上下文。仓库自述明确支持 Claude Code、OpenClaw、Codex、Gemini、Hermes、Copilot、OpenCode 等多种 CLI 工具。

这个项目在 AI 开源热榜排第 24 名，Star 数超过 10 万，过去 30 天还在涨。热度背后是一个普遍痛点：编程 Agent 的上下文窗口有限，而开发任务往往跨越多天、多个会话。

本文不列功能清单，只拆三件事：它为什么这样设计、代价是什么、同样的目标还有哪些做法。

记录与压缩分离：为什么不能直接存原文

最笨的跨会话记忆方案是把每次会话的完整日志存下来，下次原样塞回上下文。这行不通。

Claude Code、Codex 这类工具的上下文窗口有硬限制。一个下午的开发会话产生的终端输出、文件 diff、工具调用记录，轻松超过几十万 token。直接回放，新任务还没开始窗口就满了。

claude-mem 的设计把「记录」和「压缩」拆成两步。会话期间它持续捕获 agent 的操作——具体捕获哪些事件、以什么粒度记录，文档没有详细说明。但从它声称支持的多种 CLI 工具来看，这一层大概率是适配器模式：每种工具的事件流格式不同，需要各自的采集器。

压缩这一步交给 AI。原始记录经过模型提炼，去掉重复的、无关的细节，留下结构化的摘要。摘要可以很小，但保留了后续任务可能需要的核心信息。

代价是信息损耗。AI 压缩不是无损操作，模型会判断哪些信息「可能有用」。这个判断可能错。你今天调试的某个诡异 bug 的根因，模型可能觉得是噪音，压缩时丢掉了。明天同样的问题复现，Agent 又得从头查。

另一个代价是延迟。每次会话结束都要跑一次压缩，摘要入库也要时间。对于频繁开关的短会话，这个开销占比不低。

按需注入：比全量注入聪明，但依赖检索质量

把压缩后的摘要存起来只是第一步。真正难的是「什么时候注入什么」。

claude-mem 的做法是「注入相关上下文」。注意「相关」这个词——它不是把整个记忆库倒给新会话，而是根据当前任务挑选。

这意味着系统内部必然有一个检索或匹配环节。新会话开始时，agent 的初始 prompt 或用户输入会被拿来和记忆库做比对，找出最相关的摘要条目。具体用什么技术，文档没有说明。可能是向量相似度，可能是关键词匹配，也可能直接让 AI 做选择。

按需注入的好处是省 token。记忆库里存了几百条摘要，但一次只注入三五条，不会挤爆新会话的上下文。

坏处是检索可能漏。相关性的判断发生在任务真正开始之前。你写了一句「继续昨天的那个功能」，系统得先理解「那个功能」指什么，再去记忆库里捞。如果摘要写得模糊，或者检索算法不够聪明，捞上来的东西和你真正需要的对不上。

还有一种更隐蔽的失败：你需要的上下文根本没被压缩进记忆库。检索再准，库里没有就是没有。

多工具适配：覆盖面广，但深度存疑

仓库自述列出的支持名单很长：Claude Code、OpenClaw、Codex、Gemini、Hermes、Copilot、OpenCode，后面还跟了个「+ More」。

这个名单说明项目走的是广度路线。它不想只做 Claude Code 的插件，而想成为一个通用的 agent 记忆层。

但广度路线有代价。每个 CLI 工具的事件模型、会话生命周期、上下文注入机制都不同。Claude Code 有 hooks，Codex 有它自己的一套，Copilot 又是另一套。要同时适配这些，采集层的逻辑会变得复杂，而且每个适配器的质量可能参差不齐。

文档没有说明各工具的支持程度是否一致。是全部深度集成，还是部分工具只支持基础记录？这是使用前需要自己验证的。

从架构角度看，一个更稳的做法是聚焦单一工具，把采集、压缩、注入的链路打磨到极致，再逐步扩展。同时铺开多个适配器，在项目早期可能会分散精力。

安全与存储：文档没提，但绕不开

claude-mem 记录的是 agent 的「一切操作」。这句话在仓库自述里出现时没有附加任何限定。

这带来一个直接的安全问题：agent 在会话中可能接触到的敏感信息，比如 API key、内部代码、客户数据，都会被捕获并送进压缩流程。压缩后的摘要存在哪里？本地还是云端？如果用了外部 AI 做压缩，原始记录是否经过第三方？

README 没有回答这些问题。License 是 Apache-2.0，代码可以审计，但仅凭字段无法判断默认的存储位置和数据流向。

对于一个处理开发会话数据的工具，这个信息缺口是实打实的风险。开发者的会话记录往往比聊天记录更敏感，因为它直接包含生产环境的上下文。

边界与判断

claude-mem 解决的是真实存在的痛点。跨会话记忆是编程 Agent 走向长时间、多步骤协作的必经之路，这个项目至少给出了一个可用的思路：记录、压缩、按需注入。

但它不是一个装上就完事的工具。压缩的信息损耗、检索的相关性风险、多工具适配的深度、以及安全存储的未说明，都是实打实的边界。Star 数高说明需求大，不代表这些边界已经解决。

我的判断是：值得试，但别默认它靠谱。先在一个不涉及敏感信息的项目里跑几天，观察它注入的上下文到底准不准、漏不漏。如果你只用 Claude Code 一个工具，也可以先看看同类单工具方案，比较一下记忆质量和配置成本。