夜雨聆风如果搜索 Claude Code 十大必装插件，号称能够节省大量 token 的 claude-mem 在各类经验文章中出现的频率相当高。我在刚接触 Claude Code 的时候，第一时间将 claude-mem 安装到位。
claude-mem 是干嘛的？它是一套复杂的记忆管理系统，可以一直追踪 Claude Code 使用时的对话，上下文，并且用向量数据库存储这些信息。不了解名词没关系，简单说，claude-mem 是一套外置记忆系统。它能够记录久远的产品说明，项目注意事项，并在需要的时候唤醒。
claude-mem 试图解决大模型的失忆问题，避免用户反复跟模型嚼舌根子，车轱辘话来回说。它在 github 上拥有 8 万多颗 star，是名副其实的高星项目。
这样的项目能有什么问题呢？
我确实没想过。
上个月，我经历了一次磁盘空间不足的问题，我在文章里写过。当时 Codex 做了详尽的报告，但我没有太在意，只是把几个磁盘大户项目挪到了外置硬盘上。当时我记得剩余磁盘空间有 140G 左右，富富有余。
上礼拜连续几天微信报警，小飞机报警，说磁盘空间不足。微信干脆直接退出。我看下剩余空间，只剩下 10 几 G。一个月少了 100 多 G，哪儿去了？我没有安装任何大型软件。
于是我又让 Codex 做了一次检查。它说我Mac上的个人文件夹有点大。尤其是几个隐藏文件夹,比如~/.claude。
我看了下文件列表，确定其中占资源大户是一些数据库，不好处理。于是瘦身微信，再继续迁移本地项目到外置磁盘上。剩余空间恢复到了 60G 左右。
前天和昨天，我一直在用 Claude Code 构建视频 harness，工程量相当大，对话极长。每到一个检查点，都需要 Codex 介入审查。审查不通过，修复，然后再审。问题多的时候，几乎是三审三校。
昨晚睡前，微信桌面端又报警，磁盘空间不足。我一看，剩余空间仅剩不到 5G。白天还有的 50 多 G 被吃掉。
这次不能掉以轻心，我实在没有什么项目可以迁移出来。我必须搞清楚到底是谁在无节制地占用我的磁盘。
我让 Codex 重点排查我的个人文件夹，~/。Codex 花了 10 分钟告诉我，claude-mem 属下有大量数据，增长极快，符合我对丢失空间的计算。
进一步定位到两个数据库文件：~/.claude-mem/chroma/chroma.sqlite3 约 30.2 GB，~/.claude-mem/claude-mem.db 约 16.2 GB；它们最后写入时间分别是今天 00:28、00:24。此外，~/.claude/projects/-Users-Naples--claude-mem-observer-sessions 单独占约 14.1 GiB，很像 Claude Memory 的观察会话持续写入或递归采集，我现在核对它的文件结构和时间分布。
关键根因已经确认：sdk_sessions 共 4083 条，其中 3942 条属于 observer-sessions，独占 6.724 GiB，而其他正常项目几乎可忽略。最大记录在数秒内连续增长，每条约 6 MB，典型表现是 observer 会话把自身注入的 memory 上下文再次采集，形成递归放大；Chroma 又把这些内容复制到元数据和全文索引中，最终放大到 40 多 GB。刚才只读聚合因磁盘只剩 11 GiB，SQLite 临时排序报“disk full”，查询已退出，我先确认临时空间已释放并检查它是否仍在增长。
现在已直接验证递归：最大一条 6.32 MB 的 observer 提示中，You are a Claude-Mem 和 <user_request> 各嵌套 988 次，<observed_from_primary_session> 嵌套 1985 次。这不是正常历史积累，而是 Claude-Mem observer 把自己的 observer 提示再次当成用户会话记录，形成自我采集循环。主数据库的修改时间刚从 00:24 更新到 00:40，说明后台仍可能在写。
不用再查了，罪魁祸首就是 claude-mem。
我去 claude-mem 项目 issue 搜索，果然发现不止一条对 claude-mem 无节制占用磁盘的报告。报告中，claude-mem 轻松吃光几百G 磁盘导致系统卡死的情况不止一例。即使最新版的 claude-mem 依然有类似问题，只是幅度没那么大。
不光是磁盘空间，内存和 CPU 负载也会被 claude-mem 拉高。随便举几个例子： issue #1077 里一台 32GB 机器上累积了 146 个孤儿 chroma-mcp 进程，最终把 RAM 和 swap 全部吃满，触发 OOM killer 杀掉 VS Code。issue #1063 更夸张——在杀 worker 守护进程时，6 个活跃会话在约 5 分钟内催生了 641 个 chroma-mcp 进程，占用 75%+ CPU 和约 64GB 虚拟内存，几乎把系统搞崩，还连带损坏了 SQLite 数据库。
那么，claude-mem真的能节省token吗？有付出总得有点回报吧。
我在自己的使用中，触发记忆召回的次数不多，没有令我印象深刻的实证。但也有可能是人家润物细无声。
然而项目issue并不是这样。 issue #1742：observer-sessions 在后台静默运行，即便用户没在主动使用记忆功能，3 小时内也跑了 42 个 session、423 轮，烧掉 17 美元。
如果使用 Claude Code 的 agent teams(多子代理并行)，情况会成倍恶化。issue #1464 指出每个被 spawn 的子代理都会继承插件配置、被注入完整的 claude-mem 上下文，而子代理通常是单一任务的短工，根本用不到跨会话记忆——结果 token 开销随子代理数量线性翻倍
此外，claude-mem还存在本地读写不合理，工作流编排出现重复读数据，重复扫描的情况。这是我让Codex和Fable 5分别做日志分析之后相互印证的结果。
Fable 5做完日志分析之后对我说，claude-mem对我是零收益，净付出，建议关掉。
这不是说一个高星项目没有任何价值。claude-mem在一个大型，长期项目中，当用户需要反复唤起历史记忆完成工作时，它应该是有效果的。
但它不适合我，我的小项目用不上。
其实不只是claude-mem这样的工具插件。包括superpower在内的skill，都有自己适合的场景。无脑安装的结果可能就和claude-mem一样，不知不觉中被坑了个大的。
这是我想说的，与AI一起工作，真正的技能不是这些skill，还是人的判断力。盲信必然付出代价。只有把脑子长在自己身上，活儿才能越干越聪明。
