开源：参考OpenClaw，我们给 Claude Code 加上了轻量化的永久透明记忆

天天跟AI对话编码，最烦什么？就是每次打开新会话，Claude 对你的代码习惯、昨天的重构思路、好不容易敲定的风格偏好，统统不记得。于是又得复制粘贴历史记录，一遍遍重复交代。这种挫败感多了，真的会让人想摔键盘。

我们之前聊过如何复刻 OpenClaw 的 mem 系统，为所有 Agent 打造透明可控的记忆，并发布了 memsearch CLI。但代码场景下的记忆和检索，跟其他领域不太一样——代码决策带有强烈的上下文依赖，单靠通用记忆不够。所以，基于 memsearch CLI，我们又给 Claude Code 做了个永久记忆的 plugin——

（其实它适用于所有 AI coding 软件）。利用这个轻量级方案，Claude 能够记住每次对话、每个决策、每一条代码风格偏好，跨会话、跨天自动检索，随时可用。

为了区分，我们把上层这个 memsearch Claude Code plugin 叫 ccplugin，下层的 memsearch 还是叫 memsearch。

01 我们为什么要做 memsearch ccplugin？

早上打开 Claude Code，想让AI继续昨天的认证重构。结果Claude一脸茫然，完全不记得你们昨天一起搞了什么。于是你只能重新回翻，复制粘贴，做重复劳动。不算大问题，但天天来这么一出，烦不烦？

Claude Code 本身有记忆机制，但实际生产中根本不够用。比如 CLAUDE.md 文件能存项目指令和偏好，但更适合静态规则和简短提示，长期知识积累不合适。还有 resume、fork 这些命令，你得手动记住 session ID，自己输入，管理一堆分叉的对话历史。更糟的是，输入 /resume 时经常蹦出一堆会话标题，时间一久，你只记得操作细节却不知道哪个标题对应哪个会话，根本找不到。

市场上出现了全栈式解决方案

。它的思路是构建一套完整记忆系统：自动捕获编码活动，用AI压缩成可搜索的摘要，需要时注入相关上下文。

具体实现上，claude-mem 打造了三层记忆系统：先搜索高层摘要，需要细节查看时间线，想看原始对话就拿完整 observations。附加功能包括隐私标签、成本统计、Web 可视化界面。技术实现如下：

• 运行层：基于 Node.js 开发的 Worker 服务，运行在 37777 端口，会话基础数据存 SQLite，引入向量库做精准检索。
• 交互层：配套 React 开发的 Web 可视化 UI，直接查看记忆内容（摘要、时间线、原始记录）。
• 接口层：通过 MCP Server 对外暴露标准化工具接口，Claude 可直接调用 search、timeline、get_observations 等命令。

平心而论，这个产品不错，解决了问题，但也确实很重：

• 环境依赖复杂
  ：需要部署 Node.js、Bun、MCP runtime，还要维护 Worker、Express Server、React UI、SQLite、向量库等多个组件。

• Context 窗口与成本开销大
  ：MCP server 所有工具定义会永久加载到 Claude 上下文中，每次工具调用的请求/响应都消耗 tokens。长时间会话，累积开销可能失控。

• 记忆召回被动
  ：记忆召回是“agent-driven”模式，必须 Claude 主动决定调用来触发；三层记忆系统每一层都得显式调用对应工具。

• 数据存储不透明
  ：数据分散在 SQLite 和 Chroma 向量库中，无通用格式。想迁移需写导出脚本，查看底层数据也只能通过 Web UI 或专用接口。

基于这些现实，我们开始思考：记忆系统能不能更简单？

02 memsearch ccplugin 是如何构建的

claude-mem 走了全栈路线，而我们开发的 memsearch ccplugin 走了完全相反的路线——以极简为核心设计哲学，用最轻量化的方式解决问题。

ccplugin 的架构核心是四个 shell hooks，加上一个后台 watch 进程。完全摒弃了 Node.js、MCP server、Web UI 等复杂组件，本质上就是几个调用 memsearch CLI 的 shell 脚本，部署和维护门槛大幅降低。

从职责边界来看，ccplugin 本身不做记忆存储、不做向量检索、不做文本嵌入，这些全部交由底层的 memsearch CLI 搞定。ccplugin 唯一的职责就是充当桥梁，把 Claude Code 全生命周期的关键事件（会话启动、用户输入 prompt、停止回复、会话结束）精准桥接到 memsearch CLI 的对应功能上。

这种分层解耦带来极强的灵活性：即使你不用 Claude Code，memsearch CLI 也能独立对接其他 IDE、Agent 框架，甚至手动调用。

具体落地上，这套架构有两大特色。

第一：Markdown 优先，数据永远可从 .md 文件重建

ccplugin 的所有记忆都存在 .memsearch/memory/ 目录下的 Markdown 文件里：

.memsearch/memory/
├── 2026-02-09.md
├── 2026-02-10.md
└── 2026-02-11.md

每个文件是一天的 session 摘要，纯文本，人类可读。下面就是 memsearch 项目本身的每日记忆 Markdown 文件截图：

时间、会话 ID、每轮对话的 ID、会话摘要，一目了然。想知道 AI 记住了什么？直接打开 Markdown。想修改？用编辑器改就行。想迁移数据？复制 .memsearch/memory/ 文件夹即可。过程中，向量索引仅作缓存：Milvus 向量库中的索引只是为了加速语义检索，可随时从 Markdown 文件重建。零不透明数据库，零二进制黑盒，数据永远可追溯、可重建。

第二：自动注入，零上下文消耗

透明的存储只是第一步，真正的效率来自于使用方法。ccplugin 的记忆召回是自动的：每次你输入 prompt，UserPromptSubmit hook 会自动触发语义搜索，把 top-3 相关记忆注入到上下文中。Claude 不需要决定是否搜索，它直接就能拿到上下文。

过程中，Claude 看不到任何 MCP tool definitions（不会占用 context window），也无需主动调用工具。Hook 机制在 CLI 层面运行，注入的只是纯文本搜索结果，无 IPC 开销，也没有工具调用的 token 成本，彻底避免 context 开销累积。

另外，为兼顾效率和灵活性，我们设计了三层渐进式检索逻辑（均为 CLI 命令）：

• L1（自动层）
  ：每次输入自动返回 top-3 语义搜索结果（chunk_hash + 200 字预览），满足日常需求。

• L2（按需层）
  ：需要完整上下文时，运行 memsearch expand 获取完整 Markdown 章节 + 元数据。

• L3（深入层）
  ：需要原始对话时，运行 memsearch transcript --turn 调取 JSONL 格式原始记录。

整体逻辑是先给概览，再按需深入，既保证默认轻量化，又满足特殊场景的细节需求。

记忆的检索解决了“用”的问题，那怎么“存”呢？ccplugin 的 Markdown 记忆内容通过一套后台异步、极低成本的流程自动生成：每次你停止 Claude 回复时，Stop hook 会异步触发，解析对话记录（transcript），调用 Claude Haiku 模型（claude -p --model haiku）生成会话摘要，追加到当天 Markdown 文件中。Haiku 模型 API 调用成本极低，几乎可以忽略。紧接着，后台 watch 进程检测到 Markdown 文件变化，自动将新内容索引到 Milvus，保证检索时效性。全程后台运行，不干扰操作，成本可控。

03 快速上手

第一步：在 Claude Code 中通过插件市场安装：

# 在 Claude Code 终端运行
/plugin marketplace add zilliztech/memsearch/plugin install memsearch

第二步：重启 Claude Code，插件会自动初始化配置。

第三步：完成一次对话后，查看当天的记忆文件：

cat .memsearch/memory/$(date +%Y-%m-%d).md

第四步：下次启动 Claude Code 时，系统会自动检索并注入相关记忆，无需额外操作。

04 结尾

回到最开始的问题：如何给 AI 加记忆？claude-mem 与 memsearch ccplugin 各有优劣，这是我们整理的一个快速选型指南：

claude-mem 提供了更丰富的功能、更完善的 UI、更灵活的控制。如果你需要团队协作、Web 可视化、精细的记忆管理，它是好选择。

memsearch ccplugin 提供了极简的设计、零上下文消耗、透明的存储。如果你只想要一个轻量的记忆层，不需要额外的复杂度，它可能更适合。

哪个更好，取决于你需要什么。