OpenMemory Auto Manager：让所有 AI Agent 共享同一个记忆大脑

开场：每次重开 Claude Code，记忆归零的痛苦

想象一下这样的场景：你花了一整上午和 Claude Code 讨论项目架构，它记住了"这个项目用 PostgreSQL 16""测试数据库端口是 5433""不要用 JWT，用 Session"。结果第二天你关掉终端重新打开 Claude Code，问它"昨天那个数据库端口是多少？"——Claude 茫然地回答"抱歉，我没有上下文"。

这就是当下 AI Agent 的集体困境：每个会话都是独立的"金鱼记忆"，没有任何持久化可言。 当你需要同时跑 Claude Code、OpenCode、Codex CLI 和 Gemini CLI 四个工具时，这个问题成倍放大——每个工具各自为政，你必须反复告诉它们相同的信息。

vancelin 开源的 OpenMemory Auto Manager 就是来解决这个问题的。它不是一个 AI 模型，而是一个跨工具的长期记忆共享层——只要你在任意一个 AI CLI 里存过的信息，其他所有 CLI 立刻就能搜到。而且整个系统完全本地运行，不需要任何 API Key，不需要 Docker，也不需要外部云服务。

技术实现：参考计数驱动的自动启停

从架构上看，OpenMemory Auto Manager 包含三个核心组件：

openmemory-manager.sh 是整个系统的"中枢神经"，负责 OpenMemory MCP 服务器的生命周期管理。它通过一个巧妙的参考计数（Reference Counting）机制来实现零配置自动启停：当你在终端输入 claude、opencode、gemini 或 codex 时，对应的 Shell 包装函数会触发 _om_ref_incr()，将计数器加一并自动启动 OpenMemory 服务器。当终端关闭时，zshexit 钩子自动触发 _om_ref_decr()，计数器减一，直到最后一个终端退出，服务器才自动关闭。

这样设计的好处是：即使同时开 4 个终端跑不同的 CLI，它们也共享同一个 OpenMemory 服务器实例（localhost:8080），而不是各自启动新进程。内存占用极低，资源利用率高。

openmemory-codex-proxy.py 是一个专为 Codex CLI 定制的桥接层。Codex CLI 只支持 STDIO 协议传输 MCP，而 OpenMemory 服务器暴露的是 HTTP MCP 接口。proxy 脚本利用 FastMCP 的 create_proxy 机制，将所有 STDIO 调用透明地转发到 HTTP 端点，相当于一个协议翻译器，让 Codex CLI 也能无缝接入记忆系统。

install.sh 是安装入口，支持幂等安装——多次运行不会重复追加配置，只会检测并提示"已安装"。它自动在 ~/.zshrc 或 ~/.bashrc 中注入 Shell 钩子，不需要用户手动修改任何配置文件。

核心功能：MCP 工具集与跨工具记忆

OpenMemory 服务器暴露了完整的 MCP 工具集：

最令人惊艳的是跨工具共享——在 Claude Code 里用中文告诉它"我喜欢用 Python 写后端，前端用 React"，然后在 Gemini CLI 里问"我的项目用什么技术栈？"立刻得到正确答案。OpenMemory 的底层用的是 SQLite 向量数据库 + 合成嵌入（Synthetic Embeddings），不需要任何外部 Embedding API Key，完全本地计算。

上手体验：安装分两步，总计 20 分钟

整个安装流程分两阶段：

第一阶段：安装 OpenMemory 服务器（这是上游依赖项目 CaviraOSS/OpenMemory）：

git clone https://github.com/CaviraOSS/OpenMemory.git ~/OpenMemory
cd ~/OpenMemory/packages/openmemory-js
npm install && npm run build

第二阶段：安装 Auto Manager（本项目）：

git clone git@github.com:vancelin/openmemory.git ~/dev/memory
uv venv .venv --python 3.11
uv pip install fastmcp --python .venv/bin/python
./install.sh

重启终端后直接运行 claude、opencode、codex 或 gemini，OpenMemory 会自动启动。安装脚本自动检测 Shell 类型（zsh/bash），自动注入配置，零手动操作。

局限与边界：它不是什么

需要明确的是，OpenMemory Auto Manager 不是 AI 模型本身，它只是一个记忆管理层。它依赖上游 CaviraOSS/OpenMemory 项目提供实际的 MCP 服务器能力——如果你不使用任何 AI CLI 工具（Claude Code / OpenCode / Codex CLI / Gemini CLI），它对你毫无意义。

其次，虽然它做到了跨工具记忆共享，但每个 AI CLI 本身仍然是"无状态的"——你不能期待 Claude Code 记住"当前在哪个分支工作"这类会话级状态，那是 AI CLI 本身的责任。

此外，安装流程中需要预先安装 OpenMemory 服务器这个独立项目，相比于"克隆即用"的开箱体验，增加了一步门槛。对于不熟悉 Node.js 环境配置的用户，仍有一定挑战。

行业意义：Agent 记忆层的新范式

2025-2026 年，AI Agent 领域最活跃的探索方向之一就是长期记忆与上下文管理。OpenMemory 的创新点不在于用了什么新模型，而在于它提出了一个务实的工程问题：当用户同时使用多个 Agent 工具时，如何让它们共享记忆？

参考计数 + 共享服务器的思路，在操作系统进程管理中极为常见，但将它引入 AI CLI 工具链是一个有趣的设计选择。合成嵌入（无需 API Key 的 Embedding）则进一步降低了部署门槛——任何人都可以在没有 OpenAI/Anthropic API Key 的情况下运行这套系统。

该项目目前 stars 105，fork 24，还处于早期阶段，但从工程完整度（MCP 协议、多工具桥接、Shell 钩子、崩溃恢复）和文档质量（README 有完整中文版本）来看，已具备生产使用的基础。