GraphMemory：双时态记忆把“何时发生”和“何时记录”分开

先给结论：GraphMemory 是一个面向 AI Agent 的双时态记忆服务，试图同时保存“事实在现实中何时有效”和“系统何时记录或修订了事实”。仓库还提供事实抽取、检索、衰减策略、MCP 工具、REST API 与简单管理页面。它的设计范围比轻量向量记忆库更宽，但目前是刚创建不久的 0.1.0 项目，没有 GitHub Release；启动需要 Neo4j、PostgreSQL/pgvector、Redis，以及可用的 LLM 和 embedding 接口。它适合技术团队做本地原型和数据模型研究，不宜未审查就承载真实个人资料。

为什么需要两个时间轴

例如用户曾在 A 公司任职，后来转到 B 公司。只存一条“当前公司”会覆盖过去；只保留聊天时间又未必能回答事实从哪一天起有效。GraphMemory 将 valid time（事实有效时间）与 transaction time（入库或记录时间）分开，支持按当前视角或历史视角查询。README 将底层 Graphiti 用于实体关系图，将事实台账、状态和 episodes 放入 PostgreSQL，并用 Redis 保存检索缓存。

检索链路不仅是向量相似度。仓库描述六个衰减变量、时间梯度、TTL、去重、冲突裁决和访问后巩固，再通过竞争检索筛出 Top-K。MCP server 提供记忆读写和时间线等工具。这些衰减与检索规则是项目设计，不是经过独立评估的记忆准确率结论。

部署流程按 README 需要 Python 3.10 以上与 Docker Compose，启动 Neo4j 5.26、PostgreSQL 16+pgvector、Redis 7；随后创建数据库 schema，再运行 FastAPI 服务。Embedding 和事实抽取从环境变量读取，可连接 OpenAI 兼容 endpoint。仓库附有 add/search、时间线、MCP 配置与 pytest 示例；但启动三类存储和模型服务的成本明显高于单文件插件。桌面悬浮球和 IM 适配器不在仓库中；项目边界是后端服务、API、MCP 与 Web 管理页面。

隐私与删除边界是重点

项目的 privacy 文档说 API key 和数据库密码应从环境变量配置，并建议修改示例密码、启用 API_KEY、把 Neo4j、Postgres 与 Redis 限制在本机或内网。Compose 默认只绑定 127.0.0.1；API_KEY 默认空、示例密码只供开发，仍需检查反向代理、端口与备份。

尤其要看清“遗忘”的含义：项目说明 memory_forget 或去重会写墓碑并删除若干事实状态表，但 episodes 原文账本默认永久保留用于审计；TTL 到期也先隐藏，再宽限一天后删除事实状态，原文仍保留。若用户要求彻底擦除聊天与派生数据，当前默认策略不够，必须自定义删除逻辑，并覆盖数据库备份、导出文件和日志。这是该项目最重要的产品边界，不能只看工具名 memory_forget 就推断数据已不可恢复。

如何做负责任的试点

建议先使用虚构对话数据，设计有时间变化、纠错和删除请求的测试集，逐条检查抽取的 valid_from/until、冲突处理、查询来源和跨用户隔离。确认需要 embedding、LLM 抽取和记忆召回后，再测费用、延迟、数据库增长与定时衰减。不要把尚未验证的记忆直接注入有工具权限的 Agent；记忆来自用户和模型，应始终视为不可信内容，工具调用另做服务端授权。

GitHub API 显示该仓库创建于 2026 年 10 月 30 日，当前约 183 颗星、MIT 许可，默认分支标记 0.1.0。README 提供 pytest 运行方式，但本文未对外部服务进行端到端测试；没有公开 release 也意味着版本稳定性和升级政策尚待观察。评估者应先固定 commit 与数据库镜像，再阅读迁移脚本和隐私代码，不能仅凭 README 的功能表就认为所有通路已验证。

结论：GraphMemory 的双时态、账本与 MCP 组合值得关注，特别适合研究 Agent 如何保留可追溯的历史事实。它当前更像需要开发团队维护的实验性后端：依赖栈不轻，数据删除不是彻底擦除，访问控制也需要按自身部署补齐。先用合成数据验证数据模型和安全边界，再决定是否进入真实业务试点。

参考资料

1. GraphMemory repository
2. 项目功能与安装说明
3. API 和 MCP 接口示例
4. 隐私、安全与删除说明
5. 设计记录和系统架构
6. Docker Compose 配置
7. MIT 许可