Graphiti 调研：时序知识图谱 + 论文级记忆检索，Agent 长期记忆的新 baseline？

Zep 团队开源的时序知识图谱引擎，把“AI 记得住、追得到源、还能随时间更新”这件事，从愿景落到了开源代码和论文里。

写在前面

大多数 AI 系统有个通病：你一停止对话，它就把之前聊的内容全忘了。你喂给它 facts、context、chat logs，会话一结束，上下文直接清空。以前解决这个问题的办法，大多是向量数据库 + 摘要 + 滑动窗口，本质仍是“静态记忆”——把历史压扁、存起来，下次直接丢给模型。问题是，真实业务里的信息是不断变化的，昨天说“我喜欢 Adidas”，今天改口“我喜欢 Nike”，静态记忆系统只会产生冲突上下文，让大模型犯晕。

Graphiti 想换一条路：它不把记忆当成文档集合来检索，而是把记忆建成一张 会随时间演化的知识图谱。新信息进来，图谱增量更新；旧事实被推翻，不是删除，而是打上“失效时间”，保留完整时间线。这篇文章就拆一下这个思路靠不靠谱、适合谁、以及现在落地还差几步。

一、它解决什么问题

Graphiti 的核心定位是：为 AI Agent 构建和查询时序感知知识图谱。它不是通用的知识图谱工具，也不是传统的 RAG 引擎，而是专门面向“动态、经常变化的数据 + 需要长期记忆的 Agent”这个交叉场景。

一句话总结：Graphiti 让 Agent 的记忆从“静态文档检索”变成“动态事实图谱”，并且每个事实都带时间戳和溯源。

二、时序知识图谱：不是静态 KG，是带 validity window 的记忆

传统知识图谱的问题是一旦建完就基本定型。Graphiti 的思路完全不同：图谱里的每个 fact 都有 有效性窗口——什么时候变成真的，什么时候被新的信息覆盖。它把图谱拆成三个层次：

• Entities（实体）：人、产品、政策、概念，附动态摘要，会随时间演化
• Facts / Relationships（事实 / 边）：三元组，带 temporal validity window，旧事实自动失效而非删除
• Episodes（原始片段）：所有推导出来的事实都能回溯到原始数据，形成完整 lineage

举个例子：用户昨天说“我不喜欢吃西瓜”，今天说“我喜欢吃西瓜”。Graphiti 不会在图上留两条冲突边，而是把前一条标为失效，保留历史，同时记录新事实。Agent 检索时能知道“现在是真的，但昨天反过来说过”。

这种设计本质上是在模仿人类的 情节记忆 + 语义记忆：既有原始经历，又有抽象后的事实，还能知道事实随时间变化。

三、混合检索：语义 + 关键词 + 图遍历，不用 LLM Summarize

Graphiti 的另一个核心能力是 混合检索。很多 RAG 系统依赖 LLM 做摘要式检索，Graphiti 则把三种检索方式拧在一起：

• 语义检索：embedding 相似度，理解语义
• 关键词检索：BM25，精准匹配
• 图遍历：沿着实体关系跳转，做多跳推理

三者结果融合后返回，延迟据官方说法是 sub-second。这意味着 Agent 拿到的不只是“最像的历史片段”，而是 结合了关系、时间、语义的综合上下文。

额外加分项是它支持自定义 Ontology。开发者可以通过 Pydantic 模型定义实体类型和边类型，让图谱结构贴合业务，而不是被通用 schema 绑死。

四、平台集成：LangChain / LlamaIndex / MCP 一应俱全

Graphiti 不是孤立运行的图谱引擎，它从设计上就考虑了 Agent 框架的接入：

后端存储也给了多选：

五、对比：Graphiti vs Mem0 vs MemGPT vs GraphRAG

这几个经常被放在一起比较，但定位其实差很多：

结论很清晰：如果你的场景是 信息持续变化、需要跨会话长期记忆、对时间线敏感（比如 CRM、个人助理、客服 Agent），Graphiti 的增量时序图谱是当前最贴近答案的选择；如果只是“给 FAQ Bot 加个长期记忆壳子”，Mem0 或 MemGPT 可能更快。

六、实战：3 步跑通 Graphiti

Graphiti 官方推荐的最小可用栈是 FalkorDB（Docker 一键）+ Python 3.10+。

第一步：启动图数据库

docker run -p 6379:6379 -p 3000:3000 -it --rm falkordb/falkordb:latest

第二步：安装 Graphiti

pip install graphiti-core

需要 Python 3.10+，建议配虚拟环境。如果需要 Anthropic / Groq / Gemini 作为 LLM 提供商，对应装 extra：

pip install "graphiti-core[openai,anthropic]"

第三步：写入并查询

from graphiti_core import Graphiti

graphiti = Graphiti(
    uri="bolt://localhost:7687",
    user="neo4j",
    password="password",
)

# 写入一段原始对话
await graphiti.add_episode(
    name="user_session_1",
    episode_body="User said they love Adidas shoes in March 2026.",
    source="message",
)

# 检索
results = await graphiti.search("What brands does the user like?",)

官方还有 MCP Server，装完后 Claude Code / Cursor 可以直接通过 MCP 调用 Graphiti 做记忆检索，不需要手写 SDK 代码。

七、风险与坑

1. 图数据库运维成本：Graphiti 的核心优势来自图存储，但也意味着你必须维护 Neo4j/FalkorDB。小型项目可能觉得过重。
2. Kuzu 已弃用：官方明确说上游不再维护，新项目不要踩。
3. LLM 依赖结构化输出：Graphiti 默认用 OpenAI / Anthropic / Gemini 做抽取，模型必须支持 structured output，否则 ingestion 容易失败。小模型慎用。
4. 图谱噪音：动态图谱不是银弹。如果 episode 质量差、实体抽取不稳定，图谱会快速变脏，检索精度反而下降。
5. 生产监控需自建：Graphiti 是开源引擎，不像 Zep Cloud 自带 dashboard 和 graph visualization，生产环境要自己补监控和调试工具。

八、总结

Graphiti 目前最值得装的理由有三条：

1. 时序语义是目前 Agent 记忆最缺的能力：静态 RAG 解决不了“用户昨天说的今天反悔了”这类问题，Graphiti 是少数开源方案里原生支持 validity window 的。
2. 论文 + 生产双层验证：有 arXiv 论文（DMR 94.8% vs MemGPT 93.4%，LongMemEval 提升 18.5%），也有 Zep Cloud 的线上业务背书，不是 toy project。
3. MCP / LangChain / LlamaIndex 全栈打通：不是让你换掉现有框架，而是作为记忆层插进去用。

如果你现在就在做需要长期记忆的 AI 助理、客服 Agent、或个人知识库助手，Graphiti 值得花一个周末按官方 quickstart 跑一遍，感受一下“动态事实图谱”和传统向量检索的差异。大多数人在第二步就会明白：原来记忆不只是“存得下”，更重要的是“追得到源、记得住变化”。

参考

• getzep/graphiti
• Zep: A Temporal Knowledge Graph Architecture for Agent Memory
• Graphiti 官方文档
• Zep Cloud / Context Lake
• awesome-ai-memory
• Graphiti 源码解读（博客园）