上周三下午，我花了两小时把 claude-mem 从 clone 到跑通，中间崩了两次、重装一次 Python 环境。这篇不聊它 README 里那些漂亮的架构图，只说我实际敲了哪些命令、卡在哪、最后跑出来什么效果。如果你也在观望这个项目，可以先看完再决定要不要动手。
先说清楚我到底装了什么
我拉的是 claude-mem 主分支，commit 停在 3 天前那个版本，pip show 出来是 0.4.2。机器是 M2 MacBook Air，16G 内存，Python 3.11.6。安装流程本身不复杂：先 git clone 仓库，进目录建 venv，然后 pip install -e .，最后跑一遍 python -m claude_mem.cli init 初始化本地存储。这一步它会问你记忆库放哪，我默认用了 ~/.claude-mem，没改。整个 pip 安装大概花了 90 秒，依赖里有个 sentence-transformers 会顺带拉 torch，光这一项就占了 1.2G 磁盘。init 阶段它要下载一个 embedding 小模型，约 80MB，我这网络等了 40 秒左右。装完之后 claude-mem --version 能正常回显，说明环境没问题。真正开始踩坑是在第一次让它"记东西"的时候。
第一次写入就给我上了一课
我按文档示例跑了 claude-mem add "今天调试了支付回调的幂等逻辑"，终端直接抛了个 KeyError: 'content_hash'。翻 issue 区发现这是个已知问题：0.4.2 在没配置 storage.backend 的情况下，默认走 sqlite 但 schema 迁移没跑全。解决办法是手动执行 claude-mem migrate --to 0.4.2，然后再 add 一次。这回成功了，但写入延迟比我预期高------单条记忆落库加向量化花了 1.8 秒，我连续灌 20 条测试数据用了 36 秒。如果你打算批量导入历史对话，这个速度得提前有心理准备。另外它默认把 embedding 也存进 sqlite，库文件涨得挺快，20 条短文本就干到了 14MB，长期用建议把向量单独扔到别的后端。
检索效果比我想的好一点
我灌了 60 条自己过去两周的调试记录进去，然后拿几个模糊问题去查。比如问"那个回调重复扣款怎么修的"，它 top3 里第一条就命中了正确的记忆片段，相似度 0.83，第二条是相关但不同场景的，0.71。我又试了"上周三下午改的那个配置"，它没直接命中，因为我的记忆里没写具体日期，只写了"支付回调那会儿"。这说明它对语义的抓取还行，但对时间、人名这类硬实体不敏感，别指望它当日志搜索引擎用。检索单次耗时在 200ms 上下，60 条数据量下可以接受，但我没敢测上千条的规模，怕 sqlite 全表扫拖垮体验。整体来说，作为"给 Claude 补长期记忆"的中间层，它的召回质量对得起 0.4.2 这个版本号，但离"无脑信任"还差一截。
那个让我重启两次的坑
最烦的不是写入报错，是它的 CLI 在管道输入时会静默挂起。我试过 echo "测试记忆" | claude-mem add -，终端没有任何输出，光标卡住，等了 2 分钟没反应，Ctrl+C 才退出来。换成交互式 claude-mem add 再手动输入就正常。后来看源码发现 stdin 非 tty 时它有个 readline 死循环，0.4.2 还没修。这意味着你想用脚本批量灌数据，得绕开 CLI 直接调它的 Python API，或者用 --file 参数传路径。我最后是写了个 15 行的小脚本走 MemoryStore.add() 才把 60 条灌完。这个坑不致命但很膈应人，尤其是你按文档示例复制粘贴的时候，根本想不到会卡在这。
值不值得你花一个下午
跑完这一圈，我的结论是：claude-mem 的思路值得学------把记忆抽成独立层、用向量做语义召回、给 agent 提供 add/search 两个原语，这套设计比把历史全塞 context 里聪明得多。但 0.4.2 的工程完成度大概只有 70%，schema 迁移、stdin 处理、批量写入性能这三块都还有毛刺。如果你只是想体验一下"给 Claude 装记忆"是什么感觉，花 2 小时跑通、灌几十条数据、试几次检索，完全够用，记得先跑 migrate、别用管道输入。如果要上生产或者接自动化流程，我建议再等一两个版本，或者做好自己 patch 的准备。我这边会继续用它记日常调试碎片，但暂时不敢把它放进任何无人值守的链路里。