LongMemory：给 LLM 应用加一份带时间轴的本地记忆
Local persistent memory store for LLM applications including claude desktop, github copilot, codex, antigravity, etc.
秒懂
- 它是什么？
- LongMemory 是一个用 TypeScript 写的本地持久记忆引擎，面向 Claude Desktop、Copilot、Codex 等 AI 宿主。它把记忆当作带时间戳、带来源、带权限的图来管理，而不是简单的向量检索。
- 适合谁用？
- LongMemory 适合那些已经受够了「每次对话都失忆」的 LLM 应用开发者，尤其是需要追溯事实变更、按权限隔离记忆、或者要把记忆导出给多个 Agent 宿主的人。它不适合只想快速做向量检索的团队，因为它的核心概念（节点、世界、有效时间、衰减）会带来额外的学习成本。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是「检索不是记忆」的问题
很多号称记忆的系统，本质是三条流水线：切块、嵌入、返回最近邻。这种方案回答不了几个关键问题：某条事实在 1 月是否成立？新事实是否取代了旧事实？哪个来源更权威？谁有权限看到这条记忆？LongMemory 的 README 明确把这些担忧写进了设计目标。它把记忆建模为带时间戳的图，节点不可变，边带类型，世界（world）用来隔离不同的事实版本。适用对象是那些需要跨会话保持上下文、并且需要追溯或审计的 LLM 应用。
时间真相：记录时间与有效时间分开
LongMemory 区分 recorded time 和 valid time，这是它区别于普通向量库的核心。记录时间是知识进入系统的时刻，有效时间是这条事实在现实世界中成立的时间段。召回时你可以问「当前部署区域是哪里」，也可以问「1 月的部署区域是哪里」。后者在普通 RAG 里几乎无法回答，因为旧文档可能已被新文档覆盖。LongMemory 用历史召回模式保留被取代的真相，而不是物理删除。这种设计对审计场景有价值，但也意味着存储会随时间增长，README 没有给出压缩策略的细节。
MCP 集成：工具参数不能越权
LongMemory 暴露了 13 个高层级工具，这些工具通过 MCP（Model Context Protocol）暴露给 Agent 宿主。你可以用 `longmemory mcp --db .longmemory/project.db --project current` 启动本地 stdio MCP，也可以用 `LONGMEMORY_API_KEY=change-me longmemory serve --mcp-http` 暴露带认证的 HTTP MCP。关键约束是工具参数不能覆盖服务端绑定的运行时身份，也就是说 Agent 无法通过传参来越权访问其他租户或用户的记忆。这种设计把权限边界放在服务端，而不是依赖 Agent 自觉。支持 Claude Code、Codex、OpenCode、Gemini CLI、Copilot Chat、Cline，覆盖了主流宿主。
五种召回模式，各有适用场景
README 展示了五种召回模式。strict 模式应用时间、矛盾、契约、置信度和接地门控，适合需要高确定性的查询。historical 模式接受 valid_time 参数，返回指定时间点的真相。associative 模式结合语义、词汇、实体、激活和图信号，适合「找出与支付迁移相关的事件」这类模糊查询。world_grounded 模式要求当前的外部证据，适合验证生产端点是否仍然有效。这些模式不是装饰，它们对应不同的推理需求。普通向量检索只有一种相似度，这里每种模式有独立的门控逻辑。代价是调用方需要理解每种模式的行为差异。
部署：本地优先，但也可以跑成服务
作为服务运行时，LongMemory 提供 HTTP API、MCP 端点、dashboard 和健康检查。默认端口 7331，dashboard 在 3000。Docker 部署需要挂载数据卷 `longmemory-data:/data` 并设置环境变量 `LONGMEMORY_API_KEY`。从源码构建需要 corepack 和 pnpm，步骤为 `pnpm install --frozen-lockfile`、`pnpm build`、`pnpm start`。Docker Compose 方式更简单，复制 `.env.example` 后 `docker compose up --build -d longmemory`。如果要 dashboard，加 `--profile ui`。健康检查端点 `/health` 可用于编排系统。
对比：它和纯 RAG 工具不是一回事
与 LongMemory 形成对比的是 SuperMemory 这类纯检索工具。SuperMemory 通常只做「保存网页或文本，然后按相似度召回」，不区分记录时间和有效时间，也不提供图结构和权限模型。LongMemory 则把记忆当作一等公民来治理，支持项目、租户、用户、团队、角色、Agent 作用域。如果你只需要快速找到以前写过的片段，SuperMemory 的轻量模型更直接。但如果你需要回答「这个决定是什么时候做出的，谁批准的，后来被推翻了吗」，LongMemory 的图和时间轴就是必要的。两种工具解决的是不同层级的问题。
谁该用，谁不该用
结论：如果你正在构建一个需要跨会话记忆的 Agent，并且对「事实何时为真」有要求，LongMemory 值得试用。先用 npm 包和 SQLite 跑通一个 demo，验证 strict 和 historical 模式是否符合你的预期。如果你的应用只需要关键词搜索，不要选它。在把它接入生产前，先确认 embedding 服务的可用性，以及你能否接受 Apache-2.0 的条款。最后，跑一次它自带的 benchmark，用数据说话，而不是凭感觉。
编辑结论
LongMemory 适合那些已经受够了「每次对话都失忆」的 LLM 应用开发者，尤其是需要追溯事实变更、按权限隔离记忆、或者要把记忆导出给多个 Agent 宿主的人。它不适合只想快速做向量检索的团队，因为它的核心概念（节点、世界、有效时间、衰减）会带来额外的学习成本。在采用之前，先确认两件事：你的 embedding 服务是否兼容 OpenAI 或 Ollama 接口，以及你是否愿意接受 Apache-2.0 许可下对修改版本的公开要求。若只是单机实验，用 npm 包加 SQLite 即可，不必急着部署 Docker 服务。
社区笔记