Memmy：把多个 AI 编程代理的上下文拼成一份共享记忆
🍙 A personal AI agent & local memory hub for all AI agents, gives every AI one shared, fully controlled memory and persistent context — all AI remember the same you. Now supports Claude Code, Codex, OpenClaw and Hermes Agent etc.
秒懂
- 它是什么？
- Memmy 用本地 Memory Service 加 Gateway 的组合，让 Claude Code、Codex、Cursor 等代理读写同一份记忆。它解决的是换工具就丢上下文的问题，代价是你要接受一套常驻的 systemd 用户服务。
- 适合谁用？
- 如果你同时使用两个以上 AI 编程代理、且愿意让一套 systemd --user 服务常驻本机，Memmy 值得按 README 的流程装一遍再评估；如果你只用一个代理、或者不能接受本地常驻服务与私有格式的记忆库，它带来的复杂度大于收益。上手前先确认三件事：Node.js 是否达到 22、systemd 用户会话是否可用、以及你打算用注册赠送的试用额度还是切到 BYOK。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
换一个代理就要重讲一遍背景，这是 Memmy 要消掉的那件事
用 Claude Code 写了一半的重构，第二天换成 Codex 继续，代理对项目一无所知。你重新解释目录结构、代码风格、上次为什么放弃某个方案。这种重复劳动不是模型能力问题，而是每个代理把上下文存在自己的会话里，彼此不通。Memmy 的定位就是在这中间加一层共享记忆：README 把它概括为记住、接力、行动三件事，其中接力指的是切换工具时不丢项目背景、偏好和进度。目标用户很明确，是同时用多个代理干活的人，包括在 DeepSeek Harness、Claude Code、Codex、Cursor、OpenClaw、Hermes 之间来回切换的开发者。项目用 TypeScript 写成，MIT 许可，仓库没有归档，最近一次推送是 2026 年 9 月 9 日，同一天发布了 v1.1.4，节奏是几天一个小版本。
本地两个服务加一份记忆库，代理通过 Skill 和 Hook 接入
从 README 能确认的架构是：本机跑一个 Memory Service，默认监听 http://127.0.0.1:18960；另有一个 Gateway，提供 OpenAI 兼容 API，端口 18990。两者都是 systemd --user 服务，绑定 localhost。代理这一侧不是自动接入的，安装脚本只初始化 Memory，不会改动 Codex、Claude Code、Cursor 等工具的配置；要显式执行 memmy-memory init 或 memmy-memory init --agent <agent>，才会给对应代理装上 Memory Skill 以及受支持的 Hook 或插件。也就是说数据流是代理触发 Hook，Hook 调本地记忆接口，记忆写进本地库，换到另一个代理时再读出来。这个设计把接入点放在代理自己的扩展机制上，所以支持列表取决于每个代理是否提供 Hook 或插件能力，README 列出的支持范围是 DeepSeek Harness、OpenClaw、Hermes、Claude Code、Codex、Cursor、WorkBuddy、OpenCode、Pi。至于记忆以什么格式落盘、检索用什么算法，README 没有展开，文档指向 memmy.bot/docs，本文无法确认。
安装路径分三条：桌面应用、CLI 安装脚本、源码构建
最省事的是桌面应用，从官网 memmy.bot 或 GitHub Releases 下载。第二条是 Linux 上的 CLI 安装，README 给出的前提很具体：x64 或 arm64、Node.js 22 及以上、有可用的 systemd 用户会话。命令是 curl -fsSL https://raw.githubusercontent.com/MemTensor/memmy-agent/main/scripts/install.sh | bash，然后直接运行 memmy。安装脚本会立刻把 memmy-memory.service 启起来；第一次裸跑 memmy 时，如果缺配置会先弹模型设置向导，然后启用 memmy-gateway.service，等它就绪后进入 TUI。这两个服务在 TUI 或终端退出后仍然活着，下次登录会重新启动，但安装脚本不启用 linger。用 systemctl --user status memmy-memory.service 和 systemctl --user status memmy-gateway.service 可以查看状态。第三条是源码构建：git clone 仓库、cp .env.example .env、npm install、npm run build，然后 bash scripts/dev-start.sh。README 里有一处需要留意，文档明确说只有安装脚本拉起的 CLI 才会启用这套服务管理，自行从源码构建的 Linux CLI 保持原有行为，两者在服务生命周期上并不一致。
BYOK 配置只有两个键，但环境变量的刷新逻辑值得注意
最小可用配置放在 ~/.memmy/config.yaml，README 给的例子是 agents.defaults 下写 model、provider、timezone，providers 下写对应厂商的 apiKey，值可以引用 ${OPENAI_API_KEY} 这样的环境变量。交互式配置走 memmy onboard，想直接生成默认文件用 memmy onboard --defaults，检查当前配置和模型用 memmy status，跑单轮任务用 memmy agent --message "..."，起 OpenAI 兼容 API 用 memmy serve。这里有一个容易被忽略的机制：每次启动或重连 Gateway 之前，memmy 会刷新 ~/.memmy/systemd/gateway.env，权限 0600，内容包含配置里引用的环境变量、常见厂商凭据以及终端的 PATH。如果这些值变了，下一次裸跑 memmy 会用新环境重启用户服务。好处是凭据不用写死在服务文件里，代价是你的 shell 环境成了服务运行环境的一部分，PATH 或环境变量的差异会直接反映到常驻服务上。
试用额度用完要切 BYOK，这是商业设计不是技术缺陷
README 的提示写得很直白：注册会赠送 Agent 任务试用额度，余额和用量在应用里显示，额度用完后切到 BYOK 模式使用自己的模型 API。这意味着记忆层本身是本地服务，但代理运行时默认走 Memmy 自己的额度体系。对个人开发者来说，这决定了成本结构：前期零成本试，长期要么持续付费，要么自己接模型。如果你的团队已经把模型调用收敛到内部网关，BYOK 是唯一现实的路径，配置里改 provider 和 apiKey 即可。需要提醒的是，README 没有说明试用额度的具体数量、有效期，也没有说明是否存在速率限制，这些只能到应用里看当前余额。
它不适合的场景：单代理用户、非 Linux 环境、以及不愿常驻服务的人
Memmy 的价值来自跨代理共享，如果你只用一个代理，这层记忆带来的收益接近于零，却要付出两个常驻用户服务的代价。平台限制也是硬约束：README 里的 CLI 安装脚本明确面向 Linux x64 或 arm64，并要求 systemd 用户会话，macOS 和 Windows 上能走的是桌面应用或源码构建，服务管理行为不同。接入需要显式执行 memmy-memory init，说明它不是透明的，代理侧要装 Skill 和 Hook，而 Hook 的行为依赖各代理自身实现，README 没有逐个说明支持程度，只给了支持列表。还有一点，记忆是长期累积的，写进去的内容会持续影响后续所有代理的输出，错误或过期的记忆如果没有清理手段，会变成跨工具的污染源。README 里没有描述记忆的过期、去重或人工修订流程，这是采用前应当自己确认的部分。
和 MCP 记忆服务器相比，差别在服务边界和接入方式
常见的替代做法是给每个代理单独接一个 MCP 记忆服务器，比如各类 memory MCP server。两者都做长期记忆，区别在边界：MCP 方案通常由代理进程按需拉起或由客户端托管，生命周期跟着代理走，每个代理各自配置；Memmy 把记忆做成独立于代理的本地常驻服务，代理只是客户端，所以换代理不用重建记忆。反过来说，MCP 方案的部署更轻，不要求 systemd，也不要求 Node.js 22，退出代理就没有后台进程。选哪个取决于你要的是共享还是轻量：多代理共享记忆，Memmy 的模型更贴合；只想给单个代理加记忆，一个 MCP 服务器就够，没必要引入 Gateway 和两个用户服务。
维护成本、许可证与版本节奏
MIT 许可意味着你可以读源码、改源码、把它嵌进内部工具链，商用也没有额外限制，但许可证不覆盖模型调用费用，也不覆盖官方托管的记忆服务，这部分取决于你选试用额度还是 BYOK。维护成本主要来自三处：Node.js 运行时版本要求 22 及以上；两个 systemd 用户服务需要随环境变化重启，gateway.env 会在每次裸跑 memmy 时刷新；代理侧的 Skill 和 Hook 在代理自身升级后可能需要重新初始化。版本节奏可以参考发布记录，v1.1.2 到 v1.1.4 集中在 2026 年 9 月 4 日到 9 月 9 日，属于高频小版本迭代，跟进升级前建议先看 release notes 里对配置和服务行为的改动。本文没有实际安装或运行该项目，以上机制均来自 README 与仓库元数据，记忆的存储格式、检索质量、跨代理接力的实际效果，需要在你的环境里用 memmy-memory health 和 memmy-memory search 自行验证。
编辑结论
如果你同时使用两个以上 AI 编程代理、且愿意让一套 systemd --user 服务常驻本机，Memmy 值得按 README 的流程装一遍再评估；如果你只用一个代理、或者不能接受本地常驻服务与私有格式的记忆库，它带来的复杂度大于收益。上手前先确认三件事：Node.js 是否达到 22、systemd 用户会话是否可用、以及你打算用注册赠送的试用额度还是切到 BYOK。验证顺序建议是 memmy-memory health 确认记忆服务在线，再跑 memmy-memory init --agent <agent> 只给一个代理装 Skill 和 Hook，观察记忆写入是否符合预期，最后才批量执行 memmy-memory init。
社区笔记